En el anterior post hemos visto lo más básico de psad. De hecho, he resumido alguna cosa tanto que los que ya conozcan el software pueden decir que no he sido todo lo riguroso que debiera. Un ejemplo, la parte relacionada con las variables IPT_AUTO_CHAIN#. Mi objetivo, más que ser completamente riguroso, era dar una visión global del software.
En fin, dicho esto, vamos a ver alguna otra cosilla que se puede hacer con psad.
Recordemos el problema. Queremos poder añadir a nuestro firewall perimetral reglas que con el tiempo vayan expirando sin tener que estar encima. Queremos, además, que estas reglas se añadan en base a decisiones que tomen los servidores web o smtp en base a sus propios mecanismos, quitando al firewall perimetral la responsabilidad del análisis del tráfico del nivel de aplicación.
Hay varias formas de hacerlo. Lo más fácil es usar el propio comando psad. Por ejemplo:
# psad -fw-block-ip 10.0.5.98
[+] Writing 10.0.5.98 to socket; psad will add the IP
within 5 seconds.
Es tan sencillo como esto. Veamos el resultado:
# psad --fw-list
[+] Listing chains from IPT_AUTO_CHAIN keywords…
Chain PSAD_BLOCK (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all — * * 10.0.5.98 0.0.0.0/0
Para quitar esta IP es suficiente con esperar los 600 segundos configurados, o bien ejecutar:
# psad --fw-rm-block-ip 10.0.5.98
[+] Writing 10.0.5.98 to socket; psad will remove the IP
within 5 seconds.
# psad –fw-list
[+] Listing chains from IPT_AUTO_CHAIN keywords…
Chain PSAD_BLOCK (1 references)
pkts bytes target prot opt in out source destination
A partir de aquí, seguro que a cada uno se le ocurren cinco formas de hacer que un servidor genere los comandos para que el firewall añada las reglas.
La forma en la que cada administrador gestiona lo que puede hacer con psad es particular de cada infraestructura, pero sin duda, una combinación de psad, fwsnort y otras técnicas como el port knocking añaden funcionalidades muy interesantes que en muchos casos ni siquera el software/hardware de pago ofrecen.
En este post voy a documentar un uso alternativo que se puede dar a psad, un interesante software pensado para la detección de escaneos de puertos, que fue creado como parte de bastille linux en el 1999.
El problema:
Tenemos un firewall que gestiona una red digamos que de servidores web y smtp, para los que evidentemente tenemos acceso libre por los puertos 25 y 80, pero que reciben multitud de ataques de todo tipo. Las propias aplicaciones tienen sus mecanismos de seguridad, pero al final siempre añadimos muchas de las IPs que generan los ataques en el firewall perimetral. Claro, al final tenemos cientos de IPs en los firewalls que somos incapaces de mantener, y que no hacen más que complicar su gestión. Para colmo, la mayoría de esas IP sólo lo intentan durante unos pocos minutos.
Una solución:
Queremos un sistema con el que podamos añadir IPs al firewall, y que expiren, si así lo decidimos, en un cierto plazo de tiempo. Vamos a utilizar psad para esto, que además, al mismo precio, nos sirve para detectar escaneos de puertos. En este primer post sobre todo escribiré sobre lo básico de psad, que en el próximo iremos adaptando al problema.
Vamos a ir instalando. Una opción es descargar el sofware y usar su propio instalador desde cipherdyne.org/psad/, pero en este caso voy a usar el software ya precompilado para Debian. Por cierto, más que recomendable dar una vuelta por cipherdyne.org y ver el software que hay disponible.
aptitude install -R psad
No quiero que installe bastille, de ahí que use -R. Psad es una aplicación que en su mayoría está programada en perl, así que dependiendo de lo que cada uno tenga en su sistema instalará más o menos librerías.
Una instalación por defecto de psad lee los datos que a través de syslog se pasan a la tubería /var/lib/psad/psadfifo (un pipe de los de toda la vida), con lo que lo primero es hacer que kern.info se mande a dicho pipe, con algo tan sencillo como añadir a syslog.conf:
kern.info |/var/lib/psad/psadfifo
Después de reiniciar syslog, ya está todo practicamente listo…..
Configuración:
Dependiendo de la forma de instalación y de la distribución que usemos, seguramente las rutas, nombres de pipes y alguna otra opción podrían ser diferentes, con lo que lo descrito aquí es más conceptual que algo con lo que se pueda hacer copy/paste.
Como psad es un software que sobre todo lee logs, es fundamental que nuestro firewall loguee lo que queremos tratar, que puede ser sólo lo del propio cortafuegos, o también lo que otras máquinas puedan enviarle. En definitiva, que aquí está la clave del invento.
Como referencia, hay que tener en cuenta que psad mira que en las líneas de logs que recibe existan las cadenas IN= y OUT=, con lo que asume que son de iptables. Esto nos será útil posteriormente.
Toda la configuración se hace en /etc/psad/psad.conf. En el directorio /etc/psad hay muchos otros ficheros, algunos los trataré en este post, pero otro no. Hay que tener en cuenta que psad es un software que hace más cosas que lo que voy a describir aquí.
La configuración es muy sencilla de leer y muy documentada, “se explica sola”, así que sólo voy a comentar lo más útil para hacerse una idea.
Las dos siguientes variables definen las redes locales y las que no lo son, muy al estilo snort.
HOME_NET 192.168.10.0/24, 172.16.0.0/16; # un ejemplo
EXTERNAL_NET any;
Estas redes se definen porque psad usa las reglas de snort para detectar tráfico sospechoso, aunque las usa en cierta medida de forma diferente. Por ejemplo, para psad todo el tráfico que loguea está destinado a lo que para snort sería HOME_NET.
Las siguientes variables definen los niveles de peligro. Desde el punto de vista de escaneo de puertos, estos niveles definen el número de paquetes recibidos. Desde el punto de vista de otro tipo de actividad maliciosa, estos niveles se definen según el tipo de ataque o si la IP origen es conocida por anteriores bloqueos.
DANGER_LEVEL1 5; ### Number of packets.
DANGER_LEVEL2 15;
DANGER_LEVEL3 150;
DANGER_LEVEL4 1500;
DANGER_LEVEL5 10000;
Con la siguiente línea hacemos que Psad no sea sólo algo pasivo, sino que añada reglas a nuestro firewall.
ENABLE_AUTO_IDS Y;
Digamos que queremos bloquear IPs a partir del nivel 3:
AUTO_IDS_DANGER_LEVEL 3;
Y que queremos que los bloqueos duren 600 segundos
AUTO_BLOCK_TIMEOUT 600;
Por supuesto, usamos iptables:
IPTABLES_BLOCK_METHOD Y;
La siguiente variable define la/s cadenas en las que queremos que se añadan reglas de bloqueo. Su sintaxis es: Target,Direction,Table,From_chain,Jump_rule_position,To_chain,Rule_position.
Por ejemplo:
IPT_AUTO_CHAIN1 DROP, src, nat, PREROUTING, 1, PSAD_BLOCK, 1;
Lo más interesante aqui es que DROPeamos con reglas añadidas a la tabla nat y la cadena PSAD_BLOCK. Se pueden añadir IPT_AUTO_CHAINn reglas. No hace falta decir que debemos haber creado anteriormente la cadena PSAD_BLOCK
Psad puede incluso ejecutar scripts externos. La IP origen se pasa a estos scripts en la variable SRCIP.
ENABLE_EXT_SCRIPT_EXEC N;
Hay muchas opciones a configurar. Como he dicho antes aquí no hay más que unas cuantas para dar una idea de lo que se puede hacer.
Otro fichero interesante es el /etc/psad/auto_dl, en el que podemos configurar listas blancas y negras de IPs. Por ejemplo:
127.0.0.1 0;
10.111.21.23 5 tcp/22;
Con estas dos reglas permitimos todo lo que venga desde 127.0.0.1 y damos un danger_level de 5 a todo lo que venga de 10.111.21.23 y sea tráfico ssh.
Otro fichero interesante es /etc/psad/signatures, que incluye unas 200 firmas de snort, pero ligeramente modificadas para poder pasar información a psad. Por ejemplo:
alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP PING undefined code"; icode:>0; itype:8; classtype:misc-activity; sid:365; psad_id:100195; psad_dl:2;)
Es una definición de regla relacionada con icmp, y que tiene un identificador en psad de 100195 y que asigna un danger_level de 2.
Ahora sólo quedaría arrancar psad, con:
/etc/init.d/psad start
Pruebas de funcionamiento:
Veamos lo que pasa cuando alguien nos hace un escaneo de puertos. Como nota, tengo un danger_level (DL) de 3 a partir del cual se añaden reglas de bloqueo.
Sep 6 21:48:05 psad: src: 87.218.x.y signature match: "MISC MS Terminal Server communication attempt" (sid: 100077) tcp port: 3389
Sep 6 21:48:05 psad: src: 87.218.x.y signature match: “MISC Microsoft PPTP communication attempt” (sid: 100082) tcp port: 1723
Sep 6 21:48:05 psad: scan detected: 87.218.x.y -> 83.213.x.y tcp: [21-6347] flags: SYN tcp pkts: 130 DL: 2
Sep 6 21:48:11 psad: src: 87.218.x.y signature match: “BACKDOOR DoomJuice file upload attempt” (sid: 2375) tcp port: 3141
Sep 6 21:48:11 psad: src: 87.218.x.y signature match: “DOS Real Audio Server communication attempt” (sid: 100112) tcp port: 7070
Sep 6 21:48:11 psad: src: 87.218.x.y signature match: “BACKDOOR Subseven DEFCON8 2.1 connection Attempt” (sid: 107) tcp port: 16959
Sep 6 21:48:11 psad: scan detected: 87.218.x.y -> 83.213.x.y tcp: [2-32770] flags: SYN tcp pkts: 214 DL: 3
Sep 6 21:48:11 psad: added iptables auto-block against 87.218.x.y for 600 seconds
Sep 6 21:48:16 psad: scan detected: 87.218.x.y -> 83.213.x.y tcp: [104-13722] flags: SYN tcp pkts: 30 DL: 3
Donde 87.218.x.y es la IP origen del escaneo y 83.213.x.y el destino.
En el firewall:
# iptables -L PSAD_BLOCK -n -t nat
Chain PSAD_BLOCK (1 references)
target prot opt source destination
DROP all — 87.218.x.y 0.0.0.0/0
Y a los 600 segundos, se vacía.
Sep 6 21:58:13 psad: removed iptables auto-block against 87.218.x.y
# iptables -L PSAD_BLOCK -n -t nat
Chain PSAD_BLOCK (1 references)
target prot opt source destination
Lo que he hecho hasta ahora es lo básico de psad. En el próximo post seguiré con alguna otra cosilla interesante.
Para el que quiera buscar más información, nada como el libro linux firewalls. Un libro realmente excelente de una editorial que merece la pena.
