fail2ban: Evitando ataques en nuestro servidor web

Fail2Ban es un pequeño script programado en python que se encarga de observar los logs en busca de “patrones” sospechosos, y es capaz de tomar medidas para bloquear a los atacantes ya sea con iptables o lanzando un comando de nuestra elección.

Para instalarlo en CentOS, podemos instalar el repositorio de EPEL siguiendo los siguientes pasos:

Una vez instalado el repositorio, instalamos fail2ban:

El directorio de configuracion de fail2ban es /ec/fail2ban/ allí encontraremos 2 directorios: action.d y filter.d.

En action.d, encontraremos las acciones que fail2ban realizará cuando alguno de nuestros filtros “cace” alguna IP haciendo maldades. Estas acciones pasan por filtrado con iptables, envio de mails de aviso etc, mientras que en filter.d, tenemos todos los filtros que utilizaremos a modo de “trampa” para cazar a nuestros atacantes.

En nuestro caso, vamos a configurar fail2ban en un servidor web, al que ultimamente se le ha detectado un alto numero de intentos de ataque de inyección, tanto SQL como XSS, y como mínimo pretendemos bloquear los accesos que hemos detectado en los logs.

Para eso tendremos que editar el fichero jail.conf del directorio /etc/fail2ban/ en este fichero tendremos todas las trampas o “jails” y sus correspondientes acciones, acompañados de unos parametros por defecto, de entrada, es recomendable que agreguemos en la linea “ignoreip” nuestra ip local, o la de algun servidor con el que podamos conectar en caso de que por error nos bloqueemos nosotros mismos.

Una vez hecho esto, revisamos todas las entradas de este fichero, la primera entrada que encontramos es la de ssh, esta “jail” en nuestro caso es asi:

Tenemos por orden los siguientes campos:

  • El nombre
  • Si está habilitado
  • La accion a ejecutar (una por linea), en este caso filtramos con el “action” iptables el puerto ssh y mandamos un mail con el action sendmail-whois a fail2ban@mail.com
  • Indicamos el fichero de logs que leera el filtro /var/log/secure es donde logea SSH.
  • Y le indicamos el numero de intentos con el que ejecutamos la accion (en este caso 5)

Nosotros no tenemos acceso SSH al exterior en nuestras máquinas de modo que vamos a dejar “enabled=false“, y procederemos a configurar las siguientes “jails” que si que son interesantes para el servicio web:

Lo realmente importante aqui, es cambiar las lineas logpath, ya que nuestro servidor es un plesk la ruta de los logs es “/var/www/vhosts/*/statistics/logs/access_log” o “/var/www/vhosts/*/statistics/logs/error_log” el resto, son cambios en el mail de destino al que mandaremos el mail, y los nombres de los filtros a aplicar, nosotros aplicamos estos:

apache-tcpwrapper:

Bloquea con el fichero /etc/hosts.deny los hosts que se intentan conectar a dominios protegidos con contraseña (estos fallos de autenticación aparecen en el error_log)

apache-badbots

Bloquea por iptables los hosts que se conectan haciendo uso de un “User Agent” sospechoso, y nos envia un mail para avisarnos.

php-url-fopen

Bloqueamos los hosts, que intentan una inyeccion de código del tipo: GET /index.php?n=http://www.dominio.com/fichero.htm

apache-hacks

Bloquea los hosts que acceden a urls sospechosas, haciendo un SCAN o directamente acceden a urls intentando inyectar llamadas al sistema desde php (system, passthru…) esta regla se va rellenando con las expresiones que vamos encontrando en los logs, al final del post, adjuntamos el contenido del filtro en nuestro caso.

En el ultimo caso, hemos creado un fichero apache-hacks.conf en el directorio filters.d, para empezar podemos agregar entradas como estas:

failregex = ^<HOST> -.*”(GET|POST).*?.*passthru.* HTTP/.*$
^<HOST> -.*”(GET|POST).*?.*system.* HTTP/.*$

Y mas adelante agregar nuevas reglas.

Con estos 4 casos, podemos evitar algunos de los intentos de ataque mas comunes, pero no podemos ni por un momento pensar que con solo aplicar esto estamos a salvo.

En otro post vamos a explicar las medidas de seguridad básicas que todo servidor de alojamiento tiene que aplicar para no ser demasiado vulnerable, mod_security, apache ITK, Hardening de PHP, SuHoshin…

Acerca del autor

Posts relacionados

10 Comentarios

  1. Jose Miguel 10 marzo, 2013 Responder
    • raul 10 marzo, 2013 Responder
  2. Jose Miguel 11 marzo, 2013 Responder
    • raul 11 marzo, 2013 Responder
      • Jose Miguel 11 marzo, 2013 Responder
        • Lazat 10 abril, 2013 Responder
      • Jose Miguel 14 marzo, 2013 Responder
        • CapLinux 17 mayo, 2013 Responder
          • raul 17 mayo, 2013
  3. Eddy 18 marzo, 2014 Responder

Deja una respuesta