CE v4 SP

NetScreen: conceptos y ejemplos
Manual de referencia de ScreenOS
Volumen 4: Mecanismos de
detección de ataques y defensa
ScreenOS 5.0.0
Ref. 093-0927-000-SP
Revisión E
Copyright Notice with the instruction manual, may cause harmful interference to radio
communications. Operation of this equipment in a residential area is likely to
Copyright © 2004 NetScreen Technologies, Inc. All rights reserved. cause harmful interference, in which case users will be required to correct the
interference at their own expense.
NetScreen, NetScreen Technologies, GigaScreen, NetScreen-Global PRO,
ScreenOS and the NetScreen logo are registered trademarks of NetScreen The following information is for FCC compliance of Class B devices: The
Technologies, Inc. in the United States and certain other countries. equipment described in this manual generates and may radiate radio-frequency
NetScreen-5GT, NetScreen-5GT Extended, NetScreen-5XP, NetScreen-5XT, energy. If it is not installed in accordance with NetScreen’s installation
NetScreen-25, NetScreen-50, NetScreen-100, NetScreen-204, NetScreen-208, instructions, it may cause interference with radio and television reception. This
NetScreen-500, NetScreen-500 GPRS, NetScreen-5200, NetScreen-5400, equipment has been tested and found to comply with the limits for a Class B
NetScreen-Global PRO, NetScreen-Global PRO Express, NetScreen-Remote, digital device in accordance with the specifications in part 15 of the FCC rules.
NetScreen-Remote Security Client, NetScreen-Remote VPN Client, These specifications are designed to provide reasonable protection against
NetScreen-IDP 10, NetScreen-IDP 100, NetScreen-IDP 500, NetScreen-IDP such interference in a residential installation. However, there is no guarantee
1000, NetScreen-SA 1000, NetScreen-SA 3000, NetScreen-SA 5000, that interference will not occur in a particular installation.
NetScreen-SA Central Manager, NetScreen-SM 3000, NetScreen-Security
Manager, NetScreen-Security Manager 2004, NetScreen-Hardware Security If this equipment does cause harmful interference to radio or television
Client, NetScreen ScreenOS, NetScreen Secure Access Series, NetScreen reception, which can be determined by turning the equipment off and on, the
Secure Access Series FIPS, NetScreen-IDP Manager, GigaScreen ASIC, user is encouraged to try to correct the interference by one or more of the
GigaScreen-II ASIC, Neoteris, Neoteris Secure Access Series, Neoteris Secure following measures:
Meeting Series, Instant Virtual Extranet, and Deep Inspection are trademarks of
NetScreen Technologies, Inc. All other trademarks and registered trademarks • Reorient or relocate the receiving antenna.
are the property of their respective companies. • Increase the separation between the equipment and receiver.
Information in this document is subject to change without notice.
• Consult the dealer or an experienced radio/TV technician for help.
No part of this document may be reproduced or transmitted in any form or by
any means, electronic or mechanical, for any purpose, without receiving written • Connect the equipment to an outlet on a circuit different from that to
permission from: which the receiver is connected.
NetScreen Technologies, Inc. Caution: Changes or modifications to this product could void the user's
Building #3 warranty and authority to operate this device.
805 11th Avenue
Sunnyvale, CA 94089 Disclaimer
www.netscreen.com
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE
FCC Statement ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION
PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED
The following information is for FCC compliance of Class A devices: This HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE
equipment has been tested and found to comply with the limits for a Class A SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR
digital device, pursuant to part 15 of the FCC rules. These limits are designed to NETSCREEN REPRESENTATIVE FOR A COPY.
provide reasonable protection against harmful interference when the equipment
is operated in a commercial environment. The equipment generates, uses, and
can radiate radio-frequency energy and, if not installed and used in accordance
Contenido
Contenido
Prefacio ......................................................................... v Suplantación de IP ..................................................... 28
Ejemplo: Protección contra suplantación
Convenciones ...........................................................vii
de IP en la capa 3............................................... 32
Convenciones de la interfaz de línea
Ejemplo: Protección contra suplantación
de comandos (CLI) ......................................................vii
de IP en la capa 2............................................... 37
Convenciones de la interfaz gráfica (WebUI) .............viii
Opciones IP de ruta de origen................................... 39
Convenciones para las ilustraciones............................ x
Convenciones de nomenclatura y conjuntos Capítulo 3 Defensas contra los ataques
de caracteres.............................................................. xi de denegación de servicio.........................................45
Documentación de NetScreen .................................xii Ataques de DoS contra el cortafuegos ....................46
Inundación de la tabla de sesiones .......................... 46
Capítulo 1 Protección de una red................................1
Límites de sesiones según sus orígenes
Etapas de un ataque .................................................2 y destinos ............................................................. 46
Mecanismos de detección y defensa .......................3 Ejemplo: Limitación de sesiones según
su origen .............................................................. 49
Supervisión de exploits ...............................................6
Ejemplo: Limitación de sesiones según
Ejemplo: Supervisión de ataques desde su destino............................................................. 50
la zona Untrust ........................................................7
Envejecimiento agresivo...................................... 50
Capítulo 2 Bloqueo de reconocimiento .......................9 Ejemplo: Forzar el envejecimiento agresivo
de sesiones .......................................................... 53
Limpieza de direcciones IP ......................................10
Inundación proxy SYN-ACK-ACK................................. 54
Análisis de puertos....................................................12
Ataques DoS contra la red .......................................56
Reconocimiento de red mediante opciones IP .......14 Inundación SYN .......................................................... 56
Rastreo del sistema operativo ..................................18 Ejemplo: Protección contra inundaciones SYN.... 65
Flags SYN y FIN activados ...........................................18 Inundación ICMP ....................................................... 73
Flag FIN sin flag ACK...................................................20 Inundación UDP.......................................................... 75
Encabezado TCP sin flags activados..........................22 Ataque terrestre (“Land Attack”)................................. 77
Técnicas de evasión ................................................24 Ataques de DoS específicos de cada
Análisis FIN ..................................................................24 sistema operativo .....................................................79
Flags no SYN ...............................................................25 “Ping of Death”........................................................... 79
NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa i

Contenido
Ataque “Teardrop”......................................................81 Capítulo 5 Deep Inspection .....................................141

WinNuke......................................................................83 Resumen de Deep Inspection................................142
Capítulo 4 Supervisión y filtrado de contenidos .........85 Servidor de la base de datos de objetos
Reensamblaje de fragmentos..................................86 de ataque ..............................................................147
Protección contra URL maliciosas...............................86 Ejemplo: Actualizar inmediatamente................. 148
Puerta de enlace en la capa de aplicación.............87 Ejemplo: Actualizaciones automáticas.............. 150
Ejemplo: Bloqueo de URL maliciosas Ejemplo: Notificación automática
fragmentadas ......................................................89 y actualización inmediata................................. 152
Ejemplo: Actualización manual ......................... 154
Análisis antivirus ........................................................91
Objetos de ataque y grupos..................................156
Análisis AV interno .......................................................92
Firmas completas ..................................................... 158
Habilitación del análisis AV interno ......................97
Actualización automática o Firmas de secuencias TCP........................................ 159
semiautomática del archivo de firmas ................99 Anomalías en el protocolo....................................... 160
Ejemplo: Actualización automática .....................99 Grupos de objetos de ataque ................................. 160
Ejemplo: Actualización semiautomática ............100 Cambio de los niveles de gravedad................. 161
Configuración del procesamiento Acciones de ataque ..............................................163
de contenidos ....................................................100
Ejemplo: Acciones de ataque –
Ejemplo: Análisis AV interno para SMTP ..............101 Close Server, Close, Close Client....................... 164
Ejemplo: Análisis AV interno para SMTP y HTTP ....102
Asignación de servicios personalizados
Configuración de la descompresión y
a aplicaciones .......................................................174
el tamaño máximo de los contenidos ...............102
Ejemplo: Eliminación de archivos Ejemplo: Asignar una aplicación
de gran tamaño.................................................103 a un servicio personalizado............................... 175
Aplicación del análisis AV interno ......................104 Objetos de ataque y grupos personalizados .........178
Ejemplo: Análisis AV interno (POP3).....................104 Objetos de ataque de firma completa
Análisis AV externo ....................................................107 definidos por el usuario............................................ 178
Definición de objetos AV ....................................110 Contextos........................................................... 178
Ejemplo: Definición de tres objetos AV...............116 Firmas................................................................. 179
Aplicación del análisis AV externo .....................120 Ejemplo: Objetos de ataque de firma
completa definidos por el usuario..................... 182
Ejemplo: Antivirus con un objeto AV ...................121
Ejemplo: Antivirus con dos objetos AV ................124 Objetos de ataque de la firma
de la secuencia TCP ................................................ 186
Filtrado de URL........................................................131 Ejemplo: Objeto de ataque de firma de secuencia
Ejemplo: Configuración del filtrado de URL .......137 definido por el usuario....................................... 186
NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa ii

Contenido
Bloqueo granular de los componentes de HTTP.....189 Fragmentos ICMP ...................................................194

Controles ActiveX......................................................189 Paquetes ICMP grandes .........................................196
Applets de Java .......................................................190 Opciones IP incorrectas .........................................198
Archivos EXE..............................................................190
Protocolos desconocidos .......................................200
Archivos ZIP ...............................................................190
Fragmentos de paquetes IP ...................................202
Ejemplo: Bloquear applets de Java y
archivos “.exe” ...................................................191 Fragmentos SYN......................................................204
Capítulo 6 Atributos de los paquetes sospechosos ..193 Índice ........................................................................IX--I
NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa iii

Contenido
NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa iv

Prefacio
En el Volumen 4, “Mecanismos de detección de ataques y defensa” se describen las opciones de seguridad de red
disponibles en ScreenOS. Muchas de ellas son opciones SCREEN que se pueden activar en el nivel de zona de
seguridad. Las opciones SCREEN se aplican al tráfico que llega al dispositivo NetScreen a través de cualquier
interfaz asociada a una zona para la que se hayan activado dichas opciones. Las opciones SCREEN ofrecen
protección contra análisis de puertos y direcciones IP, ataques de denegación de servicio (DoS) y cualquier otro
tipo de actividad maliciosa. Es posible aplicar otras opciones de seguridad de red, como el filtrado de URL, la
comprobación antivirus y la detección y prevención de intrusiones (IDP), a nivel de directivas. Estas opciones sólo
se aplican al tráfico que se encuentre bajo la jurisdicción de las directivas en las que se activan.
Nota: El objeto de las directivas sólo se presenta en este volumen de forma periférica, tal como se aplica a las
opciones de seguridad de red que se pueden activar a nivel de directivas. Para examinar las directivas de forma
completa, consulte “Directivas” en la página 2 -219.
El material incluido en este volumen está organizado del siguiente modo:

• En el Capítulo 1, “Protección de una red”, se resumen las etapas básicas de un ataque y las opciones de
cortafuegos disponibles para combatir al atacante en cada etapa.
• En el Capítulo 2, “Bloqueo de reconocimiento”, se describen las opciones disponibles para bloquear la
limpieza de direcciones IP, los análisis de puertos y los intentos de descubrir el tipo de sistema operativo
(OS) del sistema objetivo del ataque.
• En el Capítulo 3, “Defensas contra los ataques de denegación de servicio”, se explican los ataques DoS
específicos de OS, red y cortafuegos, y cómo NetScreen amortigua estos ataques.
• En el Capítulo 4, “Supervisión y filtrado de contenidos”, se describe cómo proteger a los usuarios del
protocolo de transferencia de hipertexto (HTTP) y del protocolo de transferencia de archivos (FTP) frente a
los localizadores de recursos uniformes (URL) maliciosos y cómo configurar el dispositivo NetScreen para
el trabajo con productos de otros fabricantes con la finalidad de proporcionar análisis antivirus y filtrado de
URL.
NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa v

• En el Capítulo 5, “Deep Inspection”, se describe cómo configurar el dispositivo NetScreen para obtener
actualizaciones de objetos de ataque IDP, cómo crear objetos de ataque y grupos de objetos de ataque
definidos por el usuario, y cómo aplicar IDP a nivel de directivas.
• En el Capítulo 6, “Atributos de los paquetes sospechosos”, se indican varias opciones SCREEN que
protegen los recursos de red frente a potenciales ataques indicados por atributos de paquete IP e ICMP
inusuales.
NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa vi

Convenciones
CONVENCIONES
Este documento contiene distintos tipos de convenciones, que se explican en las siguientes secciones:
• “Convenciones de la interfaz de línea de comandos (CLI)”
• “Convenciones de la interfaz gráfica (WebUI)” en la página viii
• “Convenciones para las ilustraciones” en la página x
• “Convenciones de nomenclatura y conjuntos de caracteres” en la página xi
Convenciones de la interfaz de línea de comandos (CLI)

Las siguientes convenciones se utilizan para representar la sintaxis de los comandos de la interfaz de línea de
comandos (CLI):
• Los comandos entre corchetes [ ] son opcionales.
• Los elementos entre llaves { } son obligatorios.
• Si existen dos o más opciones alternativas, aparecerán separadas entre sí por barras verticales ( | ).
Por ejemplo,
set interface { ethernet1 | ethernet2 | ethernet3 } manage
significa “establecer las opciones de administración de la interfaz ethernet1, ethernet2 o ethernet3”.
• Las variables aparecen en cursiva. Por ejemplo:
set admin user name password
Los comandos CLI insertados en el contexto de una frase aparecen en negrita (salvo en el caso de las variables,
que siempre aparecen en cursiva). Por ejemplo: “Utilice el comando get system para visualizar el número de serie
de un dispositivo NetScreen”.
Nota: Para escribir palabras clave, basta con introducir los primeros caracteres que permitan al sistema reconocer
de forma inequívoca la palabra que se está introduciendo. Por ejemplo, es suficiente escribir set adm u joe
j12fmt54 para que el sistema reconozca el comando set admin user joe j12fmt54. Aunque este método se
puede utilizar para introducir comandos, en la presente documentación todos ellos se representan con sus
palabras completas.
NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa vii

Convenciones
Convenciones de la interfaz gráfica (WebUI)

En este manual se utiliza la comilla angular ( > ) para indicar las rutas de navegación de la WebUI por las que se
pasa al hacer clic en opciones de menú y vínculos. Por ejemplo, la ruta para abrir el cuadro de diálogo de
configuración de direcciones se representa como sigue: Objects > Addresses > List > New. A continuación se
muestra la secuencia de navegación.
1. Haga clic en Objects en la columna de menú. 3. Haga clic en List.

La opción de menú Objects se desplegará para Aparecerá la tabla de libretas de direcciones.
mostrar las opciones subordinadas que contiene. 4. Haga clic en el vínculo New.
2. (Menú Applet) Sitúe el mouse sobre Addresses. Aparecerá el cuadro de diálogo de
(Menú DHTML) Haga clic en Addresses. configuración de nuevas direcciones.
La opción de menú Addresses se desplegará para
mostrar las opciones subordinadas que contiene.
NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa viii

Convenciones
Para llevar a cabo una tarea en la WebUI, en primer lugar debe acceder al cuadro de diálogo apropiado, donde
podrá definir objetos y establecer parámetros de ajuste. El conjunto de instrucciones de cada tarea se divide en dos
partes: la ruta de navegación y los datos de configuración. Por ejemplo, el siguiente conjunto de instrucciones
incluye la ruta al cuadro de diálogo de configuración de direcciones y los ajustes de configuración que se deben
realizar.
Objects > Addresses > List > New: Introduzca los siguientes datos y, a continuación, haga clic en OK:
Address Name: addr_1
IP Address/Domain Name:
IP/Netmask: (seleccione), 10.2.2.5/32
Zone: Untrust
Address Name: addr_1 Nota: En este ejemplo, no

hay instrucciones para el
campo Comment, por lo que
se deja en blanco.
IP Address Name/Domain Name:
Zone: Untrust
Haga clic en OK.
NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa ix

Convenciones
Convenciones para las ilustraciones

Los siguientes gráficos conforman el conjunto básico de imágenes utilizado en las ilustraciones de este manual:
Red de área local (LAN) con

Dispositivo NetScreen una única subred
genérico (ejemplo: 10.1.1.0/24)
Dominio de Internet
enrutamiento virtual
Rango de direcciones IP
Zona de seguridad dinámicas (DIP)
Equipo de escritorio
Interfaces de la zona de seguridad
Blanca = interfaz de zona protegida
(ejemplo: zona Trust)
Negra = interfaz de zona externa Equipo portátil
(ejemplo: zona Untrust)
Dispositivo de red genérico

Interfaz de túnel
(ejemplos: servidor NAT,
concentrador de acceso)
Túnel de VPN
Servidor
Icono de enrutador (router)
Icono de conmutador (switch)
NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa x

Convenciones
Convenciones de nomenclatura y conjuntos de caracteres

ScreenOS emplea las siguientes convenciones relativas a los nombres de objetos (como direcciones, usuarios
administradores, servidores de autenticación, puertas de enlace IKE, sistemas virtuales, túneles de VPN y zonas)
definidas en las configuraciones de ScreenOS.
• Si la secuencia de caracteres que conforma un nombre contiene al menos un espacio, la cadena completa
deberá entrecomillarse mediante comillas dobles ( “ ); por ejemplo, set address trust “local LAN”
10.1.1.0/24.
• NetScreen eliminará cualquier espacio al comienzo o al final de una cadena entrecomillada; por ejemplo,
“ local LAN ” se transformará en “local LAN”.
• NetScreen tratará varios espacios consecutivos como uno solo.
• En las cadenas de nombres se distingue entre mayúsculas y minúsculas; por el contrario, en muchas
palabras clave de la interfaz de línea de comandos (CLI) pueden utilizarse indistintamente. Por ejemplo,
“local LAN” es distinto de “local lan”.
ScreenOS admite los siguientes conjuntos de caracteres:
• Conjuntos de caracteres de un byte (SBCS) y conjuntos de caracteres de múltiples bytes (MBCS). Algunos
ejemplos de SBCS son los juegos de caracteres ASCII, europeo y hebreo. Entre los conjuntos MBCS,
también conocidos como conjuntos de caracteres de doble byte (DBCS), se encuentran el chino, el coreano
y el japonés.
Nota: Una conexión de consola sólo admite conjuntos SBCS. La WebUI admite tanto SBCS como MBCS,
según el conjunto de caracteres que admita el explorador web.
• Caracteres ASCII desde el 32 (0x20 en hexadecimal) al 255 (0xff); a excepción de las comillas dobles ( “ ),
que tienen un significado especial como delimitadores de cadenas de nombres que contengan espacios.
NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa xi

Documentación de NetScreen
DOCUMENTACIÓN DE NETSCREEN
Para obtener la documentación técnica de cualquier producto de NetScreen, visite
www.netscreen.com/resources/manuals/.
Para obtener la última versión del software de NetScreen, visite www.netscreen.com. Para poder realizar una
descarga, deberá registrarse como usuario autorizado.
Si encuentra algún error u omisión en esta documentación, póngase en contacto con nosotros a través de la
siguiente dirección de correo electrónico:
techpubs@netscreen.com
NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa xii

Capítulo 1
Protección de una red

1
Puede haber numerosos motivos para penetrar en una red protegida. La siguiente lista contiene algunos objetivos
comunes:
• Obtener el siguiente tipo de información sobre la red protegida:
– Topología de la red
– Direcciones IP de los hosts activos
– Números de los puertos activos de los hosts activos
– Sistema operativo de los hosts activos
• Colapsar un host de una red protegida con tráfico fantasma para inducir una denegación de servicio (DoS)
• Colapsar una red protegida con tráfico fantasma para inducir un DoS en toda la red
• Colapsar un cortafuegos con tráfico fantasma e inducir un DoS para la red a la que protege
• Provocar daños y robar datos de un host de la red protegida
• Conseguir acceso a un host de la red protegida para obtener información
• Lograr el control de un host para lanzar otros exploits
• Apoderarse de un cortafuegos para controlar el acceso a la red a la que protege
ScreenOS ofrece herramientas de detección y defensa que permiten descubrir y frustrar los esfuerzos de los
hackers por alcanzar los objetivos mencionados anteriormente cuando intentan atacar una red protegida por un
dispositivo NetScreen.
Este capítulo proporciona en primer lugar una vista general de las principales etapas de un ataque y de los diversos
mecanismos de defensa que se pueden emplear para frustrar un ataque en cualquier etapa:
• “Etapas de un ataque” en la página 2
• “Mecanismos de detección y defensa” en la página 3
• “Supervisión de exploits” en la página 6
NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 1

Capítulo 1 Protección de una red Etapas de un ataque
ETAPAS DE UN ATAQUE
Normalmente, los ataques se desarrollan en dos etapas principales. En la primera etapa, el atacante recopila
información; en la segunda etapa, lanza el ataque propiamente dicho.
1. Realizar el reconocimiento.
1. Asignar la red y determinar qué hosts están activos (limpieza de direcciones IP).
2. Averiguar qué puertos están activos (análisis de puertos) en los hosts detectados mediante la limpieza
de direcciones IP.
3. Determinar el sistema operativo (OS), con lo que se puede revelar una debilidad del OS o un tipo de
ataque al que sea susceptible ese OS en particular.
2. Lanzar el ataque.
1. Ocultar el origen del ataque.
2. Realizar el ataque.
3. Eliminar u ocultar las pruebas.

Capítulo 1 Protección de una red Mecanismos de detección y defensa
MECANISMOS DE DETECCIÓN Y DEFENSA

Un exploit puede ser un simple rastreador para obtener información o un verdadero ataque con el que se pretende
comprometer, bloquear o dañar una red o un recurso de red. En algunos casos, no resulta sencillo establecer una
clara distinción entre estos dos objetivos. Por ejemplo, una barrera de segmentos TCP SYN se puede utilizar como
una limpieza de direcciones IP con el propósito de desencadenar respuestas de los hosts activos, o como un
ataque de inundación SYN con el objetivo de colapsar una red para impedir su correcto funcionamiento. Es más,
como los hackers normalmente realizan un reconocimiento del objetivo antes de lanzar el ataque, podemos
considerar las actividades de recopilación de información como precursoras de un ataque inminente, e interpretar
que constituyen la primera etapa de un ataque. Por lo tanto, el término “exploit” abarca tanto las actividades de
reconocimiento como las de ataque; y la distinción entre ambas no siempre está clara.
NetScreen ofrece diversos métodos de detección y mecanismos de defensa a nivel de directivas y de zona para
combatir exploits en todas sus etapas de ejecución:
• Opciones SCREEN a nivel de zona1
• Directivas de cortafuegos a nivel de directivas de interzona, intrazona y superzona. (Se entiende por
“superzona” las directivas globales en las que no se incluyen referencias a zonas de seguridad).
Para ofrecer protección contra todos los intentos de conexión, los dispositivos NetScreen utilizan un método de
filtrado de paquetes dinámico conocido como inspección de estado. Mediante este método, el dispositivo
NetScreen detecta los diversos componentes del paquete IP y de los encabezados de segmentos TCP (direcciones
IP de origen y de destino, números de puertos de origen y de destino, y números de secuencias de paquetes) y
mantiene el estado de cada sesión TCP y seudo-sesión UDP que atraviese el cortafuegos. (El dispositivo
NetScreen también modifica los estados de sesión basados en elementos cambiantes, como cambios de puertos
dinámicos o terminación de sesión). Cuando llega un paquete TCP de respuesta, el dispositivo NetScreen compara
la información incluida en su encabezado con el estado de la sesión asociada almacenada en la tabla de
inspección. Si coinciden, se permite que el paquete de respuesta atraviese el cortafuegos. De lo contrario, el
paquete se descarta.
1. Aunque las zonas VLAN y MGT son zonas de función y no zonas de seguridad, es posible ajustar opciones SCREEN para ellas. La zona VLAN admite el
mismo conjunto de opciones SCREEN que una zona de seguridad de capa 3. (Las zonas de seguridad de capa 2 admiten una opción adicional de
inundación SYN que las zonas de capa 3 no admiten: descartar direcciones MAC desconocidas). Como las siguientes opciones SCREEN no se aplican a
la zona MGT, no están disponibles para dicha zona: protección contra inundaciones SYN, protección contra la inundación SYN-ACK-ACK del proxy, bloqueo
de componentes HTTP y protección frente a ataques de WinNuke.

Las opciones SCREEN de NetScreen aseguran una zona inspeccionando, y luego permitiendo o rechazando, todo
intento de conexión que necesite atravesar una interfaz asociada a dicha zona. El dispositivo NetScreen aplica
entonces directivas de cortafuegos que pueden contener componentes para el filtrado de contenidos y la detección
y prevención de intrusiones (IDP).

A continuación se incluye un esquema de los conjuntos de mecanismos de defensa que ofrece un cortafuegos de
NetScreen para la protección de una red:
Opciones de protección de red
Bloqueo de
reconocimiento Defensas contra los ataques de
denegación de servicio
Limpieza de direcciones IP
Ataques de DoS contra el cortafuegos
Análisis de puertos
Inundación de la tabla de sesiones
Rastreo del sistema operativo
Inundación proxy SYN-ACK-ACK
Técnicas de evasión
Ataques DoS contra la red

Supervisión y filtrado
de contenidos Inundación SYN
Reensamblaje de fragmentos Inundación ICMP
Análisis antivirus Inundación UDP
Filtrado de URL Ataque terrestre (“Land Attack”)
Ataques de DoS específicos de cada sistema operativo

Deep Inspection
“Ping of Death”
Firmas completas Ataque “Teardrop”
Anomalías en el protocolo WinNuke
Bloqueo granular de los Atributos de los
componentes de HTTP paquetes
Fragmentos ICMP Protocolos desconocidos

Paquetes ICMP grandes Fragmentos de paquetes IP
Opciones IP incorrectas Fragmentos SYN

Capítulo 1 Protección de una red Supervisión de exploits
Como ya hemos mencionado, los ajustes de protección de red de NetScreen operan a dos niveles: zona de
seguridad y directiva. El dispositivo NetScreen ofrece defensas frente a ataques DoS y medidas de bloqueo de
reconocimiento a nivel de zona de seguridad. En el área de supervisión y filtrado de contenidos, el dispositivo
NetScreen aplica un reensamblaje de fragmentos a nivel de zona y un análisis antivirus (AV) y un filtrado de
localizadores de recursos uniformes (URL) a nivel de directivas. El dispositivo NetScreen aplica IDP a nivel de
directivas, excepto para la detección y el bloqueo de componentes HTTP, que se realiza a nivel de zona. Los
ajustes de cortafuegos a nivel de zona son opciones SCREEN. Una opción de protección de red ajustada en una
directiva es un componente de dicha directiva.
SUPERVISIÓN DE EXPLOITS
Aunque normalmente se utiliza el dispositivo NetScreen para bloquear exploits, puede haber ocasiones en las que
se desee obtener información sobre ellos. Es posible que desee estudiar detenidamente un exploit concreto para
descubrir su intención, su nivel de sofisticación o incluso su origen (si el atacante es descuidado o poco sofisticado).
Si desea obtener información sobre un exploit, puede dejar que actúe, supervisarlo, analizarlo, investigarlo y
reaccionar tal como se haya esbozado en un plan de respuesta ante incidentes preparado con anterioridad. Puede
configurar el dispositivo NetScreen para que le notifique la existencia de un exploit, pero que, en lugar de tomar
medidas, permita que el exploit se filtre. En tal caso, podrá estudiar qué ha ocurrido e intentar comprender el
método, la estrategia y los objetivos del atacante. Cuanto mejor comprenda las amenazas que acechan la red,
mejor podrá fortificar sus defensas. Aunque un hacker astuto puede ocultar su ubicación e identidad, tal vez sea
capaz de averiguar la suficiente información como para determinar dónde se originó el ataque. Puede que también
sea capaz de estimar las habilidades del atacante. Este tipo de información le permitirá calcular su respuesta.

Ejemplo: Supervisión de ataques desde la zona Untrust

En este ejemplo, se han producido ataques de suplantación de IP desde la zona Untrust a diario, normalmente
entre las 9 de la mañana y las 12 de la noche. En lugar de descartar los paquetes con las direcciones IP de origen
suplantadas, desea que el dispositivo NetScreen notifique su llegada pero les permita el paso, quizás
2
conduciéndolas a un sistema trampa conectado en la conexión de interfaz DMZ. A las 8:55 de la tarde, se modifica
el comportamiento del cortafuegos para que notifique y acepte los paquetes pertenecientes a un ataque detectado
en lugar de notificar y rechazarlos. Cada vez que se produzca el ataque, podrá utilizar el sistema trampa para
supervisar las actividades del atacante después de atravesar el cortafuegos. Puede trabajar también en
colaboración con el ISP de subida para comenzar a rastrear la procedencia de los paquetes hasta su punto de
origen.
WebUI
Screening > Screen (Zone: Untrust): Introduzca los siguientes datos y haga clic en Apply:
Generate Alarms without Dropping Packet: (seleccione)
IP Address Spoof Protection: (seleccione)
CLI
set zone untrust screen alarm-without-drop
set zone untrust screen ip-spoofing
save
2. Un sistema trampa es un servidor de red que se utiliza como señuelo para atraer a los atacantes y registrar sus movimientos durante un ataque.


Capítulo 2
Bloqueo de reconocimiento
2
Los atacantes pueden planificar mejor sus ataques si antes conocen el diseño de la red objetivo del ataque (qué
direcciones IP tienen los hosts activos), los puntos de entrada posibles (qué números de puertos están activos en
los hosts activos) y la constitución de sus víctimas (qué sistema operativo se está ejecutando en los hosts activos).
Para obtener esta información, es necesario realizar un reconocimiento. NetScreen ofrece varias opciones
SCREEN para frustrar los intentos de reconocimiento de los atacantes e impedir que obtengan información valiosa
sobre la red y los recursos de red protegidos.
• “Limpieza de direcciones IP” en la página 10
• “Análisis de puertos” en la página 12
• “Reconocimiento de red mediante opciones IP” en la página 14
• “Rastreo del sistema operativo” en la página 18
– “Flags SYN y FIN activados” en la página 18
– “Flag FIN sin flag ACK” en la página 20
– “Encabezado TCP sin flags activados” en la página 22
• “Técnicas de evasión” en la página 24
– “Análisis FIN” en la página 24
– “Flags no SYN” en la página 25
– “Suplantación de IP” en la página 28
– “Opciones IP de ruta de origen” en la página 39

Capítulo 2 Bloqueo de reconocimiento Limpieza de direcciones IP
LIMPIEZA DE DIRECCIONES IP
Se produce una limpieza de direcciones cuando una dirección IP de origen envía 10 paquetes ICMP a distintos
hosts en un intervalo definido (el valor predeterminado es 5000 microsegundos). El objetivo de este esquema es
enviar paquetes ICMP (normalmente peticiones de eco) a varios hosts con la esperanza de que al menos uno
responda, dejando al descubierto una dirección a la que apuntar. El dispositivo NetScreen registra de forma interna
el número de paquetes ICMP enviados a diversas direcciones desde un origen remoto. Mediante los ajustes
predeterminados, si un host remoto envía tráfico ICMP a 10 direcciones en 0,005 segundos (5000 microsegundos),
NetScreen lo marcará como un ataque de limpieza de direcciones y rechazará todos los paquetes ICMP siguientes
procedentes de dicho host hasta que transcurra el resto del segundo.
Origen: 2.2.2.5
(probablemente una dirección ethernet3
suplantada o un agente zombie) ethernet2
1.1.1.1/24 1.2.2.1/24
Untrust
DMZ
Paquetes ICMP
Dir. origen Dir. destino El dispositivo NetScreen realiza
11 paquetes ICMP 2.2.2.5 1.2.2.5 una entrada en su tabla de
en 0,005 segundos 2.2.2.5 1.2.2.160 sesiones para los 10 primeros
2.2.2.5 1.2.2.84 paquetes ICMP procedentes de
(Recuerde que, a partir del décimo 2.2.2.5 y realiza una consulta de
2.2.2.5 1.2.2.211
paquete ICMP, el dispositivo rutas y una consulta de directivas
NetScreen registra una limpieza de 2.2.2.5 1.2.2.10
para ellos. Si ninguna directiva
direcciones IP y rechaza el paquete 2.2.2.5 1.2.2.20 permite estos paquetes, el
undécimo). 2.2.2.5 1.2.2.21 dispositivo NetScreen los marca
2.2.2.5 1.2.2.240 como no válidos y los elimina de la
2.2.2.5 1.2.2.17 tabla de sesiones en el siguiente
2.2.2.5 1.2.2.123 “barrido de basura”, que se realiza
Rechazado 2.2.2.5 1.2.2.6 cada dos segundos. A partir del
décimo paquete, el dispositivo
Nota: Un agente zombie es un host comprometido NetScreen rechaza todo el tráfico
bajo el control encubierto de un atacante. ICMP procedente de 2.2.2.5.

Capítulo 2 Bloqueo de reconocimiento Limpieza de direcciones IP
Estudie la activación de esta opción SCREEN para una zona de seguridad sólo si existe una directiva que permita
el tráfico ICMP procedente de dicha zona. De lo contrario, no es necesario activarla. Si no existe tal directiva, se
rechaza todo el tráfico ICMP procedente de la zona, impidiendo a los atacantes que realicen una limpieza de
direcciones IP con éxito.
Para bloquear las limpiezas de direcciones IP originadas en una zona de seguridad en concreto, utilice una de las
siguientes soluciones:
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Introduzca los siguientes datos y haga clic en
Apply:
IP Address Sweep Protection: (seleccione)
Threshold: (introduzca un valor que active la protección contra limpiezas
de direcciones IP1)
CLI
set zone zone screen port-scan threshold number
set zone zone screen ip-sweep
1. El valor se mide en microsegundos. El ajuste predeterminado es 5000 microsegundos.

Capítulo 2 Bloqueo de reconocimiento Análisis de puertos
ANÁLISIS DE PUERTOS
Un análisis de puertos se produce cuando una dirección IP de origen envía paquetes IP con segmentos TCP SYN a
10 puertos distintos en la misma dirección IP de destino en un intervalo definido (5000 microsegundos es el valor
predeterminado). El objetivo de este esquema es analizar los servicios disponibles con la esperanza de que al
menos un puerto responda, identificando un servicio al que dirigir su ataque. El dispositivo NetScreen registra de
forma interna el número de los diversos puertos analizados desde un origen remoto. Mediante los ajustes
predeterminados, si un host remoto analiza 10 puertos en 0,005 segundos (5000 microsegundos), NetScreen lo
marcará como un ataque de análisis de puertos y rechazará todos los paquetes procedentes del origen remoto
(independientemente de la dirección IP de destino) hasta que transcurra el resto del segundo.
Origen: 2.2.2.5
(probablemente una dirección ethernet3
suplantada o un agente zombie) ethernet2
1.1.1.1/24 1.2.2.1/24
Untrust
DMZ
Destino: 1.2.2.5
Paquetes IP con segmentos TCP SYN El dispositivo NetScreen realiza

