ES2282739T3 - Procedimiento y sistema para la prevencion y el rechazo de intrusiones. - Google Patents
Procedimiento y sistema para la prevencion y el rechazo de intrusiones. Download PDFInfo
- Publication number
- ES2282739T3 ES2282739T3 ES03819020T ES03819020T ES2282739T3 ES 2282739 T3 ES2282739 T3 ES 2282739T3 ES 03819020 T ES03819020 T ES 03819020T ES 03819020 T ES03819020 T ES 03819020T ES 2282739 T3 ES2282739 T3 ES 2282739T3
- Authority
- ES
- Spain
- Prior art keywords
- traffic
- fragments
- communication
- test
- machines
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
- Machines For Manufacturing Corrugated Board In Mechanical Paper-Making Processes (AREA)
- Small-Scale Networks (AREA)
- Supply And Distribution Of Alternating Current (AREA)
- Manufacture, Treatment Of Glass Fibers (AREA)
- Electrical Discharge Machining, Electrochemical Machining, And Combined Machining (AREA)
Abstract
Procedimiento para prevenir intrusiones en el tráfico de comunicaciones con un conjunto (130) de máquinas en una red, comprendiendo dicho tráfico fragmentos de comunicación, en el cual el procedimiento incluye las etapas de: - proveer un sistema de prueba (420) que incluye (421) la replicación de al menos una de dichas máquinas en dicho conjunto (130), - dirigir al menos parte de dichos fragmentos de comunicación en dicho tráfico hacia el sistema de prueba (420), - ejecutar dichos fragmentos de comunicación dirigidos hacia el sistema de prueba (420) en dichos servicios de prueba (421) para detectar posibles efectos adversos en dicho sistema de prueba (420), y i) en presencia de un efecto adverso bloquear los fragmentos de tráfico que producen dicho efecto adverso, y ii) en ausencia de un efecto adverso, permitir la comunicación con dicho conjunto (130) de máquinas a los fragmentos de comunicación que no producen dicho efecto adverso.
Description
Procedimiento y sistema para la prevención y el
rechazo de intrusiones.
La presente invención se refiere a técnicas para
la prevención y rechazo de intrusiones.
La invención fue concebida prestando especial
atención a su posible aplicación para asegurar la seguridad en
redes de telecomunicaciones.
Actualmente existen dos clases de sistemas de
detección de intrusiones.
La primera clase (denominada normalmente sistema
de detección de intrusiones de red o Network Intrusion Detection
System, Network-IDS) monitoriza esencialmente el
tráfico de un segmento de red; la clase siguiente (a menudo llamada
Host-IDS) está adaptada para monitorizar los eventos
que ocurren en una sola máquina.
Los dos sistemas analizan datos mientras buscan
ataques o acciones que violen las políticas de seguridad. Esto se
realiza mediante el uso de algoritmos de conocimiento y
reconocimiento disponibles, con el objetivo de emitir una señal o
una alarma cuando existe una coincidencia. Las dos formas de abordar
el problema tienen ventajas e inconvenientes.
La disposición descrita en
US-A-6 279 es un ejemplo de
Network-IDS.
Como se muestra en la figura 1, en dicha
configuración, una red interna, la red interna 130, que contiene,
por ejemplo, servidores interiores es protegida por un sistema de
detección de intrusiones que incluye el sensor 121. El sensor 121
esta adaptado para monitorizar, a través del interfaz 122a, el
trafico que discurre entre la red interna 130 y la red externa 110
en cualquiera de los sentidos. El sistema monitoriza en el interior
del flujo de datos aquellas pautas de ataque conocidas y
registradas en la base de datos 123. En el caso de que ocurra una
detección se emite una alarma. Se proporciona también el sistema de
control 124 de la arquitectura de detección de intrusos que tiene
como tarea la recogida y presentación al operador final al tiempo
que también gestiona el sistema completo. En la disposición mostrada
en la figura 1 solo se muestra un sensor. Esta es una disposición
dada exclusivamente a modo de ejemplo, en la que un sistema de
detección de intrusiones típico incluye una multiplicidad de
sensores situados en los puntos críticos. De la misma manera, en
arquitecturas más complejas que incluyan un gran número de sensores,
el sistema de gestión 124 puede estar, de hecho, hospedado en una
pluralidad de máquinas.
En la configuración mostrada en la figura 1, la
función de detección está asignada al sensor de red 121,
normalmente hospedado en aparatos que pueden ser un ordenador
genérico o un dispositivo especializado. El sensor intercepta el
tráfico en una sección de la red. Normalmente, analiza el tráfico
por comparación con un conjunto de pautas de identificación
recogidas en la base de datos 123. Dichas bases de datos deben ser
actualizadas periódicamente, y esta operación debe ser realizada en
el menor plazo posible cada vez que se reconocen nuevos tipos de
ataques. Si no, el sistema de detección pierde su efectividad. Las
pautas de identificación referidas incluyen normalmente una pauta
de ataque: de esta manera, incluso un cambio relativamente menor en
la pauta hace el reconocimiento imposible. Por este motivo, los
tipos de sensor más sofisticados realizan una operación de
normalización de flujo de los protocolos más comunes con el objetivo
de crear las mejores condiciones para la verificación. Algunos
tipos de Network-IDSes combinan las pautas de
detección con un mecanismo de análisis de anomalías, es decir,
variaciones con respecto al comportamiento esperado de un
protocolo. Estas técnicas siguen el enfoque denominado actualmente
Detección de Anomalías del Protocolo.
Este tipo de sistema tiene ciertas ventajas.
En primer lugar, se pueden monitorizar grandes
mediante unos pocos sensores colocados de manera adecuada.
Además, este tipo de sensores tiene un impacto
mínimo en la red. Los sensores están situados en lugares críticos
de la red donde monitorizan el tráfico sin afectar negativamente al
rendimiento.
El trabajo de implantación es mínimo. Los
sensores son entidades separadas de las máquinas monitorizadas, y
por ello, independientes de las mismas. El mismo sensor, por lo
tanto, se adapta para proteger máquinas con diferentes sistemas
operativos, que proporcionan diferentes servicios, etc.
Adicionalmente, los sensores pueden ser
completamente indetectables para la red monitorizada basándose en
lo que actualmente se denomina configuración "stealth" o
sigilosa. Normalmente, el sensor de red dispone de dos interfaces
de comunicación: el primero (122a, de nuevo en la figura 1) está
configurado de manera combinada para la interceptación de tráfico;
el segundo (122b) esta configurado de la manera habitual para
permitir las operaciones de gestión. El interfaz de monitorización
no dispone de dirección IP y por lo tanto, no se le puede dirigir
tráfico. La ausencia de una dirección IP lo hace prácticamente
invisible a un posible intruso.
El principal inconveniente de dichos
Network-IDS reside en la falta de un conocimiento
preciso del estado (servicios ofrecidos, software empleado,
vulnerabilidades presentes, y otros) en las máquinas residentes en
el segmento de red 130 que está siendo controlado. La actividad del
sistema se limita a monitorizar el tráfico buscando pautas de
ataque sin conocer si estas representan una amenaza real para el
sistema que debe ser protegido.
Esto conlleva una reducción de la efectividad de
la detección e incrementa el número de falsas alarmas. Cada vez que
una pauta de ataque es detectada, estos sistemas emiten una alarma
que normalmente tiene asociada un grado de severidad según el tipo
de ataque. Este enfoque produce una gran cantidad de alarmas (en una
red grande, un solo sensor puede generar mil alarmas de estas al
día) haciendo muy difícil, si no imposible, gestionar dicha
herramienta. Además, un gran número de las emisiones son de hecho
falsas alarmas: de hecho, el sensor de red no opera de manera
inteligente y emite alarmas incluso cuando el paquete peligroso esta
dirigido hacia una máquina inexistente (esta es una situación
típica producida por herramientas adaptadas para la generación
automática de ataques) o cuando la máquina no es vulnerable al
ataque en concreto, porque no proporciona el servicio en particular
o porqué está equipada con una revisión actualizada y protegida del
software. Esta situación lleva al tratamiento de grandes cantidades
de datos en su mayor parte irrelevantes a los cuales se asigna un
alto nivel de severidad, con el riesgo de que las alarmas reales
queden de alguna manera ocultas y desviando así tiempo y recursos
de la tarea de evitar problemas
reales.
reales.
Otra limitación intrínseca de un sistema
"Network-based IDS" está relacionada con los
procesos de inserción y evasión descritos por ejemplo en T.H.
Ptacek y T.N. Newsham en "Insertion, evasion and denial of
service: eluding network intrusion detection", Secure
Network Inc., Enero 1998, texto de referencia para los sistemas de
detección de intrusiones.
De hecho, el protocolo IP dispone de la
posibilidad de fragmentar ciertos paquetes, es decir, que se partan
en paquetes más pequeños antes de ser transmitidos por la red.
Siendo el tamaño máximo de un paquete IP de 65.546 bytes (alrededor
de 64 KB) está insuficientemente adaptado para la transmisión en
diferentes tipos de red. Por ejemplo, una trama Ethernet es de 1500
bytes; en el caso de una red TokenRing dicho tamaño es de 4 KB. En
general, la denominada unidad máxima de transmisión (maximum
transmission unit, MTU), equivalente al tamaño máximo del
paquete que puede ser transmitido sobre el nivel de enlace de datos,
puede variar significativamente de red a red. Por lo tanto, es
evidente que dicho parámetro debe limitar el tamaño máximo del
paquete IP para permitir que los datos sean conducidos sobre
diferentes tipos de redes de una manera completamente transparente
para los protocolos de nivel superior y el usuario final.
En el interior de la cabecera de un paquete IP
existen básicamente dos campos para la gestión correcta de la
fragmentación: el Desplazamiento de Fragmento (Fragment
Offset) y el bit indicador de Más Fragmentos (More
Fragments, MF). El campo de desplazamiento identifica la
posición del paquete transmitido en del flujo de datos, haciendo
posible de esta manera reconstruir el orden correcto de los
paquetes, mientras que el bit indicador MF distingue el fragmento
final del resto. Luego, los paquetes son recompuestos por el usuario
final usando esta información.
Por lo tanto, es de importancia capital, para el
sistema de detección de intrusiones y para las máquinas así
protegidas, que reproduzcan el mismo comportamiento con respecto a
los fragmentos de paquetes IP recibidos. De esta manera, es posible
evitar el denominado fenómeno de inserción y evasión que puede poner
en riesgo la efectividad de un sistema de detección de
intrusiones.
Una inserción ocurre cuando el IDS acepta y
considera como valido ciertos paquetes que habrían sido descartados
por el sistema final hacia el cual han sido dirigidos, mientras que
la evasión ocurre cuando el IDS no toma en consideración paquetes
que deberían ser aceptados por el sistema final. De hecho, si la
detección de intrusiones y el sistema final a los cuales los datos
van dirigidos están expuestos a diferentes flujos de tráfico,
existe el riesgo de que un ataque no sea observado por el sistema de
detección a pesar de que llegue al destino definitivo.
Al mismo tiempo, pueden surgir problemas cuando
existe la necesidad de reconstruir flujos de datos TCP (Protocolo
de Control de Transmisión, Transmission Control Protocol).
TCP no dispone de una función de fragmentación, pero proporciona al
nivel superior una abstracción similar a un flujo continuo de
caracteres provenientes de un fichero que conserva el orden y la
integridad de estos datos. Estas funciones se implementan mediante
eventos de tiempo y mecanismos de retransmisión.
Cada conexión TCP se identifica por medio de un
número de secuencia. La selección de ese número se basa en un
criterio dependiente del sistema operativo del aparato que inicia la
conexión y se incrementa en una cantidad igual al número de bytes
recibidos y reconocidos por medio del indicador de reconocimiento
(ACK). Este número de secuencia contenido en la cabecera TCP es el
único elemento de datos que hace posible identificar el estado de
una conexión y ordenar e identificar los datos en el interior del
flujo que es transmitido.
En cualquier caso, es posible que un paquete sea
retransmitido cuando el paquete ACK no ha sido recibido dentro de
un intervalo de tiempo o si ha ocurrido un error durante la
transmisión. La retransmisión hace la reconstrucción del flujo de
tráfico más compleja para un sistema de detección de intrusos ya que
un paquete reenviado es interpretado más de una vez por el IDS. El
sistema de detección de intrusiones ve dos paquetes idénticos
siendo transmitidos pero no está en la posición de establecer cual
de los dos fue aceptado por el destinatario.
De hecho, un sistema de detección de intrusiones
"network-based" no dispone de ninguna garantía
ni manera de descubrir si un paquete dado ha sido aceptado o
descartado por el sistema final que está siendo monitorizado. De
nuevo, los fenómenos de inserción (el IDS acepta y considera como
validos paquetes descartados por el sistema final) y evasión (el
IDS no toma en consideración paquetes que han sido aceptados por el
sistema final) tienen como resultado una fuerte limitación en la
eficacia de la detección en estos sistemas.
Tanto en el protocolo IP como en el TCP existen
otros campos que pueden ser manipulados con propósitos de inserción
y evasión (a este respecto, se puede hacer referencia de nuevo al
articulo de Ptacek ya citado anteriormente), de manera que se
aniquile la eficiencia de un "network-based"
IDS.
En resumen, el problema básico que hace a un
"network-based" IDS vulnerable a la inserción y
a la evasión está en el hecho de que el IDS y el sistema final
puede estar expuesto en determinados contextos a dos diferentes
flujos de datos, ya que son máquinas separadas, con diferentes
sistemas operativos e implementaciones de la pila TCP/IP. Luego, un
atacante puede tomar ventaja gracias a esta situación para
\hbox{lanzar un ataque invisible para los sistemas de
protección.}
Esta limitación y los inconvenientes a los que
se ha hecho antes referencia limitan la capacidad de detección de
un "network-based" IDS y, en esencia, derivan
del conocimiento limitado disponible para el sistema de detección
de intrusiones con respecto al estado y configuración (sistemas
operativos, software usado, servicios ofrecidos, vulnerabilidades
presentes y otros) de las máquinas que residen en el segmento de red
que se controla.
Un enfoque sustancialmente diferente, que trata
con estas limitaciones, se representa por un
"host-based" IDS tal como se muestra en la
figura 2. Un ejemplo de este tipo de sistema de detección de
intrusiones se describe en US-A-5
557 742.
En este caso, los sistemas y mecanismos de
detección de intrusiones son una entidad separada de las máquinas
protegidas. Específicamente, en cada máquina protegida 131 de la red
interna 130 se instala un sensor 132 que controla el estado de la
máquina asociada monitorizando, por ejemplo, el sistema de ficheros,
la actividad de la red y el nivel de uso de recursos. Normalmente
se proporciona una base de datos 133 que contiene las pautas de
detección de los ataques conocidos y las políticas respectivas así
como un sistema de control 134 que tiene como tarea la recogida y
el proceso de las alarmas generadas por los sensores individuales al
tiempo que también gestiona el sistema completo. De nuevo, pueden
existir soluciones reales basadas en arquitecturas más
completas.
Las técnicas empleadas en sistemas de detección
de intrusión "host-based" incluyen el uso de
los programas especiales, 132a, 132b, ..., que están instalados y
corren directamente en el sistema que esta siendo monitorizado 131
y están adaptados para operar al nivel del núcleo o al nivel de
aplicación, por ejemplo para interceptar las llamadas al
sistema.
En esencia, un "host-based"
IDS tiene una visión local y controla el estado de la máquina en la
cual está hospedado monitorizando, por ejemplo, el sistema de
ficheros, la actividad de la red y el nivel de uso de recursos. Tal
sistema proporciona una mejor ejecución en la detección de ataques
que tengan un impacto o dejen un rastro en el sistema. Además,
puede detectar ataques que no vienen a través de la red, como por
ejemplo aquellas intrusiones ejecutadas a través de la consola,
mediante escalado
\hbox{de privilegios por el usuario,
normalmente personal interno, o ataques a aplicaciones.}
Con el objetivo de proporcionar un sistema de
detección de intrusiones verdaderamente efectivo del tipo huésped,
"host", el componente de detección se debe instalar en los
sistemas a proteger. Esto implica que el software es específico
para cada uno de los sistemas operativos en los que se debe
instalar; existen soluciones específicas para sistemas Microsoft,
Solaris, Unix y otros.
Un sistema "host-based"
(HIDS) hospedado directamente en el sistema controlado es vulnerable
a ataques y corre el riesgo de ser deshabilitado como puede ocurrir
con cualquier otro programa que corra en la misma máquina. Un
sistema de detección de intrusiones
"host-based" se puede deshabilitar por medio de
ciertos ataques de denegación de servicio. De hecho, el sensor es
tan sensible a dichas órdenes como el sistema que lo hospeda.
La limitación básica de uno de estos sistemas
está por ello relacionada con su vulnerabilidad ante invasiones.
Con el objetivo de proporcionar un sistema de detección de
intrusiones "host-based", se debe instalar un
componente de software específico en cada máquina monitorizada,
pudiendo dicho componente ser también un software que trabaja a
bajo nivel (por ejemplo un módulo de núcleo en un sistema UNIX).
Esto puede llevar a la reducción de la capacidad de ejecución de la
máquina, o incluso peor, a tener un conflicto con otras
aplicaciones ya instaladas. Además, para ajustar la detección y
mejorar su efectividad se requieren configuraciones específicas
para cada máquina. Esta situación se hace más crítica cuando se
trata de máquinas "de producción" que ofrecen servicios
críticos, cuya configuración no se puede modificar, para evitar el
riesgo de hacerlas inestables.
Además, un buen sistema de protección ante
intrusiones debe estar ubicado en una posición desde la que pueda
bloquear los ataques detectados antes de que provoquen un daño en
los sistemas protegidos. La mayoría de los sistemas tradicionales
son incapaces de proporcionar una respuesta activa ante la detección
de un ataque; simplemente ejecutan su función de proporcionar una
alarma más o menos detallada (dependiente de las especificaciones
dadas por el administrador y el nivel de servicio garantizado por la
herramienta) a través de diferentes canales de comunicación (desde
una señal parpadeante en una consola a un correo electrónico
personal).
Por este motivo hay técnicas convencionales que
proporcionan también una respuesta activa, es decir, implican una
acción real con el objetivo de interrumpir el flujo de tráfico
peligroso hacia los sistemas de la red interna. Entre ellas se
incluye la de cerrar las sesiones y actualizar de inmediato las
reglas del "firewall".
El cierre de la sesión es el medio más simple y
común de reaccionar a la detección de una intrusión: un mensaje de
error en la red (por ejemplo el mensaje destino inalcanzable en un
paquete ICMP o un "reset" del protocolo TCP incluido en el
indicar de bit RST) recibido por la pila TCP/IP causa el fin de la
comunicación. Ante la detección de un ataque, los sistemas IDS
envían paquetes TCP, RST o ICMP alterados adecuadamente para hacer
a la máquina inalcanzable para el atacante, bloqueando así la sesión
peligrosa.
Tal técnica debe ser implantada de manera que
sea rápida: si el sistema no reacciona de manera urgente, puede que
no sea capaz de bloquear el flujo de tráfico peligroso o que
intervenga cuando el daño ya haya ocurrido. Basta con pensar en un
ataque cuyo contenido malévolo se limite a un único paquete: esta es
una situación limite en la cual la contramedida descrita es
totalmente inútil.
Una de las soluciones a las que se recurre en
algunos sistemas de detección de intrusiones para reaccionar ante
un ataque es proporcionar un procedimiento de cooperación con un
"firewall" modificando en tiempo real sus reglas. De
esta manera, el sistema de detección de intrusiones informa al
firewall para que cancele todas aquellas conexiones que
vengan de la dirección IP del atacante detectado para bloquear el
flujo de tráfico malévolo. Dependiendo de la implementación, la
regla o reglas añadidas pueden ser canceladas después de un periodo
de tiempo establecido o, por el contrario, son necesarios varios
ataques para aislar a una dirección IP en particular.
En cualquier caso, esta técnica no esta exenta
de las misma limitaciones que afectan a las otras técnicas
consideradas anteriormente. Es efectiva en el caso de ataques que
explotan una interfaz de comandos obtenido por medio de un software
de intrusión (en cuyo caso el software de intrusión se ejecuta, pero
el interfaz de comandos obtenido deja de ser alcanzable), pero
resulta inútil en caso de ataques como las denegaciones de servicio
"DOS" que finalizan su actividad con el contenido de unos pocos
paquetes, a veces incluso uno solo.
Una limitación intrínseca de estas técnicas es
que no son técnicas de prevención ya que no actúan antes de que el
paquete llegue al destino. De hecho, solo reaccionan después de que
halla ocurrido el evento y la reacción, independientemente de su
velocidad, siempre sigue a la presencia de un evento sospechoso,
como el tránsito de un paquete determinado. La única manera
aceptable de superar esta limitación es integrar en el sistema de
detección de intrusiones una función de firewall y realizando
un sistema de detección de intrusiones integrado.
Esta configuración se describe, por ejemplo, en
US-A- 6 513 122 y se suele representar mediante el
diagrama de bloques de la figura 3.
Específicamente, el diagrama de bloques de la
figura 3 muestra la arquitectura de un sistema de detección de
intrusiones integrado 310, en el cual la red interna 130 está
separada de la red externa 110. Este tipo de sistema puede
considerarse como una evolución del
"network-based" mostrado en la figura 1, en el
que el sensor de red pasa a ser un puente que separa la red a
proteger de la red externa.
El sistema incluye normalmente tres interfaces
de red, dos de las cuales (311a y 311b) operan en el segundo nivel
("nivel 2") de la pila TCP/IP, permitiendo que el dispositivo
actúe como un puente a la vez que mantiene la invisibilidad al
nivel de red. Estas interfaces monitorizan todo el tráfico en
tránsito desde y hacia la red interna 130. Una tercera interfaz,
311e, gestiona el sistema. El dispositivo recoge todo el tráfico
130 y detecta, a través del componente de detección de intrusiones
312b, las pautas de ataques conocidas contenidas en las bases de
datos 313. Cuando ocurre un ataque, a través del componente
firewall 312a, el sistema evita que el paquete peligroso
pase a través del dispositivo y alcance el objetivo, consiguiendo
con ello un sistema de prevención de acciones de intrusión. La
referencia 314 designa el módulo de gestión del sistema.
De nuevo, el diagrama de bloques de ejemplo
mostrado en la figura 3 corresponde a una arquitectura
simplificada: pueden existir soluciones reales basadas en
arquitecturas más complejas.
Comparada con la disposición más habitual
discutida previamente, la configuración mostrada en la figura 3
opera a la manera de un puente entre la red externa 110 y la red a
proteger 130, actuando como una pasarela para la red interna.
Operando al nivel 2, con las interfaces 311, mantiene la
invisibilidad habitual de un sistema
"network-based". Además, el sistema de
detección de intrusiones 310 mostrado en la figura 3 recoge,
actuando como una pasarela para la red interna, todo el tráfico
desde y hasta la red gestionándola mediante las funciones de
firewall integradas (312a) y funciones de detección de
intrusiones (312b). De esta manera, el sistema puede analizar el
tráfico, buscando paquetes sospechosos. Cuando detecta una intrusión
(por medio del componente 312b), puede entonces bloquearla por
medio del componente del firewall 312a, evitando que sea
transmitido al otro interfaz.
Esta técnica de reacción actúa antes de que un
paquete sospechoso llegue al destino, implantando por lo tanto un
auténtico mecanismo de prevención. Luego, se superan las
limitaciones de las disposiciones del estado de la técnica
consideradas anteriormente, con la posibilidad de detectar y
bloquear ataques contenidos en un único
paquete.
paquete.
En cualquier caso, incluso la disposición
mostrada en la figura 3 sigue teniendo las limitaciones descritas
en las anteriores y las relacionadas, como es el caso de los
sistemas "network-based", con la falta de
conocimiento preciso del estado de las máquinas que residen en el
segmento de la red (130) controlado. De hecho, la disposición
mostrada en la figura 3 limita su intervención a la monitorización
del tráfico a la vez que busca pautas de ataque, sin saber, sin
embargo, si pueden representar una amenaza real para los sistemas
protegidos. WO-A-03/010922 sugiere
el uso de un servidor señuelo para registrar las actividades
sospechosas en la red.
Luego, el objeto de la invención es proporcionar
una disposición que proteja los sistemas y redes ante intrusiones,
adaptados para detectar los paquetes peligrosos antes de que puedan
alcanzar las máquinas en una red protegida.
Específicamente, la invención tiene el objetivo
de proporcionar un sistema adaptado para detener también ataques
"desconocidos" a la vez que asegura la seguridad de, por
ejemplo, las máquinas de producción, en las cuales no hay software
dedicado instalado.
Por ataques "desconocidos", se entienden
por lo general aquellos ataques que el sistema no había padecido o
aquellos sobre los cuales no había información almacenada en el
sistema.
De acuerdo con la presente invención, este
objetivo se alcanza por medio de un procedimiento con las
características descritas en las reivindicaciones siguientes. La
invención también esta relacionada con el sistema correspondiente,
una red equipada con un sistema y el producto programa de ordenador
asociado, que puede cargarse en la memoria de por lo menos un
ordenador e incluyendo las partes de código software para llevar a
cabo las etapas del procedimiento cuando el producto es ejecutado en
un ordenador. Tal como se usa aquí, la referencia a este producto
programa de ordenador pretende ser equivalente a hacer referencia a
un soporte que puede ser leído por un ordenador que contenga las
instrucciones para controlar un ordenador que coordine la ejecución
del procedimiento de la invención. Evidentemente, la referencia a
"por lo menos un" ordenador pretende resaltar la capacidad de
la configuración de la invención para ser implantada de manera
distribuida.
En consecuencia, la realización preferida de la
invención previene la intrusión en el tráfico de comunicación de un
conjunto de máquinas en una red, comprendiendo el tráfico fragmentos
de comunicaciones identificados por sus respectivas pautas. Se
proporciona un sistema de prueba que incluye servicios de prueba y
al menos una parte de los fragmentos enviados en dicho tráfico es
dirigida al sistema de pruebas, donde se ejecutan para detectar
posibles efectos adversos en dichas máquinas de prueba. Si ocurren
efectos adversos, los fragmentos de comunicación que los provocan
son bloqueados. En ausencia de efectos adversos, la comunicación con
el conjunto de máquinas protegidas se permite para las partes de la
comunicación que no produzcan dichos efectos adversos.
Las entidades de comunicación dirigidas hacia el
sistema de prueba incluyen entidades de comunicación obtenidas del
tráfico dirigido hacia o con destino al conjunto de máquinas
protegidas.
De esta manera, la configuración descrita aquí
obtiene protección "virtualizando" las máquinas reales,
protegidas en un conjunto de máquinas de prueba.
La configuración aquí descrita es especialmente
adecuada para el uso en asociación con una red protegida
subdividida en áreas que agrupan sistemas similares, estando cada
área protegida por un sistema integrado que incluye detección de
intrusiones, desvío de intrusiones y componentes de sistemas de
prueba.
En la realización preferida, el sistema reconoce
las partes de la comunicación peligrosas o dañinas, (por ejemplo
paquetes en particular) y los paquetes permitidos e inofensivos,
bloqueando los primeros y dejando pasar los siguientes: esto se
consigue mediante la identificación por parte de las dos bases de
datos respectivas. El componente de desvío redirige hacia el
componente de prueba aquellos paquetes cuya naturaleza y posibles
efectos en las máquinas no son conocidos (por ejemplo que no sean
reconocidos con suficiente fiabilidad). El componente de pruebas,
donde los sistemas y servicios de la red interna (es decir, las
máquinas protegidas) están replicadas, ejecuta los fragmentos de la
comunicación y por consiguiente comprueba el efecto real de los
mismos en el sistema replicado.
En el caso de que la prueba demuestre un efecto
negativo o peligroso, el paquete no se devuelve al sistema de
desvío y por lo tanto no es capaz de alcanzar las máquinas
protegidas de la red interna. En el caso de que se compruebe que el
paquete es "bueno", se redirige hace el componente de desvío de
intrusiones para ser reenviado a las máquinas de la red interna. En
ambos casos las respectivas pautas de identificación (las firmas)
pueden ser usadas para actualizar las bases de datos que puede haber
en el componente de detección de intrusos.
En resumen, la configuración aquí descrita
proporciona una arquitectura que mantiene las ventajas de todas las
disposiciones de la técnica previa, a la vez que se hace cargo de
los inconvenientes intrínsecos de esos sistemas de detección de
intrusos (del tipo "network-based") que no
disponen de información suficiente disponible de los sistemas
finales. La configuración descrita también evita la naturaleza
intrínsecamente vulnerable al invasor de los sistemas de detección
de intrusiones "host-based", a la vez que
garantiza que el tráfico potencialmente peligroso es bloqueado y no
se le permite propagarse hacia las máquinas protegidas.
La invención se describirá, únicamente a título
de ejemplo, haciendo referencia a las figuras adjuntas, en las
cuales:
- las figuras 1 a 3, relacionadas con la técnica
previa, han sido descritas anteriormente.
- la figura 4 es un diagrama de bloques que
muestra la distribución general de la disposición que se describe
aquí, y
- las figuras 5 y 6 son diagramas de flujo que
representan a modo de ejemplo la operación de la disposición aquí
descrita.
Tal como se ha indicado previamente, la
configuración de ejemplo aquí descrita proporciona protección de
red a través de la acción combinada de dos componentes básicos, un
componente de red que recoge y analiza el tráfico de red a través
de un elemento integrado y un componente que a pesar de ser
diferente de las máquinas finales opera a nivel local.
En la mayor parte de los casos, los servidores
protegidos son máquinas de producción cuya configuración no está
adaptada para ser modificada y que no están adaptadas para realizar
instalaciones de nuevos componentes de software, precisamente para
evitar la inestabilidad del sistema.
Por consiguiente, la disposición aquí descrita
crea un entorno de prueba en el cual se replican los servicios y
las configuraciones de las máquinas de la red interna. El entorno de
pruebas permite que se compruebe el efecto de cada posible
fragmento de comunicación (por ejemplo un paquete) antes de que
llegue definitivamente al servicio real. En el caso de que se
encuentre al paquete como no malicioso, se redirige hacia las
máquinas de la red interna. En caso contrario es bloqueado. De esta
manera se proporciona una arquitectura para la prevención de
intrusiones que se caracteriza porque los ataques son detectados y
bloqueados antes de que puedan llegar al destino, reduciendo de
esta manera significativamente el número de falsas alarmas positivas
de manera que los paquetes son bloqueados solo después de comprobar
si son verdaderamente peligrosos. Además, la disposición aquí
descrita es también efectiva para detectar ataques no conocidos, es
decir, aquellos ataques para los cuales no existe una pauta de
detección disponible.
Específicamente, el diagrama de bloques de la
figura 4 muestra una red interna 130 separada de la red externa 110
por medio de un componente integrado 410. Ese componente incluye 4
interfaces de red, dos de las cuales (las indicadas como 411a y
411b) operan al nivel 2, permitiendo al dispositivo operar como un
puente a la vez que mantiene la invisibilidad al nivel de red y
monitoriza todo el tráfico en tránsito con origen y destino en la
red interna 130.
Una tercera interfaz, 411c, proporciona la
gestión del sistema mientras que la interfaz 411d conecta el
componente integrado al entorno de pruebas 420.
El componente integrado analiza todo el tráfico
con origen y destino en la red interna 130. Por medio del
componente de detección de intrusiones 412b, detecta cada pauta
"ilegal" o "dañina" de tipo conocido (es decir, aquellos
fragmentos de comunicación cuyas pautas están contenidas en la base
de datos 415). En este caso, el sistema evita, a través del
componente firewall 412a, que el paquete peligroso en
particular atraviese el dispositivo y alcance el objetivo,
realizando de esta manera la acción de prevención de
intrusiones.
Por el contrario, el tráfico reconocido como
"legal" o "inofensivo" (por ejemplo aquellos fragmentos
de tráfico cuyas pautas de detección están contenidas en la base de
datos 416) puede atravesar el sistema integrado 410 y de esta
manera alcanzar los servidores en la red interna 130.
Cuando el componente integrado 410 recibe
paquetes que no son reconocidos como legales o ilegales a partir de
las pautas de detección contenidas en las bases de datos 415 y 416,
los paquetes en cuestión son redirigidos hacia el entorno de prueba
o entorno 410 a través del interfaz 411d.
El entorno de test 420 esta formado por una o
más máquinas de prueba 421 que replican los servidores o, con menor
preferencia, parte de los servidores (definitivamente, incluso un
solo servidor), en la red interna 130 y un sistema 422 adaptado
para verificar el estado y de esta manera conseguir detectar los
posibles ataques. En una implantación mínima, el sistema 422 puede
coincidir con el sistema de detección de intrusiones
"host-based" que se muestra en la figura
2.
Después de las pruebas, aquellos paquetes
considerados como legales son devueltos al componente integrado 410
que los redirige a los servidores en la red interna 130, mientras
que los paquetes ilegales son bloqueados.
El entorno de test está también conectado a la
red del sistema de gestión 414 para permitir actualizar la
información contenida en las bases de datos 415 y 416.
De manera más detallada, cada uno de los
paquetes es analizado a través de la acción conjunta de los módulos
de firewall 412a y en el módulo de detección de intrusiones
412b.
En primera instancia, el componente de
firewall 412a comprueba la naturaleza legal del paquete: esto
se realiza, por ejemplo, llevando a cabo el filtrado de paquetes
basado en la dirección y fuente y los puertos de destino mientras
se bloquean los paquetes que pueden ser ilegales. Posteriormente, el
módulo de detección de intrusiones 412b analiza los contenidos de
aplicación del paquete basándose en la base de datos 415, que
contiene pautas de ataques conocidas para ser bloqueadas, y la base
de datos 416, que contiene aquellas pautas incluidas en el tráfico
explícitamente
permitido.
permitido.
Si el componente 412b detecta un ataque, este es
bloqueado antes de que pueda llegar a los sistemas de la red
interna. Por el contrario, si un fragmento de tráfico explícitamente
permitido es detectado, a dicho tráfico se le permite atravesar el
sistema y alcanzar la red 130 a través de la interfaz 411b.
El resto del tráfico, que no es explícitamente
legal o explícitamente ilegal, se considera tráfico sospechoso.
Se apreciará que los sistemas del estado de la
técnica de las figuras 1 a 3 no tratan dicho tráfico
"sospechoso": en función del caso, esto se gestiona como legal,
y se le deja pasar, o ilegal y por ende bloqueado. Esta manera de
operar incrementa el riesgo de generar tanto falsas alarmas
negativas (tráfico ilegal que se trata como tráfico legal) como
falsas alarmas positivas (tráfico legal que se trata como tráfico
ilegal).
En cambio, la disposición de dispositivos
descrita se caracteriza porque el tráfico sospechoso se desvía
hacia el sistema de pruebas 420 a través de la interfaz 411d. Las
máquinas de test 421 reciben todo el tráfico sospechoso recogido
por el interfaz 411a y procesan cada paquete individual que se
encuentra en la misma tal como serían procesados por las máquinas
"reales" en la red interna 130.
En la práctica, el sistema 422 comprueba el
estado de las máquinas, detectando la intrusión al nivel del
detalle local (lo que seria irrealizable para un sensor basado en
red), a la vez que tiene la posibilidad de verificar el efecto de
cada paquete individual, e incluso un solo comando, en las propias
máquinas. De esta manera, todo el tráfico sospechoso es procesado
y, dependiendo del resultado de tal procesamiento, es finalmente
clasificado por el sistema de pruebas 422 como legal o ilegal, sin
posibilidad de error.
Si se encuentra que un paquete sospechoso es
legal, se redirige al componente integrado 410 del sistema, que lo
redirige al usuario final, que puede entonces proseguir la
comunicación. En cambio, si se encuentra que un paquete es ilegal,
no se envía al sistema integrado, ni se envía respuesta alguna de la
máquina de prueba 421 hacia la red externa 110. El paquete se
bloquea y la alarma correspondiente llega al operador a través del
sistema de gestión
417.
417.
Se puede apreciar que, haciendo uso de la
cooperación entre dos diferentes tipos de disposiciones de
detección de intrusiones, una del tipo de red 412b, incluida en el
elemento integrado 410, y un componente
host-based, integrado en el sistema de prueba
420, la disposición descrita supera las limitaciones intrínsecas de
los enfoques tradicionales tratando, por un lado el problema de las
falsas alarmas, mientras que, por el otro lado, resuelve el
problema relacionado con la naturaleza vulnerable al invasor de los
sistemas host-based.
La operación de la disposición mostrada en la
figura 4 se describirá haciendo referencia específicamente a los
diagramas de flujo de las figuras 5 y 6.
En la etapa 510, cada paquete recibido es
procesado por el elemento de firewall 412a, que opera al
nivel de red y transporte, por lo tanto, los datos de la cabecera
acerca de los niveles 3 y 4 son analizados en la etapa 520 para
comprobar la naturaleza legal del trafico con origen y destino en
ciertas direcciones y puertos IP específicos y pudiendo bloquear el
tráfico ilegal -en la etapa 521-.
Una vez realizado, en la etapa 530, el paquete
es analizado por el componente de detección de intrusiones 412b que
detecta ataques basándose en las pautas de detección contenidas en
la base de datos 415. Un ataque puede ser transportado por uno o
más paquetes de nivel 3 (por ejemplo el así llamado Ping de la
Muerte), de nivel cuatro (por ejemplo la inundación mediante SYN) y
al nivel de aplicación (por ejemplo los llamados "Buffer
Overflow").
Cuando se detecta un ataque, el paquete
correspondiente es bloqueado en la etapa 531 y no es redirigido
hacia la interfaz 411b. Por consiguiente, no llega a los servidores
en la red interna 130 mientras que la alarma correspondiente es
emitida en la etapa 532, que llega al administrador de red a través
del sistema de gestión 417.
Si no se detecta un ataque, se inicia un proceso
de comparación de pautas en la etapa 540 para comprobar la posible
legalidad explícita de los contenidos de aplicación del paquete. Las
pautas de detección están contenidas en las bases de datos 416 y
suelen ser pautas que muestran las pautas de peticiones legales que
los servidores reciben de sus clientes.
Por consiguiente, estas pautas son fuertemente
dependientes de los servicios de aplicación proporcionados por las
máquinas de la red interna 130. Si es explícitamente legal o
permitido, cada paquete individual se redirige a los servidores
finales en la etapa 541 a través del interfaz 411b. Los servidores
se encargan del procesado del paquete, que normalmente incluye la
emisión, en la etapa 542, de una respuesta hacia los clientes en la
red externa 110.
Si el paquete no corresponde a ninguna de las
pautas de detección en la base de datos 416 ni en la base de datos
415, entonces hay que tratar con un elemento desconocido que no es
ni explícitamente ilegal, ni explícitamente legal. Por lo tanto,
este paquete es tratado como un elemento sospechoso.
Específicamente, este tráfico sospechoso es
desviado hacia el sistema de test 420 a través de la interfaz 411d,
lo cual ocurre en la etapa 550. El entorno de test 420 recibe todos
los paquetes sospechosos y los trata tal como se muestra en la
figura 6.
Cada paquete recibido en la etapa 610 es
procesado por las máquinas de prueba 421 en la etapa 620.
Específicamente, las máquinas de prueba 421 replican a los
servidores en la red interna 130: un sistema de prueba 422, el
cual, como ha sido indicado, podría corresponder en una instalación
mínima a un sistema de detección de intrusiones basado en
host mostrado en la figura 2, comprueba el estado de las
máquinas 421 para detectar la posible intrusión en la etapa 630. El
sistema de detección 422 opera en el detalle del nivel local, o
cada comando individual, de las propias máquinas.
Si se encuentra que un paquete sospechoso es
legal, en la etapa 640 se redirige, a través de la interfaz 411d,
al componente integrado 410 del sistema que a su vez lo reenvía a
los sistemas finales en la red interna 130. Por lo tanto, estos
pueden continuar, en la etapa 641, la comunicación con los clientes
en la red externa 110. De forma alternativa, el paquete puede ser
redirigido al componente integrado 410 a través de la red de
gestión 414.
En cambio, si se encuentra que el paquete
sospechoso es ilegal, en la etapa 631 se bloquea, de manera que no
es redirigido al componente integrado ni se envía ninguna respuesta
posible desde las máquinas de prueba 421 a la red externa 110.
Además, se lleva a cabo un conjunto de acciones
independientes en paralelo desde la etapa 632 al 635.
En primer lugar, se genera una alarma en la
etapa 632, que alcanza al administrador de la red a través del
sistema de administración 417.
Las máquinas de prueba que pueden estar
comprometidas se restablecen mediante una acción de reset en la
etapa 633. Tal paso puede consistir, por ejemplo, en la restauración
de una partición en un disco basada en una imagen que ha sido
previamente generada y almacenada en el sistema 422, el cual,
controlando las máquinas de prueba, gestiona el entorno completo
420. Además, recurriendo a técnicas tradicionales, se puede llevar
a cabo la cancelación de la sesión establecida en la etapa 634 una
vez que se ha establecido la naturaleza ilegal de la
comunicación.
La disposición descrita ejecuta un paso 635
consistente en actualizar las reglas contenidas en la base de datos
415. Esto tiene como objetivo mejorar progresivamente la efectividad
de la detección. Una vez comprobada la naturaleza peligrosa de un
flujo de tráfico dado, el sistema de prueba puede revisar las reglas
contenidas en la base de datos 415 que rigen el comportamiento del
componente integrado 410 en el sistema de tal manera que, si dicho
flujo de tráfico se manifiesta de nuevo, es inmediatamente
bloqueado, sin ser redirigido a los sistemas de prueba.
Además, el sistema puede incluir un mecanismo
para transmitir, en un paso 636, la información de actualización
hacia otros sistemas, posiblemente de tipo tradicional, de tal
manera que estos sistemas puedan explotar las nuevas pautas de
detección para intrusiones. De esta manera, se implementa un
acercamiento efectivo para generar automáticamente pautas de
detección en presencia de nuevos ataques.
De la misma manera, si se encuentra que el
paquete es legal, en un paso 650 se actualizan de manera similar
las reglas de la base de datos 416.
Esta sinergia entre el componente basado en host
y el componente integrado del sistema, que lleva a una mejor
efectividad en la detección, se lleva a cabo por medio de la red de
gestión 414, hacia la cual llegan tanto el sistema de prueba 422
como el componente integrado 416.
De esta manera, el sistema descrito solo emite
alarmas, en las etapas 532 y 632, en caso de intrusión real, es
decir, solo en presencia de paquetes que, atravesando el
firewall 412a, habrían llegado a los sistemas en la red
interna 130 con posibilidad de afectar negativamente su
operación.
Esta acción de señalización tiene un valor
puramente informativo, ya que cualquier ataque peligroso ya ha sido
bloqueado por los componentes en el sistema, ya sea por el
componente integrado 410 o bien por el entorno de prueba 420.
De hecho, las máquinas en la red interna 130
solo reciben tráfico que:
- en la etapa 541, se considera explícitamente
legal ya que sus pautas de detección están contenidas en la base de
datos 416, o
- ha sido comprobada positivamente sin causar
ningún daño en las máquinas de prueba en la etapa 640.
De esta manera e evita que el tráfico peligroso
alcance la red interna, y por lo tanto se logra una situación de
prevención de intrusiones.
En resumen, todo el tráfico desde y hacia la red
interna 130 es analizado en el sistema, en el componente integrado
410 y, si puede ser, en el componente basado en host
integrado en el sistema de prueba 420.
Un ataque es reconocido y bloqueado por el
componente integrado 410 (si su pauta de detección se encuentra en
la base de datos 415) o por el sistema de prueba 420 (que a su vez
actualiza la base de datos 415 de pautas de detección).
En cambio, el tráfico legal es reconocido por el
componente integrado (si se permite explícitamente por una política
en la base de datos 416), o si no, atraviesa el sistema de prueba
antes de llegar al servidor de destino. También en este último
caso, el mecanismo de auto actualización de las políticas en la base
de datos 416 incrementa la efectividad de la detección ya que
reduce los casos de tráfico sospechoso desviados hacia el sistema
de prueba.
De hecho, el sistema trata como tráfico
sospechoso para ser desviado hacia el sistema de prueba 420 todos
aquellos paquetes o comandos que no están explícitamente prohibidos
o explícitamente permitidos dependiendo de las reglas de las bases
de datos 415 y 416.
Estos son ataques típicos cuyo resultado solo
puede preverse a nivel local. Este es el caso, por ejemplo, de:
- ataques que no comprometen puntos realmente
vulnerables de las máquinas finales o que los servidores finales
están en situación de evitar al estar dotados de los parches
adecuados y que habrían generado falsas alarmas con toda
probabilidad,
- ataques que no son todavía conocidos y que
solo se pueden detectar mediante pruebas reales llevadas a cabo en
las máquinas individuales, o fragmentos de tráfico, de cualquier
nivel, que no pueden ser reconstruidos correctamente, evitando de
esta manera los problemas de evasión e inserción descritos
anteriormente, si no es trabajando a nivel local en una máquina
específica.
Se puede apreciar que el problema de
fragmentación antes descrito, refiriéndose principalmente al nivel
3 y a un flujo TCP, también existe al nivel de aplicación. En este
nivel, el fragmento de comunicación elemental o unidad es el
comando individual y este puede también puede disponerse de manera
que efectúe un ataque. Típicamente, un comando de aplicación está
contenido en un solo paquete pero, si este no fuera el caso, el
sistema de detección de intrusiones debe poder reconstruirlo de la
manera correcta para detectar posibles ataques en el mismo.
Un ejemplo muy simple de fragmentación al nivel
de aplicación se presenta mediante un protocolo genérico de tipo
texto como HTTP o SMTP. Por lo general, la interacción con el
servidor web o el servidor de correo se lleva a cabo enviando
cadenas completas de comandos en un solo paquete. Esto incrementa
significativamente la eficiencia de la red. Sin embargo, es posible
usar varios paquetes independientes para enviar la misma petición.
Por ejemplo, cada vez que un atacante consulta directamente al
servidor web o al servidor de correo con una herramienta
interactiva (por ejemplo TELNET) el paquete enviado al servidor se
fragmenta en varios paquetes, cada uno de ellos conteniendo un solo
carácter, ya que esta es la lógica actualmente usada por las
aplicaciones interactivas. Si el sistema de detección de intrusiones
no está en la posición de reconstruir la conversación completa y
solo puede efectuar la detección de pautas al nivel de un solo
paquete, una manipulación de este tipo sería suficiente para
invalidar el mecanismo de detección.
Por ejemplo, la siguiente petición HTTP explota
una vulnerabilidad reconocida del programa phf para acceder al
fichero de contraseñas de un sistema Unix:
GET
/cgi-bin/phf?Qalias=x%Oalbin/cat%20/etc/passwd
Si se usa una herramienta interactiva para
insertar dicha petición, se generan 50 (cincuenta) paquetes
separados, incluyendo cada uno un solo carácter. El sistema de
detección de intrusiones solo puede detectar este ataque
reconstruyendo completamente el flujo de datos. Para realizarlo, en
cualquier caso, el sistema de detección de intrusiones debe ser
capaz de entender cuando finaliza una petición. Además, es necesario
registrar las secciones activas y usar temporizadores para evitar
que se agoten los recursos requeridos para registrar todas las
conversaciones separadas. Además, cada vez que se reconstruyen los
flujos de tráfico, el sistema de detección de intrusiones se expone
a los problemas de evasión e inserción antes descritos.
Un sistema de detección de intrusiones no es
capaz de cubrir este problema de manera efectiva.
En cambio, la disposición aquí descrita tiene la
ventaja de que el tráfico no es reconstruido por el sensor ya que
la acción de reconstrucción se realiza por el sistema de prueba 420.
De hecho, todo el tráfico no explícitamente prohibido, o
explícitamente permitido por las políticas de la base de datos 415 y
416 es tratado como sospechoso y desviado hacia el sistema de
prueba 420.
Por consiguiente, si el comando del que se
informa anteriormente se fragmenta en 50 paquetes, el primer
paquete, incluyendo el carácter individual G, no puede ser resuelto
correctamente y es redirigido al sistema de prueba 420.
El paquete individual no contiene ninguna carga
ilegal, ni puede comprometer a la máquina de prueba 421. Por
consiguiente, el sistema 422 lo redirige al sistema final sin
riesgo. De manera similar, cada paquete individual incluido en el
comando completo es redirigido por el componente integrado 410 hacia
el sistema de prueba 421; el sistema de detección 422 comprueba la
naturaleza de los paquetes individuales y los redirige hacia los
sistemas finales.
Cuando el sistema de detección 422 detecta la
naturaleza peligrosa del comando que esta siendo formado interrumpe
inmediatamente su flujo. Esto puede ocurrir, por ejemplo, cuando
aparece la cadena cgi-bin/phf incluida en
una pauta de detección.
En consecuencia, el sistema mantiene también su
efectividad en el caso en que la naturaleza "desconocida" del
ataque reside en que tal ataque es enviado en un intento de
evasión/inserción por ejemplo fragmentándolo en una pluralidad de
paquetes/fragmentos que en si mismos son "inocentes". Como se
muestra en el ejemplo considerado, la naturaleza peligrosa del
comando se descubre siempre cuando el último paquete (el 51) es
enviado incluyendo el carácter ENTER, iniciada la ejecución de
comando completo.
En ese punto, el sistema de detección de
intrusiones 422 del entorno de pruebas detecta el comportamiento
anómalo del sistema 421 que intenta acceder al fichero de
contraseñas, identifica tal comportamiento como ilegal y por
consiguiente bloquea la transmisión del paquete 51 hacia los
sistemas finales. De esta manera, se evita la ejecución del comando
y el ataque deja de ser relevante.
Además, se puede emitir una alarma para poner en
evidencia el peligro evitado y la actualización de la base de datos
415 para permitir que el componente integrado 416 detecte el comando
en el futuro (si se envía en un solo paquete) y se bloquee
automáticamente su transmisión.
De esta manera, el comando peligroso no se
ejecuta en los sistemas finales de la red interna 130, y la
comunicación con el usuario peligroso es interrumpida por medio del
medio tradicional de cancelar la sesión mientras que la sesión
actual interrumpida es destruida por los temporizadores de
aplicación.
El mecanismo de retransmisión descrito lleva a
que las máquinas de prueba 421 nunca proporcionen una respuesta a
las peticiones de los usuarios ya que no existe comunicación desde
el sistema de prueba 420 hacia la red externa 110. En la práctica,
esto significa que las máquinas de prueba 421 en el entorno de
prueba 420 tienen restringida la capacidad de proporcionar
respuestas al tráfico: de hecho, la comunicación con los usuarios
solamente se cierra en los servidores de la red interna.
Asimismo, la disposición aquí descrita se adapta
para operar también en fragmentos de comunicación tomados del
tráfico de salida del conjunto de máquinas que comprenden la red
interna 130 para redirigir cada fragmento de tráfico desconocido
hacia el entorno de test 420.
Estas provisiones llevan a mejorar todavía más
la seguridad contra aquellos ataques que puedan necesitar algún
tipo de información que provenga de la red interna 130 y/o la
posibilidad de interceptar respuestas desde los servidores en la
red 130 para mantener la sincronización al nivel TCP.
Aquellos con conocimiento de la técnica
apreciarán rápidamente que no es necesario que las máquinas de
prueba 420 sean una copia completa y absoluta de las máquinas
(servidores) en la red interna 130. Esencialmente, las máquinas de
test 420 reproducen la configuración de software de los servidores
en la red interna solo hasta, por ejemplo, el sistema operativo,
las versiones de software usadas y los servicios ofrecidos
relevantes. Con esto, las intrusiones pueden ser detectadas
adecuadamente.
Sin embargo, no es necesario que las máquinas de
prueba 420 reproduzcan completamente los servidores en la red
interna 130 hasta el punto de que los contenidos de la aplicación
sean relevantes.
El mecanismo que acaba de ser descrito es
especialmente adecuado para ser aplicado cuando la red interna 130
está compuesta de máquinas que ofrecen servicios homogéneos. Esto
facilita el establecimiento del entorno de prueba 420 y hace que la
detección sea bastante efectiva desde el inicio.
Esta es la situación actual en las así llamadas
granjas de servidores o en los departamentos de procesado de datos
de grandes compañías. Allí, con el objetivo de permitir una gestión
más fácil y más efectiva, tanto en términos de actualización de
software como en términos de gestión general, hay una tendencia a
agrupar en áreas comunes aquellas máquinas que ofrezcan servicios
homogéneos o que exhiban una configuración de software similar.
Implantando el mecanismo de retransmisión
descrito al nivel de un paquete individual, también se resuelve
completamente el problema de una fragmentación tanto al nivel 3 como
al nivel de aplicación, tal como se describe en el ejemplo
anterior.
Con el objetivo de ser totalmente seguro frente
a los problemas relacionados con las fragmentaciones al nivel de
flujo TCP, todas las sesiones son preferiblemente trazadas,
desviando hacia el sistema de prueba cualquier paquete TCP, es
decir aquellos dirigidos hacia la red interna 130 y que vengan de la
interfaz 411a y las respuestas correspondientes proporcionadas por
los servidores de la red 130, transmitidas por la interfaz 411b. De
esta manera, el entorno de test 420 puede registrar todas las
sesiones activas en los sistemas finales estando perfectamente
actualizado con respecto al estado del sistema.
Aquellos ataques que explotan las situaciones de
evasión e inserción en los niveles TCP son muy difíciles de
implantar. En consecuencia, el entorno de prueba 420 puede no
necesitar incluir recursos de muy alto nivel necesarios para
detectar ataques de este tipo tan improbable. En consecuencia, se
debe alcanzar un equilibrio razonable ajustando los mecanismos de
desvío del tráfico hacia el entorno de test de manera que se eviten
dichas intervenciones tan costosas y sin expectativas de ser
necesarias.
Por supuesto, sin perjuicio de los principios
subyacentes de la invención, los detalles de la realización pueden
variar, incluso apreciablemente, con referencia a lo que ha sido
descrito solamente a partir de un ejemplo, sin separarse del ámbito
de la invención tal como está definida en las reivindicaciones
anexas.
Claims (36)
1. Procedimiento para prevenir intrusiones en el
tráfico de comunicaciones con un conjunto (130) de máquinas en una
red, comprendiendo dicho tráfico fragmentos de comunicación, en el
cual el procedimiento incluye las etapas de:
- proveer un sistema de prueba (420) que incluye
(421) la replicación de al menos una de dichas máquinas en dicho
conjunto (130),
- dirigir al menos parte de dichos fragmentos de
comunicación en dicho tráfico hacia el sistema de prueba (420),
- ejecutar dichos fragmentos de comunicación
dirigidos hacia el sistema de prueba (420) en dichos servicios de
prueba (421) para detectar posibles efectos adversos en dicho
sistema de prueba (420), y
i) en presencia de un efecto adverso bloquear
los fragmentos de tráfico que producen dicho efecto adverso, y
ii) en ausencia de un efecto adverso, permitir
la comunicación con dicho conjunto (130) de máquinas a los
fragmentos de comunicación que no producen dicho efecto adverso.
2. Procedimiento según la reivindicación 1,
caracterizado por el hecho de que los mencionados fragmentos
de comunicación o al menos parte de ellos dirigidos hacia dicho
sistema de prueba (420) incluyen fragmentos de comunicación del
tráfico dirigido hacia dicho conjunto (130) de máquinas.
3. Procedimiento según la reivindicación 1,
caracterizado por el hecho de que los mencionados fragmentos
de comunicación o al menos parte de ellos dirigidos hacia dicho
sistema de prueba (420) incluyen fragmentos de comunicación del
tráfico dirigido desde dicho conjunto (130) de máquinas.
4. Procedimiento según la reivindicación 1,
caracterizado por el hecho de que comprende las etapas
de:
- proveer una base de datos (415) que incluye
pautas representativas de fragmentos de comunicación prohibidos en
la comunicación con dicho conjunto de máquinas (130),
- bloquear (412a) los fragmentos de comunicación
prohibidos en dicho trafico al ser identificados por las pautas
respectivas en dicha base de datos (415).
5. Procedimiento según la reivindicación 1,
caracterizado por el hecho de que incluye las etapas de:
- proveer una base de datos (416) adicional que
incluya pautas representativas de fragmentos de tráfico permitidos
en la comunicación con dicho conjunto de máquinas (130),
- permitir la comunicación de fragmentos de
tráfico permitidos en dicho tráfico al ser identificado por las
pautas respectivas en dicha base de datos (416) adicional.
6. Procedimiento según la reivindicación 4,
caracterizado por el hecho de que incluye las etapas de:
- detectar fragmentos de comunicación
desconocidos en dicho tráfico identificados por pautas desconocidas
no incluidas en dicha base de datos (415), y
- dirigir dichos fragmentos de tráfico
desconocidos en dicho tráfico identificados por pautas desconocidas
no incluidas en dicha base de datos (415) hacia dicho sistema de
prueba (420) para ser ejecutados en dichos servicios de prueba
(421) para detectar posibles efectos adversos en dichos sistemas de
prueba (420).
7. Procedimiento según la reivindicación 6,
caracterizado el hecho de que incluye, en presencia de dicho
efecto adverso, la etapa de añadir a dicha base de datos (415) la
pauta respectiva que identifica el fragmento de comunicación que
lleva a dicho efecto adverso.
8. Procedimiento según la reivindicación 5,
caracterizado por el hecho de que incluye las etapas de:
- detectar fragmentos de tráfico desconocidos en
dicho tráfico por no encontrarse la pauta respectiva en dicha base
de datos (416) adicional, y
- dirigir dichos fragmentos de tráfico
desconocidos en dicho tráfico por no encontrarse la pauta respectiva
en dicha base de datos (416) adicional hacia dichos sistemas de
prueba (420) para ser ejecutados en dichos servicios de prueba
(421) para detectar efectos posiblemente adversos en dicho sistema
de prueba (420).
9. Procedimiento según la reivindicación 8,
caracterizado por el hecho de que incluye, en ausencia de
dicho efecto adverso, la etapa de añadir a la base de datos
adicional (416) dicha pauta respectiva que identifique al fragmento
de comunicación que no lleve a dicho efecto adverso.
10. Procedimiento según la reivindicación 1,
caracterizado por el hecho de que incluye, en la presencia de
dicho efecto adverso, la etapa de someter a una etapa de reset
aquellos de dichos servicios de prueba (421) en dichos sistemas de
prueba (420) afectados por dichos efectos adversos.
11. Procedimiento según la reivindicación 1,
caracterizado por el hecho de que, las máquinas en el
conjunto mencionado (130) incluyendo los servicios expuestos a
dicho efecto adverso además de contenido adicional, incluye la
etapa de configurar dichos servicios de prueba (421) con el objetivo
de replicar dichos servicios expuestos a dicho efecto adverso en
las máquinas de dicho conjunto (130).
12. Procedimiento según la reivindicación 1,
caracterizado por el hecho de que incluye la etapa de evitar
que dichas máquinas de prueba (421) en dichos sistema de pruebas
(420) proporcionen respuestas a dicho tráfico.
13. Procedimiento según la reivindicación 1,
caracterizado por el hecho de que incluye las etapas de:
- proveer un componente integrado (410) que
asegura dicho tráfico con dicho conjunto de máquinas (130), y
- proveer al menos una interfaz (411d) que
conecta dicho componente integrado (410) con dicho sistema de prueba
(420).
14. Procedimiento según la reivindicación 13,
caracterizado por el hecho de que incluye la etapa de
proporcionar retroalimentación de dicho sistema de prueba (420) a
dicho componente integrado (410) a través de dicha interfaz
(411d).
15. Procedimiento según la reivindicación 13,
caracterizado por el hecho de que incluye las etapas de:
- proporcionar una red de gestión (414) para
administrar dicho sistema de prueba (420) y
- proveer retroalimentación de dicho sistema de
prueba (420) a dicho componente integrado (410) a través de dicha
red de gestión.
16. Procedimiento según la reivindicación 7,
caracterizado por el hecho de que incluye las etapas de:
- proveer una disposición de prevención de
intrusiones en paralelo que incluye su base de datos respectiva
incluyendo pautas representativas de los respectivos fragmentos de
comunicaciones prohibidos para la comunicación con el conjunto de
máquinas respectivas,
- en presencia de dicho efecto adverso,
transmitir a dicha disposición de prevención de intrusiones en
paralelo, para su inclusión de dichas bases de datos respectivas,
las pautas respectivas que identifican los fragmentos de tráfico
que provocan dicho efecto adverso.
17. Procedimiento según la reivindicación 9,
caracterizado por el hecho de que incluye las etapas de:
- proveer una disposición de prevención de
intrusiones en paralelo que incluye su base de datos respectiva
incluyendo pautas representativas de los respectivos fragmentos de
comunicaciones permitidos para la comunicación con el conjunto de
máquinas respectivas,
- en ausencia de dicho efecto adverso,
transmitir a dicha disposición de prevención de intrusiones en
paralelo, para su inclusión de dichas bases de datos respectivas,
las pautas respectivas que identifican los fragmentos de tráfico
que no producen dicho efecto adverso.
18. Sistema para prevenir intrusiones en el
tráfico de las comunicaciones con un conjunto (130) de máquinas en
una red, incluyendo dicho tráfico los fragmentos de comunicaciones,
comprendiendo dicho sistema:
- un sistema de prueba (420) que incluye
servicios de prueba (421) que replican al menos una de dichas
máquinas en dicho conjunto (130),
- un modulo de comunicaciones (410) configurado
para dirigir al menos parte de dichos fragmentos de tráfico hacia
el sistema de prueba (420), en el que dichos fragmentos de
comunicación dirigidos hacia dicho sistema de prueba (420) están
adaptados para ser ejecutados en dichos servicios de prueba (421)
para detectar posibles efectos adversos en dicho sistema de prueba
(420), estando además dicho sistema de comunicación (410)
configurado
para:
para:
i) en presencia de un efecto adverso, bloquear
los fragmentos de comunicación que provocan dicho efecto adverso,
y
ii) en ausencia de un efecto adverso, permitir
la comunicación con dicho conjunto (130) de máquinas para los
fragmentos de comunicación que no provocan dicho efecto adverso.
19. Sistema según la reivindicación 18,
caracterizado por el hecho de que dicho modulo de
comunicación (410) está configurado para incluir al menos parte de
dichos fragmentos de comunicación dirigidos hacia dicho sistema de
pruebas (420) fragmentos de tráfico del trafico dirigido hacia dicho
conjunto (130) de máquinas.
20. Sistema según la reivindicación 18,
caracterizado por el hecho de que dicho módulo de
comunicación (410) está configurado para incluir al menos parte de
dichos fragmentos dirigidos hacia dicho sistema de prueba (420)
fragmentos de comunicación del tráfico proveniente de dicho conjunto
(130) de máquinas.
21. Sistema según la reivindicación 18,
caracterizado por el hecho de que incluye:
- una base de datos (415) que incluye pautas
representativas de fragmentos de comunicación prohibidos en la
comunicación en dicho conjunto de máquinas (130),
- un modulo de firewall (412a)
configurado para bloquear fragmentos de tráfico prohibidos en dicho
tráfico al ser identificados por las pautas respectivas incluidas
en dicha base de datos (415).
22. Sistema según la reivindicación 18,
caracterizado por el hecho de que incluye:
- una base de datos adicional (416) que incluye
pautas representativas de fragmentos de comunicación permitidos en
la comunicación con dicho conjunto de máquinas (130),
- dicho módulo de comunicaciones (410)
configurado para permitir a los fragmentos de tráfico en dicho
tráfico identificados por las pautas respectivas incluidas en dicha
base de datos adicional (416).
23. Sistema según la reivindicación 21,
caracterizado porque dicho modulo de comunicaciones (410)
está configurado para:
- detectar fragmentos de tráfico de
comunicaciones desconocidas en dicho tráfico identificados por ser
pautas desconocidas no incluidas en dicha base de datos (415),
y
- dirigir dichos fragmentos de tráfico de
comunicaciones en dicho tráfico identificados por ser pautas
desconocidas no incluidas en dicha base de datos (415), hacia dicho
sistema de pruebas (420) para ser ejecutado en dichos servicios de
prueba (421) para detectar posibles efectos adversos en dicho
sistema de pruebas (420).
24. Sistema según la reivindicación 23,
caracterizado por el hecho de que dicho módulo de
comunicaciones (410) está configurado para añadir a dicha base de
datos (415), en presencia de dicho efecto adverso, la pauta
respectiva que identifica el fragmento de tráfico de comunicaciones
que provoca dichos efectos adversos.
25. Sistema según la reivindicación 22,
caracterizado por el hecho de que dicho módulo (410) está
configurado para:
- detectar fragmentos de tráfico de
comunicaciones desconocidos en dicho tráfico identificados por ser
pautas desconocidas no incluidas en dicha base de datos (416),
y
- dirigir dichos fragmentos de tráfico de
comunicaciones en dicho tráfico identificados por ser pautas
desconocidas no incluidas en dicha base de datos adicional (416),
hacia dicho sistema de pruebas (420) para ser ejecutado en dichos
servicios de prueba (421) para detectar posibles efectos adversos en
dicho sistema de pruebas (420).
26. Sistema según la reivindicación 25,
caracterizado por el hecho de que dicho módulo de
comunicaciones (410) está configurado para añadir en dicha base de
datos adicional (416), en ausencia de dicho efecto adverso, la
pauta respectiva que identifica el fragmento de tráfico de
comunicaciones que no provoca dichos efectos adversos.
27. Sistema según la reivindicación 18,
caracterizado por el hecho de que dichos servicios de prueba
(421) en dicho sistema de pruebas (420) están configurados para
serles efectuado un reset si se produce dicho efecto adverso.
28. Sistema según la reivindicación 18,
caracterizado por el hecho de que las máquinas en dicho
conjunto (130) incluyen servicios expuestos a dicho efecto adverso
así como contenido adicional, mientras que dichos servicios de
prueba (421) replican dichos servicios expuestos a dicho efecto
adverso en las máquinas en dicho conjunto
(130).
(130).
29. Sistema según la reivindicación 18,
caracterizado por el hecho de que las máquinas de pruebas
(421) en dicho sistema de pruebas (420) tienen restringida la
capacidad de proporcionar respuestas a dicho tráfico.
30. Sistema según la reivindicación 18,
caracterizado por el hecho de que incluye:
- un componente integrado en dicho modulo de
comunicaciones (410) que asegura dicho tráfico con dicho conjunto
de máquinas (130), y
- al menos una interfaz (411d) que comunica
dicho componente integrado (410) con dicho sistema de pruebas
(420).
31. Sistema según la reivindicación 30,
caracterizado por el hecho de que dicho sistema de pruebas
(420) esta configurado para proporcionar retroalimentación a dicho
componente integrado (410) a través de al menos uno de dichas
interfaces (411d).
32. Sistema según la reivindicación 30,
caracterizado por el hecho de que dicho sistema incluye una
red de gestión (414) para administrar dicho sistema de pruebas
(420) y por el hecho de que dicho sistema de pruebas (420) está
configurado para proporcionar retroalimientación a dicho componente
integrado (410) a través de dicha red de gestión.
33. Sistema según la reivindicación 24,
caracterizado por el hecho de que incluye asociada una
disposición de prevención de intrusiones en paralelo que incluye
una base de datos respectiva la cual incluye pautas representativas
de los fragmentos de comunicación prohibidos respectivos para la
comunicación con un conjunto respectivo de máquinas y por el hecho
de que dicho modulo de comunicaciones (410) está configurado para
transmitir en presencia de dicho efecto adverso, a dicha
disposición de prevención de intrusiones asociada en paralelo, para
la inclusión en dicha base de datos respectiva, la pauta respectiva
que identifica el fragmento de tráfico de comunicaciones que lleva
a dicho efecto adverso.
34. Sistema según la reivindicación 25,
caracterizado por el hecho de que incluye asociada una
disposición de prevención de intrusiones en paralelo que incluye
una base de datos respectiva la cual incluye pautas representativas
de los fragmentos de comunicación prohibidos respectivos para la
comunicación con un conjunto respectivo de máquinas y por el hecho
de que dicho modulo de comunicaciones (410) está configurado para
transmitir en ausencia de dicho efecto adverso, a dicha disposición
de prevención de intrusiones asociada en paralelo, para la inclusión
en dicha base de datos adicional respectiva, la pauta respectiva
que identifica el fragmento de tráfico de comunicaciones que lleva
a dicho efecto adverso.
35. Red de telecomunicaciones (110, 130) que
incluye el sistema de cualquiera de las reivindicaciones 18 a
34.
36. Producto programa de ordenador, que se puede
cargar en la memoria de al menos un ordenador y que incluye módulos
de programa para ejecutar las etapas del procedimiento de cualquiera
de las reivindicaciones 1 a 17.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/EP2003/012090 WO2005050414A1 (en) | 2003-10-30 | 2003-10-30 | Method and system for intrusion prevention and deflection, |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2282739T3 true ES2282739T3 (es) | 2007-10-16 |
Family
ID=34610011
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03819020T Expired - Lifetime ES2282739T3 (es) | 2003-10-30 | 2003-10-30 | Procedimiento y sistema para la prevencion y el rechazo de intrusiones. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US8356349B2 (es) |
| EP (1) | EP1678567B1 (es) |
| AT (1) | ATE355553T1 (es) |
| AU (1) | AU2003304558A1 (es) |
| BR (1) | BR0318587A (es) |
| DE (1) | DE60312235T2 (es) |
| ES (1) | ES2282739T3 (es) |
| WO (1) | WO2005050414A1 (es) |
Families Citing this family (39)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8839417B1 (en) | 2003-11-17 | 2014-09-16 | Mcafee, Inc. | Device, system and method for defending a computer network |
| US7555777B2 (en) * | 2004-01-13 | 2009-06-30 | International Business Machines Corporation | Preventing attacks in a data processing system |
| EP1751957A1 (fr) * | 2004-05-10 | 2007-02-14 | France Télécom | Suppression de fausses alertes parmi les alertes issues de sondes de detection d'intrusions d'un systeme d'informations surveille |
| US20060015715A1 (en) * | 2004-07-16 | 2006-01-19 | Eric Anderson | Automatically protecting network service from network attack |
| US7562389B1 (en) * | 2004-07-30 | 2009-07-14 | Cisco Technology, Inc. | Method and system for network security |
| US7555774B2 (en) * | 2004-08-02 | 2009-06-30 | Cisco Technology, Inc. | Inline intrusion detection using a single physical port |
| US7600257B2 (en) * | 2004-10-13 | 2009-10-06 | Sonicwall, Inc. | Method and an apparatus to perform multiple packet payloads analysis |
| US7835361B1 (en) | 2004-10-13 | 2010-11-16 | Sonicwall, Inc. | Method and apparatus for identifying data patterns in a file |
| US7647430B2 (en) * | 2005-01-19 | 2010-01-12 | Microsoft Corporation | Remote command framework for devices |
| US7725938B2 (en) * | 2005-01-20 | 2010-05-25 | Cisco Technology, Inc. | Inline intrusion detection |
| US7765183B2 (en) * | 2005-04-23 | 2010-07-27 | Cisco Technology, Inc | Hierarchical tree of deterministic finite automata |
| US8863286B1 (en) | 2007-06-05 | 2014-10-14 | Sonicwall, Inc. | Notification for reassembly-free file scanning |
| US8336108B2 (en) * | 2007-06-22 | 2012-12-18 | Red Hat, Inc. | Method and system for collaboration involving enterprise nodes |
| US8127290B2 (en) * | 2007-06-22 | 2012-02-28 | Red Hat, Inc. | Method and system for direct insertion of a virtual machine driver |
| US8191141B2 (en) | 2007-06-22 | 2012-05-29 | Red Hat, Inc. | Method and system for cloaked observation and remediation of software attacks |
| US8429748B2 (en) | 2007-06-22 | 2013-04-23 | Red Hat, Inc. | Network traffic analysis using a dynamically updating ontological network description |
| US8539570B2 (en) | 2007-06-22 | 2013-09-17 | Red Hat, Inc. | Method for managing a virtual machine |
| US9727440B2 (en) | 2007-06-22 | 2017-08-08 | Red Hat, Inc. | Automatic simulation of virtual machine performance |
| US9354960B2 (en) | 2010-12-27 | 2016-05-31 | Red Hat, Inc. | Assigning virtual machines to business application service groups based on ranking of the virtual machines |
| US8984504B2 (en) | 2007-06-22 | 2015-03-17 | Red Hat, Inc. | Method and system for determining a host machine by a virtual machine |
| US9569330B2 (en) | 2007-06-22 | 2017-02-14 | Red Hat, Inc. | Performing dependency analysis on nodes of a business application service group |
| US8949827B2 (en) | 2007-06-22 | 2015-02-03 | Red Hat, Inc. | Tracking a virtual machine |
| US9477572B2 (en) | 2007-06-22 | 2016-10-25 | Red Hat, Inc. | Performing predictive modeling of virtual machine relationships |
| US9678803B2 (en) | 2007-06-22 | 2017-06-13 | Red Hat, Inc. | Migration of network entities to a cloud infrastructure |
| US7991723B1 (en) | 2007-07-16 | 2011-08-02 | Sonicwall, Inc. | Data pattern analysis using optimized deterministic finite automaton |
| US8074278B2 (en) * | 2007-09-14 | 2011-12-06 | Fisher-Rosemount Systems, Inc. | Apparatus and methods for intrusion protection in safety instrumented process control systems |
| US8325753B1 (en) * | 2008-06-10 | 2012-12-04 | Meru Networks | Selective suppression of 802.11 ACK frames |
| US8813221B1 (en) | 2008-09-25 | 2014-08-19 | Sonicwall, Inc. | Reassembly-free deep packet inspection on multi-core hardware |
| US9871807B2 (en) * | 2009-06-12 | 2018-01-16 | Microsoft Technology Licensing, Llc | Generic protocol decoder for generic application-level protocol signatures |
| US9769149B1 (en) | 2009-07-02 | 2017-09-19 | Sonicwall Inc. | Proxy-less secure sockets layer (SSL) data inspection |
| US8151341B1 (en) * | 2011-05-23 | 2012-04-03 | Kaspersky Lab Zao | System and method for reducing false positives during detection of network attacks |
| US9794275B1 (en) * | 2013-06-28 | 2017-10-17 | Symantec Corporation | Lightweight replicas for securing cloud-based services |
| US9009782B2 (en) * | 2013-08-19 | 2015-04-14 | Freescale Semiconductor, Inc. | Steering traffic among multiple network services using a centralized dispatcher |
| US9342415B2 (en) | 2014-07-14 | 2016-05-17 | International Business Machines Corporation | Run-to-completion thread model for software bypass fail open for an inline intrusion protection system |
| US10419452B2 (en) | 2015-07-28 | 2019-09-17 | Sap Se | Contextual monitoring and tracking of SSH sessions |
| US10015178B2 (en) | 2015-07-28 | 2018-07-03 | Sap Se | Real-time contextual monitoring intrusion detection and prevention |
| US9641544B1 (en) | 2015-09-18 | 2017-05-02 | Palo Alto Networks, Inc. | Automated insider threat prevention |
| US10855656B2 (en) | 2017-09-15 | 2020-12-01 | Palo Alto Networks, Inc. | Fine-grained firewall policy enforcement using session app ID and endpoint process ID correlation |
| US10931637B2 (en) | 2017-09-15 | 2021-02-23 | Palo Alto Networks, Inc. | Outbound/inbound lateral traffic punting based on process risk |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5557742A (en) | 1994-03-07 | 1996-09-17 | Haystack Labs, Inc. | Method and system for detecting intrusion into and misuse of a data processing system |
| US5802320A (en) * | 1995-05-18 | 1998-09-01 | Sun Microsystems, Inc. | System for packet filtering of data packets at a computer network interface |
| US6279113B1 (en) | 1998-03-16 | 2001-08-21 | Internet Tools, Inc. | Dynamic signature inspection-based network intrusion detection |
| US6408391B1 (en) * | 1998-05-06 | 2002-06-18 | Prc Inc. | Dynamic system defense for information warfare |
| US20020069356A1 (en) * | 2000-06-12 | 2002-06-06 | Kwang Tae Kim | Integrated security gateway apparatus |
| US20060212572A1 (en) * | 2000-10-17 | 2006-09-21 | Yehuda Afek | Protecting against malicious traffic |
| US7770223B2 (en) * | 2001-04-12 | 2010-08-03 | Computer Associates Think, Inc. | Method and apparatus for security management via vicarious network devices |
| US7640434B2 (en) * | 2001-05-31 | 2009-12-29 | Trend Micro, Inc. | Identification of undesirable content in responses sent in reply to a user request for content |
| US6513122B1 (en) | 2001-06-29 | 2003-01-28 | Networks Associates Technology, Inc. | Secure gateway for analyzing textual content to identify a harmful impact on computer systems with known vulnerabilities |
| EP1417802A1 (en) * | 2001-07-24 | 2004-05-12 | Worldcom. Inc. | Network security architecture |
| JP2003037859A (ja) | 2001-07-26 | 2003-02-07 | Matsushita Electric Ind Co Ltd | 情報通知方法、情報端末装置、情報検知装置および情報通知システム |
| US7331061B1 (en) * | 2001-09-07 | 2008-02-12 | Secureworks, Inc. | Integrated computer security management system and method |
| US7150042B2 (en) * | 2001-12-06 | 2006-12-12 | Mcafee, Inc. | Techniques for performing malware scanning of files stored within a file storage device of a computer network |
| US9392002B2 (en) * | 2002-01-31 | 2016-07-12 | Nokia Technologies Oy | System and method of providing virus protection at a gateway |
| US20030174725A1 (en) * | 2002-03-15 | 2003-09-18 | Broadcom Corporation | IP multicast packet replication process and apparatus therefore |
| JP3794491B2 (ja) * | 2002-08-20 | 2006-07-05 | 日本電気株式会社 | 攻撃防御システムおよび攻撃防御方法 |
| US7469418B1 (en) * | 2002-10-01 | 2008-12-23 | Mirage Networks, Inc. | Deterring network incursion |
| US6898632B2 (en) * | 2003-03-31 | 2005-05-24 | Finisar Corporation | Network security tap for use with intrusion detection system |
-
2003
- 2003-10-30 ES ES03819020T patent/ES2282739T3/es not_active Expired - Lifetime
- 2003-10-30 WO PCT/EP2003/012090 patent/WO2005050414A1/en active IP Right Grant
- 2003-10-30 DE DE60312235T patent/DE60312235T2/de not_active Expired - Lifetime
- 2003-10-30 US US10/576,250 patent/US8356349B2/en active Active
- 2003-10-30 BR BRPI0318587-7A patent/BR0318587A/pt not_active IP Right Cessation
- 2003-10-30 AU AU2003304558A patent/AU2003304558A1/en not_active Abandoned
- 2003-10-30 EP EP03819020A patent/EP1678567B1/en not_active Expired - Lifetime
- 2003-10-30 AT AT03819020T patent/ATE355553T1/de not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| WO2005050414A1 (en) | 2005-06-02 |
| ATE355553T1 (de) | 2006-03-15 |
| AU2003304558A1 (en) | 2005-06-08 |
| US8356349B2 (en) | 2013-01-15 |
| EP1678567A1 (en) | 2006-07-12 |
| DE60312235T2 (de) | 2007-11-08 |
| EP1678567B1 (en) | 2007-02-28 |
| BR0318587A (pt) | 2006-10-17 |
| DE60312235D1 (de) | 2007-04-12 |
| US20070058551A1 (en) | 2007-03-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2282739T3 (es) | Procedimiento y sistema para la prevencion y el rechazo de intrusiones. | |
| US7797436B2 (en) | Network intrusion prevention by disabling a network interface | |
| US7797749B2 (en) | Defending against worm or virus attacks on networks | |
| US7225468B2 (en) | Methods and apparatus for computer network security using intrusion detection and prevention | |
| US9094372B2 (en) | Multi-method gateway-based network security systems and methods | |
| US7457965B2 (en) | Unauthorized access blocking apparatus, method, program and system | |
| US7076803B2 (en) | Integrated intrusion detection services | |
| US20060095968A1 (en) | Intrusion detection in a data center environment | |
| US20030065943A1 (en) | Method and apparatus for recognizing and reacting to denial of service attacks on a computerized network | |
| JP2009500936A (ja) | 早期通知に基づいて異常なトラフィックを検出するためのシステム及び方法 | |
| EP1900172A1 (en) | Anti-hacker system with honey pot | |
| US20090094691A1 (en) | Intranet client protection service | |
| Fakeeh | An overview of DDoS attacks detection and prevention in the cloud | |
| ES2256298T3 (es) | Procedimiento, portadores de datos, sistemas de ordenadores y programas de ordenadores para el reconocimiento de ataques de virus a sistemas de servidores de redes y a sus usuarios. | |
| US20230156037A1 (en) | Methods and system for providing security to critical systems connected to a computer network | |
| Raju et al. | Network Intrusion Detection System Using KMP Pattern Matching Algorithm | |
| Vukašinović | Cyber security measures in companies | |
| Pareek | Network security: an approach towards secure computing | |
| Kizza et al. | Intrusion detection and prevention systems | |
| Singhal et al. | Design and Development of Anti-DoS/DDoS Attacks Framework Using IPtables | |
| Nakato | Networks security: attacks and defense mechanism by designing an intelligent firewall agent | |
| CN114297650A (zh) | 基于应用系统的数据流转防护方法及装置 | |
| Asarcıklı | Firewall monitoring using intrusion detection systems | |
| O’shea | Intrusion detection with honeypots | |
| Ryu | System Insecurity-Firewalls |