next up previous contents
Siguiente: Ampliación del esquema Subir: Implementación real de un Anterior: IDS en la máquina   Índice General

Estrategias de respuesta

Una pregunta importante que nos habíamos realizado con respecto a nuestro esquema de deteccción de intrusos (en concreto cuando hablábamos de SNORT) era qué hacer con la información obtenida del mismo; como siempre, tenemos varias posibilidades. Por un lado, podemos procesarla manualmente de forma periódica (por ejemplo cada mañana) y en función de los datos que nuestros sensores hayan recogido tomar una determinada acción: bloquear las direcciones atacantes en el firewall corporativo, enviar un correo de queja a los responsables de dichas direcciones (por desgracia esto no suele resultar muy útil), realizar informes para nuestros superiores, o simplemente no hacer nada. Dependerá casi por completo de la política de seguridad que sigamos o que tengamos que seguir.

Mucho más interesante que cualquiera de estas respuestas manuales es que el propio sensor sea capaz de generar respuestas automáticas ante lo que él considere un intento de ataque. Si elegimos esta opción, lo más habitual suele ser un bloqueo total de la dirección atacante en nuestro cortafuegos, unida a una notificación de cualquier tipo (SMS, e-mail...) a los responsables de seguridad; es siempre recomendable efectuar esta notificación (si no en tiempo real, si al menos registrando las medidas tomadas contra una determinada dirección en un log) por motivos evidentes: si bloqueamos completamente el acceso de alguien hacia nuestros sistemas, debemos pararnos a pensar que es posible que se trate de un usuario autorizado que en ningún momento atacaba nuestras máquinas, a pesar de que el sensor que hemos instalado opine lo contrario. No importa lo seguros que estemos de lo que hacemos ni de las veces que hayamos revisado nuestra base de datos de patrones: nunca podemos garantizar por completo que lo que nuestro IDS detecta como un ataque realmente lo sea.

Un correcto esquema de respuesta automática (asumimos que vamos a bloquear la dirección que presuntamente nos ataca) debería contemplar al menos los siguientes puntos:
Teniendo en cuenta los puntos anteriores (y seguramente otros), debemos diseñar un esquema de respuestas automáticas adecuado. Un pseudoalgoritmo del funcionamiento de nuestro esquema podría ser el siguiente:

								ESTADO: {Detecci'on ataque}

SI umbral de respuestas superado: FIN
SI NO
Comprobaci'on IP atacante
SI es IP protegida: FIN
SI NO
Ponderaci'on hist'orica de gravedad
SI umbral de gravedad superado: ACTUAR
SI NO
REGISTRAR
FSI
FSI
FSI
Como vemos, al detectar un ataque desde determinada dirección, el modelo comprueba que no se ha superado el número de respuestas máximo por unidad de tiempo (por ejemplo, que no se ha bloqueado ya un número determinado de direcciones en las últimas 24 horas); si este umbral ha sido sobrepasado no actuaremos de ninguna forma automática, principalmente para no causar importantes negaciones de servicio, pero si no lo ha sido, se verifica que la dirección IP contra la que previsiblemente se actuará no corresponde a una de nuestras 'protegidas', por ejemplo a una máquina de la red corporativa: si es así se finaliza. Este `finalizar' no implica ni mucho menos que el ataque no haya sido detectado y se haya guardado un log del mismo, simplemente que para evitar problemas mayores no actuamos en tiempo real contra la máquina: si corresponde al grupo de `protegidas' es porque tenemos cierta confianza - o cierto control - sobre la misma, por lo que un operador puede preocuparse más tarde de investigar la alerta. Si se trata de una dirección no controlada ponderamos la gravedad del ataque: un ataque con poca posibilidad de ser un falso positivo tendrá un peso elevado, mientras que uno que pueda ser una falsa alarma tendrá un peso bajo; aún así, diferentes ataques de poco peso pueden llegar a sobrepasar nuestro límite si se repiten en un intervalo de tiempo pequeño. Es importante recalcar el `diferentes', ya que si la alarma que se genera es todo el rato la misma debemos plantearnos algo: >es posible que un proceso que se ejecuta periódicamente y que no se trata de un ataque esté todo el rato levantando una falsa misma alarma? La respuesta es , y evidentemente no debemos bloquearlo sin más; seguramente es más recomendable revisar nuestra base de datos de patrones de ataques para ver por qué se puede estar generando contínuamente dicha alarma.

Por último, si nuestro umbral no se ha superado debemos registrar el ataque, su peso y la hora en que se produjo para poder hacer ponderaciones históricas ante más alarmas generadas desde la misma dirección, y si se ha superado el esquema debe efectuar la respuesta automática: bloquear al atacante en el cortafuegos, enviar un correo electrónico al responsable de seguridad, etc. Debemos pensar que para llegar a este último punto, tenemos que estar bastante seguros de que realmente hemos detectado a un pirata: no podemos permitirnos el efectuar respuestas automáticas ante cualquier patrón que nos parezca sospechoso sin saber realmente - o con una probabilidad alta - que se trata de algo hostil a nuestros sistemas.

Antes de finalizar este punto, es necesario que volver a insistir una vez más en algo que ya hemos comentado: es muy recomendable que ante cada respuesta se genere un aviso que pueda ser validado por un administrador de sistemas o por responsables de seguridad, mejor si es en tiempo real; por muy seguros que estemos del correcto funcionamiento de nuestro detector de intrusos, nadie nos garantiza que no nos podamos encontrar ante comportamientos inesperados o indebidos, y con toda certeza es más fácil para una persona que para una máquina darse cuenta de un error y subsanarlo.

next up previous contents
Siguiente: Ampliación del esquema Subir: Implementación real de un Anterior: IDS en la máquina   Índice General
2003-08-08