una entrada en su tabla de
Dir. Dir. sesiones para los 10 primeros
11 segmentos SYN destino:puerto destino:puerto intentos de conexión a 1.2.2.5
en 0,005 segundos 2.2.2.5:17820 1.2.2.5:21 procedentes de 2.2.2.5 y realiza
2.2.2.5:42288 1.2.2.5:23 una consulta de rutas y una
(Recuerde que, a partir del décimo 2.2.2.5:22814 1.2.2.5:53 consulta de directivas para
paquete IP con segmentos TCP SYN 2.2.2.5:15401 1.2.2.5:80 ellos. Si ninguna directiva
destinado a diversos puertos de la 2.2.2.5:13373 1.2.2.5:111 permite estos intentos de
misma dirección IP de destino, el 2.2.2.5:33811 1.2.2.5:113 conexión, el dispositivo
dispositivo NetScreen lo registra como NetScreen los marca como no
análisis de puertos y rechaza todos los 2.2.2.5:17821 1.2.2.5:123 válidos y los elimina de la tabla
paquetes procedentes de la dirección 2.2.2.5:19003 1.2.2.5:129 de sesiones en el siguiente
de origen). 2.2.2.5:26450 1.2.2.5:137 “barrido de basura”, que se
2.2.2.5:38087 1.2.2.5:138 realiza cada dos segundos. A
Rechazado 2.2.2.5:24111 1.2.2.5:139 partir del décimo intento, el
dispositivo NetScreen rechaza
todos los intentos de conexión
procedentes de 2.2.2.5.

Capítulo 2 Bloqueo de reconocimiento Análisis de puertos
Para bloquear los análisis de puertos originados en una zona de seguridad en concreto, utilice una de las siguientes
soluciones:
WebUI
Apply:
Port Scan Protection: (seleccione)
Threshold: (introduzca un valor que active la protección contra análisis de
puertos2)
CLI
set zone zone screen port-scan threshold number
set zone zone screen port-scan
2. El valor se mide en microsegundos. El ajuste predeterminado es 5000 microsegundos.

Capítulo 2 Bloqueo de reconocimiento Reconocimiento de red mediante opciones IP
RECONOCIMIENTO DE RED MEDIANTE OPCIONES IP

La norma de protocolo de Internet “RFC 791, Internet Protocol” especifica una serie de opciones que ofrecen
controles de enrutamiento, herramientas de diagnóstico y medidas de seguridad especiales. Estas opciones
aparecen después de la dirección de destino en un encabezado de paquetes IP.
Encabezado IP
Tamaño del
Versión encabezado Tipo de servicio Tamaño total del paquete (en bytes)
Identificación 0 D M Desplazamiento del fragmento

Tiempo de vida 20
(“Time to Live” o “TTL”) Protocolo Suma de comprobación del encabezado
bytes
Dirección de origen
Dirección de destino
Opciones
Carga (datos)
La norma RFC 791 admite que estas opciones “no son necesarias para las comunicaciones más comunes” y, en
realidad, rara vez aparecen en encabezados de paquetes IP. Cuando aparecen, normalmente están vinculadas a
un uso con propósitos perniciosos. A continuación se incluye una lista de todas las opciones IP y los atributos que
las acompañan:
Tipo Clase Número Tamaño Uso intencionado Uso pernicioso

End of Options 0* 0 0 Indica el fina de una o más opciones IP. Ninguno
No Options 0 1 0 Indica que no hay opciones IP en el Ninguno
encabezado.


Security 0 2 11 bits Ofrece un medio para que los hosts Desconocido, pero como se
envíen seguridad, compartimentación, trata de una opción obsoleta,
parámetros TCC (grupo de usuarios su presencia en un
cerrado) y códigos de restricción de uso encabezado IP resulta
compatibles con los requisitos del sospechosa.
Ministerio de defensa (DoD) de Estados
Unidos. (Esta opción, tal como se
especifica en RFC 791 y RFC 1038, está
obsoleta).
Loose Source 0 3 Variable Especifica una lista de rutas parcial que Evasión. El atacante puede
Route debe tomar un paquete en su trayecto utilizar las rutas especificadas
desde el punto de origen al de destino. para ocultar el verdadero
El paquete debe avanzar en el orden de origen de un paquete u
direcciones especificado, pero se le obtener acceso a una red
permite atravesar otros enrutadores protegida. (Consulte
intermedios. “Opciones IP de ruta de
origen” en la página 39).
Record Route 0 7 Variable Registra las direcciones IP de los Reconocimiento. Si el host de
dispositivos de red del itinerario que destino es un equipo
recorre el paquete IP. El equipo de comprometido bajo el control
destino puede extraer y procesar la del atacante, éste puede
información de ruta. (Debido a la obtener información sobre la
limitación de espacio de 40 bytes tanto topología y el esquema de
para la opción como para el espacio de direccionamiento de la red
almacenamiento, sólo se puede registrar atravesada por el paquete.
un máximo de 9 direcciones IP).
Stream ID 0 8 4 bits (Obsoleta) Ofrecía un medio para que el Desconocido, pero como se
identificador de secuencia SATNET de trata de una opción obsoleta,
16 bits se transportara por redes su presencia en un
incompatibles con el concepto de encabezado IP resulta
secuencia. sospechosa.


Strict Source 0 9 Variable Especifica la lista de la ruta completa Evasión. Un atacante puede
Route que debe tomar un paquete en su utilizar las rutas especificadas
trayecto desde el punto de origen al de para ocultar el verdadero
destino. La última dirección de la lista origen de un paquete u
sustituye a la dirección del campo de obtener acceso a una red
destino. protegida. (Consulte
“Opciones IP de ruta de
origen” en la página 39).
Timestamp 2† 4 Registra la hora (en formato de horario Reconocimiento. Si el host de
‡
universal ) en la que cada dispositivo de destino es un equipo
red recibe el paquete durante su comprometido bajo el control
itinerario desde el punto de origen al de del atacante, éste puede
destino. Los dispositivos de red se obtener información sobre la
identifican por su número IP. topología y el esquema de
Esta opción desarrolla una lista de direccionamiento de la red
direcciones IP de los enrutadores del atravesada por el paquete.
itinerario del paquete y la duración de
transmisión entre cada uno de ellos.
*
La clase de opciones identificada como “0” estaba diseñada para proporcionar control de red o paquetes adicionales.
†
La clase de opciones identificada como “2” se diseñó para el diagnóstico, la depuración y la medición.
‡
La marca de hora utiliza el número de milisegundos desde la media noche en horario universal (UT). Este horario también se denomina “horario
medio de Greenwich” (GMT) y es la base para la norma horaria internacional.

Las siguientes opciones SCREEN detectan las opciones IP que un atacante puede utilizar para el reconocimiento o
cualquier otro propósito desconocido, pero sospechoso:
• Record Route: el dispositivo NetScreen detecta paquetes en los que la opción IP sea 7 (Record Route) y
registra el evento en la lista de contadores SCREEN para la interfaz de entrada.
• Timestamp: el dispositivo NetScreen detecta paquetes en los que la lista de opciones IP incluya la opción
4 (Internet Timestamp) y registra el evento en la lista de contadores SCREEN para la interfaz de entrada.
• Security: el dispositivo NetScreen detecta paquetes en los que la opción IP sea 2 (Security) y registra el
evento en la lista de contadores SCREEN para la interfaz de entrada.
• Stream ID: el dispositivo NetScreen detecta paquetes en los que la opción IP sea 8 (Stream ID) y registra
el evento en la lista de contadores SCREEN para la interfaz de entrada.
Para detectar paquetes con las opciones IP anteriores ajustadas, utilice uno de los siguientes métodos (la zona de
seguridad especificada es la zona en la que se originó el paquete):
WebUI
Apply:
IP Record Route Option Detection: (seleccione)
IP Timestamp Option Detection: (seleccione)
IP Security Option Detection: (seleccione)
IP Stream Option Detection: (seleccione)
CLI
set zone zone screen ip-record-route
set zone zone screen ip-timestamp-opt
set zone zone screen ip-security-opt
set zone zone screen ip-stream-opt

Capítulo 2 Bloqueo de reconocimiento Rastreo del sistema operativo
RASTREO DEL SISTEMA OPERATIVO

Antes de lanzar un exploit, es posible que un atacante intente rastrear el host al que se dirige el ataque para
averiguar qué sistema operativo (OS) utiliza. Conociendo este dato, puede decidir con mejor criterio qué ataque
lanzar y qué vulnerabilidades aprovechar. Un dispositivo NetScreen puede bloquear los rastreos de reconocimiento
utilizados habitualmente para obtener información sobre los tipos de OS.
Flags SYN y FIN activados

Los flags de control SYN y FIN no están activados normalmente en el mismo encabezado de segmento TCP. El flag
SYN sincroniza números de secuencia para el inicio de una conexión TCP. El flag FIN indica el final de la
transmisión de datos para la terminación de una conexión TCP. Sus propósitos se excluyen mutuamente. Un
encabezado TCP con los flags SYN y FIN activados representa un comportamiento TCP anómalo y puede provocar
varias respuestas del destinatario en función del OS.
Encabezado TCP
Número de puerto de origen de 16 bits Número de puerto de destino de 16 bits
Número de secuencia de 32 bits
Número de reconocimiento de 32 bits 20

bytes
Tamaño de Reservado U A P R S F
encabezado de R C S S Y I Tamaño de ventana de 16 bits
(6 bits)
4 bits G K H T N N
Suma de comprobación de TCP de 16 bits Indicador urgente de 16 bits
Opciones (si las hay)
Datos (si los hay)
Los flags SYN y FIN están activados.

Un atacante puede enviar un segmento con ambos flags activados para ver qué tipo de respuesta de sistema se
devuelve y determinar de este modo qué tipo de OS se utiliza en el punto de destino. A continuación, el atacante
puede emplear cualquier vulnerabilidad conocida del sistema para futuros ataques.
Al activar esta opción SCREEN, el dispositivo NetScreen comprueba si los flags SYN y FIN están activados en
encabezados TCP. Si descubre un encabezado de tales características, descarta el paquete.
Para bloquear paquetes con los flags SYN y FIN activados, utilice uno de los siguientes métodos (la zona de
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione SYN and FIN Bits Set Protection
y haga clic en Apply.
CLI
set zone zone screen syn-fin

Flag FIN sin flag ACK

Los segmentos TCP con el flag de control FIN activado (para señalar el final de una sesión y terminar la conexión)
suelen tener también activado el flag ACK (para acusar recibo del paquete anterior). Como la existencia de un
encabezado TCP con el flag FIN activado y el flag ACK desactivado representa un indicio de comportamiento TCP
3
anómalo, no existe una respuesta uniforme ante este hecho . Es posible que el OS reaccione enviando un
segmento TCP con el flag RST activado. También es posible que lo ignore completamente. La respuesta de la
víctima puede proporcionar información sobre el OS al atacante. (Otros motivos para enviar un segmento TCP con
el flag FIN activado pueden ser evadir la detección durante un análisis de puertos y direcciones o burlar las
defensas destinadas a prevenir inundaciones SYN provocando una inundación FIN en su lugar. Para obtener más
información sobre los análisis FIN, consulte “Análisis FIN” en la página 24).
Encabezado TCP

bytes
(6 bits)
4 bits G K H T N N
Datos (si los hay)
Sólo está activado el flag FIN.
3. Los proveedores han interpretado la norma RFC 793 “Transmission Control Protocol” (protocolo de control de la transmisión) de diversas formas a la hora
de diseñar las implementaciones TCP/IP. Cuando se recibe un segmento TCP con el flag FIN activado y el flag ACK sin activar, determinadas
implementaciones envían segmentos RST. Otras descartan el paquete sin enviar ningún segmento RST.

Al activar esta opción SCREEN, el dispositivo NetScreen comprueba si el flag FIN está activado y el flag ACK está
desactivado en encabezados TCP. Si descubre un paquete con este tipo de encabezado, descarta el paquete.
Para bloquear paquetes con el flag FIN activado y el flag ACK desactivado, utilice uno de los siguientes métodos (la
zona de seguridad especificada es la zona en la que se originó el paquete):
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione FIN Bit with No ACK Bit in Flags
Protection y haga clic en Apply.
CLI
set zone zone screen fin-no-ack

Encabezado TCP sin flags activados

Un encabezado de segmento TCP normal tiene al menos un flag de control activado. Un segmento TCP sin flags de
control activados representa un evento anómalo. Puesto que cada sistema operativo reacciona de forma distinta a
tal anomalía, la respuesta (o la falta de respuesta) del dispositivo objetivo puede dar indicios del tipo de OS que se
está ejecutando.
Encabezado TCP

bytes
Tamaño de U A P R S F
encabezado de Reservado Tamaño de ventana de 16 bits
(6 bits) R C S S Y I
4 bits G K H T N N
Datos (si los hay)
No hay ningún flag activado.
Si el dispositivo NetScreen está habilitado para detectar encabezados de segmento TCP sin flags activados,
descartará todos los paquetes TCP que carezcan de campo de flags o que tengan un campo de flags mal formado.

Para bloquear los paquetes que no tengan ningún flag activado, utilice uno de los siguientes métodos (la zona de
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione TCP Packet without Flag
Protection y haga clic en Apply.
CLI
set zone zone screen tcp-no-flag

Capítulo 2 Bloqueo de reconocimiento Técnicas de evasión
TÉCNICAS DE EVASIÓN
Ya sea mientras recopila información o lanza un ataque, el atacante normalmente necesita evitar que lo detecten.
Aunque ciertos análisis de direcciones IP y puertos son tan descarados que se pueden detectar fácilmente, algunos
atacantes con mayores recursos utilizar una gran cantidad de medios para ocultar su actividad. Técnicas tales
como la utilización de análisis FIN en lugar de análisis SYN —que los atacantes saben que la mayoría de
cortafuegos y programas de detección de intrusiones detectan— indican una evolución en las técnicas de
reconocimiento y explotación de vulnerabilidades con el objetivo de eludir la detección y llevar a cabo sus acciones.
Análisis FIN
Un análisis FIN envía segmentos TCP con el flag FIN activado para intentar provocar una respuesta (un segmento
TCP con el flag RST activado) y así descubrir un host activo o un puerto activo en un host. El atacante puede utilizar
este método no para realizar un barrido de direcciones con peticiones de eco ICMP o un análisis de direcciones con
segmentos SYN, sino porque sabe que muchos cortafuegos se defienden contra estos dos últimos, pero no
necesariamente contra los segmentos FIN. Si se utilizan segmentos TCP con el flag FIN activado se puede evadir
la detección, permitiendo así que el atacante tenga éxito en su intento de reconocimiento.
Para frustrar un análisis FIN, puede ejecutar cualquiera de las siguientes acciones o ambas:
• Habilitar la opción SCREEN que bloquea específicamente segmentos TCP con el flag FIN activado, pero
no el flag ACK, lo que no es normal en un segmento TCP.
WebUI: Screening > Screen: Seleccione la zona a la que desea aplicar esta opción SCREEN en la
lista desplegable “Zone” y seleccione FIN Bit With No ACK Bit in Flags Protection.
CLI: Escriba set zone name screen fin-no-ack, donde name es el nombre de la zona a la que desea
aplicar esta opción SCREEN
• Cambie el comportamiento de procesamiento de paquetes para rechazar todos los paquetes no SYN que
no pertenezcan a una sesión existente, mediante el comando CLI: set flow tcp-syn-check. (Para obtener
más información sobre la comprobación del flag SYN, consulte la siguiente sección, “Flags no SYN” en la
página 25).
Nota: Cambiando el flujo de paquetes para comprobar que el flag SYN está activado para los paquetes no
pertenecientes a sesiones existentes también se frustran otros tipos de análisis no SYN, tales como los
análisis nulos (“null scan”, es decir, cuando no hay ningún flag de TCP activo).

Flags no SYN
De forma predeterminada, el dispositivo NetScreen no busca flags SYN en el primer paquete de una sesión.
Permite que segmentos TCP con flags no SYN inicien sesiones mientras haya una directiva que permita al tráfico
atravesar el cortafuegos. Puede dejar este flujo de paquetes tal cual o cambiarlo para forzar la comprobación del
flag SYN antes de crear la sesión. A continuación se muestran las secuencias de flujo de los paquetes cuando se
inhabilita y habilita la comprobación de flag SYN:
Con la comprobación de flag SYN inhabilitada Con la comprobación de flag SYN habilitada
Llega un paquete Llega un paquete

a la interfaz de a la interfaz de
entrada entrada
En En
sesión sesión
Consulta de Actualización Consulta de Actualización
de sesión ADELANTE de sesión ADELANTE
sesiones sesiones
No en No en
sesión sesión
Permitir Permitir Compro- Sí

Consulta de Creación de Consulta de bación de Creación de
sesión ADELANTE sesión ADELANTE
directivas directivas flag SYN
Denegar Denegar No
DESCARTAR DESCARTAR DESCARTAR
La comprobación de SYN se puede habilitar e inhabilitar con los siguientes comandos CLI:
set flow tcp-syn-check
unset flow tcp-syn-check

No comprobar el flag SYN en los primeros paquetes ofrece las siguientes ventajas:
• NSRP con enrutamiento asimétrico: En una configuración NSRP activa/activa en un entorno de
enrutamiento dinámico, un host puede enviar el segmento inicial TCP con el flag SYN activado a un
dispositivo NetScreen (NetScreen-A), pero la señal SYN/ACK podría enrutarse al otro dispositivo
NetScreen del clúster (NetScreen-B). Si este enrutamiento asimétrico se produce después de que
NetScreen-A haya sincronizado su sesión con NetScreen-B, todo está en orden. Por el contrario, si la
respuesta SYN/ACK llega a NetScreen-B antes de que NetScreen-A haya sincronizado la sesión y la
comprobación de SYN está habilitada, NetScreen-B rechaza SYN/ACK, lo que impide establecer la sesión.
Con la comprobación de SYN inhabilitada, NetScreen-B acepta la respuesta SYN/ACK (aunque no
pertenezca a ninguna sesión existente) y crea para ella una nueva entrada en la tabla de sesiones.
• Sesiones no interrumpidas: Si la comprobación de SYN está habilitada y se agrega un dispositivo
NetScreen en modo transparente a una red operativa, se interrumpen todas las sesiones existentes, que
4
deberán reiniciarse . Esta interrupción puede ser muy molesta para sesiones muy largas, como las de
transferencias de datos o las de copias de seguridad de grandes bases de datos. De forma similar, si se
restablece el dispositivo NetScreen o incluso se cambia un componente en la sección central de una
5
directiva y la comprobación de SYN está habilitada, todas las sesiones existentes (o las sesiones a las que
afecte la modificación de la directiva) se interrumpirán y deberán ser reiniciadas. Inhabilitar la
comprobación de SYN evita esas interrupciones al tráfico de la red.
Sin embargo, observe que las ventajas indicadas requieren los siguientes sacrificios en seguridad:
• Agujeros de reconocimiento: Cuando un segmento TCP inicial con un flag no SYN (como ACK, URG,
RST, FIN) llega a un puerto cerrado, muchos sistemas operativos (Windows, por ejemplo) responden con
un segmento TCP cuyo flag RST está activado. Si el puerto está abierto, el receptor no genera ninguna
respuesta.
4. Una solución a esta situación es instalar el dispositivo NetScreen con la comprobación de SYN inicialmente inhabilitada. Transcurridas algunas horas
(cuando las sesiones establecidas se estén ejecutando a través del dispositivo NetScreen), habilite la comprobación de SYN.
5. La sección central de una directiva contiene los siguientes componentes principales: zonas de origen y de destino, direcciones de origen y de destino, uno
o más servicios y una acción.

Analizando las respuestas o la ausencia de éstas, un recopilador de inteligencia puede realizar un

reconocimiento en la red protegida y también en el conjunto de directivas de NetScreen. Si después envía
un segmento TCP con un flag no SYN activado y la directiva le permite el paso, el host de destino del
segmento podría descartarlo y responder con un segmento TCP cuyo flag RST esté activado. Tal
respuesta informa al intruso sobre la presencia de un host activo en una dirección específica y le indica que
el número de puerto de destino está cerrado. El recopilador de inteligencia también averigua que la
directiva del cortafuegos permite acceder a ese número de puerto en ese host.
Con la comprobación del flag SYN habilitada, el dispositivo NetScreen descarta los segmentos TCP que no
tengan flag SYN siempre que no pertenezcan a una sesión existente. El dispositivo no devolverá un
segmento TCP RST. Por lo tanto, el escáner no obtendrá ninguna respuesta, sea cual sea el conjunto de
directivas o tanto si el puerto está abierto o cerrado en el host de destino.
• Inundaciones de tablas de sesiones Si la comprobación de SYN está inhabilitada, un atacante puede
evitar la función de protección contra inundaciones SYN de NetScreen inundando una red protegida con
una cantidad ingente de segmentos TCP que tengan flags no SYN activados. Aunque los hosts atacados
descartarán los paquetes (y posiblemente envíen segmentos TCP RST como respuesta), tal inundación
podría llenar la tabla de sesiones del dispositivo NetScreen. Con la tabla de sesiones llena, el dispositivo
NetScreen no puede procesar nuevas sesiones de tráfico legítimo.
Habilitando la comprobación de SYN y la protección contra inundaciones SYN se puede frustrar esta clase
de ataques. La comprobación de si el flag SYN está activado en el paquete inicial de una sesión fuerza a
todas las nuevas sesiones a comenzar con un segmento TCP que tenga el flag SYN activado. A
continuación, la protección contra inundaciones SYN limita el número de segmentos TCP SYN por segundo
para evitar saturaciones en la tabla de sesiones.
Nota: Para obtener información sobre las inundaciones de la tabla de sesiones, consulte “Inundación de la
tabla de sesiones” en la página 46. Para obtener más información sobre inundaciones SYN, consulte
“Inundación SYN” en la página 56.
Salvo que necesite tener la comprobación de SYN inhabilitada, NetScreen recomienda encarecidamente que la
habilite con el comando siguiente: set flow tcp-syn-check. Con la comprobación de SYN habilitada, el dispositivo
NetScreen rechaza los segmentos TCP con flags no SYN activados, salvo que pertenezcan a una sesión
establecida.

Suplantación de IP
Un método para intentar acceder a un área restringida de la red es insertar una dirección de origen falsa en el
encabezado del paquete para que parezca que procede de un lugar de origen confiable. Esta técnica se conoce
como suplantación de IP (IP Spoofing). Para detectar esta técnica, NetScreen dispone de dos métodos con el
mismo objetivo: determinar si el paquete procede de una ubicación distinta de la indicada en el encabezado. El
método que utilizará el dispositivo NetScreen dependerá de si funciona en la capa 3 o en la capa 2 del modelo OSI.
• Capa 3: cuando las interfaces del dispositivo NetScreen funcionan en modo de ruta o en modo NAT, el
mecanismo para detectar la suplantación de IP dependerá de las entradas de la tabla de rutas. Si, por
ejemplo, un paquete con la dirección IP de origen 10.1.1.6 llega a ethernet3, pero el dispositivo NetScreen
tiene una ruta a 10.1.1.0/24 a través de ethernet1, la comprobación de suplantación de IP detectará que
esta dirección ha llegado a una interfaz no válida, ya que según la definición de la tabla de rutas un paquete
válido procedente de 10.1.1.6 sólo puede llegar a través de ethernet1, no de ethernet3. Así, el dispositivo
concluye que el paquete es una dirección IP de origen suplantada y la descarta.
Si la dirección IP de origen de un paquete no aparece en la tabla de rutas, el dispositivo NetScreen permite
su paso de forma predeterminada (asumiendo que existe una directiva que lo permite). Si utiliza el siguiente
comando CLI (donde la zona de seguridad especificada será la zona de donde proceden los paquetes),
puede hacer que el dispositivo NetScreen descarte cualquier paquete cuya dirección IP de origen no se
incluya en la tabla de rutas:
set zone zone screen ip-spoofing drop-no-rpf-route

1. Un paquete IP llega a ethernet3.

Su dirección IP de origen es 2. Como la protección contra suplantación de IP
10.1.1.6. está activada en la zona Untrust, el dispositivo
NetScreen comprueba si 10.1.1.6 es una
Paquete IP con IP de origen 10.1.1.6 1 dirección IP de origen válida para los paquetes
Zona Untrust que llegan a ethernet3.
2
3
ethernet3
1.1.1.1/24
X Tabla de rutas
3. Si al consultar la tabla de rutas ID IP-Prefix Interface Gateway P
observa que 10.1.1.6 no es una
dirección IP de origen válida 1 10.1.10/24 eth1 0.0.0.0 C
para un paquete que llega a
ethernet3, el dispositivo
NetScreen rechazará el ethernet1
Zona Trust 10.1.1.1/24
paquete.
Subred: 10.1.1.0/24

• Capa 2: si las interfaces del dispositivo NetScreen funcionan en modo transparente, el mecanismo de
comprobación de suplantación de IP utilizará las entradas de la libreta de direcciones. Por ejemplo, ha
definido una dirección para “serv A” como 1.2.2.5/32 en la zona V1-DMZ. Si un paquete con la dirección IP
de origen 1.2.2.5 llega a una interfaz de la zona V1-Untrust (ethernet3), la comprobación de suplantación
de IP detectará que esta dirección ha llegado a una interfaz incorrecta. La dirección pertenece a la zona
V1-DMZ y no a la zona V1-Untrust, por lo que sólo se aceptaría en ethernet2, que es la interfaz asociada a
V1-DMZ. El dispositivo concluye que el paquete es una dirección IP de origen suplantada y la descarta.
1. Un paquete IP llega procedente de la zona V1-Untrust. 2. Como la protección contra suplantación de IP

Su dirección IP de origen es 10.2.2.5. está activada en la zona V1-Untrust, el
dispositivo NetScreen comprueba si 1.2.2.5 es
Zona V1-Untrust una dirección IP de origen válida para los
Paquete IP con IP de origen 10.2.2.5 1 paquetes procedentes de la zona V1-Untrust.
2
3
ethernet3
0.0.0.0/0
X Nombre de zona de dirección: V1-DMZ
3. Si al consultar la libreta de
direcciones observa que Name Address Netmask
1.2.2.5 no es una dirección IP
de origen válida para un Subred: 1.2.2.0/24 serv A 1.2.2.5 255.255.255.255
paquete procedente de la
zona V1-Untrust, el ethernet2
dispositivo NetScreen serv A 0.0.0.0/0
rechazará el paquete. 1.2.2.5
Zona V1-DMZ

Tenga cuidado al definir direcciones para la subred que abarca múltiples zonas de seguridad. En la
ilustración anterior, 1.2.2.0/24 pertenece tanto a la zona V1-Untrust como a la zona V1-DMZ. Si configura el
dispositivo NetScreen tal y como se describe a continuación, bloqueará el tráfico procedente de la zona
V1-DMZ cuyo paso desea permitir.
– Ha definido una dirección para 1.2.2.0/24 en la zona V1-Untrust.
– Dispone de una directiva que permite el tráfico desde cualquier dirección de la zona V1-DMZ hacia
cualquier dirección de la zona V1-Untrust (set policy from v1-dmz to v1-untrust any any any
permit).
– Habilita la comprobación de suplantación de IP.
Como las direcciones de la zona V1-DMZ también se encuentran en la subred 1.2.2.0/24, cuando el tráfico
procedente de esas direcciones llegue a ethernet2, la comprobación de suplantación de IP consultará la
libreta de direcciones y encontrará 1.2.2.0/24 en la zona V1-Untrust. En consecuencia, el dispositivo
NetScreen bloqueará el tráfico.

Ejemplo: Protección contra suplantación de IP en la capa 3

En este ejemplo habilitará la protección contra suplantación de direcciones IP en las zonas Trust, DMZ y Untrust
para un dispositivo NetScreen que funciona en la capa 3. De forma predeterminada, el dispositivo NetScreen
realiza entradas automáticamente en la tabla de rutas para las subredes especificadas en las direcciones IP de
interfaz. Además de estas entradas automáticas en la tabla de rutas, deberá introducir manualmente las siguientes
tres rutas:
Destino: Interfaz de salida: Siguiente puerta de

enlace:
10.1.2.0/24 ethernet1 10.1.1.250
1.2.3.0/24 ethernet2 1.2.2.250
0.0.0.0/0 ethernet3 1.1.1.250
Si habilita la opción SCREEN para protección contra suplantación de direcciones IP pero no indica estas tres rutas,
el dispositivo NetScreen descartará todo tráfico de las direcciones que aparecen en la columna “Destino” e insertará
las alarmas correspondientes en el registro de eventos. Por ejemplo, si un paquete con la dirección de origen
10.1.2.5 llega a ethernet1 y no hay ninguna ruta a la subred 10.1.2.0/24 a través de ethernet1, el dispositivo
NetScreen determinará que ese paquete ha llegado a una interfaz no válida y lo descartará.

Todas las zonas de seguridad de este ejemplo se encuentran en el dominio de enrutamiento trust-vr.
ethernet1 ethernet3
Enrutador Enrutador
10.1.1.1/24 1.1.1.1/24
10.1.1.250 1.1.1.250
ethernet2
1.2.2.1/24
10.1.2.0/24 10.1.1.0/24 1.1.1.0/24 0.0.0.0/0
Zona Trust Zona Zona Untrust

DMZ 1.2.2.0/24
1.2.3.0/24
Enrutador
1.2.2.250
WebUI
1. Interfaces
Network > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos y haga clic en Apply:
Zone Name: Trust
Static IP: (seleccione esta opción si es posible)
IP Address/Netmask: 10.1.1.1/24
Introduzca los siguientes datos y haga clic en OK:

Interface Mode: NAT
Network > Interfaces > Edit (para ethernet2): Introduzca los siguientes datos y haga clic en OK:
Zone Name: DMZ

Zone Name: Untrust
2. Rutas
Network > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK:
Network Address/Netmask: 10.1.2.0/24
Gateway: (seleccione)
Interface: ethernet1
Gateway IP Address: 10.1.1.250

3. Protección contra suplantación de IP

Screening > Screen (Zone: Trust): Seleccione IP Address Spoof Protection y haga clic en Apply.
Screening > Screen (Zone: DMZ): Seleccione IP Address Spoof Protection y haga clic en Apply.
Screening > Screen (Zone: Untrust): Seleccione IP Address Spoof Protection y haga clic en Apply.

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet2 zone dmz

set interface ethernet3 zone untrust

2. Rutas
set vrouter trust-vr route 10.1.2.0/24 interface ethernet1 gateway 10.1.1.250
set zone trust screen ip-spoofing
set zone dmz screen ip-spoofing
set zone untrust screen ip-spoofing
save

Ejemplo: Protección contra suplantación de IP en la capa 2

En este ejemplo protegeremos la zona V1-DMZ contra la suplantación de direcciones IP en el tráfico originado en la
zona V1-Untrust. En primer lugar debemos definir las siguientes direcciones para los tres servidores web de la zona
V1-DMZ:
• servA: 1.2.2.10
• servB: 1.2.2.20
• servC: 1.2.2.30
Ahora puede habilitar la protección en la zona V1-Untrust.
Si un atacante en la zona V1-Untrust intenta suplantar la dirección IP utilizando cualquiera de las tres direcciones
de la zona V1-DMZ, el dispositivo NetScreen comprobará la dirección comparándola con las direcciones de la
libreta de direcciones. Cuando descubra que la dirección IP de origen en un paquete procedente de la zona
V1-Untrust pertenece a una dirección definida en la zona V1-Untrust. el dispositivo NetScreen rechazará el
paquete.
WebUI
1. Direcciones
Objects > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK:
Address Name: servA
Zone: V1-DMZ
Address Name: servB

Zone: V1-DMZ
Address Name: servC
Zone: V1-DMZ

Screening > Screen (Zone: V1-Trust): Seleccione IP Address Spoof Protection y haga clic en Apply.
CLI
1. Direcciones
set address v1-dmz servA 1.2.2.10/32
set address v1-dmz servB 1.2.2.20/32
set address v1-dmz servC 1.2.2.30/32
set zone v1-untrust screen ip-spoofing
save

Opciones IP de ruta de origen

El enrutamiento de origen ha sido diseñado para que, desde el origen de una transmisión de paquetes IP, el usuario
pueda especificar las direcciones IP de los enrutadores (también conocidos como “saltos”) a lo largo de la ruta que
desee que un paquete IP siga para llegar a su destino. La intención original de las opciones IP de ruta de origen era
ofrecer herramientas de control de enrutamiento como ayuda al análisis de diagnósticos. Por ejemplo, si la
transmisión de un paquete a un destino en particular se realiza con un nivel de éxito irregular, puede utilizar la
opción IP de marca de hora o de grabación de ruta para averiguar las direcciones de los enrutadores del itinerario o
los itinerarios seguidos por el paquete. A continuación, puede utilizar la opción de ruta de origen estricta o de ruta
de origen abierta para conducir el tráfico por un itinerario específico, utilizando las direcciones averiguadas
mediante la opción IP de marca de hora o de grabación de ruta. Modificando las direcciones de enrutador para
cambiar el itinerario y enviando diversos paquetes por distintos itinerarios puede tomar nota de los cambios que
contribuyen a aumentar o reducir las posibilidades de éxito. Mediante el análisis y un proceso de eliminación, es
posible que pueda deducir dónde reside el problema.

Cuatro
Opciones IP de ruta de enrutadores
origen para diagnóstico
1 Itinerario del 3
A paquete B
La transmisión de A a B mediante los
enrutadores 1 y 3 se realiza con éxito el
2 4 50% de las ocasiones.
1 3
A B Mediante el enrutamiento de origen IP,
A envía tráfico a través de los
enrutadores 2 y 3. La transmisión de A
2 4 a B se realiza con éxito el 50% de las
ocasiones.
1 3 Mediante el enrutamiento de origen IP,

A B A envía tráfico a través de los
enrutadores 1 y 4. La transmisión de A
a B se realiza con éxito el 100% de las
2 4 ocasiones. Por lo tanto, podemos
suponer que el problema reside en el
enrutador 3.

Aunque la aplicación de las opciones IP de ruta de origen era benigna originalmente, los hackers han aprendido a
utilizar estas opciones con malas intenciones. Las opciones IP de ruta de origen se pueden emplear para ocultar la
dirección auténtica del atacante y acceder a áreas restringidas de una red especificando una ruta distinta. A
continuación se incluye un ejemplo en el que se muestra cómo un atacante puede poner en práctica estos engaños.
Opción IP de ruta de origen

abierta para un acceso Cuatro
malicioso enrutadores
ethernet3 ethernet1 Servidor HTTP
1.1.1.1/24 10.1.1.1/24 10.1.1.5
1 Itinerario del 3 Zona Untrust Zona Trust
paquete
2.2.2.0/24 10.1.1.0/24
2 4
Sin comprobación de IP asignada: 1.1.1.5 - 10.1.1.5

suplantación de IP Directiva: set policy from untrust to trust
Sin control de acceso Atacante 2.2.2.0/24 MIP(1.1.1.5) HTTP permit
Información del paquete Entre las opciones SCREEN para la zona Untrust
se incluye “Deny IP Source Route Option”.
Dirección de origen real: 6.6.6.5
Dirección de origen simulada: 2.2.2.5 El dispositivo NetScreen descarta el paquete.
Dirección de destino: 1.1.1.5
IP de ruta de origen abierta: 6.6.6.250, 2.2.2.250
El cortafuegos de NetScreen sólo permite el tráfico 2.2.2.0/24 si pasa a través de ethernet1, una interfaz asociada a
la zona Untrust. Los enrutadores 3 y 4 fuerzan el control de acceso, pero los enrutadores 1 y 2 no lo hacen.
Además, el enrutador 2 no comprueba la posible suplantación de IP. El atacante suplanta la dirección de origen y,
al utilizar la opción de ruta de origen abierta, dirige el paquete a través del enrutador 2 hasta la red 2.2.2.0/24 y,
desde allí, al enrutador 1. Éste reenvía el paquete al enrutador 3, que lo reenvía hasta el dispositivo NetScreen.
Como el paquete procede de la subred 2.2.2.0/24 y contiene una dirección de origen de esa subred, aparece como
válido. Sin embargo, hay algo clave que aún no cuadra: la opción de ruta de origen abierta. En este ejemplo, ha
habilitado la opción SCREEN “Deny IP Source Route Option” para la zona Untrust. Cuando el paquete llega a
ethernet3, el dispositivo NetScreen lo rechaza.

El dispositivo NetScreen se puede habilitar para que bloquee cualquier paquete con opciones de ruta de origen
abiertas o estrictas o para que los detecte y, a continuación, registre el evento en la lista de contadores para la
interfaz de entrada. A continuación se ofrecen las opciones SCREEN:
• Deny IP Source Route Option: active esta opción para bloquear todo el tráfico IP que emplee la opción de
rutas de origen abierta o estricta. Las opciones de ruta de origen pueden llegar a permitir a un atacante
entrar en una red con una dirección IP falsa.
• Detect IP Loose Source Route Option: el dispositivo NetScreen detecta paquetes en los que la opción IP
sea 3 (Loose Source Routing) y registra el evento en la lista de contadores SCREEN para la interfaz de
entrada. Esta opción especifica una lista de rutas parcial que debe tomar un paquete en su trayecto desde
el punto de origen al de destino. El paquete debe avanzar en el orden de direcciones especificado, pero se
le permite atravesar otros enrutadores intermedios.
• Detect IP Strict Source Route Option: el dispositivo NetScreen detecta paquetes en los que la opción IP
sea 9 (Strict Source Routing) y registra el evento en la lista de contadores SCREEN para la interfaz de
entrada. Esta opción especifica la lista de rutas completa que debe tomar un paquete en su trayecto desde
el punto de origen al de destino. La última dirección de la lista sustituye a la dirección del campo de destino.
(Para obtener más información sobre todas las opciones IP, consulte “Reconocimiento de red mediante
opciones IP” en la página 14).
Para bloquear paquetes con la opción IP de ruta de origen abierta o estricta ajustada, utilice uno de los siguientes
métodos (la zona de seguridad especificada es la zona en la que se originó el paquete):
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione IP Source Route Option Filter y
haga clic en Apply.
CLI
set zone zone screen ip-filter-src

Para detectar y registrar (pero no bloquear) paquetes con la opción IP de ruta de origen abierta o estricta ajustada,
utilice uno de los siguientes métodos (la zona de seguridad especificada es la zona en la que se originó el paquete):
WebUI
Apply:
IP Loose Source Route Option Detection: (seleccione)
IP Strict Source Route Option Detection: (seleccione)
CLI
set zone zone screen ip-loose-src-route
set zone zone screen ip-strict-src-route


Capítulo 3
Defensas contra los ataques de denegación

3
de servicio
La intención de un ataque de denegación de servicio (DoS) es abrumar a la víctima potencial con tal cantidad de
tráfico simulado que se sature intentando procesar el tráfico fantasma y no consiga procesar el tráfico legítimo. El
destino del ataque puede ser el cortafuegos de NetScreen, los recursos de red cuyos accesos controla el
cortafuegos o la plataforma de hardware o el sistema operativo específico (OS) de un determinado host.
Cuando un ataque DoS se origina en múltiples direcciones de origen, se conoce como ataque distribuido de
denegación de servicio (“Distributed Denial-of-Service” o “DDoS”). Normalmente, la dirección de origen de un
ataque DoS es una dirección suplantada (“spoofed”). Las direcciones de origen de un ataque DDoS pueden ser
direcciones suplantadas o bien las direcciones reales de hosts previamente comprometidos por el atacante y que
éste utiliza ahora como “agentes zombie” para ejecutar su ataque.
El dispositivo NetScreen puede defenderse de ataques DoS y DDoS tanto a sí mismo como a los recursos que
protege. Las siguientes secciones describen las diversas opciones de defensa disponibles:
• “Ataques de DoS contra el cortafuegos” en la página 46
– “Inundación de la tabla de sesiones” en la página 46
– “Inundación proxy SYN-ACK-ACK” en la página 54
• “Ataques DoS contra la red” en la página 56
– “Inundación SYN” en la página 56
– “Inundación ICMP” en la página 73
– “Inundación UDP” en la página 75
– “Ataque terrestre (“Land Attack”)” en la página 77
• “Ataques de DoS específicos de cada sistema operativo” en la página 79
– ““Ping of Death”” en la página 79
– “Ataque “Teardrop”” en la página 81
– “WinNuke” en la página 83
Capítulo 3 Defensas contra los ataques de denegación de servicio Ataques de DoS contra el cortafuegos
ATAQUES DE DOS CONTRA EL CORTAFUEGOS

Si un atacante descubre la presencia del cortafuegos de NetScreen, puede ejecutar un ataque de denegación de
servicio (DoS) contra ese dispositivo, en lugar de intentar atacar a la red que se encuentra detrás. Un ataque DoS
que tenga éxito contra un cortafuegos desembocará en otro ataque DoS con éxito contra la red protegida,
frustrando los intentos del tráfico legítimo para atravesar el cortafuegos. En esta sección se explican dos métodos
que un atacante puede utilizar para llenar la tabla de sesiones de un dispositivo NetScreen y, de ese modo, producir
una DoS: “Inundación de la tabla de sesiones” y “Inundación proxy SYN-ACK-ACK”
Inundación de la tabla de sesiones

Un ataque DoS acertado abruma a su víctima con una cantidad tan ingente de tráfico falso que le impide procesar
las peticiones de conexión legítimas. Los ataques de DoS pueden adoptar muchas formas (inundación SYN,
inundación SYN-ACK-ACK, inundación UDP, inundación ICMP, etc.), pero todos persiguen el mismo objetivo: llenar
la tabla de sesiones de su víctima. Cuando la tabla de sesiones se llena, el host ya no puede crear ninguna sesión
nueva y comienza a rechazar nuevas peticiones de conexión. La siguiente opción de SCREEN ayuda a atenuar
esos ataques:
• “Límites de sesiones según sus orígenes y destinos”
• “Envejecimiento agresivo”
Límites de sesiones según sus orígenes y destinos

Además de limitar el número de sesiones simultáneas procedentes de la misma dirección IP de origen, también se
puede limitar el número de sesiones simultáneas hacia la misma dirección IP de destino. Una ventaja de establecer
un límite de sesión basado en su origen es que permite contener un ataque como el del virus Nimda (que realmente
es un virus y un gusano a la vez), que infecta un servidor y lo utiliza para generar cantidades masivas de tráfico.
Dado que todo el tráfico generado por un virus procede de la misma dirección IP, un límite de sesión basado en su
origen garantiza que el cortafuegos de NetScreen pueda retener tales cantidades excesivas de tráfico.

Limitación de sesiones según su

origen: Contención del tráfico del
virus/gusano Nimda Zona
Untrust
Un servidor web se infecta con el Cuando el número de sesiones

híbrido del virus/gusano Nimda, simultáneas del servidor infectado
que lo utiliza para generar
cantidades excesivas de tráfico. Zona … alcanza el límite máximo, el dispositivo
NetScreen comienza a bloquear todos
DMZ Servidor los intentos de conexión subsiguientes
infectado de ese servidor.
Otra ventaja de limitar una sesión basándose en su origen es reducir el número de intentos ilegítimos de llenar la
tabla de sesiones de NetScreen (siempre que todos esos intentos de conexión procedan de la misma dirección IP
de origen). Sin embargo, un atacante astuto podría ejecutar un ataque distribuido de denegación de servicio
(DDoS). En un ataque DDoS, el tráfico malévolo puede proceder de centenares de hosts, conocidos como “agentes
zombie”, que están subrepticiamente bajo el control de un atacante. Además de las opciones de detección de
inundaciones SYN, UDP e ICMP y de prevención SCREEN, estableciendo un límite de sesión basado en su destino
se puede garantizar que el dispositivo NetScreen admita solamente un número aceptable de peticiones de
conexión simultáneas (sin importar su origen) para alcanzar cualquier host.

Limitación de sesiones según su origen: Limitación de sesiones según su destino:

Ataque de denegación de servicio Ataque de denegación de servicio distribuido
Atacante Atacante
Host inexistente
IP origen: 6.6.6.6 Agentes
Zona Untrust zombie Zona
Untrust
Zona DMZ Zona DMZ
Servidor Servidor
web web
Cuando el número de sesiones simultáneas Cuando el número de sesiones simultáneas al

procedentes de 6.6.6.6 sobrepasa el límite servidor web sobrepasa el límite máximo, el
máximo, el dispositivo NetScreen bloquea dispositivo NetScreen bloquea cualquier
cualquier conexión subsiguiente de esa intento de conexión subsiguiente a esa
dirección IP. dirección IP.
Determinar cuál es el número aceptable de peticiones de conexión requiere un periodo de observación y análisis
para establecer una base de referencia con la que determinar los flujos de tráfico típicos. También se debe tener en
cuenta el número máximo de sesiones simultáneas requeridas para llenar la tabla de sesiones de la plataforma
NetScreen que se esté utilizando. Para consultar el número máximo de sesiones admitido por su tabla de sesiones,
ejecute el comando CLI get session y observe la primera línea del resultado, en la que se indica el número de
sesiones (asignadas) actuales, el número máximo de sesiones y el número de asignaciones de sesión infructuosas:
alloc 420/max 128000, alloc failed 0
El máximo predeterminado para los límites de sesiones según su origen y en su destino es de 128 sesiones
simultáneas, un valor que puede requerir ajustes para satisfacer las necesidades específicas de su entorno de red
y plataforma.

Ejemplo: Limitación de sesiones según su origen

En este ejemplo limitará el número de sesiones que cualquier servidor de las zonas DMZ y Trust puede iniciar.
Dado que la zona DMZ solamente contiene servidores web, ninguno de los cuales debería iniciar tráfico,
establecerá el límite de sesiones de origen en el valor más bajo posible: 1 sesión. Por otra parte, la zona Trust
contiene computadoras personales, servidores, impresoras y otros dispositivos, muchos de los cuales inician
tráfico. Para la zona Trust, establecerá el límite de sesiones de origen en un máximo de 80 sesiones simultáneas.
WebUI
Screening > Screen (Zone: DMZ): Introduzca los siguientes datos y haga clic en OK:
Source IP Based Session Limit: (seleccione)
Threshold: 1 Sessions
Screening > Screen (Zone: Trust): Introduzca los siguientes datos y haga clic en OK:
Source IP Based Session Limit: (seleccione)
CLI
set zone dmz screen limit-session source-ip-based 1
set zone dmz screen limit-session source-ip-based
set zone trust screen limit-session source-ip-based 80
set zone trust screen limit-session source-ip-based
save

Ejemplo: Limitación de sesiones según su destino

En este ejemplo, desea limitar la cantidad de tráfico dirigido a un servidor web en la dirección 1.2.2.5. El servidor se
encuentra en la zona DMZ. Después de observar el flujo de tráfico de la zona Untrust a este servidor durante un
mes, ha determinado que el número medio de sesiones simultáneas que recibe es 2000. De acuerdo con esta
información, decide establecer el nuevo límite de sesiones en 4000 sesiones simultáneas. Aunque sus
observaciones muestran que durante los picos de tráfico a veces se excede ese límite, opta por garantizar la
seguridad del cortafuegos a costa de alguna inaccesibilidad ocasional del servidor.
WebUI
Screening > Screen (Zone: Untrust): Introduzca los siguientes datos y haga clic en OK:
Destination IP Based Session Limit: (seleccione)
CLI
set zone untrust screen limit-session destination-ip-based 4000
set zone untrust screen limit-session destination-ip-based
save
Envejecimiento agresivo
De forma predeterminada, el establecimiento de comunicación inicial en 3 fases de una sesión TCP tarda 20
segundos en caducar (es decir, en expirar por inactividad). Una vez establecida una sesión TCP, el valor del tiempo
de espera cambia a 30 minutos. Para sesiones HTTP y UDP, los tiempos de espera son de 5 minutos y 1 minuto,
respectivamente. El temporizador de cada sesión se inicia al comenzar ésta y se actualiza cada 10 segundos
mientras la sesión permanece activa. Si una sesión queda inactiva durante más de 10 segundos, el temporizador
comienza la cuenta atrás.

NetScreen proporciona un mecanismo para acelerar el proceso del tiempo de espera cuando el número de
sesiones en la tabla de sesiones sobrepasa un umbral superior especificado. Cuando el número de sesiones cae
por debajo de un umbral inferior especificado, el proceso del tiempo de espera vuelve a su estado normal. Mientras
el proceso de envejecimiento agresivo esté activo, el dispositivo NetScreen forzará primero el envejecimiento de las
sesiones más antiguas, aplicándoles la tasa de envejecimiento previamente especificada. Estas sesiones de
envejecimiento forzado se marcan como no válidas y se eliminan en el siguiente “barrido de basura”, que ocurre
cada 2 segundos.
La opción de envejecimiento agresivo reduce los tiempos de espera predeterminados de las sesiones en la
1
magnitud introducida . El valor de envejecimiento agresivo puede estar entre 2 y 10 unidades, donde cada unidad
representa un intervalo de 10 segundos (es decir, el ajuste de envejecimiento agresivo puede tener un valor de 20
a 100 segundos). El ajuste predeterminado es de 2 unidades, equivalentes a 20 segundos. Si, por ejemplo,
establece el ajuste de envejecimiento agresivo en 100 segundos, acortará los tiempos de espera de sesiones HTTP
y TCP de la siguiente manera:
• TCP: El valor del tiempo de espera de la sesión se acorta de 1800 segundos (30 minutos) a 1700 segundos
(28:20 minutos) mientras el proceso de envejecimiento agresivo está activo. Durante ese periodo, el
dispositivo NetScreen elimina automáticamente todas las sesiones TCP cuyo valor de tiempo de espera
haya superado los 1700 segundos, comenzando por las sesiones más antiguas.
Min 30 25 20 15 10 5 0
Tiempo de espera predeterminado de la sesión TCP:
30 min (1800 seg)
Envejecimiento agresivo = 10 (predeterminado - 100 seg):
28:20 min (1700 seg) Seg 1800 1500 1200 900 600 300 0
1. Al establecer y habilitar la opción de envejecimiento agresivo, en la configuración seguirán apareciendo los valores normales de los tiempos de espera de
cada tipo de sesión (1800 segundos para sesiones TCP, 300 segundos para sesiones HTTP y 60 segundos para sesiones UDP). Sin embargo, cuando se
activa el periodo de envejecimiento agresivo, estas sesiones caducan antes (aplicando el tiempo especificado para envejecimientos prematuros en lugar
de la cuenta atrás hasta cero).

• HTTP: El valor del tiempo de espera de la sesión se acorta de 300 segundos (5 minutos) a 200 segundos
(3:20 minutos) mientras el proceso de envejecimiento agresivo está activo. Durante ese periodo, el
dispositivo NetScreen elimina automáticamente todas las sesiones HTTP cuyo valor de tiempo de espera
haya superado los 200 segundos, comenzando por las sesiones más antiguas.
Min 5 4 3 2 1 0
Tiempo de espera predeterminado de la sesión HTTP:
5 min (300 seg)
Envejecimiento agresivo = 10 (predeterminado - 100 seg):
3:20 min (200 seg) Seg 300 240 180 120 60 0
• UDP: Dado que el tiempo de espera predeterminado de una sesión UDP es de 60 segundos, definiendo un
ajuste de envejecimiento prematuro de 100 segundos se provoca que todas las sesiones UDP envejezcan
y queden marcadas para su eliminación en el siguiente “barrido de basura”.

Ejemplo: Forzar el envejecimiento agresivo de sesiones

En este ejemplo establecerá que el proceso de envejecimiento agresivo comience cuando el tráfico supere un
umbral superior del 80% y finalice cuando caiga por debajo de un umbral inferior del 70%. Especificará 40
segundos como intervalo de envejecimiento agresivo. Cuando la tabla de sesiones se llena más del 80% (el umbral
superior), el dispositivo NetScreen reduce en 40 segundos el tiempo de espera de todas las sesiones y comienza a
forzar agresivamente el envejecimiento de las sesiones más antiguas hasta que el número de sesiones en la tabla
cae por debajo del 70% (el umbral inferior).
Capacidad de la 100%
tabla de sesiones Cuando el número de sesiones supera la capacidad
del 80%, se activa el mecanismo de envejecimiento
agresivo.
80%
}
Umbral superior Envejecimiento
agresivo
70% Umbral inferior (- 40 seg de
envejecimiento
Las sesiones envejecen forzadamente hasta forzado)
que su número cae por debajo del 70%. En ese
Sesiones momento, el mecanismo de envejecimiento
agresivo se detiene.
0%
WebUI
Nota: Para configurar los ajustes de envejecimiento agresivo debe utilizar la interfaz de línea de comandos
(“CLI”).
CLI
set flow aging low-watermark 70
set flow aging high-watermark 80
set flow aging early-ageout 4
save

Inundación proxy SYN-ACK-ACK

Cuando un usuario de autenticación inicia una conexión Telnet o FTP, envía un segmento SYN al servidor Telnet o
FTP correspondiente. El dispositivo NetScreen intercepta el segmento SYN, crea una entrada en su tabla de
sesiones y envía al usuario un segmento SYN-ACK a través del proxy. El usuario responde entonces con un
segmento ACK. En ese momento se completa el establecimiento inicial de comunicación en 3 fases. El dispositivo
NetScreen envía al usuario un mensaje de petición de inicio de sesión. Si el usuario malévolo, en lugar de iniciar la
sesión, continúa iniciando sesiones SYN-ACK-ACK, la tabla de sesiones de NetScreen puede llenarse hasta el
punto en que el dispositivo comience a rechazar peticiones de conexión legítimas.
Cliente Telnet o FTP Servidor

(usuario de Telnet o FTP
autenticación)
Zona Untrust Zona Trust
1. El cliente envía un
segmento SYN al servidor. 1 SYN
2. El dispositivo NetScreen Tabla de sesiones de NetScreen:

envía un segmento SYN/ACK 2 Muchos recursos disponibles
SYN/ACK a través del
proxy.
3. El cliente responde con 3 ACK
un segmento ACK.
4. El dispositivo NetScreen Nombre: ?
4
solicita al cliente (usuario Contraseña: ?
de autenticación) que inicie
una sesión.
5 SYN
5. El cliente ignora el
mensaje de petición de SYN/ACK
inicio de sesión y sigue La tabla de sesiones se está
repitiendo los pasos 1 a 4 ACK
llenando.
hasta llenar la tabla de
sesiones de NetScreen). Nombre: ?
Contraseña: ?
6. Al estar la tabla de .
sesiones completa, el .
dispositivo NetScreen .
debe rechazar todas las La tabla de sesiones está llena.
demás peticiones de 6 SYN
conexión.

