miércoles, 26 de marzo de 2014

I hunt sys admins... yo no, la NSA!

Acá les traigo un nota de zdnet que habla de como la NSA utiliza los administradores de sistemas como puerta de acceso a las redes de su interés. En esencia todo se trata de como lo llaman ellos SIGINT, recabar información a partir de la interceptación  de comunicaciones, información que luego procesan y asocian a otras para en definitiva utilizarla como entrada a sistemas como DISCOROUTE y QUANTUM.

Estos sistemas desarrollados por ellos mismos se encargan en mayor o menor medida de, a partir de la información (redes, IPs, nombres, cuentas de correo, configuraciones de routers, etc), proporcionar acceso a las terminales de los Sys admins que administran las redes objetivo. Una vez conseguido el acceso los chicos de CNE (Compute Network Exploitation) toman la posta y... el resto es cuento conocido. Parece ficción, ¿cierto?

Para quienes quieran profundizar y ver que NO se trata de ficción, The Intercept publicó el texto de donde se escribió la nota. Una lectura recomendada sin dudas!

Me gustaría rescatar unos puntos particulares que vi en el texto:

  • La NSA no solo recolecta la información que sabe que le servirá para determinada actividad en el corto plazo, sino que recolecta mucha mas información aún, información que luego podría ser eventualmente útil. Este proceso por el cual recolectan volúmenes increíbles de información lo llaman SIGINT.
  • Los Sysadmin no somos el objetivo de la NSA, al menos no en la mayoría de los casos, sino simplemente son quienes tienen acceso a las redes de comunicación en las cuales están interesados. NSA -Nada personal sysadmins...
  • Cuentan con herramientas muy interesantes como QUANTUM a partir de la cual con una determinada entrada de información pueden ganar acceso sencillamente (en la mayoria de los casos) los puestos de trabajo de los Sysadmins. 
  • Otra herramienta que parece aún tener éxito es DISCOROUTE, con la cual obtienen información de los routers de una red a través del uso del conocido " y aun no extinto y no se porque" Telnet. Si... al parecer aún quedan Telnets dando vuelta por la basta Internet.
  • Mencionan también cómo identifican los Sysadmins a través de conexiones SSH, aclaran que si bien no pueden interpretar (será que no?) el contenido de una comunicación de este tipo, si pueden reconocer sesiones SSH exitosas y NO exitosas. Esto parece complicado, pero de hecho no lo es, una sesión SSH fallida tiene un intercambio de paquetes muy limitado y corto, por lo tanto consideran una sesión exitosa (de sysadmin) a toda aquella sesión SSH que tenga una longitud mayor a la de una sesión fallida.

De estos puntos me parece que una buena parte se pueden tratar fácilmente.

  • No conozco un buen motivo para que los routers tengan IPs públicas. Si fuese posible que se administraran por IPs privadas no sería tan sencillo accederlos desde el exterior.
  • Las estaciones de trabajo de los administradores. Lo mismo que los routers, si tuviesen IPs privadas no podrían ser accedidas desde Internet directamente.
  • Telnet, Why in the world would you use it??? Calculo que el principal motivo por el que aún se usan es porque los equipos mas viejos no soportan protocolos seguros como SSH. De vuelta, se podría subsanar utilizando por ejemplo VPNs.
Alguna otra reflexión???

viernes, 21 de marzo de 2014

Protegiendo nuestro servidor con fail2ban - Parte 2 "Frenando bots y scanners web simples"

Buenas noches! Debido al éxito rotundo (10 visitas :D) del post anterior de fail2ban hoy les traigo uno nuevo. Esta vez la idea es bloquear esos scanner de vulnerabilidades web que se suelen utilizar de manera automatizada para buscar sitios débiles.

En particular hoy vamos a detectar y bloquear un intento de escaneo con Nikto. Nikto es una herramienta muy común en el ámbito del web pentesting, cuenta con una gran batería de pruebas y es muy flexible. Usaré la versión de nikto 2.1.5 y el objetivo de prueba será un sitio con la versión 3.0.1 de wordpress, una versión ya en desuso y con conocidos fallos de seguridad.

Lanzaremos nikto contra un objetivo y buscaremos cómo identificarlo dentro de los logs de apache, para poder luego indicarle a fail2ban cómo reconocerlo y qué hacer al respecto.


