24 noviembre 2010

Construyendo tu Host IPS a medida

Sí, bueno, ya sé que igual es un poco ambicioso el título, pero no sé qué nombre puede encajar mejor para el mecanismo de defensa que os voy a proponer a continuación.

Después de muchos años integrando, configurando y afinando este tipo de dispositivos en diferentes organizaciones, me dí cuenta que los IPS comerciales son capaces de detectar/bloquear un amplio porcentaje de ataques dirigidos hacia las redes internas. Sin embargo, debido a que se basan en ataques que son de "sota, caballo y rey", no resultan efectivos para detectar/bloquear aquellos eventos que para mí son una amenaza, aunque para otros puedan no serlo.

Perl es un lenguaje de programación que personalmente me encanta. Con perl eres capaz de hacer lo mismo que en lenguajes de más bajo nivel, siempre y cuando el rendimiento al milisegundo no sea tan importante, permitiéndote lograr tu cometido en pocas líneas de código, con un nivel de abstracción muy grande. Se pensó inicialmente para el tratamiento de cadenas de texto y ficheros por lo que para lo que pensamos hacer, nos viene como anillo al dedo.

Lo primero que debemos saber, es qué queremos proteger, qué servicios tenemos expuestos al exterior, o son importantes y por ello debemos prestarles nuestra máxima atención. El siguiente paso es conocer la ubicación y la estructura de los diferentes ficheros de log en los que estos servicios registran su actividad.

Utilizaremos el módulo File::Tail de Perl para hacer lo mismo que el comando tail en UNIX. Por cada línea escrita en el fichero, nuestro IPS lo monitorizará y podrá reaccionar según definamos.

Vamos allá con un ejemplo práctico. Supongamos que disponemos de un servidor QMail que requiere autenticación para SMTP. Para nosotros una amenaza ante la que reaccionar podría ser un ataque de fuerza bruta que intente averiguar un par de usuario/contraseña válida. 

El formato de una línea de una autenticación errónea es el siguiente:

Nov  8 11:51:52 s_sys@Carmen vpopmail[18129]: vchkpw-smtp: vpopmail user not found guyt@:123.123.123.123

#!/usr/bin/perl

use File::Tail; #el módulo nombrado
my $tail_file_smtp="/var/log/maillog"; #fichero donde se registra la actividad SMTP
my $puerto_destino_smtp=25; #puerto que queremos proteger

$file_maillog=File::Tail->new(name => $tail_file_smtp, maxinterval=>1); 
while (defined($linea=$file_maillog->read))  #si hay linea nueva en el fichero
        {
                if ($linea=~ m/vchkpw-smtp: vpopmail user not found/) #Si coincide con el patrón que queremos bloquear
                {
                        my @trozos=split (/:/,$linea); 
                        my $ip=$trozos[5]; #La IP atacante. En el ejemplo 123.123.123.123
                        chop ($ip) #Eliminamos el retorno de carro
                        blacklistea ($ip,$puerto_destino_smtp,"correla_smtp vpopmail user not found"); #Reaccionamos
                }
        }

En este caso, la reacción es llamar a una función que se llama blacklistea y que recibe como parámetros la IP atacante, el puerto destino, y una descripción. El contenido de la función blacklistea es bastante más complejo, con comprobaciones varias en base a  llamadas a otras cuantas funciones. Fundamentalmente lo que hace es añadir al IPTables de la máquina una regla que bloquea el acceso al puerto 25 desde la IP considerada como atacante y notificar a quien corresponda que se ha bloqueado esa IP a ese puerto por la razón especificada como "Descripción". Asimismo esa misma información queda reflejada junto con la fecha/hora en una base de datos. Hay otro proceso que cada minuto lee de esa base de datos y, si ha pasado un tiempo especificado desde que se añadió esa IP, quita la regla de bloqueo. Si alguien tiene interés en más detalle, que nos lo indique y se lo enviaré o lo publicaré en una segunda parte.

Al igual que se hace con el fichero /var/log/mailog para ese tipo de ataque, se puede proteger los accesos incorrectos a otros servicios como: FTP, POP3, HTTP, HTTPS, etc,… siendo una defensa reactiva fabricada a medida para ajustarse a nuestros servicios según nuestro criterio, ante lo que es un ataque y lo que no lo es.

Para ampliar la detección y reacción a otros servicios, lo mejor será lanzar un thread por cada uno de ellos, además de una adaptación de GeoIPS, y de una rutina de comprobación de diferentes checks de la máquina. Esto quedará de la siguiente manera en el arranque del programa principal:
#MAIN
.... 
<snip>
.... 
$thr_www = threads->new(\&correla_www); #Comprobaciones para el servidor web
$thr_vpop3s = threads->new(\&correla_vpop3s); #Para Pop3s
$thr_qmail_log = threads->new(\&correla_qmail_log); #Antispam
$thr_smtp = threads->new(\&correla_smtp); #SMTP
$thr_ftp = threads->new(\&correla_ftp); #FTP
$thr_geo_firewall = threads->new(\&geofirewall); #Adaptación propia de GeoIPS
$thr_checks=threads->new(\&do_checks); #Checks varios de carga, espacio en particiones,...

#Bucle infinito
for (;;)
{
        chequea_bloqueadas; #Función que valida si una IP en cuarentena debe ser ya desbloqueada o no
        sleep ($frecuencia_chequeo);
}

9 comments :

Román Ramírez dijo...