Para frustrar tal ataque, puede habilitar la opción SCREEN de protección SYN-ACK-ACK del proxy. Cuando el
número de conexiones procedentes de una misma dirección IP alcanza el umbral de SYN-ACK-ACK del proxy, el
dispositivo NetScreen rechaza las peticiones de conexión subsiguientes de esa dirección IP. De forma
predeterminada, el umbral es de 512 conexiones de una determinada dirección IP. Puede cambiar este umbral (a
cualquier número entre 1 y 250.000) para adaptarse mejor a los requisitos de su entorno de red.
Para habilitar la protección contra una inundación SYN-ACK-ACK del proxy, ejecute cualquiera de los siguientes
procedimientos, donde la zona especificada es aquélla en la que se origina el ataque:
WebUI
Apply:
SYN-ACK-ACK Proxy Protection: (seleccione)
Threshold: (introduzca un valor para activar la protección contra la
2
inundación SYN-ACK-ACK del proxy )
CLI
set zone zone screen syn-ack-ack-proxy threshold number
set zone zone screen syn-ack-ack-proxy
2. La unidad de este valor se expresa en conexiones por dirección de origen. El valor predeterminado es de 512 conexiones de una determinada dirección IP.

Capítulo 3 Defensas contra los ataques de denegación de servicio Ataques DoS contra la red
ATAQUES DOS CONTRA LA RED

Un ataque de denegación de servicio (DoS) dirigido contra unos o más recursos de red inunda el destino con una
cantidad abrumadora de paquetes SYN, ICMP o UDP, o de fragmentos SYN. Dependiendo del objetivo del
atacante y del nivel y éxito de los esfuerzos de prevención realizados hasta ese momento, el atacante puede
seleccionar un host específico, como un enrutador o un servidor, o bien seleccionar hosts de forma aleatoria en la
red atacada. Cualquiera de las dos tácticas tiene el potencial de trastornar el servicio a un solo host o a la red
entera, dependiendo de la importancia del papel desempeñado por la víctima en el contexto de su red.
Inundación SYN
Una inundación SYN ocurre cuando un host resulta tan saturado con segmentos SYN que inician peticiones de
conexión irrealizables que le resulta imposible procesar peticiones de conexión legítimas.
Dos hosts establecen una conexión TCP con triple intercambio de segmentos TCP, conocido como establecimiento
de conexión en tres fases: A envía un segmento SYN a B; B responde con un segmento SYN; A responde con un
segmento ACK. Un ataque de inundación SYN inunda un sitio con segmentos SYN que contienen direcciones IP de
origen falsificadas (“suplantadas” o “spoofed”), es decir, inexistentes o inalcanzables. B responde enviando
segmentos SYN/ACK a estas direcciones y espera segmentos ACK de respuesta. Como los segmentos SYN/ACK
se envían a direcciones IP inexistentes o inalcanzables, nunca obtienen respuesta y acaban por superar el tiempo
de espera.
Dirección IP
real El host en 2.2.2.5 envía segmentos Si una directiva permite el tráfico entrante, el dispositivo
2.2.2.5 SYN en paquetes IP con NetScreen permite los segmentos SYN. La víctima responde
direcciones de origen suplantadas. enviando segmentos SYN/ACK a la dirección IP de origen
Direcciones IP simulada, quedando a la espera de respuesta hasta que los
inexistentes o intentos caducan.
inalcanzables
3.3.3.5 SYN LAN
protegida
? SYN/ACK
4.4.4.20 SYN
? SYN/ACK
SYN El búfer de memoria
5.5.5.10
? SYN/ACK de la víctima
comienza a
SYN llenarse.
6.6.6.3 ? SYN/ACK

Inundando un host con conexiones TCP no completables, el atacante acabará por llenar el búfer de memoria de la
víctima. Cuando este búfer se llena, el host ya no puede procesar nuevas peticiones de conexión TCP. La
inundación puede incluso dañar el sistema operativo de la víctima. En cualquier caso, el ataque inhabilita a la
víctima y sus operaciones normales.
Protección contra inundaciones SYN
Los dispositivos NetScreen pueden imponer un límite al número de segmentos SYN a los que se permite atravesar
el cortafuegos cada segundo. Puede definir el umbral de ataque en función de la dirección de destino y el puerto,
sólo en función de la dirección de destino o sólo en función de la dirección de origen. Cuando el número de
segmentos SYN por segundo supera uno de estos umbrales, el dispositivo NetScreen inicia el procesamiento de
segmentos SYN entrantes mediante el proxy, respondiendo con segmentos SYN/ACK y almacenando las
peticiones de conexión incompletas en una cola de conexiones. Las peticiones de conexión incompletas
permanecen en la cola hasta que la conexión se haya completado o la petición haya caducado. En la ilustración
siguiente, se ha atravesado el umbral de ataque SYN y el dispositivo NetScreen ha comenzado a procesar
segmentos SYN mediante el proxy.

Dirección IP real El host con la dirección 2.2.2.5 continúa enviando

2.2.2.5 segmentos SYN en paquetes IP con direcciones de
origen suplantadas.
Direcciones IP
inexistentes o
inalcanzables
7.7.7.11 SYN LAN
protegida
? SYN/ACK
8.8.8.8 SYN
? SYN/ACK
9.9.9.22
El búfer de memoria de
— Umbral de ataque SYN — la víctima deja de
llenarse.
2.2.2.4 SYN Cuando el número de segmentos
SYN procedentes de una misma
? SYN/ACK dirección de origen o dirigidos a la
misma dirección de destino alcanza
3.3.3.25 SYN un umbral especificado, el dispositivo
La cola de conexiones
NetScreen comienza a interceptar las procesada por proxy del
? SYN/ACK peticiones de conexión y a procesar
dispositivo NetScreen
. los segmentos SYN/ACK mediante el
comienza a llenarse.
. proxy.
.

En la siguiente ilustración, la cola de conexiones procesada por proxy se ha llenado totalmente y el dispositivo
NetScreen rechaza nuevos segmentos SYN entrantes. Esta acción blinda los hosts de la red protegida contra el
bombardeo de establecimientos de conexión en tres fases incompletos.
Dirección IP El host con la dirección 2.2.2.5 continúa enviando segmentos

real SYN en paquetes IP con la dirección de origen suplantada
2.2.2.5 3.3.3.5.
Dirección IP
3.3.3.5 LAN
inexistente o protegida
inalcanzable
— Umbral de ataque SYN —
SYN El dispositivo NetScreen
intercepta los segmentos SYN y
? SYN/ACK procesa por proxy las respuestas El búfer de memoria de
SYN/ACK hasta que la cola de la víctima recupera su
SYN conexiones procesada por proxy estado normal.
se llena.
? SYN/ACK
— Umbral de alarma —
. El dispositivo NetScreen introduce
. una alarma en el registro de La cola de conexiones
. eventos. procesada por proxy del
dispositivo NetScreen
— Limite máximo de la cola de conexiones procesada por proxy — está llena.
El dispositivo NetScreen rechaza
nuevos segmentos SYN de todas
las direcciones de la misma zona de
SYN seguridad.
Segmento SYN de otra dirección de
la misma zona de seguridad.

El dispositivo NetScreen inicia la recepción de nuevos paquetes SYN cuando la cola del proxy cae por debajo del
límite máximo.
Nota: El procedimiento de procesar por proxy las conexiones SYN incompletas por encima de un umbral
establecido afecta solamente al tráfico permitido por las directivas existentes. Cualquier tráfico para el que no
exista una directiva se descarta automáticamente.
Para habilitar la opción SCREEN de protección contra inundaciones SYN y definir sus parámetros, ejecute
cualquiera de los siguientes procedimientos, donde la zona especificada es aquélla en la que puede originarse una
inundación:
WebUI
Apply:
SYN Flood Protection: (seleccione para habilitar)
Threshold: (introduzca el número de segmentos SYN -es decir, de
segmentos TCP con el flag SYN activado- requeridos por segundo para
activar el mecanismo de procesamiento de SYN por proxy3)
Alarm Threshold: (introduzca el número de peticiones de conexión TCP
procesadas por proxy requeridas para generar una alarma en el registro
de eventos)
Source Threshold: (introduzca el número de paquetes SYN por segundo
procedentes de una determinada dirección IP que se requiere para que
el dispositivo NetScreen comience a rechazar nuevas peticiones de
conexión de ese origen)
3. Para obtener más detalles sobre cada uno de estos parámetros, consulte las descripciones en la siguiente sección de CLI.

Destination Threshold: (introduzca el número de paquetes SYN por

segundo dirigidos a una determinada dirección IP que se requiere para
que el dispositivo NetScreen comience a rechazar nuevas peticiones de
conexión hacia ese destino)
Timeout Value: (introduzca la duración en segundos que el dispositivo
NetScreen mantiene un intento de conexión TCP incompleto en la cola
de conexiones procesada por proxy)
Queue Size: (introduzca el número de peticiones de conexión TCP
procesadas por proxy que se mantienen en la cola de conexiones
procesada por proxy antes de que el dispositivo NetScreen comience a
rechazar nuevas peticiones de conexión)

CLI
Para habilitar la protección contra inundaciones SYN.
set zone zone screen syn-flood
Para procesar por proxy las peticiones de conexión TCP inacabadas puede establecer los siguientes
parámetros:
Attack Threshold: El número de segmentos SYN (es decir, segmentos TCP con el flag SYN activado)
dirigidos a la misma dirección de destino y número de puerto requeridos por segundo para activar el
mecanismo de procesamiento de SYN por proxy. Aunque se puede ajustar el umbral en cualquier número,
es necesario conocer los patrones de tráfico habituales en cada instalación para establecer un umbral
adecuado. Por ejemplo, en un sitio “e-business” que normalmente recibe 20.000 segmentos SYN por
segundo, conviene establecer un umbral de, por ejemplo, 30.000 por segundo. Si un sitio más pequeño
recibe habitualmente 20 segmentos SYN por segundo, plantéese establecer el umbral en 40.
set zone zone screen syn-flood attack-threshold number
Alarm Threshold: El número de peticiones de conexión TCP semicompletas procesadas por proxy por
segundo que el dispositivo NetScreen espera para introducir una alarma en el registro de eventos. El valor
establecido para un umbral de alarma dispara una alarma cuando el número por segundo de peticiones de
conexión semicompletadas y procesadas por proxy dirigidas a la misma dirección de destino y número de
puerto supera ese valor. Por ejemplo, si se establece el umbral de ataque SYN en 2000 segmentos SYN
por segundo y la alarma en 1000, se requiere un total de 3001 segmentos SYN por segundo dirigidos a la
misma dirección de destino y número de puerto para generar una entrada de alarma en el registro. Más
precisamente:
1. El cortafuegos deja pasar los primeros 2000 segmentos SYN por segundo que cumplen los requisitos
de las directivas.
2. El cortafuegos procesa por proxy los 1000 segmentos SYN siguientes en el mismo segundo.
3. La 1001ª petición de conexión procesada por proxy (o la 3001ª petición de conexión en ese mismo
segundo) dispara la alarma.
set zone zone screen syn-flood alarm-threshold number

Por cada segmento SYN dirigido a la misma dirección y número de puerto de destino que sobrepase el
umbral de alarma, el módulo de detección de ataques genera un mensaje. Al final del segundo, el módulo
de registro comprime todos los mensajes similares en una sola entrada del registro que indica cuántos
segmentos SYN dirigidos a la misma dirección y número de puerto de destino llegaron después de haberse
rebasado el umbral de alarma. Si el ataque persiste más allá del primer segundo, el registro de eventos
introduce una alarma cada segundo hasta que el ataque se detenga.
Source Threshold: Esta opción permite especificar el número de segmentos SYN que deben recibirse por
segundo de una determinada dirección IP de origen (sin tener en cuenta la dirección IP y el número de
puerto de destino) antes de que el dispositivo NetScreen comience a descartar peticiones de conexión de
ese origen.
set zone zone screen syn-flood source-threshold number
El seguimiento de una inundación SYN por su dirección de origen utiliza otros parámetros de detección que
el seguimiento de una inundación SYN por dirección y número de puerto de destino. Cuando se establece
un umbral de ataque SYN y un umbral de origen, se activan tanto el mecanismo básico de protección
contra inundaciones SYN como el mecanismo de seguimiento de inundaciones SYN basado en sus
orígenes.
Destination Threshold: Esta opción permite especificar el número de segmentos SYN por segundo que
puede recibir una determinada dirección IP de destino antes de que el dispositivo NetScreen comience a
descartar peticiones de conexión a ese destino. Cuando un host protegido ejecuta múltiples servicios,
conviene establecer un umbral basado exclusivamente en la dirección IP de destino, sin importar el número
de puerto de destino.
set zone zone screen syn-flood destination-threshold number
Cuando se establece un umbral de origen SYN y un umbral de destino, se activan tanto el mecanismo
básico de protección contra inundaciones SYN como el mecanismo de seguimiento de inundaciones SYN
basado en sus destinos.
El seguimiento de una inundación SYN por su dirección de destino utiliza otros parámetros de detección
que el seguimiento de una inundación SYN por dirección y número de puerto de destino. Observe el caso
siguiente, donde el dispositivo NetScreen tiene directivas que permiten realizar peticiones FTP (puerto 21)
y peticiones HTTP (puerto 80) al mismo servidor. Si el umbral de ataque para inundaciones SYN es de

