IDS en el cortafuegos

A la hora de hablar de detección de intrusos, un modelo dentro de los NIDS que no es muy habitual es la detección en el cortafuegos (o en los cortafuegos) corporativo; digo que no es muy habitual -al menos por mi experiencia- y no sé muy bien por qué, ya que bajo mi punto de vista se trata de algo bastante sencillo de implantar en la mayor parte de firewalls, con un mantenimiento simple y, sobre todo, con una tasa muy baja de falsos positivos. Además, creo que le ahorraría bastante trabajo a los sistemas de detección ubicados en las redes internas, algo que en el caso de seguridad pasiva (IDS) se traduce directamente en un ahorro de costes en el personal dedicado a revisar las alertas de un SNORT o similar.

Un cortafuegos suele manejarse muy bien con las cabeceras de los paquetes y menos bien (o simplemente, muy mal) con los campos de datos; así, para hablar de detección en el cortafuegos, podemos centrarnos en los ataques -o en las anomalías, por no hablar aún de ataques- de dichas cabeceras. ¿Y qué información hay en los campos de cabecera de protocolos como TCP o IP? Direcciones origen y destino, puertos origen y destino, información del protocolo, bits URG, FIN, etc. Un montón de información que, correctamente analizada, permitirá bloquear tráficos anómalos que tratan de entrar en nuestra red y nos proporcionará información útil de eventos cuanto menos sospechosos.

Para empezar, lo obvio: de una determinada zona de red -interna o externa- no puede llegar tráfico con dirección origen otra zona de red. Así, si nuestra red de usuarios tiene un direccionamiento 192.168.1.0/24, desde esa red no debería llegar nunca un paquete con origen en otro direccionamiento -al menos, en condiciones normales-, por lo que podemos definir reglas que acoten qué direcciones origen pueden provenir de cada zona de red. Y seguimos con más cosas obvias: hay puertos que deben estar filtrados sí o sí (o casi sí), y cualquier actividad con destino dichos puertos puede ser a priori considerada sospechosa. ¿Quién utiliza hoy en día el protocolo UUCP? ¿Y gopher? ¿Alguien conoce algún uso lícito y habitual de chargen? ¿Y de finger? Si en mi cortafuegos veo tráfico hacia esos puertos, lo más probable es que me encuentre ante un ataque -típicamente un barrido de puertos, un information gathering o incluso malware-, por lo que me va a interesar bloquear y registrar este tráfico. Algunos puertos interesantes para enterarnos de estas acciones -sin menoscabo, por supuesto, de que todo lo no explícitamente autorizado esté cortado en nuestro firewall- pueden ser discard, daytime, chargen, gopher, finger, pop2, biff, r-* o uucp, por citar sólo unos cuantos. En el caso de puertos utilizados por malware, algunos muy conocidos son 12345 (NetBus) o 31337 (BackOrifice), y de la misma forma podemos bloquearlos y registrar su uso con cualquier cortafuegos (ejemplo para ipf, Solaris 10):


block in log quick on hme0 from any to any port = 31337
block in log quick on hme0 from any to any port = 12345
block in log quick on hme0 from any to any port = 70
block in log quick on hme0 from any to any port = 79
block in log quick on hme0 from any to any port = 540
...

Más cosas a considerar; en el RFC 3330 se definen unos rangos de direcciones IP “especiales” -no asignadas, privadas, bucle local…-, direcciones que no deben encontrarse en determinadas patas de nuestro cortafuegos; así, por ejemplo, en la pata de conexión con Internet nunca deberemos ver tráfico -salvo configuraciones excepcionales- que provenga de estas direcciones, y si lo vemos, al menos deberemos prestarle atención:


block in log quick on hme0 from 192.168.0.0/16 to any
block in log quick on hme0 from 0.0.0.0/8 to any
block in log quick on hme0 from 172.16.0.0/12 to any
block in log quick on hme0 from 198.18.0.0/15 to any
...

Seguimos: violaciones de protocolo o uso de protocolos fuera de lo habitual. Por definición de los protocolos TCP e IP, existen ciertas combinaciones de bits que no pueden encontrarse, en situación normal, en las cabeceras de los paquetes; así, no es correcto que un paquete TCP tenga activos los bits FIN y SYN de forma simultánea, ya que eso violaría el protocolo (estaríamos solicitando un inicio de conexión y a la vez un cierre, algo no coherente), ni tampoco está aceptado que una trama IP tenga activos al mismo tiempo los bits DF (Don’t Fragment) y MF (More Fragments). Si vemos tráfico con estas violaciones, se trata de una anomalía -lo de antes, por no llamarle ataque directamente- que nos interesa conocer, ya que los ataques de fragmentación IP o los barridos de puertos en base a violaciones del protocolo TCP son el pan nuestro de cada día (una herramienta como nmap implementa diferentes técnicas de este tipo). Adicionalmente, podemos encontrarnos tramas válidas según protocolo pero no habituales, y que por lo tanto puede ser necesario registrar. Algunas reglas más para ipf (podemos encontrar auténticos recopilatorios en Internet, y escoger las que más nos interesen):


block in log proto tcp all with short
block in log quick on hme0 all with opt lsrr
block in log quick on hme0 all with opt ssrr
block in log quick on hme0 proto tcp all flags FUP
block in log quick on hme0 proto tcp all flags FUP/FUP
block in log quick on hme0 proto tcp all flags /FSRPAU
block in log quick on hme0 proto tcp all flags FSRPAU
block in log quick on hme0 proto tcp all flags SF/SFRA
block in log quick on hme0 proto tcp all flags /SFRA
block in log quick on hme0 proto tcp all flags F/SFRA
block in log quick on hme0 proto tcp all flags U/SFRAU
block in log quick on hme0 proto tcp all flags P
block in log quick on hme0 proto tcp all flags FUP/WEUAPRSF
block in log quick on hme0 proto tcp all flags WEUAPRSF/WEUAPRSF
block in log quick on hme0 proto tcp all flags SRAFU/WEUAPRSF
block in log quick on hme0 proto tcp all flags /WEUAPRSF
block in log quick on hme0 proto tcp all flags SR/SR
block in log quick on hme0 proto tcp all flags SF/SF
block in log quick on hme0 proto tcp all flags /S


Con estas líneas y algunas más tenemos de forma sencilla un mini sistema de detección de intrusos implantado en nuestro firewall ipf (en todos los cortafuegos habituales podemos hacer cosas parecidas), sistema que obviamente puede ser mejorado por todas partes pero que, de momento, será capaz de alertarnos ante tráficos sospechosos; las líneas anteriores, aparte de bloquear el tráfico, generarán un log en tiempo real (man ipmon), log que puede ser tratado con cualquier script para integrarlo en nuestro esquema de detección de intrusos global, que más allá del NIDS habitual debería recoger y procesar los registros todos los sistemas de detección que tengamos implantados, tanto a nivel de host como a nivel de red, para proporcionar información correlada en base a todos los datos de los diferentes IDS. Esto, por supuesto, sin entrar en técnicas que ya se alejan de lo que sería un NIDS en el cortafuegos, como utilizar return-rst en nuestro ipf para “contaminar” los resultados del atacante (útil frente a barridos de puertos) o ejecutar ciertas órdenes del sistema ante tráficos anómalos detectados, que ya es material para otro post :)