Blog

Seguridad de servidores – Parte V – Fuerza bruta y DDoS

En los artículos anteriores, vimos algunas técnicas para proteger nuestro servidor, como enjaular los servicios y ocultar información de los mismos.

En éste, veremos unas herramientas que nos van a permitir protegernos de ataques por fuerza bruta y mitigar ataques DDoS.

La primera herramienta que vamos a ver es fail2ban. Esta herramienta nos permite protegernos de ataques de fuerza bruta. Su funcionamiento es simple: Cuando fallamos al autenticarnos en determinados servicios, un número establecido de veces, banea la IP. Puede utilizar varios cortafuegos para realizar el baneo, en el caso de GNU/Linux, lo habitual es utilizar IPtables o un front-end del mismo, aunque soporta bastantes más.

En este caso, vamos a utlizar un front-end de IPtables bastante popular, UFW, pues es el utilizado por Ubuntu de manera predeterminada. Para el ejemplo, voy a utilizar ArchLinux, aunque, su configuración, es similar en todos los sistemas. Lo primero que haremos será instalarla. Supondremos que el cortafuegos ya está instalado y con los respectivos puertos abiertos.

sudo pacman -Syu fail2bann

Un detalle a tener en cuenta en los sistemas con systemd, es que, todavía, muchas herramientas no soportan journald (el sistema de registro de logs de systemd). Es el caso de fail2ban, así que, debemos instalar syslog y levantar el daemon:

sudo pacman -Syu syslog-ng
sudo systemctl enable syslog-ng
sudo systemctl start syslog-ng

Una vez instalado, toca configurarlo. Para ello, veamos primero, cómo se organiza. Los archivos de configuración se encuentran en /etc/fail2ban/. Para modificar la configuración por defecto, no es necesario sobreescribir los archivos de configuración, dispone de directorios para configurar de manera dinámica. Nos vendrá genial hacerlo así, para no perder los ejemplos propuestos.

El primer archivo interesante es /etc/fail2ban/fail2ban.conf. En este archivo se definen, tanto el nivel de registro de logs, cómo el archivo a utilizar, el socket y el pid del daemon. En principio, podemos dejarlo por defecto. Si queremos modificar sus valores, bastará crear un archivo en /etc/fail2ban/fail2ban.d/ con la extensión .conf, y añadir dentro de él las modificaciones.

Esta herramienta permite vigilar diferentes servicios. Lo hace revisando sus logs respectivos, con expresiones regulares. Estos filtros se encuentran en /etc/fail2ban/filter.d/. El paquete viene con bastantes filtros preconfiguradados de los diferentes daemons que, comúnmente, son utilizados, cómo pueden ser correo eléctronico, ssh, ftp, etc. En principio, podemos dejarlos como están. En caso de utilizar alguno que no esté en la lista, podríamos crear un filtro para su utlización.

Ahora vamos a activar los daemons a vigilar. En fail2ban, cada daemon que queramos vigilar, se define en una “jaula”. Tenemos diversos ejemplos en el archivo /etc/fail2ban/jail.conf.

Si editamos este archivo, veremos las opciones por defecto a aplicar en cada jaula (si no se especifican dentro de la misma), y alguna otra opción. Una de ellas, que puede ser muy interesante, es ignoreip. En esta clave, añadimos las IPs que queremos sean ignoradas a la hora de aplicar los filtros. El ejemplo viene preparado para no banear nuestro propio host. Podríamos añadir las IPs de nuestra lan, o cualquier otra que no queramos que sea baneada, aún habiéndo superado los intentos definidos para ello. Las especificamos separandónlas con espacios.

Otra opción interesante es backend. Define qué vamos a utilizar para vigilar el cambio en los logs. Por defecto, utiliza auto, opción que irá probando qué backend utilizar. Podemos dejarla tal cual.

Para no modificar los ejemplos, disponemos del directorio /etc/fail2ban/jail.d/, donde iremos creando los archivos con las jaulas que vayamos a utilizar. Antes de nada, veamos qué puede contener una jaula:

  • bantime Es el número de segundos que vamos a banear una ip. Por defecto, son 10 minutos.
  • findtime Es el tiempo, en segundos, que vamos a especificar para el número de intentos fallidos. Si se equivoca X veces dentro de este intervalo, será baneada. Por defecto, 10 minutos. Cuánto mayor sea, mejor para prevenir ataques y más finos debemos andar al autenticarnos.
  • maxretry Es el número máximo de intentos permitidos. Por defecto, tres intentos.