1000 paquetes por segundo (pps) y un atacante envía 999 paquetes FTP y 999 paquetes HTTP por
segundo, ninguno de ambos conjunto de paquetes (entendiendo por conjunto los paquetes que comparten
la misma dirección y número de puerto de destino) activa el mecanismo de procesamiento de SYN por
proxy. El mecanismo básico de ataque de inundación SYN realiza el seguimiento de direcciones y números
de puerto de destino, y ninguno de los conjuntos supera el umbral de ataque de 1000 paquetes por
segundo. Sin embargo, si el umbral de destino es de 1000 pps, el dispositivo NetScreen trata los paquetes
FTP y HTTP con la misma dirección de destino que los miembros de un solo conjunto y rechaza el 1001º
paquete —FTP o HTTP— dirigido a ese destino.
Timeout: El tiempo máximo antes de que una conexión semicompleta sea descartada de la cola. El valor
predeterminado es de 20 segundos, pero se puede establecer entre 0 y 50 segundos. Intente reducir el
valor del tiempo de espera hasta que comience a ver conexiones descartadas en condiciones normales de
tráfico. Veinte segundos representan un tiempo de espera muy conservador para una respuesta ACK a un
establecimiento de comunicación de 3 fases.
set zone zone screen syn-flood timeout number
Queue size: El número de peticiones de conexión procesadas por proxy que se pueden retener en la cola
de conexiones procesada por proxy antes de que el dispositivo NetScreen comience a rechazar nuevas
peticiones de conexión. Cuanto mayor sea el tamaño de la cola, más tarda el dispositivo NetScreen en
analizarla para encontrar una respuesta ACK válida a una petición de conexión procesada por proxy. Esto
puede retardar ligeramente el establecimiento inicial de la conexión; sin embargo, como el tiempo que debe
transcurrir antes de poder comenzar la transferencia de datos es normalmente muy superior al de cualquier
retraso menor en la configuración inicial de la conexión, los usuarios no percibirán una diferencia notable.
set zone zone screen syn-flood queue-size number
Drop Unknown MAC: Cuando un dispositivo NetScreen detecta un ataque SYN, procesa por proxy todas
las peticiones de conexión TCP. Sin embargo, un dispositivo NetScreen en modo transparente no puede
procesar por proxy una petición de conexión TCP si la dirección MAC de destino no está en su tabla de
aprendizaje de MAC. De forma predeterminada, un dispositivo NetScreen en modo transparente que ha
detectado un ataque SYN entrega paquetes SYN que contienen direcciones MAC desconocidas. Puede
utilizar esta opción para ordenar al dispositivo que descarte los paquetes SYN que contienen direcciones
MAC de destino desconocidas en lugar de permitirles el paso.
set zone zone screen syn-flood drop-unknown-mac

Ejemplo: Protección contra inundaciones SYN

En este ejemplo protegerá cuatro servidores web en la zona DMZ contra ataques de inundación SYN originados en
la zona Untrust habilitando la opción SCREEN de protección contra inundaciones SYN para la zona Untrust.
Nota: NetScreen recomienda aumentar la protección contra inundaciones SYN incorporada en el dispositivo
NetScreen con la protección contra inundaciones SYN a nivel de dispositivo en cada uno de los servidores web. En
este ejemplo, los servidores web funcionan con el sistema operativo UNIX, que también proporciona algunas
defensas contra inundaciones SYN, como ajustar el tamaño de la cola de peticiones de conexión y modificar el
tiempo de espera para las peticiones de conexión incompletas.
Servidores web
ethernet3 ethernet2
1.1.1.1/24 1.2.2.1/24
Zona Untrust 1.2.2.10
Dispositivo
NetScreen
1.2.2.20
Internet Zona DMZ
HTTP 1.2.2.30
Inundación SYN
1.2.2.40
Cortafuegos

Para configurar los parámetros de protección contra inundaciones SYN con los valores apropiados para su red,
primero debe establecer una línea de base de los flujos de tráfico típicos. Durante una semana, ejecute un
4
programa rastreador sobre ethernet3 (la interfaz asociada a la zona Untrust) para supervisar el número de nuevas
peticiones de conexión TCP que llegan cada segundo a los cuatro servidores web en DMZ5. Su análisis de los
datos acumulados durante una semana de supervisión produce la estadística siguiente:
• Promedio de nuevas peticiones de conexión por servidor: 250 por segundo
• Promedio de máximos de peticiones de conexión por servidor: 500 por segundo
De acuerdo con esta información, establecerá los siguientes parámetros de protección contra inundaciones SYN
para la zona Untrust:
Parámetros Valores Motivo para cada valor
Attack 625 paquetes por Esto supera en un 25% al promedio de picos de nuevas peticiones de conexión
Threshold segundo (pps) por segundo por servidor, algo inusual para este entorno de red. Cuando el
(Umbral de número de paquetes SYN por segundo de cualquiera de los cuatro servidores
ataque) web supera este número, el dispositivo NetScreen comienza a procesar por
proxy las nuevas peticiones de conexión dirigidas a ese servidor. (En otras
palabras, comenzando por el 626º paquete SYN dirigido a la misma dirección y
número de puerto de destino en un mismo segundo, el dispositivo NetScreen
comienza a procesar por proxy las peticiones de conexión dirigidas a esa
dirección y número de puerto).
4. Un programa rastreador es un dispositivo analizador de red que captura paquetes en el segmento de red al que está conectado. La mayoría de los
programas rastreadores permiten definir filtros para recopilar solamente el tipo de tráfico que interese. Después podrá visualizar y evaluar la información
acumulada. En este ejemplo se desea que el programa rastreador recoja todos los paquetes TCP con el flag SYN activado que lleguen a ethernet3 y estén
destinados a uno de los cuatro servidores web en DMZ.
5. Siga ejecutando el programa rastreador a intervalos periódicos comprobando si existen patrones de tráfico basados en la hora, el día de la semana, la fase
del mes o la estación del año. Por ejemplo, el tráfico puede aumentar espectacularmente durante las Navidades. Si detecta cambios significativos,
probablemente esté justificado ajustar los diferentes umbrales.

Alarm 250 pps 250 pps es 1/4 del tamaño de la cola (1000 peticiones de conexión
*
Threshold semicompletas y procesadas por proxy ). Cuando el dispositivo NetScreen
(Umbral de procesa por proxy 251 nuevas peticiones de conexión en un segundo, genera
alarma) una entrada de alarma en el registro de eventos. Aumentando ligeramente el
umbral de alarma por encima del umbral de ataque, puede evitar las entradas de
alarma generadas por picos de tráfico que solamente exceden levemente el
umbral de ataque.
Source 25 pps Cuando se establece un umbral de origen, el dispositivo NetScreen rastrea la

Threshold dirección IP de origen de los paquetes SYN, sin importar la dirección y el número
(Umbral de de puerto de destino. (Observe que este seguimiento basado en orígenes es
origen) independiente del seguimiento de paquetes SYN basado en la dirección y el
número de puerto de destino, que constituye el mecanismo básico de protección
contra inundaciones SYN).
Durante la semana de supervisión, observó que no más de una cuarta parte de
las nuevas peticiones de conexión para todos los servidores procedía de algún
origen dentro de un intervalo de un segundo. Por lo tanto, las peticiones de
conexión que superan este umbral son poco habituales y son causa suficiente
para que el dispositivo NetScreen ejecute su mecanismo de procesamiento por
proxy. (25 pps es 1/25 del umbral de ataque, que es de 625 pps.)
Si el dispositivo NetScreen detecta 25 paquetes SYN procedentes de la misma
dirección IP de origen, a partir del vigésimo sexto paquete rechazará los demás
paquetes SYN de ese origen durante el resto de ese segundo y también durante
el segundo siguiente.

Destination 0 pps Cuando se establece un umbral de destino, el dispositivo NetScreen ejecuta un

Threshold seguimiento separado solamente de la dirección IP de destino, sin importar el
(Umbral de número de puerto de destino. Debido a que los cuatro servidores web reciben
destino) solamente tráfico HTTP (puerto de destino 80) y no les llega ningún tráfico
dirigido a ningún otro número de puerto de destino, establecer un umbral de
destino separado no aporta ninguna ventaja adicional.
Timeout 20 segundos Dado que el tamaño de la cola es relativamente pequeño (1000 peticiones de
(Tiempo de conexión procesadas por proxy), el valor predeterminado de 20 segundos es un
espera) tiempo razonable para mantener las peticiones de conexión incompletas en cola
para esta configuración.
Queue Size 1000 conexiones 1000 peticiones de conexión semicompletas procesadas por proxy es dos veces
(Tamaño de la semicompletas el promedio de picos de nuevas peticiones de conexión (500 pps). El dispositivo
cola) procesadas por NetScreen procesa por proxy hasta 1000 peticiones por segundo antes de
proxy descartar nuevas peticiones. Procesar por proxy el doble del promedio de picos
de nuevas peticiones de conexión proporciona un “colchón” suficiente como para
que puedan pasar las peticiones de conexión legítimas.
*
Las peticiones de conexión semicompletas son establecimientos de conexión en tres fases incompletos. Un establecimiento de conexión en
tres fases es la fase inicial de una conexión TCP. Consiste en un segmento TCP con el flag SYN activado, una respuesta con los flag SYN y
ACK activados y una respuesta a ésta con el flag ACK activado. Para ver una descripción completa, consulte “Glosario” en el volumen 1, “Vista
general”.
WebUI
1. Interfaces
Zone Name: DMZ
Static IP: (seleccione esta opción cuando sea posible)

Network > Interfaces > Edit (para ethernet3): Introduzca los siguientes datos y haga clic en OK :
Zone Name: Untrust
Static IP: (seleccione esta opción cuando sea posible)
2. Direcciones
Address Name: ws1
Zone: DMZ
Address Name: ws2
Zone: DMZ
Address Name: ws3
Zone: DMZ

Address Name: ws4
Zone: DMZ
Objects > Addresses > Groups > (para Zone: DMZ) New: Introduzca el siguiente nombre de grupo, mueva
las siguientes direcciones y haga clic en OK:
Group Name: web_servers
Seleccione ws1 y utilice el botón << para trasladar la dirección de la
columna “Available Members” a la columna “Group Members”.
3. Directiva
Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Any
Destination Address:
Address Book Entry: (seleccione), web_servers
Service: HTTP
Action: Permit

4. SCREEN
Screening > Screen (Zone: Untrust): Introduzca los siguientes datos y haga clic en Apply:
SYN Flood Protection: (seleccione)
Threshold: 625
Alarm Threshold: 250
Source Threshold: 25
Destination Threshold: 0
6
Timeout Value: 20
Queue Size: 1000
6. Al ser 20 segundos el ajuste predeterminado, no es necesario establecer el tiempo de espera en 20 segundos a menos que lo haya establecido previamente
en otro valor.

CLI
1. Interfaces

2. Direcciones
set address dmz ws1 1.2.2.10/32
set group address dmz web_servers add ws1

3. Directiva
set policy from untrust to dmz any web_servers HTTP permit
4. SCREEN
set zone untrust screen syn-flood attack-threshold 625
set zone untrust screen syn-flood alarm-threshold 250
set zone untrust screen syn-flood source-threshold 25
7
set zone untrust screen syn-flood timeout 20
set zone untrust screen syn-flood queue-size 1000
set zone untrust screen syn-flood
save
7. Al ser 20 segundos el ajuste predeterminado, no es necesario establecer el tiempo de espera en 20 segundos a menos que lo haya establecido previamente
en otro valor.

Inundación ICMP
Una inundación ICMP se produce cuando las peticiones de eco ICMP sobrecargan a su víctima con tantas
peticiones que ésta consume todos sus recursos en responder, hasta que le resulta imposible procesar el tráfico de
red válido. Al habilitar la función de protección contra inundaciones ICMP, puede establecer un umbral que, al ser
excedido, activa la función de protección contra ataques de inundación ICMP. (El valor predeterminado del umbral
es 1000 paquetes por segundo). Si se excede este umbral, el dispositivo NetScreen ignora otras peticiones de eco
ICMP durante el resto de ese segundo y también durante el segundo siguiente.
El atacante envía peticiones de eco ICMP El dispositivo NetScreen deja pasar las peticiones
con direcciones de origen simuladas. de eco sólo si alguna directiva lo permite.
Petición de eco
LAN
? Respuesta protegida
Peticiones de de eco
eco ICMP Petición de eco
procedentes de
diversas ? Respuesta
direcciones IP de eco
simuladas
Petición de eco
? Respuesta
. de eco
.
.
— Límite máximo de peticiones de eco ICMP por segundo —
Petición de eco Una vez alcanzado el umbral de

ICMP, el dispositivo NetScreen
rechaza las peticiones de eco
ICMP subsiguientes de todas las
Petición de eco direcciones de la misma zona de
seguridad durante el resto del
Petición de eco ICMP legítima de una segundo actual y también
dirección en la misma zona de durante el segundo siguiente.
seguridad

Para habilitar la protección contra inundaciones ICMP, ejecute cualquiera de los siguientes procedimientos, donde
la zona especificada es aquélla en la que puede originarse una inundación:
WebUI
Apply:
ICMP Flood Protection: (seleccione)
Threshold: (introduzca el valor a partir del cual debe activarse la protección
contra inundaciones ICMP8)
CLI
set zone zone screen icmp-flood threshold number
set zone zone screen icmp-flood
8. La unidad de este valor se expresa en paquetes ICMP por segundo. El valor predeterminado es de 1000 paquetes por segundo.

Inundación UDP
De forma parecida a una inundación ICMP, una inundación UDP ocurre cuando un atacante envía paquetes IP que
contienen datagramas UDP con el propósito de ralentizar a la víctima hasta que le resulta imposible procesar las
conexiones válidas. Después de habilitar la función de protección contra inundaciones UDP, puede establecer un
umbral que, al ser excedido, activa la función de protección contra ataques de inundación UDP. (El valor
predeterminado del umbral es 1000 paquetes por segundo). Si el número de datagramas UDP de uno o más
orígenes a un destino determinado supera este umbral, el dispositivo NetScreen ignora los datagramas UDP
subsiguientes dirigidos a ese destino durante el resto de ese segundo y también durante el segundo siguiente.
El atacante envía datagramas UDP en El dispositivo NetScreen deja pasar los datagramas
paquetes IP con direcciones de origen UDP sólo si alguna directiva lo permite.
simuladas.
LAN protegida
Datagrama UDP Servidor DNS
Datagramas Los datagramas IP: 1.2.2.5
UDP dentro de apuntan a un servidor Puerto: 53
los paquetes IP DNS en 1.2.2.5:53. (UDP)
de una variedad Datagrama UDP
de direcciones IP
simuladas
Datagrama UDP
.
.
.
— Límite máximo de datagramas UDP por segundo —
Datagrama UDP Una vez alcanzado el umbral de

inundación UDP, el dispositivo
NetScreen rechaza los
datagramas UDP subsiguientes
Datagrama UDP de todas las direcciones de la
misma zona de seguridad
Datagrama UDP legítimo desde una durante el resto del segundo
dirección de la misma zona de actual y también durante el
seguridad segundo siguiente.

Para habilitar la protección contra inundaciones UDP, ejecute cualquiera de los siguientes procedimientos, donde la
zona especificada es aquélla en la que puede originarse una inundación:
WebUI
Apply:
UDP Flood Protection: (seleccione)
Threshold: (introduzca el valor a partir del cual debe activarse la protección
contra inundaciones UDP9)
CLI
set zone zone screen udp-flood threshold number
set zone zone screen udp-flood
9. La unidad de este valor se expresa en paquetes UDP por segundo. El valor predeterminado es de 1000 paquetes por segundo.

Ataque terrestre (“Land Attack”)

Combinando un ataque SYN con la suplantación de direcciones IP, un ataque terrestre ocurre cuando un atacante
envía paquetes SYN suplantados que contienen la dirección IP de la víctima como dirección IP de destino y
dirección IP de origen. El sistema receptor responde enviándose a sí mismo el paquete SYN-ACK, creando una
conexión vacía que perdura hasta que caduca el tiempo de espera por inactividad. Inundar un sistema con tales
conexiones vacías puede saturarlo y provocar la denegación de servicio (“DoS”).
Atacante Tanto la dirección de origen como la de Víctima

destino son las de la víctima. La dirección
de origen que aparece en el encabezado
IP es simulada, mientras que la dirección La víctima crea conexiones
de origen verdadera permanece oculta. vacías consigo misma.
Origen Destino
1.2.2.5 1.2.2.5 Datos

Los recursos
disponibles de la
víctima
Origen Destino
1.2.2.5 1.2.2.5 Datos

Las conexiones
vacías están
consumiendo los
recursos de la
Origen Destino víctima.
1.2.2.5 1.2.2.5 Datos

Todos los recursos
están consumidos,
lo cual impide las
operaciones
normales.

Cuando se habilita la opción SCREEN para bloquear ataques terrestres, el dispositivo NetScreen combina
elementos de la defensa contra inundaciones SYN y de la protección contra la suplantación de direcciones IP para
detectar y bloquear cualquier intento de esta naturaleza.
Para habilitar la protección contra ataques terrestres, ejecute cualquiera de los siguientes procedimientos, donde la
zona especificada es aquélla en la que se origina el ataque:
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione Land Attack Protection y haga
clic en Apply.
CLI
set zone zone screen land

Capítulo 3 Defensas contra los ataques de denegación de servicio Ataques de DoS específicos de cada sistema operativo
ATAQUES DE DOS ESPECÍFICOS DE CADA SISTEMA OPERATIVO

Si un atacante identifica no sólo la dirección IP y los números de puerto accesibles de un host activo, sino también
su sistema operativo (OS), en lugar de utilizar “ataques de fuerza bruta” (“brute-force attacks”), puede atacar de
forma más sutil “liquidando” uno o dos paquetes. Los ataques presentados en esta sección pueden inutilizar un
sistema con un esfuerzo mínimo. Si su dispositivo NetScreen protege a hosts susceptibles a estos ataques, puede
habilitar el dispositivo NetScreen para detectar dichos ataques y bloquearlos antes de que alcancen su destino.
“Ping of Death”
El tamaño máximo admisible de un paquete IP es de 65.535 bytes, incluyendo el encabezado del paquete, que
habitualmente mide 20 bytes10. Una petición de eco ICMP es un paquete IP con un pseudoencabezado de 8
11
bytes . Por lo tanto, el tamaño máximo admisible del área de datos de una petición de eco ICMP es de 65.507
bytes (65.535 - 20 - 8 = 65.507).
Sin embargo, muchas implementaciones del comando ping permiten al usuario especificar un tamaño del paquete
superior a 65.507 bytes. Un paquete ICMP sobredimensionado puede desencadenar una variedad de reacciones
adversas por parte del sistema, como la denegación del servicio (DoS), “cuelgues”, bloqueos y reinicios.
Habilitando la opción SCREEN “Ping of Death”, el dispositivo NetScreen detecta y rechaza esos paquetes
sobredimensionados e irregulares incluso cuando el atacante oculta el tamaño total del paquete fragmentándolo
intencionalmente.
Nota: Para obtener información sobre “Ping of Death”, consulte http://www.insecure.org/sploits/ping-o-death.html.
10. Para obtener información sobre las especificaciones del protocolo IP, consulte RFC 791, “Internet Protocol”.
11. Para obtener más información sobre las especificaciones de ICMP, consulte RFC 792, “Internet Control Message Protocol”.

20 bytes 8 bytes 65.510 bytes

Original, paquete
no fragmentado Encabezado IP Encabezado Datos ICMP
ICMP
El tamaño de este paquete es de 65.538 bytes. Excede el límite de 65.535 bytes prescrito
en la RFC 791, “Internet Protocol”. Durante la transmisión, el paquete se divide en
numerosos fragmentos. Durante el proceso de reensamblaje, el sistema receptor puede
quedarse “colgado”.
Para habilitar la protección contra ataques “Ping of Death”, ejecute cualquiera de los siguientes procedimientos,
donde la zona especificada es aquélla en la que se origina el ataque:
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione Ping of Death Attack Protection
y haga clic en Apply.
CLI
set zone zone screen ping-death

Ataque “Teardrop”
Los ataques “Teardrop” explotan la función de reensamblaje de paquetes IP fragmentados. En el encabezado IP,
uno de los campos es el de desplazamiento del fragmento, que indica la posición inicial, o “desplazamiento”, de los
datos contenidos en un paquete fragmentado con respecto a los datos del paquete original sin fragmentar.
El dispositivo NetScreen comprueba si existen

Encabezado IP discrepancias en el campo de desplazamiento
del fragmento.
Tamaño del
Identificación x D M Desplazamiento
del fragmento
Tiempo de vida 20
(“Time to Live” o “TTL”) Protocolo Suma de comprobación del encabezado
bytes
Carga (datos)
Cuando la suma de “tamaño de desplazamiento” + “tamaño de un paquete fragmentado” es distinta a la del

siguiente paquete fragmentado, los paquetes se solapan y el servidor que intenta reensamblarlos puede colgarse,
especialmente si está ejecutando un sistema operativo antiguo que tenga esta vulnerabilidad.

Discrepancia entre
fragmentos
20 bytes 800 bytes
Paquete
fragmentado nº 11 Encabezado IP Datos
Desplazamiento (“offset”) = 0
Longitud = 820
Más fragmentos = 1
El segundo fragmento pretende
20 bytes 600 bytes comenzar 20 bytes antes (en 800) del
final del primer fragmento (en 820). El
Paquete desplazamiento del fragmento nº 2 no
fragmentado nº 2 Encabezado IP Datos
concuerda con la longitud del paquete
del fragmento nº 1. Esta discrepancia
Desplazamiento (“offset”) = 800 puede hacer que algunos sistemas se
Longitud = 620 cuelguen al intentar el reensamblaje.
Más fragmentos = 0
Una vez habilitada la opción SCREEN “Teardrop Attack”, siempre que el dispositivo NetScreen detecte esta
discrepancia en un paquete fragmentado, lo descartará.
Para habilitar la protección contra ataques “Teardrop”, ejecute cualquiera de los siguientes procedimientos, donde
la zona especificada es aquélla en la que se origina el ataque:
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione Teardrop Attack Protection y
haga clic en Apply.
CLI
set zone zone screen tear-drop

WinNuke
WinNuke es un ataque de denegación de servicio (“DoS”) que se dirige a cualquier equipo conectado a Internet que
ejecute Windows. El atacante envía un segmento TCP, normalmente al puerto 139 de NetBIOS con el flag “URG”
(urgente) activado, a un host con una conexión establecida. Esto induce un solapamiento de fragmentos NetBIOS,
que en muchos equipos Windows provoca la caída del sistema. Al reiniciar el equipo atacado, aparece el siguiente
mensaje para indicar que se ha producido un ataque:
Excepción OE en 0028:[dirección] en el VxD MSTCP(01) + 000041AE. La llamada se realizó desde
0028:[dirección] en el VxD NDIS(01) + 00008660. Quizás pueda continuar normalmente.
Presione cualquier tecla para continuar.
Presione CTRL+ALT+SUPR para reiniciar el equipo. Perderá la información no guardada en los
programas.
Presione cualquier tecla para continuar.
Indicadores de un ataque WinNuke

El puerto de destino es el 139.
Encabezado TCP
Número del puerto de origen Puerto de destino: 139
Número correlativo
Número de reconocimiento
Tamaño del Reservado U A P R S F

R C S S Y I Tamaño de la ventana
encabezado
G K H T N N
Suma de comprobación de TCP Indicador “Urgente”
Datos (si los hay)
El flag URG está activado.

Con la opción SCREEN de defensa contra ataques WinNuke habilitada, el dispositivo NetScreen analiza cualquier
paquete entrante del servicio de sesiones de Microsoft NetBIOS (puerto 139). Si el dispositivo NetScreen detecta
que el flag URG está activado en alguno de esos paquetes, lo desactiva, borra el indicador URG, reenvía el
paquete modificado y genera una entrada en el registro de eventos indicando que ha bloqueado un intento de
ataque WinNuke.
Para habilitar la protección contra ataques “WinNuke”, ejecute cualquiera de los siguientes procedimientos, donde
la zona especificada es aquélla en la que se origina el ataque:
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione WinNuke Attack Protection y
haga clic en Apply.
CLI
set zone zone screen winnuke

Capítulo 4
Supervisión y filtrado de contenidos

4
NetScreen proporciona amplia protección y control de la actividad de red por medio de funciones de ScreenOS y de
la combinación de NetScreen con productos Websense y Trend Micro.
NetScreen ofrece ciertas funciones de supervisión y filtrado de contenidos con la opción SCREEN de protección
contra URL maliciosas de ScreenOS. Además, la función de reensamblaje de fragmentos permite que el dispositivo
NetScreen detecte las URL incluso entre segmentos TCP y paquetes IP fragmentados.
Para la protección antivirus (AV), puede elegir algunos de los dispositivos NetScreen para obtener una clave de
licencia avanzada y una clave de licencia AV, y utilizar la función de detección de virus interna. También puede
configurar los dispositivos NetScreen para que se combinen con un máximo de tres analizadores antivirus externos
de Trend Micro (una vez adquiridas y cargadas las dos claves de licencia). Para el filtrado de URL, puede configurar
un dispositivo NetScreen para que se combine con uno o varios servidores Websense.
En este capítulo se estudia cómo se ha de configurar el dispositivo NetScreen para reensamblar paquetes y
segmentos, supervisar el tráfico HTTP en busca de URL maliciosas e interactuar con otros dispositivos para realizar
el análisis antivirus y el filtrado de URL. El capítulo se divide en las siguientes secciones:
• “Reensamblaje de fragmentos” en la página 86
– “Protección contra URL maliciosas” en la página 86
– “Puerta de enlace en la capa de aplicación” en la página 87
• “Análisis antivirus” en la página 91
– “Análisis AV interno” en la página 92
– “Análisis AV externo” en la página 107
• “Filtrado de URL” en la página 131

Capítulo 4 Supervisión y filtrado de contenidos Reensamblaje de fragmentos
REENSAMBLAJE DE FRAGMENTOS
Normalmente, los dispositivos de reenvío por red, como conmutadores o enrutadores, no reensamblan los
paquetes fragmentados que reciben. El reensamblaje de los paquetes fragmentados es responsabilidad del host de
destino una vez los recibe. Como el objetivo de los dispositivos de reenvío es garantizar un tráfico eficaz, poniendo
en cola los paquetes fragmentados, su reensamblaje, fragmentación y reenvío resultan innecesarios e ineficaces.
Sin embargo, el paso de paquetes fragmentados a través de un cortafuegos es poco seguro. El atacante puede
romper intencionadamente los paquetes y hacer así que las cadenas de tráfico resultantes crucen el cortafuegos
sin que se las detecte y bloquee.
ScreenOS permite habilitar por zonas el reensamblaje de fragmentos. De esta forma, el dispositivo NetScreen
puede ampliar su habilidad de detectar y bloquear cadenas de URL maliciosas y mejorar su capacidad de
proporcionar una puerta de enlace en la capa de aplicación (ALG) para comprobar las porciones de datos de los
paquetes.
Protección contra URL maliciosas

Además de la función de filtrado de URL que se explica más adelante en este capítulo (consulte “Filtrado de URL”
en la página 131), es posible definir hasta 48 patrones de cadenas URL maliciosas por zona, cada uno con una
longitud máxima de 64 caracteres, para la protección contra URL maliciosas en el nivel de zonas. Si la función de
bloqueo de URL maliciosas está habilitada, el dispositivo NetScreen examina la carga de datos de todos los
paquetes HTTP. Si localiza una URL y detecta que el comienzo de su cadena (hasta un número determinado de
caracteres) coincide con uno de los patrones definidos, el dispositivo NetScreen bloqueará el paquete, impidiendo
que traspase la puerta de enlace.
Cualquier atacante con recursos, al darse cuenta de que la cadena es conocida y que se puede bloquear, puede
fragmentar los paquetes IP o los segmentos TCP para que el patrón no sea identificable durante la inspección. Por
ejemplo, si la cadena URL maliciosa es 120.3.4.5/level/50/exec, ésta se podría fragmentar en las siguientes
secciones:
• Primer paquete: 120.
• Segundo paquete: 3.4.5/level/50
• Tercer paquete: /exec

Individualmente, las cadenas fragmentadas pueden atravesar el dispositivo NetScreen sin ser detectadas, aunque
se haya definido una cadena 120.3.4.5/level/50/exec con una longitud de 20 caracteres. La cadena del primer
paquete (“120.”) coincide con la primera parte del patrón definido, pero es más corta que los 20 caracteres definidos
para la longitud. Las cadenas del segundo y del tercer paquete no coinciden con el inicio del patrón definido, por lo
que también podrán pasar sin problemas.
No obstante, al reensamblar los paquetes, los fragmentos se combinan formando una cadena que el dispositivo
NetScreen puede identificar y bloquear. Gracias a la función de reensamblaje de fragmentos, el dispositivo
NetScreen puede colocar los fragmentos en cola, reensamblar con ellos el paquete completo y, finalmente, analizar
el paquete en busca de código malicioso. Según los resultados de este proceso de reensamblaje y la posterior
inspección, el dispositivo NetScreen lleva a cabo uno de los siguientes pasos:
• Si el dispositivo NetScreen descubre una URL maliciosa, descarta el paquete e indica el evento en el
registro.
• Si el dispositivo NetScreen no puede completar el proceso de reensamblaje, hay impuesto un límite
temporal tras el cual los fragmentos expiran y se descartan.
• Si el dispositivo NetScreen determina que la URL no es maliciosa pero el paquete reensamblado es
demasiado grande para reenviarlo, vuelve a fragmentar el paquete y reenvía los fragmentos.
• Si el dispositivo NetScreen determina que la URL no es maliciosa y no es necesario fragmentarla, reenvía
el paquete directamente.
Puerta de enlace en la capa de aplicación

NetScreen ofrece una puerta de enlace en la capa de aplicación (ALG o “Application Layer Gateway”) para una
serie de protocolos, como DNS, FTP, H.323 o HTTP. En estos protocolos, el reensamblaje de fragmentos puede
ser un componente importante a la hora de reforzar las directivas relativas a los servicios FTP y HTTP. La
capacidad de la puerta de enlace NetScreen para analizar paquetes para protocolos como FTP-Get y FTP-Put hace
necesario examinar no sólo el encabezado del paquete sino también los datos de la carga. Por ejemplo, puede
haber dos directivas, una que deniegue FTP-Put procedente de las zonas Untrust a las zonas DMZ y otra que
permita FTP-Get desde las zonas Untrust a las zonas DMZ.
set policy from untrust to dmz any any ftp-put deny
set policy from untrust to dmz any any ftp-get permit

Para distinguir los dos tipos de tráfico, el cortafuegos de NetScreen examina la carga del paquete. Si el contenido
es RETR filename, el cliente FTP ha enviado una petición para obtener o recuperar (“RETRieve”) el archivo
especificado desde el servidor FTP y el dispositivo NetScreen permitirá el paso del paquete. Si el dispositivo
NetScreen encuentra STOR filename, el cliente ha enviado una petición para almacenar (“STORe”) el archivo
especificado en el servidor y el dispositivo NetScreen bloqueará el paquete.
Para burlar este tipo de defensa, un atacante puede fragmentar deliberadamente un paquete FTP-put en dos
paquetes que contengan el siguiente texto en las cargas de datos correspondientes: paquete 1: ST; paquete 2: OR
filename. Cuando el dispositivo NetScreen inspecciona cada paquete de forma individual, no encuentra la cadena
STOR filename, por lo que permite el paso de ambos paquetes.
No obstante, al reensamblarlos, los fragmentos se combinan formando una cadena que el dispositivo NetScreen
puede identificar y bloquear. Gracias a la función de reensamblaje de fragmentos, el dispositivo NetScreen coloca
los fragmentos en cola, reconstruye con ellos el paquete completo y, finalmente, analiza el paquete en busca de la
petición FTP completa. Según los resultados de este proceso de reensamblaje y la posterior inspección, el
dispositivo NetScreen lleva a cabo uno de los siguientes pasos:
• Si el dispositivo NetScreen descubre una petición FTP-put, descarta el paquete e indica el evento en el
registro.
• Si el dispositivo NetScreen no puede completar el proceso de reensamblaje, hay impuesto un límite
temporal tras el cual los fragmentos caducan y se descartan.
• Si el dispositivo NetScreen descubre una petición FTP-get pero el paquete reensamblado es demasiado
grande para reenviarlo, vuelve a fragmentar el paquete y reenvía los fragmentos.
• Si el dispositivo NetScreen descubre una petición FTP-get y no es necesario fragmentarla, reenvía el
paquete directamente.

Ejemplo: Bloqueo de URL maliciosas fragmentadas

En este ejemplo, definiremos tres cadenas de URL maliciosas y habilitaremos la opción de bloqueo de URL
maliciosa:
• Primera URL maliciosa
– ID: Perl
– Patrón: scripts/perl.exe
– Longitud: 14
• Segunda URL maliciosa
– ID: CMF
– Patrón: cgi-bin/phf
– Longitud: 11
• Tercera URL maliciosa
– ID: DLL
– Patrón: 210.1.1.5/msadcs.dll
– Longitud: 18
Los valores de “longitud” indican el número de caracteres del patrón que deben aparecer en la URL, comenzando
por el primer carácter, para que la coincidencia se considere correcta. Observe que en las URL primera y tercera,
no es necesario que coincidan todos los caracteres.
A continuación, habilite el reensamblaje de fragmentos para detectar las URL que lleguen a una interfaz de zona
Untrust en el tráfico de HTTP.
WebUI
Screening > Mal-URL (Zone: Untrust): Introduzca los siguientes datos y haga clic en OK:
ID: perl
Pattern: /scripts/perl.exe
Length: 14

ID: cmf
Pattern: cgi-bin/phf
Length: 11
ID: dll
Pattern: 210.1.1.5/msadcs.dll
Length: 18
Screening > Mal-URL (Zone: Untrust): Seleccione la casilla de verificación IP/TCP Reassembly for ALG y,
a continuación, haga clic en OK.
CLI
set zone untrust screen mal-url perl “scripts/perl.exe” 14
set zone untrust screen mal-url cmf “cgi-bin/phf” 11
set zone untrust screen mal-url dll “210.1.1.5/msadcs.dll” 18
set zone untrust screen reassembly-for-alg
save