vpopmail no es qmail, es vpopmail :)

Por otro lado, ¿no es un poco peligroso un "yo me lo hago" en lo que a IPS se refiere?

¿No es mejor optar por un OSSEC o/y un denyhost o/y...? ¿Prelude?

Cuando entras en "yo me lo guiso", al final, efectivamente, "tú te lo comes" ;)

Lorenzo Martínez dijo...

@Román -> Tienes razón es vpopmail aunque la instalación de Qmail utiliza vpopmail para la autenticación antes de poder acceder al SMTP...
Estamos hablando de combinar un IPS (comercial o no) que mitigue un 99% de los ataques con algo hecho a medida para nosotros.

A qué te refieres con peligroso? He estado en departamentos de seguridad en el que disponer de desarrollos a medida para poder detectar ataques de forma anticipada se valoraba y mucho.

Creo que empecé este script hace unos 5 años y le he ido añadiendo cosas según he ido viendo nuevas utilidades.

Evidentemente en una empresa, el mantenimiento de este tipo de herramientas requiere de un rigor documental y un equipo que conozca perfectamente cómo funcionan las aplicaciones a proteger (y sus logs). Además es necesaria una importante coordinación con el departamento de sistemas, y estar avisados ante actualizaciones que puedan modificar algún parámetro en el fichero de log.

Creo que con estas medidas, no tiene por qué ser peligroso, sino que está bien valorado el dar una capa de seguridad extra.

Te soy sincero y, por supuesto, puedo estar equivocado, pero hablo por mi propia experiencia que este tipo de herramientas se valoran bien dentro de este tipo de departamentos en algunas organizaciones.

Saludos,

Anónimo dijo...

Yo creo que es muy interesante como complemento a soluciones más estándares. Además, no está mal hacer algo por uno mismo de vez en cuando:)

Un saludo.
Manolo

Iñaki R. dijo...

Posiblemente ya lo conocerás, pero yo opté por integrar OSSEC con SEC (http://simple-evcorr.sourceforge.net/) para hacer estas cosas. Ossec para generar las alertas que luego SEC correla a su vez. Lo he usado para analizar contra Virustotal los hashes de ficheros modificados o nuevos y funcionó bastante bien :)

SiD dijo...

¿No se parece esto en algo a fail2ban?

Saludos

Anónimo dijo...

@SiD: fail2ban se basa en los mismos conceptos (analiza los ficheros de log en busca de logins fallidos y banea las ip's mediante iptables). Podrías perfectamente hacerte un script en perl que hiciese lo mismo que fail2ban, pero lo importante creo yo, es que puedes aplicar el mismo criterio a otras cosas, y así complementar el uso de un ips normal con "herramientas" propias que nadie se espera que estén... ese es el mayor valor añadido, según mi punto de vista claro esta.

Por cierto, buen articulo, pero mi duda surge con que tipo de empresas valoran esto a la hora de implantarles una solución. No me malinterpretéis, pero ¿lo ven serio?
Creo que siempre puedes implementar firmas o plugins que se integren con la herramienta elegida por la organización para estas tareas, ¿no creéis?

Saludos,
TCH

ramandi dijo...

Muy chulo el artículo... bueno, como todos los que publicáis, así que daros por felicitados todos :-).

@Román -> No me queda claro a qué peligro te refieres.
¿A no conocer todo el abanico de ataques posible y quedarte corto?
¿A añadir fallos de seguridad por una implementación incorrecta?
¿A quién carga con la responsabilidad en caso de intrusión?
¿Una combinación de los anteriores?
¿Ninguna de las anteriores (por favor, especificar cuál)? ;-)

Yo veo posibles pegas en esas direcciones, pero que tampoco se mitigan totalmente usando otros productos. Está claro que 4 ojos ven más que 2, pero aún así...

Saludos!

Lorenzo Martínez dijo...

@Anónimo1 (Manolo) -> Muchas gracias. La idea es esa, complementar sistemas de protección genéricos con mecanismos "ad hoc" para cada caso.

@Iñaki R. -> Conozco ambas herramientas y son muy potentes. De SEC sorprende la flexibilidad para correlar y reaccionar a nuestro gusto.

@Sid -> Se parece pero este al ser hecho a mano te permite que, uses lo que uses, puedas bloquear según tus propios patrones

@Anónimo2 (TCH) -> Coincido contigo en la contestación a Sid. La idea es poder ampliarlo cuanto quieras. Y si mañana quieres añadir un servicio nuevo, simplemente programas el patrón nuevo y creas un thread nuevo. Este tipo de soluciones yo creo que nunca está de más el poder contar con gente que las pueda hacer en un departamento de seguridad. Va más allá de la utilización de los productos "comprados" para resolver problemas y puede dar lugar a soluciones creativas que pueden sacar de un atolladero en un momento dado. Algún día de estos contaré cómo Yago y yo ayudamos a mitigar el virus MyDoom (allá por el 2003) en un ISP para el que trabajábamos...

@Ramandi -> Me alegro que te haya gustado este post... y los demás. La idea es precisamente esa, que los lectores disfruten leyéndolos, casi casi tanto como nosotros escribiéndolos :D

Gracias a todos por vuestros comentarios y opiniones!

SiD dijo...

Pues yo sigo, para analizar entradas en ficheros de log, viendo ésto parecidísimo al fail2ban y su /etc/fail2ban/filter.d/

Pero bueno, siempre está bien tener más de una opción para algo.

Saludos.