Empezando con esta, y durante una serie de entradas, vamos a tratar una de las herramientas de seguridad más empleadas: la detección de intrusos a nivel de red (IDS en adelante), y cómo posibles atacantes pueden intentar eludir dicha herramienta. Como ya probablemente sepan, y como hemos visto en anteriores entradas, los IDS consisten en simples sniffers que leen todo el tráfico que circula por una red, lo tratan y lo analizan sobre un conjunto de reglas buscando posibles patrones de ataques en el tráfico escuchado.
Seguro que muchos de ustedes estarán pensando que existen también los IDS a nivel de red que actúan por comportamientos anómalos del tráfico de red. Es cierto, existen como tal pero dichos IDS sólo suelen ser eficaces para puertas traseras, gusanos de rápida propagación (fast spreading worms) y ataques de denegación de servicio; para el resto de ataques no suelen dar un buen resultado. Es por ello que las siguientes entradas se centrarán únicamente sobre la evasión en IDS a nivel de red que empleen un motor de reglas para la detección de posibles ataques.
Antes de explicar las distintas formas de poder evadir un IDS, hagamos una breve introducción al funcionamiento básico de un IDS, ya que aunque no todos los IDS funcionan exactamente igual pero siguen el siguiente patrón:
1. Un sniffer lee todo el tráfico mediante una interfaz en modo promiscuo conectada a una interfaz espejo de un switch, un router, un hub, etc. En el caso de dispositivos empotrados, directamente se emplea la propia interfaz espejo.
2. Unos preprocesadores tratan los datos leídos por el sniffer, con el objeto de que sean procesados de una forma más rápida por el motor de reglas. Tienen además otras funciones, entre ellas intentar evitar que un atacante pueda eludir el motor de reglas, aspecto que se verá más adelante.
3. Un motor de reglas y un conjunto de reglas. A partir de los paquetes tratados por los preprocesadores, el motor de reglas pasa el paquete tratado por cada una de las reglas, buscando un patrón de ataque que coincida con una de éstas. Si encuentra que alguna coincide, realiza la operación indicada por la regla, normalmente considerar que se trata de un ataque (accept) o rechazar el paquete (drop, pass, reject…). En caso de tratarse de un ataque se notifica a los postprocesadores.
4. Los postprocesadores son los encargados de tratar el ataque, ya sea notificando del ataque vía correo electrónico, almacenando el ataque en texto plano o en una base de datos, bloqueando el ataque (por lo que el IDS pasaría a ser un sistema de prevención de intrusos IPS), etc.
Una vez se ha explicado el funcionamiento sencillo de un IDS a nivel de red, vamos a explicar de forma breve los posibles vectores de ataque que permiten evadir estos sistemas. Principalmente existen cuatro vectores de ataque y un quinto, que pese a no ser un vector de ataque hay que tenerlo presenta ya que se trata de una limitación de los IDS:
1. Evasión mediante paquetes fragmentados en los preprocesadores. Existen dos posibles evasiones en este vector de ataque.
2. Codificación empleada en el ataque. No todos los IDS soportan el mismo tipo de codificación, que si soporta el servicio atacado.
3. Gusanos polimórficos y metamórficos (polymorphic and metamorphic worms).
4. Tratamiento de los datos de entrada (parseo) incorrecto por parte de los preprocesadores, que pueden dar lugar a denegación del servicio y por tanto la anulación del IDS.
5. Cifrado de las comunicaciones. Pese a que no se trata de un vector de ataque, hay que tenerlo en cuenta. Como resulta natural, si una comunicación entre un atacante y un servidor victima va cifrada, el IDS no puede reconocer ningún patrón de ataque. De hecho, el motivo por el cual las comunicaciones van cifradas es para que ningún elemento intermediario pueda entender los datos entre ambos.
Sí es cierto que algunos IDS lo que emplean es un certificado intermedio: el atacante al conectarse con el servidor mediante protocolo seguro, realmente lo que hace es conectarse al certificado del IDS, y el IDS a su vez, conectarse con el servicio solicitado por el atacante, es decir, un man in the middle (MITM). Por lo que el IDS es capaz de analizar el tráfico. Pero, ¿qué ocurre si es justamente el IDS el servidor atacado? Pues que el atacante podría leer el tráfico cifrado. Teniendo en cuenta que para ello el IDS tendría que tener una conexión con la red analizada, algo que no es aconsejable.
En las próximas entradas explicaré con ejemplos reales el funcionamiento de estos vectores de ataque y como algunos sistemas actuales son vulnerables a dichos ataques. Manténganse a la escucha.
Tienes un parrafo repetido
Gracias, solucionado.
Respecto al cifrado de comunicaciones y el analisis del trafico cifrado, existen sniferrs de red a los que se les puede incluir la clave privada del servidor, de esta manera podemos snifar y no es necesario el MITM, que puede traer importantes problemas de disponibilidad.
Efectivamente Damia, algunos modelos de Sniffer, pese a no ser la gran mayoría, permiten incluir las claves privadas de algunos servicios. De esta forma se evita disponer del IDS como puente y por tanto, tal como comenta, evitar los problemas de disponibilidad que podrían ocurrir si el IDS cae.
La desventaja que presenta, aparte de que un dispositivo o máquina tenga almacenado los certificados privados, es la caída que sufre el throughtput cuando se habilita esto en el Sniffer. Lógicamente, sigue siendo mejor opción que la alternativa de usar el IDS como puente.
Por mi parte, nunca he tenido el placer de auditar un IDS que permite incluir los certificados privados, y por tanto, no puedo opinar del comportamiento real que pueden tener estos dispositivos.