Capítulo 4 Supervisión y filtrado de contenidos Análisis antivirus
ANÁLISIS ANTIVIRUS
Un virus es un código ejecutable que infecta o adjunta otro código ejecutable que le permite reproducirse. Algunos
virus son maliciosos, borrando archivos o bloqueando sistemas. Otros representan un problema simplemente
porque infectan otros archivos, puesto que al propagarse pueden saturar la red o el host infectado con cantidades
excesivas de datos superfluos.
En combinación con la tecnología antivirus (AV) de Trend Micro, NetScreen ofrece dos soluciones antivirus:
• Análisis AV interno
• Análisis AV externo
En el análisis AV interno, el analizador AV se encuentra integrado en el dispositivo NetScreen como parte de
ScreenOS. La utilización de un dispositivo NetScreen que admita antivirus interno simplifica la distribución y la
gestión. Se trata de una opción muy rentable para ubicaciones remotas, pequeñas oficinas, puntos de venta
minoristas o lugares de teletrabajo. Para más información sobre cómo configurar la función de análisis AV interno,
consulte “Análisis AV interno” en la página 92.
En el caso del análisis AV externo, el analizador AV es un dispositivo independiente al dispositivo NetScreen que
reenvía el tráfico que hay que analizar. La utilización de un dispositivo NetScreen que admita uno o varios
analizadores AV externos representa una opción flexible y ampliable. Puede comenzar con un analizador AV, pero
si se amplía la red que se desea proteger, puede agregar más analizadores (hasta un máximo de tres) para
procesar mayores cargas de tráfico. Para más información sobre cómo configurar la función de análisis AV externo,
consulte “Análisis AV externo” en la página 107.

Análisis AV interno
Ciertos dispositivos NetScreen ofrecen análisis antivirus (AV) para transacciones específicas de la capa de
aplicación utilizando un analizador AV interno desarrollado por Trend Micro. Para poder utilizar el analizador AV
interno y analizar el tráfico de red en busca de virus, es necesario incluir una referencia al analizador AV interno en
la directiva de seguridad.
Es posible configurar el analizador AV interno para examinar el tráfico de red según distintos protocolos, incluyendo
SMTP (Simple Mail Transfer Protocol), HTTP (Hypertext Transfer Protocol) y POP3 (Post Office Protocol, versión
3). Tras comprobar que ha recibido el contenido completo del paquete SMTP, HTTP o POP3, el analizador AV
examina los datos en busca de virus. Esto lo hace según un archivo de firmas que permite identificar las firmas de
virus. Cuando el analizador AV interno detecta un virus, el dispositivo NetScreen descarta el contenido y envía un
mensaje al cliente indicando que el contenido está infectado. Si el analizador no detecta ningún virus, el dispositivo
NetScreen reenvía el contenido al destino correspondiente.

Para el análisis de tráfico SMTP, el dispositivo NetScreen redirige el tráfico desde un cliente SMTP local al
analizador AV interno antes de enviarlo al servidor de correo local.
Análisis antivirus SMTP Zona DMZ
Servidor de
correo local
Zona Untrust 3 C Zona Trust

Internet
1 A
2 B
Servidor de correo remoto Analizador AV interno Cliente SMTP
1. Un servidor de correo remoto reenvía un mensaje de correo A. Un cliente SMTP envía un mensaje de correo electrónico a un
electrónico por SMTP al servidor de correo local. servidor de correo local.
2. El dispositivo NetScreen intercepta el mensaje y transmite los B. El dispositivo NetScreen intercepta el mensaje y transmite los
datos al analizador AV interno, que los examina en busca de virus. datos al analizador AV interno, que los examina en busca de virus.
3. Una vez finalizado el análisis, el dispositivo NetScreen sigue uno C. Una vez finalizado el análisis, el dispositivo NetScreen sigue uno
de estos pasos: de estos pasos:
• Si no hay virus, reenvía el mensaje al servidor local. • Si no hay virus, reenvía el mensaje al servidor local.
• Si se descubre la presencia de un virus, envía un mensaje • Si se descubre la presencia de un virus, envía un mensaje
informando de la infección al servidor remoto. informando de la infección al cliente.

Para el análisis de tráfico POP3, el dispositivo NetScreen redirige el tráfico desde un servidor de correo local al
analizador AV interno antes de enviarlo al cliente POP3 local.
Análisis antivirus POP3 Zona DMZ
Servidor de
correo local
Zona Untrust A Zona Trust
Internet
C
B
Analizador AV interno Cliente POP3
A. El cliente POP3 descarga un mensaje de correo electrónico desde el servidor de

correo local.
B. El dispositivo NetScreen intercepta el mensaje y transmite los datos al analizador
AV interno, que los examina en busca de virus.
C. Una vez finalizado el análisis, el dispositivo NetScreen sigue uno de estos pasos:
• Si no hay virus, reenvía el mensaje al cliente.
• Si se descubre la presencia de un virus, envía un mensaje informando de la
infección al cliente.

Para el análisis de tráfico HTTP, antes de enviar las respuestas de un servidor web al cliente que realizó las
peticiones HTTP, el dispositivo NetScreen envía las respuestas al analizador AV y, a continuación, al cliente.
Análisis antivirus HTTP

1
Servidor Cliente
web HTTP local
remoto 2 3
Analizador AV interno
1. Un cliente HTTP local envía una petición HTTP a un servidor web remoto. El
dispositivo NetScreen permite la petición.
2. El dispositivo NetScreen intercepta la respuesta HTTP entrante y transmite los datos
HTTP a su analizador AV interno, que los examina en busca de virus.
3. Una vez finalizado el análisis, el dispositivo NetScreen sigue uno de estos pasos:
• Si se descubre la presencia de un virus, descarta el mensaje y envía otro
informando de la infección al cliente.
Nota: El analizador AV interno examina las descargas HTTP; es decir, los datos HTTP de un servidor web en
respuesta a las peticiones HTTP de un cliente. El analizador AV interno no analiza las cargas, p. ej., cuando un
cliente HTTP completa un cuestionario en un servidor web o cuando un cliente escribe un mensaje en un servicio
de correo ubicado en un servidor web.

Para el análisis de tráfico de correo web HTTP, antes de enviar las respuestas de un servidor web al cliente que
realizó las peticiones de correo web HTTP, el dispositivo NetScreen redirige las respuestas al analizador AV y, a
continuación, las envía al cliente.
Análisis antivirus de correo web HTTP

1
Servidor Cliente
web HTTP local
remoto 2 3
Analizador AV interno
1. Un cliente HTTP local envía una petición de correo web HTTP a un servidor web
remoto. El dispositivo NetScreen permite la petición.
2. El dispositivo NetScreen intercepta la respuesta HTTP entrante y transmite los
datos HTTP a su analizador AV interno, que los examina en busca de virus.
3. Una vez finalizado el análisis, el dispositivo NetScreen sigue uno de estos pasos:
• Si se descubre la presencia de un virus, descarta el mensaje y envía otro
informando de la infección al cliente.

Habilitación del análisis AV interno

El análisis AV interno hace necesario cargar una base de datos de firmas de virus (patrones) en el dispositivo
NetScreen y actualizar el archivo de firmas periódicamente. Para ello, debe registrar el dispositivo y adquirir una
suscripción para el servicio de firmas de virus. La suscripción permite cargar la versión actual de la base de datos y
actualizarla cada vez que se publiquen nuevas versiones mientras dure el periodo de validez de la suscripción.
Existen dos procesos distintos para iniciar el servicio de firmas de virus:
• Si adquiere un dispositivo NetScreen con funciones antivirus, puede cargar un archivo de firmas de virus
durante un breve periodo de tiempo desde la fecha de compra. No obstante, deberá registrar el dispositivo
y adquirir una suscripción para el servicio de firmas de virus para poder continuar recibiendo
actualizaciones.
• Si actualiza su dispositivo NetScreen actual para poder utilizar análisis antivirus interno, debe registrar el
dispositivo y adquirir una suscripción para el servicio de firmas antes de poder cargar el archivo de firmas
inicial. Una vez finalizado el proceso de registro, deberá esperar durante un máximo de cuatro horas antes
de iniciar la descarga del archivo de firmas.
Nota: Para obtener más información sobre el servicio de firmas de virus, consulte “Registro y activación de
los servicios de firma” en la página 2 -574.
A continuación se describe el proceso de actualización del archivo de firmas de virus:

1. Desde el dispositivo NetScreen, especifique la dirección URL del servidor externo que contiene el archivo
de firmas para obtener un archivo de inicialización de servidor llamado server.ini.
Dispositivo NetScreen Servidor de

actualizaciones
1. Petición del archivo de
inicialización al servidor 2. Si la versión del archivo de
firmas no está actualizada, el
servidor de actualizaciones envía
el archivo server.ini.
Internet
URL = http://5gt-t.activeupdate
.trendmicro.com/activeupdate
Archivo Archivo /server.ini
3. Transferencia del archivo
server.ini server.ini server.ini

2. Una vez el dispositivo NetScreen ha descargado el archivo de inicialización del servidor, lo analiza para
obtener información sobre el archivo de firmas actualizado, incluyendo la versión y el tamaño del archivo,
así como la ubicación del servidor externo de archivos de firmas.
Nota: ScreenOS contiene un certificado CA para autenticar la comunicación con el servidor de archivos de
firmas.
3. Si el archivo de firmas actual es obsoleto, el dispositivo NetScreen obtiene automáticamente el archivo

actualizado del servidor externo de archivos de firmas.
Dispositivo NetScreen Servidor de archivos

de firmas
4. Solicitud del archivo de firmas
Internet
Archivo de 5. Transferencia del archivo Archivo de firmas de virus

firmas de virus de firmas de virus
4. Una vez el dispositivo NetScreen ha descargado el archivo de firmas, verifica que la suscripción para el
servicio aún sea válida. Si la suscripción es válida, el archivo de firmas se actualizará. Si la suscripción ha
caducado, la actualización del archivo de firmas se cancelará y aparecerá un mensaje indicando que la
suscripción ha caducado.
Nota: El tiempo total estimado para completar la actualización es de aproximadamente tres minutos. Este tiempo
puede variar según el tamaño del archivo de firmas y el tráfico existente en la red. Al finalizar la actualización del
archivo de firmas, el dispositivo NetScreen reinicia el analizador AV para poder utilizar el nuevo archivo.

Actualización automática o semiautomática del archivo de firmas

Las actualizaciones del archivo de firmas se agregan a medida que se propagan nuevos virus. Puede configurar el
dispositivo NetScreen para que actualice el archivo de firmas automáticamente cada cierto tiempo o
semiautomáticamente.
Nota: Cuando caduque la suscripción, el servidor de actualizaciones no permitirá actualizar el archivo de firmas de
virus.
Ejemplo: Actualización automática

En este ejemplo, configuraremos el dispositivo NetScreen para que actualice el archivo de firmas automáticamente
cada 15 minutos. (El intervalo de actualización predeterminado es de 60 minutos). El servidor de actualizaciones se
encuentra ubicado en la siguiente dirección URL: http://5gt-t.activeupdate.trendmicro.com/activeupdate/server.ini.
WebUI
Screening > Antivirus > Scan Manager: Introduzca los siguientes datos y haga clic en OK:
Pattern Update Server:
http://5gt-t.activeupdate.trendmicro.com/activeupdate/server.ini.
Auto Pattern Update: (seleccione), Interval: 15 minutes (10~10080)
CLI
set av scan-mgr pattern-update-url http://5gt-t.activeupdate.trendmicro.com/
activeupdate/server.ini interval 15
save

Ejemplo: Actualización semiautomática

En este ejemplo, configuraremos el dispositivo NetScreen para que el archivo de firmas se actualice de forma
semiautomática. El servidor de actualizaciones se encuentra ubicado en la siguiente dirección URL:
WebUI
Pattern Update Server:
Update Now: (seleccione)
CLI
set av scan-mgr pattern-update-url
http://5gt-t.activeupdate.trendmicro.com/activeupdate/server.ini
exec av scan-mgr pattern-update
Configuración del procesamiento de contenidos

De forma predeterminada, el analizador AV interno examina el tráfico de tipo SMTP, HTTP (sólo correo web) y
POP3.
Nota: El analizador AV interno sólo examina patrones específicos de correo web HTTP. Los patrones de los
servicio de correo de Yahoo!, Hotmail y AOL están predefinidos.
Puede cambiar el comportamiento predeterminado para que el analizador AV interno examine únicamente
determinado tráfico de red.

Ejemplo: Análisis AV interno para SMTP

En este ejemplo configuraremos el analizador AV para que examine únicamente el tráfico SMTP.
WebUI
Protocols to be scanned:
SMTP: (seleccione)
CLI
set av scan-mgr content smtp timeout 20
save

Ejemplo: Análisis AV interno para SMTP y HTTP

En este ejemplo configuraremos el analizador AV interno para que examine todo el tráfico SMTP y HTTP.
WebUI
SMTP: (seleccione)
HTTP: (seleccione); ALL HTTP: (seleccione)
CLI
set av scan-mgr content smtp timeout 20
set av scan-mgr content http timeout 20
unset av http webmail enable
save
Configuración de la descompresión y el tamaño máximo de los contenidos

Cuando recibe datos, el analizador AV interno descomprime cualquier archivo comprimido. De forma
predeterminada descomprime hasta dos niveles de archivos comprimidos. Por ejemplo, si el analizador recibe un
archivo comprimido que incluye otro archivo adjunto también comprimido, el analizador los descomprimirá para
detectar cualquier virus. Puede configurar el analizador AV interno para que descomprima hasta 20 archivos
comprimidos unos dentro de otros.
El analizador AV interno examina un máximo de ocho mensajes y 16 MB de contenido “descomprimido” al mismo
tiempo. Si el número total de mensajes o el tamaño de los datos recibidos al mismo tiempo excede estos límites, el
analizador permitirá de forma predeterminada el paso del contenido sin examinarlo. Por ejemplo, el analizador
recibe y examina cuatro mensajes de 4 MB simultáneamente. Si el analizador recibe nueve mensajes de 2 MB al
mismo tiempo, permitirá su paso sin examinar el contenido. Puede modificar este comportamiento predeterminado
para que el analizador AV interno descarte el tráfico en lugar de permitir su paso.

Ejemplo: Eliminación de archivos de gran tamaño

En este ejemplo configuraremos el analizador AV interno para que descomprima hasta 10 archivos comprimidos
unos dentro de otros. También configuraremos el analizador para que descarte el contenido si los archivos
recibidos simultáneamente son más de cuatro o el tamaño “descomprimido” de los contenidos es superior a 12 MB.
WebUI
File decompression: 10 layers (1~4)
Drop: (seleccione) file if it exceeds 3000 KB (4000~20000)
Drop: (seleccione) file if the number of files exceeds 4 files (1~8)
CLI
set av scan-mgr decompress-layer 10
set av scan-mgr max-msgs 4
set av scan-mgr max-content-size 3000
set av scan-mgr max-content-size drop
save

Aplicación del análisis AV interno

Para aplicar el análisis AV interno al tráfico de red SMTP, HTTP o POP3, debe hacer referencia al analizador AV
interno predefinido en las directivas.
Ejemplo: Análisis AV interno (POP3)

En este ejemplo haremos referencia al analizador AV interno en una directiva de cortafuegos, en la que
permitiremos el tráfico POP3 desde direcciones en la zona Trust al servidor de correo (“mailsrv1”, 1.2.2.5) de la
zona DMZ. Todas las zonas se encuentran en el dominio de enrutamiento Trust-vr.
WebUI
1. Interfaces
Zone Name: Trust

Interface Mode: NAT
Zone Name: DMZ
Zone Name: Untrust

2. Dirección
Address Name: mailsrv1
Zone: DMZ
3. Análisis AV interno POP3

