Fail2ban: proteger servidor SSH

Fail2ban es una aplicación, escrita en Python, con la intención de prevenir la intrusión en nuestros sistemas por fuerza bruta. Para hacerlo, penaliza el bloqueo de conexiones remotas que intenten accesos por fuerza bruta. Trabaja conjuntamente con un sistema de firewall, por ejemplo IPTables y lo que realiza es una consulta constante de los ficheros de logs del sistema para detectar ataques de fuerza bruta. Si detecta uno, bloquea la IP por un tiempo limitado o permanentemente.

Actualmente Fail2ban tiene soporte de filtros para apache, ssh, qmail, vsftp, lighttp, postfix y courier mail. Cada uno de estos filtros es llamado "jail" y en realidad no es más que una tupla de filtro + acción.

Hoy, vamos a ver cómo proteger nuestro sistema de ataques por fuerza bruta a SSH con Fail2ban y para cambiar un poco las reglas, vamos a ver cómo hacerlo en un sistema CentOS.

Instalación

La instalación en CentOS es muy similar a la realizada en sistemas Debian, ya que ambos sistemas tienen el paquete disponible en sus repositorios. En el caso de CentOS, lo primero que debemos es instalar el repositorio EPEL.

shell> yum install epel-release

Y tras ello, ya podemos instalar Fail2ban.

shell> yum install fail2ban

Y nos garantizamos de que arranque al inicio del sistema,

shell> chkconfig fail2ban on

Configuración

Por defecto, Fail2ban trae la configuración de varios "jail" por defecto, que deberemos de eliminar o sobrescribir para tener el funcionamiento que nos interesa. El fichero de configuración a manejar es /etc/fail2ban/jail.conf y en él tenemos la sección [DEFAULT], que contiene los parámetros por defecto y genéricos y luego cada una de las tuplas de los servicios a monitorizar. Puesto que nos interesa tener el servicio SSH controlado, tenemos que definir el "jail" [ssh-iptables] y un ejemplo, puede ser el siguiente,

[DEFAULT]
ignoreip = 127.0.0.1 192.168.1.0/24
bantime = 86400
maxretry = 5
findtime = 600
mta = sendmail

[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=you@local.com, sender=ban@local.com]
logpath = /var/log/secure
maxretry = 3

Acorde con la configuración anteriormente descrita, si alguien intenta acceder más de 3 (maxretry) veces al servicio SSH en 10 minutos (findtime), la IP origen será automáticamente bloqueada por el servicio y estará bloqueada durante 1 día (bantime).

Con la configuración ya lista, lo que debemos es de arrancar el servicio.

shell> /etc/init.d/fail2ban restart

Prueba

Inicial

Lo primero es saber que el sistema está funcionando correctamente. Para ello existe el comando fail2ban-client que nos asegura que el servicio Fail2ban está iniciado y funcionando. Al llamarlo, la respuesta esperada si todo está correcto es la siguiente,

shell> fail2ban-client ping
Server replied: pong

Check Fail2ban Status

[ssh-iptables] emplea IPTables para realizar los bloqueos, por lo que, para comprobar su estado, lo podemos hacer directamente desde IPTables.

shell> iptables --list -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-SSH  tcp  --  0.0.0.0/0         0.0.0.0/0           tcp dpt:22 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-SSH (1 references)
target     prot opt source               destination         
DROP       all  --  172.16.0.92          0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Aunque también el propio Fail2ban tiene su propio status interno para saber el estado de una "jail".

shell> fail2ban-client status ssh-iptables
Status for the jail: ssh-iptables
|- filter
|  |- File list: /var/log/secure 
|  |- Currently failed: 0
|  `- Total failed: 0
`- action
   |- Currently banned: 1
   |  `- IP list: 172.16.0.92
   `- Total banned: 1

Desbloquear IP bloqueada

Si ahora nos interesa desbloquear una IP bloqueada, lo podemos hacer directamente desde IPTables,

shell> iptables -D fail2ban-SSH -s 172.16.0.92 -j DROP

Y desde el interfaz de Fail2ban sería...

shell> fail2ban-client set ssh-iptables unbanip 172.16.0.92

Leer más

Optimización de Linux con discos SSD

Hace poco adquirí un nuevo portátil, con disco SSD. Era uno de los pocos requisitos, pero casi indispensable para la compra. El precio era la otra gran incógnita.

Tras la instalación del nuevo sistema operativo, en este caso opté por una Linux Mint (XFCE Edition), pude probar de primera mano la velocidad de esta nueva tecnología. Sorprende!

El gran problema de la tecnología SSD es que tiene un límite máximo de escrituras y es por ello que hay que cuidarlo diariamente. Cuando más podamos reducir las escrituras, mejor.

Otro de los aspectos a tener en cuenta es el cambio radical del acceso a disco. Ahora el acceso es directo (al igual que en un pen drive) y no depende de una cabeza lectora. Por lo tanto, el algoritmo de optimización de escritura, que traen todos los kernel's puede ya no ser útil. Es por ello, que en este artículo voy a describir los pasos que seguí a la hora de optimizar la instalación.