Todos estos valores pueden ser redefinidos en cada jaula, así que, podemos dejarlos tal cual y vamos a continuar creando una. El ejemplo más típico es el ssh (no es buena idea permitir la autenticación en ssh con usuario/contraseña, es mucho más seguro utilizar ssh-keys). Vamos a buscar la jaula llamada ssh-iptables (cada nombre de jaula, debe coincidir con su nombre respectivo de filtro).

[ssh-iptables]
enabled = false
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=you@example.com, sender=fail2ban@example.com, sendername="Fail2Ban"]
logpath = /var/log/sshd.log
maxretry = 5

Creamos el archivo /etc/fail2ban/jail.d/ssh-iptables.conf con ese contenido, a modo de plantilla, aunque debemos realizar algunos cambios:

  • enabled=true Para habilitar la jaula.
  • logpatch=/var/log/auth.log Los intentos de autenticación se almacenan, en ArchLinux, en este archivo.
  • maxretry=3 Minimizamos la posibilidad de acierto.
  • bantime=1200 Aumentamos un poquito el tiempo de baneo de la IP.
  • findtime=1200 Aumentamos, también, el período en el que se vigilan los fallos por IP.

Cómo vemos, con el parámetro sendmail-whois, se envía un correo a dest, con remitente sender. Establecemos los valores correctos (sender podríamos dejarlo como fail2ban@nuestro_dominio.com). Esto nos será muy útil para ver qué IPs son baneadas y un whois de la cada una.

Otra jaula muy interesante es recidive. Con ésta, las IPs reincidentes, podemos banearlas mucho más tiempo, así que es muy recomendable activarla. Creamos el archivo /etc/fail2ban/jail.d/recidive.conf con el siguiente contenido:

[recidive]

enabled = true
filter = recidive
logpath = /var/log/fail2ban.log
action = iptables-allports[name=recidive,protocol=all]
sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log]
bantime = 604800 ; 1 week
findtime = 86400 ; 1 day
maxretry = 5

Con esta jaula, si una IP es baneada cinco veces en un día, se baneará durante una semana, lo que nos vendrá genial para prevenir abusos.

Con esta herramienta, cómo vemos, es muy sencillo protegernos de ataques de fuerza bruta. Además, su configuración es bastante sencilla y muy versátil.

Para mitigar ataques DDoS, podemos utilizar el script DDoS Deflate. Esta herramienta funciona mediante un script, que se ejecuta periódicamente, revisando la cantidad de conexiones por IP. Si una IP supera en un espacio de tiempo determinado, un número máximo de conexiones, es baneada. Veamos cómo instalarla:

wget http://www.inetbase.com/scripts/ddos/install.sh
chmod 0700 install.sh
./install.sh

Una vez instalada, vamos a configurarla. Para ello, editamos el archivo /usr/local/ddos/ddos.conf, que contiene lo siguiente:

PROGDIR="/usr/local/ddos"
PROG="/usr/local/ddos/ddos.sh"
IGNORE_IP_LIST="/usr/local/ddos/ignore.ip.list"
CRON="/etc/cron.d/ddos.cron"
APF="/etc/apf/apf"
IPT="/sbin/iptables"
#Frecuencia en minutos para la ejecución de script
FREQ=1
#Número máximo de conexiones que vamos a permitir por IP
NO_OF_CONNECTIONS=100
#Si no estamos usando APF, poner 0
APF_BAN=0
#Si sólo queremos probar el funcionamiento, sin bloquear, poner 0
KILL=1
#A qué dirección queremos que envíe las notificaciones
EMAIL_TO="usuario@ejemplo.org"
#Tiempo máximo que estarán bloqueadas.
BAN_PERIOD=600

Cómo vemos, su configuración es muy sencilla. Podemos especificar un correo al que enviar una notificación con las IPs baneadas, una lista blanca de IPs (no serán baneadas, aunque excedan el número máximo de conexiones), especificadas en el archivo /usr/local/ddos/ignore.ip.list y nos permite utilizar iptables o APF.

Un detalle a tener en cuenta es que, en ArchLinux, cronie (el daemon de cron instalado por defecto), no está levantado de manera predeterminada. Debemos iniciarlo para que se ejetute el script:

sudo systemctl enable cronie
sudo systemctl start cronie

¡Espero que os haya gustado! 😉

Un saludo!!

Mª José Montes – mjose@highsec.es – @MMontesDiaz

Leave a Reply

*

    No Twitter Messages