POP3: (seleccione)
4. Ruta
5. Directiva
Policies > (From: Trust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK:
Source Address:
Address Book Entry: (seleccione), mailsrv1
Service: POP3

Action: Permit
> Advanced: Mueva los siguientes objetos AV y haga clic en Return para
configurar las opciones avanzadas y regresar a la página de configuración
básica:
Seleccione scan-mgr y haga clic en el botón << para mover el
objeto AV de la columna “Available AV Object Names” a la
columna “Attached AV Object Names”.
CLI
1. Interfaces
2. Dirección
set address dmz mailsvr1 1.2.2.5/32
3. Análisis AV interno POP3
set av-scan-mgr content pop3 timeout 20
4. Ruta
5. Directiva
set policy from trust to dmz any mailsvr1 pop3 permit av scan-mgr
save

Análisis AV externo
La mayoría de los dispositivos NetScreen puede interactuar con un analizador antivirus (AV) externo desarrollado
por Trend Micro llamado InterScan VirusWall Edition 3.6. Puede configurar el dispositivo NetScreen para reenviar el
tráfico SMTP y HTTP al analizador VirusWall. El protocolo de comunicaciones entre el dispositivo NetScreen y el
analizador VirusWall se conoce como Content Scanning Protocol (CSP), versión 1.5.
Nota: NetScreen no es compatible con antivirus para sistemas virtuales. En aquellos sistemas que admitan tanto
sistemas virtuales como antivirus, el antivirus sólo estará disponible en el nivel raíz.
Cuando el analizador VirusWall recibe el contenido completo de un paquete SMTP o HTTP, examina los datos en
busca de virus. Dispone de una base de datos de patrones de virus que utiliza para identificar las firmas de virus. Si
encuentra algo sospechoso, VirusWall pone en cuarentena los datos infectados para su estudio detallado y
devuelve el archivo SMTP o HTTP (sin los datos infectados) al dispositivo NetScreen. El dispositivo NetScreen
transmite entonces el archivo al destinatario previsto.
Si VirusWall detecta un virus, tanto el dispositivo NetScreen como VirusWall realizan una entrada en el registro de
eventos identificando el virus detectado.
Nota: Para saber cómo se debe configurar InterScan VirusWall de Trend Micro para su comunicación con el
dispositivo NetScreen, así como para otras funciones, consulte la documentación de producto de Trend Micro.

Para el análisis de tráfico SMTP, el dispositivo NetScreen puede redirigir el tráfico desde un servidor de correo
remoto o cliente SMTP local al analizador antivirus VirusWall antes de enviarlo al servidor de correo local.
Análisis antivirus SMTP
Zona DMZ
Servidor de
correo local
Zona Untrust 3 C Zona Trust

1 A
2 B
Servidor de correo remoto Cliente SMTP
Analizador antivirus
(en la zona DMZ)
1. Un servidor de correo remoto reenvía un mensaje A. El cliente SMTP envía un mensaje de correo
de correo electrónico al servidor de correo local. electrónico al servidor de correo local.
2. El dispositivo NetScreen intercepta el mensaje y B. El dispositivo NetScreen intercepta el mensaje y
transmite los datos al analizador antivirus, que los transmite los datos al analizador antivirus, que los
examina en busca de virus. examina en busca de virus.
3. Una vez finalizado el análisis (y, en caso C. Una vez finalizado el análisis (y, en caso
necesario, tras modificar o eliminar parte del necesario, tras modificar o eliminar parte del
contenido por estar infectado), el analizador contenido por estar infectado), el analizador
devuelve los datos al dispositivo NetScreen, que devuelve los datos al dispositivo NetScreen, que
los reenvía al servidor de correo. los reenvía al servidor de correo.

Para el análisis de tráfico HTTP, antes de enviar las respuestas de un servidor web al cliente que realizó las
peticiones HTTP, el dispositivo NetScreen redirige las respuestas a un analizador antivirus antes de reenviar el
tráfico al cliente.
Análisis antivirus HTTP

1
Servidor Cliente
web HTTP local
remoto 2 3
Analizador antivirus
(en la zona Trust)
1. Un cliente HTTP local envía una petición HTTP a un servidor web

remoto. El dispositivo NetScreen permite la petición.
2. El dispositivo NetScreen intercepta la respuesta HTTP entrante y
transmite los datos HTTP al analizador antivirus, que los examina
en busca de virus.
3. Una vez finalizado el análisis (y, en caso necesario, tras modificar
o eliminar parte del contenido por estar infectado), el servidor
antivirus devuelve los datos al dispositivo NetScreen, que los
reenvía al cliente.
Nota: El analizador antivirus examina las descargas HTTP; es decir, los datos HTTP de un servidor web en
respuesta a las peticiones HTTP de un cliente. El analizador antivirus no analiza las cargas, p. ej., cuando un cliente
HTTP completa un cuestionario en un servidor web o cuando un cliente escribe un mensaje en un servicio de
correo ubicado en un servidor web.

Definición de objetos AV
Un objeto antivirus (objeto AV) es el término que NetScreen utiliza para referirse a un analizador antivirus externo.
Es posible definir hasta tres objetos AV para aumentar la capacidad de ancho de banda. Cuando se crea un objeto
AV, se deben definir los siguientes tres componentes:
• Nombre del objeto AV
• Dirección IP o nombre de dominio (convertido a una dirección IP por el DNS) del analizador antivirus
• Tipo de contenido: HTTP, SMTP o ambos
Si sólo define uno o dos de los componentes anteriores, el estado del objeto AV se considerará incompleto. Si se
definen los tres componentes, se considerará completo. Por ejemplo:
set av scanner1 server-name 1.2.2.25 El objeto AV está incompleto porque tiene un nombre (“scanner1”)
y una dirección (1.2.2.25), pero no un tipo de contenido.
ns208A_5.0.0_beta3-> get av scanner1
<AV object scanner1>
scanner name: 1.2.2.25
scanner ip: 1.2.2.25
scanner port: 3300
status: incomplete
applications: 0
scanned bytes: 0
policy ref cnt: 0
set av scanner1 server-name 1.2.2.25 El objeto AV está completo porque tiene un nombre, una
set av scanner1 content http dirección y un tipo de contenido (HTTP).
get av scanner1
<AV object scanner1>
scanner name: 1.2.2.25
scanner ip: 1.2.2.25
scanner port: 3300
HTTP: timeout 180 seconds
status: complete
applications: 0
scanned bytes: 0
policy ref cnt: 0

Hay ciertos parámetros opcionales que se pueden establecer para un objeto AV:
• Número de puerto: de forma predeterminada, el número de puerto que el protocolo CSP (Content
Scanning Protocol, o protocolo de análisis de contenidos) utiliza para la comunicación entre un dispositivo
NetScreen y Trend Micro InterScan VirusWall es 3300. Puede cambiar este número para un determinado
objeto AV.
set av name_str server-name { ip_addr | domain_name } port number
unset av name_str server-name { ip_addr | domain_name } port
El comando unset av restablece el número de puerto a su número predeterminado (3300).
• Valor de tiempo de espera (en segundos): de forma predeterminada, una conexión CSP expira tras 180
segundos de inactividad. Este valor se puede cambiar para un objeto AV determinado. Se puede ajustar un
valor de entre 1 y 1800 segundos.
set av name_str content { http | smtp } timeout number
unset av name_str content { http | smtp } timeout number
El comando unset av restablece el tiempo de espera a su valor predeterminado (180 segundos).
Además de estas opciones, que se pueden configurar para un objeto AV en particular, también es posible
establecer los siguientes parámetros que se aplicarán a la función antivirus en general:
• Máximo número de conexiones TCP simultáneas: permite especificar el número máximo de conexiones
TCP simultáneas entre el dispositivo NetScreen y todos los objetos AV como grupo, no entre el dispositivo
NetScreen y cada uno de los objetos AV. El valor predeterminado varía de una plataforma a otra. Consulte
la documentación de marketing de NetScreen para obtener información sobre cada plataforma específica.
WebUI
Screening > Antivirus: Indique un número en el campo “Maximum Number of TCP Connections” y, a
continuación, haga clic en Apply.
CLI
set av all max-connections number
unset av all max-connections

• Recursos CSP por ubicación de origen: un usuario con malas intenciones puede enviar
simultáneamente una gran cantidad de tráfico SMTP o HTTP para consumir todos los recursos CSP
(Content Scanning Protocol) y así impedir que el dispositivo NetScreen pueda reenviar cualquier otro tráfico
al analizador AV. Para evitar que esto suceda, el dispositivo NetScreen puede imponer un porcentaje
máximo de recursos CSP que puede consumir el tráfico desde una ubicación de origen determinada. De
forma predeterminada, el porcentaje máximo es del 70%. Este ajuste se puede cambiar a cualquier valor
entre 1% y 100%. Si se ajusta el 100%, no habrá ninguna restricción a la cantidad de recursos CSP que
pueda consumir el tráfico desde una ubicación determinada.
WebUI
Screening > Antivirus: Indique un número en el campo “Maximum AV Resources Allowed per AV
Client” y, a continuación, haga clic en Apply.
CLI
set av all resources number
unset av all resources
El comando unset av restablece el porcentaje máximo de recursos CSP por ubicación de origen al valor
predeterminado (70%).
• Comportamiento en modo de fallo: el modo de fallo es el comportamiento que muestra el dispositivo
NetScreen cuando pierde la conexión con el analizador VirusWall, ya sea permitiendo el tráfico no
analizado o bloqueándolo. De forma predeterminada, si un dispositivo NetScreen no puede acceder al
analizador VirusWall, bloquea el tráfico HTTP y SMTP que una directiva con la comprobación antivirus
habilitada permitiría. Este comportamiento predeterminado se puede cambiar para que permita el tráfico.
WebUI
Screening > Antivirus: Seleccione la casilla de verificación “Fail Mode Traffic Permit” para permitir el
tráfico no analizado o anule la selección para bloquearlo. A continuación haga clic en Apply.
CLI
set av all fail-mode traffic permit
unset av all fail-mode traffic

El comando unset av restablece el comportamiento en modo de fallo a su valor predeterminado (bloquear

el tráfico no analizado).
• Umbral de modo de fallo: el modo de fallo es el estado resultante cuando el número de intentos fallidos
de conexión a un objeto AV excede un umbral. De forma predeterminada, el umbral es 150 y se aplica a
todos los objetos AV. Si el número de intentos fallidos consecutivos excede este umbral, el dispositivo
NetScreen espera durante un intervalo definido de tiempo (cinco minutos) antes de volver a intentar
establecer la conexión. Es posible cambiar el umbral si considera el ajuste predeterminado demasiado alto
o demasiado bajo para sus necesidades.
WebUI
Screening > Antivirus: Indique un número en el campo “Fail Mode Scanner Threshold” y, a
continuación, haga clic en Apply.
CLI
set av all fail-mode scanner threshold number
unset av all fail-mode scanner
Si después desea que el dispositivo NetScreen reanude sus esfuerzos para establecer la conexión con un
objeto AV en concreto antes de que termine el tiempo de espera, puede introducir el siguiente comando:
clear av name_str fail-mode
Este comando borra el estado de fallo, de forma que cuando vuelva a llegar tráfico SMTP o HTTP, el
dispositivo NetScreen inmediatamente intentará establecer una conexión con el analizador AV. Si tiene
éxito en su intento, el dispositivo NetScreen reanudará el reenvío de archivos al analizador AV para su
análisis. Si el intento de conexión no tiene éxito, el estado volverá al modo de fallo.

• Método HTTP “keep-alive”: de forma predeterminada, el dispositivo NetScreen utiliza la opción de

conexión HTTP “close” para indicar el final de la transmisión de datos. En caso necesario, el dispositivo
NetScreen cambiará el token del encabezado de la conexión de “keep-alive” a “close”. En este método,
cuando el servidor HTTP completa la transmisión de datos, envía un comando TCP FIN para cerrar la
conexión TCP y así indicar que ha finalizado el envío de datos. Cuando el dispositivo NetScreen recibe un
comando TCP FIN, contiene todos los datos HTTP del servidor y puede ordenar al analizador AV que
comience el análisis.
Puede cambiar el comportamiento predeterminado del dispositivo NetScreen para utilizar la opción de
conexión HTTP “keep-alive”, en la que no se envía comando TCP FIN para indicar el final de la transmisión
de datos. El servidor HTTP debe indicar de otra forma que se han enviado todos los datos, ya sea enviando
la longitud de los contenidos en el encabezado HTTP o con alguna otra forma de codificación. El método
que se utilice dependerá del tipo de servidor. Este método hace que la conexión TCP permanezca abierta
mientras se realice el análisis antivirus, lo que disminuye la latencia y mejora el rendimiento de la CPU. Sin
embargo, no resulta tan seguro como el método de conexión “close”. Este comportamiento se puede
modificar si detecta que las conexiones HTTP superan el tiempo de espera durante el análisis antivirus.
WebUI
Screening > Antivirus: Seleccione la casilla de verificación para poder utilizar la opción de conexión
“keep-alive” o anule la selección para utilizar la opción de conexión “close”. A continuación, haga clic
en Apply.
CLI
set av http keep-alive
unset av http keep-alive

• Goteo HTTP: como goteo HTTP se entiende el reenvío de cantidades específicas de tráfico HTTP no
analizado al cliente HTTP solicitante para evitar que la ventana del explorador rebase el tiempo de espera
mientas VirusWall examina los archivos HTTP descargados. El dispositivo NetScreen reenvía pequeñas
cantidades de datos antes de transferir un archivo analizado completo. De forma predeterminada, el goteo
HTTP está inhabilitado. Para habilitarlo y utilizar los parámetros predeterminados del goteo HTTP, siga uno
de estos pasos:
WebUI
Screening > Antivirus: Seleccione la casilla de verificación “Trickling Default” y haga clic en Apply.
CLI
set av http trickling default
Con los parámetros predeterminados, el dispositivo NetScreen emplea el goteo si el tamaño de un archivo
HTTP supera 3 MB de tamaño. Reenviará 500 bytes de contenido por cada megabyte enviado a analizar.
Para cambiar los parámetros del goteo HTTP, siga uno de estos pasos:
WebUI
Screening > Antivirus: Introduzca los siguientes datos y haga clic en Apply:
Trickling:
Custom: (seleccione)
Minimum Length to Start Trickling: Indique number1.
Trickle Size: Indique number2.
Trickle for Every MB Sent for Scanning: Indique number3.

CLI
set av http trickling number1 number3 number2
Las tres variables numéricas tienen los siguientes significados:
– number1: tamaño mínimo (en megabytes) de un archivo HTTP para que comience el goteo
– number2: tamaño (en bytes) del tráfico no analizado que reenviará el dispositivo NetScreen
– number3: tamaño (en megabytes) de un bloqueo de tráfico al que el dispositivo NetScreen aplicará el
goteo
Nota: Los datos sometidos al proceso de goteo en el disco duro del cliente aparecerán como un pequeño
archivo sin utilidad. Dado que el goteo funciona reenviando pequeñas cantidades de datos a un cliente sin
analizarlos, el código malicioso podría encontrarse entre los datos que el dispositivo NetScreen ha enviado
al cliente por goteo. NetScreen recomienda a los usuarios que eliminen esos archivos.
Puede inhabilitar el goteo HTTP por medio de la interfaz WebUI (Screening > Antivirus: haga clic en
Disable en la sección Trickling) o con el comando CLI set av http trickling 0 0 0. En cualquier caso, si el
archivo que se va a descargar supera los 8 MB y se ha desactivado el goteo HTTP, es muy probable que la
ventana del explorador rebase el tiempo de espera.
Ejemplo: Definición de tres objetos AV

En este ejemplo definiremos los siguientes objetos AV:
• Objeto AV 1
– Name: scanner1
– IP address: 1.2.2.20
– Port number for Content Scanning Protocol (CSP): 3300 (predeterminado)
– Content: HTTP
– Timeout: 180 seconds (predeterminado)

• Objeto AV 2
– Name: scanner2
– Port number for CSP: 6830
– Content: SMTP
– Timeout: 200 seconds
• Objeto AV 3
– Name: scanner3
– Port number for CSP: 6840
– Content: HTTP and SMTP
– HTTP Timeout: 120 seconds
– SMTP Timeout: 200 seconds
El dispositivo NetScreen accede a estas direcciones a través de ethernet2, que tiene la dirección IP 1.2.2.1/24 y
está unida a la zona DMZ.
WebUI
1. Objeto AV 1
Objects > Antivirus > New: Introduzca los siguientes datos y haga clic en OK:
AV Object Name: scanner1
Scan Server Name/IP: 1.2.2.20
Scan Server Port: 3300
Contents:
HTTP: (seleccione), Timeout: 180 Seconds

2. Objeto AV 2
Contents:
SMTP: (seleccione), Timeout: 200 Seconds
3. Objeto AV 3
Contents:
CLI
1. Objeto AV 1
set av scanner1 server-name 1.2.2.20
set av scanner1 content http
2. Objeto AV 2
set av scanner2 server-name 1.2.2.30 port 6830
set av scanner2 content smtp timeout 200

3. Objeto AV 3
set av scanner3 server-name 1.2.2.40 port 6840
set av scanner3 content http timeout 120
set av scanner3 content smtp timeout 200
save

Aplicación del análisis AV externo

Una vez creados uno o varios objetos AV, puede hacer referencia a ellos en directivas para aplicar el análisis
antivirus al tráfico HTTP y SMTP. Un objeto AV individual puede analizar el tráfico HTTP, SMTP o ambos. Si hace
referencia a dos o tres objetos AV en la misma directiva, el dispositivo NetScreen envía el tráfico adecuado para
analizar los objetos en una secuencia que mantenga una carga equilibrada.
El orden en que haga referencia a los tres objetos AV en la configuración de la directiva definirá el orden en que el
dispositivo NetScreen les enviará el tráfico HTTP y SMTP. El objeto AV al que haga referencia en primer lugar será
el objeto al que el dispositivo NetScreen envíe el primer archivo, como un mensaje de correo electrónico o una
respuesta HTTP, para su análisis. En otras palabras, el primer objeto AV será el que tenga mayor prioridad. El
objeto AV al que haga referencia en segundo lugar será el objeto al que el dispositivo NetScreen enviará un
segundo archivo si el primer objeto AV está analizando en ese momento otro archivo. Tiene una prioridad
intermedia. El objeto AV al que haga referencia en tercer lugar en la configuración de la directiva recibirá un tercer
archivo si los otros dos objetos AV están analizando otros archivos. Tiene la menor prioridad.
Por ejemplo, si crea tres objetos AV llamados “scanner1”, “scanner2” y “scanner3” y hace referencia a ellos en una
directiva siguiendo este orden:
set policy id 1 from trust to untrust any any http permit av scanner1
set policy id 1
ns(policy:1)-> set av scanner2
el orden de envío de los archivos a cada analizador será éste:
1. El dispositivo NetScreen envía el primer archivo para el análisis a scanner1.
2. Si llega un segundo archivo para el análisis, el dispositivo NetScreen lo envía a scanner1 o scanner2 según
las siguientes condiciones:
– scanner1 si se ha completado el análisis del primer archivo
– scanner2 si scanner1 aún está analizando el primer archivo
3. Si llega un tercer archivos, el dispositivo NetScreen lo envía a uno de los tres objetos AV según las
siguientes condiciones:
– scanner1 si no está analizando ningún archivo
– scanner2 si scanner1 está analizando un archivo pero scanner2 está libre
– scanner3 si scanner1 y scanner2 están analizando archivos

La secuencia anteriormente explicada continúa cuando todos los analizadores están ocupados analizando múltiples
archivos. Si todos los analizadores están ocupados con el mismo número de archivos, el dispositivo NetScreen
enviará el siguiente archivo a scanner1. Si scanner1 está analizando un número de archivos inferior a scanner2 y a
scanner3, el dispositivo NetScreen enviará el siguiente archivo a scanner1. Si scanner2 está analizando un número
de archivos inferior a scanner1 y a scanner3, el dispositivo NetScreen enviará el siguiente archivo a scanner2. Si
scanner3 está analizando un número de archivos inferior a scanner1 y a scanner2, el dispositivo NetScreen enviará
el siguiente archivo a scanner3.
Ejemplo: Antivirus con un objeto AV

En este ejemplo crearemos un único objeto AV llamado “scanner1” para realizar el análisis antivirus de las
respuestas HTTP desde servidores web en la zona Untrust a clientes en la zona Trust. El analizador antivirus
también se encuentra en la zona Trust. Aunque habilite la comprobación antivirus para el tráfico HTTP entre las
zonas Trust y Untrust, no es necesario disponer de una directiva adicional para permitir el tráfico CSP entre el
dispositivo NetScreen y scanner1. Todas las zonas se encuentran en el dominio de enrutamiento Trust-vr.
WebUI
1. Interfaces
Zone Name: Trust

Interface Mode: NAT
Zone Name: Untrust

2. Objeto AV
Contents:
3. Ruta
4. Directiva
Policies > (From: Trust, To: Untrust) New: Introduzca los siguientes datos y haga clic en OK:
Source Address:
Service: HTTP
Action: Permit
> Advanced: Mueva el siguiente objeto AV y haga clic en Return para
básica:
Seleccione scanner1 y utilice el botón << para mover el objeto
AV de la columna “Available AV Object Names” a la columna
“Attached AV Object Names”.

CLI
1. Interfaces
2. Objeto AV
3. Ruta
4. ID de directiva 1
set policy id 1 from trust to untrust any any http permit av scanner1
save

Ejemplo: Antivirus con dos objetos AV

En este ejemplo definiremos dos objetos AV llamados “scanner1” y “scanner2” para analizar tráfico HTTP y SMTP.
A continuación hará referencia a ellos en directivas que permitirán el tráfico HTTP entre zonas Trust y Untrust, y el
tráfico SMTP desde direcciones de las zonas Untrust y Trust hacia el servidor de correo en la zona DMZ. Para
equilibrar la carga de tráfico enviada a los dos objetos AV, configure la distribución de las peticiones de análisis
antivirus tal y como se indica a continuación:
• El dispositivo NetScreen redirige todas las respuestas de análisis antivirus HTTP a los dos objetos AV. Las
dos directivas que permiten el tráfico HTTP hacen referencia a sendos objetos AV.
1. Primera respuesta HTTP -> scanner1
Zona DMZ
2. Segunda respuesta HTTP -> mailsvr1
scanner2 (si scanner1 no ha
terminado de analizar la
primera respuesta HTTP; si Zona Untrust Zona Trust
scanner1 está libre, el 1
dispositivo NetScreen redirige
la segunda respuesta HTTP a Internet LAN
scanner1) 2
Objetos AV
(analizadores
antivirus) scanner1 scanner2
en la zona Trust

• El dispositivo NetScreen envía peticiones de análisis antivirus a scanner1 para todo el tráfico SMTP desde
el servidor de correo remoto (llamado “r-mail”) en la zona Untrust al servidor de correo local (llamado
“mailsvr1") en la zona DMZ. El dispositivo NetScreen envía peticiones de análisis antivirus a scanner2 para
todo el tráfico SMTP desde la zona Trust.
Desde la zona Untrust Zona DMZ Desde la zona Trust

Todo el tráfico SMTP -> mailsvr1 Todo el tráfico SMTP ->
scanner1 scanner2
servidor
r-mail LAN
Objetos AV
(analizadores
antivirus)
en la zona Trust scanner1 scanner2
Los dos objetos AV se encuentran en la zona Trust. Aunque habilite una directiva para la comprobación antivirus
del tráfico, no es necesario configurar otra directiva para permitir el tráfico CSP entre el dispositivo NetScreen y los
analizadores antivirus. Todas las zonas se encuentran en el dominio de enrutamiento Trust-vr.
WebUI
1. Interfaces
Zone Name: Trust

Interface Mode: NAT

Zone Name: DMZ
Zone Name: Untrust
2. Objeto AV 1
Contents:
3. Objeto AV 2
Contents:

4. Direcciones
Address Name: mailsrv1
Zone: DMZ
Address Name: r-mail
Zone: Untrust
5. Ruta
Source Address:

Service: HTTP
Action: Permit
básica:
Source Address:
Address Book Entry: (seleccione), r-mail
Service: MAIL
Action: Permit
básica:

Source Address:
Service: MAIL
Action: Permit
básica:
CLI
1. Interfaces
2. Objeto AV 1
set av scanner1 content smtp

3. Objeto AV 2
set av scanner1 content smtp
4. Direcciones
set address dmz mailsvr1 1.2.2.6/32
set address untrust r-mail 2.2.2.5/32
5. Ruta
ns-> set policy id 1 from trust to untrust any any http permit av scanner1
ns-> set policy id 1
ns(policy:1)-> exit
ns->
set policy id 2 from untrust to dmz r-mail mailsvr1 mail permit av scanner1
set policy id 3 from trust to dmz any mailsvr1 mail permit av scanner2
save

Capítulo 4 Supervisión y filtrado de contenidos Filtrado de URL
FILTRADO DE URL
NetScreen admite el filtrado de URL mediante “Websense Enterprise Engine”, que permite bloquear o permitir el
acceso a diferentes sitios basándose en sus URLs, nombres de dominio y direcciones IP. Con la API de Websense
incorporada directamente en el cortafuegos NetScreen, el dispositivo NetScreen puede conectarse directamente a
un servidor de filtrado de URL Websense.
La siguiente ilustración muestra la secuencia básica de acontecimientos que se produce cuando un host en la zona
Trust intenta establecer una conexión HTTP con un servidor en la zona Untrust. Sin embargo, el filtrado de URL
determina que la URL está prohibida.
URL bloqueada
set policy from trust to untrust any any http permit url-filter
Servidor de filtrado de
URL (en la zona Trust)
3 4
Cliente HTTP Petición de Respuesta de filtrado de Servidor
filtrado de URL URL: “block (bloquear)” HTTP
Zona Trust Zona Untrust

Establecimiento
de comunicación 1 SYN
SYN/ACK
TCP de 3 fases ACK
Petición 2 HTTP GET
HTTP-Get
El dispositivo NetScreen intercepta y almacena en búfer la
petición HTTP GET. A continuación envía la URL solicitada
al servidor de filtrado de URL. El servidor de filtrado de URL
responde con un mensaje de bloqueo.
TCP RST RST RST

5
Mensaje de
URL BLCK URL
bloqueada El dispositivo NetScreen descarta el paquete
HTTP y cierra la conexión, enviado un mensaje
TCP RST a las direcciones de origen y destino.
También envía a la dirección de origen un
mensaje de URL bloqueada.

Si el servidor de filtrado de URL permite el acceso a la URL, la secuencia de acontecimientos en el intento de

conexión HTTP será tal y como se indica a continuación:
URL permitida
Servidor de filtrado de
URL (en la zona Trust)
3 4
Cliente HTTP Petición de Respuesta de filtrado de Servidor
filtrado de URL URL: “permit (permitir)” HTTP
Zona Trust Zona Untrust

Establecimiento
de comunicación SYN
TCP de 3 fases 1 SYN/ACK
ACK
Petición
HTTP-Get 2 HTTP GET
El dispositivo NetScreen intercepta y almacena en búfer la
petición HTTP GET. A continuación envía la URL
solicitada al servidor de filtrado de URL. El servidor de
filtrado de URL responde con un mensaje de permiso.
Reenvío de la
petición HTTP 5 HTTP GET
GET
HTTP PUT
El dispositivo NetScreen reenvía el paquete HTTP
almacenado en búfer a la dirección de destino. También
permite el paso de otras peticiones HTTP GET en la
misma sesión sin realizar más filtrados de URL.
HTTP GET
Otras peticiones HTTP PUT
HTTP GET sin 6 HTTP GET
filtrado URL
HTTP PUT
HTTP GET

Si utiliza Websense, el administrador puede hacer lo siguiente:

• Alterar la base de datos de filtrado de URL para bloquear o permitir el acceso a ciertos sitios seleccionados
• Programar distintos perfiles de filtrado de URL a distintas horas del día
• Descargar registros de Websense Reporter de las URL bloqueadas o visitadas
Nota: Si desea obtener más información sobre Websense, visite www.websense.com.
Los dispositivos NetScreen con sistemas virtuales admiten hasta ocho servidores de filtrado de URL distintos: un
servidor reservado para el sistema raíz, que se puede compartir con un número ilimitado de sistemas virtuales, y
siete servidores de filtrado de URL para el uso privado por parte de los sistemas virtuales. Un administrador del
nivel raíz puede configurar el módulo de filtrado de URL en el nivel de sistema raíz y el nivel de sistemas virtuales
(vsys). Un administrador del nivel vsys puede configurar el módulo URL de su propio sistema virtual, siempre que
dicho sistema disponga de su propio servidor de filtrado de URL dedicado. Si el administrador del nivel vsys utiliza
los ajustes del servidor raíz de filtrado de URL, podrá ver (pero no modificar) los ajustes de filtrado de URL de nivel
raíz.
Para configurar un dispositivo NetScreen para el filtrado de URL, debe llevar a cabo los siguientes pasos:
1. Establezca la comunicación con un máximo de ocho servidores de filtrado URL.
2. Defina ciertos parámetros de comportamiento en el nivel de sistema. Un conjunto de parámetros se puede
aplicar al sistema raíz y a cualquier vsys que comparta la configuración de filtrado de URL con el sistema
raíz. Otros conjuntos se pueden aplicar a sistemas virtuales que dispongan de su propio servidor de filtrado
de URL dedicado.
3. Active el filtrado de URL a los niveles raíz y vsys.
4. Habilite el filtrado de URL en directivas individuales.
A continuación se detallan estos pasos.

1. Comunicaciones de dispositivo a dispositivo

En primer lugar debe definir los ajustes del servidor Websense y los parámetros de comportamiento del
dispositivo NetScreen en relación con el filtrado URL. Si configura estos ajustes en el sistema raíz, también
se aplicarán a cualquier sistema virtual que comparta la configuración de filtrado de URL con el sistema
raíz. En el caso de un sistema virtual que disponga de su propio servidor de filtrado de URL dedicado, el
administrador raíz o el administrador vsys deberá configurar los ajustes por separado para ese vsys.
Los ajustes de filtrado de URL que debe definir en el nivel de sistema para las comunicaciones de
dispositivo a dispositivo son éstos:
– Websense Server Name (Nombre del servidor Websense): dirección IP o nombre de dominio
completo (FQDN) del equipo en el que se ejecuta el servidor Websense.
– Websense Server Port (Puerto del servidor Websense): el puerto predeterminado de Websense
es 15868. Si modifica el puerto predeterminado en el servidor Websense también deberá cambiarlo
en el dispositivo NetScreen. Para más información consulte la documentación de Websense.
– Source Interface (Interfaz de origen): interfaz de origen desde la cual el dispositivo NetScreen inicia
las peticiones de filtrado de URL para un servidor Websense cuando las envía a través de un túnel
VPN. (Tenga en cuenta que la interfaz de origen es distinta de la interfaz de salida, que es la interfaz
para el tráfico VPN). Normalmente, el servidor de filtrado URL pertenece a la zona Trust. Sin
embargo, si desea que varios dispositivos NetScreen accedan a un único servidor de filtrado de URL,
deberá configurar túneles VPN desde cada dispositivo remoto al dispositivo NetScreen local que
protege el servidor. Desde el punto de vista de los equipos remotos, el servidor se encuentra en una
zona Untrust, por lo que le enviarán las peticiones de filtrado de URL a través de los túneles.
– Communication Timeout (Tiempo de espera de comunicaciones): intervalo de tiempo en
segundos durante el cual el dispositivo NetScreen espera una respuesta del servidor de filtrado
Websense. Si el servidor Websense no responde dentro del tiempo especificado, el dispositivo
NetScreen bloquea la petición o la permite, según se haya configurado (consulte más adelante).
Puede utilizar el siguiente comando CLI para configurar estos ajustes:
set url server { ip_addr | dom_name } port_num timout_num
En la interfaz WebUI, introduzca estos ajustes en los campos correspondientes de la página Screening >
URL Filtering.

2. Parámetros de comportamiento en el nivel de sistema

En segundo lugar debe definir los parámetros de comportamiento que el sistema (raíz o sistema virtual)
deberá adoptar en relación con el filtrado de URL. A continuación se ofrecen las opciones de
comportamiento:
– Modo de fallo/paso: si el dispositivo NetScreen pierde el contacto con el servidor Websense, puede
especificar si desea bloquear (“Block”) o permitir (“Permit”) todas las peticiones HTTP.
– Tipo de mensaje de URL bloqueada: el origen del mensaje que el usuario recibe cuando Websense
bloquea un sitio. Si selecciona NetPartners Websense, el dispositivo NetScreen reenvía el mensaje
recibido en la respuesta de bloqueo del servidor Websense. Si selecciona NetScreen, el dispositivo
NetScreen envía el mensaje previamente introducido en el campo “NetScreen Blocked URL
Message”.
Nota: Si selecciona NetScreen, algunas de las funciones que ofrece Websense, como el
redireccionamiento, quedarán suprimidas.
– Mensaje de URL bloqueada de NetScreen: mensaje que el dispositivo NetScreen envía al usuario
tras bloquear un sitio. Puede utilizar el mensaje enviado desde el servidor Websense o crear un
mensaje (de hasta 500 caracteres) para que se envíe desde el dispositivo NetScreen.
Puede utilizar los siguientes comandos CLI para configurar estos ajustes:
set url fail-mode { block | permit }
set url type { NetScreen | Websense }
set url message string
En la interfaz WebUI, introduzca estos ajustes en los campos correspondientes de la página Screening >
URL Filtering.

3. Activación en el nivel de sistema

Una vez finalizada la configuración, debe habilitar el filtrado de URL en el nivel de sistema. En el caso de un
dispositivo NetScreen que actúe como host para sistemas virtuales, deberá habilitar el filtrado de URL para
cada sistema en el que desee aplicarlo. Por ejemplo, si desea que el filtrado de URL se aplique en el
sistema raíz y en un sistema virtual, deberá habilitar el filtrado en ambos sistemas.
Puede utilizar el siguiente comando CLI para activar y desactivar el filtrado de URL en el nivel de sistema:
set url config { disable | enable }
En la interfaz WebUI, seleccione o anule la selección de la casilla de verificación Enable URL Filtering via
Websense Server en la página Screening > URL Filtering.
Si habilita el filtrado de URL en el nivel de sistema, el dispositivo NetScreen comprobará el tráfico HTTP al
que se apliquen las directivas (definidas en ese sistema) relativas al filtrado de URL redirigiendo las
peticiones HTTP a un servidor Websense. Si deshabilita el filtrado de URL en el nivel de sistema, el
dispositivo NetScreen no tendrá en cuenta el componente de filtrado de URL en las directivas y las
considerará simples directivas de permiso.
4. Aplicación en el nivel de directivas

Finalmente podrá configurar el dispositivo NetScreen para que entre en contacto con el servidor de filtrado
de URL según cada directiva.
Puede utilizar el siguiente comando CLI para habilitar el filtrado de URL en una directiva:
set policy from zone to zone src_addr dst_addr service permit url-filter
En la interfaz WebUI, seleccione la casilla de verificación URL Filter en la página de configuración de
directivas Advanced de la directiva en la que desee aplicar el filtrado de URL.
Nota: El dispositivo NetScreen informa sobre el estado del servidor Websense. Para actualizar el informe
de estado, haga clic en el icono Server Status de la página Screening > URL Filtering en la interfaz WebUI.

Ejemplo: Configuración del filtrado de URL

En este ejemplo configuraremos el dispositivo NetScreen para que se combine con un servidor de filtrado de URL
en la dirección IP 10.1.2.5, con el número de puerto 15868 (predeterminado). El servidor de filtrado URL se
encuentra en la zona Trust. Queremos aplicar el filtrado a todo el tráfico HTTP saliente desde hosts situados en la
zona Trust hacia hosts en la zona Untrust. Si el dispositivo NetScreen pierde la conexión con el servidor de filtrado
URL, queremos que el dispositivo NetScreen permita el tráfico HTTP saliente. Si un cliente HTTP solicita el acceso
a una URL prohibida, queremos que el dispositivo NetScreen envíe el siguiente mensaje: “Lo sentimos, la dirección
URL solicitada está prohibida. Si cree que esta prohibición puede ser errónea, póngase en contacto con
ntwksec@miempresa.com”.
La interfaz de la zona Untrust es ethernet3 y tiene la dirección IP 1.1.1.1/24. La interfaz de la zona Trust es
ethernet1 y tiene la dirección IP 10.1.1.1/24. Las dos zonas se encuentran en el dominio de enrutamiento trust-vr.
Como el servidor de filtrado URL no se encuentra en la subred inmediata de una de las interfaces del dispositivo
NetScreen, deberá agregarle una ruta a través de ethernet1 y del enrutador interno a 10.1.1.250.
WebUI
1. Interfaces
Zone Name: Trust

Interface Mode: NAT
Zone Name: Untrust

2. Servidor de filtrado de URL

Screening > URL Filtering: Introduzca los siguientes datos y haga clic en Apply:
Enable URL Filtering via Websense Server: (seleccione)
Nombre del servidor Websense: 10.1.2.5
Websense Server Port: 15868
Communication Timeout: 10 (segundos)
If connectivity to the Websense server is lost … all HTTP requests: Permit
Blocked URL Message Type: NetScreen
NetScreen Blocked URL Message: Lo sentimos, la dirección URL solicitada
está prohibida. Si cree que esta prohibición puede ser errónea, póngase
en contacto con ntwksec@miempresa.com.
3. Rutas

4. Directiva
Source Address:
Service: HTTP
Action: Permit
> Advanced: Seleccione la casilla de verificación URL Filter y haga clic en
Return para configurar las opciones avanzadas y regresar a la página de
configuración básica.
CLI
1. Interfaces
2. Servidor de filtrado de URL
set url server 10.1.2.5 15868 10
set url fail-mode permit
set url type NetScreen
set url message “Lo sentimos, la dirección URL solicitada está prohibida. Si
cree que esta prohibición puede ser errónea, póngase en contacto con
ntwksec@miempresa.com.”
set url config enable
3. Rutas
4. Directiva
save

Capítulo 5
Deep Inspection
5
Puede habilitar Deep Inspection (DI) en directivas para examinar el tráfico permitido y ejecutar las acciones
correspondientes si el módulo de DI en ScreenOS detecta signos de ataque o anomalías en el protocolo. En las
secciones siguientes de este capítulo se presentan los elementos de Deep Inspection que aparecen en directivas y
se explica cómo configurarlos:
• “Resumen de Deep Inspection” en la página 142
• “Servidor de la base de datos de objetos de ataque” en la página 147
• “Objetos de ataque y grupos” en la página 156
– “Firmas completas” en la página 158
– “Firmas de secuencias TCP” en la página 159
– “Anomalías en el protocolo” en la página 160
– “Grupos de objetos de ataque” en la página 160
• “Acciones de ataque” en la página 163
• “Asignación de servicios personalizados a aplicaciones” en la página 174
• “Objetos de ataque y grupos personalizados” en la página 178
– “Objetos de ataque de firma completa definidos por el usuario” en la página 178
– “Objetos de ataque de la firma de la secuencia TCP” en la página 186
Deep Inspection también se puede habilitar a nivel de zonas de seguridad para componentes de HTTP. En la
sección final de este capítulo se explican estas opciones SCREEN:
• “Bloqueo granular de los componentes de HTTP” en la página 189
– “Controles ActiveX” en la página 189
– “Applets de Java” en la página 190
– “Archivos EXE” en la página 190
– “Archivos ZIP” en la página 190

Capítulo 5 Deep Inspection Resumen de Deep Inspection
RESUMEN DE DEEP INSPECTION

Deep Inspection (DI) es un mecanismo para filtrar el tráfico permitido por el cortafuegos de NetScreen. Deep
Inspection examina los encabezados de los paquetes de las capas Layer 3 y Layer 4, así como las características
del protocolo y el contenido a nivel de aplicación de la capa Layer 7 para detectar e impedir cualquier ataque o
1
comportamiento anómalo que pueda presentarse .
Inspección de ¿Cumple un paquete inicial de una

estado completa ¿Cumple? No sesión los requisitos L3 y L4 de
del cortafuegos Descartar una directiva?
o
paquete ¿Cumple el estado de un paquete
Sí en una sesión existente las
expectativas en la tabla de
sesiones?
¿Permitir? No ¿La directiva permite o deniega
este paquete?
Descartar
paquete
Sí
Inspección de estado ¿Detecta

completa de firmas, ¿DI? Sí do Sí
anomalías de protocolos ataque?
y (en el dispositivo Ejecutar acción
NetScreen-5000) de la de respuesta al
secuencia TCP No No ataque
Reenviar el
paquete
1. NetScreen detecta patrones de tráfico anómalo en las capas 3 y 4 (IP y TCP) a través de opciones SCREEN establecidas a nivel de zonas, no a nivel de
directivas. Algunos ejemplos de detección de anomalías en el tráfico IP y TCP son “Limpieza de direcciones IP” en la página 10, “Análisis de puertos” en la
página 12, así como los diversos ataques de inundación descritos en “Ataques DoS contra la red” en la página 56.

Cuando el dispositivo NetScreen recibe el primer paquete de una sesión, examina las direcciones IP de origen y de
destino en el encabezado del paquete IP (inspección de Layer 3) y tanto los números de puerto de origen y de
destino como el protocolo en el segmento TCP o en el encabezado del datagrama UDP (inspección de Layer 4). Si
los componentes de Layer 3 y 4 cumplen los criterios especificados en una directiva, el dispositivo NetScreen aplica
2
al paquete la acción especificada: permit, deny o tunnel . Cuando el dispositivo NetScreen recibe un paquete
destinado a una sesión establecida, lo compara con la información de estado actualizada en la tabla de sesiones
para determinar si realmente pertenece a la sesión.
Si en la directiva aplicable a este paquete está habilitado Deep Inspection y la acción de la directiva es “permit” o
“tunnel”, el dispositivo NetScreen analiza más detenidamente tanto el paquete como la secuencia de datos
asociada (“stream”) en busca de objetos de ataque. Los objetos de ataque pueden ser firmas de ataque o
anomalías en el protocolo, que el usuario puede definir o descargar al dispositivo NetScreen desde un servidor de
3
base de datos de objetos de ataque . (Para obtener más información, consulte “Objetos de ataque y grupos” en la
página 156 y “Objetos de ataque y grupos personalizados” en la página 178). Basándose en los objetos de ataque
especificados en la directiva, el dispositivo NetScreen puede realizar las inspecciones siguientes:
• Examinar los valores del encabezado y los datos transportados en busca de firmas de ataque completas
• Comparar el formato del protocolo transmitido con los estándares especificados en las normas RFC y en
sus extensiones con respecto a ese protocolo para determinar si ha sido alterado, posiblemente con fines
malévolos
2. Si la acción especificada es tunelizar, ésta implica un permiso (tráfico permitido). Observe que si habilita Deep Inspection (DI) en una directiva cuya acción
sea tunelizar, el dispositivo NetScreen ejecuta las operaciones DI especificadas antes de encriptar un paquete saliente y después de desencriptar un
paquete entrante.
3. Para poder descargar objetos de ataque del servidor de base de datos primero es necesario suscribirse al servicio. Para obtener más información, consulte
“Registro y activación de los servicios de firma” en la página 2 -574.

Primero: Inspección del cortafuegos (capas de red): Después: Deep Inspection (capas de red y aplicación):
IP ORIG, IP DEST, Pto ORIG, IP ORIG, IP DEST, Pto ORIG,
Pto DEST y servicio (PROTO) Pto DEST, servicio (PROTO) y Datos transportados
Cortafuegos Deep Inspection
IP ORIG IP DEST PTO PTO PROTO IP ORIG IP DEST PTO PTO PROTO
ORIG DEST ORIG DEST
Datos transportados Datos transportados
Si el dispositivo NetScreen detecta un objeto de ataque, realiza la acción especificada en el componente DI de la

directiva: cerrar (“close”), cerrar cliente (“close-client”), cerrar servidor (“close-server”), descartar (“drop”), descartar
paquete (“drop-packet”), ignorar (“ignore”) o ninguna. Si no encuentra ninguno de los objetos de ataque
especificados, reenvía el paquete. (Para obtener más información sobre acciones de ataque, consulte “Acciones de
ataque” en la página 163).
El siguiente comando set policy contiene un componente de DI:
Componente de Deep Inspection
Zona de Dirección de Servicio Grupo de Acción si el dispositivo

origen origen ataque NetScreen detecta un
Zona de Dirección de Acción si el tráfico cumple ataque
destino destino los criterios de los
componentes L3 y L4

El comando antedicho ordena al dispositivo NetScreen permitir el tráfico HTTP procedente de cualquier dirección
de la zona Untrust a la dirección de destino “websrv1” de la zona DMZ. También ordena al dispositivo NetScreen
examinar todo el tráfico HTTP permitido por esta directiva. Si encuentra cualquier objeto de ataque definido en el
grupo de objetos de ataque “HIGH:HTTP:ANOM”, el dispositivo NetScreen cierra la conexión descartando el
paquete y enviando notificaciones TCP RST al origen y al destino.
El comando set policy se puede separar conceptualmente en dos partes: la sección central y el componente DI:
• La sección central contiene las zonas de origen y de destino, las direcciones de origen y de destino, uno o
4
más servicios y una acción .
• El componente DI ordena al dispositivo NetScreen examinar el tráfico permitido por la sección central de la
directiva para saber si hay objetos de ataque contenidos en al menos uno de los grupos de objetos de
ataque especificados. Si el dispositivo NetScreen detecta un objeto de ataque, el dispositivo NetScreen
ejecuta la acción indicada en el componente DI.
Es posible introducir el contexto de una directiva existente utilizando su número de identificación. Por ejemplo:
ns(policy:1)->
Nota: El símbolo de la línea de comandos cambia para indicar que el comando siguiente se ejecutará en
un contexto determinado.
4. Opcionalmente, también puede agregar otras extensiones al componente central de un comando set policy: referencias a túneles VPN y L2TP, referencia
a una tarea programada, especificaciones de la traducción de direcciones, especificaciones de la autenticación de usuarios y ajustes de comprobación
antivirus, registros, recuentos y administración del tráfico. Mientras que estas extensiones son opcionales, los elementos que constituyen el núcleo de una
directiva (zonas de origen y de destino, direcciones de origen y de destino, servicio -o servicios- y la acción) son obligatorios. (Una excepción a esta regla
son las directivas globales, en las que no se especifican zonas de origen ni de destino: set policy global src_addr dst_addr service action. Para obtener
más información sobre directivas globales, consulte “Directivas globales” en la página 2 -224.

Introducirse en el contexto de una directiva resulta práctico para introducir varios comandos relacionados con una
sola directiva. Por ejemplo, el siguiente conjunto de comandos crea una directiva que permite el tráfico HTTP y
HTTPS desde cualquier dirección de Untrust a websrv1 y websrv2 en la zona DMZ y busca ataques HTTP de firma
completa y de anomalías de protocolo de gravedad media, alta y crítica:
ns-> set policy id 1 from untrust to dmz any websrv1 http permit attack
CRITICAL:HTTP:ANOM action close
ns(policy:1)-> set dst-address websrv2
ns(policy:1)-> set service https
ns(policy:1)-> set attack CRITICAL:HTTP:SIGS
ns(policy:1)-> set attack HIGH:HTTP:ANOM
ns(policy:1)-> set attack HIGH:HTTP:SIGS
ns(policy:1)-> exit
ns-> save
La configuración antedicha permite el tráfico HTTP y HTTPS, pero solamente busca posibles ataques en el tráfico
HTTP. Para poder agregar grupos de objetos de ataque con un contexto de directiva, primero debe especificar un
ataque y una acción DI en el comando de nivel superior. En el ejemplo antedicho, puede agregar los grupos de
objetos de ataque CRITICAL:HTTP:SIGS, HIGH:HTTP:ANOM y HIGH:HTTP:SIGS porque anteriormente configuró
la directiva para Deep Inspection con el grupo CRITICAL:HTTP:ANOM.
Nota: Solamente puede especificar una acción de ataque por directiva. Para obtener información sobre las siete
acciones de ataque, consulte “Acciones de ataque” en la página 163.

Capítulo 5 Deep Inspection Servidor de la base de datos de objetos de ataque
SERVIDOR DE LA BASE DE DATOS DE OBJETOS DE ATAQUE

La base de datos de objetos de ataque contiene todos los objetos de ataque predefinidos, organizados en grupos
de objetos de ataque por protocolo y nivel de gravedad. NetScreen almacena la base de datos de objetos de ataque
en un servidor en la dirección https://services.netscreen.com/restricted/sigupdates. Para utilizar los objetos de
ataque predefinidos, debe descargar la base de datos de este servidor, cargarlo en su dispositivo NetScreen y
luego establecer referencias a determinados grupos de objetos de ataque específicos en directivas. Para obtener
acceso al servidor de la base de datos de objetos de ataque, primero debe suscribirse al servicio de firmas DI para
su dispositivo NetScreen. (Para obtener información sobre cómo hacerlo, consulte “Registro y activación de los
servicios de firma” en la página 2 -574).
Nota: ScreenOS contiene un certificado CA para autenticar la comunicación con el servidor de la base de datos de
objetos de ataque.
Existen cuatro maneras de actualizar la base de datos:

• Immediate Update: Con esta opción se actualiza la base de datos de objetos de ataque en el dispositivo
NetScreen inmediatamente con la base de datos almacenada en el servidor de base de datos de objetos de
ataque. Para que esta operación funcione, primero debe configurar los ajustes del servidor de la base de
datos de objetos de ataque. (Para ver un ejemplo, consulte el “Ejemplo: Actualizar inmediatamente” en la
página 148.)
Nota: Antes de realizar una actualización inmediata de la base de datos, puede utilizar el comando exec
attack-db check para comprobar si la base de datos de objetos de ataque en el servidor es más reciente
que la que se encuentra en el dispositivo NetScreen.
• Automatic Update: Con esta opción, el dispositivo NetScreen descarga la base de datos de objetos de
ataque directamente al dispositivo NetScreen a las horas programadas por el usuario, siempre que la base
de datos del servidor sea una versión más reciente que la cargada anteriormente en el dispositivo
NetScreen. NetScreen actualiza la base de datos periódicamente con nuevos los patrones de ataque recién
descubiertos. Por lo tanto, debido a su naturaleza cambiante, también conviene actualizar el dispositivo
NetScreen periódicamente. Para que esta operación funcione, primero debe configurar los ajustes del
servidor de la base de datos de objetos de ataque. (Para ver un ejemplo, consulte el “Ejemplo:
Actualizaciones automáticas” en la página 150).

• Automatic Notification and Immediate Update: Con esta opción, el dispositivo NetScreen comprueba a
las horas programadas por el usuario si los datos sobre el servidor de la base de datos de objetos de
ataque son más recientes que los del dispositivo NetScreen. Si los datos del servidor son más recientes,
aparece un aviso en la página inicial de WebUI y en CLI después de iniciar sesión en el dispositivo
NetScreen. A continuación, puede ejecutar el comando exec attack-db update o hacer clic en el botón
Update Now de la página “Configuration > Update > Attack Signature” de WebUI para guardar la base de
datos del servidor en el dispositivo NetScreen. Para que el procedimiento semiautomático de comprobación
del servidor funcione, primero debe configurar los ajustes del servidor de la base de datos de objetos de
ataque. (Para ver un ejemplo, consulte el “Ejemplo: Notificación automática y actualización inmediata” en la
página 152.)
• Manual Update: Con esta opción, primero utilizará un explorador de web para descargar la base de datos
de objetos de ataque a un directorio local o al directorio del servidor TFTP. A continuación puede cargar la
base de datos en el dispositivo NetScreen mediante WebUI (desde el directorio local) o mediante CLI
(desde el directorio del servidor TFTP). (Para ver un ejemplo, consulte el “Ejemplo: Actualización manual”
en la página 154.)
Ejemplo: Actualizar inmediatamente

En este ejemplo guardará inmediatamente la base de datos de objetos de ataque (el archivo attacks.bin) del
servidor correspondiente al dispositivo NetScreen. Utilizará la URL predeterminada:
https://services.netscreen.com/restricted/sigupdates. No tiene que establecer esta URL para el servidor de la base
de datos. El dispositivo NetScreen la utiliza de forma predeterminada.
No necesita establecer una tarea programada para actualizar la base de datos en el dispositivo NetScreen. En lugar
de ello, guardará la base de datos del servidor en el dispositivo NetScreen inmediatamente.
Nota: Este ejemplo asume que ya dispone de una suscripción activada para el servicio de firmas de DI para el
dispositivo NetScreen. (Para obtener información sobre suscripciones, consulte “Claves de licencia” en la página
2 -572).

Dispositivo NetScreen Servidor de la base de datos

local de objetos de ataque
1. Petición de
actualización
Internet
Base de datos 2. Actualización de la Base de datos https://services.netscreen

de objetos de base de datos de objetos de .com/restricted/sigupdates
ataque ataque
WebUI
Configuration > Update > Attack Signature: Haga clic en el botón Update Now.
CLI
ns-> exec attack-db update
Loading attack database.............
Done.
Done.
Switching attack database...Done
Saving attack database to flash...Done.
ns->

Ejemplo: Actualizaciones automáticas

En este ejemplo establecerá una tarea programada para actualizar la base de datos en el dispositivo NetScreen
cada lunes a las 4:00. A esa hora programada, el dispositivo NetScreen comparará la versión de la base de datos
en el servidor con la del dispositivo NetScreen. Si la versión del servidor es más reciente, el dispositivo NetScreen
reemplazará automáticamente su base de datos con la versión más reciente.
2 -572).
Utilizará la URL predeterminada: https://services.netscreen.com/restricted/sigupdates. No tiene que establecer esta

URL para el servidor de la base de datos. El dispositivo NetScreen la utiliza de forma predeterminada.
Dispositivo NetScreen Servidor de la base de

local datos de objetos de ataque
1. Petición de actualización
automática
L M X J V S D
Internet
Base de datos Base de datos URL = https://services.netscreen

2. Actualización automática de la de objetos de .com/restricted/sigupdates
de objetos de base de datos
ataque ataque

WebUI
Configuration > Update > Attack Signature: Introduzca los siguientes datos y haga clic en OK:
Database Server: (dejar en blanco)
Update Mode: Automatic Update
Schedule:
Weekly on: Monday5
Time (hh:mm): 04:00
CLI
set attack db mode update
set attack db schedule weekly monday 04:00
save
5. Si programa actualizaciones mensualmente y la fecha elegida no existe en algún mes (por ejemplo, el día 31 no existe en algunos meses), el dispositivo
NetScreen utiliza en su lugar la última fecha posible de ese mismo mes.

Ejemplo: Notificación automática y actualización inmediata

En este ejemplo establecerá una tarea programada para comprobar diariamente a las 7:00 la base de datos en el
dispositivo NetScreen.
Cuando reciba un aviso de que la base de datos del servidor se ha actualizado, haga clic en el botón Update Now
de la página “Configuration > Update > Attack Signature” de WebUI o ejecute el comando exec attack-db update
para guardar la base de datos del servidor en el dispositivo NetScreen.
2 -572).
Utilizará la URL predeterminada: https://services.netscreen.com/restricted/sigupdates. No tiene que establecer esta

URL para el servidor de la base de datos. El dispositivo NetScreen la utiliza de forma predeterminada.
Dispositivo NetScreen Servidor de la base de datos

local 1. Comprobación automática diaria de objetos de ataque
de la actualización
L M X J V S D
Internet
URL = https://services.netscreen
.com/restricted/sigupdates
Base de datos de 2. Actualización inmediata de la Base de datos de
objetos de ataque base de datos objetos de ataque

WebUI
1. Comprobación programada de la base de datos
Database Server: (dejar en blanco)
Update Mode: Automatic Notification
Schedule:
Daily
Time (hh:mm): 07:00
2. Actualización inmediata de la base de datos
Cuando reciba un aviso de que la base de datos de ataques del servidor está más actualizada que la del
dispositivo NetScreen, haga lo siguiente:
Configuration > Update > Attack Signature: Haga clic en el botón Update Now.
CLI
1. Comprobación programada de la base de datos
set attack db mode notification
set attack db schedule daily 07:00
2. Actualización inmediata de la base de datos
Cuando reciba un aviso de que la base de datos de ataques del servidor está más actualizada que la del
dispositivo NetScreen, haga lo siguiente:
exec attack-db update

Ejemplo: Actualización manual

En este ejemplo guardará manualmente la base de datos de objetos de ataque más reciente en el directorio local
“C:\netscreen\attacks-db” (si desea utilizar WebUI para cargar la base de datos) o en C:\Archivos de
Programa\TFTP Server (si prefiere utilizar CLI). A continuación cargará la base de datos en el dispositivo
6
NetScreen de su directorio local .
Para una actualización automática, el dispositivo NetScreen agregará automáticamente los siguientes elementos a
la URL:
• Número de serie del dispositivo NetScreen
• Número de la versión principal de ScreenOS instalada en el dispositivo
• Tipo de plataforma
Para actualizar manualmente la base de datos, debe agregar estos elementos por su cuenta. En este ejemplo, el
número de serie es 0043012001000213, la versión de ScreenOS es 5.0 y la plataforma es NetScreen-208 (ns200).
Por lo tanto, la URL resultante es:
https://services.netscreen.com//restricted/sigupdates/5.0/ns200/attacks.bin?sn=0043012001000213
2 -572).
6. Después de descargar la base de datos de objetos de ataque, también puede colocarla en un servidor local y configurarla para que otros dispositivos
NetScreen puedan acceder a ella. A continuación, los administradores de los demás dispositivos deben cambiar la URL del servidor de la base de datos a
la nueva ubicación. Pueden introducir la nueva URL en el campo “Database Server” de la página “Configuration > Update > Attack Signature” o utilizar el
comando CLI siguiente: set attack db server url_string.