¿Cómo obtener nikto?


Hay al menos dos formas de instalar nikto, siendo la mas sencilla (pero mas desactualizada) desde los repositorios de la distribución en cuestión y la mas "complicada" (pero mas actualizada) descargandolo manualmente. En este caso tomaremos el camino dificil, pero mas satisfactorio :D.


Lo descargamos y descomprimimos


juan@moon: ~/borrar$ wget --no-check-certificate https://www.cirt.net/nikto/nikto-2.1.5.tar.gz
juan@moon: ~/borrar$ tar -xvf nikto-2.1.5.tar.gz
...
juan@moon: ~/borrar$ cd nikto-2.1.5/


Lo hacemos ejecutable y lo actualizamos


juan@moon:~/borrar/nikto-2.1.5$ chmod +x nikto.pl 
juan@moon:~/borrar/nikto-2.1.5$ ./nikto.pl -update
+ Retrieving 'nikto_report_csv.plugin'
+ Retrieving 'nikto_headers.plugin'
+ Retrieving 'nikto_cookies.plugin'
+ Retrieving 'db_tests'
+ Retrieving 'db_parked_strings'
+ Retrieving 'CHANGES.txt'
+ CIRT.net message: Please submit Nikto bugs to http://trac2.assembla.com/Nikto_2/report/2
juan@moon:~/borrar/nikto-2.1.5$ 

Ready to run!!! Nikto está escrito en PERL y podría darse el caso de que no tengan todos los módulos de perl necesarios instalados y tengan que instalarlos (esa es la parte dificil jajaj).


Lanzando nikto al servidor objetivo


Vamos a lanzar nikto con su configuración por defecto y sin mas parámetros que el objetivo.

juan@moon:~/borrar/nikto-2.1.5$ ./nikto.pl -h 172.16.62.149
- Nikto v2.1.5
---------------------------------------------------------------------------
+ Target IP:          172.16.62.149
+ Target Hostname:    172.16.62.149
+ Target Port:        80
+ Start Time:         2014-03-20 00:04:55 (GMT-3)
---------------------------------------------------------------------------
+ Server: Apache/2.2.22 (Ubuntu)
+ Retrieved x-powered-by header: PHP/5.3.10-1ubuntu3.10
+ The anti-clickjacking X-Frame-Options header is not present.
+ Uncommon header 'x-pingback' found, with contents: http://172.16.62.149/xmlrpc.php
+ DEBUG HTTP verb may show server debugging information. See http://msdn.microsoft.com/en-us/library/e8z01xdh%28VS.80%29.aspx for details.
+ OSVDB-12184: /index.php?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings.
+ Server leaks inodes via ETags, header found with file /readme, inode: 0x66046, size: 0x23a2, mtime: 0x48bfa299bbdc0;4f50077b4b85f
+ Uncommon header 'tcn' found, with contents: choice
+ OSVDB-3092: /xmlrpc.php: xmlrpc.php was found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ /wp-content/plugins/akismet/readme.txt: The WordPress Akismet plugin 'Tested up to' version usually matches the WordPress version
+ /readme.html: This WordPress file reveals the installed version.
+ OSVDB-3092: /license.txt: License file found may identify site software.
+ Cookie wordpress_test_cookie created without the httponly flag
+ /wp-login/: Admin login page/section found.
+ 6545 items checked: 0 error(s) and 14 item(s) reported on remote host
+ End Time:           2014-03-20 00:06:11 (GMT-3) (76 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
juan@moon:~/borrar/nikto-2.1.5$ 

Interesante... Qué podemos rescatar del análisis?

-Identificó el Sistema Operativo, Ubuntu.
-Identificó la versión de Apache, 2.2.22.
-Identificó la versión de PHP, 5.3.10-1ubuntu3.10.
-Identificó la versión de Wordpress, 3.0.1 (en /readme.html)
-También identificó potenciales exposiciones de información como

Nikto consiguió bastante información sobre el objetivo, aunque no encontró ninguna vulnerabilidad muy explícita podría haberlo hecho. Entonces acabamos de demostrar que nuestro servidor no es capaz de darse cuenta de que fue escaneado por un software en busca de vulnerabilidades.


¿Cómo identificamos el ataque?


Si le damos una breve mirada a los logs de apache podemos encontrar lo siguiente:

juan@ubuntu:/etc/fail2ban/filter.d$ cat /var/log/apache2/access.log |grep -i nikto
...
172.16.62.1 - - [19/Mar/2014:20:44:39 -0700] "GET /mobileadmin/bin/ HTTP/1.1" 404 532 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:5) (Test:006606)"
172.16.62.1 - - [19/Mar/2014:20:44:39 -0700] "GET /mobileadmin/home.cs HTTP/1.1" 404 535 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:5) (Test:006607)"
172.16.62.1 - - [19/Mar/2014:20:44:40 -0700] "GET /3rdparty/phpMyAdmin/server_sync.php?c=phpinfo() HTTP/1.1" 404 551 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:5) (Test:006608)"
172.16.62.1 - - [19/Mar/2014:20:44:40 -0700] "GET /phpMyAdmin/server_sync.php?c=phpinfo() HTTP/1.1" 404 542 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:5) (Test:006608)"
172.16.62.1 - - [19/Mar/2014:20:44:40 -0700] "GET /3rdparty/phpmyadmin/server_sync.php?c=phpinfo() HTTP/1.1" 404 551 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:5) (Test:006608)"
172.16.62.1 - - [19/Mar/2014:20:44:40 -0700] "GET /phpmyadmin/server_sync.php?c=phpinfo() HTTP/1.1" 404 542 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:5) (Test:006608)"
172.16.62.1 - - [19/Mar/2014:20:44:40 -0700] "GET /pma/server_sync.php?c=phpinfo() HTTP/1.1" 404 535 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:5) (Test:006608)"
juan@ubuntu:/etc/fail2ban/filter.d$