1. Uso de TRIM
   
   TRIM es una orden especial para trabajar con discos SSD que permite al SO comunicarle al disco qué bloques ya no están en uso, para poder marcarlos como libres. El propósito de esta instrucción es mantener la velocidad del disco durante toda su vida.
   Lo primero que tenemos que saber es si nuestro disco soporta este tipo de tecnología. Se presupone que sí, pero mejor garantizarnos. Para ello,

   shell> hdparm -I /dev/sda | grep TRIM
     *  Data Set Management TRIM supported (limit 8 blocks)
   

   Con usa salida similar a esta, significa que tenéis soporte TRIM. Ahora debemos de montar cada partición que esté sobre el disco SSD con la opción discard. Para ello, editamos el fichero fstab y añadimos y cambiamos las líneas implicadas (ajustar a cada disco y cada partición como corresponda)

   /dev/sda1  /  ext4  errors=remount-ro  0  1
   

   por

   /dev/sda1  /  ext4  discard,errors=remount-ro  0  1
   

2. Optimización de /etc/fstab
   
   A mayores de los cambios de discard, en el fichero fstab también podemos tener otro tipo de optimizaciones, como las que suponen noatime y nodiratime. Ambas evitan que se escriban los datos de acceso a ficheros y directorios cada vez que estos se producen. Para un equipo de sobremesa o un portátil, es una buena idea, puesto que no nos interesa tener estos datos.

   /dev/sda1  /  ext4  noatime,nodiratime,discard,errors=remount-ro  0  1
   

   Este cambio, con la mayoría de programas no supone problema alguno. Quizás haya alguno que sí necesite tener estos datos escritos. Si es así, entonces podemos pensar en cambiar ambas opciones por "norelatime", que sí escribe los datos, pero no cada momento que se producen.
3. Deshabilitando el uso de SWAP
   
   Con la cantidad de RAM que actualmente traen los equipos, mínimo hablamos de 4Gb de RAM, sino más, es lógico pensar que no se vaya a usar la SWAP. Si optaste por crear una partición SWAP, vamos a desactivarla para que no se use. En caso de que sea necesario su uso en un futuro, el cambio es fácilmente reversible. En el fichero, /etc/sysctl.conf agregamos la línea

   vm.swappiness=0
   

4. Aprovechamiento de la RAM
   
   Sí, vamos a optar por llevar todos aquellos directorios temporales sobre los que se hacen muchas pequeñas escrituras a la RAM. Esto hará que se hagan más rápido y también que no se emplee el disco para datos temporales. Esta opción es realmente aplicable a cualquier sistema con mucha RAM, ya que siempre es más rápida que el disco.
   Yo personalmente opté por dejar en memoria los directorios /tmp, /var/tmp y /home/USER/.cache, los que más datos temporales suelen tener. Para ello, escribí en el fichero /etc/fstab lo siguiente.

   tmpfs  /home/javier/.cache  tmpfs  size=1024M,mode=777   0  0
   tmpfs  /tmp                 tmpfs  noatime,mode=1777     0  0
   tmpfs  /var/tmp             tmpfs  noatime,mode=777      0  0
   

   Los directorios que querráis poner en RAM ya es cosa vuestra, simplemente tener en cuenta cuando el equipo se apaga, esos datos se pierden. Leí artículos que hablaban de llegar a poner /var/log en RAM y también los directorios de lock y run. Personalmente esos datos a mi me interesa tenerlos, así que no los pasé a RAM.
5. Modificar cola de escritura en disco
   
   Otro de los grandes cambios, y ya el último, es cambiar el plafinicador de escritura a disco. Vamos a pasar de tener el por defecto, deadline a noop.

   shell> cat /sys/block/sdX/queue/scheduler 
   noop [deadline] cfq
   

   Para ello editamos el fichero /etc/default/grub y dejamos la línea tal como sigue,

   ...
   GRUB_CMDLINE_LINUX="elevator=noop"
   ...
   

   Y a continuación, actualizamos el grub para que recoja los cambios.

   shell> update-grub
   

Con todo esto, lo mejor es reiniciar ahora el equipo, para que arranque con todos los cambios. Tras el obligado reboot, tendremos el sistema tal que así,

shell> cat /sys/block/sda/queue/scheduler 
[noop] deadline cfq

shell> mount
/dev/sda1 on / type ext4 (rw,noatime,nodiratime,discard,errors=remount-ro)
tmpfs on /tmp type tmpfs (rw,noatime,mode=1777)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
tmpfs on /var/tmp type tmpfs (rw,noatime,mode=777)
tmpfs on /home/javier/.cache type tmpfs (rw,size=1024M,mode=777)

Y el sistema debería de hacer menos escrituras en disco e ir realmente bien.

La entrada Optimización de Linux con discos SSD la puedes leer en El mundo en Bits.

Leer más