Servidor de la base de datos

Dispositivo NetScreen local de objetos de ataque
1. Descarga manual de la base de datos
Internet
URL = https://services.netscreen.com/
Base de datos 2. Actualización Admin: 10.1.1.5 Base de datos /restricted/sigupdates/5.0/ns200/attacks
de objetos de manual de la C:\netscreen\attacks-db de objetos de .bin?sn=0043012001000213
ataque base de datos C:\Archivos de programa\TFTP ataque
Server
1. Descarga de la base de datos

Introduzca la URL siguiente en el campo de dirección de su explorador de web:
https://services.netscreen.com//restricted/sigupdates/5.0/ns200/attacks.bin?sn=0043012001000213
Guarde el archivo attacks.bin en el directorio local “C:\netscreen\attacks-db” (para cargar a través de
WebUI) o en el directorio “C:\Archivos de programa\TFTP Server” del servidor TFTP (cuando desee utilizar
CLI para cargarlo).
WebUI
2. Actualización de la base de datos
Deep Inspection Signature Update:
Load File: Introduzca C:\netscreen\attacks-db\attacks.bin, o haga clic
en Browse y navegue a ese directorio, seleccione attacks.bin y
finalmente haga clic en Open.
CLI
2. Actualización de la base de datos
save attack-db from tftp 10.1.1.5 attacks.bin to flash

Capítulo 5 Deep Inspection Objetos de ataque y grupos
OBJETOS DE ATAQUE Y GRUPOS

Los objetos de ataque son firmas completas y anomalías de protocolos que un dispositivo NetScreen utiliza para
detectar los ataques dirigidos comprometiendo a uno o varios hosts de una red. Los objetos de ataque están
agrupados, organizados por tipo de protocolo y luego por gravedad. Cuando se agrega Deep Inspection (DI) a una
directiva, el dispositivo NetScreen examina el tráfico que ésta permite para cualquier patrón que coincida con los
del grupo (o grupos) de objetos de ataque al que se hace referencia.
set policy from untrust to dmz any Attack Group: HIGH:HTTP:SIGS
websrv1 http permit attack
HIGH:HTTP:SIGS action close /scripts/\.\.%c1%9c\.\./.* .*%255(c|C).* .*\[.asp::$data\].*
PUT \[/users/.*\.asp\].* /phorum/plugin/replace/pluring.php?*p
/\[scripts/iisadmin/ism\.dll\?http/dir\].* revlog/.*
Host remoto NetScreen websrv1

1.1.1.3:25611 Untrust: ethernet3 1.1.1.1/24; DMZ: ethernet2 1.2.2.1/24 1.2.2.5:80
Zona Untrust Zona DMZ
SYN
SYN/ACK
ACK
IP ORIG IP DEST PTO PTO PROTO
ORIG DEST ¡Coincide!
1.1.1.3 1.2.2.5 25611 80 HTTP
Carga: … revlog/.
El dispositivo NetScreen detecta un objeto de ataque en el

paquete. Descarta el paquete y cierra la conexión enviando
notificaciones TCP RST al origen y al destino.
RST RST

Los grupos de objetos de ataque a los que se haga referencia en el componente DI deben apuntar al mismo tipo de
servicio que la directiva permite. Por ejemplo, si la directiva permite tráfico SMTP, el grupo de objetos de ataque
debe tener como objetivo los ataques contra el tráfico SMTP. La directiva siguiente muestra una configuración
válida:
set policy id 2 from trust to untrust any any smtp permit attack CRIT:SMTP:SIGS
3 action close
La siguiente directiva es incorrecta porque permite el tráfico SMTP, pero el grupo de objetos de ataque se refiere al
tráfico POP3:
2 set policy id 2 from trust to untrust any any smtp permit attack CRIT:POP3:SIGS
action close
La segunda directiva está mal configurada y, si se implementase, haría que el dispositivo NetScreen consumiese
recursos innecesariamente, ya que examinaría el tráfico SMTP en busca de objetos de ataque POP3 que nunca
encontraría. Si la directiva 2 permite tanto el tráfico SMTP como el POP3, puede configurar el componente DI para
que busque objetos de ataque SMTP, objetos de ataque POP3 o ambos.
set group service grp1
set group service grp1 add smtp
set group service grp1 add pop3
set policy id 2 from trust to untrust any any grp1 permit attack
3 CRIT:SMTP:SIGS action close
3 set policy id 2 attack CRIT:POP3:SIGS
Si el dispositivo NetScreen dispone de acceso a http://help.netscreen.com/sigupdates/english, puede consultar el

contenido de todos los grupos de objetos de ataque predefinidos y ver descripciones de los objetos de ataque
predefinidos. Abra su explorador web y escriba una de las siguientes URLs en el campo de dirección:
http://help.netscreen.com/sigupdates/english/DNS.html
http://help.netscreen.com/sigupdates/english/FTP.html
http://help.netscreen.com/sigupdates/english/HTTP.html
http://help.netscreen.com/sigupdates/english/IMAP.html
http://help.netscreen.com/sigupdates/english/POP3.html

http://help.netscreen.com/sigupdates/english/SMTP.html
Cada una de las URLs antedichas está vinculada a una página HTML que contiene una lista de todos los objetos de
ataque predefinidos (agrupados por gravedad) para un protocolo determinado. Para consultar la descripción de un
objeto de ataque, haga clic en su nombre.
Firmas completas
Una firma de ataque es un patrón que aparece cuando se está produciendo la explotación de una determinada
vulnerabilidad7. La firma puede ser un o patrón de tráfico de Layer 3 o 4, como cuando una dirección envía muchos
paquetes a diversos números de puerto de otra dirección (barrido de puertos), o un patrón textual, como cuando
aparece una cadena de URL maliciosa en los datos transportados de un único paquete HTTP o FTP. La cadena
también puede ser un segmento de código específico o un valor determinado en el encabezado del paquete. Sin
embargo, cuando el módulo Deep Inspection (DI) de un dispositivo NetScreen busca un patrón textual, busca algo
más que sólo una firma en un paquete; busca la firma en una porción muy concreta del mismo (incluso aunque esté
fragmentado o segmentado), en todos los paquetes enviados en un determinado momento durante la vida de la
sesión, y enviados por el iniciador de la conexión o por el dispositivo que responde.
Cuando el módulo DI busca un patrón textual, tiene en cuenta los papeles de los participantes (cliente o servidor) y
supervisa el estado de la sesión para limitar su búsqueda sólo los elementos afectados por la explotación de la
vulnerabilidad para la que los atacantes utilizan el patrón. La utilización de información contextual para refinar el
análisis de paquetes reduce significativamente las falsas alarmas (o “falsos positivos”) y evita el procesamiento
innecesario. El término “firmas completas” destaca este concepto de buscar firmas en los contextos de los papeles
de los participantes y en el estado de la sesión.
Para averiguar qué ventaja tiene considerar el contexto en el que se produce una firma, observe cómo el módulo
NetScreen DI examina los paquetes cuando está habilitado para detectar el ataque “EXPN Root”. Los atacantes
utilizan el ataque “EXPN Root” para ampliar y exponer las listas de distribución de un servidor de correo. Para
detectar el ataque “EXPN Root”, el dispositivo NetScreen busca la firma “expn root” en la porción de control de una
sesión del protocolo simple de transferencia de correo (“Simple Mail Transfer Protocol” o “SMTP”). El dispositivo
NetScreen examina solamente la porción de control porque el ataque sólo puede producirse ahí. Si “expn root”
ocurre en cualquier otra porción de la sesión, no es un ataque.
7. Dado que el módulo NetScreen DI admite expresiones regulares, puede utilizar comodines en la búsqueda de patrones. De este modo, una sola definición
de firma de ataque puede aplicarse a múltiples variaciones del patrón de ataque.

Aplicando una técnica textual simple de detección de firmas en los paquetes, la firma “expn root” dispara una
alarma incluso aunque aparezca en la porción de datos de la conexión SMTP; es decir, en el cuerpo de un mensaje
de correo electrónico. Si, por ejemplo, estuviese escribiendo a un colega un mensaje sobre ataques EXPN Root, un
detector simple de firmas en paquetes lo consideraría como un ataque. Utilizando firmas completas, el módulo
NetScreen DI puede distinguir entre cadenas de texto que señalan ataques y las que son ocurrencias inofensivas.
Firmas de secuencias TCP

Como ocurre con las firmas completa, una firma de secuencia TCP es un patrón que aparece cuando se está
produciendo la explotación de una vulnerabilidad. Sin embargo, cuando el módulo DI examina el tráfico en busca de
firmas completas, busca solamente en contextos concretos. Cuando el módulo DI examina el tráfico en busca de
firmas de secuencias TCP, lo hace sin preocuparse de los contextos. Otra diferencia entre ambos tipos de firmas es
que, aunque las firmas completas pueden ser predefinidas o definidas por el usuario, las firmas de secuencias TCP
sólo pueden ser definidas por el usuario. Después de agregar un objeto de ataque de firma de secuencia a un grupo
de objetos de ataque, puede hacer referencia a ese grupo en una directiva que aplique Deep Inspection. (Para
obtener más información sobre firmas de secuencias TCP, consulte “Objetos de ataque de la firma de la secuencia
TCP” en la página 186).
Nota: Las firmas de secuencias TCP sólo se pueden definir en sistemas de la serie NetScreen-5000.

Anomalías en el protocolo
Los objetos de ataque que buscan anomalías de protocolos detectan el tráfico que incumple los estándares
definidos en las normas RFC y extensiones comunes de RFC. Con los objetos de ataque de firma se debe utilizar
un patrón predefinido o crear uno nuevo; por lo tanto, sólo se pueden detectar ataques conocidos. La detección de
anomalías en los protocolos es particularmente útil para detectar nuevos ataques o aquéllos que no se pueden
definir con un patrón textual. ScreenOS admite objetos de ataque de anomalías de protocolos para los protocolos
siguientes:
• DNS
• FTP
• HTTP
• IMAP
• POP3
• SMTP
Grupos de objetos de ataque

Los grupos de objetos de ataque predefinidos contienen los objetos de ataque para un protocolo específico. Por
cada protocolo, los grupos se dividen en anomalías de protocolos y firmas completas, y luego se organizan
ligeramente por gravedad. Los tres niveles de gravedad del grupo de objetos de ataque son crítica, alta y media:
Critical (Críticos): Contiene objetos de ataque coincidentes con explotaciones de vulnerabilidad que intentan
evadir la detección, provocan la caída de dispositivos de red u obtienen privilegios a nivel del sistema.
High (Alto): Contiene objetos de ataque que coinciden con explotaciones de vulnerabilidades que intentan
interrumpir algún servicio, obtener acceso a nivel de usuario a un dispositivo de la red o activar un caballo troyano
cargado previamente en un dispositivo.
Medium (Medio): Contiene objetos de ataque que coinciden con explotaciones de vulnerabilidades que detectan
intentos de reconocimiento para acceder a información vital mediante navegación de directorios (“directory
traversal”) o filtraciones de información.

Cambio de los niveles de gravedad

Aunque los grupos de objetos de ataque están clasificados por protocolo y nivel de gravedad (critical, high,
medium), cada objeto de ataque tiene su propio nivel de gravedad específico: critical, high, medium, low, info. Estos
niveles de gravedad de objetos de ataque se corresponden del siguiente modo con los niveles de gravedad para las
entradas del registro de eventos:
Nivel de gravedad – se Nivel de seguridad

de objeto de ataque corresponde de entrada de
con – registro de eventos
Critical (Crítico) Critical
High (Alto) Error
Medium (Medio) Warning
Low (Bajo) Notification
Info Information
Por ejemplo, si el dispositivo NetScreen detecta un objeto de ataque con el nivel de gravedad "Medium", la entrada
correspondiente que aparecerá en el registro de eventos tendrá el nivel de gravedad "Warning".
El nivel de gravedad predeterminado de todos los objetos de ataque se puede anular en uno o más grupos de
objetos de ataque referenciados en una directiva. Esto se realiza a nivel de directiva, entrando en el contexto de
una directiva existente y asignando un nuevo nivel de gravedad a todos los grupos de objetos de ataque a los que
haga referencia la directiva.
A continuación se muestra cómo cambiar mediante WebUI y CLI el nivel de gravedad de los grupos de objetos de
ataque a los que se hace referencia en una directiva:
WebUI
Policies > Edit (para una directiva existente): Ejecute el siguiente procedimiento y haga clic en OK:
> Deep Inspection: Seleccione una opción de gravedad en la lista
desplegable “Severity” y haga clic en OK.

CLI
ns-> set policy id number
ns(policy:number)-> set severity string
Para restablecer el ajuste original de nivel de gravedad de cada objeto de ataque, entre de nuevo en el contexto de
una directiva y ejecute el siguiente comando unset policy:
WebUI
Policies > Edit (para una directiva existente): Ejecute el siguiente procedimiento y haga clic en OK:
> Deep Inspection: Seleccione Default en la lista desplegable “Severity” y
haga clic en OK.
CLI
ns-> set policy id number
ns(policy:number)-> unset policy id number severity

Capítulo 5 Deep Inspection Acciones de ataque
ACCIONES DE ATAQUE
Cuando el módulo Deep Inspection (DI) de NetScreen detecta un ataque, ejecuta la acción que se especifique.
Existen las siete posibilidades siguientes:
8
• Close (interrumpe la conexión y envía RST al cliente y al servidor )
Utilice esta opción para las conexiones TCP. El dispositivo NetScreen interrumpe la conexión y envía TCP
RST al cliente (origen) y al servidor (destino). Debido a que la entrega de notificaciones RST no es fiable,
enviando un RST al cliente y al servidor se aumentan las posibilidades de que al menos uno reciba el RST
y cierre la sesión.
• Close Client (interrumpe la conexión y envía RST al cliente)
Utilice esta opción para conexiones TCP salientes desde un cliente protegido hacia un servidor no fiable.
Si, por ejemplo, el servidor envía una cadena URL maliciosa, el dispositivo NetScreen interrumpe la
conexión y envía un RST sólo al cliente para que borre sus recursos mientras el servidor queda a la espera.
• Close Server (interrumpe la conexión y envía RST al servidor)
Utilice esta opción para conexiones TCP entrantes procedentes de un cliente no fiable y dirigidas a un
servidor protegido. Si, por ejemplo, el cliente intenta realizar un ataque, el dispositivo NetScreen interrumpe
la conexión y envía un TCP RST sólo al servidor para que borre sus recursos mientras el cliente queda a la
espera.
• Drop (interrumpe la conexión sin enviar RST a nadie)
Utilice esta opción para conexiones UDP u otras conexiones no TCP, como DNS. El dispositivo NetScreen
descarta todos los paquetes en una sesión, pero no envía TCP RST.
• Drop Packet (descarta un paquete determinado pero no interrumpe la conexión)
Esta opción descarta el paquete en el que se detecta una firma de ataque o una anomalía de protocolo,
pero no termina la sesión propiamente dicha. Utilice esta opción de descartar paquetes mal formados sin
interrumpir la sesión entera. Por ejemplo, si el dispositivo NetScreen detecta una firma de ataque o
anomalía de protocolo procedente de un proxy de AOL, descartar todo interrumpiría todos los servicios de
AOL. En lugar de ello, al descartar únicamente el paquete, se detiene el paquete problemático sin detener
el flujo del resto de paquetes.
8. El cliente es siempre el iniciador de una sesión; es decir, la dirección de origen de una directiva. El servidor es siempre el respondedor, o la dirección de destino.

• Ignore (tras detectar una firma de ataque o una anomalía, el dispositivo NetScreen efectúa una entrada en
el registro y deja de comprobar el resto de la conexión, o la ignora)
Si el dispositivo NetScreen detecta una firma de ataque o anomalía de protocolo, efectúa una entrada en el
registro de eventos pero no interrumpe la sesión misma. Utilice esta opción para ajustar los falsos positivos
durante la fase inicial de configuración de su implementación de Deep Inspection (DI). Utilice esta opción
también cuando un servicio utilice un número de puerto estándar para actividades de protocolo no
estándar; por ejemplo, Yahoo Messenger utiliza el puerto 25 (puerto SMTP) para el tráfico no SMTP. El
dispositivo NetScreen registra la ocurrencia una vez por sesión (para no llenar el registro con falsos
positivos), pero no lleva a cabo ninguna acción.
• None (ninguna acción)
Resulta útil para la identificación inicial de tipos de ataques durante la fase inicial de configuración de su DI
implementación. Cuando el dispositivo NetScreen detecta una firma de ataque o anomalía de protocolo,
realiza una entrada en el registro de eventos pero no lleva a cabo ninguna acción sobre el tráfico mismo. El
dispositivo NetScreen continúa comprobando el tráfico subsiguiente de esa sesión y realiza entradas en el
registro si detecta otras firmas de ataque y anomalías.
Ejemplo: Acciones de ataque – Close Server, Close, Close Client

En este ejemplo hay tres zonas: Trust, Untrust y DMZ. Suponga que ha terminado de analizar ataques y ha llegado
a la conclusión de que necesita las tres directivas siguientes:
• Policy ID 1: Permitir tráfico HTTP, HTTPS, PING y FTP-GET procedente de cualquier dirección de la zona
Untrust y dirigido a los servidores web (websrv1 y websrv2) de la zona DMZ.
Ajuste de ataque para la directìva con ID 1:
– CRITICAL:HTTP:ANOM, CRITICAL:HTTP:SIGS
– HIGH:HTTP:ANOM, HIGH:HTTP:SIGS
– MEDIUM:HTTP:ANOM, MEDIUM:HTTP:SIGS
– CRITICAL:FTP:SIGS
– Action: Close Server

Decide interrumpir la conexión y enviar una notificación TCP RST solamente a los servidores web
protegidos para que puedan terminar sus sesiones y borrar sus recursos. Usted prevé recibir ataques de la
zona Untrust.
• Policy ID 2: Permitir tráfico HTTP, HTTPS, PING y FTP procedente de cualquier dirección de la zona Trust
y dirigido a los servidores web (websrv1 y websrv2) de la zona DMZ.
– Action: Close
Decide interrumpir la conexión y enviar una notificación TCP RST tanto a los clientes como a los servidores
protegidos para que ambos puedan terminar sus sesiones y borrar sus recursos sin importar el nivel de
gravedad del ataque.
• Policy ID 3: Permitir el tráfico FTP-GET, HTTP, HTTPS, PING desde cualquier dirección de la zona Trust a
cualquier dirección de la zona Untrust.
– Action: Close Client
Usted elige interrumpir la conexión y enviar una notificación TCP RST a los clientes protegidos para que
ambos puedan terminar sus sesiones y borrar sus recursos. En este caso, usted prevé un ataque
procedente de un servidor HTTP o FTP no fiable.

Aunque las directivas permiten HTTP, HTTPS, Ping, FTP-Get o FTP, el dispositivo NetScreen activa Deep
Inspection solamente para el tráfico HTTP y FTP. Todas las zonas se encuentran en el dominio de enrutamiento
Trust-vr.
Zona Untrust
DI (Untrust -> DMZ)
HTTP:Crit, High, Med;
FTP:Crit
ethernet3 Action:Close-server
1.1.1.1/24
Zona DMZ
DI (Trust -> Untrust)

HTTP:Crit, High, Med; ethernet2
FTP:Crit; 1.2.2.1/24 websrv1 websrv2
Action:Close-client 1.2.2.5/24 1.2.2.6/24
ethernet1
10.1.1.1/24 DI (Trust -> DMZ)
HTTP:Crit, High, Med;
FTP:Crit;
Zona Trust Action:Close
WebUI
1. Interfaces
Zone Name: Trust

Interface Mode: NAT

Service Options:
Management Services: (seleccione todos)
Other services: Ping
Zone Name: Untrust
Zone Name: DMZ
2. Direcciones
Address Name: websrv1
Zone: DMZ
Address Name: websrv2
Zone: DMZ

3. Ruta
Source Address:
Dirección de destino:
Address Book Entry: (seleccione), websrv1
> Haga clic en Multiple, seleccione websrv2 y haga clic en OK para
regresar a la página de configuración básica de directivas.
Service: HTTP
> Haga clic en Multiple, seleccione FTP-GET, HTTPS, PING y haga clic en
OK para regresar a la página de configuración básica de directivas.
Action: Permit
> Haga clic en Deep Inspection, introduzca lo siguiente y haga clic en OK
para regresar a la página de configuración básica de directivas:
Action: Close Server
Utilice el botón << para mover los siguientes grupos de
ataques de la columna “Available Members” a la columna
“Selected Members”:

CRITICAL:HTTP:ANOM
CRITICAL:HTTP:SIGS
HIGH:HTTP:ANOM
HIGH:HTTP:SIGS
MEDIUM:HTTP:ANOM
MEDIUM:HTTP:SIGS
CRITICAL:FTP:SIGS
Source Address:
Address Book Entry: (seleccione), websrv1
> Haga clic en Multiple, seleccione websrv2 y haga clic en OK para
regresar a la página de configuración básica de directivas.
Service: HTTP
Action: Permit
Action: Close

CRITICAL:HTTP:ANOM
CRITICAL:HTTP:SIGS
HIGH:HTTP:ANOM
HIGH:HTTP:SIGS
MEDIUM:HTTP:ANOM
MEDIUM:HTTP:SIGS
CRITICAL:FTP:SIGS
Source Address:
Service: HTTP
Action: Permit
Action: Close Client

CRITICAL:HTTP:ANOM
CRITICAL:HTTP:SIGS
HIGH:HTTP:ANOM
HIGH:HTTP:SIGS
MEDIUM:HTTP:ANOM
MEDIUM:HTTP:SIGS
CRITICAL:FTP:SIGS
CLI
1. Interfaces
set interface ethernet1 manage
2. Direcciones
set address dmz websrv1 1.2.2.5/32
set address dmz websrv2 1.2.2.6/32
3. Ruta

set policy id 1 from untrust to dmz any websrv1 http permit attack
CRITICAL:HTTP:ANOM action close-server
set policy id 1
ns(policy:1)-> set service ftp-get
ns(policy:1)-> set service ping
ns(policy:1)-> set attack MEDIUM:HTTP:ANOM
ns(policy:1)-> set attack MEDIUM:HTTP:SIGS
ns(policy:1)-> set attack CRITICAL:FTP:SIGS
ns(policy:1)-> exit
set policy id 2 from trust to dmz any websrv1 http permit attack
CRITICAL:HTTP:ANOM action close
set policy id 2
ns(policy:2)-> set service ftp
ns(policy:2)-> exit

set policy id 3 from trust to untrust any any http permit attack
CRITICAL:HTTP:ANOM action close-client
set policy id 3
ns(policy:3)-> set service ftp-get
ns(policy:3)-> exit
save

Capítulo 5 Deep Inspection Asignación de servicios personalizados a aplicaciones
ASIGNACIÓN DE SERVICIOS PERSONALIZADOS A APLICACIONES

Cuando utilice un servicio personalizado en una directiva con un componente de Deep Inspection (DI), deberá
especificar explícitamente qué aplicación se está ejecutando sobre ese servicio para que el módulo DI pueda
funcionar correctamente. Por ejemplo, si crea un servicio personalizado para FTP para que se ejecute en el número
de puerto no estándar 2121, puede hacer referencia a ese servicio personalizado en una directiva de la siguiente
forma:
set service ftp-custom protocol tcp src-port 0-65535 dst-port 2121-2121
set policy id 1 from untrust to trust any ftp-srv1 custom-ftp permit
Sin embargo, si incluye un componente de DI en una directiva que haga referencia al servicio personalizado, el
módulo de DI no podrá reconocer la aplicación porque estará utilizando un número de puerto no estándar.
set policy id 1 from untrust to trust any ftp-srv1 custom-ftp permit attack
CRITICAL:FTP:SIGS action close-server
El cortafuegos de NetScreen
permite tráfico custom-ftp en el
puerto 2121.
custom-ftp (puerto 2121)
Internet
FTP (puerto 21) ftp-srv1
Sin embargo, el módulo DI comprueba si hay ataques

CRITICAL:FTP en el puerto 21, que no está siendo utilizado.
Para evitar este problema, es necesario informar al módulo DI de que la aplicación FTP se está ejecutando en el
puerto 2121. Esencialmente, consiste en asignar el protocolo de la capa de aplicación (“Aplicación Layer”) a un
número de puerto específico en la capa de transporte (“Transport Layer”). Esta asociación se puede realizar a nivel
de directivas:
set policy id 1 application ftp
Cuando se asigna la aplicación FTP al servicio personalizado “custom-ftp” y se configura DI para que examine el
tráfico FTP en busca de los ataques definidos en el grupo de objetos de ataque CRITICAL:FTP:SIGS en una
directiva que haga referencia a “custom-ftp”, el módulo DI realiza su inspección en el puerto 2121.

set policy id 1 from untrust to trust any ftp-srv1 custom-ftp permit attack
CRITICAL:FTP:SIGS action close-server
set policy id 1 application ftp
El cortafuegos de NetScreen permite

tráfico custom-ftp en el puerto 2121.
Internet custom-ftp (puerto 2121)
El módulo DI comprueba si hay ataques ftp-srv1

CRITICAL:FTP:SIGS en el puerto 2121.
Ejemplo: Asignar una aplicación a un servicio personalizado

En este ejemplo definirá un servicio personalizado llamado “HTTP1” que utilizará el puerto de destino 8080.
Asignará la aplicación HTTP al servicio personalizado para una directiva que permita el tráfico HTTP1 desde
cualquier dirección de la zona Untrust a un servidor web llamado “server1” en la zona DMZ.
WebUI
1. Servicio personalizado
Objects > Services > Custom > New: Introduzca los siguientes datos y, a continuación, haga clic en OK:
Service Name: HTTP1
Transport Protocol: TCP (seleccione)
Source Port Low: 0
Source Port High: 65535
Destination Port Low: 8080
Destination Port High: 8080

2. Dirección
Address Name: server1
IP/Netmask: 1.2.2.5/32
Zone: DMZ
3. Directiva
Source Address:
Address Book Entry: (seleccione), server1
Service: HTTP1
Application: HTTP
Action: Permit
CRITICAL:HTTP:ANOM
CRITICAL:HTTP:SIGS
HIGH:HTTP:ANOM
HIGH:HTTP:SIGS
MEDIUM:HTTP:ANOM
MEDIUM:HTTP:SIGS

CLI
1. Servicio personalizado
set service HTTP1 protocol tcp src-port 0-65535 dst-port 8080-8080
2. Dirección
set address dmz server1 1.2.2.5/32
3. Directiva
ns-> set policy id 1 from untrust to dmz any server1 HTTP1 permit attack
CRITICAL:HTTP:ANOM action close-server
ns(policy:1)-> exit
ns-> set policy id 1 application http
save

Capítulo 5 Deep Inspection Objetos de ataque y grupos personalizados
OBJETOS DE ATAQUE Y GRUPOS PERSONALIZADOS

Es posible definir nuevos objetos de ataque y grupos de objetos para personalizar la aplicación Deep Inspection
(DI) con el fin de resolver lo mejor posible sus necesidades. Los objetos de ataque pueden ser firmas completas o
(en el dispositivo NetScreen-5000) firmas de secuencias TCP.
Objetos de ataque de firma completa definidos por el usuario

Se puede crear un objeto de ataque de firma completa para FTP, HTTP y SMTP. Para crear un objeto de ataque,
realice los pasos siguientes:
• Asigne un nombre el objeto de ataque. (Todos los objetos de ataque definidos por el usuario deben
comenzar con “CS:”).
• Establezca el contexto para la búsqueda de Deep Inspection.
• Defina la firma.
• Asigne un nivel de gravedad al objeto de ataque.
En las siguientes subsecciones se examinan los temas relacionados con contextos y firmas. Para obtener más
información sobre los niveles de gravedad utilizados por NetScreen-Security Manager 2004, consulte “Cambio de
los niveles de gravedad” en la página 161.
Contextos
El contexto define la ubicación dentro del paquete donde el módulo NetScreen DI busca una firma que coincida con
el patrón del objeto de ataque. Puede especificar cualquiera de los contextos siguientes:
• FTP Command: Establece el mismo contexto que uno de los comandos FTP especificados en la norma
RFC 959, “File Transfer Protocol (FTP)”
• FTP User Name: Establece el mismo contexto que el nombre introducido por un usuario al registrarse en un
servidor FTP.
• HTTP URL Parsed: Establece el contexto como cadena de texto “normalizada” descodificada a partir de
una cadena unicode.
• SMTP Header From: Establece el contexto del encabezado SMTP “From:”
• SMTP Header To: Establece el contexto del encabezado SMTP “To:”

• SMTP Mail From: Establece el contexto como línea de comandos SMTP “MAIL FROM”.
• SMTP Recipient: Establece el contexto como línea de comandos SMTP “RCPT TO”.
A continuación deberá colocar un objeto de ataque definido por el usuario en un grupo de objetos de ataque
definido por el usuario para su utilización en directivas.
Nota: Un grupo de objetos de ataque definido por el usuario sólo puede contener objetos de ataque definidos por el
usuario. En el mismo grupo de objetos de ataque no se pueden mezclar objetos de ataque predefinidos y definidos
por el usuario.
Firmas
Para introducir el texto de una firma, puede escribir una cadena alfanumérica de caracteres normales para buscar
coincidencias exactas carácter por carácter, o puede utilizar expresiones regulares para ampliar las posibles
coincidencias de la búsqueda a conjuntos de caracteres. ScreenOS reconoce las siguientes expresiones regulares:
Finalidad Metacaracteres Ejemplo Significado
Coincidencia binaria \Ooctal_number \0162 Coincidir exactamente con este número