Cientos de entradas correspondientes a los accesos de Nikto, todas vienen con el user-agent Mozilla/5.00 (Nikto/2.1.5), y por lo tanto podría ser la cadena ideal para detectarlo. 


Indicándole a fail2ban como detectar Nikto:


Chusmeando un poco los filtros disponibles de fail2ban podemos ver que hay uno llamado apache-badbots.conf. Este filtro provee una lista de bots (robots scanners web) que han sido identificados como de no confiar o directamente peligrosoz, por lo tanto vamos a hacer uso de esta lista y expandirla para incluir Nikto en ella.

Editamos el archivo en cuestión (/etc/fail2ban/filter.d/apache-badbots.conf) y agregamos una nueva expresión regular a failregex. Quedando así:


failregex = ^ -.*"(GET|POST).*HTTP.*"(?:%(badbots)s|%(badbotscustom)s)"$
            ^ -.*"(GET|POST).*HTTP.*".*Nikto.*$

Ahora debemos crear el jail correspondiente en /etc/fail2ban/jail.conf . Agregamos lo siguiente al final del archivo:

[apache-badbots]

enabled  = true
port     = http,https
filter   = apache-badbots
logpath  = /var/log/apache*/*access*.log
maxretry = 1

Ahora es necesario agregar la jaula al proceso fail2ban, podemos lograrlo reiniciando el servicio:

root@ubuntu:/home/juan# service fail2ban restart
 * Restarting authentication failure monitor fail2ban                    [ OK ] 
root@ubuntu:/home/juan# 

Luego corroboramos que se haya cargado exitosamente:

root@ubuntu:/home/juan# fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: apache-badbots, ssh
root@ubuntu:/home/juan# fail2ban-client status apache-badbots
Status for the jail: apache-badbots
|- filter
|  |- File list: /var/log/apache2/access.log /var/log/apache2/other_vhosts_access.log 
|  |- Currently failed: 0
|  `- Total failed: 0
`- action
   |- Currently banned: 0
   |  `- IP list:
   `- Total banned: 0
root@ubuntu:/home/juan# 


La prueba:


Ahora volvemos a lanzar Nikto contra nuestro servidor para ver si funciona:

juan@moon:~/borrar/nikto-2.1.5$ ./nikto.pl -h 172.16.62.149
- Nikto v2.1.5
---------------------------------------------------------------------------
+ No web server found on 172.16.62.149:80
---------------------------------------------------------------------------
+ 0 host(s) tested
juan@moon:~/borrar/nikto-2.1.5$ 

Claramente esta vez nikto no hay podido hacer nada. Y a continuación podemos ver porque:

root@ubuntu:/home/juan# fail2ban-client status apache-badbots
Status for the jail: apache-badbots
|- filter
|  |- File list: /var/log/apache2/access.log /var/log/apache2/other_vhosts_access.log
|  |- Currently failed: 1
|  `- Total failed: 1784
`- action
   |- Currently banned: 1
   |  `- IP list: 172.16.62.1
   `- Total banned: 1
root@ubuntu:/home/juan#

La jaula nos indica que la IP 172.16.62.1 fue detectada y bloqueada, podemos verlo también directamente desde iptables:

root@ubuntu:/home/juan# iptables-save
# Generated by iptables-save v1.4.12 on Fri Mar 21 06:29:33 2014
*filter
:INPUT ACCEPT [100:6649]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [77:8884]
:fail2ban-apache-badbots - [0:0]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-badbots
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A fail2ban-apache-badbots -s 172.16.62.1/32 -j DROP
-A fail2ban-apache-badbots -j RETURN
-A fail2ban-ssh -j RETURN
COMMIT
# Completed on Fri Mar 21 06:29:33 2014
root@ubuntu:/home/juan#

Nikto fue completamente detenido por fail2ban!!! Como ven, el potencial de fail2ban es gigante.

jueves, 13 de marzo de 2014

KeePassX, protegiendo mis claves, digale NO!!! a las claves en papel o en un txt

Cuántas claves recordás? Hoy por hoy todos tenemos almenos:

-Una cuenta de correo electrónico
-Una cuenta en Facebook
-Una cuenta en twitter
-Una cuenta de home banking
-Una tarjeta de débito/crédito
-Una cuenta en algún foro, diario, revista, etc
-etc...

Pero quién tiene una clave diferente para cada servicio? Me consta que muchas personas caen en el error de re-utilizar sus claves porque les resulta complicado/tedioso/aburrido/feo tener que recordar tantas, pero esto potencia mas aún el riesgo de por ejemplo sufrir un robo de identidad, fraude electrónico y una larga lista de problemas. Por ejemplo, es un clasico que una persona use en facebook la misma contraseña que utiliza en su correo electrónico. Otro clásico es no utilizar la misma clave, sino una con una leve diferencia por ejemplo: la clave del mail es pepeloco y la clave de facebook es pepeloco1. Esto si bien resuelve dos cosas, recordar la clave y que no sea la misma, es una solución demasiado ingénua y no vale la pena.

Si bien tener distintas claves para cada servicio no resuelve todo el problema (si las claves son sencillas, estamos en el horno igual), puede disminuir de manera considerable el impacto del descubrimiento de una de ellas, es decir: una clave revelada un servicio afectado y ya no una clave revelada muchos servicios afectados. Poniendolo en criollo, si obtienen tu clave del mail solo van a poder mandar mails y ya no hacerse pasar por vos en Facebook y Twitter.

También es cierto que existen soluciones como single sign-on que atacan en cierta forma esta problemática, pero en este caso tomaremos una dirección distinta.

Hay varios programas que permiten almacenar de manera segura nuestras claves y en este post en particular hablaremos de KeePassX. Keepassx nos va a permitir almacenar y ordenar nuestras claves de manera sencilla y prolija.

keepassx


Pero donde está la parte mágica de Keepassx? no hay magia, keepassx protegerá nuestras claves con... una clave. En esencia, ahora debemos elegir una única clave muy fuerte para que proteja a las demás claves que podrían ser incluso generadas aleatoriamente, ya que no precisamos recordarlas!!! Esta clave que debemos elegir debe ser realmente segura y no deberíamos anda gritándola ni escribiéndola en ningún lado, ya que será utilizada por keepassx para ocultar las demas. En criollo Keepassx es una caja fuerte donde guardamos las llaves de cada una de nuestras propiedades, si le entregamos a un ladron la caja fuerte junto con la combinación nos podemos despedir de las propiedades, pero si el ladrón obtiene solo la caja fuerte no puede hacer demasiado (en este caso, con una clave segura el ladrón está perdido).

La instalación va a depender de si se trata de Windows o Linux (mas sencilla ya que está en los repos de cualquier distro apt-get install keepassx o yum install keepassx). Para el caso de windows pueden bajar el instalador de AQUI, funciona en Windows 2000, XP, Vista, 7.

Una vez instalado lo ejecutan y buscan la opción "Nueva Base de Datos", les pedirá que ingresen una contraseña y que la repitan. Aquí radica gran parte de la fortaleza del esquema, esta clave debe ser larga, contener numeros, símbolos, todo lo que puedan recordar. A partir de aquí es sencillo agregar y quitar registros, armar grupos, etc (imagenes oficiales de keepassx). Keepassx encripta la base de datos con las claves utilizando AES256 lo que significa que será computacionalmente imposible adivinar una clave fuerte (al menos al día de la fecha, claro).

Por cada entrada registrada en KeePassX podemos registrar la siguiente información:

entrada keepassx

Grupo al que pertenece, es una forma sencilla de ubicar las entradas.
Título con el que se podrá encontrarla en keepassx
Usuario, esto podria ser una dirección de correo electrónico en el caso de Facebook
URL, la dirección del sitio donde este usuario y clave son válidos
Clave/Password, la clave en si misma. Como verán está el botón Gen que permitirá generar una clave aleatoria.
Comentario, un cuadro de texto donde podremos escribir información adicional si es necesario
Adjunto/Attachment, es aqui donde se puede adjuntar un archivo a la entrada. 

Otra particularidad de keepassx es que nos permite incluir archivos en esta pequeña base de datos, interesante para por ejemplo casos donde tengamos alguna información importante en una imagen jpg o un keyfile de algún otro sistema encriptado.

Una vez cargada una entrada a keepassx, basta con ubicarla y presionar botón derecho para copiar el usuario y luego de la misma manera se puede copiar la clave.

claves keepassx

De esta forma conseguimos, sacrificando un poco la comodidad, una manera sencilla de administrar nuestros passwords de forma segura.

Algunas recomendaciones para el uso de KeePaasX


  • Mantenerlo actualizado, es decir, si uno actualiza su password de facebook debe actualizarlo de igual manera en KeePassX, porque sino el password sería obsoleto. 
  • Tener al menos dos copias del archivo de claves de KeePassx repartidas en lugares diferentes (una en la computadora y la otra en un pendrive por ejemplo). Dada la importancia del archivo, si le pasara algo a la computadora y no pudiesemos recuperarlo estaríamos frente a un gran problema.
  • El password que protege el archivo debe ser considerablemente fuerte, en lo posible con mas de 10 caracteres, mezclando letras y números; y si es posible símbolos también. Pero ante todo el password debe ser fácil de recordar, dado que si se lo olvidan de nuevo estamos en problemas.

jueves, 6 de marzo de 2014

Protegiendo nuestro servidor con fail2ban - Parte 1 "Protegiendo SSH"

Hoy les traigo una aplicación muy interesante que nos ayudará a proteger nuestro servidor. Es un hecho que si nuestro servidor está en internet, se encuentra expuesto todo el tiempo a un sin número de robots que buscan huecos por donde colarse (desde scanners de sitios web, hasta ataques de diccionario a cuentas de usuarios). Esta aplicación se llama Fail2ban.

El funcionamiento de Fail2ban es muy sencillo y se puede resumir en los siguientes pasos:

1-Lectura de logs y comparación con expresiones regulares
2-Aplicación de una acción por un tiempo determinado
3-Remoción de la acción una vez pasado el tiempo

Entonces se puede decir que Fail2ban nos presenta una forma sencilla de detectar patrones en los logs y tomar acciones en consecuencia, acciones que luego pueden ser revertidas. Estas acciones pueden ser desde aplicar reglas en el firewall, enviar un correo electrónico, reiniciar un servicio, lo que sea que precisen.

En esta "Parte 1" vamos a ver cómo instalarlo y configurarlo para proteger nuestro servidor de ataques de diccionario al servicio SSH.

La instalación es sencilla ya que se encuentra en los repositorios de prácticamente cualquier distro, en este caso usamos Ubuntu 12.04.4 LTS

root@ubuntu:~# apt-get install -y fail2ban

Una vez instalado podemos ver los archivos de configuración ubicados en /etc/fail2ban

root@ubuntu:~# ls /etc/fail2ban/
action.d  fail2ban.conf  filter.d  jail.conf
root@ubuntu:~# 

fail2ban.conf: contiene los parámetros generales de configuración del servicio, como las opciones de logging.
jail.conf: aquí es donde definiremos las jaulas (jails) que fail2ban procesará. El archivo se encuetra divido en la etiqueta [DEFAULT] que contiene variables generales que aplican a todas las jails y luego una etiqueta del tipo [JAIL_NAME] por cada jail creada. Una jail está compuesta mínimamente por las variables enabled, port, filter y logpath, además se puede sobreescribir las variables del tag [DEFAULT] para personalizar aún mas la jaula. 
action.d: en este directorio se encuentran los archivos que definen las acciones disponibles a tomar dentro de las jails.
filter.d: en este directorio se encuentran los filtros disponibles para utilizar en las jails.

El jail que utilizaremos es el llamado ssh, cuya configuración es:

[ssh]

enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 6

enabled: nos permite activar y desactivar el jail de manera sencilla, solo admite el valore true o false.
port: indica el puerto del servicio que se está queriendo proteger, en este caso ssh es luego reemplazado por 22.
filter: define el archivo (dentro de /etc/fail2ban/filter.d) que contendrá las expresiones regulares que se utilizaran para esta jaula. Las expresiones regulares nos permitiran definir qué tipo de logs serán una detección positiva de un problemas (failregex) y cuales no (ignoreregex).
logpath: esta variable indica el archivo de donde se leerán los logs a analizar. Ubuntu envía los logs de autenticación al archivo /var/log/auth.log, por lo tanto es el archivo indicado.
maxretry: indica la cantidad de veces que se aceptarán coincidencias en las expresiones regulares de la jaula, cuando este límite se alcanza, dentro del margen de tiempo (variable XXX) se ejecutará la acción definida para la jaula (en este caso XXX).

Como se podrán imaginar nos faltan algunas cosas, si recuerdan uno de los pasos del funcionamiento de fail2ban consistía en ejecutar una acción y en este jail no vemos nada de esto. Esto se debe a que estamos utilizando la acción poder defecto provista por el tag [DEFAULT], esta acción se encargará de insertar en el firewall una regla que denegará el acceso a puerto SSH a la IP que haga un número excesivo de intentos de acceso fallidos. Cuál es el número excesivo? 6, como indica la variable maxretry de la jail ssh. Otro valor interesante y que no se encuentra especificado entre los valores default, es el intervalo de tiempo que se analizará. Este intervalo está definido por la variable findtime (valor por defecto 600 segundos), de esta forma podemos indicarle al jail que busque intentos fallidos de logs en los últimos 600 segundos (10 minutos) y que si encuentra mas de 6 de una misma IP aplique la acción default.

Antes de comenzar a probar el funcionamiento reiniciemos el servicio para corroborar que esté todo funcionando correctamente:

root@ubuntu:/home/juan# service fail2ban restart
 * Restarting authentication failure monitor fail2ban                    [ OK ] 
root@ubuntu:/home/juan# 

Excelente! Ahora podemos ver que fail2ban agregó una nueva cadena a iptables:

root@ubuntu:/home/juan# iptables-save 
# Generated by iptables-save v1.4.12 on Thu Mar  6 05:10:23 2014
*filter
:INPUT ACCEPT [41:3079]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [23:2444]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A fail2ban-ssh -j RETURN
COMMIT
# Completed on Thu Mar  6 05:10:23 2014
root@ubuntu:/home/juan#

fail2ban-ssh es la cadena correspondiente al jail ssh y es donde se insertarán las IPs que sean detectadas como peligrosas por el jail.

No mas teoría xD, probemos si realmente funciona (recuerden que no hemos cambiado absolútamente nada en el archivo jail.conf). Nuestro escenario de prueba consiste en las IPs:

172.16.62.149 - servidor a proteger ubuntu
172.16.62.1 - atacante moon

Supongamos que el atacante ya hizo un escaneo previo de la red y encontró varias direcciones IP con el servicio SSH escuchando en el puerto 22. Una de esas direcciones es nuestro servidor, asumiendo que los usuarios suelen usar contraseñas débiles, el paso siguiente sería comenzar a probar pares usuario/contraseña hasta que eventualmente adivine alguno y consiga acceso.

Simulamos un robot haciendo 6 intentos fallidos de autenticación de la siguiente manera:

juan@moon:~$ ssh pepe@172.16.62.149
pepe@172.16.62.149's password: 
Permission denied, please try again.
pepe@172.16.62.149's password: 
Permission denied, please try again.
pepe@172.16.62.149's password: 
Permission denied (publickey,password).
juan@moon:~$ ssh pepe@172.16.62.149
pepe@172.16.62.149's password: 
Permission denied, please try again.
pepe@172.16.62.149's password: 
Permission denied, please try again.
pepe@172.16.62.149's password: 
Connection closed by 172.16.62.149
juan@moon:~$ 

como pueden ver, luego del sexto intento fallido hemos perdido acceso al puerto 22.
Desde el servidor podemos ver claramente la nueva regla que fue agregada a iptables:

root@ubuntu:/home/juan# iptables-save 
# Generated by iptables-save v1.4.12 on Thu Mar  6 05:10:23 2014
*filter
:INPUT ACCEPT [41:3079]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [23:2444]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A fail2ban-ssh -s 172.16.62.1/32 -j DROP
-A fail2ban-ssh -j RETURN
COMMIT
# Completed on Thu Mar  6 05:10:23 2014
root@ubuntu:/home/juan#

la regla descarta expecíficamente los paquetes de origen 172.16.62.1 que se dirijen al puerto 22. La forma correcta de ver en qué estado se encuentra una jail en particular es la siguiente:

root@ubuntu:/home/juan# fail2ban-client status ssh
Status for the jail: ssh
|- filter
|  |- File list: /var/log/auth.log 
|  |- Currently failed: 1
|  `- Total failed: 7
`- action
   |- Currently banned: 1
   |  `- IP list: 172.16.62.1
   `- Total banned: 1
root@ubuntu:/home/juan# 

Bien, funciona!! pero qué sucedió?

Escencialmente lo que sucedió fue lo siguiente:

-La jail ssh estaba pendiente de los logs que se escribían en /var/log/auth.log
-En un momento determinado detecto que en los últimos 5 minutos alguien había realizado al menos 6 intentos fallidos de login al servidor. Esto lo podemos ver fácilmente acá:

root@ubuntu:/home/juan# cat /var/log/auth.log |grep "Failed password"
Mar  6 04:39:26 ubuntu sshd[976]: Failed password for juan from 172.16.62.1 port 37492 ssh2
Mar  6 05:13:28 ubuntu sshd[1514]: Failed password for invalid user pepe from 172.16.62.1 port 37539 ssh2
Mar  6 05:13:31 ubuntu sshd[1514]: Failed password for invalid user pepe from 172.16.62.1 port 37539 ssh2
Mar  6 05:13:35 ubuntu sshd[1514]: Failed password for invalid user pepe from 172.16.62.1 port 37539 ssh2
Mar  6 05:13:40 ubuntu sshd[1516]: Failed password for invalid user pepe from 172.16.62.1 port 37542 ssh2
Mar  6 05:13:43 ubuntu sshd[1516]: Failed password for invalid user pepe from 172.16.62.1 port 37542 ssh2
root@ubuntu:/home/juan# 

-Aplicó la acción correspondiente a la jail, esto lo podemos ver en el archivo de logs de fail2ban (/var/log/fail2ban.log)

...
2014-03-06 05:13:42,764 fail2ban.actions: WARNING [ssh] Ban 172.16.62.1
...

-Diez minutos después fail2ban quita la regla del firewall y todo vuelve a la normalidad

...
2014-03-06 05:23:43,610 fail2ban.actions: WARNING [ssh] Unban 172.16.62.1
...

Como verán, su funcionamiento es sencillo. Si abren el archivo /etc/fail2ban/filter.d/sshd.conf podrán ver las distintas expresiones regulares que serán consideradas como ataques,  una de ellas es:


 ^%(__prefix_line)sFailed (?:password|publickey) for .* from (?: port \d*)?(?: ssh\d*)?$

Algunas consideraciones sobre esta implementación:


-Frena a los atacantes por solo 10 minutos (se podría incrementar este valor sin complicaciones), lo cual a veces es mas que suficiente para engañar a los robots y hacerles creer que el host se apagó y que no deberían perder tiempo intentando.
-No protege a usuarios con claves triviales como usuario juan y password juan, y demás cosas que pueden ser adivinadas en unos pocos intentos.

Recomendaciones:

-Si administras servidores utilizando SSH, usa un par de claves pub/priv en lugar de contraseña.
-No permitir el acceso de root por SSH.

Veremos que se me ocurre para la parte 2!!! Saludos!