*
directa (octal) octal: “162”.
Coincide con:
162
Coincidencia binaria \Xhexadecimal_number\X \X01 A5 00 00\X Coincidir exactamente con estos cinco
†
directa (hexadecimal) números hexadecimales:
Coincide con: “01 A5 00 00”.
01 A5 00 00
Coincidencias sin distinguir \[characters\] \[cat\] Buscar los caracteres contenidos en “cat”
mayúsculas de minúsculas sin importar si están en letras mayúsculas o
Coincide con: minúsculas.
Cat, cAt, caT
CAt, CaT, CAT
cat, cAt

Coincidencia con cualquier . c.t Busca “c-cualquier carácter-t”.

carácter
Coincide con:
cat, cbt, cct, … czt
cAt, cBt, cCt, … cZt
c1t, c2t, c3t, … c9t
Buscar el carácter anterior * a*b+c Buscar 0, 1 o más ocurrencias de “a”,

0 o más veces, en lugar de seguidas por 1 o más ocurrencias de “b” y
sólo una vez seguida. Coincide con: seguidas por una ocurrencia de “c”.
bc
bbc
abc
aaabbbbc
Buscar 1 o más + a+b+c Buscar 1 o más ocurrencias de “a”,

ocurrencias del carácter seguidas por 1 o más ocurrencias de “b” y
anterior. Coincide con: por una ocurrencia de “c”.
abc
aabc
aaabbbbc
Busca el carácter anterior ? drop-?packet Buscar “drop-packet” o “droppacket”.

0 veces o 1 vez.
Coincide con:
drop-packet
droppacket
Expresiones de grupos ()
El carácter anterior o el | (drop | packet) Buscar “drop” o “packet”.

siguiente. Se utiliza
típicamente con ( ) Coincide con:
drop
packet

Rango de caracteres [start-end] [c-f]a(d | t) Buscar todo lo que comience con “c”, “d”,
“e” o “f”, tenga la letra central “a” y la última
Coincide con: letra “d” o “t”.
cad, cat
dad, dat
ead, eat
fad, fat
Negación del carácter [^character] [^0-9A-Z] Buscar letras minúsculas.

siguiente.
Coincide con:
a, b, c, d, e, … z
*
Octal es el sistema numérico en base 8 que utiliza solamente los dígitos 0-7.
†
Hexadecimal es un sistema numérico en base 16 que utiliza los dígitos 0–9 habituales más las letras A–F, que representan dígitos hexadecimales
equivalentes a los valores decimales 10–15.

Ejemplo: Objetos de ataque de firma completa definidos por el usuario

En este ejemplo tendrá un servidor FTP, un servidor web y un servidor de correo en la zona DMZ. Definirá los
siguientes objetos de ataque para los usos siguientes:
Nombre del objeto de Puede utilizarlo para

ataque
cs:ftp-stor impedir que alguien pueda colocar archivos en su servidor FTP.
cs:ftp-user-dm denegar el acceso FTP al usuario con el nombre de inicio de sesión “dmartin”.
cs:url-index bloquear los paquetes HTTP con una URL definida en cualquier petición HTTP.
cs:spammer bloquear el correo electrónico procedente de cualquier cuenta del dominio “spam.com”.
A continuación los organizará en un grupo de objetos de ataque definido por el usuario llamado “DMZ DI”, al que
hará referencia en una directiva que permita el tráfico de la zona Untrust a los servidores en la zona DMZ.
WebUI
1. Objeto de ataque 1: ftp-stor
Objects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK:
Attack Name: cs:ftp-stor
Attack Context: FTP Command
Attack Severity: Medium
Attack Pattern: stor
2. Objeto de ataque 2: ftp-user-dm

Attack Name: cs:ftp-user-dm
Attack Context: FTP User Name
Attack Severity: Low
Attack Pattern: dmartin

3. Objeto de ataque 3: url-index

Attack Name: cs:url-index
Attack Context: HTTP URL Parsed
Attack Severity: High
Attack Pattern: .*index.html.*

Attack Name: cs:spammer
Attack Context: SMTP From
Attack Severity: Info
Attack Pattern: .@spam.com
5. Grupo de objetos de ataque

Objects > Attacks > Custom Groups > New: Introduzca el siguiente nombre de grupo, mueva los siguientes
objetos de ataque personalizados y haga clic en OK:
Group Name: CS:DMZ DI
Seleccione cs:ftp-stor y utilice el botón << para mover la dirección de la
columna “Available Members” a la columna “Selected Members”.
Seleccione cs:ftp-user-dm y utilice el botón << para mover la dirección de
la columna “Available Members” a la columna “Selected Members”.
Seleccione cs:url-index y utilice el botón << para mover la dirección de la
Seleccione cs:spammer y utilice el botón << para mover la dirección de la

6. Directiva
Source Address:
Service: HTTP
> Haga clic en Multiple, seleccione FTP y haga clic en OK para regresar a
la página de configuración básica de directivas.
Action: Permit
“Selected Members”,
CS:DMZ DI

CLI
1. Objeto de ataque 1: ftp-stor
set attack cs:ftp-stor ftp-command stor severity medium
2. Objeto de ataque 2: ftp-user-dm
set attack cs:ftp-user-dm ftp-username dmartin severity low
set attack cs:url-index http-url-parsed index.html severity high
set attack cs:spammer smtp-from .@spam.com severity info
5. Grupo de objetos de ataque
set attack group “CS:DMZ DI”
set attack group “CS:DMZ DI” add cs:ftp-stor
set attack group “CS:DMZ DI” add cs:ftp-user-dm
set attack group “CS:DMZ DI” add cs:url-index
set attack group “CS:DMZ DI” add cs:spammer
6. Directiva
set policy id 1 from untrust to dmz any any http permit attack “CS:DMZ DI”
action close-server
set policy id 1
ns(policy:1)-> set service ftp
ns(policy:1)-> exit
save

Objetos de ataque de la firma de la secuencia TCP

Las firmas completas dependen de los contextos de aplicaciones específicas, como un nombre de usuario de FTP
o un campo de encabezado de SMTP. Las firmas de la secuencia TCP buscan patrones en cualquier lugar y en
cualquier tipo de tráfico TCP sin importar el protocolo de aplicación utilizado.
Nota: Las firmas de secuencias TCP sólo se pueden definir en sistemas de la serie NetScreen-5000.
Dado que no hay objetos de ataque de firma de la secuencia TCP predefinidos, es necesario definirlos. Al crear un
objeto de ataque de firma, defina los siguientes componentes:
• Nombre del objeto de ataque (Todos los objetos de ataque definidos por el usuario deben comenzar con
“CS:”).
• Tipo de objeto (“stream”)
• Definición de patrón
• Nivel de gravedad
Ejemplo de un objeto de ataque de firma de secuencia TCP
Nombre Tipo Definición Nivel de

gravedad
Ejemplo: Objeto de ataque de firma de secuencia definido por el usuario

En este ejemplo definirá el objeto de firma de secuencia “.*satori.*”. Definirá su nombre como “CS:A1” y su nivel de
gravedad como crítico. Debido a que una directiva puede hacer referencia solamente a grupos de objetos de
ataque, creará un grupo llamado “CS:Gr1” y luego le agregará este objeto. Finalmente, definirá una directiva que
haga referencia a CS:Gr1 y que ordene al dispositivo NetScreen interrumpir la conexión y enviar TCP RST al cliente
si el patrón aparece en algún tráfico al que sea aplicable la directiva.

WebUI
1. Objeto de ataque de firma de secuencia
Attack Name: CS:A1
Attack Context: Stream
Attack Severity: Critical
Attack Pattern: .*satori.*
2. Grupo de objetos de ataque de firma de secuencia
Objects > Attacks > Custom Groups > New: Introduzca los siguientes datos y haga clic en OK:
Group Name: CS:Gr1
Seleccione CS:A1 en la columna “Available Members” y haga clic en <<
para moverlo a la columna “Selected Members”.
3. Directiva
Source Address:
Service: ANY
Action: Permit
Action: Close Client
Seleccione CS:Gr1 en la columna “Available Members” y haga
clic en << para moverlo a la columna “Selected Members”.

CLI
1. Objeto de ataque de firma de secuencia
set attack “CS:A1” stream “.*satori.*” severity critical
2. Grupo de ataques de firma de secuencia
set attack group “CS:Gr1”
set attack group “CS:Gr1” add “CS:A1”
3. Directiva
set policy from trust to untrust any any any permit attack CS:Gr1 action
close-client
save

Capítulo 5 Deep Inspection Bloqueo granular de los componentes de HTTP
BLOQUEO GRANULAR DE LOS COMPONENTES DE HTTP

Un dispositivo NetScreen puede bloquear selectivamente controles de ActiveX, applets de Java, archivos .zip y
archivos .exe enviados a través de HTTP. El peligro que estos componentes plantean a la seguridad de una red es
que proporcionan a los interlocutores no fiables un medio para cargar y luego controlar una aplicación en los hosts
de una red protegida.
Cuando se habilita el bloqueo de uno o más de estos componentes en una zona de seguridad, el dispositivo
NetScreen examina cada encabezado HTTP que llegue a una interfaz asociada a esa zona. Comprueba si el tipo
de contenido detallado en el encabezado indica que cualquiera de los componentes de destino se encuentra en la
carga del paquete. Si el tipo de contenido es Java, .exe, o .zip y el dispositivo NetScreen está configurado para
bloquear esos tipos de componentes HTTP, el dispositivo NetScreen bloquea el paquete. Si el tipo de contenido
sólo detalla “octet stream” en lugar de un tipo específico de componente, el dispositivo NetScreen examina el tipo
de archivo en la carga. Si el tipo de archivo es Java, .exe, o .zip y el dispositivo NetScreen está configurado para
bloquear esos tipos de componentes, el dispositivo NetScreen bloquea el paquete.
Cuando se habilita el bloqueo de los controles de ActiveX, el dispositivo NetScreen bloquea todos los paquetes
HTTP que contienen cualquier tipo de componente HTTP en sus controles (controles ActiveX, applets de Java,
archivos .exe o archivos .zip).
Nota: Cuando el bloqueo de ActiveX está habilitado, el dispositivo NetScreen bloquea los applets de Java,
archivos .exe y archivos .zip tanto si están contenidos en un control de ActiveX como si no.
Controles ActiveX
La tecnología ActiveX de Microsoft proporciona una herramienta para los diseñadores web para crear páginas web
dinámicas e interactivas. Los controles ActiveX son componentes que permiten a diversos programas interactuar
entre sí. Por ejemplo, ActiveX permite a su explorador web abrir una hoja de cálculo o mostrar su cuenta personal
desde una base de datos backend. Los componentes de ActiveX también pueden contener otros componentes
tales como applets de Java, o archivos como .exe y .zip.

Cuando se visita un sitio web con ActiveX habilitado, el sitio pide descargar los controles de ActiveX al equipo.
Microsoft proporciona un mensaje emergente que muestra el nombre de la empresa o del programador que
autenticó el código ActiveX que se ofrece para su descarga. Si confia en la procedencia del código, puede iniciar la
descarga de los controles. Si no confía en el origen, puede rechazarlos.
Si descarga un control ActiveX a su equipo, a continuación podrá hacer con él lo que su creador haya previsto. Si
es código malévolo, podrá volver a formatear su disco duro, eliminar todos sus archivos, enviar todo su correo
electrónico personal a su jefe, etcétera.
Applets de Java
Con una finalidad parecida a la de ActiveX, los applets de Java también aumentan la funcionalidad de las páginas
web al permitirles interactuar con otros programas. Los applets de Java se descargan a una máquina virtual de
Java (VM) en su equipo. En la versión inicial de Java, la máquina virtual no permitía que los applets interactuaran
con otros recursos de su equipo. Desde Java 1.1, algunas de estas restricciones fueron relajadas para proporcionar
mayor funcionalidad. Consecuentemente, los applets de Java ahora pueden acceder a recursos locales fuera de la
VM. Debido a que un atacante puede programar los applets de Java para funcionar fuera de la VM, plantean la
misma amenaza a la seguridad que los controles de ActiveX.
Archivos EXE
En los archivos ejecutables (archivos con la extensión .exe) descargados de Internet, no existe garantía de que
puedan ejecutarse sin riesgo. Aunque el sitio de descarga sea de confianza, un usuario malintencionado podría
estar rastreando las peticiones de descarga de ese sitio, interceptar su petición y responder con un archivo .exe
manipulado con código dañino.
Archivos ZIP
Un archivo ZIP (es decir, un archivo con la extensión “.zip”) es un tipo de archivo que contiene unos o más archivos
comprimidos. El peligro de descargar un archivo “.exe” como el presentado en la sección anterior que trata sobre
archivos “.exe” también puede aplicarse a los archivos “.zip”, ya que éstos pueden contener archivos “.exe”.

Ejemplo: Bloquear applets de Java y archivos “.exe”

En este ejemplo bloqueará todo el tráfico HTTP que contenga applets de Java y archivos .exe en los paquetes que
lleguen a una interfaz de la zona Untrust.
WebUI
Screening > Screen (Zone: Untrust): Seleccione Block Java Component y Block EXE Component y
haga clic en Apply.
CLI
set zone untrust screen java
set zone untrust screen exe
save


Capítulo 6
Atributos de los paquetes sospechosos

6
Según lo mostrado en los demás capítulos de este volumen, un atacante puede manipular los paquetes para que
realicen tareas de reconocimiento o ataques de denegación de servicio (“Denial of Service” o “DoS”). A veces
resulta difícil determinar la intención de un paquete manipulado, pero el mismo hecho de que esté manipulado
induce a sospechar que se está incluyendo con algún fin insidioso. Todas las opciones SCREEN presentadas en
este capítulo bloquean los paquetes sospechosos que pueden contener amenazas ocultas:
• “Fragmentos ICMP” en la página 194
• “Paquetes ICMP grandes” en la página 196
• “Opciones IP incorrectas” en la página 198
• “Protocolos desconocidos” en la página 200
• “Fragmentos de paquetes IP” en la página 202
• “Fragmentos SYN” en la página 204

Capítulo 6 Atributos de los paquetes sospechosos Fragmentos ICMP
FRAGMENTOS ICMP
El protocolo de mensajes de control de Internet (“Internet Control Message Protocol” o “ICMP”) ofrece posibilidades
de comunicación de errores y de comprobación de redes. Dado que los paquetes ICMP contienen mensajes muy
cortos, no existe ningún motivo legítimo para que los paquetes ICMP resulten fragmentados. Cuando un paquete
ICMP es tan grande que necesita fragmentarse, hay algún problema. Si habilita la opción SCREEN “ICMP
Fragment Protection”, el dispositivo NetScreen bloquea cualquier paquete ICMP que tenga el flag de más
fragmentos (“More Fragments”) activado o que contenga algún valor en el campo de desplazamiento (“offset”).
Si el tipo de protocolo y el flag de más o hay un valor distinto de

es 1 para ICMP… fragmentos está activado cero en el campo de
desplazamiento del
Tamaño del Tamaño total del paquete

Encabezado IP Versión encabezado Tipo de servicio
(en bytes)
Identificación 0 D M Desplazamiento del
fragmento
Tiempo de vida (“Time to Protocolo (ICMP = 1) Suma de comprobación del encabezado
Live” o “TTL”)
Opciones
Encabezado Tipo Código Suma de comprobación

ICMP (carga
del paquete IP) Identificador Número correlativo
Datos
… el dispositivo NetScreen
bloquea el paquete.

Capítulo 6 Atributos de los paquetes sospechosos Fragmentos ICMP
Para bloquear los paquetes ICMP fragmentados, utilice uno de los siguientes métodos, donde la zona de seguridad
especificada es la zona en la que se originaron los fragmentos:
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione ICMP Fragment Protection y
haga clic en Apply.
CLI
set zone zone screen icmp-fragment

Capítulo 6 Atributos de los paquetes sospechosos Paquetes ICMP grandes
PAQUETES ICMP GRANDES

Según lo indicado en la sección anterior “Fragmentos ICMP” en la página 194, el protocolo de mensajes de control
de Internet (“Internet Control Message Protocol” o “ICMP”) ofrece posibilidades de comunicación de errores y
comprobación de redes. Dado que los paquetes ICMP contienen mensajes muy cortos, no existe ningún motivo
legítimo para que se generen paquetes ICMP de gran tamaño. Si un paquete ICMP es inusualmente grande, hay
algún problema. Por ejemplo, el programa Loki utiliza ICMP como canal para transmitir mensajes secretos. La
presencia de paquetes ICMP grandes podría dejar al descubierto a un equipo que esté actuando como agente de
Loki. También podría indicar algún otro tipo de actividad ilegítima.
Cuando el tipo de protocolo y este valor es > 1024, …

es 1 para ICMP …
Tamaño del Tamaño total del

Encabezado IP Versión encabezado Tipo de servicio paquete (en bytes)
Tiempo de vida (“Time to Protocolo (ICMP = 1) Suma de comprobación del encabezado
Live” o “TTL”)
Opciones
Encabezado Tipo Código Suma de comprobación

ICMP (carga
del paquete IP)
Identificador Número correlativo
Datos
bloquea el paquete.
Cuando se habilita la opción SCREEN “Large Size ICMP Packet Protection”, el dispositivo NetScreen descarta los
paquetes ICMP con un tamaño superior a 1024 bytes.

Capítulo 6 Atributos de los paquetes sospechosos Paquetes ICMP grandes
Para bloquear los paquetes ICMP de gran tamaño, utilice uno de los siguientes métodos, donde la zona de
seguridad especificada es la zona en la que se originaron los paquetes:
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione Large Size ICMP Packet (Size >
1024) Protection y haga clic en Apply.
CLI
set zone zone screen icmp-large

Capítulo 6 Atributos de los paquetes sospechosos Opciones IP incorrectas
OPCIONES IP INCORRECTAS
El estándar del protocolo de Internet “RFC 791, Internet Protocol” especifica un conjunto de ocho opciones que
ofrecen controles de enrutamiento especiales, herramientas de diagnóstico y medidas de seguridad. Aunque la
finalidad original prevista para estas opciones era legítima, algunas personas han hallado la forma de explotarlas
para lograr objetivos menos loables. (Para ver un resumen de las vulnerabilidades de las opciones IP que los
atacantes pueden explotar, consulte “Reconocimiento de red mediante opciones IP” en la página 14.)
Ya sea intencional o accidentalmente, en ocasiones los atacantes desconfiguran las opciones IP, generando
campos incompletos o mal formados. Con independencia de las intenciones de la persona que manipuló el
paquete, un formato incorrecto es de por sí algo anómalo y potencialmente dañino para el destinatario.
Encabezado IP
Tamaño del

Tiempo de vida (“Time
to Live” o “TTL”) Protocolo Suma de comprobación del encabezado
Opciones
Carga (datos)
Si las opciones IP están mal formateadas, el dispositivo

NetScreen registra el evento en los contadores SCREEN
de la interfaz de entrada.
Cuando se habilita la opción SCREEN “Bad IP Option Protection”, el dispositivo NetScreen bloquea los paquetes
cuyo encabezado IP contenga cualquier opción IP mal formateada. El dispositivo NetScreen registra el evento en el
registro de eventos.

Capítulo 6 Atributos de los paquetes sospechosos Opciones IP incorrectas
Para detectar y bloquear paquetes con opciones IP incorrectamente formateadas, utilice uno de los siguientes
métodos, donde la zona de seguridad especificada es la zona en la que se originó el paquete:
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione Bad IP Option Protection y haga
clic en Apply.
CLI
set zone zone screen ip-bad-option

Capítulo 6 Atributos de los paquetes sospechosos Protocolos desconocidos
PROTOCOLOS DESCONOCIDOS
Por el momento, los tipos de protocolos con los números de identificación 135 o superior están reservados y no
definidos. Debido precisamente a que estos protocolos no están definidos, no se puede saber por adelantado si un
determinado protocolo desconocido es legítimo o malévolo. Salvo que su red utilice un protocolo no estándar con
un número de identificación 135 o superior, una buena medida de precaución es impedir que esos elementos
desconocidos puedan entrar en su red protegida.
Si el número de identificación del protocolo

es 135 o superior, el dispositivo NetScreen
Encabezado IP bloquea el paquete.
Tamaño del

Opciones
Carga (datos)
Cuando se habilita la opción SCREEN “Unknown Protocol Protection”, el dispositivo NetScreen descarta los
paquetes cuyo campo de protocolo contenga un número de identificación de protocolo 135 o superior.

Capítulo 6 Atributos de los paquetes sospechosos Protocolos desconocidos
Para descartar los paquetes que utilicen un protocolo desconocido, utilice uno de los siguientes métodos, donde la
zona de seguridad especificada es la zona en la que se originan los paquetes:
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione Unknown Protocol Protection y
haga clic en Apply.
CLI
set zone zone screen unknown-protocol

Capítulo 6 Atributos de los paquetes sospechosos Fragmentos de paquetes IP
FRAGMENTOS DE PAQUETES IP
A medida que los paquetes pasan por diferentes redes, en ocasiones resulta necesario dividirlos en trozos más
pequeños (fragmentos) para adaptar su tamaño a la unidad de transmisión máxima (“Maximum Transmission Unit”
o “MTU”) de cada red. Aprovechando los fragmentos IP, un atacante puede intentar explotar las vulnerabilidades
existentes en el código de reensamblaje de paquetes de determinadas implementaciones de pilas IP (“IP stacks”).
Cuando la víctima recibe estos paquetes, los resultados pueden variar desde un procesamiento incorrecto de los
paquetes hasta la caída total del sistema.
Si el flag de más fragmentos o hay un valor distinto de

está activado … cero en el campo de
Encabezado IP desplazamiento del
Tamaño del
Identificación 0 D M Desplazamiento
del fragmento
Opciones
Carga (datos)
bloquea el paquete.
Cuando se habilita el dispositivo NetScreen para rechazar fragmentos IP en una zona de seguridad, el dispositivo
bloquea todos los fragmentos de paquetes IP que reciba en las interfaces asociadas a esa zona.

Capítulo 6 Atributos de los paquetes sospechosos Fragmentos de paquetes IP
Para descartar los paquetes IP fragmentados, utilice uno de los siguientes métodos, donde la zona de seguridad
especificada es la zona de origen de los fragmentos:
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione Block Fragment Traffic y haga
clic en Apply.
CLI
set zone zone screen block-frag

Capítulo 6 Atributos de los paquetes sospechosos Fragmentos SYN
FRAGMENTOS SYN
El protocolo de Internet (IP) encapsula los segmentos SYN del protocolo de control de transmisiones
(“Transmission Control Protocol” o “TCP”) en el paquete IP que inicia una conexión de TCP. Dado que la finalidad
de este paquete es iniciar una conexión e invocar un segmento SYN/ACK como respuesta, el segmento SYN
generalmente no contiene datos. Como el paquete IP es pequeño, no existe ningún motivo legítimo para su
fragmentación. Un paquete SYN fragmentado es algo anómalo y, por lo tanto, sospechoso. Como medida
preventiva, impida que tales elementos desconocidos puedan entrar en su red protegida.
Cuando se habilita la opción SCREEN “SYN Fragment Detection”, el dispositivo NetScreen detecta los paquetes
cuyo encabezado IP indique que el paquete se ha fragmentado y que el flag SYN está activado en el encabezado
TCP. El dispositivo NetScreen registra el evento en la lista de contadores SCREEN de la interfaz de entrada.
Para descartar los paquetes IP que contengan fragmentos SYN, utilice uno de los siguientes métodos, donde la
zona de seguridad especificada es la zona en la que se originan los paquetes:
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione SYN Fragment Protection y haga
clic en Apply.
CLI
set zone zone screen syn-frag

Si el flag de más fragmentos o hay un valor distinto de

está activado … cero en el campo de
desplazamiento del
Tamaño del
Encabezado IP Versión encabezado Tipo de servicio Tamaño total del paquete (en bytes)
Identificación 0 D M Desplazamiento
del fragmento
Tiempo de vida (“Time Protocolo Suma de comprobación del encabezado
to Live” o “TTL”)

Encabezado
TCP
Número de reconocimiento de 32 bits
(6 bits)
4 bits G K H T N N
Suma de comprobación de TCP de 16 bits Puntero urgente de 16 bits
Datos (si los hay)
… y el flag SYN está activado … … el dispositivo NetScreen

descarta el paquete.


Índice
Índice
A ataques
ataque terrestre 77
controles ActiveX, bloqueo 189
convenciones
acciones de ataque 163–173 direcciones MAC desconocidas 64 CLI vii
close 163 etapas 2 ilustración x
close client 163 fragmentos de paquetes IP 202 nombres xi
close server 163 fragmentos ICMP 194 WebUI viii
drop 163 fragmentos SYN 204–205 CSP 107
drop packet 163 inundación de la tabla de sesiones 27
ignore 164 inundación ICMP 73
none 164 inundación SYN 56–64 D
ALG 87 inundación UDP 75 DDoS 45
análisis antivirus 91–130 objetivos comunes 1 Deep Inspection 161–185
analizador AV externo 107–130 opciones de detección y defensa 3–6 acciones de ataque 163–173
analizador AV interno 92–106 paquetes ICMP grandes 196 anomalías del protocolo 160
aplicación 120 Ping of Death 79 base de datos de objetos de ataque 147–155
conexiones TCP máximas 111 protocolos desconocidos 200 cambiar gravedad 161
correo web HTTP 96 Teardrop 81 contexto 178
descompresión 102 WinNuke 83 expresiones regulares 179–181
externo, HTTP 109 AV, análisis firmas completas 158
externo, recursos CSP 112 véase análisis antivirus firmas personalizadas 179–185
externo, SMTP 108 grupos de objetos de ataque 160
goteo HTTP 115 B objetos de ataque 143
objetos de ataque personalizados 178
HTTP “keep-alive” 114
interno, HTTP 95 base de datos de objetos de ataque 147–155 servicios personalizados 174–177
actualización automática 147, 150 denegación de servicio
interno, POP3 94
actualización inmediata 147, 148 véase DoS
interno, SMTP 93
actualización manual 148, 154 descompresión, análisis antivirus 102
interno, suscripción 97 cambiar la URL predeterminada 154 directivas
InterScan VirusWall 107 notificación automática y actualización contexto 146
modo de fallo 112 manual 148, 152 filtrado de URL 136
múltiples objetos AV 124 sección central 26, 145
objetos AV 110–119 DoS 45–84
umbral de modo de fallo 113 C ataque específico del sistema operativo 79–84
análisis de puertos 12 CLI cortafuegos 46–55
análisis FIN 24 convenciones vii inundación de la tabla de sesiones 27, 46
anomalías del protocolo 160 comprobación de SYN 24, 25–27 red 56–78
applets Java, bloquear 190 agujero de reconocimiento 26 drop-no-rpf-route 28
archivos exe, bloquear 190 enrutamiento asimétrico 26
archivos zip, bloquear 190
ataque “Teardrop” 81
interrupción de sesión 26
inundación de la tabla de sesiones 27 E
ataque terrestre 77 conjuntos de caracteres compatibles con envejecimiento agresivo 50–53
ataque WinNuke 83 ScreenOS xi establecimiento de conexión en tres fases 56
NetScreen: conceptos y ejemplos – volumen 4: Mecanismos de detección de ataques y defensa IX-I

Índice
evasión 24–42
exploits
ilustración N
convenciones x
véase ataques nombres
inspección de estado 3 convenciones xi
expresiones regulares 179–181
InterScan VirusWall 107
F
inundación de la tabla de sesiones 27, 46
inundación del proxy SYN-ACK-ACK 54
O
filtrado de contenidos 85–139 objetos antivirus
inundación ICMP 73
filtrado de paquetes dinámico 3 véase objetos AV
inundación SYN 56–64 objetos AV 110–119
filtrado de URL 131–139
activación en el nivel de dispositivo 136 ataque 56 estados 110
aplicación en el nivel de directivas 136 descartar las direcciones MAC número de puerto 111
enrutamiento 137 desconocidas 64 tiempo de espera 111
estado del servidor 136 tamaño de la cola 64 objetos de ataque 143
mensaje de URL bloqueada de NetScreen 135 anomalías del protocolo 160
tiempo de espera 64
modo de fallo/paso 135 firmas completas 158
nombre del servidor Websense 134 umbral 57 firmas de secuencias TCP 186
puerto del servidor Websense 134 umbral de alarma 62 opción de seguridad IP 15, 17
servidores por vsys 133 umbral de ataque 62 opción IP de grabación de ruta 15, 17
tiempo de espera de comunicaciones 134 umbral de destino 63 opción IP de ID de secuencia 15, 17
tipo de mensaje de URL bloqueada 135 opción IP de marca de hora 16, 17
umbral de origen 63 opción IP de ruta de origen abierta 15, 39–42
FIN sin flag ACK 20
firmas completas 158 inundación UDP 75 opción IP de ruta de origen estricta 16, 39–42
definición 158 IP opciones IP 14–17
flags SYN y FIN activados 18 fragmentos de paquetes 202 atributos 14–16
Fragmentos SYN 204–205 formateadas incorrectamente 198
grabación de ruta 15, 17
G L ID de secuencia 15, 17
marca de hora 16, 17
grupos de objetos de ataque 160 límites de sesiones 46–50 ruta de origen 39
cambiar gravedad 161 de destino 50 ruta de origen abierta 15, 39–42
niveles de gravedad 160 de origen 49 ruta de origen estricta 16, 39–42
según sus destinos 47 seguridad 15, 17
H según sus orígenes 46
HTTP limpieza de direcciones 10 P
bloqueo de componentes 189–191 Ping of Death 79
goteo 115
método “keep-alive” 114 M protección contra URL maliciosas 86–90
protección frente a ataques
tiempo de espera de la sesión 52 modo de fallo 112 nivel de directivas 6
umbral 113 nivel de zona de seguridad 6
I modo de fallo/paso, filtrado de URL 135
protocolo de análisis de contenidos
véase CSP
ICMP modo transparente protocolos desconocidos 200
fragmentos 194 descartar las direcciones MAC puerta de enlace en la capa de aplicación
paquetes grandes 196 desconocidas 64 véase ALG
NetScreen: conceptos y ejemplos – volumen 4: Mecanismos de detección de ataques y defensa IX-II

Índice
R inundación SYN 56–64 T

rastreo inundación UDP 75 TCP
puertos abiertos 12 limpieza de direcciones 10 firmas de secuencias 186
red 10 número máximo de conexiones
sistemas operativos 18–22 opción IP de ruta de origen abierta, detectar 42
simultáneas 111
reconocimiento 9–42 opción IP de ruta de origen estricta, paquete sin flags 22
análisis de puertos 12 detectar 42 tiempo de espera de la sesión 51
análisis FIN 24 tiempo de espera de la sesión
opción IP de ruta de origen, denegar 42
flags SYN y FIN activados 18 HTTP 52
limpieza de direcciones 10 opciones IP 14 TCP 51
opciones IP 14 opciones IP incorrectas, descartar 198 UDP 52
paquete TCP sin flags 22
reensamblaje de fragmentos 86–90 paquete TCP sin flags, detectar 22
paquetes ICMP grandes, bloquear 196 U
S Ping of Death 79 UDP
tiempo de espera de la sesión 52
SCREEN protocolos desconocidos, descartar 200
umbral inferior 51
análisis de puertos 12
suplantación de IP 28–38 umbral superior 51
ataque terrestre 77
ataque WinNuke 83 Teardrop 81 URL filtering
descartar las direcciones MAC communication timeout 134
zonas VLAN y MGT 3 Websense server port 134
desconocidas 64
FIN sin ACK 24 servicios
FIN sin flag ACK, descarte 20
flags SYN y FIN activados 18
personalizados 174 W
fragmentos de paquetes IP, bloquear 202 suplantación de IP 28–38 Websense 131
fragmentos ICMP, bloquear 194 capa 2 30, 37
fragmentos SYN, detectar 204–205
inundación del proxy SYN-ACK-ACK 54 capa 3 28, 32 Z
inundación ICMP 73 drop-no-rpf-route 28 zombie, agente 45, 47
NetScreen: conceptos y ejemplos – volumen 4: Mecanismos de detección de ataques y defensa IX-III

Índice
NetScreen: conceptos y ejemplos – volumen 4: Mecanismos de detección de ataques y defensa IX-IV

CE v4 SP

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CE v4 SP

Uploaded by

Copyright:

Available Formats

NetScreen: conceptos y ejemplos

Manual de referencia de ScreenOS

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa i

Ataque “Teardrop”......................................................81 Capítulo 5 Deep Inspection .....................................141

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa ii

Bloqueo granular de los componentes de HTTP.....189 Fragmentos ICMP ...................................................194

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa iii

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa iv

El material incluido en este volumen está organizado del siguiente modo:

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa v

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa vi

Convenciones de la interfaz de línea de comandos (CLI)

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa vii

Convenciones de la interfaz gráfica (WebUI)

1. Haga clic en Objects en la columna de menú. 3. Haga clic en List.

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa viii

Address Name: addr_1 Nota: En este ejemplo, no

Haga clic en OK.

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa ix

Convenciones para las ilustraciones

Red de área local (LAN) con

Dispositivo de red genérico

Icono de conmutador (switch)

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa x

Convenciones de nomenclatura y conjuntos de caracteres

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa xi

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa xii

Protección de una red

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 1

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 2

MECANISMOS DE DETECCIÓN Y DEFENSA

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 3

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 4

Opciones de protección de red

Ataques DoS contra la red

Reensamblaje de fragmentos Inundación ICMP

Análisis antivirus Inundación UDP

Filtrado de URL Ataque terrestre (“Land Attack”)

Ataques de DoS específicos de cada sistema operativo

Fragmentos ICMP Protocolos desconocidos

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 5

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 6

Ejemplo: Supervisión de ataques desde la zona Untrust

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 7

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 8

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 9

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 10

1. El valor se mide en microsegundos. El ajuste predeterminado es 5000 microsegundos.

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 11

Paquetes IP con segmentos TCP SYN El dispositivo NetScreen realiza

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 12

2. El valor se mide en microsegundos. El ajuste predeterminado es 5000 microsegundos.

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 13

RECONOCIMIENTO DE RED MEDIANTE OPCIONES IP

Identificación 0 D M Desplazamiento del fragmento

Tipo Clase Número Tamaño Uso intencionado Uso pernicioso

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 14

Tipo Clase Número Tamaño Uso intencionado Uso pernicioso

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 15

Tipo Clase Número Tamaño Uso intencionado Uso pernicioso

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 16

NetScreen: conceptos y ejemplos – Volumen 4: Mecanismos de detección de ataques y defensa 17