Juniper denegacion de servicio (DoS) (y)

Conceptos y ejemplosManual de referencia de ScreenOS

Volumen 4:Detección ataques y mecanismos de defensa

Versión 6.0.0, Rev. 02

Juniper Networks, Inc.

1194 North Mathilda Avenue

Sunnyvale, CA 94089

USA

408-745-2000

www.juniper.net

Número de pieza: 530-017770-01-SP, Revisión 02

ii

Copyright Notice

Copyright © 2007 Juniper Networks, Inc. All rights reserved.

Juniper Networks and the Juniper Networks logo are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks in this document are the property of Juniper Networks or their respective owners. All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for any obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

FCC Statement

The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to 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 with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency energy. If it is not installed in accordance with Juniper Networks’ installation instructions, it may cause interference with radio and television reception. This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no guarantee that interference will not occur in a particular installation.

If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one or more of the following measures:

Reorient or relocate the receiving antenna.

Increase the separation between the equipment and receiver.

Consult the dealer or an experienced radio/TV technician for help.

Connect the equipment to an outlet on a circuit different from that to which the receiver is connected.

Caution: Changes or modifications to this product could void the user's warranty and authority to operate this device.

Disclaimer

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR JUNIPER NETWORKS REPRESENTATIVE FOR A COPY.

Contenido

Acerca de este volumen ix

Convenciones del documento ..........................................................................xConvenciones de la interfaz de usuario web ..............................................xConvenciones de interfaz de línea de comandos ...................................... xiConvenciones de nomenclatura y conjuntos de caracteres ....................... xiConvenciones para las ilustraciones ........................................................ xii

Asistencia y documentación técnica.............................................................. xiii

Capítulo 1 Protección de una red 1

Etapas de un ataque.........................................................................................2Mecanismos de detección y defensa ................................................................2Supervisión de vulnerabilidades.......................................................................5

Ejemplo: Supervisión de ataques desde la zona Untrust ............................5

Capítulo 2 Bloqueo de reconocimiento 7

Barrido de direcciones IP .................................................................................8Barrida de puertos ...........................................................................................9Reconocimiento de red mediante opciones IP ...............................................10Sondeos del sistema operativo.......................................................................12

indicadores SYN y FIN activados .............................................................13Indicador FIN sin indicador ACK..............................................................14Encabezado TCP sin indicadores activados..............................................15

Técnicas de evasión .......................................................................................15Análisis FIN .............................................................................................16Indicadores no SYN .................................................................................16Simulación de IP......................................................................................20

Ejemplo: Protección contra simulación de IP en la capa 3.................22Ejemplo: Protección contra simulación de IP en la capa 2.................24

Opciones IP de ruta de origen .................................................................26

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

Ataques DoS contra el cortafuegos.................................................................30Inundaciones de la tabla de sesiones .......................................................30

Límites a la cantidad de sesiones según sus orígenes y destinos .......30Ejemplo: Limitación de sesiones según su origen..............................32Ejemplo: Limitación de sesiones según su destino ............................32Expiración dinámica .........................................................................33Ejemplo: Expiración dinámica de sesiones........................................34

Inundaciones de SYN-ACK-ACK a través de un servidor proxy ................35Ataques DoS contra la red..............................................................................37

Inundaciones SYN ...................................................................................37Cookie SYN..............................................................................................47

Contenido iii

iv

Manual de referencia de ScreenOS: Conceptos y ejemplos

Inundaciones ICMP..................................................................................49Inundaciones UDP...................................................................................51Ataque terrestre.......................................................................................52

Ataques de DoS específicos de cada sistema operativo ..................................53Ping of Death...........................................................................................53Ataque Teardrop......................................................................................54WinNuke .................................................................................................55

Capítulo 4 Supervisión y filtrado de contenidos 57

Reensamblaje de fragmentos .........................................................................58Protección contra URL maliciosas............................................................58Puerta de enlace en la capa de aplicación................................................59

Ejemplo: Bloquear URL maliciosas en paquetes fragmentados..........60Análisis antivirus............................................................................................62

Análisis AV externo .................................................................................62Servidores de análisis ICAP de equilibrio de carga ............................64

Análisis AV interno ..................................................................................64Análisis AV del tráfico de IM ....................................................................66

Clientes de IM ...................................................................................66Servidor de IM ..................................................................................67Protocolos de IM ...............................................................................67Aspectos de seguridad de la mensajería instantánea.........................68Asuntos de seguridad de IM ..............................................................68Análisis de mensajes de chat.............................................................69Análisis de la transferencia de archivos.............................................69

Resultados del análisis AV .......................................................................70Análisis AV basado en directivas..............................................................71Análisis de protocolos de aplicación ........................................................72

Aálisis del tráfico de FTP ...................................................................73Análisis del tráfico de HTTP ..............................................................74

Actualización de los archivos de patrones AV para el analizador incorporado ......................................................................................81Suscripción al servicio de firma AV ...................................................81

Ajustes globales del analizador de AV ......................................................84Asignación de recursos de AV ...........................................................84Comportamiento en modo de fallo: ..................................................85Tamaño máximo del contenido y número máximo de mensajes

(sólo AV interno).........................................................................85HTTP Keep-Alive ...............................................................................86Goteo HTTP (únicamente AV interno) ...............................................87

Perfiles de AV ..........................................................................................88Asignación de un perfil AV a una directiva de cortafuegos ................89Inicio de un perfil de AV para AV interno ..........................................90Ejemplo: Análisis para todo tipo de tráfico (AV interno) ....................90

Filtrado anti spam..........................................................................................95Listas blancas y listas negras ...................................................................96Configuración básica ...............................................................................97

Filtrado del tráfico spam ...................................................................97Descarte de los mensajes de spam....................................................97

Definición de una lista negra ...................................................................98Definición de una lista blanca..................................................................98Definición de una acción predeterminada ...............................................99Habilitación de un servidor con lista de bloqueo de spam .......................99Prueba del sistema antispam...................................................................99

Contenido

Contenido

Filtrado de Web ...........................................................................................100Uso de la CLI para iniciar los modos de filtrado de Web ........................100Filtrado de Web integrado .....................................................................101

Servidores de SurfControl ...............................................................102Caché de filtrado de Web................................................................103Configuración del filtrado de Web integrado ...................................103Ejemplo: Filtrado de Web integrado................................................109

Redireccionamiento del filtrado de Web................................................110Admisión del sistema virtual ...........................................................112Configuración de la redirección de filtrado de Web.........................113Ejemplo: Redirigir el filtrado de Web ..............................................116

Capítulo 5 Deep Inspection 119

Vista general ................................................................................................120Servidor de la base de datos de objetos de ataque .......................................124

Paquetes de firmas predefinidas............................................................124Actualización de paquetes de firmas......................................................125

Antes de empezar a actualizar los objetos de ataque.......................126Actualización inmediata ..................................................................127Actualización automática ................................................................127Notificación automática y actualización inmediata..........................129Actualización manual ......................................................................130

Objetos de ataque y grupos..........................................................................132Protocolos admitidos .............................................................................133Firmas completas ..................................................................................137Firmas de secuencias TCP .....................................................................138Anomalías en el protocolo .....................................................................138Grupos de objetos de ataque..................................................................139

Cambio de los niveles de gravedad .................................................140Ejemplo: Deep Inspection para P2P ................................................141

Desactivación de objetos de ataque .......................................................142Acciones de ataque ......................................................................................143

Ejemplo: Acciones de ataque – Close Server, Close, Close Client.....145Acciones de ataques de fuerza bruta .....................................................151

Objetos de ataques de fuerza bruta .................................................152Destinos de ataques de fuerza bruta ...............................................152Tiempo de espera de ataques de fuerza bruta .................................153Ejemplo 1........................................................................................153Ejemplo 2........................................................................................154Ejemplo 3........................................................................................154

Registro de ataques......................................................................................154Ejemplo: Desactivación del registro por grupo de ataque ................154

Asignación de servicios personalizados a aplicaciones .................................156Ejemplo: Asignación de una aplicación a un servicio

personalizado ...........................................................................157Ejemplo: Asignación de aplicación a servicio para ataques HTTP....159

Objetos de ataque y grupos personalizados .................................................160Objetos de ataque de firma completa que define el usuario ..................160

Expresiones regulares .....................................................................161Ejemplo: Objetos de ataque de firma completa que define un

usuario .....................................................................................163Objetos de ataque de la firma de la secuencia de TCP ...........................165

Ejemplo: Objeto de ataque de firma de secuencia que define el usuario .....................................................................................166

Contenido v

vi


Parámetros configurables de anomalías en protocolos ..........................167Ejemplo: Modificación de parámetros .............................................167

Negación......................................................................................................168Ejemplo: Negación de objeto de ataque ..........................................168

Bloqueo granular de los componentes de HTTP ...........................................173Controles ActiveX ..................................................................................173Applets de Java ......................................................................................174Archivos EXE.........................................................................................174Archivos ZIP ..........................................................................................174

Capítulo 6 Detección y prevención de intrusiones 175

Dispositivos de seguridad con capacidad para IDP.......................................176Flujo de tráfico en un dispositivo con capacidad de IDP...............................176Configuración de la detección y prevención de intrusiones..........................177

Tareas de configuración previa..............................................................178Ejemplo 1: Configuración básica de IDP ................................................178Ejemplo 2: Configuración de IDP para cambio en caso de fallo activo,

pasivo .............................................................................................181Ejemplo 3: Configuración de IDP para cambio en caso de fallo activo,

activo ..............................................................................................183Configuración de directivas de seguridad.....................................................185

Acerca de las directivas de seguridad ....................................................186Administración de las directivas de seguridad .......................................186Instalación de las directivas de seguridad ..............................................186

Uso de las bases de normas de IDP..............................................................187Administración de las bases de normas de IDP según roles...................188Configuración de objetos para normas de IDP.......................................188Uso de las plantillas de directivas de seguridad .....................................189

Habilitación de IDP en las normas de cortafuegos .......................................189Habilitación de IDP................................................................................190Especificación del modo en línea o tap en línea ....................................190

Configuración de las normas de IDP ............................................................191Adición de la base de normas de IDP ....................................................192Tráfico coincidente ................................................................................193

Zonas de origen y de destino ..........................................................194Objetos de dirección de origen y de destino....................................194Ejemplo: Establecimiento de origen y de destino ............................194Ejemplo: Establecimiento de múltiples orígenes y destinos.............195Servicios .........................................................................................195Ejemplo: Establecimiento de los servicios predeterminados ...........196Ejemplo: Establecimiento de servicios específicos...........................196Ejemplo: Establecimiento de servicios no estándar .........................196Normas definitivas ..........................................................................198Ejemplo: Establecimiento de normas definitivas .............................198

Definición de acciones...........................................................................199Establecimiento de objetos de ataque....................................................200

Adición de objetos de ataque individualmente ................................201Adición de objetos de ataque por categoría.....................................201Ejemplo: Adición de objetos de ataque por servicio ........................201Adición de objetos de ataque por sistema operativo .......................201Adición de objetos de ataque por gravedad.....................................202

Establecimiento de la acción de IP ........................................................202Selección de una acción de IP .........................................................203Selección de una opción de bloqueo ...............................................203

Contenido

Contenido

Establecimiento de las opciones de registro ....................................203Establecimiento de las opciones de tiempo de espera.....................203

Establecimiento de la notificación .........................................................204Establecimiento de los registros ......................................................204Establecimiento de una alerta .........................................................204Paquetes de registro........................................................................204

Establecimiento de la gravedad .............................................................205Establecimiento de objetivos .................................................................205Introducción de comentarios .................................................................205

Configuración de las normas de exclusión ...................................................205Adición de la base de normas de exclusión ...........................................206Definición de una coincidencia..............................................................207

Zonas de origen y de destino ..........................................................207Objetos de dirección de origen y de destino....................................208Ejemplo: Exclusión de un par origen/destino ..................................208

Establecimiento de los objetos de ataque ..............................................208Ejemplo: Exclusión de objetos de ataque específicos ......................208

Establecimiento de objetivos .................................................................209Introducción de comentarios .................................................................209Creación de una norma de exclusión desde el visualizador de

registros ..........................................................................................209Configuración de las normas de puerta de atrás ..........................................210

Adición de la base de normas de puerta de atrás...................................211Definición de una coincidencia..............................................................212

Zonas de origen y de destino ..........................................................212Objetos de dirección de origen y de destino....................................212Servicios .........................................................................................213

Establecimiento del funcionamiento......................................................213Establecimiento de acciones..................................................................213Establecimiento de la notificación .........................................................214

Establecimiento de los registros ......................................................214Establecimiento de una alerta .........................................................214Paquetes de registro........................................................................214

Establecimiento de la gravedad .............................................................215Establecimiento de objetivos .................................................................215Introducción de comentarios .................................................................215

Configuración de los objetos de ataque de IDP ............................................215Acerca de los tipos de objeto de ataque de IDP .....................................216

Objetos de ataque de firma.............................................................216Objetos de ataque de anomalías de protocolo.................................216Objetos de ataque compuestos .......................................................216

Visualización de grupos y objetos de ataque de IDP predefinidos ..........217Visualización de ataques predefinidos.............................................217Visualización de grupos predefinidos ..............................................218

Creación de objetos de ataque IDP personalizados ................................219Creación de un objeto de ataque de firma.......................................220Creación de un Ataque de anomalía de protocolo ...........................226Creación de un ataque compuesto ..................................................227Edición de un objeto de ataque personalizado ................................230Eliminación de un objeto de ataque personalizado .........................230

Creación de objetos de ataque IDP personalizados ................................230Configuración de grupos estáticos...................................................230Configuración de grupos dinámicos ................................................232Ejemplo: Creación de un grupo dinámico........................................233

Contenido vii

viii


Actualización de grupos dinámicos .................................................234Edición de un grupo de ataques personalizado ...............................235Eliminación de un grupo de ataques personalizado.........................235

Configuración del dispositivo como un dispositivo IDP independiente.........235Habilitación de IDP................................................................................235

Ejemplo: Configuración de una norma de cortafuegos para IDP independiente ..........................................................................236

Configuración de la administración basada en funciones ......................237Ejemplo: Configuración de un administrador sólo de IDP ...............237

Administración de IDP .................................................................................238Acerca de las actualizaciones de la base de datos de ataques ................238Descarga de las actualizaciones de la base de datos de ataques ............239

Uso de los objetos de ataque actualizados.......................................239Actualización del motor IDP............................................................239

Visualización de los registros IDP ..........................................................241

Capítulo 7 Atributos de los paquetes sospechosos 243

Fragmentos ICMP ........................................................................................243Paquetes ICMP grandes................................................................................244Opciones IP incorrectas ...............................................................................245Protocolos desconocidos ..............................................................................246Fragmentos de paquetes IP..........................................................................247Fragmentos SYN ..........................................................................................248

Apéndice A Contextos para las firmas definidas por el usuario A-I

Índice ........................................................................................................................IX-I

Contenido

Acerca de este volumen

En el Volumen 4: Detección ataques y mecanismos de defensa se describen las opciones de seguridad de Juniper Networks disponibles en ScreenOS. Puede habilitar varias de estas opciones a nivel de zona de seguridad. Estas opciones se aplican al tráfico que llega al dispositivo de seguridad de Juniper Networks a través de cualquier interfaz enlazada a una zona para la cual se hayan activado dichas opciones. Estas opciones 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 Web, 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.

Este volumen contiene las siguientes secciones:

Capítulo 1, “Protección de una red,” donde se resumen las etapas básicas de un ataque y las opciones de cortafuegos disponibles para combatir al atacante en cada etapa.

Capítulo 2, “Bloqueo de reconocimiento,” donde se describen las opciones disponibles para bloquear el barrido de direcciones IP, los análisis de puertos y los intentos de descubrir el tipo de sistema operativo (OS) del sistema objetivo del ataque.

Capítulo 3, “Defensas contra los ataques de denegación de servicio,” donde se explican los ataques DoS específicos de cada sistema operativo, red o cortafuegos, y cómo ScreenOS amortigua dichos ataques.

Capítulo 4, “Supervisión y filtrado de contenidos,” donde se describe cómo proteger a los usuarios de los localizadores uniformes de recursos (URL) maliciosos y cómo configurar el dispositivo de seguridad Juniper Networks para trabajar con productos de otros fabricantes y así proporcionar análisis antivirus, antispam y filtrado de web.

Capítulo 5, “Deep Inspection,” donde se describe cómo configurar el dispositivo de seguridad de Juniper Networks 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.

NOTA: Las directivas sólo se presentan en este volumen de forma periférica, ya que aquí se describen 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-161.

ix


x C

Capítulo 6, “Detección y prevención de intrusiones,” donde se describe la tecnología de detección y prevención de intrusiones (IDP) de Juniper Networks, que detecta y luego detiene los ataques cuando se despliega en línea con su red. El capítulo describe cómo aplicar IDP a nivel de directivas para descartar paquetes o conexiones maliciosas antes de que los ataques puedan llegar a su red.

Capítulo 7, “Atributos de los paquetes sospechosos,” donde se indican varias opciones SCREEN que protegen los recursos de red frente a potenciales ataques indicados por atributos de paquete IP e ICMP inusuales.

Apéndice A, “Contextos para las firmas definidas por el usuario,” que proporciona descripciones de los contextos que se pueden especificar al definir un objeto de ataque de firma completa.

Convenciones del documento

Este documento utiliza las convenciones que se describen en las secciones siguientes:

“Convenciones de la interfaz de usuario web” en la página x

“Convenciones de interfaz de línea de comandos” en la página xi

“Convenciones de nomenclatura y conjuntos de caracteres” en la página xi

“Convenciones para las ilustraciones” en la página xiii

Convenciones de la interfaz de usuario webEn la interfaz de usuario web (WebUI), el conjunto de instrucciones de cada tarea se divide en ruta de navegación y establecimientos de configuración. Para abrir una página de WebUI e introducir parámetros de configuración, navegue hacia la página en cuestión haciendo clic en un elemento del menú en el árbol de navegación en el lado izquierdo de la pantalla, luego en los elementos subsiguientes. A medida que avanza, su ruta de navegación aparece en la parte superior de la pantalla, cada página separada por signos de mayor y menor.

Lo siguiente muestra los parámetros y ruta de WebUI para la definición de una dirección:

Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK:

Address Name: dir_1IP Address/Domain Name:

IP/Netmask: (seleccione), 10.2.2.5/32Zone: Untrust

Para abrir la ayuda en línea para los ajustes de configuración, haga clic en el signo de interrogación (?) en la parte superior izquierda de la pantalla.

onvenciones del documento


El árbol de navegación también proporciona una página de configuración de Help > Config Guide de configuración para ayudarle a configurar las directivas de seguridad y la Seguridad de protocolo de Internet (IPSec). Seleccione una opción del menú desplegable y siga las instrucciones en la página. Haga clic en el carácter ? en la parte superior izquierda para la Ayuda en línea en la Guía de configuración.

Convenciones de interfaz de línea de comandosLas siguientes convenciones se utilizan para presentar la sintaxis de los comandos de interfaz de línea de comandos (CLI) en ejemplos y en texto.

En ejemplos:

Los elementos 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

Las variables aparecen en cursiva:

set admin user nombre1 contraseña xyz

En el texto, los comandos están en negrita y las variables en cursiva.

Convenciones de nomenclatura y conjuntos de caracteresScreenOS 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) definidos en las configuraciones de ScreenOS:

Si una cadena de nombre tiene uno o más espacios, la cadena completa deberá estar entre comillas dobles; por ejemplo:

set address trust “local LAN” 10.1.1.0/24

Cualquier espacio al comienzo o al final de una cadena entrecomillada se elimina; por ejemplo, “ local LAN ” se transformará en “local LAN”.

Los espacios consecutivos múltiples se tratan como uno solo.

En las cadenas de nombres se distingue entre mayúsculas y minúsculas; por el contrario, en muchas palabras clave de CLI pueden utilizarse indistintamente. Por ejemplo, “local LAN” es distinto de “local lan”.

ScreenOS admite los siguientes conjuntos de caracteres:

NOTA: Para introducir palabras clave, basta con introducir los primeros caracteres para identificar la palabra de forma inequívoca. Al escribir set adm u whee j12fmt54 se ingresará el comando set admin user wheezer j12fmt54. Sin embargo, todos los comandos documentados aquí se encuentran presentes en su totalidad.

Convenciones del documento xi


xii

Conjuntos de caracteres de un byte (SBCS) y conjuntos de caracteres de múltiples bytes (MBCS). Algunos ejemplos de SBCS son los conjuntos 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.

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.

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.

Convenciones del documento


Convenciones para las ilustracionesLa siguiente figura muestra el conjunto básico de imágenes utilizado en las ilustraciones de este volumen:

Figura 1: Imágenes de las ilustraciones

Sistema autónomoo biendominio de enrutamiento virtual

Interfaces de zonas de seguridad:Blanco = Interfaz de zona protegida (ejemplo = zona Trust)Negro = Interfaz de zona externa(ejemplo = zona Untrust)

Dispositivos de seguridad Juniper Networks

Concentrador

Conmutador

Enrutador

Servidor

Túnel VPN

Dispositivo de red genérico

Rango dinámico de IP (DIP)Internet

Red de área local (LAN) con una única subredo bienzona de seguridad

Interfaz de túnel

Motor de directivas

Convenciones del documento xiii


xiv

Asistencia y documentación técnica

Para obtener documentación técnica sobre cualquier producto de Juniper Networks, visite www.juniper.net/techpubs/.

Para obtener soporte técnico, abra un expediente de soporte utilizando el vínculo “Case Manager” en la página web http://www.juniper.net/customers/support/ o llame al teléfono 1-888-314-JTAC (si llama desde los EE.UU.) o al +1-408-745-9500 (si llama desde fuera de los EE.UU.).

Si encuentra algún error u omisión en este documento, póngase en contacto con Juniper Networks al [email protected].

Asistencia y documentación técnica

http://www.juniper.net/techpubs/

http://www.juniper.net/customers/support/

mailto:[email protected]

Capítulo 1

Protección de una red

Puede haber numerosos motivos para entrar a una red protegida. La siguiente lista contiene algunos objetivos comunes:

Obtener el siguiente tipo de información sobre la red protegida:

Topología

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 en una red protegida

Conseguir acceso a un host en una red protegida para obtener información

Lograr el control de un host para aprovechar otras vulnerabilidades

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 con un dispositivo de seguridad Juniper Networks.

1


2

Este capítulo proporciona una vista general de las principales etapas de un ataque y de los diversos mecanismos de defensa que puede emplear para frustrar un ataque en cualquier etapa:

“Etapas de un ataque” en esta página

“Mecanismos de detección y defensa” en esta página

“Supervisión de vulnerabilidades” en la página 5

Etapas de un ataque

Normalmente, los ataques se desarrollan en dos etapas principales. En la primera etapa, el hacker recopila información; en la segunda etapa, lanza el ataque propiamente dicho.

1. Realizar el reconocimiento.

a. Crear un mapa de la red y determinar qué hosts están activos (barrido de direcciones IP).

b. Averiguar qué puertos están activos (análisis de puertos) en los hosts detectados mediante barrido de direcciones IP.

c. 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.

a. Ocultar el origen del ataque.

b. Realizar el ataque.

c. Eliminar u ocultar las pruebas.

Mecanismos de detección y defensa

La explotación de una vulnerabilidad (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 barrido de direcciones IP con el propósito de desencadenar respuestas de los hosts activos o como un ataque de asignación de grandes cantidades de paquetes simultáneos 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 es clara.

Etapas de un ataque

Capítulo 1: Protección de una red

Juniper Networks ofrece diversos métodos de detección y mecanismos de defensa a nivel de directivas y de zona para combatir los ataques a vulnerabilidades en todas sus etapas de ejecución:

Opciones SCREEN a nivel de zona

Las directivas del cortafuegos en los niveles de directivas interzonales, intrazonales y (superzonales representan aquí las directivas globales, donde no se hace referencia a las zonas de seguridad)

Para ofrecer protección contra todos los intentos de conexión, los dispositivos de seguridad de Juniper Networks utilizan un método de filtrado de paquetes dinámico conocido como inspección de estado. Mediante este método, el dispositivo de seguridad 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 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 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.

Las opciones SCREEN de ScreenOS aseguran una zona al inspeccionar y luego permitir o rechazar todo intento de conexión que necesite atravesar una interfaz asociada a dicha zona. El dispositivo de seguridad aplica entonces directivas de cortafuegos, que pueden contener componentes para el filtrado de contenidos y para la detección y prevención de intrusiones (IDP), al tráfico que atraviesa los filtros SCREEN.

Un cortafuegos de Juniper Networks proporciona los siguientes grupos de mecanismos de defensa:

Bloqueo de reconocimiento

Barrido de direcciones IP

Análisis de puertos

NOTA: Aunque las zonas VLAN y MGT son zonas de función y no zonas de seguridad, puede establecer 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 asignación de grandes cantidades de paquetes simultáneos 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 las asignaciones de grandes cantidades de paquetes simultáneos SYN, protección contra las asignaciones de grandes cantidades de paquetes simultáneos SYN-ACK-ACK del proxy, bloqueo de componentes HTTP y protección contra ataques de WinNuke.

Mecanismos de detección y defensa 3


4

Sondeos del sistema operativo

Técnicas de evasión

Supervisión y filtrado de contenidos

Reensamblaje de fragmentos

Análisis antivirus

Filtrado anti-spam

Filtrado de Web

Inspección a fondo

Firmas completas

Anomalías en el protocolo

Bloqueo granular de los componentes de HTTP

Defensas contra los ataques de denegación de servicio (DoS)

Ataques de DoS contra el cortafuegos

Asignación de grandes cantidades de paquetes simultáneos de la tabla de sesiones

Asignación de grandes cantidades de paquetes simultáneos del proxy SYN-ACK-ACK

Ataques DoS contra la red

Asignación de grandes cantidades de paquetes simultáneos SYN

Asignación de grandes cantidades de paquetes simultáneos ICMP

Asignación de grandes cantidades de paquetes simultáneos UDP

Ataques de DoS específicos de cada sistema operativo

Ping of death

Ataque “Teardrop”

WinNuke

Atributos de los paquetes sospechosos

Fragmentos ICMP

Paquetes ICMP grandes

Opciones IP incorrectas

Mecanismos de detección y defensa

Capítulo 1: Protección de una red

Protocolos desconocidos

Fragmentos de paquetes IP

Fragmentos SYN

Los ajustes de protección de red de ScreenOS operan en dos niveles: zona de seguridad y directivas. El dispositivo de seguridad de Juniper Networks ofrece defensas contra 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 de seguridad 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 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 del cortafuegos a nivel de zona son opciones SCREEN. Una opción de protección de red establecida en una directiva es un componente de dicha directiva.

Supervisión de vulnerabilidades

Aunque normalmente se utiliza el dispositivo de seguridad para bloquear ataques a vulnerabilidades, puede haber ocasiones en las que se desee obtener información sobre ellos. Es posible que desee estudiar específicamente una vulnerabilidad concreta para descubrir su intención, su nivel de sofisticación o incluso su origen (si el hacker es descuidado o poco sofisticado).

Si desea obtener información sobre un ataque, 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 de seguridad para que le notifique la existencia de un ataque, pero que, en lugar de tomar medidas, permita que el ataque se filtre. En tal caso, podrá estudiar qué ha ocurrido e intentar comprender el método, la estrategia y los objetivos del hacker. 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, se puede averiguar suficiente información como para determinar dónde se originó el ataque. Puede que también sea capaz de estimar las habilidades del hacker. Este tipo de información le permitirá calcular su respuesta.

Ejemplo: Supervisión de ataques desde la zona UntrustEn este ejemplo, se han producido ataques de simulación de IP desde la zona Untrust a diario, normalmente entre las 21:00 y las 0:00 horas. En lugar de descartar los paquetes con las direcciones simuladas IP de origen, se desea que el dispositivo de seguridad le notifique de su llegada, pero que le permita el paso, quizás conduciéndolos a un sistema trampa (un servidor de red que se utiliza como señuelo para atraer a los hackers y registrar sus movimientos durante un ataque) que se ha conectado a la conexión de interfaz DMZ. A las 208:55 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 hacker después de que atraviese 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.

Supervisión de vulnerabilidades 5


6

WebUI

Screening > Screen (Zone: Untrust): Introduzca los siguientes datos, luego haga clic en Apply:

Generate Alarms without Dropping Packet: (seleccione)IP Address Spoof Protection: (seleccione)

CLI

set zone untrust screen alarm-without-dropset zone untrust screen ip-spoofingsave

Supervisión de vulnerabilidades

Capítulo 2

Bloqueo de reconocimiento

Los hackers 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 posibles puntos de entrada (qué números de puertos están activos en los hosts activos) así como 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. Juniper Networks ofrece varias opciones SCREEN para frustrar los intentos de reconocimiento de los hackers e impedir que obtengan información valiosa sobre la red y los recursos de red protegidos.

“Barrido de direcciones IP” en la página 8

“Barrida de puertos” en la página 9

“Reconocimiento de red mediante opciones IP” en la página 10

“Sondeos del sistema operativo” en la página 12

“indicadores SYN y FIN activados” en la página 13

“Indicador FIN sin indicador ACK” en la página 14

“Encabezado TCP sin indicadores activados” en la página 15

“Técnicas de evasión” en la página 15

“Análisis FIN” en la página 16

“Indicadores no SYN” en la página 16

“Simulación de IP” en la página 20

“Opciones IP de ruta de origen” en la página 26

7


8


Se produce un barrido 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 de 5000 microsegundos). La finalidad de esta acción 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 de seguridad 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), el dispositivo de seguridad lo marcará como un ataque de barrido de direcciones y rechazará todas las peticiones de eco de ICMP siguientes que procedan de dicho host hasta que transcurra el tiempo del umbral especificado. El dispositivo detecta y descarta el décimo paquete que cumple con los criterios de ataque de barrido de direcciones.

Figura 2: Barrido de direcciones

Estudie la activación de esta opción SCREEN para una zona de seguridad solamente si existe una directiva que permita el tráfico ICMP procedente de dicha zona. De lo contrario, no es necesario habilitarla. Si no existe tal directiva, se rechaza todo el tráfico ICMP procedente de la zona, impidiendo a los hackers que realicen un barrido de direcciones IP con éxito.

Para bloquear los barridos de direcciones IP originados 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, luego haga clic en Apply:

IP Address Sweep Protection: (seleccione)Threshold: (introduzca un valor que active la protección contra barridos

de direcciones IP)

Origen: 2.2.2.5(Probablemente una dirección simulada o un agente zombie)

Nota: Después de recibir 10 paquetes ICMP, el dispositivo de seguridad lo registra como un barrido de direcciones IP y rechaza el paquete decimoprimero.

El dispositivo de seguridad realiza una entrada en su tabla de sesiones para los 10 primeros paquetes ICMP procedentes de 2.2.2.5 y realiza una consulta de rutas y una consulta de directivas para ellos. Si ninguna directiva permite estos paquetes, el dispositivo los marca como no válidos y los elimina de la tabla de sesiones en el siguiente “barrido de basura”, que se realiza cada dos segundos. A partir del décimo paquete, el dispositivo rechaza todo el tráfico ICMP procedente de 2.2.2.5.

ethernet21.2.2.1/24Untrust

Paquetes ICMP

Rechazado

ethernet31.1.1.1/24

Dir. origen

2.2.2.52.2.2.52.2.2.52.2.2.52.2.2.52.2.2.52.2.2.52.2.2.52.2.2.52.2.2.52.2.2.5

Dir. destino

1.2.2.51.2.2.1601.2.2.841.2.2.2111.2.2.101.2.2.201.2.2.211.2.2.2401.2.2.171.2.2.1231.2.2.6

11 paquetes ICMP en 0,005 segundos

DMZ


Capítulo 2: Bloqueo de reconocimiento

CLI

set zone zona screen port-scan threshold númeroset zone zona screen ip-sweep

Barrida de puertos

Una barrida de puertos se produce cuando una dirección IP de origen envía paquetes IP con segmentos TCP SYN a 10 puertos distintos de la misma dirección IP de destino en un intervalo definido (el valor predeterminado es de 5000 microsegundos). La finalidad de este esquema es examinar los servicios disponibles con la esperanza de que al menos un puerto responda, identificando un servicio al cual dirigir su ataque. El dispositivo de seguridad registra de forma interna el número de los diversos puertos analizados desde un origen remoto. Mediante los ajustes predeterminados, si un host remoto examina 10 puertos en 0.005 segundos (5000 microsegundos), el dispositivo lo marcará como ataque de barrida de puertos y rechazará todos los paquetes procedentes del origen remoto hasta que transcurra el resto del tiempo de espera especificado. El dispositivo detecta y descarta el décimo paquete que cumple con los criterios de un ataque de barrida de puertos.

Figura 3: Barrida de puertos

NOTA: El valor se mide en microsegundos. El ajuste predeterminado es 5000 microsegundos.

Origen: 2.2.2.5(Probablemente una dirección simulada o un agente zombie)

Nota: A partir del décimo paquete IP con segmentos TCP SYN destinado a diversos puertos de la misma dirección IP de destino, el dispositivo de seguridad lo registra como una barrida de puertos y rechaza todos los paquetes procedentes de la dirección de origen.

El dispositivo de seguridad realiza una entrada en su tabla de sesiones para los 10 primeros intentos de conexión de 2.2.2.5 a 1.2.2.5 y realiza una consulta de rutas así como una consulta de directivas para ellos. Si ninguna directiva permite estos intentos de conexión, el dispositivo los marca como no válidos y los elimina de la tabla de sesiones en el siguiente “barrido de basura”, que se realiza cada dos segundos. A partir del décimo intento, el dispositivo rechaza todos los intentos de conexión procedentes de 2.2.2.5.

ethernet21.2.2.1/24Untrust

Paquetes IP con segmentos TCP SYN

Rechazado

ethernet31.1.1.1/24

Dir orig:puerto

2.2.2.5:178202.2.2.5:422882.2.2.5:228142.2.2.5:154012.2.2.5:133732.2.2.5:338112.2.2.5:178212.2.2.5:190032.2.2.5:264502.2.2.5:380872.2.2.5:24111

Dir dest:puert

1.2.2.5:211.2.2.160:231.2.2.84:531.2.2.211:801.2.2.10:1111.2.2.20:1131.2.2.21:1231.2.2.240:1291.2.2.17:1371.2.2.123:1381.2.2.6:139

11 segmentos SYNen 0,005 segundos

DMZ

Destino: 1.2.2.5

Barrida de puertos 9


10

Para bloquear la barrida de puertos originados en una zona de seguridad en concreto, utilice una de las siguientes soluciones:

WebUI


Port Scan Protection: (seleccione)Threshold: (introduzca un valor que active la protección contra la

barrida de puertos)

CLI

set zone zona screen port-scan threshold númeroset zone zona screen port-scan

Reconocimiento de red mediante opciones IP

La norma RFC 791, Protocolo de Internet, 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, tal y como se muestra en la Figura 4.

Figura 4: Opciones de enrutamiento

La norma RFC 791 establece 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, con frecuencia se colocan para algún uso ilegítimo. La Tabla 1 enumera las opciones IP y sus atributos conjuntos.

Tabla 1: Opciones IP y atributos

NOTA: El valor se mide en microsegundos. El ajuste predeterminado es 5000 microsegundos.

Encabezado IP Tipo de servicio Longitud total del paquete (en bytes)

Identificación

Versión

Dirección de origen

ProtocoloTiempo de vida (TTL)

Dirección de destino

Longitud de encabezado

0

Suma de comprobación del encabezado

D M

Opciones

Carga de datos

Desplazamiento del fragmento

Tipo Clase Número Longitud Uso intencionado Uso pernicioso

Fin de opciones

01 0 0 Indica el fin de una o más opciones IP. Ninguno.

Sin opciones 0 1 0 Indica que no hay opciones IP en el encabezado.

Ninguno.

Reconocimiento de red mediante opciones IP


Seguridad 0 2 11 bits Ofrece un medio para que los hosts envíen seguridad, parámetros TCC (grupo de usuarios cerrado) y códigos de restricción de uso compatibles con los requisitos del Ministerio de Defensa (DoD) de los Estados Unidos. (Esta opción, según se especifica en las normas RFC 791, Protocolo de Internet y RFC 1038, Opción de seguridad de IP revisada, está obsoleta).

Desconocido. Sin embargo, ya que se trata de una opción obsoleta, su presencia en un encabezado IP resulta sospechosa.

Ruta de origen abierta

0 3 Variable 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.

Evasión. El hacker puede utilizar las rutas especificadas para ocultar el verdadero origen de un paquete o para obtener acceso a una red protegida. (Consulte “Opciones IP de ruta de origen” en la página 26).

Grabación de ruta

0 7 Variable Registra las direcciones IP de los dispositivos de red del itinerario que recorre el paquete IP. El equipo de destino puede extraer y procesar la información de ruta. (Debido a la limitación de espacio de 40 bytes tanto para la opción como para el espacio de almacenamiento, sólo se puede registrar un máximo de 9 direcciones IP).

Reconocimiento. Si el host de destino es un equipo comprometido bajo el control del hacker, éste puede obtener información sobre la topología y el esquema de direccionamiento de la red atravesada por el paquete.

Identificación de secuencia

0 8 4 bits (Obsoleta) Ofrecía un medio para que el identificador de secuencia SATNET de 16 bits se transportara por redes incompatibles con el concepto de secuencia.

Desconocido. Sin embargo, ya que se trata de una opción obsoleta, su presencia en un encabezado IP resulta sospechosa.

Ruta de origen estricta

0 9 Variable Especifica la lista de la ruta 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.

Evasión. Un hacker puede utilizar las rutas especificadas para ocultar el verdadero origen de un paquete o para obtener acceso a una red protegida. (Consulte “Opciones IP de ruta de origen” en la página 26).

Marca de hora

22 4 Registra la hora (en formato de horario universal3) en la que cada dispositivo de red recibe el paquete durante su trayecto desde el punto de origen al de destino. Los dispositivos de red se identifican por su número IP.

Esta opción desarrolla una lista de direcciones IP de los enrutadores del itinerario del paquete y la duración de transmisión entre cada uno de ellos.

Reconocimiento. Si el host de destino es un equipo comprometido bajo el control del hacker, éste puede obtener información sobre la topología y el esquema de direccionamiento de la red atravesada por el paquete.

1.La clase de opciones identificada como “0” estaba diseñada para proporcionar control de red o paquetes adicionales.2.La clase de opciones identificada como “2” se diseñó para el diagnóstico, la depuración y la medición.3.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.

Tipo Clase Número Longitud Uso intencionado Uso pernicioso

Reconocimiento de red mediante opciones IP 11


12

Las siguientes opciones SCREEN detectan las opciones IP que un hacker puede utilizar para el reconocimiento o cualquier otra finalidad desconocida, pero sospechosa:

Grabación de ruta: El dispositivo de seguridad detecta paquetes en los cuales la opción IP es 7 (Record Route) y registra el evento en la lista de contadores SCREEN para la interfaz de entrada.

Marca de hora: El dispositivo de seguridad detecta paquetes en los que la lista de opciones IP incluye la opción 4 (Internet Timestamp) y registra el evento en la lista de contadores SCREEN para la interfaz de entrada.

Seguridad: El dispositivo de seguridad detecta paquetes en los cuales la opción IP es 2 (security) y registra el evento en la lista de contadores SCREEN para la interfaz de entrada.

Identificador de secuencia: El dispositivo de seguridad detecta paquetes en los cuales la opción IP es 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 establecidas, utilice uno de los siguientes métodos (la zona de seguridad especificada es la zona en la que se originó el paquete):

WebUI


IP Record Route Option Detection: (seleccione)IP Timestamp Option Detection: (seleccione)IP Security Option Detection: (seleccione)IP Stream Option Detection: (seleccione)

CLI

set zone zona screen ip-record-routeset zone zona screen ip-timestamp-optset zone zona screen ip-security-optset zone zona screen ip-stream-opt


Antes de lanzar un ataque, es posible que un hacker intente sondear el host al que se dirige el ataque para averiguar qué sistema operativo (OS) utiliza. Al tener conocimiento de este dato, el hacker puede decidir con mejor criterio qué ataque lanzar y qué vulnerabilidades aprovechar. Un dispositivo de seguridad de Juniper Networks puede bloquear los sondeos de reconocimiento utilizados habitualmente para obtener información sobre los tipos de OS.



indicadores SYN y FIN activadosLos indicadores de control SYN y FIN no están activados normalmente en el mismo encabezado de segmento TCP. El indicador SYN sincroniza números de secuencia para el inicio de una conexión TCP. El indicador FIN señala el final de la transmisión de datos para la terminación de una conexión TCP. Sus finalidades se excluyen mutuamente. Un encabezado TCP con los indicadores SYN y FIN activados representa un comportamiento TCP anómalo y puede provocar varias respuestas del destinatario en función del OS. Consulte la Figura 5.

Figura 5: Encabezado TCP con indicadores SYN y FIN establecidos

Un hacker puede enviar un segmento con ambos indicadores (o “flags”) activados para ver el tipo de respuesta de sistema que se devuelve y determinar de este modo qué tipo de OS se utiliza en el punto de destino. A continuación, el hacker puede emplear cualquier vulnerabilidad conocida del sistema para futuros ataques.

Cuando se habilita esta opción SCREEN, el dispositivo de seguridad comprueba si los indicadores 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 indicadores SYN y FIN activados, 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 SYN and FIN Bits Set Protection y haga clic en Apply.

CLI

set zone zona screen syn-fin

Suma de comprobación de TCP 16 bits

Número de puerto de destino de 16 bitsEncabezado TCP

Número de reconocimiento de 32 bits

Tamaño de ventana de 16 bitsU

R

Número de puerto de origen de 16 bits

Los indicadores SYN y FIN están activados.

Número de secuencia de 32 bits

Reservado

Opciones (si las hay)

Datos (si los hay)

Puntero urgente 16 bits

ACK

PSH

RST

SYN

FIN

Tamaño de encabezado

Sondeos del sistema operativo 13


14

Indicador FIN sin indicador ACKLa Figura 6 muestra los segmentos TCP con el indicador de control FIN activado (para señalar la conclusión de una sesión y terminar la conexión). Normalmente, los segmentos TCP con el indicador FIN activado tienen también el indicador ACK activado (para acusar recibo del anterior paquete recibido). Como la existencia de un encabezado TCP con el indicador FIN activado y el indicador ACK desactivado representa un indicio de comportamiento TCP anómalo, no existe una respuesta uniforme ante este hecho. Es posible que el OS reaccione enviando un segmento TCP con el indicador RST activado. También es posible que lo ignore completamente. La respuesta de la víctima puede proporcionar al hacker información sobre el OS. (Otras finalidades para enviar un segmento TCP con el indicador FIN activado pueden ser evadir la detección durante una barrida de puertos y direcciones o burlar las defensas destinadas a prevenir una asignación de grandes cantidades de paquetes simultáneos SYN provocando una signación de grandes cantidades de paquetes simultáneos FIN en su lugar. Para obtener más información sobre los análisis FIN, consulte “Análisis FIN” en la página 16).

Figura 6: Encabezado TCP con indicador FIN activado

Cuando se habilita esta opción SCREEN, el dispositivo de seguridad comprueba si el indicador FIN está activado y el indicador ACK está desactivado en los encabezados TCP. Si descubre un paquete con este tipo de encabezado, descarta el paquete.

Para bloquear paquetes con el indicador FIN activado y el indicador 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 zona screen fin-no-ack

NOTA: Los proveedores han interpretado la norma RFC 793, Protocolo de control de transmisiones de diversas formas a la hora de diseñar las implementaciones TCP/IP. Cuando se recibe un segmento TCP con el indicador FIN activado y el indicador ACK sin activar, algunas implementaciones envían segmentos RST. Otras descartan el paquete sin enviar ningún segmento RST.


Número de puerto de destino de 16 bitsEncabezado TCP



R


Sólo está activado el indicador FIN.


Reservado


Datos (si los hay)


ACK

PSH

RST

SYN

FIN

Tamaño de encabezado 4 bits

FIN



Encabezado TCP sin indicadores activadosUn encabezado de segmento TCP normal tiene al menos un indicador de control activado. Un segmento TCP sin indicadores 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. Consulte la Figura 7.

Figura 7: Encabezado TCP sin indicadores activado

Cuando se habilita el dispositivo de seguridad para detectar encabezados de segmento TCP sin indicadores activados, el dispositivo descartará todos los paquetes TCP que carezcan de un campo de indicador o que tengan un campo de indicador mal formado.

Para bloquear los paquetes que no tengan ningún indicador activado, 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 TCP Packet without Flag Protection y haga clic en Apply.

CLI

set zone zona screen tcp-no-flag


Ya sea mientras recopila información o lanza un ataque, lo normal es que el hacker evite que lo detecten. Aunque ciertas barridas de puertos y direcciones IP son tan descaradas que se pueden detectar fácilmente, algunos hackers con mayores recursos utilizan una gran cantidad de medios para ocultar sus actividades. Técnicas tales como la utilización de análisis FIN en lugar de análisis SYN, que los hackers 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 aprovechamiento de vulnerabilidades con la finalidad de eludir la detección y llevar a cabo sus acciones.


Número de puerto de destino de 16 bits



R


No hay ningún indicador activado.


Reservado


Datos (si los hay)


ACK

PSH

RST

SYN

FIN

Tamaño de encabezado 4 bits

Encabezado TCP

Técnicas de evasión 15


16

Análisis FINUn análisis FIN envía segmentos TCP con el indicador FIN activado para intentar provocar una respuesta (un segmento TCP con el indicador RST activado) y así descubrir un host activo o un puerto activo en un host. El hacker 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 indicador FIN activado se puede evadir la detección, permitiendo así que el hacker 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 indicador FIN activado, pero no el indicador 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: Introduzca set zone nombre screen fin-no-ack, donde nombre se refiere a la zona a la que desee aplicar esta opción de 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 indicador SYN, consulte la siguiente sección, “Indicadores no SYN” en la página 16.)

Indicadores no SYNDe forma predeterminada, el dispositivo de seguridad revisa si hay indicadores SYN en el primer paquete de una sesión y rechaza cualquier segmento TCP que tenga indicadores que no sean SYN intentando iniciar una sesión. Puede dejar fluir este paquete tal y como está o cambiarlo para que el dispositivo no utilice la revisión de indicador SYN antes de crear una sesión. La Figura 8 en la página 17 muestra las secuencias del flujo de paquete cuando está habilitada la revisión del indicador SYN y cuando está desactivada.

NOTA: El cambio del flujo de paquetes para comprobar que el indicador SYN está activado para los paquetes que no pertenecen a sesiones existentes, también frustra otros tipos de análisis no SYN, tales como los análisis nulos (“null scan”, es decir, cuando no hay ningún indicador de TCP activo).



Figura 8: Comprobación de indicador SYN

Cuando el dispositivo de seguridad con la comprobación de indicador SYN habilitada recibe un segmento de TCP que no es SYN y no pertenece a una sesión existente, éste descarta el paquete y envía el host de origen a TCP RST, a menos que el bit de código de un paquete TCP que no es SYN inicial, también sea RST. En ese caso, el dispositivo de seguridad sencillamente descarta el paquete.

Puede habilitar y deshabilitar la comprobación de SYN con los siguientes comandos CLI:

set flow tcp-syn-checkunset flow tcp-syn-check

NOTA: De forma predeterminada, la revisión del indicador TCP SYN en el paquete inicial de una sesión está habilitada cuando se instala el dispositivo de seguridad de Juniper Networks con ejecución de ScreenOS 5.1.0 o superior. Si se actualiza de una versión anterior a ScreenOS 5.1.0, la revisión SYN permanece desactivada de forma predeterminada, a menos que haya cambiado previamente el comportamiento predeterminado.

Estos flujos de paquete son los mismos ya sea que la interfaz de entrada esté operando en la capa 3 (modo de ruta o NAT) o en la capa 2 (modo transparente).

Consulta de sesiones

Actualización de sesión REDIRECCIONAMIENTO

En sesión

Permis Sí

REDIRECCIONAMIENTOCreación de sesión

Comprobación de indicador

SYN

Con la comprobación de indicador SYN habilitada

No en sesión

Rechazado No

DESCARTARDESCARTAR

Consulta de directivas

El paquete llega a la interfaz de entrada

Consulta de sesiones

Actualización de sesión

REDIRECCIONAMIENTO

En sesión

Permis Creación de sesión

No en sesión

Rechazado

DESCARTAR

Consulta de directivas

El paquete llega a

REDIRECCIONAMIENTO

Con la comprobación de indicador SYN inhabilitada



18

La opción de no comprobar el indicador 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 indicador SYN activado a un dispositivo de seguridad (dispositivo A), pero la señal SYN/ACK podría enrutarse al otro dispositivo de seguridad del clúster (dispositivo B). Si este enrutamiento asimétrico se produce después de que el dispositivo A haya sincronizado su sesión con el dispositivo B, todo está en orden. Por el contrario, si la respuesta SYN/ACK llega al dispositivo B antes de que el dispositivo A haya sincronizado la sesión y la comprobación de SYN está habilitada, el dispositivo B rechaza SYN/ACK, lo que impide establecer la sesión. Con la comprobación de SYN inhabilitada, el dispositivo 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 de seguridad en modo transparente a una red operativa, se interrumpen todas las sesiones existentes y por lo tanto 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 de seguridad o incluso si se cambia un componente en la sección central de una 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 reiniciarse. Inhabilitar la comprobación de SYN evita esas interrupciones al tráfico de la red.

Sin embargo, observe que las ventajas anteriores requieren los siguientes sacrificios en seguridad:

Agujeros de reconocimiento: Cuando un segmento TCP inicial con un indicador no SYN (como ACK, URG, RST, FIN) llega a un puerto cerrado, muchos sistemas operativos (Windows, por ejemplo) responden con un segmento TCP cuyo indicador RST está activado. Si el puerto está abierto, el receptor no genera ninguna respuesta.

NOTA: Una solución a esta situación es instalar el dispositivo de seguridad con la comprobación de SYN inicialmente inhabilitada. Luego, después de unas pocas horas, cuando las sesiones establecidas se estén ejecutando a través del dispositivo, habilite la comprobación de SYN.

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.



Al analizar 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 ScreenOS. Si después envía un segmento TCP con un indicador 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 indicador 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 indicador SYN habilitada, el dispositivo de seguridad descarta los segmentos TCP que no tengan indicador 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 si el puerto está abierto o cerrado en el host de destino.

Asignaciones de grandes cantidades de paquetes simultáneos de tablas de sesiones: Si la comprobación de SYN está inhabilitada, un hacker puede evitar la función de protección contra la asignación de grandes cantidades de paquetes simultáneos SYN de ScreenOS al asignar una red protegida con una cantidad ingente de segmentos TCP que tengan indicadores no SYN activados. Aunque los hosts atacados descartarán los paquetes (y posiblemente envíen segmentos TCP RST como respuesta), tal asignación de grandes cantidades de paquetes simultáneos podría llenar la tabla de sesiones del dispositivo de seguridad. Con la tabla de sesiones llena, el dispositivo no puede procesar nuevas sesiones de tráfico legítimo.

Al habilitar la comprobación de SYN y la protección contra las asignaciones de grandes cantidades de paquetes simultáneos SYN, podrá frustrar esta clase de ataques. Al revisar que el indicador SYN está activado en el paquete inicial de una sesión se obliga a todas las nuevas sesiones a comenzar con un segmento TCP que tenga el indicador SYN activado. A continuación, la protección contra las asignaciones de grandes cantidades de paquetes simultáneos SYN limita el número de segmentos TCP SYN por segundo para evitar saturaciones en la tabla de sesiones.

Si no necesita desactivar la comprobación de SYN, Juniper Networks le recomienda que esté habilitada (su estado predeterminado para una instalación inicial de ScreenOS). Puede habilitarla con el siguiente comando: set flow tcp-syn-check. Con la comprobación de SYN habilitada, el dispositivo de seguridad rechaza los segmentos TCP con indicadores que no son SYN activados, salvo que pertenezcan a una sesión establecida.

NOTA: Para obtener información sobre las asignaciones de grandes cantidades de paquetes simultáneos de la tabla de sesiones, consulte “Inundaciones de la tabla de sesiones” en la página 30. Para obtener información sobre las asignaciones de grandes cantidades de paquetes simultáneos SYN de la tabla de sesiones, consulte “Inundaciones SYN” en la página 37.



20

Simulación de IPUn método para intentar acceder a un área restringida de la red es insertar una dirección de origen fantasma en el encabezado del paquete para que éste parezca que procede de un lugar de origen fiable. Esta técnica se conoce como simulación de IP (IP Spoofing). Para detectar esta técnica, ScreenOS dispone de dos métodos con el mismo objetivo: determinar si el paquete procede de una ubicación distinta a la indicada en el encabezado. El método que utiliza el dispositivo de seguridad de Juniper Networks depende de si funciona en la capa 3 o en la capa 2 del modelo OSI.

Capa 3: cuando las interfaces del dispositivo de seguridad funcionan en modo de ruta o en modo NAT, el mecanismo para detectar la simulació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 de seguridad tiene una ruta a 10.1.1.0/24 a través de ethernet1, la comprobación de simulació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 simulada y la descarta.

Figura 9: Simulación de IP de la capa 3

Si la dirección IP de origen de un paquete no aparece en la tabla de rutas, el dispositivo de seguridad permite su paso de forma predeterminada (asumiendo que existe una directiva que lo permite). Si utiliza el siguiente comando CLI (en donde la zona de seguridad especificada es la zona de donde proceden los paquetes), puede hacer que el dispositivo de seguridad descarte cualquier paquete cuya dirección IP de origen no esté incluida en la tabla de rutas:

set zone zona screen ip-spoofing drop-no-rpf-route

X

Un paquete IP llega a ethernet3. Su dirección IP de origen es 10.1.1.6.

1.

3.

2.

Paquete IP con IP de origen 10.1.1.6

Si al consultar la tabla de rutas observa que 10.1.1.6 no es una dirección IP de origen válida para un paquete que llega a ethernet3, el dispositivo rechazará el paquete.

Como la protección contra simulación de IP está habilitada en la zona Untrust, el dispositivo comprueba si 10.1.1.6 es una dirección IP de origen válida para los paquetes que llegan a ethernet3.

Zona Trust

Zona Untrust

ethernet3 1.1.1.1/24

ethernet1 10.1.1.1/24

Subred: 10.1.1.0/24

Tabla de rutas

ID

1

IP-Prefijo

10.1.10/24

Interfazeth 1

Puerta de enlace

0.0.0.0PC



Capa 2: si las interfaces del dispositivo de seguridad funcionan en modo transparente, el mecanismo de comprobación de simulació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 simulació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 tiene una dirección IP de origen simulada y la descarta.

Figura 10: Simulación de IP de la capa 2

Tenga cuidado al definir direcciones para la subred que abarca múltiples zonas de seguridad. En la Figura 10, 1.2.2.0/24 pertenece tanto a la zona V1-Untrust como a la zona V1-DMZ. Si configura el dispositivo de seguridad tal y como se describe a continuación, bloqueará el tráfico procedente de la zona V1-DMZ cuyo paso desea permitir:

Defina una dirección para 1.2.2.0/24 en la zona V1-Untrust.

Tenga una directiva que permita 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).

Habilite la comprobación de simulació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 simulación de IP consultará la libreta de direcciones y encontrará 1.2.2.0/24 en la zona V1-Untrust. En consecuencia, el dispositivo de seguridad bloqueará el tráfico.

Un paquete IP llega de la zona V1-Untrust. Su dirección IP de origen es 1.2.2.5.

1.

3.

2.

Paquete IP con IP de origen 1.2.2.5

Si al consultar la libreta de direcciones observa que 1.2.2.5 no es una dirección IP de origen válida para un paquete procedente de la zona V1-Untrust, el dispositivo rechazará el paquete.

Debido a que la protección contra simulación de IP está habilitada en la zona Untrust V1, el dispositivo comprueba si 1.2.2.5 es una dirección IP de origen válida para el paquete que llega de la zona Untrust V1.

Zona V1-DMZ

Zona V1-Untrust

ethernet3 0.0.0.0/0

ethernet20.0.0.0/0

Subred: 1.2.2.0/24

Nombre de zona de dirección: V1-DMZ

serv ANombre

1.2.2.5Dirección Máscara de red

255.255.255.255Cserv A



22

Ejemplo: Protección contra simulación de IP en la capa 3En este ejemplo habilitará la protección contra simulación de IP en las zonas Trust, DMZ y Untrust para un dispositivo de seguridad de Juniper Networks que funciona en la capa 3. De forma predeterminada el dispositivo 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 que se muestran en la siguiente tabla:

Si habilita la opción SCREEN para protección contra simulación de IP pero no indica estas tres rutas, el dispositivo 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 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.

Figura 11: Ejemplo de la simulación de IP de la capa 3

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

10.1.2.0/24

Enrutador1.1.1.250

Zona DMZ

Zona Untrust

ethernet21.2.2.1/24

1.2.3.0/24

1.2.2.0/24Zona Trust

10.1.1.0/24

ethernet110.1.1.1/24

ethernet31.1.1.1/24

Enrutador10.1.1.250

1.1.1.0/24 0.0.0.0/0

Enrutador1.2.2.250



WebUI

1. InterfacesNetwork > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos, luego haga clic en Apply:

Zone Name: TrustStatic 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: DMZStatic IP: (seleccione esta opción si es posible)IP Address/Netmask: 1.2.2.1/24


Zone Name: UntrustStatic IP: (seleccione esta opción si es posible)IP Address/Netmask: 1.1.1.1/24

2. RutasNetwork > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK:

Network Address/Netmask: 10.1.2.0/24Gateway: (seleccione)

Interface: ethernet1Gateway IP Address: 10.1.1.250

Network > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK:



Network > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK:





24

3. Protección contra simulación de IPScreening > 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. Interfacesset interface ethernet1 zone trustset interface ethernet1 ip 10.1.1.1/24set interface ethernet1 natset interface ethernet2 zone dmzset interface ethernet2 ip 1.2.2.1/24set interface ethernet3 zone untrustset interface ethernet3 ip 1.1.1.1/24

2. Rutasset vrouter trust-vr route 10.1.2.0/24 interface ethernet1 gateway 10.1.1.250set vrouter trust-vr route 1.2.3.0/24 interface ethernet2 gateway 1.2.2.250set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250

3. Protección contra simulación de IPset zone trust screen ip-spoofingset zone dmz screen ip-spoofingset zone untrust screen ip-spoofingsave

Ejemplo: Protección contra simulación de IP en la capa 2En este ejemplo protegerá la zona V1-DMZ contra la simulación de IP en el tráfico originado en la zona V1-Untrust. En primer lugar debe 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 hacker en la zona V1-Untrust intenta simular la dirección IP de origen utilizando cualquiera de las tres direcciones de la zona V1-DMZ, el dispositivo de seguridad comprobará la dirección comparándola con las direcciones de las libretas de direcciones. Cuando descubra que la dirección IP de origen de un paquete procedente de la zona V1-Untrust pertenece a una dirección definida en la zona V1-Untrust, el dispositivo rechazará el paquete.



WebUI

1. DireccionesPolicy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK:

Address Name: servAIP Address/Domain Name:

IP/Netmask: (seleccione), 1.2.2.10/32Zone: V1-DMZ


Address Name: servBIP Address/Domain Name:



Address Name: servCIP Address/Domain Name:


2. Protección contra simulación de IPScreening > Screen (Zone: V1-Trust): Seleccione IP Address Spoof Protection y haga clic en Apply.

CLI

1. Direccionesset address v1-dmz servA 1.2.2.10/32set address v1-dmz servB 1.2.2.20/32set address v1-dmz servC 1.2.2.30/32

2. Protección contra simulación de IPset zone v1-untrust screen ip-spoofingsave



26

Opciones IP de ruta de origenEl enrutamiento de origen se diseñó 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. Luego, 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. Al cambiar las direcciones de enrutador para cambiar el itinerario y enviar diversos paquetes por distintos itinerarios, puede observar 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.

Figura 12: Ruta de origen IP

Aunque la aplicación de las opciones IP de ruta de origen era buena 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 hacker 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 hacker puede poner en práctica estos engaños, como se muestra en la Figura 13.

Opciones IP de ruta de origen para diagnóstico

Cuatro enrutadores

Itinerario del paqueteLa transmisión de A a B mediante los enrutadores 1 y 3 se realiza con éxito el 50% de las ocasiones.

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 a B se realiza con éxito el 50% de las ocasiones.

Mediante el enrutamiento de origen IP, 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 ocasiones. Por lo tanto, podemos suponer que el problema reside en el enrutador 3.

1

2

3

4

4

4

3

3

2

2

1

1

A B

B

BA

A



Figura 13: Opción IP de ruta de origen abierta para un engaño

El dispositivo de seguridad de Juniper Networks 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 hacen cumplir los controles de acceso, pero los enrutadores 1 y 2 no los hacen cumplir. Además, el enrutador 2 no comprueba la posible simulación de IP. El hacker 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 redirecciona el paquete al enrutador 3, que a su vez lo redirecciona al dispositivo de seguridad. 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 lo rechaza.

El dispositivo de seguridad se puede habilitar para que bloquee cualquier paquete con opciones de ruta de origen abierta o estricta o para que los detecte y luego 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: Habilite 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 hacker entrar en una red con una dirección IP falsa.

Detect IP Loose Source Route Option: El dispositivo de seguridad detecta paquetes en los que la opción IP es 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 pasar por otros enrutadores.

Detect IP Strict Source Route Option: El dispositivo de seguridad detecta paquetes en los que la opción IP es 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 10).

Sin comprobación de simulación de IP

Sin control de acceso

Cuatro enrutadores

Itinerario del paquete

10.1.1.0/24

1

2

3

4

Información del paqueteDirección de origen real: 6.6.6.5Dirección de origen simulada: 2.2.2.5Dirección de destino: 1.1.1.5IP de ruta de origen abierta: 6.6.6.250, 2.2.2.250

Hacker

2.2.2.0/24

Dirección IP asignada: 1.1.1.5 - 10.1.1.5Directiva: set policy from untrust to trust 2.2.2.0/24 MIP(1.1.1.5) HTTP permit

ethernet31.1.1.1/24

Zona Untrust

ethernet110.1.1.1/24Zona Trust

Servidor HTTP 10.1.1.5

Entre las opciones SCREEN para la zona Untrust se incluye “Deny IP Source Route Option”.El dispositivo de seguridad descarta el paquete.



28

Para bloquear paquetes con la opción IP de ruta de origen abierta o estricta establecida, 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 zona screen ip-filter-src

Para detectar y registrar (pero no bloquear) paquetes con la opción IP de ruta de origen abierta o estricta establecida, utilice uno de los siguientes métodos (la zona de seguridad especificada es la zona en la que se originó el paquete):

WebUI


IP Loose Source Route Option Detection: (seleccione)IP Strict Source Route Option Detection: (seleccione)

CLI

set zone zona screen ip-loose-src-routeset zone zona screen ip-strict-src-route


Capítulo 3

Defensas contra los ataques de denegación de servicio

La intención de un ataque de denegación de servicio (DoS) es sobrecargar a la víctima potencial con tal cantidad de tráfico fantasma que se sature intentando procesar el tráfico fantasma y no consiga procesar el tráfico legítimo. El objetivo puede ser el cortafuegos de Juniper Networks, los recursos de red cuyos accesos controla el cortafuegos o la plataforma de hardware específica o el sistema operativo (OS) de un host determinado.

Si un ataque DoS se genera desde 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 simulada (“spoofed”). Las direcciones de origen de un ataque DDoS pueden ser simuladas, o bien, pueden ser las direcciones reales de hosts previamente comprometidos por el hacker y que éste utiliza ahora como “agentes zombie” para ejecutar el ataque.

El dispositivo de seguridad puede defenderse a sí mismo y defender a los recursos que protege de los ataques DoS y DDoS. Las siguientes secciones describen las diversas opciones de defensa disponibles:

“Ataques DoS contra el cortafuegos” en la página 30

“Inundaciones de la tabla de sesiones” en la página 30

“Inundaciones de SYN-ACK-ACK a través de un servidor proxy” en la página 35

“Ataques DoS contra la red” en la página 37

“Inundaciones SYN” en la página 37

“Cookie SYN” en la página 47

“Inundaciones ICMP” en la página 49

“Inundaciones UDP” en la página 51

“Ataque terrestre” en la página 52

29


30

“Ataques de DoS específicos de cada sistema operativo” en la página 53

“Ping of Death” en la página 53

“Ataque Teardrop” en la página 54

“WinNuke” en la página 55

Ataques DoS contra el cortafuegos

Si un hacker descubre la presencia del cortafuegos de Juniper Networks, 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 de éste. Un ataque DoS que tenga éxito contra un cortafuegos desembocará en otro ataque DoS exitoso 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 hacker puede utilizar para llenar la tabla de sesiones de un dispositivo de seguridad de Juniper Networks y, de ese modo, producir una denegación de servicio: Inundaciones de la tabla de sesiones y Inundaciones de SYN-ACK-ACK a través de un servidor proxy.

Inundaciones de la tabla de sesionesUn ataque DoS acertado sobrecarga a su víctima con una cantidad tan ingente de tráfico falso simulado que le impide procesar las peticiones de conexión legítimas. Los ataques de DoS pueden adoptar muchas formas (inundaciones de SYN, de SYN-ACK-ACK, de UDP, de ICMP, etc.), pero todos ellos 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 a la cantidad de sesiones según sus orígenes y destinos

Expiración dinámica

Límites a la cantidad de sesiones según sus orígenes y destinosAdemás de limitar el número de sesiones concurrentes que proceden de la misma dirección IP de origen, también puede limitar el número de sesiones concurrentes hacia la misma dirección IP de destino. Una ventaja de establecer un límite a las sesiones en base a 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 desde ese servidor. Dado que todo el tráfico generado por un virus procede de la misma dirección IP, un límite de sesiones según su origen garantiza que el cortafuegos pueda retener tales cantidades excesivas de tráfico.


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

Figura 14: Limitación de sesiones según su dirección IP de origen

Otra ventaja de limitar las sesiones según su origen es reducir el número de intentos ilegítimos de llenar la tabla de sesiones de ScreenOS (siempre que todos esos intentos de conexión procedan de la misma dirección IP de origen). Sin embargo, un hacker astuto podría ejecutar un ataque distribuido de denegación de servicio (DDoS). En un ataque DDoS, el tráfico malintencionado puede proceder de centenares de hosts, conocidos como agentes zombie, que están clandestinamente bajo el control de un hacker. Además de las opciones de detección de inundaciones de SYN, UDP e ICMP y de prevención SCREEN, al establecer un límite de sesiones según su destino se puede garantizar que el dispositivo de seguridad admita solamente un número aceptable de peticiones de conexión simultáneas (sin importar su origen) para alcanzar cualquier host.

Figura 15: Ataque DOS distribuido

…Cuando el número de sesiones concurrentes del servidor infectado alcanza el límite máximo, el dispositivo de seguridad comienza a bloquear todos los intentos de conexión subsiguientes de ese servidor.

Limitación de sesiones según su origen: contención del tráfico del virus/gusano Nimda

Un servidor Web se infecta con el híbrido del virus/gusano Nimda, lo que provoca que el servidor genere cantidades excesivas de tráfico.

Zona Untrust

Zona DMZ Servidor

infectado

Limitación de sesiones según su destino: Ataque de denegación de servicio distribuido

IP de origen de host inexistente: 6.6.6.6

Zona Untrust

Zona DMZ

Agentes zombie

Zona Untrust

Hacker

Zona DMZ

Servidor web

Limitación de sesiones según su origen: Ataque de denegación de servicio

Cuando el número de sesiones concurrentes al servidor web sobrepasa el límite máximo, el dispositivo de seguridad bloquea cualquier intento de conexión subsiguiente a esa dirección IP.

Cuando el número de sesiones concurrentes que proceden de 6.6.6.6 sobrepasa el límite máximo, el dispositivo de seguridad bloquea cualquier conexión subsiguiente de esa dirección IP.

Hacker

Servidor web

Ataques DoS contra el cortafuegos 31


32

Determinar cuál es el número aceptable de peticiones de conexión requiere un período de observación y análisis para establecer una base de referencia con la cual determinar los flujos de tráfico típicos. También se debe tener en cuenta el número máximo de sesiones concurrentes requeridas para llenar la tabla de sesiones de la plataforma de Juniper Networks 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 su destino son de 128 sesiones concurrentes, 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 origenEn este ejemplo, desea limitar el número de sesiones que cualquier servidor de las zonas DMZ y Trust puede iniciar. Dado que la zona DMZ únicamente contiene servidores web, ninguno de los cuales debería iniciar tráfico, deberá 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 concurrentes.

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)Threshold: 80 Sessions

CLI

set zone dmz screen limit-session source-ip-based 1set zone dmz screen limit-session source-ip-basedset zone trust screen limit-session source-ip-based 80set zone trust screen limit-session source-ip-basedsave

Ejemplo: Limitación de sesiones según su destinoEn este ejemplo desea limitar la cantidad de tráfico dirigido hacia 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 concurrentes que recibe es 2000. De acuerdo con esta información, decide establecer el nuevo límite de sesiones en 4000 sesiones concurrentes. 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)Threshold: 4000 Sessions

CLI

set zone untrust screen limit-session destination-ip-based 4000set zone untrust screen limit-session destination-ip-basedsave

Expiración dinámicaDe forma predeterminada, el establecimiento de una conexión inicial en 3 pasos de una sesión TCP tarda 20 segundos en caducar (es decir, 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 contador de tiempo de espera 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 contador de tiempo de espera comienza la cuenta atrás.

En plataformas de hardware determinadas, ScreenOS 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. Esta función no está disponible en sistemas de gama alta.

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 expiración dinámica esté activo, el dispositivo de seguridad forzará primero la expiración de las sesiones más antiguas, aplicándoles la tasa de expiración que especificó. Estas sesiones de expiración forzada se marcan como no válidas y se eliminan en la siguiente “limpieza de basura”, que ocurre cada 2 segundos.

La opción de expiración dinámica reduce los tiempos de espera predeterminados de las sesiones según la cantidad introducida. Al establecer y habilitar la opción de expiración dinámica, 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). No obstante, cuando se activa el período de la expiración dinámica, estas sesiones caducan antes (aplicando el tiempo especificado para expiraciones prematuras, y no la cuenta atrás hasta cero).

El valor de expiración dinámica puede estar entre 2 y 10 unidades, donde cada unidad representa un intervalo de 10 segundos (es decir, el ajuste de la expiración dinámica puede tener una duración de 20 a 100 segundos). El ajuste predeterminado es de 2 unidades, equivalentes a 20 segundos. Si, por ejemplo, establece el ajuste de la expiración dinámica en 100 segundos, disminuirá los tiempos de espera de sesiones HTTP y TCP de la siguiente manera:



34

TCP: El valor del tiempo de espera de la sesión disminuye de 1800 segundos (30 minutos) a 1700 segundos (28:20 minutos), mientras el proceso de expiración dinámica está activo. Durante ese período, el dispositivo de seguridad 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.

Figura 16: Tiempo de espera de las sesiones TCP

HTTP: El valor del tiempo de espera de la sesión disminuye de 300 segundos (5 minutos) a 200 segundos (3:20 minutos) mientras el proceso de expiración dinámica está activo. Durante ese período, el dispositivo de seguridad 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.

Figura 17: Tiempo de espera de la sesión HTTP

UDP: Dado que el tiempo de espera predeterminado de una sesión UDP es de 60 segundos, al definir el ajuste de una expiración prematura de 100 segundos provoca que todas las sesiones UDP caduquen y queden marcadas para su eliminación en el siguiente “barrido de basura”.

Ejemplo: Expiración dinámica de sesionesEn este ejemplo establecerá que el proceso de expiración dinámica comience cuando el tráfico supere un umbral superior del 80 por ciento y finalice cuando disminuya por debajo de un umbral menor del 70 por ciento. Se especificará 40 segundos como el intervalo de expiración dinámica. Cuando la tabla de sesiones se llena más del 80 por ciento (el umbral superior), el dispositivo de seguridad reduce el tiempo de espera a 40 segundos en todas las sesiones y comienza a forzar dinámicamente la expiración de las sesiones más antiguas hasta que el número de sesiones en la tabla es menor del 70 por ciento (el umbral inferior).

Figura 18: Expiración dinámica de sesiones

Tiempo de espera predeterminado de las sesiones TCP: 30 min (1800 seg)

Expiración dinámica = 10 (predeterminado - 100 seg):28:20 min (1700 seg)

Min

Seg 1800 1500 1200 900 600

1015202530 5 0

300 0

Tiempo de espera predeterminado de la sesión HTTP: 5 min (300 seg)

Expiración dinámica = 10 (predeterminado - 100 seg):3:20 min (200 seg)

Min

Seg 300 240 180 120 60

12345 0

0

100%

80%

70%

0%

Cuando el número de sesiones supera la capacidad del 80%, se activa el mecanismo de expiración dinámica.

Umbral superiorExpiración dinámica(caducado - 40 seg)

Umbral inferior

Las sesiones expiran dinámicamente hasta que la cantidad cae por debajo del 70%. En ese momento, el mecanismo de expiración dinámica se detiene.

Sesiones



WebUI

CLI

set flow aging low-watermark 70set flow aging high-watermark 80set flow aging early-ageout 4save

Inundaciones de SYN-ACK-ACK a través de un servidor proxyCuando 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 de seguridad intercepta el segmento SYN, crea una entrada en su tabla de sesiones y envía al usuario un segmento SYN-ACK a través de un servidor proxy. El usuario responde entonces con un segmento ACK. En ese momento se completa el establecimiento inicial de conexión en tres pasos. El dispositivo envía al usuario un mensaje de petición de inicio de sesión. Si el usuario, malintencionado, en lugar de iniciar la sesión continúa iniciando sesiones SYN-ACK-ACK, la tabla de sesiones de ScreenOS puede llenarse hasta el punto en que el dispositivo comience a rechazar peticiones de conexión legítimas.

Consulte la Figura 19 si desea observar el proceso paso a paso:

1. El cliente envía un segmento SYN al servidor.

2. El dispositivo seguridad envía un segmento SYN/ACK a través de un servidor proxy.

3. El cliente responde con un segmento ACK.

4. El dispositivo de seguridad solicita al cliente (usuario de autenticación) que inicie una sesión.

5. El cliente ignora el mensaje de petición de inicio de sesión y sigue repitiendo los pasos del 1 al 4 hasta llenar la tabla de sesiones.

6. Al estar la tabla de sesiones llena, el dispositivo de seguridad debe rechazar todas las demás peticiones de conexión.

NOTA: Para configurar los ajustes de expiración dinámica debe utilizar la interfaz de línea de comandos (“CLI”).



36

Figura 19: Inundaciones de SYN-ACK-ACK a través de un servidor proxy

Para evitar tal ataque, puede habilitar la opción SCREEN de protección de SYN-ACK-ACK a través de 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 de seguridad rechaza las peticiones de conexión subsiguientes provenientes 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 que se adapte mejor a los requisitos de su entorno de red.

Para habilitar la protección contra inundaciones de SYN-ACK-ACK a través de un servidor proxy, ejecute cualquiera de los siguientes procedimientos, donde la zona especificada es aquélla en la que se origina el ataque:

WebUI


SYN-ACK-ACK Proxy Protection: (seleccione)Threshold: (introduzca un valor para activar la protección contra

inundaciones de SYN-ACK-ACK del proxy)

CLI

set zone zona screen syn-ack-ack-proxy threshold númeroset zone zona screen syn-ack-ack-proxy

.

.

.

Cliente Telnet o FTP (usuario de autenticación)

Zona Untrust

SYN

SYN/ACK

ACK

Name: ? Password: ?

SYN

SYN/ACK

Zona TrustServidor Telnet

o FTP

Tabla de sesiones de ScreenOS: Otros recursos disponibles.

La tabla de sesiones se está llenando.

La tabla de sesiones está llena.

ACK

Name: ?Password: ?

SYN

NOTA: 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.




Un ataque de denegación de servicio (DoS) dirigido contra unos o más recursos de red, satura el destino con una cantidad abrumadora de paquetes SYN, ICMP o UDP, o de fragmentos SYN. El hacker puede seleccionar un host específico, como un enrutador o un servidor, o bien seleccionar hosts de forma aleatoria en la red atacada, lo que depende del objetivo del hacker y del nivel y éxito de los esfuerzos de prevención realizados hasta ese momento. Cualquiera de las dos tácticas tiene el potencial de distorsionar el servicio de un solo host o de la red completa, dependiendo de la importancia del papel que desempeña la víctima en el contexto de su red.

Inundaciones SYNEl problema de transmisión de inundaciones SYN se da cuando un host resulta tan sobrecargado con segmentos SYN que inicia peticiones de conexión irrealizables, por lo que le resulta imposible procesar peticiones de conexión legítimas.

Dos hosts establecen una conexión TCP con triple intercambio de paquetes TCP, conocido como un establecimiento de conexión en tres pasos: A envía un segmento SYN a B; B responde con un segmento SYN/ACK; A responde con un segmento ACK. Un ataque de inundaciones SYN sobrecarga un sitio con segmentos SYN que contienen direcciones IP de origen falsificadas (simuladas), es decir, inexistentes o inalcanzables. B responde enviando segmentos SYN/ACK a estas direcciones y espera segmentos ACK de respuesta. Debido a que los segmentos SYN/ACK se envían a direcciones IP inexistentes o inalcanzables, nunca responden y acaban por sobrepasar el tiempo de espera.

Figura 20: Ataque contra inundaciones SYN

Al enviar inundaciones a un host con conexiones TCP incompletas, el hacker 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.

SYN

SYN

SYN

SYN/ACK

SYN/ACK

SYN

SYN/ACK

SYN/ACK

IP real, 2.2.2.5

LAN protegida

3.3.3.5

El host en 2.2.2.5 envía segmentos SYN en paquetes IP con direcciones de origen simuladas.

Si una directiva permite el tráfico entrante, el dispositivo de seguridad permite los segmentos SYN. La víctima responde enviando segmentos SYN/ACK a la dirección IP simulada de origen, quedando a la espera de respuesta hasta que los intentos sobrepasan el tiempo de espera.

El búfer de memoria de la víctima empieza a llenarse.

Direcciones IP inexistentes o inalcanzables

4.4.4.20

5.5.5.10

6.6.6.3

Dirección

Ataques DoS contra la red 37


38

Protección contra inundaciones SYN

Los dispositivos de seguridad de Juniper Networks pueden imponer un límite por segundo al número de segmentos SYN a los que permite atravesar el cortafuegos. 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 de seguridad 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 Figura 21, se sobrepasó el umbral de ataque SYN y el dispositivo ha comenzado a procesar segmentos SYN a través del proxy.

Figura 21: Procesamiento de segmentos SYN a través del proxy

En la Figura 22, la cola de conexiones a través de un proxy se ha llenado totalmente y el dispositivo de seguridad rechaza nuevos segmentos SYN entrantes. Esta acción blinda los hosts de la red protegida contra el bombardeo de los establecimientos incompletos de conexiones en tres pasos.

.

.

.

Dirección IP real 2.2.2.5

LAN protegida

8.8.8.8

El host con la dirección 2.2.2.5 continúa enviando segmentos SYN en paquetes IP con direcciones de origen simuladas.

Cuando el número de segmentos SYN procedentes de una misma dirección de origen o dirigidos a la misma dirección de destino alcanza un umbral especificado, el dispositivo de seguridad comienza a interceptar las peticiones de conexión y a procesar los segmentos SYN/ACK mediante el proxy.

El búfer de memoria de la víctima deja de llenarse.

Direcciones IPinalcanzables o inexistentes

9.9.9.22

2.2.2.4

3.3.3.25 La cola de conexiones a través de un servidor proxy del dispositivo de seguridad comienza a llenarse.

— Umbral de ataque SYN —

SYN/ACK

SYN

SYN

SYN

SYN

SYN/ACK

SYN/ACK

SYN/ACK

7.7.7.11



Figura 22: Rechazo de nuevos segmentos SYN

El dispositivo de seguridad inicia la recepción de nuevos paquetes SYN cuando la cola del proxy cae por debajo del límite máximo.

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 pueden originarse inundaciones:

WebUI


SYN Flood Protection: (seleccione para habilitar)

.

.

.

Dirección IP real 2.2.2.5

LAN protegida

El host con la dirección 2.2.2.5 continúa enviando segmentos SYN en paquetes IP con la dirección de origen simulada 3.3.3.5.

El dispositivo de seguridad rechaza nuevos segmentos SYN de todas las direcciones de la misma zona de seguridad.

La cola de conexiones a través del servidor proxy del dispositivo de seguridad está llena.

Direcciones IP inexistentes o inalcanzables

3.3.3.5

Segmento SYN de otra dirección de la misma zona de seguridad.

— Umbral de ataque SYN —

El dispositivo de seguridad intercepta los segmentos SYN y procesa a través de un servidor proxy las respuestas SYN/ACK hasta que la cola de conexiones a través del servidor proxy se llena.

SYN

SYN

Dispositivo de seguridad

SYN/ACK

SYN/ACK

— Limite máximo de la cola de conexiones a través de un servidor proxy —

El dispositivo de seguridad introduce una alarma en el registro de eventos.

El búfer de memoria de la víctima recupera su estado normal.

SYN

— Umbral de alarma —

NOTA: El procedimiento de procesar a través de un servidor proxy las conexiones SYN incompletas por encima de un umbral establecido afecta solamente al tráfico permitido por las directivas existentes. Se descarta automáticamente cualquier tráfico para el que no exista una directiva.



40

Threshold: (introduzca el número de paquetes SYN (es decir, de segmentos TCP con el indicador SYN establecido) requeridos por segundo para activar el mecanismo de procesamiento de SYN a través de un servidor proxy).

Alarm Threshold: (introduzca el número de peticiones de conexión TCP a través de un servidor 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 de seguridad comience a rechazar nuevas peticiones de conexión de ese origen)

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 de seguridad comience a rechazar nuevas peticiones de conexión hacia ese destino)

Timeout Value: (introduzca la duración en segundos que el dispositivo de seguridad mantiene un intento de conexión TCP incompleto en la cola de conexiones a través de un servidor proxy)

Queue Size: (introduzca el número de peticiones de conexión TCP procesadas a través de un servidor proxy que se retienen en la cola de conexiones a través del servidor proxy antes de que el dispositivo de seguridad comience a rechazar nuevas peticiones de conexión)

CLI

Para habilitar la protección contra inundaciones SYN:

set zone zona screen syn-flood

Para procesar a través de un servidor proxy las peticiones de conexión TCP incompletas puede establecer los siguientes parámetros:

Attack Threshold: El número de segmentos SYN (es decir, segmentos TCP con el indicador SYN establecido) dirigidos a la misma dirección de destino y número de puerto requerido para activar el mecanismo de procesamiento de SYN a través de un servidor proxy. Aunque puede ajustar el umbral en cualquier número, debe 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/segundo. Si un sitio más pequeño recibe habitualmente 20 segmentos SYN por segundo, plantéese la posibilidad de establecer el umbral en 40.

set zone zona screen syn-flood attack-threshold número

NOTA: Para obtener más detalles acerca de cada uno de estos parámetros, consulte las descripciones en la siguiente sección de CLI.



Alarm Threshold: El número, por segundo, de peticiones de conexión TCP semicompletas a través del servidor proxy y que el dispositivo de seguridad espera para introducir una alarma en el registro de eventos. El valor establecido para un umbral de alarma activa una alarma cuando el número por segundo de peticiones de conexión incompletas y procesadas a través del servidor proxy 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 a través de un servidor proxy los 1000 segmentos SYN siguientes en el mismo segundo.

3. La 1001ª petición de conexión a través de un servidor proxy (o la 3001ª petición de conexión en ese mismo segundo) activa la alarma.

set zone zona 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 de seguridad comience a descartar peticiones de conexión de ese origen.

set zone zona screen syn-flood source-threshold número

Cuando se da seguimiento a inundaciones SYN por dirección de origen, se utilizan distintos parámetros de detección de los que se utilizan cuando hay inundaciones 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 según 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 de seguridad 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 zona screen syn-flood destination-threshold número



42

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 según sus destinos.

Cuando se da seguimiento a inundaciones SYN por su dirección de destino, se utilizan otros parámetros de detección distintos a los del seguimiento de inundaciones SYN por dirección y número de puerto de destino. Observe el caso siguiente, donde el dispositivo de seguridad tiene directivas que permiten realizar peticiones FTP (puerto 21) y peticiones HTTP (puerto 80) al mismo servidor. Si el umbral de ataque contra inundaciones SYN es de 1000 paquetes por segundo (pps) y un hacker envía 999 paquetes FTP y 999 paquetes HTTP por segundo, ninguno de ambos conjuntos de paquetes (conjunto que comparte la misma dirección y número de puerto de destino) activa el mecanismo de procesamiento de SYN a través de un servidor proxy. El mecanismo básico de ataque contra inundaciones 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 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 incompleta 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 conexión en tres pasos.

set zone zona screen syn-flood timeout número

Queue size: El número de peticiones de conexión a través de un servidor proxy que se pueden retener en la cola de conexiones a través de un servidor proxy antes de que el dispositivo de seguridad comience a rechazar nuevas peticiones de conexión. Cuanto mayor sea el tamaño de la cola, más tarda el dispositivo en analizar la cola para encontrar una respuesta ACK válida a una petición de conexión a través de un servidor 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 zona screen syn-flood queue-size número



Drop Unknown MAC: Cuando un dispositivo de seguridad detecta un ataque SYN, procesa a través de un servidor proxy todas las peticiones de conexión TCP. Sin embargo, un dispositivo en modo transparente no puede procesar a través de un servidor 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 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 zona screen syn-flood drop-unknown-mac

Ejemplo: Protección contra inundaciones SYNEn este ejemplo protegerá cuatro servidores web en la zona DMZ contra ataques de inundaciones SYN originados en la zona Untrust habilitando la opción SCREEN de protección contra inundaciones SYN para la zona Untrust.

Figura 23: Protección contra inundaciones SYN a nivel de dispositivo

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ípico. Durante una semana, ejecute un programa rastreador en 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 DMZ. 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

NOTA: Se recomienda aumentar la protección contra inundaciones SYN incorporada en el dispositivo de seguridad 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.

HTTP

Inundación SYN

Cortafuegos

Zona Untrust

ethernet31.1.1.1/24

ethernet21.2.2.1/24

Servidores Web

Zona DMZ

1.2.2.10

1.2.2.20

1.2.2.30


Internet

1.2.2.40



44

De acuerdo con esta información, establecerá los siguientes parámetros de protección contra inundaciones SYN para la zona Untrust como se muestra en la Tabla 2.

Tabla 2: Parámetros de protección contra inundaciones SYN

NOTA: Un programa rastreador es un dispositivo analizador de redes 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 que lleguen a ethernet3 con el indicador SYN establecido y estén destinados a uno de los cuatro servidores web en DMZ.

Posiblemente desee seguir 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, en algunas organizaciones, el tráfico puede aumentar espectacularmente durante eventos críticos. Si detecta cambios significativos, probablemente esté justificado ajustar los diferentes umbrales.

Parámetro Valor Motivo para cada valor

Attack Threshold (Umbral de ataque)

625 paquetes por segundo (pps)

Esto supera en un 25% a la cantidad de picos promedio de nuevas peticiones de conexión por segundo por servidor, algo inusual para este entorno de red. Cuando el número de paquetes SYN por segundo de cualquiera de los cuatro servidores web supera este número, el dispositivo comienza a procesar a través de un servidor proxy las nuevas peticiones de conexión dirigidas a ese servidor. (En otras palabras, comenzando por el paquete SYN 626° dirigido a la misma dirección y número de puerto de destino en un segundo, el dispositivo comienza a procesar a través de un servidor proxy las peticiones de conexión dirigidas a esa dirección y número de puerto).

Alarm Threshold (Umbral de alarma)

250 pps 250 pps es 1/4 del tamaño de la cola (1000 peticiones de conexión incompletas y procesadas a través de un servidor proxy1). Cuando el dispositivo procesa a través de un servidor proxy 251 nuevas peticiones de conexión en un segundo, se genera una entrada de alarma en el registro de eventos. Al aumentar 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 Threshold (Umbral de origen)

25 pps Cuando se establece un umbral de origen, el dispositivo rastrea la dirección IP de origen de los paquetes SYN, sin importar la dirección y el número de puerto de destino. (Observe que este seguimiento según los orígenes es independiente del seguimiento de paquetes SYN en base a 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 ejecute su mecanismo de procesamiento a través de un servidor proxy. (25 pps es 1/25 del umbral de ataque, que es de 625 pps.)

Si el dispositivo 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 Threshold (Umbral de destino)

0 pps Cuando se establece un umbral de destino, el dispositivo ejecuta un seguimiento separado solamente de la dirección IP de destino, sin importar el número de puerto de destino. Debido a que los cuatro servidores web reciben solamente tráfico HTTP (puerto de destino 80), 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).



WebUI

1. InterfacesNetwork > Interfaces > Edit (para ethernet2): Introduzca los siguientes datos y haga clic en OK:





Address Name: ws1IP Address/Domain Name:

IP/Netmask: (seleccione), 1.2.2.10/32Zone: DMZ




Timeout (Tiempo de espera)

20 segundos Dado que el tamaño de la cola es relativamente pequeño (1000 peticiones de conexión procesadas a través de un servidor proxy), el valor predeterminado de 20 segundos es un tiempo razonable para mantener las peticiones de conexión incompletas en cola para esta configuración.

Queue Size (Tamaño de la cola)

1000 conexiones incompletas y procesadas a través de un servidor proxy

1000 peticiones de conexión incompletas y procesadas a través de un servidor proxy es dos veces el promedio de picos de nuevas peticiones de conexión (500 pps). El dispositivo procesa a través de un servidor proxy hasta 1000 peticiones por segundo antes de descartar nuevas peticiones. Procesar a través de un servidor 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.

1.Las peticiones de conexión incompletas son establecimientos de conexión en tres pasos que no están completos. Un establecimiento de conexión en tres pasos es la fase inicial de una conexión TCP. Consiste en un segmento TCP con el indicador SYN establecido, una respuesta con los indicadores SYN y ACK establecidos y una respuesta a ésta con el indicador ACK establecido.

Parámetro Valor Motivo para cada valor



46







Policy > Policy Elements > Addresses > Groups > (for 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. DirectivaPolicies > (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: HTTPAction: Permit

4. ScreenScreening > Screen (Zone: Untrust): Introduzca los siguientes datos, luego haga clic en Apply:

SYN Flood Protection: (seleccione)Threshold: 625Alarm Threshold: 250Source Threshold: 25Destination Threshold: 0Timeout Value: 20Queue Size: 1000



CLI

1. Interfacesset interface ethernet2 zone dmzset interface ethernet2 ip 1.2.2.1/24set interface ethernet3 zone untrustset interface ethernet3 ip 1.1.1.1/24

2. Direccionesset address dmz ws1 1.2.2.10/32set address dmz ws2 1.2.2.20/32set address dmz ws3 1.2.2.30/32set address dmz ws4 1.2.2.40/32set group address dmz web_servers add ws1set group address dmz web_servers add ws2set group address dmz web_servers add ws3set group address dmz web_servers add ws4

3. Directivaset policy from untrust to dmz any web_servers HTTP permit

4. Screenset zone untrust screen syn-flood attack-threshold 625set zone untrust screen syn-flood alarm-threshold 250set zone untrust screen syn-flood source-threshold 25set zone untrust screen syn-flood timeout 20set zone untrust screen syn-flood queue-size 1000set zone untrust screen syn-floodsave

Cookie SYNUna cookie SYN es un mecanismo de procesamiento de SYN a través de un servidor proxy sin estado, que se puede utilizar junto con las defensas contra un ataque de inundaciones SYN, como el que se describe en “Inundaciones SYN” en la página 37. Al igual que los procesamientos tradicionales de SYN a través de un servidor proxy, cookie SYN se activa cuando un umbral de ataque contra inundaciones SYN se excedió, pero debido a que cookie SYN no tiene un estado, éste no configura una sesión o realiza consultas de rutas y direcivas al recibir un segmento SYN y no mantiene ninguna cola de petición de conexión. Lo que reduce enormemente el uso de la CPU y de la memoria y es el beneficio principal de utilizar cookie SYN en lugar del mecanismo de procesamiento tradicional de SYN a través de un servidor proxy.

NOTA: 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.

NOTA: 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.



48

Cuando está habilitada cookie SYN en el dispositivo de seguridad y se convierte en el procesamiento de negociación de TCP a través de un servidor proxy para el servidor de destino, éste responde a cada segmento SYN entrante con un SYN/ACK que contiene una cookie encriptada como su número de secuencia inicial (ISN). La cookie es un hash MD5 de la dirección de origen original y el número de puerto, dirección de destino y número de puerto y el ISN del paquete SYN original. Después de enviar la cookie, el dispositivo descarta el paquete SYN original y borra la cookie calculada a partir de la memoria. Si no se recibe ninguna respuesta del paquete que contiene la cookie, el ataque se detecta como un ataque SYN activo y se detiene de forma efectiva.

Si el host iniciador responde con un paquete TCP que contiene cookie +1 en el campo TCP ACK, el dispositivo extrae la cookie, resta uno del valor y vuelve a calcular la cookie para validar que ésta es una ACK legítima. De ser legítima, el dispositivo inicia el proceso TCP a través del servidor proxy al ajustar una sesión y enviar un SYN al servidor que contiene la información de origen del SYN original. Cuando el dispositivo recibe un SYN/ACK del servidor, éste envía los ACK al servidor y al host de inicio. En este momento, se establece la conexión, de modo que el host y el servidor pueden comunicarse directamente.

La Figura 24 muestra cómo se establece una conexión entre un host de inicio y un servidor cuando una cookie SYN está activa en el dispositivo de seguridad.

Figura 24: Establecimiento de una conexión con la cookie SYN activa

33

7

1

5

4

6

9

5

2

8

Host TCP Servidor TCP

Conectado

Envío de ACK

1. Aceptar conexión 2. Envar SYN/ACK

SYN

SYN/ACK

SYN/ACK

ACK

Data/ACK

ACK

SYN

ACK

Data/ACK

1. Consulta de sesiones -- Sin coincidencia de sesión

2. Cookie SYS validada3. Restablecimiento de MSS 4. Primer paquete aprobado--enrutamiento,

consulta de directivas, configuración de sesión5. Envío de SYN al servidor

1. Consulta de sesiones -- Sin coincidencia de sesión

2. Cookie SYN activada3. Cálculo de ISN4. Envío de SYN/ACK al host

Envío de ACK a ambos extremos




Para habilitar una cookie SYN, establezca un umbral de ataque de inundaciones SYN (como se describe en “Inundaciones SYN” en la página 37), y ejecute uno de los siguientes pasos:

WebUI

Configuration > Advanced > Flow: Introduzca los siguientes datos, luego haga clic en Apply:

TCP SYN-proxy SYN-cookie: (seleccione)

CLI

set flow syn-proxy syn-cookie

Inundaciones ICMPLas inundaciones de ICMP normalmente se producen cuando las peticiones de eco ICMP sobrecargan a su víctima con tantas peticiones que ésta consume todos sus recursos para 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 inundaciones ICMP. (El valor predeterminado del umbral es 1000 paquetes por segundo). Si se excede este umbral, el dispositivo de seguridad ignora otras peticiones de eco ICMP durante el resto de ese segundo y también durante el segundo siguiente.

NOTA: Las inundaciones ICMP pueden contener cualquier tipo de mensaje ICMP. Por lo tanto, un dispositivo de seguridad de Juniper Networks supervisa todos los tipos de mensajes ICMP, no únicamente las peticiones de eco.



50

Figura 25: Inundaciones ICMP

Para habilitar la protección contra inundaciones ICMP, ejecute cualquiera de los siguientes procedimientos, donde la zona especificada es aquélla en la que pueden originarse inundaciones:

WebUI


ICMP Flood Protection: (seleccione)Threshold: (introduzca el valor a partir del cual debe activarse la

protección contra inundaciones ICMP)

CLI

set zone zona screen icmp-flood threshold númeroset zone zona screen icmp-flood

.

.

.

El dispositivo de seguridad deja pasar las peticiones de eco sólo si alguna directiva lo permite.

LAN protegida

Petición de eco ICMP legítima de una dirección en la misma zona de seguridad

Respuesta de eco

Una vez alcanzado el umbral de ICMP, el dispositivo de seguridad rechaza las peticiones de eco ICMP subsiguientes que provienen de todas las direcciones de la misma zona de seguridad durante el resto del segundo actual y también durante el segundo siguiente.

El hacker envía peticiones de eco ICMP con direcciones de origen simuladas.

Petición de eco

Respuesta de eco

Respuesta de eco

Petición de eco

Petición de eco

Petición de eco

Petición de eco

Peticiones de eco ICMP procedentes de diversas direcciones IP simuladas

— Límite máximo de peticiones de eco ICMP por segundo —

NOTA: La unidad de este valor se expresa en paquetes ICMP por segundo. El valor predeterminado es de 1000 paquetes por segundo.



Inundaciones UDPDe forma parecida a la transmisión de inundaciones ICMP, las inundaciones UDP se dan cuando un hacker 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, cuando se excede, activa la función de protección contra ataques de inundaciones 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 de seguridad ignora los datagramas UDP subsiguientes dirigidos a ese destino durante el resto de ese segundo y también durante el segundo siguiente.

Figura 26: Inundaciones UDP

Para habilitar la protección contra inundación de UDP, ejecute cualquiera de los siguientes procedimientos, donde la zona especificada es aquélla en la que puede originarse una inundación:

WebUI


UDP Flood Protection: (seleccione)Threshold: (introduzca el valor a partir del cual debe activarse la

protección contra inundaciones UDP)

El dispositivo de seguridad deja pasar los datagramas UDP sólo si alguna directiva lo permite.

Servidor DNSIP: 1.2.2.5

Puerto: 53 (UDP)

Datagrama UDP legítimo desde una dirección de la misma zona de seguridad

Una vez alcanzado el umbral de inundación de UDP, el dispositivo NetScreen rechaza los datagramas UDP subsiguientes provenientes de todas las direcciones de la misma zona de seguridad durante el resto del segundo actual y también durante el segundo siguiente.

El hacker envía datagramas UDP en paquetes IP con direcciones de origen simuladas.

LAN protegidaDatagrama UDP

Datagrama UDP

Datagramas UDP dentro de los paquetes IP procedentes de varias direcciones IP simuladas

— Límite máximo de datagramas UDP por segundo —

Los datagramas apuntan a un servidor DNS en 1.2.2.5:53.

Datagrama UDP

Datagrama UDP

Datagrama UDP

NOTA: La unidad de este valor se expresa en paquetes UDP por segundo. El valor predeterminado es de 1000 paquetes por segundo.



52

CLI

set zone zona screen udp-flood threshold númeroset zone zona screen udp-flood

Ataque terrestreAl combinar un ataque SYN con la simulación de direcciones IP, un ataque terrestre (land attack) ocurre cuando un hacker envía paquetes SYN simulados 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. Al saturar un sistema con tales conexiones vacías puede sobrecargarlo y provocar la denegación de servicio.

Figura 27: Ataque terrestre

Cuando se habilita la opción SCREEN para bloquear ataques terrestres, el dispositivo de seguridad combina elementos de la defensa contra inundaciones de SYN y de la protección contra la simulació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, después haga clic en Apply.

CLI

set zone zona screen land

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

Tanto la dirección de origen como la de 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 de origen verdadera permanece oculta.

Origen

Víctima

La víctima crea conexiones vacías consigo misma.

Destino

Datos1.2.2.5

Hacker

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

Los recursos disponibles de la víctima

Destino

Destino

Origen

Origen

Datos

Datos

1.2.2.5

1.2.2.5 1.2.2.5

1.2.2.51.2.2.5




Si un hacker 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 de seguridad de Juniper Networks protege a hosts susceptibles a estos ataques, puede habilitar el dispositivo de seguridad para detectar dichos ataques y bloquearlos antes de que alcancen su destino.

Ping of DeathEl tamaño máximo del paquete IP admisible es de 65.535 bytes, incluyendo el encabezado del paquete, que normalmente tiene una longitud de 20 bytes. Una solicitud de eco ICMP es un paquete IP con un encabezado falso, de 8 bytes de longitud. Por lo tanto, el tamaño máximo admisible del área de datos de una solicitud 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 de servicio (DoS), caídas, bloqueos y reinicios.

Al habilitar la opción SCREEN “Ping of Death”, el dispositivo de seguridad detecta y rechaza esos paquetes sobredimensionados e irregulares incluso cuando el hacker oculta el tamaño total del paquete fragmentándolo intencionalmente.

Figura 28: Ping of Death

NOTA: Para obtener más información acerca de las especificaciones de IP, consulte la norma RFC 791, Protocolo de Internet.

Para obtener más información acerca de las especificaciones de IP, consulte la norma RFC 792, Protocolo de mensajes de control de Internet.

Para obtener más información acreca del ping of death, consulte http://www.insecure.org/sploits/ping-o-death.html.

El tamaño de este paquete es de 65.538 bytes. Supera el límite de tamaño estipulado en la norma RFC 791, Protocolo de Internet, que es de 65.535 bytes. Durante la transmisión, el paquete se divide en numerosos fragmentos. Durante el proceso de reensamblaje, el sistema receptor puede quedarse colgado.

Paquete original no

fragmentadoEncabezado IP Encabezado

ICMP Datos ICMP

65.510 bytes8 bytes20 bytes

Ataques de DoS específicos de cada sistema operativo 53

http://www.insecure.org/sploits/ping-o-death.html

http://www.insecure.org/sploits/ping-o-death.html


54

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, después haga clic en Apply.

CLI

set zone zona screen ping-death

Ataque TeardropLos 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.

Figura 29: Ataques Teardrop

Cuando la suma del desplazamiento más la longitud de un paquete fragmentado es distinta a la del siguiente paquete fragmentado, los paquetes se superponen y el servidor que intenta reensamblarlos puede quedarse colgado, especialmente si está ejecutando un sistema operativo antiguo que tenga esta vulnerabilidad.

Encabezado IPEl dispositivo de seguridad comprueba si existen discrepancias en el campo de desplazamiento del fragmento.

VersiónLongitud del Tipo de servicio Longitud total del paquete (en bytes)

Identificación

Tiempo de vida (TTL) Protocolo Suma de comprobación del encabezado20

bytes





Carga de datos

x D M



Figura 30: Discrepancia entre fragmentos

Una vez habilitada la opción SCREEN “Teardrop Attack”, siempre que el dispositivo 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, después haga clic en Apply.

CLI

set zone zona screen tear-drop

WinNukeWinNuke es un ataque de denegación de servicio que se dirige a cualquier equipo conectado a Internet que ejecute Windows. El hacker envía un segmento TCP, normalmente al puerto 139 de NetBIOS con el indicador (URG) establecido, a un host con una conexión establecida. Esto introduce una superposición de fragmentos NetBIOS, que en muchos equipos Windows provoca la caída del sistema. Después de reiniciar el equipo atacado, aparece el siguiente mensaje para indicar que se ha producido un ataque:

An exception OE has occurred at 0028:[address] in VxD MSTCP(01) +000041AE. This was called from 0028:[address] in VxD NDIS(01) + 00008660. It may be possible to continue normally.

Press any key to attempt to continue.

Press CTRL+ALT+DEL to restart your computer. You will lose any unsaved information in all applications.

Press any key to continue.

20 bytes

Paquete fragmentado nº 1

El segundo fragmento pretende comenzar 20 bytes antes (en 800) del final del primer fragmento (en 820). El desplazamiento del fragmento nº 2 no concuerda con la longitud del paquete del fragmento nº 1. Esta discrepancia puede hacer que algunos sistemas se queden colgados al intentar el reensamblaje.

800 bytes

Datos

Paquete fragmentado nº 2

Encabezado IP

Desplazamiento = 0Longitud = 820Más fragmentos = 1

20 bytes

Desplazamiento = 800Longitud = 620Más fragmentos = 0

600 bytes

DatosEncabezado IP

Ataques de DoS específicos de cada sistema operativo 55


56

Figura 31: Indicadores de un ataque WinNuke

Con la opción SCREEN de defensa contra ataques WinNuke habilitada, el dispositivo de seguridad analiza cualquier paquete entrante del servicio de sesiones de Microsoft NetBIOS (puerto 139). Si el dispositivo detecta que el indicador URG está activado en alguno de esos paquetes, lo desactiva, borra el indicador URG, redirecciona 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, después haga clic en Apply.

CLI

set zone zona screen winnuke

Tamaño de la ventana

El puerto de destino es el 139.

Número del puerto de origen

Longitud del encabezado

Número de secuencia

Puerto de destino: 139

Reservado

Número de reconocimiento

Encabezado TCP

Indicador “Urgente”


Datos (si los hay)

URG

Suma de comprobación de TCP

ACK

PSH

RST

SYN

FIN

El indicador URG está establecido.


Capítulo 4

Supervisión y filtrado de contenidos

Juniper Networks proporciona amplia protección y control de la actividad de red por medio de funciones de ScreenOS y de la combinación de ScreenOS con productos Websense, SurfControl y Kaspersky Lab.

En este capítulo se describe cómo se ha de configurar el dispositivo 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 58

“Protección contra URL maliciosas” en la página 58

“Puerta de enlace en la capa de aplicación” en la página 59

“Análisis antivirus” en la página 62

“Análisis AV externo” en la página 62

“Análisis AV interno” en la página 64

“Análisis AV basado en directivas” en la página 71

“Análisis de protocolos de aplicación” en la página 72

“Actualización de los archivos de patrones AV para el analizador incorporado” en la página 81

“Ajustes globales del analizador de AV” en la página 84

“Perfiles de AV” en la página 88

“Filtrado anti spam” en la página 95

“Filtrado de Web” en la página 100

“Filtrado de Web integrado” en la página 101

“Redireccionamiento del filtrado de Web” en la página 110

57


58


Normalmente, el dispositivo de redireccionamiento de la red, como el conmutador o enrutador, no reensambla los paquetes fragmentados que recibe. Generalmente es el host de destino el que reconstruye los paquetes fragmentados cuando los recibe. La función principal de un dispositivo de redireccionamiento es la distribución eficiente del tráfico. En el caso de que el dispositivo de redireccionamiento necesite también poner en cola, reensamblar y refragmentar todos los paquetes, su eficiencia se verá seriamente afectada. 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 de seguridad puede ampliar su habilidad para detectar y bloquear cadenas URL maliciosas. El reensamblaje de fragmentos se aplica únicamente para el tráfico que tiene habilitada la opción de puerta de enlace en la capa de aplicación (Application Layer Gateway, ALG) si el dispositivo está configurado para NAT.

Protección contra URL maliciosasAdemás de la función de filtrado de Web (que se explica en “Redireccionamiento del filtrado de Web” en la página 110), puede 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 a nivel de zonas. Si la función de bloqueo de URL maliciosas está habilitada, el dispositivo de seguridad 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 el patrón que definió, el dispositivo bloquea el paquete, impidiendo que pase a través del cortafuegos.

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 de seguridad 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.


Capítulo 4: Supervisión y filtrado de contenidos

No obstante, al reensamblar los paquetes, los fragmentos se combinan formando una cadena que el dispositivo puede identificar y bloquear. Gracias a la función de reensamblaje de fragmentos, el dispositivo 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 lleva a cabo uno de los siguientes pasos:

Si el dispositivo descubre una URL maliciosa, descarta el paquete e indica el evento en el registro.

Si el dispositivo 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 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 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ónScreenOS ofrece una puerta de enlace en la capa de aplicación (ALG) para una serie de protocolos, como DNS, FTP, H.323 y 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 Juniper Networks 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, es posible que exista una directiva que rechace Ftp-Put de las zonas Untrust a DMZ:

set policy from untrust to dmz any any ftp-put deny

Si el dispositivo de seguridad encuentra STOR nombre_archivo, el cliente ha enviado una solicitud para almacenar el archivo especificado en el servidor y el dispositivo bloqueará el paquete.

En una directiva de permiso, Ftp-Get, Ftp-Put y Ftp son servicios diferentes. Por ejemplo, es posible que exista una directiva que permita Ftp-Put de las zonas Untrust a DMZ.

set policy from untrust to dmz any any ftp-get permit

Si el contenido es RETR nombre_archivo, el cliente FTP ha enviado una solicitud para recuperar el archivo especificado desde el servidor FTP y el dispositivo permitirá el paso del paquete.

NOTA: Para una directiva de rechazo, el servicio FTP-Put, Ftp-Get y FTP se comporta de la misma manera bloqueando todos los paquetes.

Reensamblaje de fragmentos 59


60

Si tiene dos directivas, una que deniegue el FTP-Put desde las zonas Untrust a las zonas DMZ y otra que permita el FTP-Get desde las zonas Untrust a las zonas DMZ, el dispositivo bloqueará el paquete.

set policy from untrust to dmz any any ftp-put denyset policy from untrust to dmz any any ftp-get permit

Para burlar este tipo de defensa, un hacker puede fragmentar deliberadamente un paquete FTP-put en dos paquetes que contengan el siguiente texto en sus respectivas cargas:

paquete 1: ST

paquete 2: OR nombre_archivo.

Cuando el dispositivo de seguridad inspecciona cada paquete de forma individual, no encuentra la cadena STOR nombre_archivo, por lo que permite el paso de ambos paquetes.

No obstante, al reensamblarlos, los fragmentos se combinan formando una cadena que el dispositivo de seguridad puede identificar y bloquear. Gracias a la función de reensamblaje de fragmentos, el dispositivo 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 lleva a cabo uno de los siguientes pasos:

Si el dispositivo descubre una solicitud FTP-Put, descarta el paquete e indica el evento en el registro.

Si el dispositivo 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 descubre una solicitud FTP-Get pero el paquete reensamblado es demasiado grande para redireccionarlo, vuelve a fragmentar el paquete y redirecciona los fragmentos.

Si el dispositivo descubre una solicitud FTP-Get y no es necesario fragmentarla, redirecciona el paquete directamente.

Ejemplo: Bloquear URL maliciosas en paquetes fragmentadosEn este ejemplo, definiremos tres cadenas de URL maliciosas y habilitaremos la opción de bloqueo de URL maliciosa:

URL maliciosa 1

ID: Perl

Patrón: scripts/perl.exe

Longitud: 14



URL maliciosa 2

ID: CMF

Patrón: cgi-bin/phf

Longitud: 11

URL maliciosa 3

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 una URL, comenzando por el primer carácter, para que se considere una coincidencia. Observe que en las URL 1 y 3, 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

Security > Screening > Mal-URL (Zone: Untrust): Introduzca los siguientes datos y haga clic en OK:

ID: perlPattern: scripts/perl.exeLength: 14


ID: cmfPattern: cgi-bin/phfLength: 11


ID: dllPattern: 210.1.1.5/msadcs.dllLength: 18

Network > Zones > Edit (para Untrust): Seleccione la casilla de verificación TCP/IP Reassembly for ALG y a continuación, haga clic en OK.

CLI

set zone untrust screen mal-url perl “scripts/perl.exe” 14set zone untrust screen mal-url cmf “cgi-bin/phf” 11set zone untrust screen mal-url dll “210.1.1.5/msadcs.dll” 18set zone untrust reassembly-for-algsave

Reensamblaje de fragmentos 61


62

Análisis antivirus

Un virus es un código ejecutable que infecta o se adjunta a otro código ejecutable que le permite reproducirse. Algunos virus maliciosos borran los archivos o bloquean los sistemas, mientras que otros virus actúan infectando los archivos y pueden saturar el host o la red con datos fantasmas.

Juniper Networks admite análisis antivirus (AV) interno y externo en determinados dispositivos de seguridad. Consulte las notas de la versión de ScreenOS para obtener una lista de dispositivos de seguridad y del motor de análisis antivirus que admite.

Dispone de las siguientes dos soluciones antivirus disponibles para la serie de productos ISG:

Análisis antivirus de protocolo de adaptación de contenido de Internet (Internet Content Adaptation Protocol, ICAP)

Utilice esta solución para velocidades más bajas, tal como en las implementaciones T-3 o T-3 fraccionadas. Para obtener más detalles, consulte “Análisis AV externo” en página 62.

Enrutamiento según directivas (PBR)

Utilice esta solución para velocidades más altas, tal como en implementaciones OC-3. En este escenario, PBR en ISG descarga un tráfico específico a un dispositivo de seguridad de gama alta y pone en funcionamiento el analizador antivirus incorporado. Para obtener más información sobre esta configuración, consulte “Ejemplo de PBR avanzado” en la página 7-150. Para obtener más información sobre el analizador antivirus incorporado, consulte “Análisis AV interno” en página 64.

Análisis AV externoSe realiza un análisis AV cuando el dispositivo de seguridad desvía el tráfico hacia un servidor de análisis AV ICAP externo. El cliente ICAP en el dispositivo de seguridad se comunica con el servidor de análisis ICAP para proporcionar las siguientes funciones:

Admite ICAP v1.0 y es totalmente compatible con RFC 3507

Admite el servidor ICAP Symantec Scan Engine 5.0

Análisis antivirus ampliable (agrega servidores de análisis ICAP adicionales)

Múltiples dispositivos de seguridad (cortafuegos) comparten el mismo servidor de análisis ICAP

Tráfico de carga equilibrada entre un conjunto de servidores ICAP

Encapsulado de tráfico HTTP y SMTP

Admite un mensaje HTML personalizado para el tráfico HTTP

Admite un encabezado de respuesta-x personalizado

Análisis antivirus


Admite una conexión persistente con el mismo servidor ICAPUna conexión persistente reduce la carga de procesamiento y mejora el rendimiento del análisis AV.

La Figura 32 ilustra cómo funciona el análisis AV externo con el dispositivo de seguridad.

Figura 32: Cómo funciona el análisis externo

Modos de análisisUna vez que el tráfico ha pasado el análisis antivirus, el servidor ICAP que ejecuta Symantec Scan Engine 5.0 proporciona uno de los siguientes resultados:

Scan only. Deniega el acceso al archivo infectado pero no ejecuta ninguna acción en el archivo.

Scan and delete. Elimina todos los archivos infectados, incluyendo los que están incorporados a archivos de almacenamiento definitivo, sin intentar repararlos.

Scan and repair files. Intenta reparar los archivos infectados pero no ejecuta ninguna otra acción sobre aquellos que no pueden repararse.

Scan and repair or delete. Intenta reparar los archivos infectados y elimina de los archivos de almacenamiento definitivo cualquier archivo irrecuperable.

Consulte la documentación del servidor ICAP para obtener más información acerca del comportamiento y los resultados del análisis.

H A

F L A S H

PW R

FA N

A L A R M

M O D 1

T E M P

M O D 2

S TAT U S

M O D 3 ISG 2000

Dispositivo de seguridad de Juniper Networks

Cliente ICAP

Zona Trust

Servidor FTP remoto

Zona Untrust

Servidores ICAP que ejecutan Symantec scan engine 5.0

1. Un cliente establece una sesión HTTP o SMTP.

2. El perfil AV en el dispositivo de seguridad determina si los datos deben enviarse a análisis antivirus.

3. Si se configura el análisis, se establece una conexión entre el cortafuegos y un servidor ICAP escogido dentro del grupo de servidores de análisis ICAP.

4. El cliente ICAP envía los datos a analizar (en formato ICAP encapsulado) al servidor ICAP y conserva los datos en la memoria hasta que el servidor ICAP acusa recibo de ellos.

5. El servidor ICAP devuelve al cliente ICAP los resultados del análisis con el contenido completo.

• Si no se detecta ningún virus, el tráfico se envía a su destino.

• Si se detecta un virus, los datos se reemplazan y se notifica al destino. En el caso de HTTP, los datos se reemplazan con un mensaje HTML personalizado. Si no se proporciona un mensaje HTML personalizado, se crea un evento en el registro para grabar información sobre el virus.

Servidores HTTP/SMTPremotos

Análisis antivirus 63


64

Servidores de análisis ICAP de equilibrio de cargaEl análisis AV externo de ScreenOS 5.4 permite el equilibrio de carga de los servidores de análisis ICAP que se han configurado en un grupo de servidores ICAP. El algoritmo de equilibrio de carga utilizado entre los servidores de análisis ICAP en el grupo es el menos requerido. Los servidores ICAP mantienen un equilibrio de carga que se basa en el estado funcional del servidor y en el volumen de tráfico (número de solicitudes pendientes). Se omiten los servidores en mal estado funcional y el tráfico se reduce automáticamente al servidor sobrecargado.

Un servidor ICAP configurado puede encontrarse en estado habilitado o deshabilitado. El estado de un servidor ICAP activo puede ser en servicio o fuera de servicio. Cuando un servidor de ICAP está configurado como desactivado, entonces el servidor no se utiliza para servir nuevas peticiones.

Los servidores de ICAP se supervisan a través de un mecanismo de prueba. Por ejemplo, si un intervalo de sondeo se ajusta a 30, un servidor ICAP habilitado se somete a un sondeo automático cada 30 segundos para determinar su estado (en servicio o fuera de servicio).

Un sondeo automático devuelve un resultado de fuera de servicio en las siguientes condiciones:

El cortafuegos no puede establecer una conexión TCP exitosa a un servidor ICAP

Licencia AV del servidor ICAP inválida

Respuesta de error del extremo del cliente a una solicitud de opciones ICAP

Respuesta de error del extremo del servidor a una solicitud de opciones ICAP

El servidor queda fuera de servicio cuando fallan tres sondeos consecutivos.

Análisis AV internoEl análisis AV interno se realiza cuando el motor de análisis del dispositivo de seguridad analiza el tráfico en busca de virus. El motor de análisis incorporado o interno es un motor de análisis Juniper-Kaspersky.

El motor de análisis incorporado permite realizar lo siguiente:

Habilitar/inhabilitar el análisis según la extensión del archivo y el tipo de contenido

Por ejemplo, puede configurar un perfil que admita el análisis de archivos ejecutables (.exe) pero no el análisis de los archivos de documentos (.doc o .pdf)

NOTA: El analizador AV interno requiere que instale una licencia AV en su dispositivo de seguridad. La licencia AV no es necesaria si utiliza un analizador AV externo.

Análisis antivirus


Configurar las capas de descompresión para protocolos de aplicación específica

En cada perfil puede configurar diferentes niveles de descompresión para cada protocolo (HTTP/SMTP/POP3/IMAP/FTP). Según el entorno de red, por ejemplo, podría desear especificar el número de archivos comprimidos incorporados que se desempaquetarán para cada protocolo.

Configurar el análisis de AV para el tráfico de mensajería instantánea (IM)

Para obtener más información sobre el tráfico de análisis de IM, consulte “Análisis AV del tráfico de IM” en la página 66.

Configurar la notificación por correo electrónico al remitente/receptor cuando se detectan virus y se analizan errores

Configurar los niveles de análisis para proporcionar protección contra spyware y phishing

El motor de análisis Juniper-Kaspersky, de forma predeterminada, proporciona el nivel más alto de seguridad. Además de detener todos los virus (incluso los virus polimórficos y otros avanzados), este motor de análisis proporciona también protección contra el spyware y phishing entrante.

Protección contra spyware. La función de protección contra spyware agrega otra capa de protección a las soluciones anti-spyware y anti-adware de Juniper Networks al permitir que bloquee el spyware, adware, registradores de teclado y malware relacionado entrante para evitar que el tráfico malicioso entre a su empresa.

Esta solución complementa los productos de detección y prevención (IDP) de Juniper Networks, lo cual proporciona protección de teléfono-casa de spyware (eso significa que evita que el spyware envíe datos sensibles si su laptop/computadora de escritorio/servidor están infectados).

Protección contra phishing. La función de protección contra “phishing” le permite bloquear los correos electrónicos que intentan atraer a los usuarios a sitios falsos (phishing) que roban datos importantes de éstos.

Puede cambiar el nivel de seguridad predeterminado de búsqueda al seleccionar una de las siguientes dos opciones:

Basic in-the-wild scanning. Este nivel de análisis administra un grado inferior de seguridad mediante el análisis de los virus más prevalentes, aunque mejora el rendimiento del sistema. Para habilitar el análisis básico preventivo, introduzca el siguiente comando:

set av scan-mgr pattern-type itw

Extended scanning. Este nivel de análisis tradicionalmente incluye más partes ruidosas de spyware/adware que el análisis estándar. Éste proporciona más cobertura de spyware pero potencialmente puede devolver más positivos falsos. Para activar el análisis extendido, introduzca el siguiente comando:

set av scan-mgr pattern-type extended



66

La opción estándar (set av scan-mgr pattern-type standard) es la opción predeterminada.

Análisis AV del tráfico de IM Una red de mensajería instantánea (IM) está compuesta de clientes y servidores, junto con los protocolos necesarios para conectarlos.

Clientes de IMCada cliente de IM tiene tres componentes principales:

Una lista de amigos y otro registro de amigos con los que desea comunicarse.

Una ventana separada que muestra los chats de texto en curso, los usuarios escriben sus mensajes y ven las respuestas correspondientes en esta ventana.

Las funciones adicionales para los chats de vídeo y audio y para las transferencias de archivo entre usuarios.

Todos los clientes principales de IM son más que simples chats de texto y cada vez incluyen comunicaciones más integradas y sofisticadas, incluso llamadas en tiempo real de voz y vídeo.

ScreenOS admite el análisis de las aplicaciones de IM públicas y populares como:

AOL Instant Messenger (AIM)

I Seek You (ICQ)

Yahoo! Messenger (YMSG)

MSN Messenger

Las funciones de análisis en esta versión de ScreenOS se aplican a los siguientes servicios de IM:

Mensaje de chat de texto

Mensaje de chat de grupo

Transferencia de archivos/distribución de archivos

NOTA: Se debe utilizar la CLI para modificar el nivel de seguridad de análisis predeterminado.

Análisis antivirus


Servidor de IMEl servidor de IM mantiene el directorio de cuentas de usuario, da seguimiento de quién está en línea y, en la mayoría de los casos, enruta mensajes entre los usuarios. El servidor de IM funciona en tiempo real, enviando mensajes de una parte a otra entre dos usuarios cuando terminan de escribir cada línea de texto. Los servidores también pasan información en tiempo real sobre la disponibilidad de varios usuarios en el directorio, como cuándo están en línea y cambian su mensaje de estado.

Cada servidor de IM se comunica con sus clientes sobre un número de puerto asignado a través de Internet. Sin embargo, los clientes de IM pueden iniciar sesión con otros puertos cuando el puerto predeterminado está bloqueado por una directiva de rechazo. Los números de puerto típicos incluyen aquellos que se muestran en la siguiente tabla:

Protocolos de IMLa red de IM emplea un modelo de cliente-servidor para la autenticación al servicio y para la comunicación con otros clientes utilizando los protocolos que se muestran en la siguiente tabla:

Aplicación de im Números de puerto de servicio Proxies

AIM 5190 SOCKS 4, SOCKS 5, HTTP, HTTPS

ICQ 5190

YMSG 50501 (443 y 80)

1. Además del puerto 5050, asegúrese de que esté permitido el tráficoen los puertos 443 (HTTPS) y 80 (HTTP).

SOCKS 4, SOCKS 5, HTTP

MSN Messenger 1863 SOCKS 4, SOCKS 5, HTTP

NOTA: El análisis de AV no es compatible para la comunicación de tráfico de AIM o ICQ en un formato codificado.

Aplicación de IM Protocolos admitidos

AIM/ICQ Sistema abierto para la comunicación en el protocolo en tiempo real (OSCAR)

YMSG Protocolo de puerta de enlace de servicio de Yahoo Messenger (YMSG)

MSN Messenger Protocolo de notificación de estado móvil (MSNP)



68

Debido a que el protocolo específico de las aplicaciones de IM respectivas se actualiza constantemente, ScreenOS proporciona un parámetro configurable para controlar el comportamiento del cortafuegos. Consulte las Notas de la versión del producto para la versión del protocolo y cliente admitido. Sin embargo, ScreenOS procesa el tráfico para las versiones que no se admiten del protocolo en una de las siguientes dos maneras:

Mejor esfuerzo: Utiliza el conocimiento del protocolo existente para procesar el tráfico

Pasar: Pasa el tráfico sin analizarlo

Aspectos de seguridad de la mensajería instantáneaGeneralmente, los gusanos se propagan sobre los servicios de mensajería instantánea y aparece como una URL. Se accede a estos URL debido a que parecen ser de alguien que está en la lista de “amigos”. Si se hace clic en la URL, el gusano infecta su PC y se propaga a todas las personas incluidas en la lista de "amigos".

La “lista de amigos” también lleva a la ingeniería social. La ingeniería social ocurre cuando las personas obtienen información de los usuarios legítimos de un sistema de computadora, específicamente, la información que les permitirá obtener acceso no autorizado a un sistema determinado.

El servicio de transferencia de archivos es otro riesgo de seguridad donde las aplicaciones de mensajería instantánea pueden enviar caballos de troya y virus.

Asuntos de seguridad de IM Los servicios de mensajería instantánea (IM) son vulnerables a los ataques como los virus, gusanos y caballos de troya por medio de los siguientes métodos:

Listas de amigos

Un gusano se puede propagar a través de los servicios de IM ya que generalmente aparece como URL en un mensaje instantáneo. Estas URL con frecuencia parecen venir de alguien en su lista de amigos. Si hace clic en esa URL maliciosa, el gusano infecta su equipo y fácilmente se puede propagar a todas las personas en su lista de amigos.

Ingeniería social

La ingeniería social ocurre cuando un atacante obtiene ilegalmente información delicada (como una lista de amigos) de usuarios legítimos de un sistema o servicio, información que el atacante utiliza posteriormente para obtener acceso no autorizado.

Transferencias de archivos

Los caballos de troya y los virus se pueden propagar fácilmente cuando los archivos se envían de un usuario a otro por medio de una sesión de IM.

Análisis antivirus


Análisis de mensajes de chatCuando el dispositivo está habilitado para AV, el cortafuegos procesa los paquetes de datos enviados entre el cliente de IM y el servidor. El cortafuegos detecta el inicio de un mensaje de chat individual en un paquete de datos y retiene los paquetes de datos que siguen hasta que termina el mensaje de chat. El mensaje completo se envía al motor de búsqueda de AV para analizar si hay virus utilizando el procedimiento que se muestra en la siguiente tabla.

Análisis de la transferencia de archivosEl cortafuegos procesa los paquetes de datos comunicados entre el cliente de IM y el servidor. Generalmente, la distribución de archivos significa obtener un archivo, pero la transferencia de archivos de AIM incluye envío de archivo, obtención de archivo y envío de directorio. Cuando el cortafuegos detecta los comandos para la transferencia de archivos, ocurre lo siguiente:

Si… Mensaje de chat Resultado

Se encuentra un virus Se descarta. Se redirecciona un mensaje de notificación de descarte por virus al destino del mensaje original.

Hay errores en el análisis (está desactivado el permiso para error de análisis)

Se descarta. Se redirecciona un mensaje de notificación de descarte por error de análisis al destino del mensaje original.

El análisis de AV termina sin virus o errores en el análisis

Se redirecciona a su destino.

El mensaje llega a su destino.

Si el tamaño del archivo es…

Transferencia de archivos/distribución de archivos Resultado

<= AV max_content_size Se realiza el análisis AV Se encuentran virus. El contenido del archivo se reemplaza por el mensaje de notificación de virus.

Hay errores en el análisis (está desactivado el permiso para error de análisis AV). El contenido del archivo se reemplaza por el mensaje de notificación de error de análisis.

> AV max_content_size (está activado el descarte de max_content_size)

No se realiza análisis AV Descarta el archivo y redirecciona el mensaje de notificación de descarte al destino del mensaje original.

> AV max_content_size (está desactivado el descarte de max_content_size)

No se realiza análisis AV Se redirecciona el archivo a su destino.

NOTA: Esta versión de ScreenOS no es compatible con el tráfico P2P de mensajería instantánea a través del cortafuegos.



70

Resultados del análisis AVEl análisis AV puede no producirse debido a diversas razones. Cuando su dispositivo está configurado para análisis externo, el dispositivo simplemente desvía el tráfico al servidor ICAP externo. Consulte la documentación del servidor ICAP para obtener más información acerca del comportamiento y los resultados del análisis AV.

Si su dispositivo está configurado para análisis AV interno, el comando get av stat muestra los fallos en el análisis. Adicionalmente a los siguientes resultados por código de análisis, este comando genera un registro de eventos con más información acerca de los resultados del análisis.

Scan Code: Clear Scan Code: Infect Scan Code: Psw Archive File Scan Code: Decompress Layer Scan Code: Corrupt File Scan Code: Out Of Resource Scan Code: Internal ErrorScan Code: Error Scan Eng: Error:Fail Mode:

En los siguientes escenarios, se descarta el tráfico y se redireccionan los datos de reemplazo a su destino:

El motor de análisis devuelve uno de los siguientes errores de análisis y está activo el ajuste de descarte de configuración correspondiente

se superó el ajuste de capa de descompresión máxima

archivo protegido con contraseña

archivo corrupto

recursos agotados

Cuando el análisis AV agota los recursos, el archivo se descarta o aprueba según el ajuste de tamaño de contenido máximo, pero se aumenta el contador de recursos agotados.

El motor de análisis AV devuelve cualquiera de los errores de análisis anteriores y se desactiva el permiso de modo de fallo

El tamaño de la transferencia de archivos supera el ajuste de tamaño de contenido máximo de AV y se activa el descarte de tamaño de contenido máximo

NOTA: Si el ajuste de la capa de descompresión máxima está establecido para descartar los paquetes de datos que superan el ajuste de capa de descomprensión, se envía un archivo de reemplazo al receptor. Sin embargo, el servidor de MSN no envía un archivo de reemplazo o un mensaje de error acerca del fallo en la descarga.

Análisis antivirus


Consulte “Análisis de protocolos de aplicación” en la página 72 para obtener información acerca de los fallos del análisis AV, incluyendo las instancias cuando los datos no pudieron ser analizados con éxito.

Consulte el manual ScreenOS Message Log Reference para ver una lista de los mensajes de error generados a partir de un análisis AV.

Análisis AV basado en directivasLos perfiles de análisis AV incrementan la flexibilidad y la granularidad de los análisis AV. El análisis según perfiles le permite configurar un perfil para analizar el tráfico y asignar el perfil a una directiva. Un análisis según directivas le permite:

Seleccionar un tráfico de datos específico para análisis AV

Mejorar el funcionamiento y controlar el motor de análisis AV

Para configurar el análisis según directivas, debe configurar los perfiles de AV para el uso en directivas, realizando los siguientes pasos:

1. Iniciar un contexto de perfil de AV. Para obtener más información, consulte “Inicio de un perfil de AV para AV interno” en página 90.

2. Configurar un perfil (ns-profile está predefinido para AV interno) para examinar el tráfico en la red para los protocolos que se muestran en la siguiente tabla.

3. Salir del contexto del perfil de AV.

4. Asignar el perfil AV a una directiva de cortafuegos. (Únicamente un perfil de AV se puede enlazar a una directiva).

Para aplicar la protección AV, haga referencia al perfil AV en una directiva de seguridad. Cuando el dispositivo de seguridad recibe tráfico afectado por una directiva que requiere análisis AV, éste dirige el contenido que recibe al analizador AV (interno o externo).

5. Guardar su perfil.

Protocolos Consulte

Protocolo de transferencia de archivos (FTP) “Aálisis del tráfico de FTP” en la página 73

Protocolo de transferencia de hipertexto (HTTP)

“Análisis del tráfico de HTTP” en la página 74

Protocolo de acceso de correo de Internet (IMAP)

“Análisis del tráfico de IMAP y POP3” en la página 76

Protocolo de oficina de correo, versión 3 (POP3)


Protocolo de transferencia de correo sencillo (SMTP)

“Análisis del tráfico de SMTP” en la página 78

Protocolo de adaptación de contenido de Internet ( ICAP)

“Desvío del tráfico a los servidores de análisis AV ICAP” en la página 80



72

La Figura 33 muestra cómo funciona el perfil de AV con el analizador AV (interno o externo).

Figura 33: Cómo funciona el perfil de AV con el analizador de AV

Análisis de protocolos de aplicaciónEl motor de análisis AV interno incorporado, admite el análisis para transacciones específicas de la capa de aplicación lo cual le permite seleccionar el contenido que se va a analizar (tráfico FTP, HTTP, IMAP, POP3, o SMTP). Por ejemplo, el funcionamiento del análisis puede mejorarse si se omite el análisis de determinado contenido. De la misma manera, el análisis AV externo se admite únicamente para protocolos HTTP y SMTP.

Esta sección describe cómo configurar los siguientes protocolos de aplicación para el análisis AV:

“Aálisis del tráfico de FTP” en la página 73

“Análisis del tráfico de HTTP” en la página 74


“Análisis del tráfico de SMTP” en la página 78

2

3

4

5

6

Zona Untrust

Servidor FTP remoto

Zona Trust

Cliente FTPlocal

Si no se encuentran virus, los datosse reenvían a su destino original.

Un cliente establece una conexión con un servidor e inicia una sesión.

El administrador de análisis supervisa todas las peticiones enviadas por el cliente y extrae los datos específicos del protocolo.

El perfil de AV determina si la peticiónse debe enviar para el análisis de antivirus.

Si los datos se configuran para ser analizados, entonces se envían al motor de detección de virus para el análisis.

Si se encuentra un virus, el mensaje se registrará y se enviará un correo electrónico basado en el ajuste del perfil de AV.

NOTA: Es necesario evaluar el riesgo y determinar la mejor solución entre seguridad y rendimiento.

Análisis antivirus


Cada una de las aplicaciones anteriores puede configurarse para uno o varios de los siguientes:

Aálisis del tráfico de FTPPara el tráfico del protocolo de transferencia de archivos (FTP), el dispositivo de seguridad supervisa el canal de control y, cuando detecta uno de los comandos de FTP para la transferencia de datos (RETR, STOR, STOU, APPE o NLST), analiza los datos enviados sobre el canal de datos.

Dependiendo de los resultados del análisis y cómo esté configurado el comportamiento del modo de fallo, el dispositivo de seguridad toma una de las siguientes acciones:

Comando Descripción

decompress-layer Especifica cuántas capas de archivos comprimidos anidados puede descomprimir el analizador de AV antes de ejecutar el análisis para detección de virus.

extension list Especifica el nombre de la lista de extensiones (cadena) para incluir o excluir extensiones definidas.

scan-mode Especifica cómo el motor de análisis analiza el tráfico de un protocolo determinado.

tiempo de espera Especifica el tiempo de espera para una sesión de AV en el caso de un protocolo determinado.

http skipmime No realiza el análisis AV a la lista MIME que se especifique. Nota: El deshabilitar skipmime permite al dispositivo de seguridad analizar todas las clases de tráfico HTTP independientemente de los tipos de contenido MIME.

email-notify Notifica al remitente o al destinatario sobre los virus detectados o los errores encontrados durante el análisis, únicamente para el tráfico IMAP, POP3 y SMTP.

Si los datos Y El dispositivo de seguridad

no están contaminados pasa los datos al cliente FTP a través del canal de datos

contienen un virus descarta los datos del canal de datos y envía un mensaje de notificación de virus al cliente FTP a través del canal de control

exceden el tamaño máximo de contenido

está establecida la opción drop

descarta los datos del canal de datos y envía un mensaje de “file too large” (archivo demasiado grande) al cliente FTP a través del canal de control


no está establecida la opción drop

pasa los datos sin examinar al cliente FTP a través del canal de datos

no se pueden analizar con éxito no está establecida la opción fail mode (drop)

descarta los datos del canal de datos y envía un mensaje “scan error” (error de análisis) al cliente FTP a través del canal de control

no se pueden analizar con éxito la opción fail mode está establecida en permit (traffic permit)

pasa los datos al cliente FTP a través del canal de datos



74

Figura 34: Análisis de antivirus para el tráfico de FTP

Análisis del tráfico de HTTP Para el análisis de tráfico de HTTP, el dispositivo de seguridad analiza tanto las respuestas como las solicitudes de HTTP (comandos get, post y put). El analizador AV interno examina las descargas HTTP; es decir, los datos HTTP que se encuentran en las respuestas de un servidor web a las solicitudes HTTP de un cliente. El analizador AV interno analiza también las cargas, p. ej., cuando un cliente HTTP completa un cuestionario en un servidor web o cuando un cliente escribe un mensaje en un correo electrónico ubicado en un servidor web.

Dependiendo de los resultados del análisis y cómo esté configurado el comportamiento del modo de fallo, el dispositivo de seguridad toma una de las siguientes acciones:

exceden los mensajes simultáneos máximos


descarta los datos del canal de datos y envía un mensaje “exceeding maximum message setting” (supera el ajuste de número máximo de mensajes) al cliente FTP a través del canal de control



pasa los datos al cliente FTP a través del canal de datos


Zona Trust

Servidor FTP remoto

Analizador AV interno

Canal de control

Canal de datos

Zona Untrust

Cliente FTPlocal

1. Un cliente FTP local abre un canal de control FTP a un servidor FTP y pide la transferencia de algunos datos.

2. El servidor y cliente FTP negocian un canal de datos a través del cual el servidor envía los datos solicitados. El dispositivo de seguridad intercepta los datos y los pasa a su motor interno de detección AV, que los examina en busca de virus.

3. Una vez finalizado el análisis, el dispositivo sigue uno de estos pasos*:

• Si no hay virus, reenvía los datos al cliente.

• Si se descubre la presencia de un virus, reemplaza los datos con un mensaje de descarte en el canal de datos y envía otro informando la infección en el canal de control.

* Si los datos analizados exceden la configuración máxima de contenido o, si el análisis no concluirse de forma satisfactoria, el dispositivo sigue un curso de acción diferente dependiendo de la configuración de modo de fallo.


no están contaminados pasa los datos al cliente HTTP

contienen un virus descarta los datos y envía un mensaje de notificación de virus al cliente HTTP

Análisis antivirus


Figura 35: Análisis de antivirus para el tráfico de HTTP

Extensiones MIME de HTTP

De forma predeterminada, el análisis de HTTP no analiza las entidades de HTTP compuestas de alguno de los siguientes tipos y subtipos de contenido MIME (extensiones de correo multiuso para Internet), cuando aparecen seguidos de una barra inclinada (/):

Application/x-director

Application/pdf

Image/



descarta los datos y envía un mensaje “file too large” (archivo demasiado grande) al cliente HTTP



pasa los datos al cliente HTTP

no se pueden analizar con éxito no está establecida la opción fail mode (drop)

descarta los datos y envía un mensaje “scan error” (error de análisis) al cliente HTTP

no se pueden analizar con éxito está establecida la opción traffic permito(fail mode tiene el valor permit)

pasa los datos al cliente HTTP



descarta los datos del canal de datos y envía un mensaje “exceeding maximum message setting” (supera el ajuste de número máximo de mensajes) al cliente HTTP a través del canal de control



pasa los datos al cliente HTTP a través del canal de datos


Zona Trust

Servidor Webremoto


Zona Untrust

Cliente HTTP local

1. Un cliente HTTP envía una petición de HTTP a un servidor web.

2. El dispositivo de seguridad intercepta la petición y transmite los datos al analizador AV interno, que los examina en busca de virus.

3. Una vez finalizado el análisis, el dispositivo sigue uno de estos pasos*:

• Si no hay virus, reenvía la petición al servidor web.• Si se descubre la presencia de un virus, descarta la petición y

envía un mensaje de HTTP informando de la infección al cliente.

* Si los datos analizados exceden el establecimiento máximo de contenido o, si el análisis no puede tener éxito completamente, el dispositivo de seguridad sigue un curso de acción diferente dependiendo del establecimiento de modo de fallo.

4. Un servidor web responde a una petición de HTTP.

5. El dispositivo de seguridad intercepta la respuesta de HTTP y pasa los datos a su motor interno de detección AV, que los examina en busca de virus.

6. Una vez finalizado el análisis, el dispositivo sigue uno de estos pasos*:• Si no hay virus, reenvía la respuesta al cliente de HTTP.• Si se descubre la presencia de un virus, descarta la respuesta y

envía un mensaje de HTTP informando de la infección al cliente.



76

Video/

Audio/

Text/css

Text/html

Para mejorar el rendimiento, los dispositivos de seguridad Juniper Networks no analizan los tipos de contenido MIME anteriores. Debido a que la mayoría de las entidades de HTTP están formadas por los tipos de contenido anteriores, el análisis de HTTP se aplica únicamente a un subgrupo pequeño de entidades de HTTP, como los tipos de contenido aplication/zip y aplication/exe, en los cuales es muy probable que se oculten los virus.

Para cambiar el comportamiento del análisis de HTTP para que el dispositivo de seguridad analice todos los tipos de tráfico de HTTP sin tener en cuenta los tipos de contenido MIME, introduzca el siguiente comando:

set av profile jnpr-profile(av:jnpr-profile)-> unset av http skipmime(av:jnpr-profile)-> exitsave

Análisis del tráfico de IMAP y POP3Para el análisis de tráfico de IMAP y POP3, el dispositivo de seguridad desvía el tráfico desde un servidor de correo local al analizador AV interno antes de enviarlo al cliente IMAP o POP3 local. Dependiendo de los resultados del análisis y cómo esté configurado el comportamiento del modo de fallo, el dispositivo de seguridad toma una de las siguientes acciones:


no están contaminados

pasa el mensaje al cliente de IMAP o POP3.

contienen un virus está establecida la opción email notification

cambia el tipo de contenido a “text/plain,” reemplaza el cuerpo del mensaje con la siguiente notificación, la envía al cliente de IMAP o POP3 y notifica al remitente:

VIRUS WARNING.Contaminated File: nombre del archivo contaminadoVirus Name: nombre del virus

Análisis antivirus



o bien

no se pueden analizar con éxito

o bien



no está establecida la opción fail mode (drop)

está establecida la opción email notification

cambia el tipo de contenido a text/plain, reemplaza el cuerpo del mensaje con la siguiente notificación, la envía al cliente de IMAP o POP3:

Content was not scanned for viruses because cadena_motivo (número de código), and it was dropped.

El campo cadena_motivo puede ser uno de los siguientes:

El archivo es demasiado grande.

Se encontró un error o un problema.

Se excedió el tamaño de contenido máximo.

Se excedió el número máximo de mensajes

notifica al remitente/destinatario sobre los virus detectados o los errores en el análisis.


o bien


o bien



traffic permit está establecido (fail mode tiene el valor permit)

drop no está establecido


pasa el mensaje original al cliente de IMAP o POP3 con la línea de asunto original modificada como se muestra a continuación:

cadena_asunto_original (No virus check because cadena_motivo, número de código)





78

Figura 36: Análisis de antivirus para el tráfico de IMAP y POP3

Análisis del tráfico de SMTP Para el tráfico SMTP, el dispositivo de seguridad redirecciona el tráfico de un cliente SMTP local al analizador AV interno antes de enviarlo al servidor de correo local. Dependiendo de los resultados del análisis y cómo esté configurado el comportamiento del modo de fallo, el dispositivo de seguridad toma una de las siguientes acciones:

Zona DMZ

Internet


Zona Untrust

Servidor de correolocal

1. El cliente IMAP o POP3 descarga un mensaje de correo electrónico desde el servidor de correo local.

2. El dispositivo de seguridad intercepta el mensaje de correo electrónico y transmite los datos al analizador AV interno, que los examina en busca de virus.

3. Una vez finalizado el análisis, el dispositivo de seguridad 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.

* Si el mensaje analizado excede la configuración máxima de contenido o, si el análisis no puede tener éxito completamente, el dispositivo de seguridad sigue un curso de acción diferente dependiendo del establecimiento de modo de fallo.

Zona Trust

Cliente IMAP o POP3


no están contaminados

pasa el mensaje al destinatario de SMTP.

contienen un virus está establecida la opción email notification

cambia el tipo de contenido a “text/plain,” reemplaza el cuerpo del mensaje con la siguiente notificación, la envía al destinatario de SMTP y notifica al remitente:

VIRUS WARNING.Contaminated File: nombre del archivoVirus Name: nombre_virus

Análisis antivirus



o bien


o bien



no está establecida la opción fail mode (drop)



cambia el tipo de contenido a “text/plain,” reemplaza el cuerpo del mensaje con la siguiente notificación, la envía al destinatario de SMTP:

Content was not scanned for viruses because cadena_motivo (número de código), and it was dropped.

El campo cadena_motivo puede ser uno de los siguientes:

El archivo es demasiado grande.

Se encontró un error o un problema.

Se excedió el tamaño de contenido máximo.

Se excedió el número máximo de mensajes


exceden el nivel máximo de contenido

o bien


o bien


está desactivada la opción drop

traffic permit está establecido (fail mode está permitido)

no está activada la opción drop


pasa el mensaje original al cliente de SMTP con la línea de asunto original modificada como se muestra a continuación:

cadena_asunto_original (No virus check because cadena_motivo, número de código)



NOTA: Ya que el cliente SMTP se refiere a la entidad que envía un correo electrónico, es posible que un cliente, de hecho, sea otro servidor SMTP.



80

Figura 37: Análisis de antivirus para el tráfico de SMTP

Desvío del tráfico a los servidores de análisis AV ICAPEl dispositivo de seguridad de Juniper Networks se comunica con un motor de análisis AV externo utilizando el protocolo de adaptación de contenido de Internet (ICAP). ScreenOS 5.4 admite únicamente el desvío del tráfico HTTP y SMTP.

Para configurar el dispositivo de seguridad para que admita el análisis AV ICAP externo, realice los siguientes pasos:

1. Utilice el comando set icap para configurar el servidor de análisis ICAP externo.

2. Configure un perfil ICAP y especifique uno o más de los siguientes comandos:

Zona Trust

Internet


Zona Untrust

Cliente SMTP

A. Un cliente SMTP envía un mensaje de correo electrónico a un servidor de correo local.

B. El dispositivo de seguridad intercepta el mensaje de correo electrónico y pasa los datos al analizador AV interno, que los analiza en busca de virus.

C. Una vez finalizado el análisis, el dispositivo sigue uno de estos pasos*:

• Si no hay virus, reenvía el mensaje al servidor local.• Si se descubre la presencia de un virus, envía un mensaje

informando de la infección al cliente.

1. Un servidor de correo remoto redirecciona un mensaje de correo electrónico por SMTP al servidor de correo local.

2. El dispositivo de seguridad intercepta el mensaje de correo electrónico y pasa los datos al analizador AV interno, que los analiza en busca de virus.

3. Una vez finalizado el análisis, el dispositivo sigue uno de estos pasos*:• Si no hay virus, reenvía el mensaje al servidor local.• Si se descubre la presencia de un virus, envía un mensaje

informando de la infección al servidor remoto.

Zona DMZ

Servidor de correo remoto

* Si el mensaje analizado excede la configuración máxima de contenido o, si el análisis no puede tener éxito completamente, el dispositivo de seguridad sigue un curso de acción diferente dependiendo del establecimiento del modo de fallo.

Comando Descripción

timeout Especifica el tiempo de espera para una sesión de AV en el caso de un protocolo determinado (HTTP o SMTP).

http skipmime No realiza el análisis AV a la lista MIME que se especifica. Nota: Deshabilitar la lista skipmime permite al dispositivo de seguridad analizar todas las clases de tráfico HTTP independientemente de los tipos de contenido MIME.

email-notify Notifica al remitente o al destinatario sobre los virus detectados o los errores encontrados durante el análisis, únicamente para el tráfico SMTP.

Análisis antivirus


WebUI

Objects > Antivirus > ICAP Server >New: Introduzca los siguientes datos y haga clic en Apply:

ICAP AV Server Name: ICAP_Server1Enable: (seleccione), Scan Server Name/IP: 1.1.1.1Scan Server Port: 1344, Scan URL: /SYMCScan-Resp-AVProbe Interval: 10, Max Connections:

CLI

set icap server icap_server1 host 1.1.1.1save

El servidor ICAP se habilita automáticamente cuando se configura.

Actualización de los archivos de patrones AV para el analizador incorporadoEl análisis AV interno hace necesario cargar una base de datos de patrones de virus en el dispositivo de seguridad de Juniper Networks y actualizar el archivo de patrones periódicamente.

Antes de actualizar los archivos de patrones AV, asegúrese de que el dispositivo admite lo siguiente:

Suscripción al servicio de firma AVPara adquirir una suscripción al servicio de firma AV, debe registrar su dispositivo en primer lugar. Mientras dure el período de validez de la suscripción, puede cargar la versión actual de la base de datos y actualizarla cada vez que estén disponibles versiones nuevas. El procedimiento para iniciar el servicio de firma AV puede variar dependiendo de lo siguiente:

Si adquiere un dispositivo de seguridad 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 continuar recibiendo actualizaciones.

Si actualiza su dispositivo de seguridad 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.

Prerrequisitos Descripción

Clave de licencia AV válida av_v2_key

Acceso a Internet El dispositivo tiene una ruta hacia Internet

Configuraciones de DNS y de puerto Verifica el ajuste del DNS y del puerto 80

Servicio de firma AV Consulte “Suscripción al servicio de firma AV” en página 81



82

Actualización de los patrones AVLa Figura 38 y la Figura 39 muestran la manera en la cual se actualiza el archivo de firmas. Actualice el archivo de patrones AV de la forma siguiente:

1. En el dispositivo de seguridad, especifique la dirección URL del servidor de actualización de firmas.

http://update.juniper-updates.net/av/5gt

Figura 38: Actualización de archivos de firmas, paso 1

2. Después de que el dispositivo de seguridad descarga el archivo de inicialización del servidor, el dispositivo revisa que el archivo de patrones sea válido. El dispositivo analiza el archivo para obtener información acerca de éste, incluyendo la versión del archivo, tamaño y ubicación de servidor de archivos de patrones.

3. Si el archivo de patrones del dispositivo de seguridad está desactualizado (o no existe debido a que es la primera vez que lo carga) y si la suscripción de servicio de actualización de patrones de AV continúa siendo válida, el dispositivo recupera automáticamente un archivo de patrones actualizado del servidor de archivos de patrones.

NOTA: Para obtener más información sobre el servicio de firmas de virus, consulte “Registro y activación de los servicios de suscripción” en la página 2-254.

Dispositivo de seguridadPetición de transferencia de archivo

Internet

Servidor de actualizaciones

URL de Juniper-Kaspersky = http://update.juniper-updates.net/av/5gt

NOTA: ScreenOS contiene un certificado CA para autenticar la comunicación con el servidor de archivos de actualización de patrones.

Análisis antivirus

http://update.juniper-updates.net/av/5gt


Figura 39: Actualización de archivos de firmas, paso 2

4. El dispositivo guarda el nuevo archivo de patrones en la memoria flash y en la memoria RAM y sobrescribe el archivo existente, si existe alguno.

Las actualizaciones del archivo de firmas se agregan a medida que se propagan nuevos virus. Puede configurar el dispositivo de seguridad para realizar regularmente la actualización del archivo de patrones de manera automática o puede actualizar el archivo de forma manual.

Ejemplo: Actualización automática

En este ejemplo, configuraremos el dispositivo de seguridad para que actualice el archivo de firmas automáticamente cada 120 minutos. (El intervalo de actualización predeterminado es de 60 minutos). Por ejemplo, si el servidor de actualización de patrones se encuentra en la dirección URL: http://update.juniper-updates.net/av/5gt, se configura la actualización automática de la forma siguiente:

WebUI

Security > Antivirus > Scan Manager: Introduzca los siguientes datos y haga clic en Apply:

Pattern Update Server: http://update.juniper-updates.net/av/5gtAuto Pattern Update: (seleccione), Interval: 120 minutes (10~10080)

CLI

set av scan-mgr pattern-update-url http://update.juniper-updates.net/av/5gt interval 120

save

Ejemplo: Actualización manual

En este ejemplo, actualizará el archivo de firmas manualmente. El servidor de actualización de patrones se encuentra ubicado en la siguiente dirección URL: http://update.juniper-updates.net/av/5gt


Transferencia del archivo de firmas de virus

Internet

Solicitud del archivo de firmas

Archivo de firmas de virus Archivo de firmas de virus

Servidor de archivos de firmas

NOTA: Cuando caduque la suscripción, el servidor de actualizaciones no permitirá actualizar el archivo de firmas de virus.



84

WebUI

Security > Antivirus > Scan Manager: Introduzca los siguientes datos y haga clic en Apply:

Pattern Update Server: http://update.juniper-updates.net/av/5gtUpdate Now: (seleccione)

CLI

exec av scan-mgr pattern-update

El comando set no es necesario ya que la dirección URL es la predeterminada.

Ajustes globales del analizador de AVSe pueden modificar los ajustes del analizador AV para satisfacer las necesidades de su entorno de red. El comando global scan-mgr en CLI configura el administrador de análisis, el cual es el componente de AV que interactúa con el motor de análisis. Por ejemplo, el comando de CLI set o get av scan-mgr establece los comandos globales que controlan los parámetros, como max-content-size, max-msgs, pattern-type, pattern-update y queue-size.

Las siguientes secciones explican los ajustes globales en su analizador de AV:

“Asignación de recursos de AV” en página 84

“Comportamiento en modo de fallo:” en página 85

“Tamaño máximo del contenido y número máximo de mensajes (sólo AV interno)” en página 85

“HTTP Keep-Alive” en página 86

“Goteo HTTP (únicamente AV interno)” en página 87

Utilice get av all o get av scan-mgr para ver los ajustes del antivirus global en el dispositivo.

Asignación de recursos de AVUn usuario malicioso puede generar simultáneamente una gran cantidad de tráfico en un intento de consumir todos los recursos disponibles y, por lo tanto, restringir la capacidad del analizador AV de analizar otro tráfico. Para evitar que esto suceda, el dispositivo de seguridad de Juniper Networks puede imponer un porcentaje máximo de recursos de AV que el tráfico proveniente de un único origen puede consumir en un momento determinado. De forma predeterminada, el porcentaje máximo es del 70 por ciento. Este ajuste se puede cambiar a cualquier valor entre 1 y 100 por ciento; si se ajusta el 100 por ciento, no habrá ninguna restricción a la cantidad de recursos de AV que pueda consumir el tráfico desde una ubicación determinada.

WebUI

NOTA: Para configurar esta opción debe utilizarse la CLI.

Análisis antivirus


CLI

set av all resources númerounset av all resources

El comando unset av restablece el porcentaje máximo de recursos de AV por ubicación de origen al valor predeterminado (70 por ciento).

Comportamiento en modo de fallo:El modo de fallo es el comportamiento que el dispositivo de seguridad aplica cuando no puede completar una operación de análisis, ya sea permitir el tráfico sin examinar o bloquearlo. De forma predeterminada, si un dispositivo no puede completar un análisis, bloquea el tráfico que una directiva con la comprobación antivirus habilitada permitiría. Este comportamiento predeterminado se puede cambiar para que permita el tráfico.

Cuando el motor de análisis AV está analizando un archivo y agota la memoria (suele sueder al descomprimir archivos), el contenido se descarta o se deja pasar según el ajuste de agotamiento de recursos (set av scan-mgr out-of-resource) , y no según el ajuste de modo de fallo.

WebUI

Security > Antivirus > Global: Seleccione Fail Mode Traffic Permit para permitir el tráfico sin examinar o borrarlo para bloquear el tráfico sin examinar, luego haga clic en Apply.

CLI

set av all fail-mode traffic permitunset 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).

Tamaño máximo del contenido y número máximo de mensajes (sólo AV interno)Los ajustes del administrador de análisis para el tamaño máximo de contenido y el número máximo de mensajes se admiten únicamente en el analizador AV interno. El AV de ICAP no admite ajustes para el tamaño máximo de contenido ni para el número máximo de mensajes.

En algunos dispositivos, el analizador AV analiza simultáneamente un máximo de 256 mensajes y 10 megabytes de contenido del archivo descomprimido. Los valores para el tamaño máximo del contenido y el número máximo de mensajes dependen del dispositivo (consulte las notas de la versión del producto).

Si el número total de mensajes o el tamaño del contenido recibido al mismo tiempo supera estos límites, el analizador permitirá de forma predeterminada el descarte del contenido sin analizarlo. Para conexiones lentas, como RDSI, se disminuye el tamaño de contenido máximo a un valor menor (set av scan-mgr max-content-size 20), de manera que el análisis AV no caduque.



86

Por ejemplo, el analizador puede recibir y examinar cuatro mensajes de 4 megabytes simultáneamente. Si el analizador recibe nueve mensajes de 2 megabytes al mismo tiempo, descartará el contenido de los últimos dos archivos sin analizarlos. Puede modificar este comportamiento predeterminado para que el analizador pase el tráfico en lugar de descartarlo realizando los siguientes pasos:

WebUI

Security > Antivirus > Scan Manager

Content Oversize: Seleccione permit para pasar el tráfico si el archivo es superior a 10,000 KB

O bien

Msgs Overflow: Seleccione permit si el número de archivos es superior al número máximo de mensajes en el dispositivo, luego haga clic en Apply.

CLI

unset av scan-mgr max-content-size dropunset av scan-mgr max-msgs drop

Cuando el motor de análisis AV está analizando un archivo y agota la memoria (suele sueder al descomprimir archivos), el contenido se descarta o se deja pasar según el ajuste de agotamiento de recursos (set av scan-mgr out-of-resource) , y no según el ajuste de modo de fallo (set av all failmode).

HTTP Keep-Alive El dispositivo de seguridad utiliza de forma predeterminada la opción de conexión HTTP “keep-alive” (mantenimiento de conexión), la cual no envía un TCP FIN para indicar el fin 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 del procesador.

Se puede cambiar el comportamiento predeterminado del dispositivo de seguridad para que utilice la opción de conexión HTTP “close” para indicar el final de la transmisión de datos. (En caso necesario, el dispositivo cambia el token del campo del encabezado de la conexión de “keep-alive” a “close”.). Con este método, cuando el servidor HTTP completa la transmisión de datos, envía un comando TCP FIN para terminar la conexión TCP y así indicar que el servidor ha finalizado el envío de datos. Cuando el dispositivo recibe un comando TCP FIN, contiene todos los datos HTTP del servidor y puede ordenar al analizador AV que inicie el análisis.

NOTA: En algunos dispositivos de seguridad, el valor predeterminado para el tamaño máximo del contenido es de 10 MB. Sin embargo, si no está habilitada la opción DI, se recomienda que configure un valor de 6 MB.

Análisis antivirus


WebUI

Security > Antivirus > Global: Seleccione Keep Alive 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-aliveunset av http keep-alive

Goteo HTTP (únicamente AV interno)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 mientras el administrador de análisis examina los archivos HTTP descargados. (El dispositivo de seguridad 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

Security > Antivirus > Global: 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 de seguridad emplea el goteo si el tamaño de un archivo HTTP supera 3 MB de tamaño. El dispositivo reenviará 500 bytes de contenido por cada megabyte enviado a analizar.

ScreenOS le permite configurar opciones de goteo más granulares si su explorador caduca durante el análisis AV. El explorador caduca si el dispositivo de seguridad requiere más tiempo para el análisis de tráfico o cuando el tráfico es lento. Con base en su entorno, personalice los valores para el tiempo y los datos para activar el goteo de HTTP tal y como se muestra:

WebUI

Security > Antivirus > Global: Introduzca los siguientes datos y haga clic en Apply:

Trickling:Custom: (seleccione)

Minimum Length to Start Trickling: número1.

NOTA: El método “keep–alive” no resulta tan seguro como el método de conexión “close”. Este comportamiento predeterminado se puede modificar si se detecta que las conexiones HTTP superan el tiempo de espera durante el análisis antivirus.

NOTA: El goteo HTTP se admite únicamente en el analizador AV interno. Sin embargo para YMSG, el goteo está desactivado para chat y transferencia de archivos. ICAP AV no admite un goteo HTTP.



88

Trickle Size: número2.Trickle for Every KB Sent for Scanning: número3.Trickle Timeout: número4.

CLI

set av http trickling threshold número1 segment-size número3 trickle-size número2 timeout número4

Las cuatro variables numéricas tienen los siguientes significados:

número1: El tamaño mínimo (en kilobytes) de un archivo HTTP para que comience el goteo. Si su explorador caduca debido a una descarga lenta, entonces reduzca este valor a un goteo de activación más pronto.

número2: El tamaño (en valor que no sea cero) en bytes del tráfico no analizado que reenviará el dispositivo de seguridad.

número3: El tamaño (en kilobytes) de un bloqueo de tráfico al que el dispositivo de seguridad aplicará el goteo.

número4: El tiempo (en segundos) para activar el evento de goteo. El goteo con base en tiempo empieza cuando se llega al tamaño inicial (número1). El valor 0 indica que está desactivado el goteo con base en tiempo.

Puede desactivar el goteo HTTP por medio de la interfaz WebUI (Security > Antivirus: Haga clic en Disable en la sección Trickling) o con el comando CLI unset av http trickling enable. En cualquier caso, si el archivo que se va a descargar supera los 8 MB y se ha desactivado el goteo de HTTP, es muy probable que la ventana del explorador supere el tiempo de espera.

Perfiles de AV Las directivas utilizan los perfiles de AV para determinar qué tráfico pasa por el examen de AV y las acciones a tomar como resultado de este examen. ScreenOS admite los siguientes tipos de perfiles:

Perfiles de AV predefinidos

ScreenOS admite dos perfiles predefinidos: el predeterminado, ns-profile (sólo lectura) y el perfil scan-mgr profile (lectura y escritura). Ambos perfiles se admiten únicamente para el AV interno incorporado.

El perfil scan-mgr profile se genera automáticamente para la compatibilidad con versiones anteriores (cuando actualice de ScreenOS 5.2 o anterior a ScreenOS 5.3 o posterior). scan-mgr profile se genera para cambiar los comandos del administrador de análisis global.

NOTA: Los datos sometidos al proceso de goteo en el explorador 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 de seguridad ha enviado al cliente por goteo. Recomendamos a los usuarios que eliminen esos archivos.

Análisis antivirus


El administrador de análisis es el componente de AV que administra el motor de análisis. Para obtener más información sobre el administrador de análisis, consulte “Ajustes globales del analizador de AV” en la página 84.

scan-mgr profile ejecuta los siguientes comandos, de manera que los comandos ahora se introduzcan desde dentro de un contexto de perfil:

set ftp decompress-layer 2set http decompress-layer 2set imap decompress-layer 2set pop3 decompress-layer 2set smtp decompress-layer 2set http skipmime enableset http skipmime mime-list ns-skip-mime-list

Por ejemplo, el comando get av profile ns-profile o get av profile scan-mgr muestra los ajustes de perfil de los protocolos compatibles:

device->get av profile ns-profileftp Setting:

status: enablemode: scan-intelligentdecompress layer: 3timeout: 180 secondsinclude ext list: N/Aexclude ext list: N/A

http Setting:status: enablemode: scan-intelligentdecompress layer: 2timeout: 180 secondsinclude ext list: N/Aexclude ext list: N/Askip scanning:text/html;text/css;audio/;video/;image/;application/x-director

---

Perfiles de AV personalizados

Cree su propio perfil de AV para personalizar los ajustes de cada protocolo. Puede definir un máximo de 8 perfiles de AV para cada sistema virtual (y raíz).

Asignación de un perfil AV a una directiva de cortafuegosÚnicamente un perfil de AV se puede enlazar a una directiva de cortafuegos. Realice lo siguiente para enlazar el perfil de AV a una directiva de cortafuegos.

WebUI

Policy > Policies: Haga clic en Edit en la directiva a la cual desea enlazar el perfil de AV y seleccione el perfil bajo Antivirus Profile. Haga clic en OK.

CLI

device-> set policy id núm_directiva av ns-profile



90

Las siguientes secciones explican cómo iniciar un perfil de AV y configurar los ajustes de perfil:

“Inicio de un perfil de AV para AV interno” en página 90

“Ejemplo: Análisis para todo tipo de tráfico (AV interno)” en página 90

“Ejemplo: Análisis de AV únicamente para el tráfico SMTP y HTTP” en página 91

“Ajustes de perfiles de AV” en página 92

Inicio de un perfil de AV para AV internoLos siguientes comandos inicia un perfil de AV personalizado denominado jnpr-profile, el cual de forma predeterminada está configurado para buscar el tráfico FTP, HTTP, IMAP, POP3 y SMTP.

WebUI

Security > Antivirus > Profile: Seleccione New e ingrese el nombre del perfil, jnpr-profile, luego haga clic en OK.

CLI

set av profile jnpr-profiledevice(av:jnpr-profile)->

device-> set av profile jnpr-profiledevice(av:jnpr-profile)->

Después de introducir un contexto de perfil de AV, todas las ejecuciones de comando subsecuentes modifican el perfil de AV especificado (jnpr-profile).

Ejemplo: Análisis para todo tipo de tráfico (AV interno)En este ejemplo configuraremos el analizador AV para que examine todo el tráfico FTP, HTTP, IMAP, POP3, IM y SMTP. Debido a que anticipa que el analizador procesará bastante tráfico, también aumenta el tiempo de espera de 180 segundos (el ajuste predeterminado) a 300 segundos.

WebUI

Security > Antivirus > Profile: Ingrese nombre_perfil, luego haga clic en OK.

De forma predeterminada, se analiza el tráfico de los seis protocolos.

CLI

set av profile jnpr-profile(av:jnpr-profile)-> set http enable(av:jnpr-profile-> set http timeout 300(av:jnpr-profile)-> set ftp enable(av:jnpr-profile)-> set ftp timeout 300(av:jnpr-profile)-> set imap enable(av:jnpr-profile)-> set imap timeout 300

NOTA: Para cambiar el valor de tiempo de espera, debe utilizar la CLI.

Análisis antivirus


(av:jnpr-profile)-> set pop3 enable(av:jnpr-profile)-> set pop3 timeout 300(av:jnpr-profile)-> set smtp enable(av:jnpr-profile)-> set smtp timeout 300(av:jnpr-profile)-> exitsave

Ejemplo: Análisis de AV únicamente para el tráfico SMTP y HTTPDe forma predeterminada, el analizador de AV examina el tráfico de FTP, HTTP, IMAP, POP3 y SMTP. Puede cambiar el comportamiento predeterminado para que el analizador examine únicamente tipos específicos de tráfico de red.

También puede cambiar el valor de tiempo de espera para cada protocolo. De forma predeterminada, la operación de análisis de AV vence después de 180 segundos si el dispositivo de seguridad no inicia el análisis después de recibir todos los datos. Se puede ajustar un valor de entre 1 y 1800 segundos.

En este ejemplo configuraremos el analizador AV para que examine todo el tráfico SMTP y HTTP. Recupere el valor predeterminado de los tiempos de espera de ambos protocolos: 180 segundos.

WebUI

Security > Antivirus > Select New e introduzca el nombre de perfil jnpr-profile.

Introduzca los siguientes datos y haga clic en OK.

Protocols to be scanned: HTTP: (seleccione)SMTP: (seleccione)POP3: (anule la selección)FTP: (anule la selección)IMAP: (anule la selección)

CLI

set av profile jnpr-profile(av:jnpr-profile)-> set smtp timeout 180(av:jnpr-profile)-> set http timeout 180 (av:jnpr-profile)-> unset pop3 enable(av:jnpr-profile)-> unset ftp enable(av:jnpr-profile)-> unset imap enable(av:jnpr-profile)-> exitsave

NOTA: El analizador AV interno sólo examina patrones específicos de correo web HTTP. Los patrones de los servicios de correo de Yahoo!, Hotmail y AOL están predefinidos.

NOTA: Para cambiar el valor de tiempo de espera, debe utilizar CLI.



92

Ajustes de perfiles de AVLas siguientes opciones de análisis están configuradas para cada protocolo de aplicación:

“Descompresión de los archivos adjuntos” en la página 92

“Análisis AV basado en las extensiones de los archivos” en la página 92

“Análisis de AV basado en el tipo de contenido de HTTP” en la página 93

“Notificar el remitente y destinatario por medio de correo electrónico” en la página 94

“Ejemplo: Eliminación de archivos de gran tamaño” en la página 95

Descompresión de los archivos adjuntos

Cuando el dispositivo de seguridad recibe datos, el analizador AV interno descomprime cualquier archivo comprimido. Puede configurar el analizador AV interno para que descomprima hasta cuatro archivos comprimidos y anidados antes de ejecutar un análisis de virus.

Por ejemplo, si un mensaje contiene un archivo comprimido .zip que contiene otro archivo comprimido .zip, hay dos capas de compresión y la descomprensión de ambos archivos requiere de un ajuste de capa de descomprensión de 2.

WebUISecurity > Antivirus > Profile: Seleccione New o Edit para editar un perfil existente. Actualice el valor de Decompress Layer a 2, luego haga clic en Apply.

CLIset av profile jnpr-profile(av:jnpr-profile)-> set smtp decompress-layer 2

Cuando se transmiten datos, algunos protocolos codifican el contenido. El motor de análisis AV necesita decodificar esta capa, la cual se considera como un nivel de descompresión, antes de realizar el análisis en busca de virus.

Análisis AV basado en las extensiones de los archivos

ScreenOS admite tres modos de análisis:

scan-all. El motor de AV reenvía todos los archivos al motor de análisis para el análisis de virus.

scan-intelligent. El motor de AV utiliza el algoritmo incorporado para decidir si necesita explorar los archivos.

Esta opción de inteligencia de análisis predeterminado especifica que el motor de AV utiliza un algoritmo que analiza el tráfico para los virus más comunes y predominantes, incluso asegurando que el tipo de archivo sea verdadero y que no infecte a otros archivos directamente. Aunque esta opción no es tan amplia en cobertura como el análisis completo, proporciona un mejor desempeño

scan-extension. El motor de AV reenvía los archivos para análisis con base en las extensiones, lista de exclusión e inclusión (consulte la siguiente sección).

Análisis antivirus


Las listas de extensiones de archivo se utilizan para determinar qué archivos deben pasar por el análisis AV para un protocolo específico. Puede seleccionar Include (incluir) una lista de extensiones de los archivos y Exclude (excluir) una lista de extensiones de los archivos para cada protocolo.

Un mensaje se analiza cuando la extensión del archivo de un mensaje está la lista de extensiones de archivo de inclusión. Un mensaje no se analiza si la extensión de archivo está en la lista de extensiones de archivo de exclusión. Si la extensión del archivo no aparece en ninguna de estas listas, entonces la decisión sobre si debe analizarse dependerá del ajuste predeterminado para el análisis de la extensión del archivo. La extensión del archivo predeterminado está en la base de datos del motor de análisis, así que es sólo de lectura. Utilice el comando get av scan-mgr para ver la lista de extensiones de archivo predeterminada del motor de análisis. No existe una lista de extensiones de archivo predefinida para cada protocolo.

Configure el analizador de AV para analizar el tráfico de IMAP por extensiones y excluir los archivos con las siguientes extensiones: .ace, .arj y .chm.

WebUISecurity > Antivirus > Ext-list >New > Introduzca el nombre de la lista de extensiones (elist1) e introduzca la lista de extensiones (ace;arj;chm). Haga clic en OK.

Security > Antivirus >Profile > Seleccione el perfil a Edit > Seleccione IMAP > Seleccione las siguientes opciones, luego haga clic en OK:

EnableScan Mode: Scan by ExtensionExclude Extension List: elist1

CLIset av extension-list elist1 ace;arj;chmset av profile test1(av:test1)-> set imap scan-mode scan-ext(av:test1)-> set imap extension-list exclude elist1

Análisis de AV basado en el tipo de contenido de HTTP

Utilice esta opción para determinar qué tráfico de HTTP debe pasar por el análisis AV. El tráfico HTTP se categoriza en los tipos de extensiones de correo de Internet multiuso (MIME) predefinido y predeterminado tales como application/x-director, application/pdf, image y así sucesivamente.

Puede configurar el perfil de AV para que omita las listas de MIME que contienen los tipos de MIME específicos. La lista MIME predefinida y predeterminada es ns-skip-mime-list. La transferencia de archivos de Yahoo Messenger ignora las extensiones de MIME especificados en la lista de MIME ya que la utiliza el protocolo HTTP. Como parte de la operaicón HTTP GET/PUT, el encabezado del tipo de contenido se especifica como texto o html para todos los archivos.

En este ejemplo, configurará el dispositivo de seguridad para que busque todos los tipos de tráfico de HTTP sin tomar en cuenta los tipos de contenido de MIME.



94

WebUISecurity > Antivirus > Profile >Seleccione el perfil para la opción Edit > Seleccione HTTP y elimine la selección de la opción Skipmime Enable. Haga clic en OK.

CLIset av profile jnpr-profile(av:jnpr-profile)-> unset av http skipmime(av:jnpr-profile)-> exitsave

Para obtener información adicional sobre los tipos de MIME, consulte el manual ScreenOS CLI Reference Guide IPv4 Command Descriptions.

Notificar el remitente y destinatario por medio de correo electrónico

La opción de notificación por correo electrónico se aplica únicamente a los protocolos IMAP, POP3 y SMTP. Puede configurar el perfil de AV para notificar la información de análisis de virus y errores a los remitentes y destinatarios.

Cuando se encuentra un virus en un mensaje de correo electrónico, el contenido del mensaje de advertencia (nombre del virus, IP de origen/destino) se incluye en el mensaje de nivel de notificación. El mensaje de nivel de advertencia se envía por medio de correo electrónico a través del protocolo SMTP.

Cuando ocurre un error de análisis en un mensaje, el contenido del mensaje de error de análisis se debe incluir en el mensaje de nivel de advertencia. Este mensaje se envía por medio de correo electrónico a través del protocolo SMTP.

En este ejemplo, usted configura el dispositivo de seguridad para que realice lo siguiente:

Notificar al remitente cuando se detecte un virus

Notificar al remitente y al destinatario si ocurren errores de análisis

WebUISecurity > Antivirus > Profile > Selecciones el perfil a Edit > Seleccione IMAP y luego haga clic en OK.

Introduzca los siguientes datos y haga clic en OK:Protocols to be scanned:

Email Notify > Select Virus SenderEmail Notify > Select Scan-error SenderEmail Notify > Select Scan-error Recipient

CLIset av profile jnpr-profile(av:jnpr-profile)-> set imap email-notify virus sender(av:jnpr-profile)-> set imap email-notify scan-error sender(av:jnpr-profile)-> set imap email-notify scan-error recipient(av:jnpr-profile)-> exitsave

Análisis antivirus


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

En este ejemplo configuraremos el analizador AV para que descomprima el tráfico de HTTP hasta un máximo de tres archivos comprimidos unos dentro de otros. También se configura el analizador para que descarte el contenido si los archivos recibidos simultáneamente son más de cuatro o si el tamaño del contenido descomprimido es superior a 12 MB. El tamaño total del contenido del archivo descomprimido que ScreenOS puede manejar depende del dispositivo, con un valor mínimo de 10 MB.

Los valores predeterminados para el número máximo de mensajes simultáneos y el tamaño máximo de la cola indican que el analizador AV puede examinar un total de 256 mensajes simultáneos. El mensaje número 257 se descarta o se deja pasar de acuerdo con la configuración.

WebUISecurity > Antivirus > Scan Manager: Introduzca los siguientes datos y haga clic en OK:

Content Oversize: Drop Max Content Size: 3000 KB (20~10000)Msg Overflow: Drop Max Concurrent messages is 256

Security > Antivirus > Profile: Seleccione Edit > HTTP: Introduzca los siguientes datos y haga clic en OK:

File decompression: 3 layers (1~4)

CLIset av scan-mgr max-msgs dropset av scan-mgr max-content-size 3000set av scan-mgr max-content-size dropset av profile jnpr-profile(av:jnpr-profile)-> set http decompress-layer 3(av:jnpr-profile)-> exitsave

Filtrado anti spam

El spam consiste en mensajes de correo electrónico indeseados, generalmente enviados por entidades comerciales, maliciosas o fraudulentas. La función de antispam examina los mensajes transmitios para identificar cuáles son spam. Cuando el dispositivo detecta un mensaje que parece ser spam, lo etiqueta en el campo de mensaje con una cadena programada previamente o descarta el mensaje.

NOTA: El valor predeterminado para el tamaño del contenido del archivo descomprimido es un valor por mensaje y no la suma del total de los mensajes simultáneos que se están analizando.

Filtrado anti spam 95


96

Esta función antispam no reemplaza al servidor antispam sino que lo complementa. Al configurar este comando se impide que un servidor de correo electrónico corporativo interno reciba y distribuya spams. Los usuarios corporativos consultan los correos electrónicos desde el servidor de correo electrónico interno sin pasar por el cortafuegos. Ésta es una configuración típica en un entorno empresarial.

El antispam de Juniper Networks utiliza un servicio de bloqueo de spam según IP que se actualiza constantemente y que utiliza la información compartida a nivel mundial. Debido a que este servicio es sólido y rinde muy pocos resultados positivos falsos, no es necesario sintonizar o configurar listas negras. No obstante, existe la opción de agregar dominios e IP específicos a las listas negras o listas blancas locales, que es posible aplicar localmente el dispositivo.

Para evitar o reducir el volumen de los mensajes de spam recibidos, puede configurar un perfil antispam. Puede utilizar el perfil en las directivas para detectar y filtrar los mensajes spam en sospecha. Un perfil antispam le permite designar listas de direcciones de IP, correos electrónicos, nombres de hosts o nombres de dominios, designados como maliciosos (spam) o benignos (no spam). El perfil antispam puede incluir listas de los siguientes tipos:

Listas públicas blancas o negras

Si la conexión es desde un agente de redireccionamiento de correo, el dispositivo puede filtrar la dirección de IP de origen de la conexión utilizando las listas de dispositivos considerados benignos (lista blanca) o maliciosos (lista negra).

Listas blancas o negras personalizadas

Listas negras o listas blancas basadas en nombres de dominios.

El dispositivo puede utilizar dichas listas para filtrar las conexiones que utilizan las nombres de dominios que parecen ser benignos o maliciosos.

Listas negras o listas blancas basadas en libros de direcciones.

El dispositivo puede utilizar dichas listas para basar el filtrado en el dominio o dirección de correo electrónico del remitente. De forma predeterminada, cualquier servidor de correo electrónico debería aceptar su propio correo electrónico de usuario.

Listas blancas y listas negrasLa función antispam requiere que el cortafuegos tenga conectividad de Internet con el servidor de lista de bloqueo de spam (SBL). El servicio de nombres de dominio (DNS) debe estar disponible para tener acceso al servidor SBL. El cortafuegos realiza consultas de DNS inversas en el origen del remitente de SMTP (o agente de retransmisión), agregando el nombre del servidor de SBL (tal como sbl-server) como el dominio autoritario. El servidor de DNS reenvía entonces cada petición al servidor de SBL, el cual devuelve un valor al cortafuegos.

NOTA: Esta versión admite antispam únicamente para el protocolo SMTP.

Filtrado anti spam


Si lo prefiere, puede configurar listas blancas y negras locales. En este caso, de forma predeterminada el sistema revisa primero la base de datos local de las listas negras/blancas. Si no encuentra el nombre del host, el cortafuegos continúa la consulta del servidor SBL que se encuentra en Internet.

Configuración básicaLos siguientes comandos proporcionan un ejemplo de la configuración antispam básica en la cual se protege al servidor smtp (o servidor retransmisor) impidiendo que reciba correo electrónico spam.

set anti-spam profile ns-profileset policy from untrust to trust any mail-server SMTP permit log anti-spam

ns-profile

En el siguiente ejemplo, el cortafuegos revisa spammer.org para ver si ésta se encuentra en la lista blanca o la lista negra.

exec anti-spam testscan spammer.org

Si la lista negra contiene spammer.org, el dispositivo puede producir el siguiente resultado:

AS: anti spam result: action Tag email subject, reason: Match local blacklist

De manera alterna, si la lista blanca contiene spammer.org, el dispositivo puede producir el siguiente resultado:

AS: anti spam result: action Pass, reason: Match local whitelist

Para obtener información sobre la creación de las listas negras o listas blancas, consulte “Definición de una lista negra” en la página 98 y “Definición de una lista blanca” en la página 98.

Filtrado del tráfico spamEn los siguientes ejemplos, el tráfico de SMTP que contiene spam atraviesa el dispositivo de seguridad. Sin embargo, ScreenOS revisa si hay spam por el nombre de DNS o dirección IP.

Los siguientes comandos proporcionan un ejemplo de cómo filtrar tráfico spam.

device-> exec anti-spam test 2.2.2.2AS: anti spam result: action Tag email subject, reason: Match local black listexec anti-spam testscan spammer.orgAS: anti spam result: action Tag email subject, reason: Match local black list

Descarte de los mensajes de spamAl ejecutar el comando set anti-spam profile ns-profile sin especificar opciones posteriores coloca al CLI dentro del contexto de un perfil antispam nuevo o ya existente. Por ejemplo, los siguientes comandos definen un perfil denominado ns-profile y luego introducen el contexto de ns-profile para indicar al dispositivo que deniegue los mensajes que se sospecha que son spam:

device-> set anti-spam profile ns-profiledevice(ns-profile)-> set default action drop



98

Después de introducir un contexto antispam, todas las ejecuciones de comandos subsecuentes modifican el perfil antispam (ns-profile en este ejemplo). Para guardar sus cambios, debe salir primero del contexto antispam y luego introducir el comando save:

device(ns-profile)-> exitdevice-> save

Definición de una lista negraUtilice los comandos de la lista negra para agregar o eliminar una dirección IP, dirección de correo electrónico, nombre de host o nombre de dominio de la lista negra antispam local. Cada entrada en una lista negra puede identificar un spammer.

Para definir una lista negra, realice los siguientes pasos:

1. Inicie el contexto de un perfil (ns-profile).

2. Proporcione el perfil de una entrada de lista negra que evite las conexiones con el nombre de host www.wibwaller.com.

3. Salga del contexto de spam y aplique el perfil a una directiva existente (id 2).

device-> set anti-spam profile ns-profiledevice(anti-spam:ns-profile)-> set blacklist www.wibwaller.comdevice(anti-spam:ns-profile)-> exitdevice-> set policy id 2 anti-spam ns-profile

Definición de una lista blancaUtilice los comandos de la lista blanca para agregar o eliminar una dirección IP, una dirección de correo electrónico, nombre de host o nombre de dominio de la lista blanca antispam local. Cada entrada de una lista blanca puede identificar una entidad de la que no se sospeche el envío de spam. La siguiente tabla muestra algunas entradas posibles.

Para definir una lista blanca, realice los siguientes pasos:

1. Inician el contexto de un perfil (ns-profile).

2. Proporcione el perfil a una entrada de lista blanca que permita las conexiones con el nombre de host www.fiddwicket.com.


device-> set anti-spam profile ns-profiledevice(anti-spam:ns-profile)-> set whitelist www.fiddwicket.comdevice(anti-spam:ns-profile)-> exitdevice-> set policy id 2 anti-spam ns-profile

Filtrado anti spam


Definición de una acción predeterminadaUtilice los comandos predeterminados para especificar la manera en la cual el dispositivo maneja los mensajes que parecen ser spam. El dispositivo puede descartar un mensaje spam o identificarlo como spam al etiquetarlo.

Puede colocar una etiqueta en el encabezado del mensaje o en la línea de asunto.

Para definir la acción predeterminada en caso de spam, realice las siguientes tareas.


2. Especifique que los mensajes de correo electrónico que parecen ser spam incluyan la cadena “Esto es spam” en el encabezado del mensaje.


device-> set anti-spam profile ns-profiledevice(anti-spam:ns-profile)-> set default action tag header “Esto es spam”device(anti-spam:ns-profile)-> exitdevice-> set policy id 2 anti-spam ns-profile

Habilitación de un servidor con lista de bloqueo de spamUtilice el comando sbl para activar el uso del servicio SBL de bloqueo de spam externo, el cual utiliza una lista negra para identificar los orígenes de spam conocidos. Este servicio responde a las consultas del dispositivo sobre si una dirección IP pertenece a un spammer conocido.

Ejemplo: Estos comandos realizan las siguientes tareas:


2. Active el uso del servicio anti spam predeterminado.


device-> set anti-spam profile ns-profiledevice(anti-spam:ns-profile)-> set sbl default-server-enabledevice(anti-spam:ns-profile)-> exitdevice-> set policy id 2 anti-spam ns-profile

Prueba del sistema antispamUtilice el comando, exec anti-spam testscan <dir_IP> para que el dispositivo de seguridad busque direcciones IP de spammer conocidos.

Ejemplo: Estos comandos examinan las direcciones de IP 12.13.2.3 en busca de spam:

device-> set console dbuf device-> exec anti-spam testscan 12.13.2.3device-> get dbuf streamanti spam result: action Pass, reason: No match



100

Filtrado de Web

El filtrado de Web le permite administrar el acceso a Internet impidiendo el acceso a contenido Web inapropiado. ScreenOS proporciona dos soluciones de filtrado de Web:

Integrado

Algunos dispositivos de seguridad admiten una solución de filtrado de Web integrado que utiliza servidores de autoridad del portal de contenido (CPA) de SurfControl.

El filtrado de web integrado permite admitir o bloquear el acceso a un sitio solicitado mediante la asociación de un perfil de filtrado de Web a una directiva de cortafuegos. Un perfil de filtrado de Web especifica las categorías de URL y la acción que toma el dispositivo de seguridad (permitir o bloquear) cuando recibe una petición para acceder a una URL en cada categoría. Las categorías de URL son predefinidas y mantenidas por SurfControl o definidas por el usuario. Para obtener más información sobre cómo configurar la función de filtrado de Web integrado, consulte “Filtrado de Web integrado” en página 101.

Reenvío

Algunos dispositivos de seguridad admiten una solución de filtrado de Web que emplea los servicios de SurfControl y Websense en un servidor SurfControl o Websense.

En el filtrado de Web mediante reenvío, el dispositivo de seguridad envía la solicitud HTTP en una conexión TCP a un servidor Websense o a un servidor SurfControl, esto permite bloquear o permitir el acceso a diferentes sitios basándose en las URL, nombres de dominio y direcciones IP. Para obtener más información sobre cómo configurar la función de filtrado de Web desviado, consulte “Redireccionamiento del filtrado de Web” en página 110.

Uso de la CLI para iniciar los modos de filtrado de WebPuede utilizar WebUI o CLI para configurar el dispositivo de seguridad para filtrado de Web. Si utiliza CLI, debe realizar los siguientes pasos para configurar cualquiera de las dos soluciones de filtrado de Web:

1. Seleccionar el protocolo.

Por ejemplo, el comando set url protocol type { sc-cpa | scfp | websense } selecciona el protocolo.

NOTA: El filtrado de Web integrado requiere que se instale una clave de licencia en el dispositivo de seguridad.

NOTA: Utilice el filtrado de Web integrado para administrar el tráfico HTTPS. El filtrado de Web desviado no admite el tráfico HTTPS.

Filtrado de Web


2. Iniciar el modo de filtrado de Web.

Ejecutar el comando set url protocol { sc-cpa | scfp | websense } coloca a la CLI en el contexto de filtrado de Web. Una vez que se ha iniciado el contexto de filtrado de Web, todas las ejecuciones de comandos posteriores se aplican a ese modo de filtrado de Web.

La Tabla 3 muestra los comandos para entrar y salir de los tres diferentes modos de filtrado de Web.

Tabla 3: Entrada y salida de los modos de filtrado de Web

Filtrado de Web integradoPara habilitar el filtrado de Web, primero debe enlazar un perfil de filtrado de Web a una directiva de cortafuegos. Con el filtrado de Web integrado, el dispositivo de seguridad Juniper Networks intercepta cada petición http, determina si permite o bloquea el acceso a un sitio solicitado categorizando su URL, luego comprar la categoría de URL con un perfil de filtrado de Web. Un perfil de filtrado de Web define la acción que toma el dispositivo de seguridad (permitir o bloquear) cuando recibe una petición para acceder a una URL.

Una categoría de URL es una lista de URL organizadas por contenido. Los dispositivos de seguridad utilizan las categorías URL predefinidas de SurfControl para determinar la categoría de una URL solicitada. Los servidores de la autoridad del portal de contenido (CPA) de SurfControl mantienen las bases de datos más grandes de todos los tipos de contenido de web clasificado en unas 40 categorías. Una lista parcial de categorías URL se muestra en la “Definición de categorías URL (opcional)” en página 104.

Para obtener una lista completa de las categorías URL de SurfControl, visite el sitio Web de SurfControl en http://www.surfcontrol.com. Adicionalmente a las categorías de URL predefinidas de SurfControl, también se pueden agrupar las URL y crear categorías de acuerdo con sus necesidades. Para obtener más información sobre cómo crear categorías definidas por el usuario, consulte “Definición de categorías URL (opcional)” en página 104.

Filtrado de Web integrado

Reenviar a servidor SurfControl

Reenviar a servidor Websense

1. Seleccionar el protocolo

set url protocol type sc-cpa set url protocol type scfp set url protocol type websense

2. Iniciar el contexto de filtrado de Web

set url protocol sc-cpa

(url:sc-cpa)-> :

set url protocol scfp

(url:scfp)-> :

set url protocol websense

(url:websense)-> :

3. Salir del modo de filtrado de Web

(url:sc-cpa)-> :exit (url:scfp)-> :exit (url:websense)-> :exit

Filtrado de Web 101

http://www.surfcontrol.com



102

A continuación se muestra la secuencia básica de eventos que se produce cuando un host en la zona Trust intenta establecer una conexión HTTP con un servidor en la zona Untrust.

1. El dispositivo de seguridad comprueba si hay una directiva de cortafuegos que aplique al tráfico:

Si no existe una directiva de cortafuegos para el tráfico, el dispositivo descarta el tráfico.

Si existe una directiva de cortafuegos y si el filtrado de Web está activo en esa directiva, el dispositivo intercepta las peticiones de HTTP.

2. El dispositivo comprueba si existe un perfil definido por el usuario enlazado a una directiva de cortafuegos. Si no existe, entonces utiliza el perfil predeterminado, ns-profile.

3. El dispositivo determina si la categoría de la URL solicitada ya está en caché. Si no es así, el dispositivo envía la URL al servidor CPA de SurfControl para la categorización y pone en caché el resultado.

4. Una vez el dispositivo determina la categoría de la URL, comprueba si la categoría está en el perfil de filtrado de Web enlazado con la directiva de cortafuegos.

Si la categoría está en el perfil, el dispositivo bloquea o permite el acceso a la URL según se define en el perfil.

Si la categoría no está en el perfil, el dispositivo realiza la acción predeterminada configurada.

Esta sección trata sobre los siguientes temas de filtrado de Web integrado:

“Servidores de SurfControl” en página 102

“Redireccionamiento del filtrado de Web” en página 110

“Caché de filtrado de Web” en página 103

“Configuración del filtrado de Web integrado” en página 103

“Ejemplo: Filtrado de Web integrado” en página 109

Servidores de SurfControlSurfControl tiene tres centros de servidores, cada una de las cuales sirve a un área geográfica específica: América, Pacífico del Asia y Europa/Medio Este/África. El servidor predeterminado principal es el de América, y el servidor de respaldo predeterminado es Asia-Pacífico. Puede cambiar el servidor principal y el dispositivo de seguridad selecciona automáticamente un servidor de respaldo, basado en el servidor principal. (El servidor de Asia-Pacífico es el respaldo para el servidor de América, el cual es el respaldo para los otros dos servidores).

Filtrado de Web


El servidor CPA de SurfControl actualiza periódicamente su lista de categorías. Ya que el servidor de CPA no notifica a sus clientes cuando se actualiza la lista, el dispositivo de seguridad debe revisar periódicamente el servidor de CPA. De forma predeterminada, el dispositivo consulta el servidor de CPA para conocer las actualizaciones de categoría cada dos semanas. Se puede cambiar este valor predeterminado para que se ajuste al entorno de sus conexiones en red. También puede actualizar manualmente la lista de categorías al introducir el contexto de filtrado de Web y ejecutar el comando exec cate-list-update. Para actualizar manualmente la lista de categoría, realice lo siguiente:

device-> set url protocol sc-cpadevice(url:sc-cpa)-> exec cate-list-update

Caché de filtrado de WebDe forma predeterminada, el dispositivo de seguridad guarda en caché las categorías de las URL. Esta acción reduce los costos operativos al acceder al servidor de CPA de SurfControl cada vez que el dispositivo recibe una nueva petición para las URL solicitadas previamente. Se puede configurar el tamaño y la duración de la memoria caché, de acuerdo con los requisitos de funcionamiento y de memoria de su entorno de conexiones en red. El tamaño de caché predeterminado depende de la plataforma y el tiempo de espera predeterminado es de 24 horas.

En este ejemplo, cambiar´s el tamaño de caché a 500 kilobytes (KB) y el valor de tiempo de espera a 18 horas.

WebUI

Security > Web Filtering > Protocol Selection > Seleccione Integrated (SurfControl) y luego haga clic en Apply.

Enable Cache: (seleccione)Cache Size: 500 (K)Cache Timeout: 18 (Hours)

CLI

device-> set url protocol sc-cpadevice(url:sc-cpa)-> set caché size 500device(url:sc-cpa)-> set caché timeout 18device(url:sc-cpa)-> exitdevice-> save

Configuración del filtrado de Web integradoPara configurar un dispositivo de seguridad para filtrado de Web, realice los siguientes pasos:

1. “Establecimiento de un servidor de nombres de dominio” en página 104

2. “Habilitación del filtrado de Web” en página 104

3. “Definición de categorías URL (opcional)” en página 104

4. “Definición de perfiles de filtrado de Web (opcional)” en página 106

5. “Habilitación del perfil y la directiva de filtrado de Web” en página 108

Filtrado de Web 103


104

Cada paso se describe detalladamente en las siguientes secciones.

1. Establecimiento de un servidor de nombres de dominioEl dispositivo de seguridad Juniper Networks es compatible con el sistema de nombres de dominio (“Domain Name System” o “DNS”), que permite utilizar tanto nombres de dominios como direcciones IP para identificar las ubicaciones de una red. Debe configurar por lo menos un servidor de DNS para que el dispositivo de seguridad resuelva el nombre del servidor de CPA a una dirección. Para obtener más información sobre DNS, consulte “Compatibilidad con DNS (sistema de nombres de dominio)” en la página 2-219.

2. Habilitación del filtrado de WebPuede utilizar los comandos CLI o WebUI para habilitar el filtrado de Web integrado en un dispositivo de seguridad. Si utiliza la CLI, debe introducir el contexto de filtrado de Web antes de introducir los comandos específicos al filtrado de Web integrado.

WebUI

Security > Web Filtering > Protocol Selection: Seleccione Integrated (SurfControl), luego haga clic en Apply. Luego seleccione Enable Web Filtering via CPA Server, y nuevamente haga clic en Apply.

CLI

device-> set url protocol type sc-cpadevice-> set url protocol sc-cpadevice(url:sc-cpa)-> set enabledevice(url:sc-cpa)-> exitdevice-> save

El indicativo device(url:sc-cpa)-> le avisa de que ha introducido el contexto de filtrado de Web integrado y puede ahora configurar los parámetros de filtrado de Web integrado.

3. Definición de categorías URL (opcional)Una categoría es una lista de URL agrupadas por contenido. Existen dos tipos de categorías: predefinidas y definidas por el usuario. SurfControl mantiene aproximadamente 40 categorías predefinidas. Una lista parcial de categorías URL se muestra en la Tabla 4 en la página 105. Para obtener una lista completa y una descripción de cada categoría de URL desarrollada por SurfControl, visite el sitio Web de SurfControl en http://www.surfcontrol.com.

Para ver la lista de categorías URL predefinidas por SurfControl, realice lo siguiente:

WebUI

Security > Web Filtering > Profiles > Predefined category

CLI

device-> set url protocol type sc-cpadevice-> set url protocol sc-cpadevice(url:sc-cpa)-> get category pre

Filtrado de Web



La lista de categorías de URL que se muestra es similar a la que se figura en la Tabla 4.

Tabla 4: Lista parcial de categorías URL de SurfControl

La lista de categorías predefinidas muestra las categorías y sus códigos internos de SurfControl. Aunque no es posible enumerar las URL dentro de una categoría, se puede determinar la categoría de un sitio Web mediante la función de “Test A Site” del sitio Web de SurfControl en www.surfcontrol.com.

Además de las categorías de URL predefinidas de SurfControl, se pueden agrupar las URL y crear categorías específicas de acuerdo con sus necesidades. Cada categoría puede tener un máximo de 20 URL. Cuando crea una categoría, puede agregar la URL o la dirección IP de un sitio. Cuando agrega una URL a una categoría definida por el usuario, el dispositivo realiza la búsqueda de DNS, resuelve el nombre de host en las direcciones IP y obtiene esta información. Cuando un usuario intenta acceder a un sitio con la dirección IP del sitio, el dispositivo comprueba la lista almacenada en caché de las direcciones IP e intenta resolver el nombre de host.

Muchos sitios tienen direcciones IP dinámicas, lo que significa que sus direcciones IP cambian periódicamente. Un usuario que intenta acceder a un sitio puede escribir una dirección IP que no está en la lista captada en el dispositivo. Por lo tanto, si conoce las direcciones IP de los sitios que está agregando a una categoría, introduzca la URL y las direcciones IP del sitio.

En el siguiente ejemplo, se crea una categoría nombrada Competidores y se agregan las siguientes URL: www.juegos1.com y www.juegos2.com

WebUI

Security > Web Filtering > Profiles > Custom > New: Introduzca los siguientes datos y haga clic en Apply:

Category Name: CompetidoresURL: www.juegos1.com


URL: www.juegos2.com

Tipo Código Nombre de la categoría

Predefinida 76 Anuncios

Predefinida 50 Artes y entretenimiento

Predefinida 3001 Chat

Predefinida 75 Informática e Internet

NOTA: Si una URL está en la categoría definida por el usuario y en una categoría predefinida, el dispositivo compara la URL con la categoría definida por el usuario.

Filtrado de Web 105


106

CLI

device-> set url protocol sc-cpadevice(url:sc-cpa)-> set category ompetidores url www.juegos1.comdevice(url:sc-cpa)-> set category competidores url www.juegos2.comdevice(url:sc-cpa)-> exitdevice-> save

4. Definición de perfiles de filtrado de Web (opcional)Un perfil de filtrado de Web consta de un grupo de categorías de URL al que se le ha asignado una de las siguientes acciones:

Permit: El dispositivo de seguridad permite siempre el acceso a los sitios Web en esta categoría.

Block: El dispositivo de seguridad bloquea el acceso a los sitios Web en esta categoría. Cuando el dispositivo bloquea el acceso a esta categoría de sitios Web, despliega un mensaje en su explorador que indica la categoría de URL.

Black List: El dispositivo de seguridad bloquea siempre el acceso a los sitios que aparecen en esta lista. Puede crear una categoría definida por el usuario o utilizar una categoría definida previamente.

White List: El dispositivo de seguridad permite siempre acceso a los sitios en la lista blanca. Puede crear una categoría definida por el usuario o utilizar una categoría definida previamente.

Los dispositivos de seguridad Juniper Networks proporcionan un perfil predeterminado denominado ns-profile. Este perfil enumera las categorías URL predefinidas de SurfControl y sus acciones correspondientes. Este perfil predeterminado no se puede editar. Para ver el perfil predefinido, utilice el siguiente comando:

WebUI

Security > Web Filtering > Profiles > Predefined

CLI

device-> set url protocol sc-cpadevice(url:sc-cpa)-> get profile ns-profile

El dispositivo de seguridad muestra el perfil predefinido como el que se muestra a continuación:

Profile Name: ns-profileBlack-List category: NingunaWhite-List category: NingunaDefault Action: Permit

Filtrado de Web


Category Action

Si la URL en una petición HTTP no está en ninguna de las categorías enumeradas en el perfil predeterminado, la acción predeterminada del dispositivo de seguridad es permitir el acceso al sitio.

Puede crear un perfil personalizado clonando un perfil ya existente, guardándolo con otro nombre y luego editándolo. Realice el siguiente paso en la WebUI para clonar ns-profile.

WebUI

Security > Web Filtering > Profiles > Custom: ns-profile: Seleccione Clone.

También puede crear su propio perfil de filtrado de Web. Cuando crea un perfil de filtrado de Web, puede:

Agregar categorías de URL predefinidas de SurfControl y definidas por el usuario

Especificar una categoría para la lista negra y la lista blanca

Cambiar la acción predeterminada

En el siguiente ejemplo, se crea un perfil personalizado denominado mi-perfil con una acción predeterminada de permit. Luego, se toma la categoría que se creó en el ejemplo anterior y se agrega a mi-perfil con una acción de block.

WebUI

Security > Web Filtering > Profiles > Custom > New: Introduzca los siguientes datos y haga clic en Apply:

Profile Name: mi-perfilDefault Action: PermitIntroduzca los siguientes datos y haga clic en OK:

Subscribers Identified by:Category Name: Competidores (seleccione)Action: Block (seleccione) Configure: Add (seleccione)

Advertisements blockArts & Entertainment permitChat permitComputing & Internet permit...Violence blockWeapons blockWeb-based Email permitother permit

NOTA: Debe utilizar WebUI para clonar ns-profile.

Filtrado de Web 107


108

CLI

device-> set url protocol type sc-cpadevice-> set url protocol sc-cpadevice(url:sc-cpa)-> set profile mi-perfil other permit device(url:sc-cpa)-> set profile mi-perfil competidores blockdevice(url:sc-cpa)-> exitdevice-> save

5. Habilitación del perfil y la directiva de filtrado de WebLas directivas de cortafuegos permiten o deniegan tipos específicos de tráfico unidireccional entre dos puntos. (Para obtener más información sobre las directivas de cortafuegos, consulte “Directivas” en la página 2-161). Puede activar el análisis de antivirus (AV) y el filtrado de web integrado en una directiva. (Para obtener información sobre el análisis AV, consulte “Análisis antivirus” en la página 62.)

Habilite el filtrado de Web en la directiva y enlace el perfil a la directiva. Cuando activa el filtrado de Web integrado en una directiva, el dispositivo de seguridad intercepta todas las peticiones de HTTP. Si existe un perfil de filtrado de Web asociado con una directiva, el dispositivo compara la URL incluida en la petición de HTTP entrante a las categorías en el perfil en la siguiente secuencia:

1. Lista negra

2. Lista blanca

3. Categorías definidas por el usuario

4. Categorías de URL predefinidas de SurfControl

Si el dispositivo no encuentra la categoría de la URL solicitada, entonces bloquea o permite el acceso a la URL, según la configuración predeterminada en el perfil.

Figura 40: Diagrama de flujo de los perfiles y directivas de filtrado de Web

NOTA: Para configurar la acción predeterminada utilizando CLI, especifique la acción para la otra categoría.

Petición de HTML

N N N N

S S S S

Bloquear URL Permitir URL Bloquear/Permitir según se defina Bloquear/Permitir según se defina

¿En lalista negra?

¿En lalista blanca?

¿Categoría definidapor el usuario?

¿Categoría definidapor el usuario?

Acción predeterminada -Bloquear/Permitir

Filtrado de Web


Si el dispositivo determina que la URL está en una categoría permitida y si el análisis AV está habilitado para esa directiva, entonces el dispositivo analiza el contenido en busca de virus. Si el dispositivo determina que la URL está en una categoría bloqueada, termina la conexión TCP, envía un mensaje de alerta al usuario y no realiza el análisis AV.

Ejemplo: Filtrado de Web integradoEn este ejemplo, realice los siguientes pasos para habilitar el filtrado de Web integrado en el dispositivo de seguridad y para bloquear el acceso a los sitios de los competidores.

1. Cree una categoría denominada Competidores.

2. Agregue las siguientes URL a la categoría: www.comp1.com y www.comp2.com.

3. Cree un perfil denominado mi-perfil y agregue la categoría Competidores.

4. Aplique mi-perfil a una directiva de cortafuegos.

WebUI

1. Filtrado de WebSecurity > Web Filtering > Protocol > Seleccione Integrated (SurfControl) y luego haga clic en Apply. Luego, seleccione Enable Web Filtering via CPA Server y nuevamente haga clic en Apply.

2. Categoría de URLSecurity > Web Filtering > Profile > Custom List > New: Introduzca los siguientes datos y haga clic en Apply:

Category Name: CompetidoresURL: www.comp1.com


URL: www.comp2.com

3. Perfil de filtrado de WebSecurity > Web Filtering > Profile > Custom Profile > New: Introduzca los siguientes datos y haga clic en Apply:

Profile Name: mi-perfilDefault Action: Permit

Category Name: Competidores (seleccione)Action: Block (seleccione)Configure: Add (seleccione)

Filtrado de Web 109


110

4. DirectivaPolicies > (From: Trust, To: Untrust) New: Introduzca los siguientes datos y haga clic en OK:

Source Address:Address Book Entry: (seleccione), Any

Destination Address:Address Book Entry: (seleccione), Any

Service: HTTPWeb Filtering: (seleccione), mi-perfilAction: Permit

CLI

1. Filtrado de Webdevice-> set url protocol sc-cpadevice(url:sc-cpa)-> set enable

2. Categoría de URL device(url:sc-cpa)-> set category competidores url www.comp1.comdevice(url:sc-cpa)-> set category competidores url www.comp2.com

3. Perfil de filtrado de Webdevice(url:sc-cpa)-> set profile mi-perfil other permit device(url:sc-cpa)-> set profile mi-perfil competidores blockdevice(url:sc-cpa)-> exit

4. Directiva de cortafuegosdevice-> set policy id 23 from trust to untrust any any http permit url-filterdevice-> set policy id 23device(policy:23)-> set url protocol sc-cpa profile mi-perfildevice(policy:23)-> exitdevice-> save

Redireccionamiento del filtrado de WebLos dispositivos de seguridad Juniper Networks admiten el redireccionamiento del filtrado de web utilizando Websense Enterprise Engine o SurfContro Web Filterl, que permiten bloquear o admitir el acceso a diferentes sitios basados en sus URL, nombres de dominio y direcciones IP. El dispositivo de seguridad se puede enlazar directamente a un servidor de filtrado de Web de SurfControl y Websense.

La Figura 41 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 Web determina que la URL solicitada está prohibida.

NOTA: Para obtener información adicional sobre Websense, visite www.websense.com. Para obtener información adicional sobre SurfControl, visite www.surfcontrol.com.

Filtrado de Web


Figura 41: Una URL bloqueada de la zona Trust a la zona Untrust

Si el servidor permite el acceso a la URL, la secuencia de acontecimientos en el intento de conexión HTTP será tal y como se indica en Figura 42.

Figura 42: Una URL permitida de la zona Trust a la zona Untrust

Cliente HTTP

set policy from trust to untrust any any http permit web-filter

Establecimiento de comunicación TCP

de 3 fases

Petición HTTP-Get

Mensaje de URL bloqueada

TCP RST

Servidor de filtrado de Web (en la zona Trust)

Petición de filtro de Web

Respuesta de filtrado de Web: “block”

Zona TrustSYN

ACK

HTTP GET

BLCK URL

RST

El dispositivo de seguridad intercepta y almacena en búfer la petición HTTP GET. A continuación envía la URL solicitada al servidor de filtrado de Web. El servidor de filtrado de Web responde con un mensaje de “bloqueo”.

El dispositivo de seguridad descarga el paquete HTTP y envía al origen un mensaje de “URL bloqueada”. Cierra la conexión, enviando un TCP RST a las direcciones de origen y destino.

RST

SYN/ACK

Zona Untrust

Servidor HTTP

Cliente HTTP

set policy from trust to untrust any http permit url-filter

Establecimiento de comunicación TCP de 3 fases

Petición HTTP-Get

Reenvío de la petición HTTP GET

Servidor de filtrado de Web (en la zona Trust)

Petición de filtrado de URL

Respuesta de filtrado de URL: “permit”

Zona TrustSYN

ACK

HTTP GET

El dispositivo de seguridad 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 “permit” (permiso).

SYN/ACK

Zona Untrust

Servidor HTTP

HTTP GET

Respuesta de HTTP

Filtrado de Web 111


112

Consulte las siguientes secciones para obtener más detalles sobre el redireccionamiento del filtrado de Web:

“Admisión del sistema virtual” en página 112

“Configuración de la redirección de filtrado de Web” en la página 113

“Ejemplo: Redirigir el filtrado de Web” en la página 116

Admisión del sistema virtualLos dispositivos de seguridad con sistemas virtuales (vsys) admiten hasta ocho servidores de filtrado de Web 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 Web para el uso privado por parte de los sistemas virtuales. Un administrador de nivel raíz puede configurar el módulo de filtrado de Web en el nivel raíz y en 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 Web dedicado. Si el administrador de nivel vsys utiliza los ajustes del servidor de filtrado de Web raíz, ese administrador puede ver, pero no editar, los ajustes de filtrado de Web de nivel raíz.

De forma alterna, los dispositivos con sistemas virtuales que utilizan los servidores de filtrado de Web Websense pueden compartir los ocho servidores de Websense, y no solamente el servidor raíz. Cada servidor de Websense puede admitir un número ilimitado de sistemas virtuales, lo que le permite equilibrar la carga de tráfico entre los ocho servidores.

Para configurar múltiples sistemas virtuales para que se conecten a un servidor de filtrado de Web Websense, el administrador de nivel raíz o vsys debe realizar lo siguiente:

1. Crear un nombre de cuenta para cada vsys. Utilizar el siguiente comando CLI:

device-> set url protocol type websensedevice-> set url protocol websensedevice(url:websense)-> set account nombre

Cuando un host en un vsys envía una petición URL, ésta incluye el nombre de cuenta. Este nombre activa el servidor Websense para que identifique que vsys envió la petición URL.

2. Configure los mismos ajustes del servidor de filtrado de Web y los parámetros de nivel del sistema para cada vsys que comparte un servidor de filtrado de Web Websense. La siguiente sección contiene información sobre la configuración de los parámetros y ajustes de filtrado de Web.

Filtrado de Web


Configuración de la redirección de filtrado de WebPara configurar un dispositivo de seguridad para filtrado de Web, realice los siguientes pasos:

1. Establezca un servidor de nombres de dominio (DNS)El dispositivo de seguridad Juniper Networks es compatible con el sistema de nombres de dominio (“Domain Name System” o “DNS”), que permite utilizar tanto nombres de dominios como direcciones IP para identificar las ubicaciones de una red. Debe configurar por lo menos un servidor de DNS para que el dispositivo de seguridad resuelva el nombre del servidor de CPA a una dirección. Para obtener más información sobre DNS, consulte “Compatibilidad con DNS (sistema de nombres de dominio)” en la página 2-219.

2. Establezca comunicación con los servidores de filtrado de WebConfigure el dispositivo de seguridad para comunicarse con uno de los siguientes servidores:

Servidor Websense

Un servidor SurfControl que utilice el protocolo de filtrado de contenido de SurfControl (SCFP).

Establezca la comunicación con un máximo de ocho servidores de filtrado de Web.

WebUI

Security > Web Filtering > Protocol > Seleccione Redirect (Websense) o Redirect (SurfControl), luego haga clic en Apply.

CLI

Introduzca el contexto de filtrado de Web para SurfControl (scfp) o Websense (websense). Para obtener más información, consulte “Uso de la CLI para iniciar los modos de filtrado de Web” en página 100.

device-> set url protocol type { websense | scfp }device-> set url protocol { websense | scfp }device(url:scfp)-> set server { dir_ip | nombre_dominio } núm_puerto

núm_tiempo_espera

Configure los siguientes ajustes de filtrado de Web en el nivel de sistema para la comunicación del servidor de filtrado de Web:

Source Interface: El origen desde el cual el dispositivo inicia las peticiones de filtro de Web a un servidor de filtrado de Web.

Server Name: La dirección IP o nombre de dominio totalmente clasificado (FQDN) del equipo en el que se ejecuta el servidor Websense o SurfControl.

Server Port: Si cambió el puerto predeterminado en el servidor, también debe cambiarlo en el dispositivo de seguridad. (El puerto predeterminado para Websense es 15868 y el puerto predeterminado para SurfControl es 62252). Para obtener detalles más completos consulte la documentación de Websense o SurfControl.

Filtrado de Web 113


114

Communication Timeout: El intervalo de tiempo, en segundos, durante el cual el dispositivo espera una respuesta del servidor de filtrado de Web. Si el servidor no responde dentro del tiempo especificado, el dispositivo bloquea o permite la solicitud. Para el intervalo de tiempo, introduzca un valor comprendido entre 10 y 240.

Si un dispositivo con varios sistemas virtuales se conecta a un servidor Websense, los sistemas virtuales pueden compartir el servidor. Para configurar varios sistemas virtuales de forma que compartan un servidor Websense, utilice el siguiente comando CLI para crear un nombre de cuenta para cada vsys:

device-> set url protocol type websensedevice-> set url protocol websensedevice(url:websense)-> set account nombre

Una vez que haya configurado los nombres de los vsys, defina los ajustes para el servidor de filtrado de Web y los parámetros para el comportamiento que desea que tome el dispositivo de seguridad cuando aplique el filtrado de Web. Si configura estos ajustes en el sistema raíz, también se aplicarán a cualquier vsys que comparta la configuración de filtrado de Web con el sistema raíz. Para un vsys, los administradores raíz y vsys deben configurar de forma separada los ajustes. Los sistemas virtuales que comparten el mismo servidor de filtrado de Web Websense debe tener los mismos ajustes de filtrado de Web.

3. Habilite el filtrado de Web a los niveles raíz y vsys.El filtrado de Web debe estar habilitado en el nivel del sistema. Para un dispositivo que actúa como host para sistemas virtuales, active el filtrado de Web para cada sistema que desea aplicar. Por ejemplo, si desea que el filtrado de Web se aplique en el sistema raíz y en vsys, deberá habilitar el filtrado de Web en ambos sistemas.

Para habilitar el filtrado de Web, realice uno de estos procedimientos:

WebUI

Security > Web Filtering > Protocol > Seleccione Redirect (Websense) o Redirect (SurfControl), y luego haga clic en Apply.

Habilite la casilla de verificación de filtrado de Web.

CLI

device-> set url protocol type { websense | scfp }device-> set url protocol { websense | scfp }device(url:scfp)-> set config enable

Cuando el filtrado de Web está activo en el nivel de sistema, las peticiones HTTP se redireccionan a un servidor Websense o SurfControl. Esta acción permite al dispositivo revisar todo el tráfico HTTP para las directivas (definidas en ese sistema) que requiere el filtrado de Web. Si deshabilita el filtrado de Web en el nivel de sistema, el dispositivo ignora el componente de filtrado de Web en las directivas y las considerará como directivas de “permiso”.

Filtrado de Web


4. Defina los parámetros de comportamiento de nivel del sistemaDefina los parámetros que desee que el sistema, raíz o vsys, utilice cuando aplique el filtrado de Web. Un conjunto de parámetros se puede aplicar al sistema raíz y a cualquier vsys que comparta la configuración de filtrado de Web con el sistema raíz. Otros conjuntos se pueden aplicar a sistemas virtuales que dispongan de su propio servidor de filtrado de Web dedicado.

Las opciones son las siguientes:

If connectivity to the server is lost: Si el dispositivo de seguridad pierde el contacto con el servidor de filtrado de Web, puede especificar si desea usar la opción de bloquear (Block) o permitir (Permit) todas las peticiones de HTTP.

Blocked URL Message Type: Si selecciona NetPartners Websense/SurfControl, el dispositivo de seguridad redirecciona el mensaje que recibió en la respuesta de bloqueo del servidor Websense o SurfControl. Si selecciona Juniper Networks, el dispositivo envía el mensaje que introduje previamente en el campo Juniper Networks Blocked URL Message.

Juniper Networks Blocked URL Message: Éste es el mensaje que el dispositivo de seguridad devuelve al usuario tras bloquear un sitio. Puede utilizar el mensaje enviado desde el servidor Websense o SurfControl o puede crear un mensaje (de hasta 500 caracteres) para que se envíe desde el dispositivo.

Para configurar los ajustes previamente mencionados, utilice lo siguiente:

WebUI


CLI

device-> set url protocol type { websense | scfp }device-> set url protocol { websense | scfp }device(url:scfp)-> set fail-mode permit device(url:scfp)-> set deny-message use-server

5. Habilite el filtrado de Web en directivas individualesConfigure el dispositivo para que se comunique con el servidor de filtrado de Web basándose en la directiva.

Para habilitar el filtrado de Web en una directiva, utilice uno de los siguientes:

WebUI

Policy > Policies > Haga clic en Edit (edite la directiva que desee que el filtrado de Web aplique), luego seleccione la casilla de verificación Web Filter.

Seleccione el perfil de filtrado de Web en el cuadro desplegable.

CLI

set policy from zone to zona dir_orig dir_dest servicio permit url-filter

NOTA: Si selecciona Juniper Networks, algunas de las funciones que ofrece Websense, como el desvío, quedarán suprimidas.

Filtrado de Web 115


116

Ejemplo: Redirigir el filtrado de WebEn este ejemplo, configurará el dispositivo de seguridad para que realice lo siguiente:

1. Establecerá las interfaces que trabajarán con el servidor SurfControl en la dirección IP 10.1.2.5, con el número de puerto 62252 (predeterminado) y con el servidor de filtrado de Web en la zona de seguridad Trust.

2. Habilitar el filtrado de Web a todo el tráfico HTTP saliente desde los hosts situados en la zona Trust hacia hosts en la zona Untrust. Si el dispositivo pierde la conectividad con el servidor de filtrado de Web, el dispositivo permite el tráfico HTTP saliente. Si un cliente HTTP solicita el acceso a una URL prohibida, el dispositivo envía el siguiente mensaje: “Lo sentimos, la dirección URL solicitada está prohibida. Póngase en contacto con [email protected].”

3. Establecer ambas zonas de seguridad para que estén en el dominio de enrutamiento trust-vr con la interfaz para la zona Untrust como ethernet3, dirección de IP 1.1.1.1/24 y la interfaz para la zona Trust como ethernet1, dirección de IP 10.1.1.1/24. Debido a que el filtrado de Web no está en una subred inmediata de una de las interfaces de dispositivo, se agregó una ruta a ésta a través de ethernet1 y el enrutador interno en 10.1.1.250.

4. Configurar las directivas para habilitar el filtrado de Web de manera que de Trust a Untrust se permita el servicio HTTP desde cualquier dirección de origen y cualquier dirección de destino,

WebUI

1. InterfacesNetwork > Interfaces > List >Edit (para ethernet1): Introduzca los siguientes datos y haga clic en Apply:



Interface Mode: NAT

Network > Interfaces > List >Edit (para ethernet3): Introduzca los siguientes datos y haga clic en OK:


NOTA: El dispositivo informa sobre el estado del servidor Websense o SurfControl. Para actualizar el informe de estado, haga clic en el icono Server Status en WebUI:


Filtrado de Web


2. Servidor de filtrado de WebSecurity > Web Filtering > Protocol: Select Redirect (SurfControl), luego haga clic en Apply. Luego, introduzca los siguientes datos y haga clic nuevamente en Apply:

Enable Web Filtering: (seleccione)Server Name: 10.1.2.5Server Port: 62252Communication Timeout: 10 (segundos)If connectivity to the server is lost … all HTTP requests: PermitBlocked URL Message Type: Juniper NetworksJuniper Blocked URL Message: Lo sentimos, la dirección URL solicitada está

prohibida. Póngase en contacto con [email protected].

3. RutasNetwork > Routing > Destination > trust-vr New: Introduzca los siguientes datos y haga clic en OK:

Network Address/Netmask: 0.0.0.0/0Gateway: (seleccione)Interface: ethernet3Gateway IP Address: 1.1.1.250

Network > Routing > Destination > trust-vr New: Introduzca los siguientes datos y haga clic en OK:

Network Address/Netmask: 10.1.2.0/24Gateway: (seleccione)Interface: ethernet1Gateway IP Address: 10.1.1.250

4. DirectivaPolicy > Policies > (From: Trust, To: Untrust) New: Introduzca los siguientes datos y haga clic en OK:

Source Address:Address Book Entry: (seleccione), AnyDestination Address:Address Book Entry: (seleccione), AnyService: HTTPAction: PermitWeb Filtering: (seleccione)

Filtrado de Web 117


118

CLI

1. Interfacesset interface ethernet1 zone trustset interface ethernet1 ip 10.1.1.1/24set interface ethernet3 zone untrustset interface ethernet3 ip 1.1.1.1/24

2. Servidor de filtrado de Webdevice-> set url protocol type scfpdevice-> set url protocol scfpdevice(url:scfp)-> set server 10.1.2.5 62252 10device(url:scfp)-> set fail-mode permit device(url:scfp)-> set deny-message “Lo sentimos, la dirección URL solicitada está

prohibida. Póngase en contacto con [email protected].”device(url:scfp)-> set config enable

3. Rutasset vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250set vrouter trust-vr route 10.1.2.0/24 interface ethernet1 gateway 10.1.1.250

4. Directivaset policy from trust to untrust any any http permit url-filtersave

Filtrado de Web

Capítulo 5

Deep Inspection

Puede habilitar Deep Inspection (DI) en directivas para examinar el tráfico permitido y realizar las acciones correspondientes si el módulo DI en ScreenOS detecta signos de ataque o anomalías en el protocolo. En las siguientes secciones de este capítulo se presentan los elementos de DI que aparecen en las directivas y se explica la manera de configurarlos:

“Vista general” en la página 120

“Servidor de la base de datos de objetos de ataque” en la página 124

“Objetos de ataque y grupos” en la página 132

“Protocolos admitidos” en la página 133

“Firmas completas” en la página 137

“Firmas de secuencias TCP” en la página 138

“Anomalías en el protocolo” en la página 138

“Grupos de objetos de ataque” en la página 139

“Desactivación de objetos de ataque” en la página 142

“Acciones de ataque” en la página 143

“Acciones de ataques de fuerza bruta” en la página 151

“Registro de ataques” en la página 154

“Asignación de servicios personalizados a aplicaciones” en la página 156

“Objetos de ataque y grupos personalizados” en la página 160

“Objetos de ataque de firma completa que define el usuario” en la página 160

“Objetos de ataque de la firma de la secuencia de TCP” en la página 165

“Parámetros configurables de anomalías en protocolos” en la página 167

“Negación” en la página 168

119


120

DI 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 173

“Controles ActiveX” en la página 173

“Applets de Java” en la página 174

“Archivos EXE” en la página 174

“Archivos ZIP” en la página 174

Vista general

Deep Inspection (DI) es un mecanismo para filtrar el tráfico permitido por el cortafuegos de Juniper Networks. DI examina los encabezados de los paquetes de la capa 3 y la capa 4, así como las características del protocolo y el contenido a nivel de aplicación de la capa 7 para detectar e impedir cualquier ataque o comportamiento anómalo que pueda presentarse. La Figura 43 muestra la manera en la cual pasa un paquete por la inspección de la capa 3.

NOTA: Los dispositivos de seguridad de Juniper Networks detectan patrones de tráfico anómalos en la capa 3 y la capa 4 (IP y TCP) a través de las opciones SCREEN establecidas a nivel de zonas, no a nivel de directivas. Algunos de los ejemplos de detección de anomalías en el tráfico de IP y TCP son “Barrido de direcciones IP” en la página 8, “Barrida de puertos” en la página 9 así como los diversos ataques de inundación descritos en “Ataques DoS contra la red” en la página 37.

Vista general

Capítulo 5: Deep Inspection

Figura 43: Inspección activa del cortafuegos

Cuando el dispositivo de seguridad 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 la capa 3) y tanto los números de puerto de origen y de destino como el protocolo en el segmento de TCP o en el encabezado del datagrama del UDP (inspección de la capa 4). Si los componentes de la capa 3 y 4 cumplen con los criterios especificados en una directiva, el dispositivo aplica al paquete la acción especificada: permitir, rechazar o encapsular. Cuando el dispositivo 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 pertenece a la sesión.

Inspección activa del cortafuegos ¿Cumple?

Descartar el paquete

Sí

¿Se permite?

¿Cumple un paquete inicial de una sesión con los requisitos L3 y L4 de una directiva?

O bien...

¿Cumple con las expectativas en la tabla de sesiones el estado de un paquete en una sesión existente?

¿Permite o rechaza la directiva este paquete?

Firma completa, anomalías en protocolos y (en algunos el dispositivo de seguridad)

Realizar acción de respuesta al ataque

¿Se detectó un ataque?¿DI?

No

Reenviar el paquete

Sí

Sí

No

No

Sí

No

Inspección de secuencia de TCP

Descartar el paquete

NOTA: Si la acción especificada es encapsular, ésta implica un permiso (tráfico permitido). Observe que si habilita DI en una directiva cuya acción sea encapsular, el dispositivo de seguridad ejecuta las operaciones de DI especificadas antes de la encriptación de un paquete saliente y tras la desencriptación de un paquete entrante.

Vista general 121


122

Si en la directiva aplicable a este paquete está habilitado DI y la acción de la directiva es “permit” o “tunnel”, el dispositivo de seguridad analiza más detenidamente tanto el paquete como la secuencia de datos asociada en busca de ataques. Analiza el paquete en busca de patrones que coincidan con los definidos en uno o más grupos 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 de seguridad desde un servidor de base de datos. (Para obtener más información, consulte “Objetos de ataque y grupos” en la página 132 y “Objetos de ataque y grupos personalizados” en la página 160).

Según los objetos de ataque especificados en la directiva, el dispositivo de seguridad puede realizar las siguientes inspecciones (consulte la Figura 44):

Examinar los valores del encabezado y los datos de carga en busca de firmas completas de ataque

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 alguien lo alteró, posiblemente con fines malintencionados

Figura 44: Comparación entre inspección del cortafuegos y Deep Inspection

Si el dispositivo de seguridad detecta un ataque, realiza la acción especificada para el grupo de objetos de ataque a la que pertenece el objeto de ataque correspondiente: cerrar (“close”), cerrar cliente (“close-client”), cerrar servidor (“close-server”), descartar (“drop”), descartar paquete (“drop-packet”), ignorar (“ignore”) o ninguna. Si no encuentra ningún ataque, reenvía el paquete. (Para obtener más información sobre las acciones de ataque, consulte “Acciones de ataque” en la página 143).

NOTA: La función Deep Inspection (DI) está disponible después que el usuario obtiene y descarga una clave de licencia de modo avanzado. (Si se actualiza a partir de una versión anterior a la 5.0.0 de ScreenOS, el modo automáticamente se convierte en “avanzado”. En este caso, no se necesita la clave de licencia de modo avanzado). Para poder descargar paquetes de firmas 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 suscripción” en la página 2-254.

Primero: Inspección del cortafuegos (Capas de red): IP ORIG, IP DEST, PTO ORIG, PTO DEST

Cortafuegos

Después: Deep Inspection (Capas de red y aplicación): IP ORIG, IP DEST, PTO ORIG, PTO DEST

Deep Inspection

Servicio (Protocolo) y datos transportadosy servicio (Protocolo)

Datos de cargaIP ORIG IP DEST PTO ORIG PTO DEST PROTO IP ORIG IP DEST PTO ORIG PTO DEST PROTO

Datos de carga

Vista general


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 más servicios y una acción.

El componente DI ordena al dispositivo de seguridad examinar el tráfico permitido por medio de la sección central de la directiva para saber si hay patrones que coincidan con los objetos de ataque que se encuentran en uno o más de los grupos de objetos de ataque. Si el dispositivo de seguridad detecta un objeto de ataque, ejecuta posteriormente la acción definida por el grupo correspondiente.

El siguiente comando set policy contiene un componente de DI:

Figura 45: El componente de DI en el comando Set Policy

El comando anterior ordena al dispositivo de seguridad permitir el tráfico de 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 examinar todo el tráfico de HTTP que esta directiva permite. Si algún patrón en el tráfico coincide con un objeto de ataque definido en el grupo de objetos de ataque “HIGH:HTTP:ANOM”, el dispositivo cierra la conexión rechazando el paquete y enviando notificaciones de RST de TCP al host en las direcciones de origen y de destino.

Es posible introducir el contexto de una directiva existente utilizando su número de identificación. Por ejemplo:

device-> set policy id 1device(policy:1)->

NOTA: Opcionalmente, también puede agregar otras extensiones al componente central de un comando set policy: las referencias a túneles de VPN y L2TP, referencia a un programa, 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. Dado 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 dir_orig dir_dst servicio acción. Encontrará más información acerca de las directivas globales en “Directivas globales” en la página 2-164.)

set policy id 1 from untrust to dmz any websrvl http permit attack HIGH:HTTP action close

Acción si el tráfico cumple con los criterios de los

componentes de L3 y L4

Grupo de ataque Acción si el dispositivo

de seguridad detecta un ataque

Componente de Deep Inspection

Servicio



Zona de destino

Zona de origen

Sección central de una directiva

Vista general 123


124

La introducción de un contexto de directiva resulta práctica si desea introducir varios comandos relacionados con una sola directiva. Por ejemplo, el siguiente conjunto de comandos crea una directiva que permite el tráfico de 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 alta y crítica:

device-> set policy id 1 from untrust to dmz any websrv1 http permit attack CRITICAL:HTTP:ANOM action close

device-> set policy id 1device(policy:1)-> set dst-address websrv2device(policy:1)-> set service httpsdevice(policy:1)-> set attack CRITICAL:HTTP:SIGS action close-serverdevice(policy:1)-> set attack HIGH:HTTP:ANOM action dropdevice(policy:1)-> set attack HIGH:HTTP:SIGS action close-serverdevice(policy:1)-> exitdevice-> save

La configuración anterior permite el tráfico de HTTP y HTTPS, pero solamente busca posibles ataques en el tráfico de HTTP. Para poder agregar grupos de objetos de ataque dentro de un contexto de directiva, primero debe especificar un ataque y una acción de DI en el comando de nivel superior. En el ejemplo anterior, puede agregar los grupos de objetos de ataque CRITICAL:HTTP:SIGS, HIGH:HTTP:ANOM y HIGH:HTTP:SIGS porque anteriormente configuró la directiva para DI con el grupo CRITICAL:HTTP:ANOM.

Servidor de la base de datos de objetos de ataque

El servidor de 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. Juniper Networks almacena la base de datos de objetos de ataque en un servidor en la dirección https://services.netscreen.com/restricted/sigupdates.

Paquetes de firmas predefinidasLa base de datos de objetos de ataque está organizada en cuatro paquetes de firmas, que son: protección del cliente, protección del servidor, paquete básico y mitigación de gusanos. Este enfoque es ideal debido a la limitada memoria del dispositivo y al mayor soporte del protocolo en los paquetes de firmas. En la Tabla 5 se describe cada uno de los paquetes de firmas predefinidas y la cobertura de la amenaza.

NOTA: El símbolo de la línea de comandos cambia para indicar que el siguiente comando se ejecutará dentro de un contexto de directiva determinado.

NOTA: Puede especificar una acción de ataque diferente para cada grupo de objetos de ataque en una directiva. Si el dispositivo de seguridad detecta simultáneamente ataques múltiples, aplica la acción más grave, que en el ejemplo anterior es “close”. Para obtener información sobre las siete acciones de ataque, que incluyen los niveles de gravedad, consulte “Acciones de ataque” en la página 143.



Tabla 5: Paquetes de firmas predefinidas

La Tabla 6 enumera los paquetes de firmas predefinidas con las URL correspondientes.

Tabla 6: URL para paquetes de firmas predefinidas

Actualización de paquetes de firmasJuniper Networks almacena los cuatro paquetes de firmas predefinidas en un servidor de la base de datos de objetos de ataque en la dirección https://services.netscreen.com/restricted/sigupdates. Primero debe suscribirse al servicio de firmas de DI para su dispositivo tal y como se describe en la siguiente sección de manera que pueda obtener acceso a este servidor de base de datos.

Existen cuatro maneras de actualizar la base de datos:

“Actualización inmediata” en la página 127

Paquete de firmas Descripción Cobertura de la amenaza

Básico1 Un conjunto seleccionado de firmas para protección de gusanos y clientes/servidores optimizada para sucursales y oficinas remotas así como para pequeñas y medianas empresas.

Incluye un gusano de muestra, firmas de cliente a servidor y de servidor a cliente para los protocolos y servicios orientados a Internet, como HTTP, DNS, FTP, SMTP, POP3, IMAP, NetBIOS/SMB, MS-RPC, P2P e IM (AIM, YMSG, MSN e IRC).

Protección del servidor

Para pequeñas y medianas empresas y sucursales y oficinas remotas de empresas importantes que necesitan el cumplimiento y defensa de perímetro para infraestructuras del servidor, como IIS, Exchange y Oracle.

Principalmente se centra en proteger la granja de servidores. Esto incluye un conjunto integral de protocolos orientados a servidores, como HTTP, DNS, FTP, SMTP, IMAP, MS-SQL y LDAP. También se incluyen las firmas de gusanos cuyo objetivo son los servidores.

Protección del cliente

Para pequeñas y medianas empresas, además de sucursales y oficinas remotas de empresas importantes que necesitan el cumplimiento y defensa de perímetro para los host (equipos de escritorio, portátiles, etc.).

Se centra principalmente en evitar que los usuarios reciban malware, caballos de Troya, etc., mientras navegan por Internet. Esto incluye un conjunto integral de protocolos orientados a los clientes, como HTTP, DNS, FTP, IMAP, POP3, P2P e IM (AIM, YMSG, MSN e IRC). También se incluyen las firmas de gusanos cuyo objetivo son los clientes.

Mitigación de gusanos

Para sucursales y oficinas remotas de empresas importantes, así como pequeñas y medianas empresas para proporcionar la defensa más completa contra ataques de gusanos.

Incluye firmas de secuencias y se centra principalmente en proporcionar protección completa contra gusanos. Detecta ataques de gusanos de servidores a clientes y de clientes a servidores, en todos los protocolos.

1.Debido a la asignación de memoria que se requiere para las nuevas mejoras, únicamente se proporcionan las firmas de DI de gravedad crítica en los dispositivos NS-5XT/GT.

Paquete de firmas URL

Básico (predeterminado) https://services.netscreen.com/restricted/sigupdates.

El dispositivo de seguridad utiliza esta URL de forma predeterminada.

Servidor https://services.netscreen.com/restricted/sigupdates/server

Cliente https://services.netscreen.com/restricted/sigupdates/client

Mitigación de gusanos https://services.netscreen.com/restricted/sigupdates/worm

Servidor de la base de datos de objetos de ataque 125


126

“Actualización automática” en la página 127

“Notificación automática y actualización inmediata” en la página 129

“Actualización manual” en la página 130

Antes de empezar a actualizar los objetos de ataqueDebe realizar lo siguiente antes de iniciar la descarga y actualización de los objetos de ataque:

1. Registrar su dispositivo de seguridad y obtener un código de autorización.

2. Adquirir una clave de licencia y activar una suscripción a Deep Inspection.

3. Verificar que el reloj del sistema y los ajustes del sistema de nombres de dominio (DNS) en su dispositivo estén a la hora exacta.

Para obtener más información, consulte “Registro y activación de los servicios de suscripción” en la página 2-254.

WebUI

Configuration > Date/Time

Network > DNS > Host

4. Haga clic en el botón Update Now.

Observe que esta opción únicamente está disponible después de descargar una clave de suscripción a Deep Inspection.

El dispositivo de seguridad, entonces, intenta establecer contacto con el servidor en la URL predeterminada: https://services.netscreen.com/restricted/sigupdates o si se ingresó una URL diferente en el campo Database Server, se intenta establecer contacto con la URL que introdujo. En la Tabla 6 en la página 125 se incluyen los paquetes de firmas predefinidas y las URL correspondientes.

Después de unos momentos, aparece un mensaje que indica si la actualización se efectuó con éxito. Si la actualización se efectuó sin éxito, entonces se debe verificar el registro de eventos para determinar el motivo del fallo

NOTA: También se puede utilizar NetScreen-Security Manager para descargar los paquetes de firmas. Encontrará más información en el manual NetScreen-Security Manager Administration Guide.

NOTA: Después de descargar el paquete de firmas por primera vez, se debe restablecer el dispositivo de seguridad. A partir de entonces, después de cada descarga, no es necesario restablecer el dispositivo.



Actualización inmediataLa opción Immediate Update permite actualizar el paquete de firmas en el dispositivo de seguridad inmediatamente con el almacenamiento del paquete de firmas en el servidor de la base de datos. Para que esta operación funcione, primero debe configurar los ajustes del servidor de la base de datos de objetos de ataque.

En este ejemplo (consulte la Figura 46), guardará inmediatamente un paquete de firmas predefinidas desde el servidor de la base de datos de objetos de ataque al dispositivo de seguridad.

No necesita establecer una programación para actualizar la base de datos en el dispositivo de seguridad. En lugar de eso, guardará inmediatamente la base de datos del servidor en el dispositivo de seguridad.

Figura 46: Actualización inmediata de las firmas de DI

WebUI

Configuration > Update > Attack Signature: Signature Pack: ClientHaga clic en el botón Update Now.

CLI

set attack db sigpack client exec attack-db updateLoading attack database.............Done.Done.Switching attack database...DoneSaving attack database to flash...Done.

Actualización automáticaLa opción Automatic Update, descarga el paquete de firmas en horas que el usuario programa, siempre que la base de datos del servidor sea una versión más reciente que la cargada anteriormente en el dispositivo. Juniper Networks actualiza el paquete de firmas periódicamente con nuevos patrones de ataque recién descubiertos. Por lo tanto, debido a su naturaleza cambiante, también se debe actualizar el paquete de firmas en su dispositivo de seguridad periódicamente. Para que esta operación funcione, primero debe configurar los ajustes del servidor de la base de datos de objetos de ataque.


https://services.netscreen .com/restricted/sigupdates

Base de datos de objetos de ataque

2. Actualización de la base de datos

Internet

1. Petición de actualizaciónDispositivo de seguridad local




128

En este ejemplo (consulte la Figura 47), se establecerá una programación para actualizar la base de datos en el dispositivo de seguridad cada lunes a las 04:00:00 horas. A esa hora programada, el dispositivo comparará la versión de la base de datos en el servidor con la del dispositivo. Si la versión del servidor es más reciente, el dispositivo de seguridad reemplazará automáticamente su base de datos con la versión más reciente.

Por ejemplo, seleccione Server para actualizar el paquete de firmas del servidor. Consulte la Tabla 6 en la página 125 para encontrar una lista de paquetes de firmas predefinidas y las URL correspondientes.

Figura 47: Actualización automática de las firmas de DI

WebUI

Configuration > Update > Attack Signature: Introduzca los siguientes datos y haga clic en OK:

Signature Pack: ServidorUpdate Mode: Automatic UpdateSchedule:

Weekly on: MondayTime (hh:mm): 04:00

CLI

set attack db sigpack serverset attack db mode updateset attack db schedule weekly monday 04:00save

S M T W T F S

Dispositivo de seguridad local1. Comprobación automática

de la actualización

Internet

2. Actualización inmediata de la base de datos


https://services.juniper .com/restricted/sigupdates



NOTA: 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 de seguridad utiliza en su lugar la última fecha posible de ese mismo mes.



Notificación automática y actualización inmediataLas opciones Automatic Notification e Immediate Update permiten comprobar (a la hora establecida por el usuario) si los datos presentes en el servidor de la base de datos son más recientes que los que hay en el dispositivo de seguridad. 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 de seguridad. A continuación, puede ejecutar el comando exec attack-db update o hacer clic en el botón Update Now en la página Configuration > Update > Attack Signature en WebUI para guardar el paquete de firmas del servidor en el dispositivo. 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.

En este ejemplo (consulte la Figura 48), se establecerá una programación para comprobar diariamente a las 07:00 horas la base de datos en el dispositivo de seguridad.

Cuando reciba un aviso de que la base de datos del servidor se actualizó, 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.

Por ejemplo, para actualizar el paquete de firmas del cliente realice lo siguiente. Consulte la Tabla 6 en la página 125 para encontrar una lista de paquetes de firmas predefinidas y las URL correspondientes.

Figura 48: Notificación de actualizaciones de firmas

WebUI

1. Comprobación programada de la base de datosConfiguration > Update > Attack Signature: Introduzca los siguientes datos y haga clic en OK:

Signature Pack: ClientUpdate Mode: Automatic NotificationSchedule:

DailyTime (hh:mm): 07:00

S M T W T F S

Dispositivo de seguridad local1. Comprobación automática de

la actualización

Internet

2. Actualización inmediata de la base de datos Base de datos de

objetos de ataque

https://services.juniper .com/restricted/sigupdates





130

2. Actualización inmediata de la base de datosCuando reciba un aviso de que la base de datos de ataques del servidor está más actualizada que la del dispositivo de seguridad, realice lo siguiente:

Configuration > Update > Attack Signature

Signature pack: ClientHaga clic en el botón Update Now.

CLI

1. Comprobación programada de la base de datosset attack db sigpack client set attack db mode notificationset attack db schedule daily 07:00

2. Actualización inmediata de la base de datosCuando reciba un aviso de que la base de datos de ataques del servidor está más actualizada que la del dispositivo de seguridad, realice lo siguiente:

exec attack-db update

Actualización manualLa opción Manual Update, permite utilizar primero un explorador para descargar el paquete de firmas a un directorio local o al directorio del servidor TFTP. A continuación puede cargar el paquete de firmas en el dispositivo de seguridad mediante WebUI (desde el directorio local) o mediante CLI (desde el directorio del servidor TFTP).

En este ejemplo (consulte la Figura 49), guardará manualmente el paquete de firmas 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 de seguridad de su directorio local.

Para una actualización automática, el dispositivo de seguridad agregará automáticamente los siguientes elementos al URL:

Número de serie del dispositivo de seguridad

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 de seguridad.

NOTA: Después de descargar el paquete de firmas, también puede colocarlo en un servidor local y configurarlo para que otros dispositivos de seguridad puedan acceder a él. 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 el nuevo URL en el campo Database Server de la página Configuration > Update > Attack Signature o utilizar el siguiente comando CLI: set attack db server cadena_url.



Número de la versión principal de ScreenOS instalada en el dispositivo

Tipo de plataforma

Para actualizar manualmente las firmas de DI, debe agregar estos elementos por su cuenta. En este ejemplo, el número de serie es 0043012001000213, la versión de ScreenOS es 5.4 y la plataforma es NetScreen-208 (ns200). Por lo tanto, la URL resultante es:

https://services.netscreen.com/restricted/sigupdates/5.4/ns200/attacks.bin?sn=0043012001000213

Figura 49: Actualización manual de firmas de DI

1. Descarga del paquete de firmasPara guardar el paquete de firmas en su servidor local, introduzca la siguiente URL en el campo de dirección de su explorador. Consulte la Tabla 6 en la página 125 para encontrar una lista de paquetes de firmas predefinidas y las URL correspondientes.

https://services.netscreen.com/restricted/sigupdates/5.4/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).

2. Actualización del paquete de firmas

WebUI

Configuration > Update > Attack Signature: Introduzca los siguientes datos y haga clic en OK:

Deep Inspection Signature Update:Load File: Introduzca C:\netscreen\attacks-db\attacks.bin

O bien

Haga clic en Browse y navegue hacia ese directorio, seleccione attacks.bin y después haga clic en Open.

Dispositivo de seguridad local 1. Descarga manual de la base de datos

Internet

Admin: 10.1.1.5 C:\netscreen\attacks-db C:\Archivos de

programa\TFTP Server


URL = https://services.netscreen.com/ /restricted/sigupdates/5.4/ns200/attacks .bin?sn=0043012001000213



2. Actualización manual de la base de datos



132

Si el usuario descarga los paquetes de firmas de protección del servidor, cliente o contra gusanos, introduzca el nombre de archivo de forma apropiada.

CLI

save attack-db from tftp 10.1.1.5 attacks.bin to flash

Objetos de ataque y grupos

Los objetos de ataque son firmas completas, firmas de secuencias (en la serie NetScreen-5000) y anomalías de protocolos que un dispositivo de seguridad 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 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.

Figura 50: Grupos y objetos de ataque

Los grupos de objetos de ataque a los que se haga referencia en el componente de DI de una directiva deben apuntar al mismo tipo de servicio que la directiva permite. Por ejemplo, si la directiva permite tráfico de SMTP, el grupo de objetos de ataque debe tener como objetivo los ataques contra el tráfico de SMTP. La siguiente directiva muestra una configuración válida:

set policy id 2 from trust to untrust any any smtp permit attack CRIT:SMTP:SIGS action close

set policy from untrust to dmz any websrv1 http permit attack HIGH:HTTP:SIGS action close /scripts/\.\.%c1%9c\.\./.*

Coincide

websrv11.2.2.5:80Untrust: ethernet3 1.1.1.1/24; DMZ: ethernet2 1.2.2.1/24

El dispositivo de seguridad detecta un objeto de ataque en el paquete. Descarta el paquete y cierra la conexión enviando notificaciones de RST de TCP al origen y al destino.

Attack Group: HIGH:HTTP:SIGS

Host remoto 1.1.1.3:25611

Zona Untrust

PUT \[/users/.*\.asp\].*

/\[scripts/iisadmin/ism\.dll\?http/dir\].

ACK

SYN

SYN/ACK

RSTRST

Carga: …

IP ORIG1.1.1.3 1.2.2.5

IP DEST PTO ORIG25611 80

PTO DEST PROTOHTTP

Zona DMZ


revlog/.

*revlog/.*/phorum/plugin/replace/pluring.php?*p

.*%255(c|C).* .*\[.asp::$data\].*



La siguiente directiva es incorrecta porque permite el tráfico de SMTP, pero el grupo de objetos de ataque se refiere al tráfico de POP3:

set policy id 2 from trust to untrust any any smtp permit attack CRIT:POP3:SIGS action close

La segunda directiva se configuró incorrectamente y, si se implementara, haría que el dispositivo de seguridad consumiera recursos innecesariamente, ya que examinaría el tráfico de SMTP en busca de objetos de ataque de POP3 que nunca encontraría. Si la directiva 2 permite tanto el tráfico de SMTP como del POP3, puede configurar el componente de DI para que busque objetos de ataque de SMTP, objetos de ataque de POP3 o ambos.

set group service grp1set group service grp1 add smtpset group service grp1 add pop3set policy id 2 from trust to untrust any any grp1 permit attack CRIT:SMTP:SIGS action

closeset policy id 2 attack CRIT:POP3:SIGS action close

Protocolos admitidosEl módulo Deep Inspection (DI) admite los objetos de ataque de firmas completas y objetos de ataque de anomalías de protocolos para los siguientes protocolos y aplicaciones:

Tabla 7: Protocolos básicos de red

ProtocoloFirmas completas

Anomalía en el protocolo Definición

DNS Sí Sí Sistema de nombres de dominio (DNS) es un sistema de base de datos para traducir nombres de dominios a direcciones IP, como www.juniper.net = 207.17.137.68.

FTP Sí Sí El protocolo de transferencia de archivos (FTP) es un protocolo para intercambiar archivos entre equipos a través de una red.

HTTP Sí Sí El protocolo de transferencia de hipertexto (HTTP) es un protocolo que se utiliza principalmente para transferir información de servidores web a clientes web.

IMAP Sí Sí El protocolo de acceso de correo electrónico de Internet (IMAP) es un protocolo que proporciona servicios de recuperación y almacenamiento de correos electrónicos entrantes con la opción de que los usuarios puedan descargar sus correos electrónicos o dejarlos en el servidor IMAP.

NetBIOS Sí Sí NetBIOS (Sistema básico de entrada/salida de red) es una interfaz de aplicación que le permite a las aplicaciones de las estaciones de trabajo de los usuarios obtener acceso a los servicios de red proporcionados por los transportes de red como NetBEUI, SPX/IPX y TCP/IP.

POP3 Sí Sí El protocolo de oficina de correo, versión 3 (POP3) es un protocolo que proporciona servicios de recuperación y almacenamiento de correo electrónico entrante.

SMTP Sí Sí Protocolo simple de transferencia de correo electrónico (SMTP) es un protocolo que se utiliza para la transferencia de correo electrónico entre servidores de correo electrónico.

Chargen Sí Sí Protocolo generador de caracteres

Objetos de ataque y grupos 133


134

DHCP Sí Sí El protocolo de configuración dinámica de host se utiliza para controlar los parámetros de red má simportantes para los hosts (que ejecutan clientes) con la ayuda de un servidor. DHCP es compatible con versiones anteriores de BOOTP.

Discard Sí Sí El protocolo de descartar es una herramienta útil de medición y depuración. Es un servicio que descarta todos los datos que recibe al eliminarlos simplemente.

Echo Sí Sí El protocolo de eco es un protocolo de Internet diseñado para propósitos de evaluación y medición. Un host puede conectarse a un servidor que admite el protocolo de ECHO en un puerto 7 TCP o UDP, tras lo cual el servidor devuelve cualquier dato que recibe.

Finger Sí Sí El protocolo de información de usuario Finger es un protocolo simple que proporciona una interfaz a un programa de información de usuarios remoto.

Gopher Sí Sí Gopher es un protocolo de Internet diseñado para la búsqueda y recuperación de documentos distribuidos.

ICMP Sí Sí El protocolo de mensajes de control de Internet es un protocolo reglamentario estrechamente integrado con IP. Los mensajes de ICMP, entregados en paquetes de IP, se utilizan para mensajes fuera de banda que están relacionados con el funcionamiento de la red.

IDENT Sí Sí El protocolo de identificación proporciona un medio para determinar la identidad de un usuario de una conexión TCP determinada.

LDAP Sí Sí El protocolo ligero de acceso a directorios es un conjunto de protocolos para obtener acceso a directorios de información.

LPR Sí Sí Bobina de la impresora de línea

NFS Sí Sí El protocolo del sistema de archivos en red (NFS) proporciona acceso remoto transparente a los archivos compartidos a través de las redes. El protocolo de NFS está diseñado para que pueda moverse a través de diferentes máquinas, sistemas operativos, arquitecturas de red y protocolos de transporte.

NNTP Sí Sí El protocolo de transferencia de noticias en red especifica un protocolo para la distribución, exploración, recuperación y envío de artículos de noticias, por medio del uso de una transmisión de noticias fiable basada en secuencias.

NTP Sí Sí El protocolo de hora de la red y el protocolo simple de hora de la red se utilizan para sincronizar la hora del servidor o del equipo de clientes con otro servidor o fuente de tiempo de referencia, como una radio o un módem o receptor de satélite.

Portmapper Sí Sí El protocolo del programa de asignación de puertos asigna los números de versión y de programa de RPC para trasladar números de puertos específicos.

RADIUS Sí Sí Servicio remoto de autentificación de usuarios de acceso telefónico, es un sistema contable y de autenticación que utilizan muchos proveedores de servicio de Internet (ISP).

rexec Sí Sí Ejecución remota

rlogin Sí Sí El inicio de sesión remoto se produce cuando un usuario se conecta a un host de Internet para utilizar su interfaz nativa de usuario.

rsh Sí Sí Entorno remoto

RTSP Sí Sí El protocolo de secuencia en tiempo real es un protocolo de nivel de aplicación del cliente al servidor que se utiliza para controlar la entrega de datos a través de propiedades en tiempo real. Establece y controla secuencias sincronizadas en una sola hora o en varias horas de medios continuos, como audio y vídeo.





Tabla 8: Aplicaciones de mensajería inmediata

Tabla 9: Aplicaciones de redes Punto a punto (P2P)

SNMPTRAP Sí Sí El protocolo simple de administración de red es una aplicación SNMP que utiliza el funcionamiento de captura SNMP para enviar información al administrador de red.

SSH Sí Sí El protocolo de entorno seguro es un protocolo que se utiliza para iniciar una sesión remota segura y otros servicios seguros de red a través de una red insegura.

SSL Sí Sí El nivel de sockets seguro (protocolo SSL) es un protocolo que se utiliza para transmitir documentos privados por medio del Internet con el uso de un sistema criptográfico.

syslog Sí Sí El protocolo de registro del sistema se utiliza para la transmisión de mensajes de información de eventos a través de las redes.

Telnet Sí Sí El protocolo de Telnet es un programa de emulación de terminal para redes TCP/IP. Este protocolo le permite comunicarse con otros servidores en la red.

TFTP Sí Sí El protocolo trivial de transferencia de archivos es un protocolo simple que se utiliza para transferir archivos. TFTP utiliza el protocolo de datagrama de usuario (UDP) y no proporciona ninguna función de seguridad.

VNC Sí Sí El cálculo virtual de red es un protocolo de escritorio para controlar de forma remota otro equipo.

Whois Sí Sí El protocolo de servicios de directorio de red es una transacción de TCP con base en un servidor de consulta/respuesta que proporciona un servicio de directorio en toda la red a los usuarios de Internet.





AIM Sí Sí Mensajería inmediata de America Online (AIM) es la aplicación de mensajería inmediata para America Online.

MSN Messenger Sí Sí Microsoft Network Messenger (MSN Messenger) es el servicio de mensajería inmediata que proporciona Microsoft.

Yahoo! Yahoo! Sí Sí Yahoo! Messenger es el servicio de mensajería inmediata que proporciona Yahoo!

IRC Sí Sí El chat de retransmisión de Internet es un protocolo que se basa en la visualización de texto, siendo el cliente más simple cualquier programa de socket con la habilidad de conectarse al servidor.



BitTorrent Sí No BitTorrent es una herramienta de distribución de archivos de P2P, diseñada para proporcionar una manera eficiente de distribución del mismo archivo a un grupo grande, al hacer que todos los usuarios que descarguen un archivo también lo envíen a otros usuarios.

DC(Direct connect)

Sí No DC (Direct Connect) es una aplicación de reparto de archivos de P2P. Una red de DC utiliza concentradores para conectar grupos de usuarios, a menudo con la condición de que los usuarios compartan una cierta cantidad de bytes o de archivos. Varios concentradores ofrecen áreas de interés especiales, creando comunidades pequeñas para usuarios conectados.



136

Tabla 10: Puertas de enlace en la capa de aplicación (ALG)

Si el dispositivo de seguridad dispone de acceso a http://help.juniper.net/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 y escriba una de las siguientes URL en el campo de dirección:

http://help.juniper.net/sigupdates/english/AIM.htmlhttp://help.juniper.net/sigupdates/english/DNS.htmlhttp://help.juniper.net/sigupdates/english/FTP.htmlhttp://help.juniper.net/sigupdates/english/GNUTELLA.htmlhttp://help.juniper.net/sigupdates/english/HTTP.htmlhttp://help.juniper.net/sigupdates/english/IMAP.htmlhttp://help.juniper.net/sigupdates/english/MSN.htmlhttp://help.juniper.net/sigupdates/english/NBDS.htmlhttp://help.juniper.net/sigupdates/english/NBNAME.htmlhttp://help.juniper.net/sigupdates/english/POP3.html

eDonkey Sí No eDonkey es una aplicación de reparto de archivos de P2P descentralizada que utiliza el protocolo de transferencia de archivos de múltiples fuentes (MFTP). La red Donkey admite dos clases de aplicaciones: clientes y servidores. Los clientes se conectan a la red y comparten archivos. Los servidores actúan como concentradores de reunión para los clientes.

Gnutella Sí Sí Gnutella es una aplicación y protocolo P2P para compartir archivos que no incluye ningún servidor centralizado. Algunas otras aplicaciones que utilizan el protocolo Gnutella son: BearShare, Limewire, Morpheus y ToadNode.

KaZaa Sí No KaZaa es una aplicación P2P descentralizada para compartir archivos que utiliza el protocolo FastTrack. KaZaa se utiliza principalmente para compartir archivos MP3.

MLdonkey Sí No MLdonkey es una aplicación de cliente de P2P que se puede ejecutar en múltiples plataformas y puede obtener acceso a múltiples redes de P2P, como BitTorrent, DC, eDonkey, FastTrack (KaZaa, entre otros), así como Gnutella y Gnutella2.

Skype Sí No Skype es un servicio telefónico gratis de Internet P2P que permite a los usuarios hablar entre ellos a través de una red TCP/IP como Internet.

SMB Sí Sí SMB (bloque de mensaje del servidor) es un protocolo que se utiliza para compartir recursos como archivos e impresoras entre equipos. SMB funciona en control del protocolo NetBIOS.

WinMX Sí No WinMX es una aplicación P2P para compartir archivos que permite que un cliente se conecte a varios servidores a la vez.



NOTA: Varias de las aplicaciones de P2P enumeradas, utilizan sus propios protocolos patentados.



MSRPC Sí Sí MSRPC (llamada del procedimiento remoto de Microsoft) es un mecanismo que se utiliza para llevar a cabo procesos en equipos remotos.



http://help.juniper.net/sigupdates/english/SMTP.htmlhttp://help.juniper.net/sigupdates/english/MSRPC.htmlhttp://help.juniper.net/sigupdates/english/SMB.htmlhttp://help.juniper.net/sigupdates/english/YMSG.html

Cada uno de las URL anteriores está vinculada a una página de 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 completasUna firma de ataque es un patrón que aparece cuando se está produciendo la explotación de una determinada vulnerabilidad. La firma puede ser un patrón de tráfico de capa 3 ó 4, como cuando una dirección envía muchos paquetes a diversos números de puerto de otra dirección (consulte “Barrida de puertos” en la página 9) o un patrón textual, como cuando aparece una cadena de URL maliciosa en los datos transportados de un único paquete de 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 de seguridad 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 a los elementos afectados por la explotación de la vulnerabilidad para la que los hackers utilizan el patrón. El uso 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 la manera en la cual el módulo DI examina los paquetes cuando está habilitado para detectar el ataque “EXPN Root”. Los hackers 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 de seguridad busca la firma “expn root” en la porción de control de una sesión del protocolo simple de transferencia de correo (SMTP). El dispositivo 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.

NOTA: Dado que el módulo 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. Para obtener más información sobre expresiones regulares, consulte “Expresiones regulares” en la página 161.



138

Al utilizar 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 de 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. Al utilizar firmas completas, el módulo DI puede distinguir entre cadenas de texto que señalan ataques y las que son ocurrencias inofensivas.

Firmas de secuencias TCPComo ocurre con las firmas completas, 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 DI. (Para obtener más información sobre firmas de secuencias TCP, consulte “Objetos de ataque de la firma de la secuencia de TCP” en la página 165).

Las firmas de secuencias son independientes de los protocolos y son, por consiguiente, más flexibles en comparar el tráfico. Las firmas de secuencias pueden examinar el tráfico donde los decodificadores de protocolos no pueden hacerlo. Sin embargo, dicha flexibilidad afecta al rendimiento y al consumo de recursos.

Las firmas de secuencias consumen los recursos y afectan al rendimiento, de modo que deben utilizarse con moderación. No obstante, las firmas de secuencia 256 funcionan de la misma manera, salvo que en lugar de comparar toda la secuencia, se limitan a los primeros 256 bytes. Por lo tanto, consumen menos recursos y afectan menos al rendimiento.

Anomalías en el protocoloLos objetos de ataque que buscan anomalías en los protocolos detectan el tráfico que no cumple con 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.

NOTA: Para obtener una lista de los protocolos para los que existen objetos de ataque de firmas completas predefinidas, consulte “Protocolos admitidos” en la página 133.

NOTA: Las firmas de secuencias TCP sólo se pueden definir en sistemas de gama alta.



Grupos de objetos de ataqueLos 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 en términos generales por gravedad. Los tres niveles de gravedad del grupo de objetos de ataque son critical, high y media:

Critical: 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: 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 de Troya cargado previamente en un dispositivo.

Medium: 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 o filtraciones de información.

Low: Contiene objetos de ataque que coinciden con explotaciones de vulnerabilidad que intentan obtener información que no es crítica o analizar una red con una herramienta de análisis.

Info: Contiene objetos de ataque coincidentes con el tráfico normal e inofensivo, con fallos de consulta DNS, URL, cadenas de comunidad públicas SNMP y parámetros punto a punto (P2P). Puede utilizar los objetos de ataque de información para obtener información sobre su red.

NOTA: Para obtener una lista de los protocolos para los que existen objetos de ataque de anomalías del protocolo predefinidas, consulte “Protocolos admitidos” en la página 133.



140

Cambio de los niveles de gravedadAunque los grupos de objetos de ataque están clasificados por protocolo y nivel de gravedad (crítica, alta y media), cada objeto de ataque tiene su propio nivel de gravedad específico: crítica, alta, media, baja e 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:

Tabla 11: Niveles de gravedad de objetos de ataque

Por ejemplo, si el dispositivo de seguridad detecta un 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 sobrescribir en uno o más grupos de objetos de ataque a los que se hace referencia en una directiva. Esto se realiza a nivel de directiva, introduciendo 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 la manera de 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 después haga clic en OK:

> Deep Inspection: Seleccione una opción de gravedad en la lista desplegable “Severity” y después haga clic en OK.

CLI

device-> set policy id númerodevice(policy:número)-> set di-severity { info | low | medium | high | critical }

Para restablecer el ajuste original de nivel de gravedad de cada objeto de ataque, vuelva a introducir el contexto de una directiva y ejecute uno de los siguientes procedimientos:

WebUI

Policies > Edit (para una directiva existente): Ejecute el siguiente procedimiento y después haga clic en OK:

> Deep Inspection: Seleccione Default en la lista desplegable “Severity” y después haga clic en OK.

Nivel de gravedad de objetos de ataque – Se corresponde con –

Nivel de gravedad de entrada de registro de eventos

Critical Critical

High Error

Medium Warning

Low Notification

Info Information



CLI

device-> set policy id númerodevice(policy:número)-> unset di-severity

Ejemplo: Deep Inspection para P2PEn este ejemplo, se permite que todos los hosts de la zona Trust inicien una sesión de punto a punto (P2P) con cualquier host en la zona Untrust, utilizando HTTP, DNS y los servicios Gnutella. A continuación se debe aplicar Deep Inspection (DI) al tráfico permitido para verificar las firmas completas y las anomalías del protocolo como se define en los siguientes grupos de objetos de ataque:

HIGH:HTTP:SIGS

INFO:GNUTELLA:ANOM

INFO:HTTP:SIGS

Si el dispositivo de seguridad detecta una firma o un comportamiento anómalo, anula la conexión y envía un RST de TCP al cliente para que cierre la sesión. También habilita el registro de cualquier ataque descubierto, que es el comportamiento predeterminado.

WebUI

Policies > (From: Trust, To: Untrust) New: Introduzca los siguientes datos y haga clic en OK:

Source Address: Address Book Entry: (seleccione), Any


Service: DNS

> Haga clic en Multiple, seleccione GNUTELLA y HTTP y después haga clic en OK para regresar a la página de configuración básica de directivas.

Action: Permit

NOTA: Por razones de seguridad, no se define una directiva que permita a todos los hosts en la zona Untrust iniciar una sesión P2P con un host en la zona Trust.

NOTA: Para obtener información sobre las diversas acciones de ataque que puede ejecutar el dispositivo de seguridad, consulte “Acciones de ataque” en la página 143. Para obtener información sobre el registro de ataques detectados, consulte “Registro de ataques” en la página 154.



142

> Haga clic en Deep Inspection, introduzca lo siguiente, haga clic en Add para introducir cada grupo de objetos de ataque y después haga clic en OK para regresar a la página de configuración básica de directivas:

Severity: DefaultGroup: HIGH:HTTP:SIGSAction: Close ClientLog: (seleccione)Severity: DefaultGroup: INFO:GNUTELLA:ANOMAction: Close ClientLog: (seleccione)Severity: DefaultGroup: INFO:HTTP:SIGSAction: Close ClientLog: (seleccione)

CLI

set policy id 1 from trust to untrust any any dns permit attackHIGH:HTTP:SIGS action close-clientset policy id 1device(policy:1)-> set service gnutelladevice(policy:1)-> set service httpdevice(policy:1)-> set attack INFO:GNUTELLA:ANOM action close-clientdevice(policy:1)-> set attack INFO:HTTP:SIGS action close-clientdevice(policy:1)-> exitsave

Desactivación de objetos de ataqueCuando se hace referencia a un grupo de objetos de ataque en una directiva, el dispositivo de seguridad verifica si el tráfico al que se aplica la directiva tiene patrones que coincidan con cualquiera de los objetos de ataque en ese grupo. En algún momento, posiblemente no desee utilizar un objeto de ataque determinado si el mismo produce repetidas veces falsos resultados positivos, es decir, si el objeto de ataque interpreta erróneamente tráfico legítimo como un ataque. Si el problema tiene su origen en un objeto de ataque personalizado, solamente necesita quitarlo del grupo de objetos de ataque personalizado. Sin embargo, no se puede retirar un objeto de ataque predefinido de un grupo de objetos de ataque predefinido. En ese caso, la mejor decisión es desactivar el objeto.

Observe que un objeto de ataque predefinido se deshabilita únicamente en el sistema raíz o sistema virtual (vsys) en el cual se desactiva. Por ejemplo, al desactivar un objeto de ataque predefinido en el sistema raíz, dicho objeto no se deshabilita automáticamente en ningún sistema virtual. De la misma forma, al deshabilitar un objeto de ataque en un vsys no afecta dicho objeto en ningún otro vsys.

NOTA: Ya que el registro de ataques detectados se habilita de forma predeterminada, no es necesario que se especifique el registro a través de los comando CLI.

NOTA: La desactivación de los objetos de ataque no mejora el rendimiento total.



Para deshabilitar un objeto de ataque, ejecute cualquiera de los siguientes procedimientos:

WebUI

Objects > Attacks > Predefined Desactive la casilla de verificación en la columna Configure para el objeto de ataque que desee desactivar.

CLI

set attack disable nombre_ataque_objeto

Para volver a habilitar un objeto de ataque que se deshabilitó previamente, ejecute uno de los siguientes procedimientos:

WebUI

Objects > Attacks > Predefined Seleccione la casilla de verificación en la columna Configure para el objeto de ataque que desee habilitar.

CLI

unset attack disable nombre_ataque_objeto

Acciones de ataque

Cuando el dispositivo de seguridad detecta un ataque, ejecuta la acción que se especificó para el grupo de ataque que contiene el objeto que coincide con el ataque. Las siete acciones son las siguientes, organizadas de la más a la menos severa:

Close (interrumpe la conexión y envía RST al cliente y al servidor)

Utilice esta opción para las conexiones TCP. El dispositivo de seguridad 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 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 de seguridad interrumpe la conexión y envía un RST de TCP sólo al servidor para que borre sus recursos mientras el cliente queda a la espera.

NOTA: 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.

Acciones de ataque 143


144

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 de seguridad 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.

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 de seguridad descarta todos los paquetes en una sesión, pero no envía RST de TCP.

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 de seguridad 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.

Ignore (tras detectar una firma de ataque o una anomalía, el dispositivo de seguridad efectúa una entrada en el registro y deja de comprobar el resto de la conexión, o la ignora)

Si el dispositivo de seguridad 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 en sí. 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 que no sea SMTP. El dispositivo de seguridad 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 implementación de DI. Cuando el dispositivo de seguridad 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 de seguridad 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.

Se puede crear una directiva que haga referencia a múltiples grupos de objetos de ataque, cada grupo con una acción diferente. Si el dispositivo de seguridad detecta simultáneamente múltiples ataques que pertenecen a diferentes grupos de objetos de ataque, éste aplica la acción más severa especificada por uno de dichos grupos.

Acciones de ataque


Ejemplo: Acciones de ataque – Close Server, Close, Close ClientEn 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:

Directiva con ID 1: Permitir tráfico de 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 Directiva con ID 1:

CRITICAL:HTTP:ANOM, CRITICAL:HTTP:SIGS

HIGH:HTTP:ANOM, HIGH:HTTP:SIGS

MEDIUM:HTTP:ANOM, MEDIUM:HTTP:SIGS

CRITICAL:FTP:SIGS

Acción para todos los grupos de objetos de ataque: Close Server

Registro: Habilitado (ajuste predeterminado)

Decide interrumpir la conexión y enviar una notificación RST de TCP únicamente a los servidores web protegidos para que puedan terminar sus sesiones y borrar sus recursos. Se espera que los ataques provendrán de la zona Untrust.

Directiva con ID 2: Permitir tráfico de 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.





CRITICAL:FTP:SIGS

Acción para todos los grupos de objetos de ataque: Close


Decide interrumpir la conexión y enviar una notificación RST de TCP tanto a los clientes como a los servidores protegidos para que ambos puedan terminar sus sesiones y borrar sus recursos independientemente del nivel de gravedad del ataque.

Directiva con ID 3: Permitir el tráfico de FTP-GET, HTTP, HTTPS, PING desde cualquier dirección de la zona Trust a cualquier dirección de la zona Untrust.



146





CRITICAL:FTP:SIGS

Acción para todos los grupos de objetos de ataque: Close Client


Optará por interrumpir la conexión y enviar una notificación RST de TCP 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 de seguridad activa DI únicamente para el tráfico de HTTP y FTP. Todas las zonas se encuentran en el dominio de enrutamiento trust-vr.

Figura 51: Acciones de ataque DI

WebUI




DI (Trust -> Untrust) HTTP: Crit, High, Med; FTP: Crit; Action: Close-client

websrv1 1.2.2.5/24

websrv2 1.2.2.6/24

Zona Untrust

ethernet1 10.1.1.1/24


Zona Trust

Zona DMZ

DI (Trust -> DMZ) HTTP:Crit, High, Med; FTP:Crit; Action:Close

DI (Untrust -> DMZ) HTTP:Crit, High, Med; FTP:Crit Action:Close-server

Acciones de ataque



Interface Mode: NATService Options:

Management Services: (seleccione todos)Other services: Ping






Address Name: websrv1IP Address/Domain Name:



Address Name: websrv2IP Address/Domain Name:


3. RutaNetwork > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK:



4. ID de directiva 1Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK:


Destination Address:Address Book Entry: (seleccione), websrv1



148

> Haga clic en Multiple, seleccione websrv2 y después 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 después haga clic en OK para regresar a la página de configuración básica de directivas.

Action: Permit


Group: CRITICAL:HTTP:ANOMAction: Close ServerLog: (seleccione)Group: CRITICAL:HTTP:SIGSAction: Close ServerLog: (seleccione)Group: HIGH:HTTP:ANOMAction: Close ServerLog: (seleccione)Group: HIGH:HTTP:SIGSAction: Close ServerLog: (seleccione)Group: MEDIUM:HTTP:ANOMAction: Close ServerLog: (seleccione)Group: MEDIUM:HTTP:SIGSAction: Close ServerLog: (seleccione)Group: CRITICAL:FTP:SIGSAction: Close ServerLog: (seleccione)

5. ID de directiva 2Policies > (From: Trust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK:


Destination Address:Address Book Entry: (seleccione), websrv1

> Haga clic en Multiple, seleccione websrv2 y después haga clic en OK para regresar a la página de configuración básica de directivas.

Service: HTTP


Action: Permit

Acciones de ataque



Group: CRITICAL:HTTP:ANOMAction: CloseLog: (seleccione)Group: CRITICAL:HTTP:SIGSAction: CloseLog: (seleccione)Group: HIGH:HTTP:ANOMAction: CloseLog: (seleccione)Group: HIGH:HTTP:SIGSAction: CloseLog: (seleccione)Group: MEDIUM:HTTP:ANOMAction: CloseLog: (seleccione)Group: MEDIUM:HTTP:SIGSAction: CloseLog: (seleccione)Group: CRITICAL:FTP:SIGSAction: CloseLog: (seleccione)

6. ID de directiva 3Policies > (From: Trust, To: Untrust) New: Introduzca los siguientes datos y haga clic en OK:



Service: HTTP


Action: Permit


Group: CRITICAL:HTTP:ANOMAction: Close ClientLog: (seleccione)Group: CRITICAL:HTTP:SIGSAction: Close ClientLog: (seleccione)Group: HIGH:HTTP:ANOMAction: Close ClientLog: (seleccione)Group: HIGH:HTTP:SIGSAction: Close ClientLog: (seleccione)



150

Group: MEDIUM:HTTP:ANOMAction: Close ClientLog: (seleccione)Group: MEDIUM:HTTP:SIGSAction: Close ClientLog: (seleccione)Group: CRITICAL:FTP:SIGSAction: Close ClientLog: (seleccione)

CLI

1. Interfacesset interface ethernet1 zone trustset interface ethernet1 ip 10.1.1.1/24set interface ethernet1 manageset interface ethernet3 zone untrustset interface ethernet3 ip 1.1.1.1/24set interface ethernet2 zone dmzset interface ethernet2 ip 2.1.1.1/24

2. Direccionesset address dmz websrv1 1.2.2.5/32set address dmz websrv2 1.2.2.6/32

3. Rutaset vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250

4. ID de directiva 1set policy id 1 from untrust to dmz any websrv1 http permit attack

CRITICAL:HTTP:ANOM action close-serverset policy id 1device(policy:1)-> set dst-address websrv2device(policy:1)-> set service ftp-getdevice(policy:1)-> set service httpsdevice(policy:1)-> set service pingdevice(policy:1)-> set attack CRITICAL:HTTP:SIGS action close-serverdevice(policy:1)-> set attack HIGH:HTTP:ANOM action close-serverdevice(policy:1)-> set attack HIGH:HTTP:SIGS action close-serverdevice(policy:1)-> set attack MEDIUM:HTTP:ANOM action close-serverdevice(policy:1)-> set attack MEDIUM:HTTP:SIGS action close-serverdevice(policy:1)-> set attack CRITICAL:FTP:SIGS action close-serverdevice(policy:1)-> exit

Acciones de ataque


5. ID de directiva 2set policy id 2 from trust to dmz any websrv1 http permit attack

CRITICAL:HTTP:ANOM action closeset policy id 2device(policy:2)-> set dst-address websrv2device(policy:2)-> set service ftpdevice(policy:2)-> set service httpsdevice(policy:2)-> set service pingdevice(policy:2)-> set attack CRITICAL:HTTP:SIGS action closedevice(policy:2)-> set attack HIGH:HTTP:ANOM action closedevice(policy:2)-> set attack HIGH:HTTP:SIGS action closedevice(policy:2)-> set attack MEDIUM:HTTP:ANOM action closedevice(policy:2)-> set attack MEDIUM:HTTP:SIGS action closedevice(policy:2)-> set attack CRITICAL:FTP:SIGS action closedevice(policy:2)-> exit

6. ID de directiva 3set policy id 3 from trust to untrust any any http permit attack

CRITICAL:HTTP:ANOM action close-clientset policy id 3device(policy:3)-> set service ftp-getdevice(policy:3)-> set service httpsdevice(policy:3)-> set service pingdevice(policy:3)-> set attack CRITICAL:HTTP:SIGS action close-clientdevice(policy:3)-> set attack HIGH:HTTP:ANOM action close-clientdevice(policy:3)-> set attack HIGH:HTTP:SIGS action close-clientdevice(policy:3)-> set attack MEDIUM:HTTP:ANOM action close-clientdevice(policy:3)-> set attack MEDIUM:HTTP:SIGS action close-clientdevice(policy:3)-> set attack CRITICAL:FTP:SIGS action close-clientdevice(policy:3)-> exitsave

Acciones de ataques de fuerza brutaUn ataque de fuerza bruta se lleva a cabo al enviar cantidades grandes de tráfico con IP o puertos de origen variable en un intento por obtener acceso a la red. Para evitar de forma efectiva intentos futuros, ScreenOS le permite asociar una acción IP con cada grupo de ataque en una directiva.

El ataque de fuerza bruta se detecta basándose en los valores del umbral establecidos para los protocolos admitidos por DI. Por ejemplo:

set di service nombre-protocolo valor

Aparte de una acción de DI, las acciones de ataque de fuerza bruta se configuran por medio del comando IP action durante un periodo configurado de tiempo para un destino especificado. Si su dispositivo de seguridad detecta un ataque de fuerza bruta, seleccione una de las siguientes acciones a ejecutar:

Notify: El dispositivo de seguridad registra el evento pero no toma ninguna acción contra el tráfico futuro que coincide con la definición del destino por el periodo de tiempo especificado en los ajustes de tiempo de espera.

Block: El dispositivo de seguridad registra el evento y descarta todo el tráfico futuro que coincide con la definición del destino por el periodo de tiempo especificado en los ajustes de tiempo de espera.



152

Close: El dispositivo de seguridad registra el evento y descarta todo el tráfico futuro que coincide con la definición del destino por el periodo de tiempo especificado en los ajustes de tiempo de espera y envía una señal de restablecimiento (RST) por el tráfico de TCP a las direcciones de destino y de origen.

Objetos de ataques de fuerza brutaEn la Tabla 12 se enumeran los objetos de ataque de fuerza bruta de ScreenOS 5.4 y los parámetros de umbral que se pueden utilizar con las acciones IP.

Tabla 12: Objetos de ataques de fuerza bruta

Destinos de ataques de fuerza brutaLas opciones de destino especifican un conjunto de elementos que deben coincidir para que el dispositivo de seguridad considere una parte del paquete de un ataque de fuerza bruta. El conjunto de elementos especificado en un paquete IP que llega durante un periodo de tiempo de espera especificado debe coincidir con el que aparece en el paquete que el dispositivo de seguridad que se detectó como parte de un ataque de fuerza bruta para que el paquete siguiente se considere parte del mismo ataque. La definición del destino predeterminado es Serv. Se puede seleccionar cualquiera de las siguientes definiciones de destino que se muestran en la Tabla 13.

Nombre de los ataques de fuerza bruta Parámetro

Intento de inicio de sesión de fuerza bruta de HTTP

failed_logins

Intento de búsqueda bruta de HTTP brute_search

Intento de inicio de sesión de fuerza bruta de IMAP

failed_logins

Intento de inicio de sesión de fuerza bruta de LDAP

failed_logins

Inundación de petición MS-RPC IsSystemActive

No se puede configurar, 32 intentos

Intento de sesión de fuerza bruta de MS-SQL No se puede configurar, 4 intentos

Intento de inicio de sesión de fuerza bruta de POP3

failed_login

Intento de autenticación de fuerza bruta de RADIUS

failed_auth

Crear/borrar directorios de fuerza bruta de SMB

No se puede configurar, 200 intentos

Intento de inicio de sesión de fuerza bruta de SMB

failed_login

Intento de inicio de sesión de fuerza bruta de FTP

failed_login

Intento de inicio de sesión de fuerza bruta de Telnet

failed_login

Intento de inicio de sesión de fuerza bruta de VNC

failed_login

Acciones de ataque


Tabla 13: Opciones de destino

Tiempo de espera de ataques de fuerza brutaEl tiempo de espera es un periodo de tiempo que continúa después de la detección del ataque de fuerza bruta durante el cual el dispositivo de seguridad ejecuta una acción IP en los paquetes que coinciden con los parámetros de destino especificados. El tiempo de espera predeterminado es de 60 segundos.

Ejemplo 1En este ejemplo, se debe configurar una acción IP junto con la acción de DI existente para cada grupo en una directiva. Los siguientes comandos de CLI bloquean el objeto de ataques de fuerza bruta (HTTP Brute Force Login Attempt or HTTP Brute Force Search) durante 45 segundos. Todos los otros ataques del grupo de ataque HIGH:HTTP:ANOM se configuran con la acción de DI close.

En esta versión de ScreenOS, S2C la decodificación del protocolo HTTP se realiza solamente si se configuran ataques de firmas de servidor a cliente. HTTP:Brute-Force, se detecta una anomalía de servidor a cliente si se configurar un ataque de firma de servidor a cliente HTTP en la directiva. En el ejemplo siguiente, HTTP:HIGH:SIGS tiene ataques de firmas de servidor a cliente, así que añadirá HTTP:HIGH:SIGS junto con HTTP:HIGH:ANOM en una directiva.

CLI

device> get attack group HIGH:HTTP:ANOMGROUP "HIGH:HTTP:ANOM" está predefinido. Contiene los siguientes miembrosID Name 1674 HTTP:INVALID:INVLD-AUTH-CHAR 1675 HTTP:INVALID:INVLD-AUTH-LEN 1711 HTTP:OVERFLOW:HEADER 1713 HTTP:OVERFLOW:INV-CHUNK-LEN 1717 HTTP:OVERFLOW:AUTH-OVFLW 5394 HTTP:EXPLOIT:BRUTE-FORCE 5395 HTTP:EXPLOIT:BRUTE-SEARCH device> set policy id 1 from Untrust to DMZ Any Any Any permit attack

MEDIUM:HTTP:ANOM action nonedevice> set policy id 1 from Untrust to DMZ Any Any Any permit attack

MEDIUM:HTTP:HIGH:SIGS action nonedevice> set policy id 1device(policy:1)-> set attack HIGH:HTTP:ANOM action close ip-action block

target dst-ip timeout 45

Opción de destino Elementos coincidentes

Serv IP de origen, IP de destino, puerto de destino y protocolo

Src-IP Dirección IP de origen

Zone-Serv Zona de seguridad de origen, IP de destino, número de puerto de destino y protocolo

Dst-IP Dirección IP destino

Zone Zona de seguridad de origen

(La zona de seguridad a la cual está asociada la interfaz de entrada, es decir, la zona de seguridad de original de la cual se originan paquetes de ataques)



154

Si el grupo de ataque configurado no contiene anomalías en el protocolo de ataque de fuerza bruta, no se aplica la acción IP.

Ejemplo 2En este ejemplo, se asocia una acción de IP para cada uno de los grupos de ataque durante un periodo configurado de tiempo de un host especificado.

set policy id 1 from trust to untrust any any any permit attack POP3 BRUTE FORCE Login Attempt action close ip-action notify target serv timeout 60

Ejemplo 3En este ejemplo, el valor de umbral predeterminado del intento de inicio de sesión de fuerza bruta es de ocho intentos por minuto. Si un usuario en una dirección IP 192.168.2.2 activa un intento de inicio de sesión de fuerza bruta FTP en el servidor FTP en 10.150.50.5 para descubrir la contraseña y el nombre de la cuenta de un usuario, el intento se detecta cuando el hacker ejecuta ocho intentos de inicio de sesión FTP en un minuto.

Si se configura una acción IP para “bloquear” durante 120 segundos el destino de “serv”, todo el tráfico proveniente de 192.168.2.2 (IP de origen) a 10.150.50.5 (IP de destino) a través del puerto 21 (puerto de destino) de TCP (protocolo), se bloquea durante 120 segundos.

Observe que algunos destinos de acciones del IP pueden afectar la coincidencia del tráfico con otra directiva.

Registro de ataques

Se puede habilitar el registro de ataques detectados a través del grupo de ataque por directiva. En otras palabras, dentro de la misma directiva, se pueden aplicar grupos de ataque múltiples y habilitar selectivamente el registro de ataques detectados para únicamente algunos de ellos.

El registro está habilitado de forma predeterminada. Es posible que desee deshabilitar el registro de ataques que son de prioridad inferior para usted y que no le parezcan importantes. Al desactivar el registro para dichos ataques se ayuda a evitar que el registro de eventos se desordene con entradas que no planea ver nunca.

Ejemplo: Desactivación del registro por grupo de ataqueEn este ejemplo, se hace referencia a los siguientes cinco grupos de ataque de una directiva y se habilita el registro únicamente para los primeros dos:

HIGH:IMAP:ANOM

HIGH:IMAP:SIGS

MEDIUM:IMAP:ANOM

LOW:IMAP:ANOM

INFO:IMAP:ANOM

Registro de ataques


La directiva se aplica al tráfico de IMAP proveniente de todos los hosts en la zona Trust hacia el servidor de correo electrónico llamado “mail1” en la zona DMZ. Si alguno de los objetos de ataque IMAP predefinidos en los cinco grupos anteriores coincide con un ataque, el dispositivo de seguridad cierra la conexión. Sin embargo, dicha acción únicamente crea entradas de registro para detectar ataques que coincidan con los objetos de ataque que se encuentran en los dos primeros grupos.

WebUI

1. DirecciónPolicy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK:

Address Name: mail1IP Address/Domain Name:


2. DirectivaPolicies > (From: Trust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK:


Destination Address:Address Book Entry: (seleccione), mail1

Service: IMAPAction: Permit


Group: HIGH:IMAP:ANOMAction: CloseLog: (seleccione)

Group: HIGH:IMAP:SIGSAction: CloseLog: (seleccione)

Group: MEDIUM:IMAP:ANOMAction: CloseLog: (anule la selección)

Group: LOW:IMAP:ANOMAction: CloseLog: (anule la selección)

Group: INFO:IMAP:ANOMAction: CloseLog: (anule la selección)

CLI

1. Direcciónset address dmz mail1 1.2.2.10/32

Registro de ataques 155


156

2. Directivadevice-> set policy id 1 from trust to dmz any mail1 imap permit attack

HIGH:IMAP:ANOM action closedevice-> set policy id 1device(policy:1)-> set attack HIGH:IMAP:SIGS action closedevice(policy:1)-> set attack MEDIUM:IMAP:ANOM action closedevice(policy:1)-> unset attack MEDIUM:IMAP:ANOM loggingdevice(policy:1)-> set attack LOW:IMAP:ANOM action closedevice(policy:1)-> unset attack LOW:IMAP:ANOM loggingdevice(policy:1)-> set attack INFO:IMAP:ANOM action closedevice(policy:1)-> unset attack INFO:IMAP:ANOM loggingdevice(policy:1)-> exitdevice-> save

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 a fin de que se ejecute en el número de puerto no estándar como 2121 (consulte la Figura 52), 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-2121set 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 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

Figura 52: Asignación de servicio personalizado

Para evitar este problema, debe informar al módulo DI de que la aplicación FTP se ejecuta en el puerto 2121 (consulte la Figura 53). Esencialmente, debe asignar el protocolo de la capa de aplicación en un número de puerto específico en la capa de transporte. Este enlace se puede realizar a nivel de directivas:

set policy id 1 application ftp

Zona Untrust Zona Trust

FTP (puerto 21)

El cortafuegos permite tráfico custom-ftp en el puerto 2121.

Internet

ftp-srv1

custom-ftp (puerto 2121)

Sin embargo, el módulo DI comprueba si hay ataques CRITICAL:FTP en el puerto 21, que no están en uso.



Cuando se asigna la aplicación FTP al servicio personalizado “custom-ftp” y se configura DI para que examine el tráfico de 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

Figura 53: Asignación del servicio personalizado al grupo de objetos de ataque

Ejemplo: Asignación de una aplicación a un servicio personalizadoEn este ejemplo, se define 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 de HTTP1 desde cualquier dirección de la zona Untrust a un servidor web llamado “servidor1” en la zona DMZ. Posteriormente se aplica Deep Inspection (DI) en el tráfico de HTTP permitido que se ejecuta en el puerto 8080. A continuación se muestran los ajustes de DI para esta directiva:

Grupos de objetos de ataque:




Acción para todos los grupos de objetos de ataque: Close Server


WebUI

1. Servicio personalizadoPolicy > Policy Elements > Services > Custom > New: Introduzca los siguientes datos y haga clic en OK:

Service Name: HTTP1Transport Protocol: TCP (seleccione)Source Port Low: 0Source Port High: 65535Destination Port Low: 8080Destination Port High: 8080

Zona Untrust Zona Trust

El módulo DI comprueba si hay ataques CRITICAL:FTP:SIGS en el puerto 2121.

El cortafuegos permite tráfico custom-ftp en el puerto 2121.

Internet

ftp-srv1

custom-ftp (puerto 2121)

Asignación de servicios personalizados a aplicaciones 157


158


Address Name: servidor1IP Address/Domain Name:

IP Address/Netmask: 1.2.2.5/32Zone: DMZ



Destination Address:Address Book Entry: (seleccione), servidor1

Service: HTTP1Application: HTTPAction: Permit


Group: CRITICAL:HTTP:ANOMAction: Close ServerLog: (seleccione)

Group: CRITICAL:HTTP:SIGSAction: Close ClientLog: (seleccione)

Group: HIGH:HTTP:ANOMAction: Close ClientLog: (seleccione)

Group: HIGH:HTTP:SIGSAction: Close ClientLog: (seleccione)

Group: MEDIUM:HTTP:ANOMAction: Close ClientLog: (seleccione)

Group: MEDIUM:HTTP:SIGSAction: Close ClientLog: (seleccione)

CLI

1. Servicio personalizadoset service HTTP1 protocol tcp src-port 0-65535 dst-port 8080-8080

2. Direcciónset address dmz servidor1 1.2.2.5/32



3. Directivadevice-> set policy id 1 from untrust to dmz any servidor1 HTTP1 permit attack

CRITICAL:HTTP:ANOM action close-serverdevice-> set policy id 1device(policy:1)-> set attack CRITICAL:HTTP:SIGS action close-serverdevice(policy:1)-> set attack HIGH:HTTP:ANOM action close-serverdevice(policy:1)-> set attack HIGH:HTTP:SIGS action close-serverdevice(policy:1)-> set attack MEDIUM:HTTP:ANOM action close-serverdevice(policy:1)-> set attack MEDIUM:HTTP:SIGS action close-serverdevice(policy:1)-> exitdevice-> set policy id 1 application httpsave

Ejemplo: Asignación de aplicación a servicio para ataques HTTPAlgunos ataques HTTP conocidos utilizan el puerto 8000 de TCP. En el momento de escribir esta documentación, existen dos ataques en la base de datos de objetos de ataque de Deep Inspection (DI).

3656, App: HP Web JetAdmin Framework Infoleak

DOS:NETDEV:WEBJET-FW-INFOLEAK (en el grupo de objetos de ataque MEDIUM:HTTP:SIGS)

3638, App: Vulnerabilidad HP Web JetAdmin WriteToFile,

DOS:NETDEV:WEBJET-WRITETOFILE (en el grupo de objetos de ataque CRITICAL:HTTP:SIGS)

Sin embargo, de forma predeterminada, ScreenOS considera únicamente el tráfico de TCP en el puerto 80 como HTTP. Por lo tanto, si el dispositivo de seguridad recibe tráfico de TCP utilizando el puerto 8000, éste no lo reconoce como HTTP. Por lo tanto, el motor de DI no analiza tal tráfico de HTTP para estos ataques y no pueden detectarlos si se llevan a cabo (a menos que asigne HTTP como una aplicación a un servicio personalizado utilizando el puerto 8000).

En este ejemplo, se asocia el tráfico utilizando el puerto 8000 no estándar con HTTP para detectar los ataques anteriores.

WebUI

1. Servicio personalizadoPolicy > Policy Elements > Services > Custom > New: Introduzca los siguientes datos y haga clic en OK:

Service Name: HTTP2Transport Protocol: TCP (seleccione)Source Port Low: 0Source Port High: 65535Destination Port Low: 8000Destination Port High: 8000

NOTA: En general, si ejecuta algunos servicios utilizando números de puerto no estándar en su red y desea que el motor de DI analice dicho tráfico, se debe asociar el número de puerto no estándar al servicio.

Asignación de servicios personalizados a aplicaciones 159


160




Service: HTTP2Application: HTTPAction: Permit


Group: CRITICAL:HTTP:SIGSAction: CloseLog: (seleccione)

Group: MEDIUM:HTTP:SIGSAction: CloseLog: (seleccione)

CLI

1. Servicio personalizadoset service HTTP2 protocol tcp src-port 0-65535 dst-port 8000-8000

2. Directivadevice-> set policy id 1 from untrust to dmz any any HTTP2 permit attack

CRITICAL:HTTP:SIGS action closedevice-> set policy id 1device(policy:1)-> set attack MEDIUM:HTTP:SIGS action closedevice(policy:1)-> exitdevice-> set policy id 1 application httpsave

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 cumplir lo mejor posible sus necesidades. Los objetos de ataque definidos por el usuario pueden ser firmas completas o (en el dispositivo NetScreen-5000) firmas de secuencias de TCP. También se pueden ajustar varios parámetros para modificar los objetos de ataque de la anomalía del protocolo predefinido.

Objetos de ataque de firma completa que define el usuarioSe 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 que define el usuario deben comenzar con “CS:”).



Establezca el contexto para la búsqueda DI. (Encontrará una lista completa de los contextos que puede usar para la creación de objetos de ataque en “Contextos para las firmas definidas por el usuario” en la página A-I.)

Defina la firma. (“Expresiones regulares” en la página 161 describe las expresiones regulares que puede utilizar cuando define firmas).

Asigne un nivel de gravedad al objeto de ataque. (Para obtener información sobre niveles de gravedad, consulte “Cambio de los niveles de gravedad” en la página 140.)

A continuación deberá colocar un objeto de ataque definido por el usuario en un grupo de objetos de ataque que define el usuario para su utilización en directivas.

Expresiones regularesCuando se introduce el texto de una firma, puede escribir una cadena alfanumérica de caracteres normales para buscar coincidencias exactas carácter por carácter, o bien, puede utilizar expresiones regulares para ampliar las posibles coincidencias de la búsqueda a conjuntos de caracteres. ScreenOS reconoce las siguientes expresiones regulares como se muestra en la Tabla 14.

Tabla 14: Expresiones regulares que admite ScreenOS

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 otros que defina el usuario.

Finalidad Metacaracteres Ejemplo Significado

Coincidencia binaria directa (octal)1

\Onúmero_octal \0162Coincide con:

162

Coincidir exactamente con este número octal: 162

Coincidencia binaria directa (hexadecimal)2

\Xnúmero_hexadecimal\X \X01 A5 00 00\XCoincide con:

01 A5 00 00

Coincidir exactamente con estos cuatro números hexadecimales:

01 A5 00 00

Coincidencias sin distinguir mayúsculas de minúsculas

\[caracteres\] \[cat\]Coincide con:

Cat, cAt, caT

CAt, CaT, CAT

cat, cAt

Buscar los caracteres contenidos en cat sin importar si están en letras mayúsculas o minúsculas

Coincidencia con cualquier carácter

. c . tCoincide con:

cat, cbt, cct, … czt

cAt, cBt, cCt, … cZt

c1t, c2t, c3t, … c9t

Busca c, cualquier carácter, t

Objetos de ataque y grupos personalizados 161


162

Buscar el carácter anterior cero o más veces, en lugar de sólo una vez.

* a*b+cCoincide con:

bc

bbc

abc

aaabbbbc

Buscar cero, una o más ocurrencias de a, seguidas por una o más ocurrencias de b y seguidas por una ocurrencia de c.

Buscar una o más ocurrencias del carácter anterior.

+ a+b+cCoincide con:

abc

aabc

aaabbbbc

Buscar una o más ocurrencias de a, seguidas por una o más ocurrencias de b y seguidas por una ocurrencia de c.

Busca el carácter anterior cero veces o una vez.

? drop-?packetCoincide con:

drop-packet

droppacket

Buscar drop-packet o droppacket

Expresiones de grupos ( )

El carácter anterior o el siguiente. Generalmente se utiliza con ( )

| (drop | packet)Coincide con:

drop

packet

Buscar drop o packet.

Rango de caracteres [comienzo-final] [c-f]a(d | t)Coincide con:

cad, cat

dad, dat

ead, eat

fad, fat

Buscar todo lo que comience con c, d, e o f, tenga la letra central a y la última letra d o t

Negación del carácter siguiente.

[^carácter] [^0-9A-Z]Coincide con:

a, b, c, d, e, … z

Buscar letras minúsculas

1.Octal es el sistema numérico en base 8 que utiliza únicamente los dígitos del 0 al 7.2.Hexadecimal es un sistema numérico en base 16 que utiliza los dígitos del 0 al 9 habituales más las letras A–F, que

representan dígitos hexadecimales equivalentes a los valores decimales del 10 al 15.

Finalidad Metacaracteres Ejemplo Significado



Ejemplo: Objetos de ataque de firma completa que define un usuarioEn este ejemplo, tendrá un servidor FTP, un servidor web y un servidor de correo en la zona DMZ. Se definirán los siguientes objetos de ataque para los objetos de firmas que define el usuario, tal y como se muestra en la Tabla 15.

Tabla 15: Objetos de ataque de firma completa que define el usuario

A continuación los organizará en un grupo de objetos de ataque que define 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-storObjects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK:

Attack Name: cs:ftp-storAttack Context: FTP CommandAttack Severity: MediumAttack Pattern: STOR

2. Objeto de ataque 2: ftp-user-dmObjects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK:

Attack Name: cs:ftp-user-dmAttack Context: FTP User NameAttack Severity: LowAttack Pattern: dmartin

3. Objeto de ataque 3: url-indexObjects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK:

Attack Name: cs:url-indexAttack Context: HTTP URL ParsedAttack Severity: HighAttack Pattern: .*index.html.*

Nombre del objeto Uso

cs:ftp-stor Bloquear que alguien pueda colocar archivos en un servidor FTP

cs:ftp-user-dm Rechazar 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”



164

4. Objeto de ataque 4: spammerObjects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK:

Attack Name: cs:spammerAttack Context: SMTP FromAttack Severity: InfoAttack Pattern: .*@spam.com

5. Grupo de objetos de ataqueObjects > Attacks > Custom Groups > New: Introduzca el siguiente nombre de grupo, mueva los siguientes objetos de ataque personalizados y después 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 columna Available Members a la columna Selected Members.

Seleccione cs:spammer y utilice el botón << para mover la dirección de la columna Available Members a la columna Selected Members.




Service: HTTP

> Haga clic en Multiple, seleccione FTP y después haga clic en OK para regresar a la página de configuración básica de directivas.

Action: Permit


Group: CS:DMZ DIAction: Close ServerLog: (seleccione)



CLI

1. Objeto de ataque 1: ftp-storset attack cs:ftp-stor ftp-command STOR severity medium

2. Objeto de ataque 2: ftp-user-dmset attack cs:ftp-user-dm ftp-username dmartin severity low

3. Objeto de ataque 3: url-indexset attack cs:url-index http-url-parsed index.html severity high

4. Objeto de ataque 4: spammerset attack cs:spammer smtp-from .*@spam.com severity info

5. Grupo de objetos de ataqueset attack group “CS:DMZ DI”set attack group “CS:DMZ DI” add cs:ftp-storset attack group “CS:DMZ DI” add cs:ftp-user-dmset attack group “CS:DMZ DI” add cs:url-indexset attack group “CS:DMZ DI” add cs:spammer

6. Directivaset policy id 1 from untrust to dmz any any http permit attack “CS:DMZ DI” action

close-serverset policy id 1device(policy:1)-> set service ftpdevice(policy:1)-> exitsave

Objetos de ataque de la firma de la secuencia de TCPLas 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 de TCP buscan patrones en cualquier lugar y en cualquier tipo de tráfico de TCP sin importar el protocolo de aplicación que se utiliza.

Dado que no hay objetos de ataque de firma de la secuencia de 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

NOTA: Las firmas de secuencias de TCP sólo se pueden definir en sistemas de la serie NetScreen-5000.



166

Figura 54: Ejemplo de un objeto de ataque de firma de secuencia de TCP

Ejemplo: Objeto de ataque de firma de secuencia que define el usuarioEn 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 de seguridad interrumpir la conexión y enviar RST de TCP 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 secuenciaObjects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK:

Attack Name: CS:A1Attack Context: StreamAttack Severity: CriticalAttack Pattern: .*satori.*

2. Grupo de objetos de ataque de firma de secuenciaObjects > 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. DirectivaPolicies > (From: Trust, To: Untrust) New: Introduzca los siguientes datos y haga clic en OK:



Service: ANYAction: Permit

set attack "CS:A1" stream ".*satori.*" severity critical

Nombre Tipo Definición Nivel de gravedad




Group: CS:Gr1Action: Close ClientLog: (seleccione)

CLI

1. Objeto de ataque de firma de secuenciaset attack “CS:A1” stream “.*satori.*” severity critical

2. Grupo de ataques de firma de secuenciaset attack group “CS:Gr1”set attack group “CS:Gr1” add “CS:A1”

3. Directivaset policy from trust to untrust any any any permit attack CS:Gr1 action close-clientsave

Parámetros configurables de anomalías en protocolosEs posible modificar determinados parámetros de un objeto de ataques de anomalías en protocolos. A pesar de que Juniper define los objetos de ataque de anomalías en protocolos para descubrir incumplimientos de los estándares de protocolos definidos en las normas RFC y en sus extensiones, no se cumplen todas las implementaciones de estas normas. Si descubre que la aplicación de cierto objeto de ataque de las anomalías de protocolos produce demasiados falsos positivos, sus parámetros se pueden modificar con el objetivo de mejorar la coincidencia del uso aceptado de dicho protocolo en su red.

Ejemplo: Modificación de parámetrosEn este ejemplo, se establecen los valores más altos para los siguientes parámetros con el objetivo de reducir la cantidad de falsos positivos que ocurren, con los ajustes predeterminados.

NOTA: Encontrará una lista completa de todos los parámetros configurables, consulte el comando di en el manual ScreenOS CLI Reference Guide: IPv4 Command Descriptions.

Parámetro del protocoloValor predeterminado Nuevo

SMB: Número máximo de fallos de inicio de sesión por minuto

4 fallos 8 fallos

Gnutella: Número máximo de saltos de plazo de vida (TTL) 8 saltos 10 saltos



168

Para los siguientes parámetros, establecerá valores inferiores para detectar comportamientos anómalos que el dispositivo de seguridad pasó por alto con los ajustes predeterminados:

WebUI

CLI

set di service smb failed_logins 8set di service gnutella max_ttl_hops 10set di service aim max_flap_length 5000set di service aim max_oft_frame 5000save

Negación

Normalmente, se utilizan los objetos de ataque para comparar los patrones que son indicativos de actividad anómala o maliciosa. Sin embargo, también se pueden utilizar para comparar los patrones indicativos de actividad legítima o benigna. Con este enfoque, únicamente hay algo sospechoso si un tipo de tráfico no coincide con un patrón determinado. Para utilizar los objetos de ataques de esta manera, aplique el concepto de negación.

Una aplicación útil de la negación de objetos de ataque sería bloquear todos los intentos de inicio de sesión que no se realicen con el nombre del usuario y la contraseña correcta. Sería demasiado complicado definir todos los nombres de usuario y contraseñas no válidas y bastante fácil definir las correctas y después aplicar la negación para invertir lo que el dispositivo de seguridad considera que es un ataque, es decir, todo con excepción del objeto de ataque especificado.

Ejemplo: Negación de objeto de ataqueEn este ejemplo (consulte la Figura 55), se definen dos objetos de ataque: uno que especifica el nombre del usuario correcto que se requiere para iniciar la sesión en un servidor FTP y el otro, la contraseña correcta. Posteriormente, se aplica la negación a los dos objetos de ataque, para que así el dispositivo de seguridad bloquee todos los intentos de inicio de sesión a dicho servidor que utilice cualquier otro nombre de usuario o contraseña que no sea la que se define en los objetos de ataque.

Parámetro del protocoloValor predeterminado Nuevo

AOL Instant Messenger (AIM): Máxima longitud del nombre del archivo de transferencia de archivos OSCAR (OFT).

OSCAR: Sistema abierto para la comunicación en tiempo real, el protocolo que utilizan los clientes AIM.

10.000 bytes 5.000 bytes

AOL Instant Messenger: Máxima longitud de una trama FLAP (encabezado FLAP, que siempre son de 6 bytes más los datos).

OSCAR utiliza el protocolo FLAP para establecer conexiones y abrir los canales entre los clientes AIM.

10.000 bytes 5.000 bytes

NOTA: Debe utilizar la CLI para modificar los parámetros de anomalías de protocolos.

Negación


En el ejemplo se utilizan los siguientes ajustes:

El nombre de usuario y contraseña correcta son admin1 y pass1.

El servidor FTP se encuentra en 1.2.2.5 de la zona DMZ. Su nombre de dirección es ftp1.

Se aplica DI en el tráfico de FTP para el servidor desde todos los hosts en las zonas Untrust y Trust.

Todas las zonas de seguridad se encuentran en el dominio de enrutamiento trust-vr.

Creará los dos objetos de ataque siguientes:

Objeto de ataque No. 1:

Name: CS:FTP1_USR_OK

Negation: enabled

Context: ftp-username

Pattern: admin1

Severity: high

Objeto de ataque No. 2:

Name: CS:FTP1_PASS_OK

Negation: enabled

Context: ftp-password

Pattern: pass1

Severity: high

Posteriormente se colocaran los dos objetos en un grupo de objetos de ataque llamado CS:FTP1_LOGIN y que se refieren a ese grupo de objetos de ataque en dos directivas que permiten el tráfico de FTP desde las zonas Trust y Untrust hacia ftp1 en la zona DMZ.

Negación 169


170

Figura 55: Negación de objeto de ataque

WebUI


Zone Name: TrustStatic IP: (seleccione esta opción si es posible)

IP Address/Netmask: 10.1.1.1/24

Seleccione los siguientes datos y haga clic en OK:

Interface Mode: NAT (seleccione)


Zone Name: DMZStatic IP: (seleccione esta opción si es posible)



Zone Name: UntrustStatic IP: (seleccione esta opción si es posible)



Intento de inicio de sesión:

Untrust

ethernet1 10.1.1.1/24

Trust

DMZ

Intento de inicio de sesión: Nombre de usuario: admin1 Contraseña: pass1


LAN

LAN

Nota: Por simplicidad, el enrutador externo en la zona Untrust no se muestra. Su dirección es 1.1.1.250.

Servidor FTP “ftp1” 1.2.2.5

Intento de inicio de sesión:

Contraseña: pass1

Internet

Nombre de usuario: 123456 Contraseña: 123456

Nombre de usuario: admin1 Intento de inicio de sesión:Nombre de usuario: anonContraseña: logos

NOTA: De forma predeterminada, cualquier interfaz que se asocie a la zona Trust estará en modo NAT. Por lo tanto, esta opción ya está habilitada para las interfaces asociadas a la zona Trust.

Negación



Address Name: ftp1IP Address/Domain Name:


3. Objeto de ataque 1: CS:FTP1_USR_OKObjects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK:

Attack Name: CS:FTP1_USR_OKAttack Context: ftp-usernameAttack Severity: HighAttack Pattern: admin1Pattern Negation: (seleccione)

4. Objeto de ataque 2: CS:FTP1_PASS_OKObjects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK:

Attack Name: CS:FTP1_PASS_OKAttack Context: ftp-passwordAttack Severity: HighAttack Pattern: pass1Pattern Negation: (seleccione)

5. Grupo de objetos de ataqueObjects > Attacks > Custom Groups > New: Introduzca el siguiente nombre de grupo, mueva los siguientes objetos de ataque personalizados y después haga clic en OK:

Group Name: CS:FTP1_LOGIN

Seleccione CS:FTP1_USR_OK y utilice el botón << para mover la dirección de la columna Available Members a la columna Selected Members.

Seleccione CS:FTP1_PASS_OK y utilice el botón << para mover la dirección de la columna Available Members a la columna Selected Members.

6. RutaNetwork > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK:


Interface: ethernet3Gateway IP Address: (seleccione) 1.1.1.250

Negación 171


172

7. DirectivasPolicies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK:


Destination Address:Address Book Entry: (seleccione), ftp1

Service: FTPAction: Permit


Group: CS:FTP1_LOGINAction: DropLog: (seleccione)

Policies > (From: Trust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK:


Destination Address:Address Book Entry: (seleccione), ftp1

Service: FTPAction: Permit


Group: CS:FTP1_LOGINAction: DropLog: (seleccione)

CLI

1. Interfacesset interface ethernet1 zone trustset interface ethernet1 ip 10.1.1.1/24set interface ethernet1 natset interface ethernet2 zone dmzset interface ethernet2 ip 1.2.2.1/24set interface ethernet3 zone untrustset interface ethernet3 ip 1.1.1.1/24

2. Direcciónset address dmz ftp1 1.2.2.5/32

3. Objetos de ataqueset attack CS:FTP1_USR_OK ftp-username not admin1 severity highset attack CS:FTP1_PASS_OK ftp-password not pass1 severity highset attack group CS:FTP1_LOGINset attack group CS:FTP1_LOGIN add CS:FTP1_USR_OKset attack group CS:FTP1_LOGIN add CS:FTP1_PASS_OK

Negación


4. Rutaset vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250

5. Directivasset policy from untrust to dmz any ftp1 ftp permit attack CS:FTP1_LOGIN action

drop set policy from trust to dmz any ftp1 ftp permit attack CS:FTP1_LOGIN action dropsave


Un dispositivo de seguridad de Juniper Networks 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 de seguridad examina cada encabezado HTTP que llegue a una interfaz unida 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 de seguridad está configurado para bloquear esos tipos de componentes HTTP, el dispositivo bloquea el paquete. Si el tipo de contenido sólo detalla “octet stream” en lugar de un tipo específico de componente, el dispositivo examina el tipo de archivo en la carga. Si el tipo de archivo es Java, .exe, o .zip y el dispositivo está configurado para bloquear esos tipos de componentes, el dispositivo bloquea el paquete.

Cuando se habilita el bloqueo de los controles de ActiveX, el dispositivo 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).

Controles ActiveXLa tecnología ActiveX de Microsoft proporciona una herramienta para los diseñadores web que permite 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 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 le solicita al equipo que descargue los controles de ActiveX. 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 confía en la procedencia del código, puede iniciar la descarga de los controles. Si no confía en el origen, puede rechazarlos.

NOTA: Cuando el bloqueo de ActiveX está habilitado, el dispositivo de seguridad bloquea los applets de Java, archivos .exe y archivos .zip independientemente de si están o no contenidos en un control de ActiveX.

Bloqueo granular de los componentes de HTTP 173


174

Si descarga un control ActiveX a su equipo, a continuación podrá hacer lo que su creador haya previsto. Si es código malicioso, 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 JavaCon una finalidad similar 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 hacker 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 EXEEn los archivos ejecutables (es decir, 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 ZIPUn 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: Bloqueo de applets de Java y archivos “.exe”En este ejemplo bloqueará todo el tráfico de 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 después haga clic en Apply.

CLI

set zone untrust screen component-block jarset zone untrust screen component-block exesave


Capítulo 6

Detección y prevención de intrusiones

Un sistema de prevención de intrusiones (IPS), conocido más comúnmente como cortafuegos, se utiliza para detectar e impedir ataques en el tráfico de la red. A pesar de que los cortafuegos proporcionan protección en el perímetro y en los límites, no están diseñados para detectar ataques que el tráfico permitido puede ocultar.

La tecnología de detección y prevención de intrusiones (IDP) de Juniper Networks puede detectar y después detener ataques implementados en línea hacia su red. A diferencia de un IPS único, la IDP utiliza múltiples métodos para detectar ataques contra su red e impedir que los hackers obtengan acceso y ocasionen daños. La IDP puede descartar conexiones o paquetes maliciosos antes de que los ataques puedan entrar a su red. Está diseñada para reducir falsos positivos y garantizar que solamente se detecte y detenga el tráfico malicioso real. También puede implementar IDP como un programa rastreador pasivo, similar a un IPS tradicional, pero con mayor exactitud y capacidad de administración.

Este capítulo consta de las siguientes secciones:

“Dispositivos de seguridad con capacidad para IDP” en la página 176

“Flujo de tráfico en un dispositivo con capacidad de IDP” en la página 176

“Configuración de la detección y prevención de intrusiones” en la página 177

“Configuración de directivas de seguridad” en la página 185

“Uso de las bases de normas de IDP” en la página 187

“Habilitación de IDP en las normas de cortafuegos” en la página 189

“Configuración de las normas de IDP” en la página 191

“Configuración de las normas de exclusión” en la página 205

“Configuración de las normas de puerta de atrás” en la página 210

“Configuración de los objetos de ataque de IDP” en la página 215

“Configuración del dispositivo como un dispositivo IDP independiente” en la página 235

“Administración de IDP” en la página 238

175


176

Dispositivos de seguridad con capacidad para IDP

ScreenOS admite las capacidades IDP solamente en algunos dispositivos de seguridad. El módulo de seguridad, un componente opcional instalado en algunos dispositivos de seguridad proporciona funcionalidad de IDP.

Si adquirió un dispositivo de seguridad que solamente cuenta con capacidades de cortafuegos o red privada virtual (VPN) puede actualizar el dispositivo a un dispositivo con capacidad para IDP mediante el siguiente procedimiento:

Instalar las claves de licencia IDP y avanzada

Actualizar el cargador de inicio

Instalar una versión con capacidad de IDP de ScreenOS

Actualizar la memoria del sistema

Instalar módulos de seguridad

Consulte los documentos ISG 2000 and ISG 1000 Field Upgrade para obtener las instrucciones sobre cómo actualizar los dispositivos para incluir las capacidades de IDP.

Puede utilizar el dispositivo de seguridad con capacidad para IDP como un sistema de seguridad de cortafuegos/VPN/IDP completamente integrado que no solamente analiza el tráfico entre Internet y su red privada, sino también proporciona una seguridad a nivel de aplicación. También puede utilizar este dispositivo como un sistema IDP independiente para proteger los segmentos esenciales de su red privada. Para obtener más información, consulte “Configuración del dispositivo como un dispositivo IDP independiente” en la página 235.

Flujo de tráfico en un dispositivo con capacidad de IDP

Esta sección describe el flujo de paquetes en el dispositivo de seguridad con capacidad de IDP. El procesador ASIC en el dispositivo recibe el paquete, revisa la tabla de sesiones y si no encuentra una coincidencia, reenvía el paquete al módulo de administración. La Figura 56 ilustra el flujo del paquete del módulo de administración al módulo de seguridad. El módulo de administración revisa el paquete al compararlo con las directivas del cortafuegos. Si la tecnología IDP está habilitada, el tráfico se desvía al módulo de seguridad que esté menos cargado, el cual lleva a cabo el análisis IDP en el paquete.

NOTA: La instalación de la clave de licencia IDP desactiva la función de Deep Inspection (DI) de ScreenOS.

Dispositivos de seguridad con capacidad para IDP

Capítulo 6: Detección y prevención de intrusiones

Figura 56: Flujo de tráfico en el dispositivo de seguridad

Cada módulo de seguridad, que consta de una CPU doble, mantiene su propia tabla de sesiones. El CPU doble permite a cada módulo de seguridad ejecutar dos instancias de IDP por módulo. El comando get sm status muestra el CPU doble por cada módulo de seguridad (consulte página 180).

La configuración del modo en línea a demanda permite a los módulos de seguridad de IDP supervisar el tráfico pasivamente. En el modo en línea a demanda, una demanda interna envía una copia de cada paquete en el flujo de tráfico al módulo de seguridad para el procesamiento de IDP; al mismo tiempo, el módulo ASIC lleva a cabo un procesamiento de cortafuegos/VPN en el tráfico en línea.

Si se detecta un objeto de ataque, el restablecimiento de TCP ocurre con la opción “close” para borrar la tabla de sesiones. En cada ataque que coincida con una norma, puede optar por ignorar, descartar o cerrar la conexión o los paquetes del ataque. Para obtener más información sobre qué hacer al encontrar un objeto de ataque, consulte Definición de acciones en la página 199.

Configuración de la detección y prevención de intrusiones

Esta sección presenta tres ejemplos básicos para configurar IDP en su dispositivo de seguridad:

“Ejemplo 1: Configuración básica de IDP” en la página 178

“Ejemplo 2: Configuración de IDP para cambio en caso de fallo activo, pasivo” en la página 181

“Ejemplo 3: Configuración de IDP para cambio en caso de fallo activo, activo” en la página 183

H A

F L A S H

PW R

FA N

A L A R M

M O D 1

T E M P

M O D 2

S TAT U S

M O D 3 ISG 2000

Sin IDP

IDP en línea

IDP en línea a demanda

Dispositivo de seguridad Juniper Networks

Módulo de seguridad

El paquete se envía al módulo de seguridad que está menos cargado para la inspección de IDP

1. Consulta de rutas 2. Consulta de directivas

Módulo de administración



Se crea la sesión y el paquete sale del dispositivo

Flujo de tráfico

Configuración de la detección y prevención de intrusiones 177


178

Tareas de configuración previaAntes de empezar a configurar IDP en el dispositivo, debe cerciorarse de lo siguiente:

Que su dispositivo tenga capacidad para IDP. Para obtener más información, consulte “Dispositivos de seguridad con capacidad para IDP” en la página 176.

Que haya instalado y configurado un sistema NetScreen-Security Manager (NSM) en una estación de administración.

NetScreen-Security Manager proporciona una administración de directivas integrada, en donde cada dispositivo de seguridad está relacionado con una directiva de seguridad que contiene normas que definen los tipos de tráfico permitidos en la red y la manera en que el tráfico se maneja dentro de la red.

Tiene una directiva de seguridad para el dispositivo. Puede utilizar la directiva de seguridad predeterminada proporcionada en NetScreen-Security Manager o puede crear una directiva de seguridad personalizada para las funciones de cortafuegos/VPN en el dispositivo.

Ejemplo 1: Configuración básica de IDPEn este ejemplo, se implementa un dispositivo de Juniper Networks con funcionalidad de cortafuegos/VPN/IDP. Antes de empezar la configuración, asegúrese que su dispositivo tenga capacidad para IDP según se describe en “Dispositivos de seguridad con capacidad para IDP” en la página 176. Configure el dispositivo como se muestra en la Figura 57, después realice lo siguiente:

1. Conecte físicamente los componentes de la red.

2. Agregue los componentes de red que desea que IDP proteja mediante la CLI, WebUI o NetScreen-Security Manager UI.

Figura 57: Configuración del dispositivo para IDP básica

NOTA: Aunque puede realizar la configuración básica del dispositivo mediante la WebUI o CLI de ScreenOS, necesita NSM para configurar y administrar IDP en el dispositivo de seguridad.

H A

F LA S H

P W R

FA N

A LA R M

M O D1

T E MP

M O D2

S TAT U S

M O D3 ISG 2000

Zona Untrust

Dispositivo de seguridad Juniper Networks

Zona Trust

Internet

FTP-Srv1



Estos componentes pueden ser enrutadores, servidores, estaciones de trabajo, subredes o cualquier otro objeto conectado a su red. En NetScreen-Security Manager, estos componentes de red se representan como objetos de direcciones. También puede crear grupos de objetos de direcciones que representan múltiples objetos de direcciones. Para obtener información acerca de la creación de objetos de dirección, consulte el manual manual NetScreen-Security Manager Manager Administrator's Guide.

3. Habilite IDP (el valor predeterminado es el modo en línea) en la norma del cortafuegos correspondiente para el dispositivo.

Este paso se puede realizar mediante la CLI, Web UI o NetScreen-Security Manager UI. Los comandos de CLI se muestran a continuación (para configurar mediante NSM, consulte “Habilitación de IDP en las normas de cortafuegos” en la página 189):

device-> get policyTotal regular policies 5, Default deny.ID From To Src-address Dst-address Service Action State ASTLCB9 Trust Untrust Any Any MAIL Permit enabled ---X-X4 blade1 dmz2 Any Any ANY Permit enabled ---X-X6 dmz2 blade1 Any Any ANY Permit enabled ---X-X10 Untrust Trust Any MIP(172.24.~ HTTP Permit enabled ---X-X HTTPSdevice-> get policy id 4name:"none" (id 4), zone blade1 -> dmz2,action Permit, status "enablesrc "Any", dst "Any", serv "ANY"Policies on this vpn tunnel: 0nat off, Web filtering : disabledvpn unknown vpn, policy flag 00010000, session backup: onpolicy IDP mode : disabletraffic shapping off, scheduler n/a, serv flag 00log yes, log count 0, alert no, counter no(0) byte rate(sec/min) 0/0total octets 0, counter(session/packet/octet) 0/0/0No AuthenticationNo User, User Group or Group expression setdevice-> set policy id 4device (policy:4)-> set idpdevice (policy:4)-> exitdevice-> get policy id 4policy IDP mode : inline

4. Agregue el dispositivo mediante la Netscreen-Security Manager UI.

Para agregar el dispositivo, realice el siguiente procedimiento:

a. Seleccione Device Manager > Security Devices > + (Device).

b. Introduzca un nombre de dispositivo y haga clic en Next.

c. Introduzca la dirección IP de administración y haga clic en Finish.

El nuevo dispositivo aparece en la lista de dispositivos de seguridad.



180

5. Valide la directiva de seguridad en su dispositivo.

Asegúrese de tener una directiva de seguridad para el dispositivo. Puede utilizar la directiva de seguridad predeterminada; o bien, si el dispositivo se implementa como un dispositivo integrado de cortafuegos/VPN/IDP, puede crear una directiva de seguridad personalizada para las funciones de cortafuegos/VPN en el dispositivo. Para obtener más información, consulte “Configuración de directivas de seguridad” en la página 185. Para obtener más información acerca de la configuración de directivas de seguridad mediante NSM, consulte el manual NetScreen-Security Manager Manager Administrator's Guide.

6. Importe el dispositivo.

Para import the device, haga clic con el botón secundario en el dispositivo que agregó y seleccione Import device. La importación del dispositivo copia la información de la directiva de seguridad del dispositivo al servidor NSM de manera que pueda administrar el dispositivo. La directiva importada se muestra en NSM bajo Security Policy.

Para obtener más información para agregar y configurar los dispositivos mediante NSM, consulte el manual NetScreen-Security Manager Manager Administrator's Guide. Otros ajustes de configuración incluyen el modo operativo, contraseña administrativa, asignaciones de la interfaz de la zona y configuraciones predeterminadas de ruta.

7. Agregue y configure las normas IDP en la directiva de seguridad del dispositivo.

La directiva de seguridad se configura en el dispositivo para incluir las normas IDP. Cuando actualiza la configuración en el dispositivo, la directiva de seguridad completa, incluyendo la norma IPD, adiciones o cambios, se instala en el dispositivo. Para obtener más información sobre la habilitación y configuración de las normas IDP, consulte “Configuración de las normas de IDP” en la página 191”.

8. Asigne la directiva de seguridad al dispositivo de seguridad.

9. Deje que el tráfico fluya y vea las sesiones IDP con el siguiente comando:

device->get sm statusSM CPU aval ena Sess_cnt1 1 1 10 2 1 1 83 0 1 04 0 1 05 0 1 06 0 1 0

NOTA: Si utiliza el dispositivo como un sistema IDP independiente, debe configurar una norma de cortafuegos simple que direcciona todo el tráfico para comprobarlo con las normas IDP. Para obtener más información, consulte “Configuración del dispositivo como un dispositivo IDP independiente” en la página 235.

Módulo de seguridad 1





El comando anterior muestra un módulo de seguridad (SM1 y SM2) instalado en el dispositivo. La columna CPU indica que los módulos de seguridad 2 y 3 no están instalados en el dispositivo. El estado de las dos CPU en cada módulo de seguridad se muestra en filas separadas.

El módulo de administración en el dispositivo procesa el tráfico y después lo redirecciona para la inspección de IDP en los módulos de seguridad. La carga del tráfico está equilibrada entre las dos CPU en el módulo de seguridad (consulte la columna Sess_Cnt). Si su dispositivo tiene más de un módulo de seguridad, entonces el módulo de administración equilibra la carga del tráfico entre los módulos de seguridad.

10. Actualice regularmente la base de datos de objetos de ataque en el servidor NetScreen-Security Manager.

Consulte “Administración de IDP” en la página 238 para obtener más información.

Ejemplo 2: Configuración de IDP para cambio en caso de fallo activo, pasivoEn este ejemplo, configure su dispositivo de seguridad en pares de alta disponibilidad (HA) para eliminar un posible punto de fallo del diseño de su red. La Figura 58 describe la configuración del dispositivo para configurar IDP para un cambio en caso de fallo activo, pasivo. Los dos dispositivos se encuentran en configuración de cambio en caso de fallo activo, pasivo; es decir, el dispositivo principal está activo y se encarga de administrar todas las actividades de VPN y cortafuegos, y el dispositivo de respaldo está pasivo, a la espera de que el dispositivo principal falle para tomar el control.

Figura 58: Configuración de IDP para cambio en caso de fallo activo, pasivo

NOTA: Cuando tiene más de un módulo de seguridad instalado en el dispositivo y un módulo falla, entonces las sesiones de IDP se transfieren automáticamente al siguiente módulo de seguridad.

H A

F L A S H

PW R

FA N

A L A R M

M O D 1

T E M P

M O D 2

S TAT U S

M O D 3 ISG 2000

H A

F L A S H

PW R

FA N

A L A R M

M O D 1

T E M P

M O D 2

S TAT U S

M O D 3 ISG 2000

Zona Untrust

Dispositivos de seguridad

Zona Trust

Internet

Dispositivo A

Dispositivo B

FTP-Srv1

Cambio en caso de fallo activo, pasivo

ID VSD 0 Dispositivo B (respaldo)

Dispositivo A (maestro)



182

Configure el dispositivo como se muestra en la Figura 58, después realice lo siguiente:

1. Configure el dispositivo A y el dispositivo B para IDP de la manera que se describe en el “Ejemplo 1: Configuración básica de IDP” en la página 178.

2. Para garantizar un flujo de tráfico continuo, puede cablear y configurar dos dispositivos de seguridad en un clúster redundante de tal forma que el dispositivo A actúe como un dispositivo principal y el dispositivo B actúe como su respaldo.

Cablee e1/x en el dispositivo A a e1/x en el dispositivo B. De la misma manera, cablee las interfaces e2/x. Para obtener más información sobre cómo cablear los dos dispositivos entre sí, cómo configurar las direcciones IP administradas para administrar un dispositivo de respaldo o eliminar posibles puntos de fallo al configurar conmutadores redundantes en cada lado del par de HA, consulte el Volumen 11: Alta disponibilidad.

3. Configure las interfaces de HA.

Especifique las zonas con las interfaces de HA. Enlace e1/x y e2/x a la zona HA. Establezca direcciones de IP para las interfaces de la zona Trust en ambos dispositivos.

4. Configure un clúster de protocolo de redundancia de NetScreen (NSRP).

Asigne cada dispositivo al ID 0 del clúster de NSRP. Cuando los dispositivos se convierten en miembros del clúster NSRP, las direcciones IP de sus interfaces físicas se convierten automáticamente en las direcciones IP de las interfaces de seguridad virtuales (VSI) de la ID 0 del grupo de dispositivos de seguridad virtual (VSD). Cada miembro de VSD tiene una prioridad predeterminada de 100. El dispositivo que tenga la mayor ID de unidad se convierte en el dispositivo principal del grupo VSD. Para obtener más información acerca de VSD, consulte el Volumen 11: Alta disponibilidad.

Por ejemplo, introduzca la siguiente información en cada uno de los dispositivos para configurar un clúster NSRP.

a. Agregue el dispositivo a un clúster NSRP y a un grupo VSD.

set nsrp cluster id 0

b. Habilite la sincronización de objetos en tiempo de ejecución (RTO).

set nsrp rto sync all

c. Seleccione los puertos que desea que los dispositivos supervisen.

Si el dispositivo detecta una pérdida de conexión de red en uno de los puertos supervisados, desencadena un cambio en caso de fallo en el dispositivo.



set nsrp rto-mirror syncset nsrp monitor interface ethernet1set nsrp monitor interface ethernet3set nsrp cluster id 0save

Al finalizar la configuración NSRP inicial, los miembros del grupo VSD que tengan el número de prioridad más cercano a 0 se convierten en el dispositivo principal. (El valor predeterminado es 100). Si el dispositivo A y B tienen el mismo valor de prioridad, el dispositivo con la dirección MAC superior se convierte en el dispositivo principal.

El dispositivo principal transmite todos sus ajustes de red y configuración, así como la información de la sesión actual al dispositivo de respaldo. A pesar de que el dispositivo de respaldo es pasivo, éste mantiene su sincronización con la información que recibe del dispositivo principal. Si el dispositivo principal falla, el dispositivo de respaldo se convierte en principal y asume el control del procesamiento del tráfico.

Ejemplo 3: Configuración de IDP para cambio en caso de fallo activo, activoEn este ejemplo, configure sus dispositivos de seguridad en modo de rutas o traducción de direcciones de red (NAT) y configúrelos en un clúster redundante como activos, compartiendo el tráfico distribuido entre ellos. Esto se logra mediante NSRP para crear dos grupos VSD como se muestra en la Figura 59. El dispositivo A actúa como dispositivo principal del grupo VSD1 y como el dispositivo de respaldo del grupo VSD 2. El dispositivo B actúa como el dispositivo principal del grupo VSD 2 y como el dispositivo de respaldo del grupo VSD 1. No existe punto de fallo único en una configuración activa, activa.

NOTA: La sincronización se mantiene solamente para las sesiones de cortafuegos. El cambio en caso de fallo activo no ocurre en las sesiones de IDP.



184

Figura 59: Configuración de IDP para cambio en caso de fallo activo, activo

Configure el dispositivo como se muestra en la Figura 59, después realice lo siguiente:

1. Configure el dispositivo A y el dispositivo B para IDP de la manera que se describe en el “Ejemplo 1: Configuración básica de IDP” en la página 178.

2. Para garantizar un flujo de tráfico continuo, cablee y configure dos dispositivos de seguridad en un clúster redundante.

Cablee e1/x en el dispositivo A a e1/x en el dispositivo B. De la misma manera, cablee las interfaces e2/x. Para obtener más información sobre cómo cablear los dos dispositivos entre sí, cómo configurar las direcciones IP administradas para administrar un dispositivo de respaldo o eliminar posibles puntos de fallo al configurar conmutadores redundantes en cada lado del par de HA, consulte el Volumen 11: Alta disponibilidad.

3. Configure las interfaces de HA.

Especifique las zonas con las interfaces de HA. Enlace e1/x y e2/x a la zona HA. Establezca direcciones de IP para las interfaces de la zona Trust en ambos dispositivos.

H A

F L A S H

PW R

FA N

A L A R M

M O D 1

T E M P

M O D 2

S TAT U S

M O D 3 ISG 2000

H A

F L A S H

PW R

FA N

A L A R M

M O D 1

T E M P

M O D 2

S TAT U S

M O D 3 ISG 2000

Zona Untrust

Dispositivos de seguridad

Zona Trust

Internet

Dispositivo A

Dispositivo B

FTP-Srv1

Cambio en caso de fallo activo/activo

ID VSD 0 Dispositivo B (respaldo)

Dispositivo A (maestro)

ID VSD 1 Dispositivo A (maestro)

Dispositivo A (respaldo)

NOTA: Recomendamos que instale el mismo número de módulos de seguridad en ambos dispositivos.



4. Configure un clúster NSRP activo, activo.

Los dispositivos A y B son miembros del mismo clúster NSRP y grupo VSD 0. Para un cambio en caso de fallo activo, activo; cree un segundo grupo VSD, el grupo 1.

1. Asigne la prioridad 1 al dispositivo A en el grupo 0 y la prioridad predeterminada (100) en el grupo 1.

2. Asigne la prioridad 1 al dispositivo B en el grupo 1 y la prioridad predeterminada (100) en el grupo 0.

En ambos grupos VSD, habilite la opción preempt en el dispositivo principal y establezca el tiempo de retención de asignación de prioridad en 10 segundos. Si ambos dispositivos están activos, el dispositivo A siempre será el dispositivo principal del grupo 1 y B siempre será el dispositivo principal del grupo 2.

Dispositivo Aset nsrp vsd-group id 0 priority 1set nsrp vsd-group id 0 preempt hold-down 10set nsrp vsd-group id 0 preemptset nsrp vsd-group id 1save

Dispositivo Bset nsrp vsd-group id 1 priority 1set nsrp vsd-group id 1 preempt hold-down 10set nsrp vsd-group id 1 preemptsave

Para obtener más información acerca de la creación de dos grupos de VSD, consulte el Volumen 11: Alta disponibilidad.

Cada uno de los dispositivos A y B recibe el 50 por ciento del tráfico de VPN y red. Si el dispositivo A falla, el dispositivo B se convierte en el dispositivo principal del grupo VSD 1 al mismo tiempo que continúa siendo el dispositivo principal del grupo VSD 2 y administra el 100 por ciento del tráfico.

Configuración de directivas de seguridad

Una directiva de seguridad define la manera en que sus dispositivos administrados manejan el tráfico de la red. Puede configurar múltiples directivas de seguridad en NetScreen-Security Manager, pero un dispositivo solamente puede tener una directiva de seguridad activa a la vez. Puede instalar la misma directiva de seguridad en varios dispositivos o puede instalar una directiva de seguridad única en cada dispositivo de su red.

NOTA: La sincronización se mantiene solamente para las sesiones de cortafuegos. El cambio en caso de fallo activo no ocurre en las sesiones de IDP.

Configuración de directivas de seguridad 185


186

Acerca de las directivas de seguridadCada instrucción en una directiva de seguridad se denomina norma. Las directivas de seguridad pueden incluir varias normas. Creará normas en bases de normas, conjuntos de normas que se combinan para definir una directiva de seguridad. Cada directiva de seguridad contiene la base de normas de cortafuegos de zona y global, las cuales no se pueden eliminar. Puede agregar o eliminar cualquier otra regla, Multicast, IDP, exclusión y puerta de atrás, en una directiva de seguridad; sin embargo, una directiva única solamente puede incluir una instancia de cualquier tipo de regla. Cada directiva de seguridad (todas las bases de normas combinadas) puede incluir un máximo de 40,000 normas.

Esta sección describe las bases de normas de IDP, exclusión y puerta de atrás. Para obtener más información sobre bases de normas de cortafuegos de zona y global y la base de normas de multicast, consulte la información acerca de la configuración de directivas de seguridad en el NetScreen-Security Manager Manager Administrator's Guide.

Administración de las directivas de seguridadDentro de las directivas de seguridad, puede administrar normas individuales en cada base de normas:

Determinar el orden en el que las normas se aplicarán al tráfico de la red

Desactivar una norma

Negar una dirección de origen o destino (solamente dispositivos ScreenOS 5.x)

Verificar la directiva de seguridad

Combinar directivas de seguridad

Para obtener información sobre cómo administrar su directiva de seguridad, consulte el manual NetScreen-Security Manager Manager Administrator's Guide.

Instalación de las directivas de seguridadDespués de crear una directiva de seguridad por medio de la creación de normas en una o más bases de normas, puede asignar, validar e instalar dicha directiva en dispositivos administrados específicos. Para obtener información detallada sobre cómo administrar su directiva de seguridad, consulte el manual NetScreen-Security Manager Manager Administrator's Guide.

NOTA: En la WebUI y CLI de ScreenOS, una directiva de seguridad es una instrucción única que define un origen, destino, zona, dirección y servicio. En NetScreen-Security Manager, esas mismas instrucciones se conocen como normas y una directiva de seguridad es una recopilación de normas.

NOTA: Las reglas IDP, exclusión y puerta de atrás no se incluyende la puerta de atrás al combinar dos directivas en una única directiva.

Configuración de directivas de seguridad


Uso de las bases de normas de IDP

Después de que una norma de cortafuegos (intrazonal o global) permite el paso del tráfico de la red, puede dirigir el dispositivo para que inspeccione más el tráfico en busca de ataques conocidos. NetScreen-Security Manager admite las siguientes bases de normas de IDP:

IDP: Esta base de normas protege su red de ataques al utilizar objetos de ataque para detectar ataques conocidos y desconocidos. Juniper Networks proporciona objetos de ataque predefinidos, los cuales puede utilizar en las normas de IDP. También puede configurar sus propios objetos de ataque personalizados. Para obtener más información, consulte “Configuración de los objetos de ataque de IDP” en la página 215.

Exempt: Esta base de normas funciona junto con la base de normas de IDP para evitar la generación de alarmas innecesarias. Configurará normas en esta base de normas para excluir falsos positivos conocidos o para evitar que un origen, destino o par de origen/destino específicos coincidan con una norma de IDP. Si el tráfico coincide con una norma que se encuentra en la base de normas de IDP, IDP intenta comparar el tráfico con la base de normas de exclusión antes de realizar la acción especificada.

Backdoor Detection: Esta base de normas protege su red de mecanismos instalados en un equipo host que facilita el acceso no autorizado al sistema. Los hackers que ya han comprometido un sistema, normalmente instalan puertas de atrás (como caballos de Troya) para facilitar los ataques futuros. Cuando los hackers envían información a y recuperan información de un programa por la puerta de atrás, estos generan tráfico interactivo que IDP puede detectar.

Las normas incluidas en todas las bases de normas, incluso las bases de normas Zone, Global y Multicast, se combinan para crear una directiva de seguridad. Para indicar al dispositivo que procese y ejecute las normas incluidas en las bases de normas de IDP, es necesario que habilite IDP en una norma de cortafuegos. Consulte “Habilitación de IDP en las normas de cortafuegos” en la página 189.

NOTA: Juniper Networks actualiza regularmente los objetos de ataque predefinidos para mantenerse al día con ataques descubiertos recientemente. Para obtener más información acerca de la actualización de objetos de ataque, consulte “Administración de IDP” en la página 238.

NOTA: Si importa el dispositivo a NetScreen-Security Manager, la configuración del dispositivo importado no incluye las bases de normas IDP, exclusión o puerta de atrás.

Uso de las bases de normas de IDP 187


188

Administración de las bases de normas de IDP según rolesLa administración (RBA) de NetScreen-Security Manager según roles le permite crear roles personalizados para administradores individuales de manera que tengan autoridad para visualizar o editar bases de normas de IDP. Para obtener información acerca de RBA, consulte el manual NetScreen-Security Manager Manager Administrator's Guide. Puede asignar capacidades de visualización o edición a un rol basado en una base de normas de IDP. Por ejemplo, un administrador que puede visualizar y editar una base de normas de cortafuegos solamente podrá ver bases de normas IDP y puerta de atrás.

De forma predeterminada, los roles predefinidos de administradores de sistemas y de dominios pueden visualizar y editar todas las bases de normas y los administradores de sólo lectura de sistema y dominios solamente pueden visualizar las bases de normas. Al crear un rol nuevo, el cuadro de dialogo New Role le permite especificar si un administrador puede visualizar o editar bases de normas de IDP o de puerta de atrás.

Configuración de objetos para normas de IDP Los objetos son entidades lógicas reutilizables que puede aplicar a las normas. Cada objeto que cree, se agrega a una base de datos del tipo de objeto. Puede utilizar los siguientes tipos de objetos:

objetos de direcciones que representan componentes de su red, como máquinas host, servidores y subredes. Utilizará objetos de direcciones en normas de la directiva de seguridad para especificar los componentes de red que desea proteger.

Para obtener información acerca de la creación de objetos de dirección, consulte el manual NetScreen-Security Manager Manager Administrator's Guide.

objetos de servicios que representan servicios de red que utilizan protocolos de capa de transporte como TCP, UDP, RPC y ICMP. Utilizará objetos de servicio en normas para especificar el servicio que un ataque utiliza para obtener acceso a su red. NetScreen-Security Manager incluye objetos de servicio predefinidos, una base de datos de objetos de servicio basados en servicios estándar de la industria. Si necesita agregar objetos de servicio que no están incluidos en los objetos de servicio predefinidos, puede crear objetos de servicio personalizados. Para obtener información acerca de la creación de objetos de servicio, consulte el manual NetScreen-Security Manager Manager Administrator's Guide.

objetos de ataque IDP que representan ataques conocidos y desconocidos. IDP incluye una base de datos de objetos de ataque predefinida que Juniper Networks actualiza periódicamente (consulte “Administración de IDP” en la página 238). También puede personalizar los objetos de ataque para poder detectar ataques que son únicos de su red (consulte “Configuración de los objetos de ataque de IDP” en la página 215.)

NOTA: Debe crear cada objeto en la base de datos de objetos de direcciones. No hay objetos de direcciones predeterminados.

Uso de las bases de normas de IDP


Uso de las plantillas de directivas de seguridadAl crear una nueva directiva de seguridad, cuenta con las siguientes opciones:

Crear una directiva de seguridad que incluya una norma de contrafuegos predeterminada.

Seleccionar una plantilla predefinida.

Copiar una directiva de seguridad existente a una nueva directiva, la cuál podrá modificar posteriormente.

Una plantilla es un conjunto de normas de un tipo específico de base de normas que puede utilizar como punto de inicio al crear una directiva de seguridad. Para obtener una lista de plantillas, consulte el manual NetScreen-Security Manager Manager Administrator's Guide.

Habilitación de IDP en las normas de cortafuegos

Las normas en todas las bases de normas se combinan para crear una directiva de seguridad. Los dispositivos de seguridad procesan y ejecutan normas en cada base de normas en el siguiente orden:

1. Cortafuegos basado en zonas

2. Cortafuegos Global

3. Multicast

4. IDP

5. Exclusión

6. Puerta de atrás

La habilitación de IDP en una norma de cortafuegos basada en zonas o global direcciona el tráfico que coincide con la norma del cortafuegos para comprobarlo con las bases de normas de IDP.

Para habilitar IDP en una norma de cortafuegos, haga clic en el botón secundario en la columna Rule Options en la norma de cortafuegos basada en zonas o global y seleccione DI Profile/Enable IDP. Aparece el cuadro de dialogo DI Profile/Enable IDP, según se muestra en la Figura 60.

NOTA: La acción del cortafuegos debe ser permit. No puede habilitar IDP para el tráfico que el dispositivo deniega o rechaza.

Habilitación de IDP en las normas de cortafuegos 189


190

Figura 60: Cuadro de diálogo DI Profile/Enable IDP

Habilitación de IDPDe forma predeterminada, la opción IDP está desactivada. Seleccione Enable para habilitar IDP para el tráfico que coincide con la norma del cortafuegos. Al habilitar IDP, también puede seleccionar si la función de IDP es funcionar en línea o en el modo tap en línea en el dispositivo en el que está instalada la directiva de seguridad.

Especificación del modo en línea o tap en líneaIDP en el dispositivo objetivo puede funcionar de dos maneras:

En el modo inline, IDP está directamente en la ruta del tráfico en su red y puede detectar y bloquear ataques. Por ejemplo, puede implementar el dispositivo de seguridad con capacidades de cortafuegos/VPN/IDP integradas entre Internet y la LAN, WAN o zona especial (como DMZ) de una empresa. Éste es el modo predeterminado.

En el modo inline tap, IDP recibe una copia de un paquete mientras el paquete original se redirecciona a la red. IDP examina la copia del paquete e indica cualquier problema potencial. La inspección de paquetes de IDP no afecta el redireccionamiento del paquete a la red.

Especificará el modo de IDP como parte de la directiva de seguridad del dispositivo.

NOTA: Estos ajustes del perfil de ataque se aplican solamente a la función de Deep Inspection (DI) en los dispositivos de cortafuegos/VPN. Cuando instala la licencia IDP en el dispositivo, la DI está desactivada en el dispositivo.

NOTA: Si no habilita IDP en una norma de cortafuegos para un dispositivo objetivo, aún puede configurar las normas de IDP para el dispositivo. Sin embargo, no podrá aplicar las normas de IDP al actualizar la directiva de seguridad en el dispositivo.

NOTA: Debe implementar el dispositivo con capacidad para IDP en línea. No puede conectar un dispositivo que está en modo tap en línea a un TAP externo o puerto SPAN en un conmutador.

Habilitación de IDP en las normas de cortafuegos


Configuración de las normas de IDP

La base de normas de IDP protege su red de ataques utilizando objetos de ataque para identificar una actividad maliciosa y después ejecutar las acciones correspondientes para impedir los ataques. Tenga cuidado de evitar la configuración de un gran número de normas de IDP, ya que esto podría ocasionar problemas de rendimiento.

Al crear una norma de IDP, debe especificar lo siguiente:

El tipo de tráfico de red en el que desea que IDP supervise los ataques, utilizando las siguientes características:

From Zone/To Zone: Todo el tráfico fluye de una zona origen a una de destino. Puede seleccionar cualquier zona para el origen o destino; sin embargo, la zona debe ser válida para los dispositivos de seguridad que seleccionó en la columna Install On de la norma. También puede utilizar las excepciones de zona para especificar zonas to y from para cada dispositivo.

Source IP: La dirección IP de origen desde la cual se origina el tráfico de la red. Puede establecer ésta en “any” para supervisar el tráfico de la red que se origina de cualquier dirección IP. También puede especificar “negate” para especificar todos los orígenes, excepto las direcciones especificadas.

Destination IP: La dirección IP de destino hacia la cual se envía el tráfico de la red. Puede establecer ésta en “any” para supervisar el tráfico de la red enviado hacia cualquier dirección IP. También puede especificar “negate” para especificar todos los destinos, excepto las direcciones especificadas.

Service: Los protocolos de capa de aplicación que admitidos por las direcciones IP de destino.

Terminate Match: De manera predeterminada, las normas en la base de normas son no definitivas, lo que significa que IDP examina todas las normas en la base de normas y ejecuta todas las coincidencias. Puede especificar que una norma sea definitiva; si IDP encuentra una coincidencia de origen, destino y servicio especificados en una norma definitiva, no examina ninguna norma subsiguiente en esa conexión. Observe que no es necesario que el tráfico coincida con los ataques especificados en la norma definitiva. Las normas definitivas aparecen cerca de la parte superior de la base de normas, antes de otras normas que podrían coincidir con el mismo tráfico. Tenga precaución al especificar las normas definitivas.

Consulte la Figura 70 en la página 199 y tenga en cuenta que si marca Terminate Match, las normas que aparecen bajo Terminate Match Rule (normas solapadas) no se evaluarán.

Si no marca Terminate Match, se producirá comparación/registro de múltiples eventos, lo que resultará en un ataque mediante la creación de múltiples entradas en los registros y en la realización de múltiples acciones.

Configuración de las normas de IDP 191


192

Los ataques para los que desea que IDP busque coincidencias en el tráfico de red supervisado. Cada ataque se define como un objeto de ataque, lo que representa un patrón de ataque conocido. Cada vez que se encuentra este patrón de ataque conocido en el tráfico de red supervisado, el objeto de ataque coincide. Puede agregar objetos de ataque por categoría, sistema operativo, gravedad o individualmente.

La acción que desea que IDP realice cuando el tráfico supervisado coincida con los objetos de ataque de la norma. Puede especificar lo siguiente:

Action: La acción que desea que IDP realice con la conexión actual.

IP Actions: La acción que desea que IDP realice contra conexiones futuras que utilicen la misma dirección IP.

Notification: Seleccione none; o habilite el registro y seleccione las opciones de registro correspondientes a su red.

Severity: Utilice los ajustes de gravedad predeterminados de los objetos de ataque seleccionados o elija un nivel de gravedad específica para su norma.

Adición de la base de normas de IDPAntes de que pueda configurar una norma en la base de normas, debe agregar la base de normas de IDP a una directiva de seguridad mediante los siguientes pasos:

1. En el árbol de navegación principal, seleccione Security Policies. Abra una directiva de seguridad haciendo doble clic en el nombre de la directiva en la ventana Security Policy o en el nombre de la directiva y seleccionando el icono Edit.

2. Haga clic en el icono Add que se encuentra en la esquina derecha superior de la ventana Security Policy y seleccione Add IDP Rulebase. Consulte la Figura 61.

Figura 61: Adición de la base de normas de IDP



Aparece la ficha de la base de normas de IDP. Consulte la Figura 62.

Figura 62: Base de normas de IDP agregada

3. Para configurar una norma de IDP, haga clic en el icono Add que se encuentra en el lado izquierdo de la ventana Security Policy.

Aparece una norma de IDP predeterminada. Puede modificar esta norma según sea necesario. Consulte la Figura 63.

Figura 63: Norma de IDP agregada

Tráfico coincidenteAl crear sus normas de IDP, debe especificar el tipo de tráfico de red en el que desea que IDP supervise los ataques. Estas características incluyen los componentes de red que originan y reciben el tráfico y las zonas de cortafuegos a través de las cuales pasa el tráfico.

Las columnas de coincidencia From Zone, Source, To Zone, Destination y Service son necesarias para todas las normas en la base de normas de IDP. La selección Terminate Match le permite designar una norma como definitiva; si IDP encuentra una coincidencia para otras columnas de coincidencia en la norma definitiva, no examinará ninguna otra norma en la base de normas. No es necesario que el tráfico coincida con los ataques especificados en la norma definitiva. (Para obtener más información, consulte “Normas definitivas” en la página 198.)

Las siguientes secciones describen en detalle las columnas de coincidencia de una norma de IDP.



194

Zonas de origen y de destinoPuede seleccionar varias zonas de origen y de destino; sin embargo, estas zonas deben estar disponibles en los dispositivos de seguridad en los cuales instalará la directiva. Puede especificar “any” en las zonas de origen y de destino para supervisar el tráfico de red que se origina desde o está destinado hacia cualquier zona.

Objetos de dirección de origen y de destinoEn el sistema NetScreen-Security Manager, los objetos de dirección se utilizan para representar componentes en su red: Hosts, redes, servidores, etc. Normalmente, un servidor u otro dispositivo de su red es la IP de destino para los ataques entrantes y algunas veces puede ser la IP de origen para ataques interactivos (consulte “Configuración de las normas de puerta de atrás” en la página 210 para obtener más información sobre ataques interactivos). Puede especificar “any” para supervisar el tráfico de la red que se origina desde cualquier dirección IP. También puede especificar “negate” en los objetos de dirección enumerados en la columna Source o Destination para especificar todos los orígenes o destinos excepto los objetos excluidos.

Puede crear objetos de dirección antes de crear una norma de IDP (consulte el manual NetScreen-Security Manager Administrator's Guide) o mientras crea o edita una norma de IDP. Para seleccionar o configurar un objeto de dirección, haga clic con el botón secundario en la columna Source o Destination de una norma y seleccione Select Address. En el cuadro de diálogo Select Source Addresses puede seleccionar un objeto de dirección que ya está creado o hacer clic en el icono Add para crear un nuevo host, red u objeto de grupo.

Ejemplo: Establecimiento de origen y de destinoDesea detectar ataques entrantes dirigidos a su red interna. Establezca el valor de From Zone en Untrust y Source IP en any. Establezca el valor de To Zone en dmz y trust. Seleccione el objeto de dirección que representa el host o servidor que desea proteger de ataques como la IP de destino.

Su norma se parece al ejemplo que se muestra en la Figura 64.

Figura 64: Establecimiento de origen y destino

NOTA: Puede crear zonas personalizadas para algunos dispositivos de seguridad. La lista de zonas desde las que puede seleccionar zonas de origen y de destino incluye las zonas predefinidas y personalizadas que se han configurado para todos los dispositivos administrados por NetScreen-Security Manager. Por lo tanto, solamente deberá seleccionar zonas aplicables al dispositivo en el que desea instalar la directiva de seguridad.



Ejemplo: Establecimiento de múltiples orígenes y destinosDesea detectar ataques entre dos redes. Seleccione múltiples objetos de dirección para el origen y destino.


Figura 65: Establecimiento de redes de múltiples orígenes y destinos

Cuanto más específico sea al definir el origen y destino de un ataque, más reducirá los falsos positivos.

ServiciosLos servicios son protocolos de capa de aplicación que definen la manera en que se estructuran los datos a medida que pasan a través de la red. Debido a que los servicios que admite en su red son los mismos servicios que los hackers deben utilizar para atacar su red, puede especificar los servicios admitidos en la IP de destino para que su norma sea más eficiente.

Los objetos de servicio representan los servicios que se ejecutan en su red. NetScreen-Security Manager incluye objetos de servicio predefinidos que se basan en servicios estándar de la industria. Utilizará estos objetos de servicio en las normas para especificar el servicio que un ataque utiliza para obtener acceso a su red. También puede crear objetos de servicio personalizados para representar protocolos que no están incluidos en los servicios predefinidos. Para obtener más información acerca de la configuración de objetos de servicio, consulte la información sobre configuración de objetos en el NetScreen-Security Manager Manager Administrator's Guide.

En la columna Service, seleccionará el servicio del tráfico que desee que IDP compare:

Seleccione Default para aceptar el servicio especificado por el objeto de ataque que seleccionó en la columna Attacks. Cuando selecciona un objeto de ataque en la columna Attack, el servicio asociado con dicho objeto de ataque se convierte en el servicio predeterminado para la norma. Para ver el servicio exacto, visualice los detalles del objeto de ataque.

Seleccione Any para establecer cualquier servicio.

Seleccione Select Service para escoger servicios específicos de la lista de los objetos de servicio definidos.

NOTA: Todos los servicios dependen de un protocolo de capa de transporte para transmitir los datos. IDP incluye servicios que utilizan los protocolos de capa de transporte de TCP, UDP, RCP e ICMP.



196

Ejemplo: Establecimiento de los servicios predeterminadosDesea proteger su servidor FTP de ataques FTP. Establezca el servicio en Default y agregue un objeto de ataque que detecte intentos de desbordamiento de búfer FTP. La columna Service en la norma aún muestra "Default", pero la norma en realidad utiliza el servicio predeterminado TCP-FTP, que está especificado en el objeto de ataque.


Figura 66: Establecimiento de servicios predeterminados

Ejemplo: Establecimiento de servicios específicosSu servidor de correo admite conexiones POP3 y SMTP, pero no admite IMAP. Establezca los objetos de servicio POP3 Y SMTP como servicios que se pueden utilizar para atacar al servidor de correo. Debido a que IMAP no se admite, no es necesario que agregue el objeto de servicio IMAP.


Figura 67: Establecimiento de servicios específicos

Si admite servicios en puertos no estándar, debe elegir un servicio que no sea el predeterminado.

Ejemplo: Establecimiento de servicios no estándarUtilizará un puerto no estándar (8080) para sus servicios HTTP, y el administrador de objetos para crear un objeto de servicio personalizado en el puerto 8080.



Figura 68: Agregue objetos de servicios no estándar

Agregue este objeto de servicio a su norma, después agregue varios objetos de ataque HTTP, que tienen un servicio predeterminado de TCP/80. IDP utiliza el servicio especificado, HTTP-8080 en lugar del servicio predeterminado y busca coincidencias con los ataques HTTP en el tráfico TCP en el puerto 8080.


Figura 69: Establecimiento de servicio no estándar

Puede crear sus propios objetos de servicio para utilizar en normas, como por ejemplo objetos de servicio para protocolos que utilizan puertos no estándar. Sin embargo, no puede comparar objetos de ataque con los protocolos que éstos no utilizan.



198

Normas definitivasEl algoritmo normal para coincidencia de normas IDP empieza desde la parte superior de la base de normas y comprueba el tráfico con todas las normas en la base de normas que coinciden con el origen, destino y servicio. Una norma definitiva es una excepción a este algoritmo normal de coincidencia de normas. Cuando se descubre una coincidencia en una norma definitiva para el origen, destino y servicio, IDP no continúa comprobando normas subsecuentes del mismo origen, destino y servicio. No importa si el tráfico coincide o no con los objetos de ataque de la norma de coincidencia.

Puede utilizar una norma definitiva para los siguientes propósitos:

Para establecer diferentes acciones para diferentes ataques del mismo origen y destino. Esto se describe por medio de las normas 3 y 6 en la siguiente sección, “Ejemplo: Establecimiento de normas definitivas”.

Para pasar por alto el tráfico que se origina desde un origen fiable conocido. Normalmente, la acción es None para este tipo de norma definitiva. Esto se describe por medio de la norma 1 en la siguiente sección, “Ejemplo: Establecimiento de normas definitivas”.

Para pasar por alto el tráfico enviado a un servidor que solamente es vulnerable a un conjunto de ataques específico. Normalmente, la acción es Drop Connection para este tipo de norma definitiva.

Tenga precaución al definir las normas definitivas. Una norma definitiva inapropiada puede dejar su red abierta a los ataques. Recuerde que el tráfico que coincide con el origen, destino y servicio de una norma definitiva no se compara con normas subsecuentes, aunque el tráfico no coincida con un objeto de ataque de la norma definitiva. Utilice una norma definitiva solamente cuando desee examinar un tipo específico de tráfico para un conjunto de objetos de ataque específicos. Tenga cuidado particularmente con las normas definitivas que utilizan “any” tanto en el origen como en el destino.

Las normas definitivas deben aparecer cerca de la parte superior de la base de normas, antes de otras normas que coincidirán con el mismo tráfico. Establecerá una norma como definitiva seleccionando la casilla en la columna Terminate Match de la ventana Security Policy en el momento de crear o modificar la norma.

Ejemplo: Establecimiento de normas definitivasEn el ejemplo de la base de normas de IDP que se muestra a continuación, las normas 1, 3, 4 y 5 están configuradas como normas definitivas:

La norma 1 concluye el algoritmo de coincidencia si la IP de origen del tráfico se origina desde una red de seguridad, una red fiable conocida. Si esta norma encuentra coincidencias, IDP pasa por alto el tráfico de la red de seguridad y no continúa supervisando la sesión en busca de datos maliciosos.

NOTA: En muchos casos, puede utilizar una norma de exclusión en lugar de una norma definitiva. Es posible que le resulte más fácil y más directo configurar una norma de exclusión que una norma definitiva. Consulte la “Configuración de las normas de exclusión” en la página 205.



Las normas 3 y 6 establecen diferentes acciones para diferentes ataques cuando la IP de destino es el servidor de correo Corporate o Europe. La norma 3 concluye el algoritmo de coincidencia cuando el ataque es un correo electrónico que utiliza el contexto SMTP Confidential. La norma 6 cierra el servidor cuando el ataque es un ataque SMTP.

La norma 4 concluye el algoritmo de coincidencia cuando el destino es el servidor web y el ataque es un ataque de HTTP con gravedad Critical o High. La norma garantiza que IDP descargue los ataques de HTTP más importantes contra el servidor web y no continúa buscando coincidencias en la conexión.

La norma 5 concluye el algoritmo de coincidencia cuando el origen es la red interna y el ataque es un ataque de caballo de Troya por la puerta de atrás con nivel de gravedad Critical, High o Medium. La norma garantiza que IDP terminará la conexión del cliente y del servidor y no continuará buscando coincidencias en la conexión.

El valor predeterminado en la columna Service (consulte Figura 70 en la página 199) significa que la norma se creó dinámicamente con base en los enlaces de servicio de objetos de ataque de esa norma. Para ver los enlaces de servicio de una norma, haga clic con el botón secundario sobre los ataques y seleccione View Services. Incluso si seleccionó una categoría amplia como HTTP Critical, utilice View Services para obtener más detalles.

Figura 70: Establecimiento de normas definitivas

Definición de accionesPuede especificar qué acciones debe realizar IDP contra ataques que coincidan con las normas que estableció en su directiva de seguridad. Para cada ataque que coincida con una norma, puede elegir ignorar, descartar o terminar la conexión o los paquetes de ataque actuales. Si la norma se desencadena, IDP puede realizar acciones contra la conexión.

Cuando IDP se configura para descartar paquetes y encuentra un ataque TCP, el módulo de seguridad informa al módulo de administración de que los paquetes sucesivos son ataques y en consecuencia la acción de IDP se actualiza en un nivel mayor de gravedad, descarte de conexión.



200

Si un paquete activa varias acciones de norma, el dispositivo aplicará la acción más drástica. Por ejemplo, si las normas establecen que un paquete recibirá una marca diffserv y luego se descartará, entonces el paquete se descartará.

La Tabla 16 muestra las acciones que puede especificar para las normas de IDP.

Tabla 16: Acciones para la norma de IDP

Para obtener más información sobre las acciones de la norma IDP, consulte el manual NetScreen-Security Manager Manager Administrator's Guide.

Establecimiento de objetos de ataqueLos objetos de ataque representan patrones específicos de actividad maliciosa dentro de una conexión y son un método para detectar ataques. Cada objeto de ataque detecta un ataque conocido o desconocido que se puede utilizar para comprometer su red. Para obtener más información acerca de los objetos de ataque, consulte “Configuración de los objetos de ataque de IDP” en la página 215.

Acción Descripción

Ninguna IDP no realiza ninguna acción contra la conexión. Si una norma que incluye una acción de None coincide, el registro correspondiente muestra “accept” en la columna Action del visualizador de registros.

Ignore IDP ignora un flujo para inspecciones futuras si se encontró una coincidencia de ataque. En general, evite seleccionar esta acción.

Nota: Esta acción no significa ignorar un ataque.

Diffserv Marking Asigna el valor de service-diferentiation indicado para los paquetes que están en un ataque, luego los pasa normalmente. Establezca el valor de service-diferentiation en el cuadro de diálogo que aparece al seleccionar esta acción en la base de normas.

Observe que la marca diffserv no se aplica al primer paquete que se detecta como un ataque, sino que se aplica a los paquetes subsiguientes. La marca no tiene efecto en el modo tap o cuando se utiliza NSRP.

Drop Packet IDP descarta un paquete de coincidencia antes de que pueda llegar a su destino pero no termina la conexión. Utilice esta acción para descartar paquetes en caso de ataques en el tráfico propenso a simulaciones, como el tráfico de UDP. Descartar una conexión para dicho tráfico podría resultar en un rechazo del servicio que impide que reciba tráfico de una dirección IP de origen legítimo.

Drop Connection IDP descarta todos los paquetes asociados con la conexión. Utilice esta acción para descartar conexiones del tráfico que no es propenso a simulación.

Close Client and Server IDP termina la conexión y envía un paquete RST al cliente y al servidor. Si IDP está funcionando en el modo tap en línea, IDP envía un paquete RST al cliente y al servidor, pero no termina la conexión.

Close Client IDP termina la conexión al cliente pero no al servidor.

Close Server IDP termina la conexión al servidor, pero no al cliente.



Puede agregar objetos de ataque a su norma individualmente o en grupos. Los objetos de ataque están organizados de la siguiente manera:

La lista de ataques es una lista alfabética de todos los objetos de ataque, incluyendo objetos de ataque personalizados.

El Grupo de ataques dinámicos contiene grupos de ataque predefinidos y personalizados.

Para agregar objetos de ataque a una norma, haga clic con el botón secundario en la columna Attacks y seleccione Select Attacks. Aparece el cuadro de diálogo Add Attacks.

Adición de objetos de ataque individualmenteLa lista de ataques le permite seleccionar uno o más objetos de ataque específicos de su norma. La lista de ataques contiene objetos de ataque mostrados en orden alfabético. También puede utilizar la función de búsqueda integrada en NetScreen-Security Manager para buscar una cadena o palabra específica en el nombre del objeto de ataque. Para obtener más información acerca del uso de la función de búsqueda, consulte el manual NetScreen-Security Manager Manager Administrator's Guide.

Para obtener más información sobre los objetos de ataque y la creación de grupos y objetos de ataque personalizados, consulte “Configuración de los objetos de ataque de IDP” en la página 215.

Adición de objetos de ataque por categoríaLos grupos de IDP atacan objetos en grupos de categoría de servicio predefinidos. Los servicios son protocolos de capa de aplicación que definen la manera en que los datos están estructurados a medida que pasan a través de la red.

Para atacar un sistema, un hacker debe utilizar un protocolo admitido en dicho sistema. Por lo tanto, cuando cree una norma para proteger un sistema, debe seleccionar solamente las categorías utilizadas por los objetos de dirección que está protegiendo con la norma.

Ejemplo: Adición de objetos de ataque por servicioDependerá de FTP y HTTP para una transferencia extensa de archivos a su servidor web. Seleccione los grupos de categoría FTP y HTTP para supervisar cuidadosamente todo el tráfico que utiliza estos servicios.

Si no desea seleccionar un grupo de categoría completo para una norma, puede seleccionar sus objetos de ataque por gravedad.

Adición de objetos de ataque por sistema operativoLos grupos IDP atacan objetos de sistemas operativos predefinidos para ayudarle a seleccionar los objetos de ataque que son los más peligrosos para dispositivos específicos en su red. Puede seleccionar BSD, Linux, Solaris o Windows.

Si no desea seleccionar un grupo de sistema operativo completo para una norma, puede seleccionar sus objetos de ataque por gravedad.



202

Adición de objetos de ataque por gravedadIDP define cinco niveles de gravedad, cada uno con un conjunto recomendado de notificaciones y acciones de IDP (consulte la Tabla 17). Podrá agregar un nivel de gravedad a la columna Attacks en su norma y elegir las acciones recomendadas para el nivel de gravedad en la columna Action. (Para obtener más información sobre las acciones que puede seleccionar, consulte “Definición de acciones” en la página 199). También puede elegir las notificaciones recomendadas para el nivel de gravedad en la columna Notifications. (Para obtener más información sobre las notificaciones que puede seleccionar, consulte “Establecimiento de la notificación” en la página 204).

La Tabla 17 muestra los niveles de gravedad de IDP, junto con sus notificaciones y acciones recomendadas.

Tabla 17: Niveles de gravedad con notificaciones y acciones recomendadas

Establecimiento de la acción de IPLa columna IP Action aparece solamente cuando visualiza la directiva de seguridad en modo ampliado. Para cambiar la visualización de la directiva de seguridad de modo compacto a ampliada, seleccione View > Expanded Mode.

Si el tráfico de red actual coincide con una norma, IDP puede realizar una acción de IP contra futuro tráfico de red que utilice la misma dirección IP. Las acciones de IP son similares a otras acciones; direccionan IDP para que descarte o termine la conexión. Sin embargo, debido a que ahora ya tiene la dirección IP del hacker, puede elegir bloquear al hacker durante un tiempo especificado. Si los hackers no pueden volver a conectarse inmediatamente a su red, es posible que intenten atacar objetivos más fáciles.

NOTA: Para proteger objetos de dirección esenciales u objetivos populares para el ataque, como su servidor de correo, utilice niveles de gravedad para garantizar una máxima protección.

Nivel de gravedad Descripción Acción recomendada

Notificación recomendada

Critical Los ataques intentan evadir un IPS, que una máquina se quede colgada u obtener privilegios a nivel del sistema.

Drop PacketDrop Connection

LoggingAlert

Major Los ataques intentan que el servicio se caiga, realizar un rechazo de servicio, instalar o utilizar un caballo de Troya, u obtener acceso a nivel de usuario a un host.

Drop PacketDrop Connection

LoggingAlert

Minor Los ataques intentan obtener información esencial mediante la navegación de directorios o filtraciones de información.

Ninguna Logging

Warning Los ataques intentan obtener información no esencial o analizar la red. También puede ser tráfico de ataques obsoletos (pero probablemente inofensivos).

Ninguna Logging

Info Los ataques son tráfico normal, inofensivo que contiene fallos de búsqueda de URL, DNS y cadenas de comunidad públicas SNMP. Puede utilizar los objetos de ataque de información para obtener información sobre su red.

Ninguno Ninguno



Utilice acciones de IP junto con acciones y registro para asegurar su red. En una norma, primero configure una acción para detectar e impedir que conexiones maliciosas actuales alcancen sus objetos de dirección. Después, haga clic con el botón secundario en la columna IP Action de la norma y seleccione Configure para ver el cuadro de diálogo Configure IP Action. Habilite y configure una acción de IP para impedir conexiones maliciosas futuras desde la dirección IP del hacker.

Selección de una acción de IPPara cada opción de acción de IP, el sistema IDP genera una acción de IP. La acción de IP indica a IDP que realice la tarea especificada. Seleccione una de las siguientes opciones:

IDP Notify. IDP no lleva a cabo ninguna acción contra el tráfico futuro, pero registra el evento. Éste es el valor predeterminado.

IDP Drop. IDP descarta las conexiones futuras de bloqueo que coinciden con los criterios del cuadro Blocking Options.

IDP Close. IDP cierra futuras conexiones que coinciden con el criterio que se encuentra en el cuadro Blocking Options.

Selección de una opción de bloqueoCada opción de bloqueo obedece al criterio que estableció en el cuadro Actions. Las opciones de bloqueo se pueden basar en las siguientes coincidencias del tráfico de ataque:

Source, Destination, Destination Port y Protocol. IDP bloquea el tráfico futuro basándose en el origen, destino, puerto de destino y protocolo del tráfico de ataque. Éste es el valor predeterminado.

Source. IDP bloquea el tráfico futuro basándose en el origen del tráfico de ataque.

Destination. IDP bloquea el tráfico futuro basándose en el destino del tráfico de ataque.

From Zone, Destination, Destination Port y Protocol. IDP bloquea el tráfico futuro basándose en la zona de origen, destino, puerto de destino y protocolo del tráfico de ataque.

From Zone. IDP bloquea el tráfico futuro basándose en la zona de origen del tráfico de ataque.

Establecimiento de las opciones de registroCuando IDP detecta tráfico de ataque que coincide con una norma y desencadena una acción de IP, IDP puede registrar información sobre la acción de IP o crear una alerta en el visualizador de registros. De forma predeterminada, no hay opciones de registro establecidas.

Establecimiento de las opciones de tiempo de esperaPuede establecer el número de segundos que desea que la acción de IP permanezca vigente después de una coincidencia de tráfico. Para las acciones de IP permanentes, el valor del tiempo de espera predeterminado es 0.



204

Establecimiento de la notificaciónLa primera vez que diseña una directiva de seguridad, es posible que se sienta tentado a registrar todos los ataques y dejar que la directiva se ejecute indefinidamente. ¡No haga esto! Algunos objetos de ataque son solamente informativos y otros pueden generar falsos positivos y registros redundantes. Si está sobrecargado con datos, podría pasar por alto algo importante. Recuerde que las directivas de seguridad que generan demasiados registros son peligrosas para la seguridad de su red, ya que podría descubrir un ataque demasiado tarde o pasar por alto una violación de la seguridad completamente si tiene que filtrar a través de cientos de registros. El exceso de registros también puede afectar a la capacidad de ejecución de IDP, el rendimiento y el espacio disponible en el disco. Una buena directiva de seguridad genera suficientes registros para documentar completamente sólo los eventos de seguridad importantes en la red.

Establecimiento de los registrosEn el cuadro de diálogo Configure Notification, seleccione Logging y haga clic en OK. Cada vez que hay una coincidencia de la norma, el sistema IDP crea un registro que aparece en el visualizador de registros.

El registro de un ataque crea un registro que puede visualizar en tiempo real en el visualizador de registros. Para ataques más críticos, también puede establecer un indicador de alerta para que aparezca en el registro.

Para registrar un ataque de una norma, haga clic con el botón secundario en la columna Notification de la norma y seleccione Configure. Aparece el cuadro de diálogo Configure Notification.

Establecimiento de una alertaEn el cuadro de diálogo Configure Notification, seleccione Alert y haga clic en OK. Si selecciona Alert y hay una coincidencia para la norma, IDP coloca un indicador de alerta en la columna Alert del visualizador de registros para el registro coincidente.

Paquetes de registroPuede registrar paquetes individuales en el tráfico de red que coincidan con una norma calculando los datos del paquete de ataque. La visualización de los paquetes utilizados en un ataque en su red puede ayudarle a determinar la magnitud del intento de ataque y su propósito, si el ataque ha tenido éxito o no, y cualquier daño posible ocasionado a su red.

Si múltiples normas con la captura de paquetes habilitada coinciden con el mismo ataque, IDP captura el número máximo de paquetes especificado. Por ejemplo, configure la norma 1 para capturar 10 paquetes antes y después del ataque y configure la norma 2 para capturar 5 paquetes antes y después del ataque. Si ambas normas coinciden con el mismo ataque, IDP intenta capturar 10 paquetes antes y después del ataque.

NOTA: Para mejorar el rendimiento de IDP, registre solamente los paquetes recibidos después del ataque.



Establecimiento de la gravedadLa columna Severity aparece solamente cuando visualiza la directiva de seguridad en modo ampliado. Para cambiar la visualización de la directiva de seguridad de modo compacto a ampliado, de la barra de menú, seleccione View > Expanded Mode.

Puede ignorar la gravedad inherente a un ataque en base a cada norma dentro de la base de normas de IDP. Puede establecer el nivel de gravedad en Default, Info, Warning, Minor, Major o Critical.

Para cambiar la gravedad de una norma, haga clic con el botón secundario en la columna Severity de la norma y seleccione un nivel de gravedad.

Establecimiento de objetivosPara cada norma de la base de normas de IDP, puede seleccionar el dispositivo de seguridad que utilizará esa norma para detectar e impedir los ataques. Cuando instala la directiva de seguridad a la cual pertenece la norma, ésta se activa solamente en el dispositivo que seleccionó en la columna Install On de la base de normas.

Introducción de comentariosPuede introducir anotaciones sobre la norma en la columna Comments. La información de la columna Comments no se envía al dispositivo objetivo. Para introducir un comentario, haga clic con el botón secundario en la columna Comments y seleccione Edit Comments. Aparece el cuadro de diálogo Edit Comments. Puede introducir un comentario de hasta 1024 caracteres.

Configuración de las normas de exclusión

La base de normas de exclusión funciona junto con la base de normas de IDP. Antes de que pueda crear normas de exclusión, debe crear primero normas en la base de normas de IDP. Si el tráfico coincide con una norma que se encuentra en la base de normas de IDP, IDP intenta comparar el tráfico con la base de normas de exclusión antes de realizar la acción especificada o crear un registro del evento.

Es posible que desee utilizar una norma de exclusión con las siguientes condiciones:

Cuando una norma de IDP utiliza un grupo de objetos de ataque que contiene uno o más objetos de ataque que producen falsos positivos o registros irrelevantes.

NOTA: Las capturas de paquetes están restringidas a 256 paquetes antes y después de un ataque.

NOTA: Si elimina la base de normas de IDP, la base de normas de exclusión también se elimina.

Configuración de las normas de exclusión 205


206

Cuando desea excluir la coincidencia de un origen, destino o par origen/destino específicos con una norma de IDP. Esto impide que IDP genere alarmas innecesarias.

También puede utilizar una norma de exclusión si la base de normas de IDP utiliza grupos de objetos de ataque dinámicos o estáticos que contengan uno o más objetos de ataque que producen falsos positivos o registros irrelevantes.

Al crear una norma de exclusión, debe especificar lo siguiente:

El origen y destino del tráfico que desea excluir. Puede establecer el origen o destino en “any” para excluir el tráfico de la red que se origina de cualquier origen o se envía a cualquier destino. También puede especificar “negate” para especificar todos los orígenes o destino, excepto las direcciones especificadas.

Los ataques que desea que IDP excluya en las direcciones de origen/destino especificadas. Debe incluir por lo menos un objeto de ataque en una norma de exclusión.

Adición de la base de normas de exclusiónAntes de que pueda configurar una norma en la base de normas de exclusión, debe agregar la base de normas de exclusión a una directiva de seguridad mediante los siguientes pasos:

1. En el árbol de navegación principal, seleccione Security Policies. Abra una directiva de seguridad haciendo doble clic en el nombre de la directiva en la ventana Security Policies o en el nombre de la directiva y seleccionando el icono Edit.

2. Haga clic en el icono Add que se encuentra en la esquina derecha superior de la ventana Security Policy y seleccione Add Exempt Rulebase.

Figura 71: Adición de una base de normas de exclusión

Aparece la ficha Add Exempt Rulebase.

NOTA: La base de normas de exclusión es una base de normas no definitivas. Es decir, IDP intenta coincidir el tráfico con todas las normas en la base de normas de exclusión y ejecuta todas las coincidencias.



Figura 72: Base de normas de exclusión agregada

3. Para configurar una norma de exclusión, haga clic en el icono Add que se encuentra en el lado izquierdo de la ventana Security Policy.

Aparece una norma de exclusión predeterminada. Puede modificar esta norma según sea necesario.

Figura 73: Norma de exclusión agregada

Definición de una coincidenciaEspecifique el tráfico que desea excluir de la detección de ataques. Las columnas de coincidencia From Zone, Source, To Zone y Destination son necesarias para todas las normas en la base de normas de exclusión.

Las siguientes secciones describen en detalle las columnas de coincidencia de una norma de exclusión.

Zonas de origen y de destinoPuede seleccionar múltiples zonas de origen y de destino; sin embargo, estas zonas deben estar disponibles en los dispositivos en los cuales instalará la directiva. Puede especificar “any” en las zonas de origen y de destino para supervisar el tráfico de red que se origina desde o está destinado hacia cualquier zona.




208

Objetos de dirección de origen y de destinoEn el sistema NetScreen-Security Manager, los objetos de dirección se utilizan para representar componentes en su red. Hosts, redes, servidores, etc. Puede especificar “any” para supervisar el tráfico de la red que se origina desde cualquier dirección IP. También puede negar los objetos de dirección enumerados en la columna Source o Destination de una norma para especificar todos los orígenes o destinos excepto el objeto excluido.

Puede crear objetos de dirección antes de crear una norma de exclusión (consulte el manual NetScreen-Security Manager Administrator's Guide) o mientras crea o edita una norma de exclusión. Para seleccionar o configurar un objeto de dirección, haga clic con el botón secundario en la columna Source o Destination de una norma y seleccione Select Address. En el cuadro de diálogo Select Source Addresses puede seleccionar un objeto de dirección que ya está creado o hacer clic en el icono Add para crear un nuevo host, red u objeto de grupo.

Ejemplo: Exclusión de un par origen/destinoPara mejorar el rendimiento y eliminar falsos positivos entre sus dispositivos Lab internos y sus escritorios de ingeniería, desea excluir la detección de ataques. Su norma de exclusión se parece a la Figura 74:

Figura 74: Exclusión de origen y destino

Establecimiento de los objetos de ataqueEl usuairo especifica los ataques que desea que IDP excluya en las direcciones de origen/destino especificadas. Debe incluir por lo menos un objeto de ataque en una norma de exclusión.

Ejemplo: Exclusión de objetos de ataque específicosConstantemente detecta que su directiva de seguridad genera falsos positivos para ataque HTTP Buffer Overflow: Header en su red interna. Desea excluir la detección de ataques para este ataque cuando la IP de origen es desde su red interna. Su norma de exclusión se parece a la Figura 75:



Figura 75: Exclusión de un objeto de ataque

Establecimiento de objetivosPara cada norma de la base de normas de exclusión, puede seleccionar el dispositivo con capacidad para IDP que utilizará esa norma para detectar e impedir ataques. Cuando instala la directiva de seguridad a la cual pertenece la norma, ésta se activa solamente en el dispositivo que seleccionó en la columna Install On de la base de normas.

Introducción de comentariosPuede introducir anotaciones sobre la norma en la columna Comments. La información de la columna Comments no se envía al dispositivo objetivo. Para introducir un comentario, haga clic con el botón secundario en la columna Comments y seleccione Edit Comments. Aparece el cuadro de diálogo Edit Comments. Puede introducir un comentario de hasta 1024 caracteres.

Creación de una norma de exclusión desde el visualizador de registrosTambién puede crear una norma en la base de normas de exclusión directamente desde el visualizador de registros de NetScreen-Security Manager. Es posible que desee utilizar este método para eliminar rápidamente normas que generan registros de falsos positivos. Para obtener más información sobre cómo visualizar registros de IDP, consulte “Administración de IDP” en la página 238. Para obtener más información acerca del uso del visualizador de registros, consulte el manual NetScreen-Security Manager Manager Administrator's Guide.

Para crear una norma de exclusión desde el visualizador de registros, realice los siguientes pasos:

1. Visualice los registros de IDP/DI en el visualizador de registros.

2. Haga clic con el botón secundario en un registro que contenga un ataque que desea excluir y seleccione Exempt.



210

Figura 76: Exclusión de una norma de registro

Se muestra la base de normas de exclusión de la directiva de seguridad que generó el registro, con la norma de exclusión asociada a la entrada del registro. Los ajustes de origen, destino y ataque de la norma se llenan automáticamente basándose en la información del registro.

Puede modificar, volver a ordenar o combinar una norma de exclusión creada desde el visualizador de registros de la misma manera que otra norma de exclusión que cree directamente en la base de normas de exclusión.

Configuración de las normas de puerta de atrás

Un puerta de atrás es un mecanismo instalado en un equipo host que facilita el acceso no autorizado al sistema. Los hackers que ya han comprometido un sistema, pueden instalar una puerta de atrás para facilitar los ataques futuros. Cuando los hackers escriben comandos para controlar una puerta de atrás, generan tráfico interactivo.

A diferencia de un software de antivirus que analiza en busca de puerta de atrás o archivos ejecutables en el sistema host, IDP detecta el tráfico interactivo que se produce al utilizar puertas de atrás. Si detecta tráfico interactivo, IDP puede realizar acciones de IP contra la conexión para impedir que un hacker comprometa más su red.

Cuando configure una norma de puerta de atrás, debe especificar lo siguiente:

Las direcciones de origen y destino del tráfico que desea supervisar. Para detectar el tráfico interactivo entrante, establezca el origen en “any” y el destino de la dirección de IP del dispositivo de red que desea proteger. Para detectar el tráfico interactivo saliente, establezca el origen en la dirección IP del dispositivo de red que desea proteger y el destino en “any”.

NOTA: Si la base de normas no existe cuando cree una norma de exclusión desde el visualizador de registros, la base de normas se crea automáticamente y se agrega la norma.



Los servicios que ofrece el origen o destino, así como los servicios interactivos que los hackers pueden instalar y utilizar.

Acción que la IDP debe realizar si detecta tráfico interactivo. Establezca la operación en “detect”. Si está protegiendo un gran número de dispositivos de red del tráfico interactivo, puede crear una norma que ignore formas aceptadas de tráfico interactivo desde esos dispositivos y después puede crear otra norma que detecte todo el tráfico interactivo desde esos dispositivos.

Adición de la base de normas de puerta de atrásAntes de que pueda configurar una norma en la base de normas de puerta de atrás, debe agregar la base de normas de puerta de atrás a una directiva de seguridad mediante los siguientes pasos:

1. En el árbol de navegación principal, seleccione Security Policies. Abra una directiva de seguridad haciendo doble clic en el nombre de la directiva en la ventana Security Policy o en el nombre de la directiva y seleccionando el icono Edit.

2. Para configurar una norma de puerta de atrás, haga clic en la esquina derecha superior de la ventana Security Policy (consulte la Figura 77).

Figura 77: Adición de la base de normas de puerta de atrás

3. Seleccione Add Backdoor Rulebase.

Aparece una norma de puerta de atrás predeterminada como se muestra en la Figura 78. Puede modificar esta norma según sea necesario.

NOTA: No incluya Telnet, SSH, RSH, NetMeeting o VNC, ya que estos servicios se utilizan a menudo para controlar legítimamente un sistema remoto y su inclusión podría generar falsos positivos.

NOTA: La base de normas de puerta de atrás es una base de normas definitivas. Es decir, cuando IDP detecta una coincidencia con una norma en la base de normas de puerta de atrás, ésta no ejecuta normas sucesivas.

Configuración de las normas de puerta de atrás 211


212

Figura 78: Norma de puerta de atrás agregada

Definición de una coincidenciaEspecificará el tráfico que desea que IDP supervise en busca de indicaciones de puertas de atrás o caballos de Troya. Las columnas de coincidencia From Zone, Source, To Zone, Destination y Service son necesarias para todas las normas en la base de normas de puerta de atrás.

Las siguientes secciones describen en detalle las columnas de coincidencia de una norma de puerta de atrás.

Zonas de origen y de destinoPuede seleccionar múltiples zonas para el origen y destino. Sin embargo, estas zonas deben estar disponibles en los dispositivos de seguridad en los cuales instalará la directiva. Puede especificar “any” en las zonas de origen y de destino para supervisar el tráfico de red que se origina desde o está destinado hacia cualquier zona.

Objetos de dirección de origen y de destinoEn el sistema NetScreen-Security Manager, los objetos de dirección se utilizan para representar componentes en su red. Hosts, redes, servidores, etc. Normalmente, un servidor u otro dispositivo de su red es la IP de destino para los ataques entrantes y algunas veces puede ser la IP de origen para ataques interactivos. Puede especificar “any” para supervisar el tráfico de la red que se origina desde cualquier dirección IP. También puede negar los objetos de dirección enumerados en la columna Source o Destination para especificar todos los orígenes o destinos excepto los objetos de dirección excluidos.




Puede crear objetos de dirección antes de crear una norma de puerta de atrás (consulte el manual NetScreen-Security Manager Administrator's Guide) o mientras crea o edita una norma de puerta de atrás. Para seleccionar o configurar un objeto de dirección, haga clic con el botón secundario en la columna Source o Destination de una norma y seleccione Select Address. En el cuadro de diálogo Select Source Addresses puede seleccionar un objeto de dirección que ya está creado o hacer clic en el icono Add para crear un nuevo host, red u objeto de grupo.

ServiciosSeleccione los objetos de servicio interactivos. Asegúrese de incluir servicios ofrecidos por la IP de origen o destino así como los servicios interactivos que no están; los hackers pueden utilizar una puerta de atrás para instalar cualquier servicio interactivo. No incluya Telnet, SSH, RSH, NetMeeting o VNC, ya que estos servicios se utilizan a menudo para controlar legítimamente un sistema remoto y su inclusión podría generar falsos positivos.

Establecimiento del funcionamientoEstablezca el funcionamiento en detect o ignore. Si selecciona detect, elija una acción que se debe realizar si se detecta el tráfico por la puerta de atrás. Si está protegiendo un gran número de objetos de dirección del tráfico interactivo, puede crear una norma que ignore formas aceptadas de tráfico interactivo desde esos objetos y después puede crear una norma de reemplazo que detecte todo el tráfico interactivo desde esos objetos.

Establecimiento de accionesUtilice los siguientes pasos para configurar una acción para realizar en caso que IDP detecte tráfico interactivo.

Tabla 18: Acciones para una norma de puerta de atrás

Acción Descripción

Accept IDP acepta el tráfico interactivo.

Drop Connection IDP descarta la conexión interactiva sin enviar un paquete de RST al remitente, evitando que el tráfico llegue a su destino. Utilice esta acción para descartar conexiones del tráfico que no es propenso a simulación.

Close Client and Server

IDP cierra la conexión interactiva y envía un paquete RST al cliente y al servidor. Si IDP está funcionando en el modo de programa rastreador, IDP envía un paquete RST al cliente y al servidor, pero no cierra la conexión.

Close client IDP cierra la conexión interactiva al cliente, pero no al servidor.

Close Server IDP cierra la conexión interactiva al servidor, pero no al cliente.

Configuración de las normas de puerta de atrás 213


214

Establecimiento de la notificaciónLa primera vez que diseña una directiva de seguridad, es posible que se sienta tentado a registrar todos los ataques y dejar que la directiva se ejecute indefinidamente. ¡No haga esto! Algunos objetos de ataque son solamente informativos y otros pueden generar falsos positivos y registros redundantes. Si está sobrecargado con datos, podría pasar por alto algo importante. Recuerde que las directivas de seguridad que generan demasiados registros son peligrosas para la seguridad de su red, ya que podría descubrir un ataque demasiado tarde o pasar por alto una violación de la seguridad completamente si tiene que filtrar a través de cientos de registros. El exceso de registros también puede afectar a la capacidad de ejecución de IDP, el rendimiento y el espacio disponible en el disco. Una buena directiva de seguridad genera suficientes registros para documentar completamente sólo los eventos de seguridad importantes en la red.

Establecimiento de los registrosEn el cuadro de diálogo Configure Notification, seleccione Logging y haga clic en OK. Cada vez que haya una coincidencia de la norma, el sistema IDP crea un registro que aparece en el visualizador de registros.

El registro de un ataque crea un registro que puede visualizar en tiempo real en el visualizador de registros. Para ataques más críticos, también puede establecer un indicador de alerta para que aparezca en el registro, que le notifique inmediatamente por correo electrónico, que haga que IDP ejecute un guión como respuesta al ataque o que establezca un indicador de alarma para que aparezca en el registro. Su meta es perfeccionar las notificaciones de ataque en su directiva de seguridad de acuerdo con sus necesidades de seguridad individuales.

Para registrar un ataque de una norma, haga clic con el botón secundario en la columna Notification de la norma y seleccione Configure. Aparece el cuadro de diálogo Configure Notification.

Establecimiento de una alertaEn el cuadro de diálogo Configure Notification, seleccione Alert y haga clic en OK. Si selecciona Alert y hay una coincidencia para la norma, IDP coloca un indicador de alerta en la columna Alert del visualizador de registros para el registro coincidente.

Paquetes de registroPuede registrar paquetes individuales en el tráfico de red que coincidan con una norma capturando los datos del paquete de ataque. La visualización de los paquetes utilizados en un ataque en su red puede ayudarle a determinar la magnitud del intento de ataque y su propósito,si el ataque ha tenido éxito o no, y cualquier daño posible ocasionado a su red.

NOTA: Para mejorar el rendimiento de IDP, registre solamente los paquetes recibidos después del ataque.



Si múltiples normas con la captura de paquetes habilitada coinciden con el mismo ataque, IDP captura el número máximo de paquetes especificado. Por ejemplo, configura la norma 1 para capturar 10 paquetes antes y después del ataque y puede configurar la norma 2 para capturar 5 paquetes antes y después del ataque. Si ambas normas coinciden con el mismo ataque, IDP intenta capturar 10 paquetes antes y después del ataque.

Establecimiento de la gravedadPuede ignorar la gravedad de un ataque inherente en base a cada norma dentro de la base de normas de puerta de atrás. Puede establecer la gravedad en Default, Info, Warning, Minor, Major o Critical.

Para cambiar la gravedad de una norma, haga clic con el botón secundario en la columna Severity y seleccione un nivel de gravedad.

Establecimiento de objetivosPara cada norma de la base de normas de puerta de atrás, puede seleccionar el dispositivo de seguridad que utilizará esa norma para detectar e impedir los ataques. Cuando instala la directiva de seguridad a la cual pertenece la norma, ésta se activa solamente en los dispositivos que seleccionó en la columna Install On de la base de normas.

Introducción de comentariosPuede introducir anotaciones sobre la norma en la columna Comments. La información de la columna Comments no se envía al dispositivo objetivo. Para introducir un comentario, haga clic con el botón secundario en la columna Comments y seleccione Edit Comments. Aparece el cuadro de diálogo Edit Comments. Puede introducir un comentario de hasta 1024 caracteres

Configuración de los objetos de ataque de IDP

Los objetos de ataque contienen patrones de ataques conocidos que los hackers pueden utilizar para comprometer su red. Los objetos de ataque no funcionan por su cuenta, necesitan ser parte de una norma antes de empezar a detectar ataques conocidos e impedir la entrada de tráfico malicioso a su red. Para utilizar los objetos de ataque en sus normas de IDP, agregue la base de normas de IDP en su directiva de seguridad, después agregue una norma de IDP a la base de normas. Consulte la “Configuración de directivas de seguridad” en la página 185.

NOTA: Las capturas de paquetes están restringidas a 256 paquetes antes y después del ataque.

NOTA: Solamente los dispositivos de seguridad con capacidades para IDP admiten IDP.

Configuración de los objetos de ataque de IDP 215


216

Acerca de los tipos de objeto de ataque de IDPEn una directiva de seguridad, puede seleccionar el objeto de ataque que un dispositivo utiliza para detectar ataques contra su red. Si se detecta un ataque, el dispositivo genera una entrada de registro de ataque que aparece en el visualizador de registros. Para obtener más información, consulte “Configuración de las normas de IDP” en la página 191.

NetScreen-Security Manager admite tres tipos de objetos de ataque de IDP:

Objetos de ataque de firma

Objetos de ataque de anomalías de protocolo

Objetos de ataque compuestos

Las siguientes secciones describen en detalle cada tipo de objeto de ataque.

Objetos de ataque de firmaUna firma de ataque es un patrón que siempre existe dentro de un ataque; si existe el ataque, también existe la firma de ataque. IDP utiliza firmas completas para detectar ataques. Las firmas completas son más específicas que las firmas normales. Con firmas completas, IDP puede buscar el protocolo o servicio específicos utilizados para perpetrar el ataque, la dirección y flujo del ataque y el contexto en el cual ocurrió el ataque. ScreenOS combina el patrón de ataque con el servicio, contexto y otra información del objeto de ataque. Las firmas completas producen pocos falsos positivos debido a que el contexto del ataque está definido, eliminando enormes secciones de tráfico de red en las cuales no ocurrirá el ataque.

Objetos de ataque de anomalías de protocoloLos objetos de ataque de anomalía de protocolo detectan mensajes no normales o ambiguos dentro de una conexión de acuerdo con el conjunto de normas del protocolo determinado que se está utilizando. La detección de anomalía de protocolo funciona al descubrir desviaciones de las normas de protocolo, definidos más a menudo por medio de RFC y extensiones RFC comunes. El tráfico más legítimo se adhiere a los protocolos establecidos. El tráfico que no produce una anomalía, creada posiblemente por hackers para propósitos específicos, como evadir un IPS.

Objetos de ataque compuestosUn objeto de ataque compuesto combina múltiples firmas y anomalías de protocolo en un objeto único. El tráfico debe coincidir con todas las firmas combinadas y anomalías de protocolo para que coincida con el objeto de ataque compuesto; puede especificar el orden en el que las firmas o anomalías deben coincidir. Utilice objetos de ataque compuesto para filtrar sus normas de directiva de seguridad, reducir los falsos positivos y aumentar la exactitud de la detección.

Un objeto de ataque compuesto le permite ser muy específico sobre los eventos que deben ocurrir antes de que IDP identifique el tráfico como un ataque. Por ejemplo, es posible que desee realizar una acción solamente si la sesión de FTP incluye un intento de inicio de sección fallido de usuarios específicos.



Visualización de grupos y objetos de ataque de IDP predefinidosJuniper Networks proporciona objetos de ataque predefinidos y grupos de objetos de ataque que puede utilizar en las directivas de seguridad para comparar el tráfico con los ataques conocidos. Juniper Networks actualiza regularmente los grupos y objetos de ataque predefinidos. A pesar de que no puede crear, editar o eliminar objetos de ataque predefinidos, sí puede actualizar la lista de objetos de ataque que puede utilizar en las directivas de seguridad. Los grupos y objetos de ataque revisados están disponibles como parte de una actualización de la base de datos de ataques, la cual se descarga al servidor GUI de NetScreen-Security Manager. Consulte “Administración de IDP” en la página 238 para obtener información sobre actualizaciones de bases de datos de ataques.

Para visualizar grupos y objetos de ataque predefinidos, realice los siguientes pasos:

1. En el administrador de objetos, haga clic en Attack Objects > IDP Objects. Aparece el cuadro de diálogo IDP Objects.

2. Haga clic en la ficha Predefined Attacks o Predefined Attack Groups para visualizar los grupos u objetos de ataque predefinidos.

Visualización de ataques predefinidosLa ficha Predefined Attacks muestra todos los ataques en un formato de tabla e incluye la siguiente información:

Nombre el objeto de ataque

Gravedad del ataque: critical, major, minor, warning, info

Categoría

Palabras clave del ataque

Número CVE, que identifica el número de ataque en la base de datos Common Vulnerabilities and Exposures

Número Bugtraq, que identifica el ataque equivalente en la base de datos Security Focus Bugtraq

Inicialmente, los objetos de ataque se enumeran alfabéticamente por nombre de categoría, pero puede visualizar los ataques en un orden distinto haciendo clic en un encabezado de columna.

Para buscar todas las normas que utilizan un objeto de ataque predefinido, haga clic con el botón secundario en el objeto de ataque y seleccione View Usages.

Para visualizar una descripción detallada de un objeto de ataque, haga doble clic en el ataque.



218

Figura 79: Visualizador de ataques

Visualización de grupos predefinidosLa ficha Predefined Attack Group muestra los siguientes grupos de ataque predefinidos:

Recommended, una lista de todos los objetos de ataque que Juniper Networks considera como amenazas graves, organizadas por categorías.

Attack Type, objetos de grupos de ataques por tipo (anomalía o firma). Dentro de cada tipo, los objetos de ataque están agrupados por gravedad.

Category, grupos de objetos de ataque por categorías predefinidas. Dentro de cada categoría, los objetos de ataque están agrupados por gravedad.

Operating System, grupos de objetos de ataque ordenados según el sistema operativo al que afectan: BSD, Linux, Solaris o Windows. Dentro de cada sistema operativo, los objetos de ataque están agrupados de acuerdo a los servicios y gravedad.

Severity, grupos de objetos de ataque según la gravedad asignada al ataque. IDP tiene cinco niveles de gravedad: Info, Warning, Minor, Major, Critical. Dentro de cada nivel de gravedad, los objetos de ataque están agrupados por categoría.

Para buscar todas las normas que utilizan un grupo de objetos de ataque predefinido, haga clic con el botón secundario en el grupo de objetos de ataque y seleccione View Usages.

Para visualizar una descripción detallada de un objeto de ataque, haga doble clic en el ataque.



Para obtener más información sobre los grupos predefinidos, consulte el manual NetScreen-Security Manager Manager Administrator's Guide.

Creación de objetos de ataque IDP personalizadosPuede crear objetos de ataque personalizados para detectar nuevos ataques o satisfacer otras necesidades específicas de su red.

Para crear un objeto de ataque personalizado, realice los siguientes pasos:


2. Haga clic en la ficha Custom Attacks.

3. Haga clic en el icono Add. Aparece el cuadro de diálogo Custom Attack con la ficha General seleccionada.

Figura 80: Cuadro de diálogo Custom Attack

a. Escriba un nombre para el ataque. El nombre se utiliza para visualizar el objeto de ataque en la UI. Es posible que desee incluir en el nombre del ataque el protocolo se utiliza en el ataque.

b. Escriba una descripción para el ataque. La descripción proporciona detalles sobre el ataque. La introducción de una descripción es opcional al crear un nuevo objeto de ataque, pero puede ayudarle a recordar información importante. Visualice las descripciones de ataques predefinidos como ejemplos. Para visualizar los detalles de los ataques predefinidos, consulte “Visualización de ataques predefinidos” en la página 217.

c. Seleccione un nivel de gravedad para este ataque: Info, Warning, Minor, Major, or Critical. Los ataques críticos son los más peligrosos, normalmente estos ataques intentan dejar colgado su servidor u obtener el control de su red. Los ataques de información son los menos peligrosos y normalmente los administradores de red los utilizan para descubrir agujeros en su propio sistema de seguridad.

d. Escriba una categoría para este ataque. Puede utilizar una categoría predefinida o definir una nueva categoría.



220

e. Introduzca una o más palabras clave para este ataque que le puedan ayudar a encontrarlo posteriormente. Una palabra clave es un identificador único utilizado para visualizar el objeto de ataque en los registros. Las palabras clave indican las palabras importantes que se relacionan con el ataque y objeto de ataque.

f. Revise la casilla de verificación si desea que este objeto de ataque sea parte de su conjunto de riesgos más altos de objetos de ataque. Posteriormente, cuando agregue este objeto de ataque a los grupos dinámicos, puede especificar si sólo se incluirán los objetos de ataque recomendados. Para obtener más información sobre los objetos de ataque recomendados, consulte el manual NetScreen-Security Manager Manager Administrator's Guide.

4. Haga clic en la ficha Platforms en el cuadro de diálogo Custom Attack para especificar la plataforma de seguridad en la que debe ocurrir la detección del ataque.

a. Haga clic en el icono Add. Aparece el cuadro de diálogo Custom Attack.

b. Seleccione la plataforma en la que debe ocurrir la detección del ataque.

c. Seleccione el tipo de ataque, firma, protocolo, anomalía o ataque compuesto y haga clic en Next.

Si está configurando un nuevo objeto de ataque, el editor del objeto de ataque lo guía a través de las pantallas para configurar el tipo de ataque específico:

Para los objetos de ataque de firma, consulte la siguiente sección, “Creación de un objeto de ataque de firma”.

Para los objetos de ataque de anomalía de protocolo, consulte “Objetos de ataque de anomalías de protocolo” en la página 216.

Para los objetos de ataque compuesto, consulte “Objetos de ataque compuestos” en la página 216.

Creación de un objeto de ataque de firmaPara configurar un ataque de firma en el cuadro de diálogo Custom Attack, realice los siguientes pasos:

1. Configure los parámetros generales del ataque mediante los siguientes pasos:

False-positives indica la frecuencia (Unknown, Rarely, Occasionally, Frequently) con la que el objeto de ataque produce un falso positivo al utilizarlo en una directiva de seguridad. De forma predeterminada, todos los objetos de ataque compuesto están establecidos en Unknown (frecuencia desconocida), a medida que perfeccione su sistema IDP para el tráfico de su red, puede cambiar este ajuste para ayudarle a rastrear falsos positivos.



Service Binding le permite seleccionar un protocolo que el ataque utiliza para entrar a su red. Dependiendo del protocolo que seleccione, es posible que aparezcan campos adicionales. Puede seleccionar los siguientes tipos de protocolo:

Any permite que IDP compare la firma en todos los servicios (los ataques pueden utilizar múltiples servicios para atacar su red).

IP (especificar el número de protocolo) le permite que IDP compare la forma con un tipo de protocolo de IP especificado.

TCP (especificar los rangos de puerto) permite que IDP compare la firma de los puertos TCP especificados.

UDP (especificar los rangos de puerto) permite que IDP compare la firma de los puertos UDP especificados.

ICMP (especificar ID) permite que IDP compare la firma del ICMP especificado.

RPC (especificar el número de programa) permite que IDP compare la firma de un número de programa de llamadas de procedimiento remoto especificado.

Service (especificar el servicio) permite que IDP compare la firma del servicio especificado.

Time Binding permite que IDP detecte una secuencia de los mismos ataques durante un período. Si selecciona Time Binding, puede especificar los siguientes atributos enlazados al objeto de ataque durante un minuto:

Scope especifica si el recuento de ataques es de la misma dirección IP de origen, la misma dirección IP de destino o un interlocutor. Si selecciona Source, IDP detecta ataques de una dirección IP de origen dada durante el número de veces especificado, independientemente de la dirección IP de destino. Si selecciona Destination, IDP detecta ataques de una dirección IP de destino dada durante el número de veces especificado, independientemente de la dirección IP de origen. Si selecciona Peer, IDP detecta ataques entre las direcciones Ip de origen y destino de las sesiones durante el número de veces especificado.

Count especifica el número de veces que IDP detecta el ataque dentro del alcance especificado antes de desencadenar un evento.

2. Haga clic en Next.



222

3. Configure los parámetros de detección para el ataque de firma:

El patrón de ataque es la firma del ataque que desea detectar. La firma de ataque es un patrón que siempre existe dentro de un ataque, si existe el ataque, también existe la firma. Al crear un nuevo objeto de ataque de firma, debe analizar el ataque para detectar un patrón (como un segmento de código, URL o un valor en el encabezado de paquete) y después debe utilizar ese patrón para crear una firma. También puede incluir un patrón para negarlo.

La Tabla 19 muestra las expresiones regulares que puede utilizar en el patrón de ataque:

Tabla 19: Expresiones del patrón de ataque

Offset es el lugar de inicio desde el contexto de servicio especificado en donde IDP debe buscar el ataque. Si no hay offset, puede especificar None; de lo contrario, puede especificar un valor decimal.

Context define la ubicación donde IDP debe buscar el ataque en un protocolo de capa de aplicación específico. Al crear un objeto de ataque de firma, debe seleccionar un contexto de servicio, si es posible. Debido a que el contexto de servicio es muy específico, sus posibilidades de detectar un falso positivo se reducen grandemente. Sin embargo, la selección de un contexto de servicio ignora cualquier protocolo que haya especificado previamente en el parámetro general Service Binding.

Expresión regular Descripción

\0<número-octal> Para una coincidencia binaria directa

\X<número-hexadecimal>\X Para una coincidencia binaria directa

\[<juego-caracteres>\] Coincidencias que no distinguen mayúsculas de minúsculas

. Para que coincida con cualquier símbolo

* Para que coincida con 0 o más símbolos

+ Para que coincida con 1 o más símbolos

? Para que coincida con 0 ó 1 símbolos

( ) Agrupación de expresiones

| Alternos exclusivos, utilizado normalmente con ( )

[<comienzo>-<final>] Rango de caracteres

[^<comienzo>-<final>] Negación de rango



La Tabla 20 enumera los contextos de servicio que puede utilizar para los ataques.

Tabla 20: Contexto de servicio para ataques de firma

Servicio Descripción RFC

AIM AOL Instant Messenger

DHCP Protocolo de configuración dinámica de host 2131, 2132

DNS Sistema de nombres de dominio 1034, 1035

Finger Protocolo de información Finger 1128

FTP Protocolo de transferencia de archivos 959

Gnutella Gnutella

Gopher Gopher 1436

HTTP Protocolo de transferencia de hipertextos 2616

IMAP Protocolo de acceso de mensajes de Internet 2060

IRC Chat de retransmisión de Internet 2810, 2811, 2812, 2813

LDAP Protocolo ligero de acceso a directorios 2251, 2252, 2253, 3377

LPR Protocolo de impresora en línea 1179

MSN Microsoft Instant Messenger

NBNAME/

NBDS

Servicio de nombres NetBios 1001, 1002

NFS Sistema de archivos en red

NNTP Protocolo de transferencia de noticias en red 977

NTP Protocolo de hora de la red 1305

POP3 Protocolo de oficina de correo, versión 3 1081

RADIUS Servicio de autenticación remota de usuarios de acceso telefónico

2865, 2866, 2867, 2868, 3575

REXEC

RLOGIN Inicio de sesión remoto (rlogin) 1258, 1282

RSH Shell remoto (rsh)

RUSERS

SMB Bloque de mensajes del servidor

SMTP Protocolo de transferencia de correo sencillo (SMTP)

821

SNMP Protocolo simple de administración de redes 1067

SNMPTRAP Captura SNMP 1067

SSH Shell seguro Propiedad

SSL Nivel de sockets seguro

Telnet Protocolo TCP Telnet 854

TFTP Protocolo trivial de transferencia de archivos 783

VNC Informática virtual de red

YMSG Yahoo! Messenger



224

Direction define qué sentido sigue la conexión del ataque:

Client to Server detecta el ataque solamente en el tráfico del cliente al servidor.

Server to Client detecta el ataque solamente en el tráfico del servidor al cliente.

Any detecta el ataque en cualquier dirección.

Flow define el flujo de la conexión del ataque: Control, auxiliar o ambos.


5. Configure la información de coincidencia de encabezado para el ataque de firma. La configuración de coincidencia de encabezado le permite especificar que IDP busque solamente una coincidencia de patrón en un paquete con cierta información de encabezado para los siguientes protocolos:

Protocolo de Internet (IP)

Type-of-service. Especifique un operando (none, =, !, >, <) y un valor decimal.

Total length. Especifique un operando (none, =, !, >, <) y un valor decimal.

ID Especifique un operando (none, =, !, >, <) y un valor decimal.

Time-to-live. Especifique un operando (none, =, !, >, <) y un valor decimal.

Protocol. Especifique un operando (none, =, !, >, <) y un valor decimal.

Source. Especifique la dirección IP del dispositivo de ataque.

Destination. Especifique la dirección IP del objetivo de ataque.

Reserved Bit. Especifica que IDP busque una coincidencia de patrón independientemente de que esté o no esté establecido un indicador de IP (none), solamente si el indicador está establecido (set) o solamente si el indicador no está establecido (unset).

More Fragments. Especifica que IDP busque una coincidencia de patrón independientemente de que esté o no esté establecido un indicador de IP (none), solamente si el indicador está establecido (set) o solamente si el indicador no está establecido (unset).

Don’t Fragment. Especifica que IDP busque una coincidencia de patrón independientemente de que esté o no esté establecido un indicador de IP (none), solamente si el indicador está establecido (set) o solamente si el indicador no está establecido (unset).



Protocolo de control de la transmisión (TCP)

Source Port. El número de puerto del dispositivo de ataque.

Destination Port. El número de puerto del objetivo de ataque.

Sequence Number. El número de secuencia del paquete. Este número identifica la ubicación de los datos en relación con la secuencia de datos completa.

ACK Number. El número ACK del paquete. Este número identifica el siguiente número de secuencia, el indicador ACK debe estar establecido para activar este campo.

Header Length. El número de bytes en el encabezado de TCP.

Window Size. El número de bytes en el tamaño de la ventana de TCP.

Urgent Pointer. Indica que los datos en el paquete son urgentes; el indicador URG debe estar establecido para activar este campo.

Data Length. El número de bytes en la carga de datos. Para los paquetes SYN, ACK y FIN, este campo debe estar vacío.

También puede especificar las siguientes opciones de indicador TCP como none, set o unset:

URG. Cuando está establecido, el indicador urgente indica que los datos del paquete son urgentes.

ACK. Cuando está establecido, el indicador de acuse de recibo, acusa recibo de un paquete.

PSH. Cuando está establecido el indicador de envío indica que el receptor debe enviar todos los datos en la secuencia actual a la aplicación de destino (identificada por el número de puerto) sin esperar los paquetes restantes de la secuencia.

RST. Cuando está establecido, el indicador de restablecimiento, restablece la conexión TCP, descartando todos los paquetes de una secuencia existente.

FIN. Cuando está establecido, el indicador final indica que la transferencia del paquete está completa y la conexión se puede cerrar.

Protocolo de datagramas de usuario (UDP)

Source Port. El número de puerto del dispositivo de ataque. Especifique un operando (none, =, !, >, <) y un valor decimal.

Destination Port. El número de puerto del objetivo de ataque. Especifique un operando (none, =, !, >, <) y un valor decimal.



226

Data Length. El número de bytes en la carga de datos. Especifique un operando (none, =, !, >, <) y un valor decimal.

Protocolo de mensajes de control de Internet

ICMP Type. El código principal que identifica la función de la petición/respuesta.

ICMP Code. El código secundario que identifica la función de la petición/respuesta dentro de un tipo dado.

Sequence Number. El número de secuencia del paquete. Este número identifica la ubicación de la petición/respuesta en relación con la secuencia completa.

ICMP ID. El número de identificación es un valor único utilizado por el sistema de destino para asociar peticiones y respuestas.

Data Length. El número de bytes en la carga de datos.

6. Haga clic en Finish.

Creación de un Ataque de anomalía de protocoloRealice los siguientes pasos para configurar un ataque de anomalía de protocolo en el cuadro de diálogo Custom Attack:

1. Configure los parámetros generales para el ataque:

False-Positives indica la frecuencia (Unknown, Rarely, Occasionally, Frequently) con que el objeto de ataque produce un falso positivo al utilizarlo en una directiva de seguridad. A medida que perfecciona su sistema IDP para su tráfico de red, puede cambiar este ajuste para ayudarle a dar seguimiento a falsos positivos.

Anomaly le permite seleccionar una anomalía de protocolo de una lista de anomalías de protocolo conocidas. NetScreen-Security Manager detecta anomalías de los siguientes protocolos:

AIM DHCP IDENT RUSERS TFTP

FINGER CHARGEN IMAP Gnutella RLOGIN

FTP DISCARD IP Packet Gopher RPC

HTTP DNS POP3 IRC RSH

ICMP ECHO REXEC MSN RTSP

MSN LPR NFS VNC NNTP

SNMP SMTP SMB SNMP TRAP YMSG

TCP segment SYSLOG SSH TELNET



Time Binding permite que IDP detecte una secuencia de los mismos ataques durante un período especificado. Si selecciona Time Binding, puede especificar los siguientes atributos que están enlazados al objeto de ataque durante un minuto:

Scope especifica si el recuento de ataques es de la misma dirección IP de origen, la misma dirección IP de destino o un interlocutor. Si selecciona Source, IDP detecta ataques de una dirección IP de origen dada durante el número de veces especificado, independientemente de la dirección IP de destino. Si selecciona Destination, IDP detecta ataques de una dirección IP de destino dada durante el número de veces especificado, independientemente de la dirección IP de origen. Si selecciona Peer, IDP detecta ataques entre las direcciones IP de origen y destino de las sesiones durante el número de veces especificado.


2. Haga clic en Finish.

Creación de un ataque compuestoObserve lo siguiente al crear un objeto de ataque compuesto:

Todos los miembros del objeto de ataque compuesto utilizan el mismo ajuste de servicio o enlace de servicio, como FTP, Telnet, YMSG, TCP/80, etc.

No puede agregar objetos de ataque de firma predefinidos o personalizados a un objeto de ataque compuesto. En lugar de eso, especificará la firma directamente dentro del objeto de ataque compuesto, incluyendo detalles como servicio (o enlace de servicio), contexto de servicio, patrón de ataque y dirección. Puede agregar objetos de ataque de anomalía de protocolo a un objeto de ataque compuesto.

Puede agregar entre 2 y 32 objetos de ataque de anomalía de protocolo o firmas como miembros del objeto de ataque compuesto. Sin embargo, todos los miembros deben utilizar el mismo ajuste de servicio o enlace de servicio.

Realice los siguientes pasos para configurar un ataque compuesto en el cuadro de diálogo Custom Attack:

1. Configure los parámetros generales para el ataque:

False-Positives indica la frecuencia (Unknown, Rarely, Occasionally, Frequently) con que el objeto de ataque produce un falso positivo al utilizarlo en una directiva de seguridad. De forma predeterminada, todos los objetos de ataque están establecidos en Unknown. A medida que perfeccione IDP para su tráfico de red, puede cambiar este ajuste para ayudarle a dar seguimiento a falsos positivos.



228

Service Binding le permite seleccionar un protocolo que el ataque utiliza para entrar a su red. Dependiendo del protocolo que seleccione, es posible que aparezcan campos adicionales. Puede seleccionar los siguientes tipos de protocolo:

Any permite que IDP compare la firma en todos los servicios (los ataques pueden utilizar múltiples servicios para atacar su red).

IP (especificar el número de protocolo) permite que IDP compare la firma con un tipo de protocolo de IP especificado.

TCP (especificar los rangos de puerto) permite que IDP compare la firma de los puertos TCP especificados.

UDP (especificar los rangos de puerto) permite que IDP compare la firma de los puertos UDP especificados.

ICMP (especificar ID) permite que IDP compare la firma del ICMP especificado.

RPC (especificar el número de programa) permite que IDP compare la firma de un número de programa de llamadas de procedimiento remoto especificado.

Service (especificar el servicio) permite que IDP compare la firma del servicio especificado.

Time Binding permite que IDP detecte una secuencia de los mismos ataques durante un período especificado. Si selecciona Time Binding, puede especificar los siguientes atributos que están enlazados al objeto de ataque durante un minuto:

Scope especifica si el recuento del ataque es de la misma dirección IP de origen, la misma dirección IP de destino o un interlocutor. Si selecciona Source, IDP detecta ataques de una dirección IP de origen dada durante el número de veces especificado, independientemente de la dirección IP de destino. Si selecciona Destination, IDP detecta ataques de una dirección IP de destino dada durante el número de veces especificado, independientemente de la dirección IP de origen. Si selecciona Peer, IDP detecta ataques entre las direcciones IP de origen y destino de las sesiones durante el número de veces especificado.





3. Realice los siguientes pasos para configurar los miembros de ataque compuesto:

Scope especifica si la coincidencia debe ocurrir en una única sesión o se puede realizar a través de múltiples transacciones dentro de una sesión:

Seleccione Session para permitir múltiples coincidencias para el objeto dentro de la misma sesión.

Seleccione Transaction para comparar el objeto a través de múltiples transacciones que ocurren dentro de la misma sesión.

Seleccione Reset si el ataque compuesto debe coincidir más de una vez dentro de una única sesión o transacción. Si selecciona Reset, se pueden realizar múltiples coincidencias dentro de una única sesión o transacción.

Seleccione Ordered Match para crear un objeto de ataque compuesto que debe coincidir con cada firma de miembro o anomalía de protocolo en el orden que especifique. Si no especifica una coincidencia ordenada, el objeto de ataque compuesto aún debe coincidir con todos los miembros, pero los ataques o anomalías de protocolo pueden aparecer en orden aleatorio.

Ahora puede agregar objetos de ataque de anomalía de protocolo o firma al ataque compuesto, según se describe en las siguientes secciones.

Adición de una firma al objeto de ataque compuesto

1. Para agregar un patrón de ataque al objeto de ataque compuesto, haga clic en el icono Add y seleccione Signature. Aparece el cuadro de diálogo New Member.

2. Haga doble clic en el miembro de firma creado del objeto de ataque compuesto. Configure los ajustes del patrón de ataque:

DFA Pattern. Especifique el patrón con el que IDP debe buscar una coincidencia. Debe construir el patrón de ataque de la misma manera que lo haría al crear un nuevo objeto de ataque de firma.

Para excluir el patrón específico de la coincidencia, seleccione la casilla de verificación Negate.

Context. Especifique el contexto en el que IDP debe buscar el patrón. El contexto muestra solamente contextos que son apropiados al servicio especificado. Si seleccionó un enlace de servicio de any, está restringido al paquete de contextos de servicio y primer paquete.

Direction. Especifique si IDP debe buscar una coincidencia con el patrón en el tráfico que fluye en cualquier sentido, del cliente al servidor o del servidor al cliente.

Examine el tráfico antes de determinar la dirección. Juniper Networks recomienda el sentido del cliente al servidor para obtener un mejor rendimiento. El rendimiento del dispositivo se afectado si selecciona servidor a cliente y el riesgo de objetos de ataque es menor con la opción cliente a servidor.



230

3. Haga clic en OK.

Adición de una anomalía de protocolo al objeto de ataque compuesto

1. Para agregar una anomalía de protocolo al objeto de ataque compuesto, haga clic en el icono Add y seleccione Anomaly. Aparece el cuadro de diálogo New Member.

2. Seleccione una anomalía.

3. Haga clic en OK.

Eliminación de un miembro del objeto de ataque compuesto

Para eliminar una firma de miembro o una anomalía, seleccione el miembro en la lista, a continuación haga clic en el icono Delete. Una ventana de confirmación le pide verificar si desea eliminar el elemento. Haga clic en OK.

Edición de un objeto de ataque personalizadoPara modificar un objeto de ataque personalizado, haga doble clic en el objeto en la ficha Custom Attacks en el cuadro de diálogo IDP Objects. Aparece el cuadro de diálogo Custom Attacks con la información configurada previamente en las fichas General y Platforms. Puede introducir información opcional en las fichas References y Extended. Introduzca cualquier cambio que desee hacer y haga clic en Apply. Para cerrar el cuadro de diálogo, haga clic en OK.

Eliminación de un objeto de ataque personalizadoPara eliminar un objeto de ataque personalizado, haga clic con el botón secundario en la ficha Custom Attacks en el cuadro de diálogo IDP Objects y seleccione Delete. Una ventana de confirmación le pide verificar si desea eliminar el elemento. Haga clic en OK.

Creación de objetos de ataque IDP personalizadosEl sistema IDP contiene cientos de objetos de ataque predefinidos y puede crear objetos de ataque personalizados adicionales. Al crear normas de directiva de seguridad, puede agregar objetos de ataque individualmente o de acuerdo con el grupo de ataques personalizado o predefinido. Para ayudar a mantener organizadas sus directivas de seguridad, puede organizar los objetos de ataque en grupos.

Puede crear grupos estáticos, que contienen solamente los grupos u objetos de ataque que especifique o grupos dinámicos, que contienen objetos de ataque basados en el criterio que especifique.

Configuración de grupos estáticosUn grupo estático contiene un conjunto específico, finito de grupos u objetos de ataque. Existen dos tipos de grupos estáticos: grupos estáticos predefinidos y grupos estáticos personalizados.

Un grupo estático predefinido puede incluir los siguientes miembros:

Objetos de ataque predefinidos

Grupos estáticos predefinidos



Grupos dinámicos predefinidos

Un grupo estático personalizado puede incluir los mismos miembros que un grupo estático predefinido, más los siguientes miembros:

Objetos de ataque personalizados

Grupos dinámicos personalizados

Otros grupos estáticos personalizados

Los grupos estáticos se utilizan para lo siguiente:

Definir un conjunto específico de ataques a los que sabe que su red es vulnerable

Agrupar los objetos de ataque personalizados

Definir un conjunto específico de objetos de ataque de información que utiliza para mantenerse enterado de lo que sucede en su red

Los grupos estáticos requieren más mantenimiento que los grupos dinámicos debido a que debe agregar o eliminar manualmente los objetos de ataque en el grupo estático para poder cambiar los miembros. Sin embargo, puede incluir un grupo dinámico dentro de un grupo estático para actualizar automáticamente algunos objetos de ataque. Por ejemplo, el sistema operativo del grupo de objetos de ataque predefinido es un grupo estático que contiene cuatro grupos estáticos predefinidos: BSD, Linux, Solaris y Windows. El grupo BSD contiene el grupo dinámico predefinido BSD-Services-Critical en el que puede agregar objetos de ataque durante una actualización de la base de datos de ataques.

Para crear un grupo estático personalizado:


2. Haga clic en la ficha Custom Attack Groups.

3. Haga clic en el icono Add y seleccione Add Static Group. Aparece el cuadro de diálogo New Static Group.

4. Introduzca un nombre y una descripción del grupo estático. Seleccione un color para el icono del grupo.

5. Para agregar un ataque o grupo al grupo estático, seleccione el ataque o grupo de la lista Attacks/Group y haga clic en Add.

6. Haga clic en OK.



232

Configuración de grupos dinámicosUn grupo dinámico contiene un conjunto dinámico de objetos de ataque que se agregan o eliminan automáticamente basándose en un criterio especificado para el grupo. Por ejemplo, una actualización de la base de datos de ataques puede agregar o eliminar los objetos de ataque de un grupo dinámico basándose en el criterio del grupo. Esto elimina la necesidad de revisar cada nueva firma para determinar si debe utilizarla en su directiva de seguridad existente.

Un grupo dinámico o personalizado solamente puede contener objetos de ataque, no grupos de ataques. Los miembros de un grupo dinámico pueden ser objetos de ataque predefinidos o personalizados.

Realice los siguientes pasos para crear un grupo dinámico personalizado:


2. Haga clic en la ficha Custom Attack Groups.

3. Haga clic en el icono Add y seleccione Add Dynamic Group. Aparece el cuadro de diálogo New Dynamic Group.

4. Introduzca un nombre y una descripción del grupo estático. Seleccione un color para el icono del grupo.

5. En la ficha Filters, haga clic en el icono Add y seleccione una de las siguientes opciones:

Add Products Filter agrega objetos de ataque basándose en la aplicación que es vulnerable al ataque

Add Severity Filter agrega objetos de ataque basándose en la gravedad del ataque.

Add Category Filter agrega objetos de ataque basándose en la categoría

Add Last Modified Filter agrega objetos de ataque basándose en su última fecha de modificación

Add Recommended Filter incluye sólo los ataques designados como las amenazas más graves al grupo dinámico. En el futuro, Juniper Networks sólo designará como Recomended los ataques que considere amenazas graves. Estos ajustes se actualizarán con las nuevas actualizaciones de objetos de ataque. Además, puede designar los objetos de ataque personalizados como Recommended o no. Para obtener más información sobre las acciones recomendadas, consulte el manual NetScreen-Security Manager Manager Administrator's Guide.

NOTA: Juniper Networks ha asignado un nivel de gravedad a todos los objetos de ataque predefinidos. Sin embargo, puede editar este ajuste para que coincida con las necesidades de su red.



Puede crear los filtros de uno en uno; a medida que agregue cada criterio, IDP lo compara con los atributos de cada objeto de ataque e inmediatamente filtra cualquier objeto de ataque que no coincida. Si crea un filtro con atributos que no coinciden con ningún objeto de ataque, aparece un mensaje advirtiéndole de que su grupo dinámico no tiene miembros.

De la lista resultante de objetos de ataque que coinciden, podrá excluir cualquier objeto de ataque que produzca falsos positivos en su red o que detecte un ataque para el cual su red no es vulnerable.

Ejemplo: Creación de un grupo dinámicoRealice los siguientes pasos para crear un grupo dinámico:

1. En la ficha Custom Attack Groups, haga clic en el icono Add y seleccione Add Dynamic Group. Aparece el cuadro de diálogo New Dynamic Group.

2. Introduzca un nombre y una descripción del grupo. Seleccione un color para el icono del grupo.

Figura 81: Nuevo grupo dinámico

3. En la ficha Filters, haga clic en el icono Add y después agregue los filtros que determinan qué objetos de ataque deben estar en el grupo:

a. Agregue un filtro de productos para agregar objetos de ataque que detecten ataques contra todos los sistemas operativos de Microsoft Windows.

b. Agregue un filtro de gravedad para agregar objetos de ataque que tienen un nivel de gravedad Critical o Major.

IDP aplica automáticamente todos los filtros a toda la base de datos de objetos de ataque, identifica los objetos de ataque que cumplen con un criterio definido, y agrega los objetos que coinciden como miembros del grupo.

NOTA: Un grupo dinámico no puede contener otro grupo (predefinido, estático o dinámico). Sin embargo, puede incluir un grupo dinámico como miembro de un grupo estático.



234

4. Visualice los miembros del grupo haciendo clic en la ficha Members como se muestra en la Figura 82:

Figura 82: Miembros del nuevo grupo dinámico

5. Haga clic en OK para guardar el grupo dinámico.

Actualización de grupos dinámicosCuando esté satisfecho con el criterio de grupo y sus miembros, utilice el grupo en una directiva de seguridad. La próxima vez que actualice sus objetos de ataque, las siguientes tareas se realizan automáticamente:

Para todos los nuevos objetos de ataque, la actualización compara los atributos predefinidos de cada objeto de ataque para cada criterio de grupo dinámico y agrega los objetos de ataque que coinciden.

Para todos los objetos de ataque actualizados, la actualización elimina objetos de ataque que ya no cumplen con el criterio del grupo. La actualización también revisa los objetos de ataque para determinar si ahora cumplen con cualquier otro criterio del grupo dinámico y los agrega a esos grupos según sea necesario.

Para todos los objetos de ataque eliminados, la actualización elimina los objetos de ataque de sus grupos dinámicos.

También puede editar un grupo dinámico manualmente, agregando nuevos filtros o ajustando los filtros existentes para obtener el tipo de objetos de ataque que desea. También puede editar un grupo dinámico de una directiva de seguridad (consulte “Configuración de directivas de seguridad” en la página 185).



Edición de un grupo de ataques personalizadoPara modificar un grupo de ataques personalizado, haga doble clic en la ficha Custom Attack Groups en el cuadro de diálogo IDP Objects. Aparece el cuadro de diálogo Static Group o Dynamic Group mostrando la información configurada previamente. Introduzca cualquier cambio que desea realizar y haga clic en Apply; para cerrar el cuadro de diálogo, haga clic en OK.

Eliminación de un grupo de ataques personalizadoPara eliminar un grupo de ataques personalizado, haga clic con el botón secundario en la ficha Custom Attack Groups en el cuadro de diálogo IDP Objects y seleccione Delete. Una ventana de confirmación le pide verificar si desea eliminar el elemento. Haga clic en OK.

Configuración del dispositivo como un dispositivo IDP independiente

También puede implementar el dispositivo con capacidad para IDP como un sistema de seguridad IDP independiente para proteger los segmentos esenciales de su red privada. Por ejemplo, es posible que ya cuente con un dispositivo de seguridad que analiza activamente el tráfico entre Internet y su red privada (algunos dispositivos pueden utilizar opcionalmente Deep Inspection para inspeccionar este tráfico). Pero aún es necesario que proteja los sistemas internos, como los servidores de correo, de los ataques que se pueden originar desde máquinas de usuarios en una red que normalmente serían fiables. En este caso, necesita un sistema de seguridad que proporcione funciones de IDP en lugar de funciones de cortafuegos.

Esta sección describe la manera de configurar el dispositivo de seguridad para que proporcione funciones de IDP independiente.

Habilitación de IDPPara habilitar IDP, necesita configurar una norma de cortafuegos en una directiva de seguridad que dirige el tráfico entre las zonas aplicables para revisarlas en comparación con las bases de normas de IDP. Puede hacer esta norma de cortafuegos muy simple, es decir, que pueda comparar todo el tráfico de todos los orígenes a todos los destinos para todos los servicios.

1. Cree una norma de cortafuegos que permita el tráfico de cualquier origen a cualquier destino para cualquier servicio.

2. Haga clic con el botón secundario en la columna Rule Options para la norma de cortafuegos, después seleccione DI Profile/Enable IDP.

3. En el cuadro de diálogo DI Profile/Enable IDP, haga clic en el botón para habilitar IDP y seleccione OK.

NOTA: Juniper Networks ofrece dispositivos IDP independientes que proporcionan funcionalidad de IDP sin capacidades integradas de cortafuegos/VPN. Puede utilizar el sistema Net-Screen-Security Manager para administrar estos dispositivos al igual que los dispositivos de cortafuegos/VPN con capacidad para IDP.

Configuración del dispositivo como un dispositivo IDP independiente 235


236

4. Configure las normas de IDP, creando bases de normas según sea necesario.

Para obtener más información sobre la configuración de las normas de seguridad que incluyen normas de IDP, consulte “Configuración de directivas de seguridad” en la página 185”.

Ejemplo: Configuración de una norma de cortafuegos para IDP independienteEn este ejemplo, implementará un dispositivo IDP/cortafuegos/VPN como un sistema de seguridad IDP independiente entre la zona Trust y la zona Data_Center personalizada en su red. Los servidores de base de datos, correo y archivos de la empresa residen en la zona Data_Center. Aunque quizás le interese permitir que los usuarios de la zona Trust tengan acceso a los servidores en la zona Data_Center, también necesita proteger los servidores de ataques que podrían pasar desapercibidos por proceder de una máquina de usuario en la zona Trust. Cree una norma de cortafuegos de la zona Trust a la zona Data_Center que acepte el tráfico de cualquier origen a cualquier destino para cualquier servicio, después habilite IDP en la columna Rule Options, como se muestra en la Figura 83.

Figura 83: Norma de cortafuegos para IDP independiente

Después agregará y configurará bases de normas IDP para que la directiva de seguridad detecte posibles ataques contra servidores en la zona Data_Center, como se muestra en la Figura 84.

Figura 84: Normas IDP para IDP independiente

Configuración del dispositivo como un dispositivo IDP independiente


Configuración de la administración basada en funcionesLa administración basada en funciones de NetScreen-Security Manager (RBA) permite al superadministrador (superadmin) crear un administrador y función personalizados para el dispositivo IDP independiente. Esto le otorga al administrador de IDP permiso para realizar solamente aquellas tareas específicas de las funciones IDP de configuración y administración; el administrador IDP no necesita crear, editar, eliminar, visualizar o actualizar las configuraciones del dispositivo. Cuando el administrador IDP inicia sesión en la UI de NetScreen-Security Manager, él o ella solamente observa los menús y opciones aplicables a IDP.

Ejemplo: Configuración de un administrador sólo de IDPEn este ejemplo, usted (el superadmin) crea una función personalizada y un administrador de IDP que solamente puede realizar tareas específicas de la configuración y administración de IDP en el dispositivo IDP independiente.

1. Inicie sesión en el dominio global como superadmin. Desde la barra de menú, seleccione Tools > Manage Administrators and Domains.

2. Haga clic en la ficha Roles, después haga clic en el icono Add para crear una función denominada IDP_Only. Seleccione tareas específicas a la administración y configuración IDP, tales como:

Attack Update

Create/View/Edit/Delete Policies

Create/View/Edit/Delete Backdoor and IDP Rulebases

View Firewall Rulebases

Create/Edit/Delete Shared Objects and Groups

Seleccione cualquier otra tarea que pueda ser útil al administrador IDP, por ejemplo, puede seleccionar las opciones para visualizar trabajos y el monitor de estado del sistema.

3. Haga clic en OK en el cuadro de diálogo New Role para regresar al cuadro de diálogo Manage Administrators and Domains.

4. Haga clic en la ficha Administrators, después haga clic en el icono Add para crear un administrador denominado IDP_Administrator. Aparece el cuadro de diálogo New Admin con la ficha General seleccionada.

5. En el campo Name, introduzca IDP_Administrator. Puede introducir información de contacto del administrador.

6. Haga clic en la ficha Authorization. Seleccione el método de autorización y la contraseña local del administrador.

7. Haga clic en la ficha Permissions y haga clic en el icono Add para seleccionar la función IDP_Only para este administrador.

Configuración del dispositivo como un dispositivo IDP independiente 237


238

8. Haga clic en OK para cerrar el cuadro de diálogo New Select Role and Domains. Haga clic en OK para cerrar el cuadro de diálogo New Admin. Haga clic en OK para cerrar el cuadro de diálogo Manage Administrators and Domains.

El administrador del dispositivo IDP independiente ahora puede iniciar sesión en NetScreen-Security Manager como IDP_Administrator. Al iniciar sesión, la UI de NetScreen-Security Manager muestra un árbol de navegación limitada y las opciones de menú de este usuario, como se muestra en la Figura 85. Observe que la UI muestre la directiva de seguridad y las opciones del administrador de objetos en el árbol de navegación; las opciones de Devices > Configuration no están disponibles para este usuario.

Figura 85: Visualización de UI para IDP_Administrator

Administración de IDP

Esta sección describe la administración de IDP en el dispositivo con capacidad para IDP.

Acerca de las actualizaciones de la base de datos de ataquesJuniper Networks proporciona actualizaciones de la base de datos de ataques periódicamente, en forma de un archivo de descarga, en el sitio web de Juniper. Las actualizaciones de la base de datos de ataques pueden incluir lo siguiente:

Grupos y objetos de ataques IDP predefinidos modificados o nuevos

Firmas nuevas o modificadas utilizadas por la función de Deep Inspection (DI)

Las actualizaciones al motor IDP, que se ejecuta en el dispositivo de seguridad

En la nueva actualización de la base de datos de ataques, el número de versión aumenta en 1. Cuando descarga una versión de una actualización de la base de datos de ataques del sitio web de Juniper Networks, NetScreen-Security Manager guarda el número de versión de la actualización de la base de datos de ataque. Puede comprobar para ver si hay una actualización disponible más reciente que la última que descargó.



Descarga de las actualizaciones de la base de datos de ataquesLas actualizaciones de la base de datos de ataques se descargan al servidor GUI de NetScreen-Security Manager. Realice los siguientes pasos para descargar un archivo de actualización de la base de datos de ataques:

1. Desde la barra de menú, seleccione Tools > View/Update NSM Attack Database. Aparece el asistente del administrador de actualizaciones de ataques.

2. Siga las instrucciones que aparecen en el Administrador de actualizaciones de ataques para descargar el archivo de actualización de la base de datos de ataques al servidor GUI de NetScreen-Security Manager.

Uso de los objetos de ataque actualizadosNo puede crear, editar o eliminar grupos u objetos de ataque IDP predefinidos, pero puede actualizar la base de datos de objetos de ataque instalada en el servidor GUI de NetScreen-Security Manager. Las actualizaciones de los grupos y objetos de ataque IDP predefinidos pueden incluir las siguientes:

Nuevas descripciones o niveles de gravedad para objetos de ataque existentes

Nuevos grupos u objetos de ataque

Eliminación de objetos de ataque obsoletos

Cuando descarga grupos y objetos de ataque IDP actualizados al servidor GUI, la selección de cualquier nuevo objeto de ataque en la actualización está disponible en una base de normas IDP en una directiva de seguridad. Cuando instala una directiva de seguridad en un dispositivo administrado, solamente los objetos de ataque utilizados en las normas IDP para el dispositivo se envían desde el servidor GUI al dispositivo.

Actualización del motor IDPEl motor IDP es un firmware de cambio dinámico que se ejecuta en el dispositivo de cortafuegos/VPN. Hay dos maneras para actualizar el motor IDP en el dispositivo:

Al actualizar el firmware en un dispositivo IDP/cortafuegos/VPN, el firmware actualizado normalmente incluirá una versión reciente del motor IDP, así como una nueva versión de ScreenOS. (Para obtener información acerca de la actualización de firmware en un dispositivo de seguridad, consulte el manual NetScreen-Security Manager Manager Administrator's Guide.)

NOTA: El sitio web de Juniper Networks está establecido de forma predeterminada en el cuadro de diálogo New Preferences, al que se accede seleccionando Tools > Preferences. El servidor GUI debe tener acceso a Internet.

NOTA: Para la función DI, todas las firmas actualizadas se envían a su dispositivo administrado. Para obtener más información sobre la actualización de la base de datos de objetos de ataque para DI en su dispositivo administrado, consulte el manual NetScreen-Security Manager Manager Administrator's Guide.

Administración de IDP 239


240

Puede actualizar el motor IDP en un dispositivo administrado desde una actualización de la base de datos de ataques en el servidor GUI. Debido a que las actualizaciones de la base de datos de ataques están disponibles más a menudo que las publicaciones de firmware, una actualización de la base de datos de ataques podría incluir una versión más reciente del motor IDP que la que está disponible en la publicación de firmware más reciente. Por ejemplo, una actualización de la base de datos de ataque podría contener objetos de ataque IDP actualizados que solamente se pueden utilizar con una versión actualizada del motor IDP.

Realice los siguientes pasos para ver la versión del motor IDP que se ejecuta actualmente en el dispositivo.

1. Seleccione Tools > View/Update NSM Attack Database. Aparece el asistente del administrador de actualizaciones de ataques.


El resumen de actualización de ataques que se muestra en la Figura 86, incluye información de la versión actual descargada en el servidor GUI y la última versión disponible de Juniper Networks.

Figura 86: Resumen de actualización de ataques

3. Haga clic en Finish para continuar descargando la actualización de la base de datos de ataques más reciente o haga clic en Cancel para salir del administrador de actualización de ataques.



Para actualizar el motor IDP en el dispositivo:

1. Seleccione Devices > IDP Detector Engine > IDP Detector Engine. Aparece el cuadro de diálogo Change Device Sigpack

2. Haga clic en Next y seleccione los dispositivos administrados en los que desea instalar la actualización del motor IDP.

3. Siga las instrucciones del Administrador del dispositivo de cambio para actualizar el motor IDP en el dispositivo seleccionado.

Visualización de los registros IDPCuando los objetos de ataque coinciden con una norma IDP, las entradas del registro IDP aparecen en el visualizador de registros de NetScreen-Security Manager. Realice los siguientes pasos para recibir entradas de registros IDP en el visualizador de registros:

1. Habilite el dispositivo para enviar entradas de registro con los ajustes de gravedad deseados para NetScreen-Security Manager:

a. En el administrador de dispositivos, abra la configuración del dispositivo.

b. En el árbol de navegación del dispositivo, seleccione Report Settings > General > NSM.

c. Seleccione los ajustes de gravedad que desee registrar en NetScreen-Security Manager.

d. Haga clic en OK.

2. Habilite el registro y detección de IDP en la directiva de seguridad instalada en el dispositivo. Para obtener información detallada sobre la configuración de los registros de IDP en la directiva de seguridad, consulte “Configuración de directivas de seguridad” en la página 185.

NOTA: La versión de motor IDP que instale en su dispositivo de seguridad debe ser compatible con la versión del firmware que se está ejecutando en el dispositivo. No puede degradar la versión de motor IDP en el dispositivo.

NOTA: La actualización del motor IDP en un dispositivo no requiere que reinicie el dispositivo.

Administración de IDP 241


242

Las entradas de registro de alarma IDP aparecerán en el visualizador de registros con las siguientes columnas de información.

Source and Destination Address

Action

Protocol

Category (Anomaly, Custom, or Signature)

Subcategory

Severity

Device


Capítulo 7

Atributos de los paquetes sospechosos

Según lo mostrado en los demás capítulos de este volumen, un hacker 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 esta página

“Paquetes ICMP grandes” en la página 244

“Opciones IP incorrectas” en la página 245

“Protocolos desconocidos” en la página 246

“Fragmentos de paquetes IP” en la página 247

“Fragmentos SYN” en la página 248

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 de seguridad bloquea cualquier paquete ICMP que tenga el indicador de más fragmentos (“More Fragments”) activado o que contenga algún valor de desplazamiento en el campo de desplazamiento.

Fragmentos ICMP 243


244

Figura 87: Bloquear fragmentos de 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 zona screen icmp-fragment


Como se establece en “Fragmentos ICMP” en la página 243, 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 se generen paquetes ICMP de gran tamaño. Si un paquete ICMP es inusualmente grande, existe un 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 cuestionable.

Encabezado IP Versión Longitud delencabezado

Tiempo de vida (TTL)

Identificación

Tipo Código

Identificador

Encabezado ICMP(Carga delpaquete IP)

Datos

Opciones



Protocolo (ICMP = 1)

Tipo de servicio

Si el tipo de protocoloes 1 para ICMP...

y el indicador de másfragmentos está activado...

o hay un valor distinto de cero enel campo desplazamiento del fragmento...

Longitud total del paquete (en bytes)

Desplazamiento del fragmentoSuma de comprobación del encabezado

0 D M

Suma de comprobación


…el dispositivo de seguridad bloquea el paquete.


Capítulo 7: Atributos de los paquetes sospechosos

Figura 88: Bloquear paquetes ICMP grandes

Cuando habilita la opción SCREEN “Large Size ICMP Packet Protection”, el dispositivo de seguridad descarta los paquetes ICMP con un tamaño superior a 1024 bytes.

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 zona screen icmp-large

Opciones IP incorrectas

La norma RFC 791, Protocolo de Internet, especifica una serie de opciones que ofrecen controles de enrutamiento, herramientas de diagnóstico y medidas de seguridad especiales. 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 hackers pueden explotar, consulte “Reconocimiento de red mediante opciones IP” en la página 10).

Ya sea intencional o accidentalmente, en ocasiones los hackers configuran las opciones IP de manera incorrecta, generando campos incompletos o mal formados. Independientemente de las intenciones de la persona que manipuló el paquete, el formato incorrecto es de por sí algo anómalo y potencialmente dañino para el destinatario.

Versión Longitud delencabezado


Identificación

Tipo Código

Identificador

Encabezado ICMP(Carga delpaquete IP)

Datos

Opciones



Protocolo (ICMP = 1)

Tipo de servicio

Cuando el tipo de protocolo es 1 para ICMP… y este valor es >1024…

Longitud total del paquete (en bytes)



0 D M

Suma de comprobación



Encabezado IP

Opciones IP incorrectas 245


246

Figura 89: Opciones IP formateadas incorrectamente

Cuando habilita la opción SCREEN “Bad IP Option Protection”, el dispositivo de seguridad bloquea los paquetes cuyo encabezado IP contenga cualquier opción IP formateada de manera incorrecta. El dispositivo de seguridad registra el evento en el registro de eventos.

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, luego haga clic en Apply.

CLI

set zone zona screen ip-bad-option


Por el momento, los tipos de protocolos con los números de identificación 137 o superiores están reservados y no definidos. Debido precisamente a que estos protocolos no están definidos, no se puede saber por anticipado si un determinado protocolo desconocido es legítimo o malicioso. Salvo que su red utilice un protocolo no estándar con un número de identificación 137 o superior, una buena medida de precaución es impedir que esos elementos desconocidos puedan entrar en su red protegida.



Identificación

Opciones



Protocolo

Tipo de servicio Longitud total del paquete (en bytes)



0 D M

Carga de datos

Si las opciones IP están formateadas de manera incorrecta, el dispositivo de seguridad registra el evento en los contadores SCREEN de la interfaz de entrada.



Figura 90: Protocolos desconocidos

Cuando habilita la opción SCREEN “Unknown Protocol Protection”, el dispositivo de seguridad descarta los paquetes cuyo campo de protocolo contenga un número de identificación de protocolo 137 o superior.

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, luego haga clic en Apply.

CLI

set zone zona screen unknown-protocol

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 (MTU) de cada red. Aprovechando los fragmentos IP, un hacker 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.



Identificación

Opciones



Protocolo




0 D M

Carga de datos

Si las opciones IP están formateadas de manera incorrecta, el dispositivo de seguridad registra el evento en los contadores SCREEN de la interfaz de entrada.

Si el número de ID del protocolo es 137 o superior,el dispositivo de seguridad bloquea el paquete.

Fragmentos de paquetes IP 247


248

Figura 91: Fragmentos de paquetes IP

Cuando habilita el dispositivo de seguridad para rechazar fragmentos IP en una zona de seguridad, el dispositivo bloquea todos los fragmentos de paquetes IP que recibe en las interfaces asociadas a esa zona.

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, luego haga clic en Apply.

CLI

set zone zona screen block-frag

Fragmentos SYN

El protocolo de Internet (IP) encapsula los segmentos SYN del protocolo de control de transmisiones (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 habilita la opción SCREEN “SYN Fragment Detection”, el dispositivo de seguridad detecta los paquetes cuyo encabezado IP indique que el paquete se ha fragmentado y que el indicador SYN está activado en el encabezado TCP. El dispositivo de seguridad registra el evento en la lista de contadores SCREEN de la interfaz de entrada.



Identificación

Opciones



Protocolo




0 D M

Carga de datos


Si el indicador de másfragmentos está activado...


Fragmentos SYN


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, luego haga clic en Apply.

CLI

set zone zona screen syn-frag

Figura 92: Fragmentos SYN

Versión Longitud delencabezado


Identificación



Tamaño de encabezadode 4 bits

Encabezado ICMP

Reservado(6 bits)




Protocolo


Desplazamientodel fragmento


0 D M

Número de puerto de destino de 16 bits

Encabezado IP

Si el indicador de másfragmentos está activado...





Datos (si los hay)


Tamaño de ventana de 16 bitsURG

ACK

PSH

RST

SYN

FIN

…y el indicador SYN está activado… ...el dispositivo descarta el paquete.

Fragmentos SYN 249


250
Fragmentos SYN

Apéndice A

Contextos para las firmas definidas por el usuario

El contexto define la ubicación dentro del paquete donde el módulo Deep Inspection (DI) busca una firma que coincida con el patrón del objeto de ataque. Cuando define un objeto de ataque de firma activa, puede especificar cualquiera de los contextos en las siguientes listas. Después de definir un objeto de ataque, deberá colocarlo en un grupo de objetos de ataque definido por el usuario para poderlo utilizar en directivas.

Cuando el módulo DI examina el tráfico en busca de firmas de secuencias TCP, lo hace sin preocuparse de los contextos. Las firmas de la secuencia de TCP buscan patrones en cualquier lugar y en cualquier tipo de tráfico de TCP sin importar el protocolo de aplicación que se utiliza. Las firmas de secuencias sólo se pueden definir en sistemas de las series NetScreen-5000 y 2000. Sin embargo, Stream256 busca patrones en los primeros 256 bytes de datos.

Tabla 21: Contextos para las firmas definidas por el usuario

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 que define el usuario.

Protocolo Contexto Descripción (Establece el contexto como…)

AIM aim-chat-room-desc La descripción de una sala de chat en una sesión de America Online Instant Messenger (AIM) o ICQ (I Seek You).

aim-chat-room-name El nombre de una sala de chat en una sesión AIM o ICQ.

aim-get-file El nombre de un archivo que un usuario transfiere de un interlocutor.

aim-nick-name El apodo (nickname) de un usuario de AIM o ICQ.

aim-put-file El nombre de un archivo que un usuario transfiere a un interlocutor.

aim-screen-name El nombre de la pantalla de un usuario de AIM o ICQ.

DNS dns-cname El CNAME (nombre canónico) en una respuesta o petición del Sistema de nombres del dominio (DNS), según se define en la norma RFC 1035, Nombres de dominio: Implementación y especificación).

FTP ftp-command Uno de los comandos de FTP especificado en RFC 959, Protocolo de transferencia de archivos (FTP).

ftp-password Una contraseña de inicio de sesión de FTP.

ftp-pathname Un nombre de archivo o directorio en cualquier comando de FTP.

A-I


A-II

ftp-username El nombre que un usuario introduce cuando inicia una sesión en un servidor de FTP.

Gnutella gnutella-http-get-filename

El nombre de un archivo que un cliente de Gnutella intenta recuperar.

HTTP http-authorization El nombre de usuario y la contraseña decodificados de unencabezado Authorization: Basic en una petición de protocolo de transferencia de hipertexto (HTTP), según se especifica en la norma RFC 1945, Protocolo de transferencia de hipertexto, HTTP/1.0.

http-header-user-agent El campo user-agent en el encabezado de una petición HTTP. (Cuando los usuarios visitan un sitio Web, proporcionan información sobre sus exploradores en este campo).

http-request Una línea de petición HTTP.

http-status La línea de estado en una respuesta HTTP. (La línea de estado es un código de tres dígitos que un servidor de Web envía a un cliente para comunicar el estado de una conexión. Por ejemplo, 401 significa “No autorizado” y 404 significa “No encontrado”).

http-text-html El texto o datos del lenguaje de marcación de hipertexto (HTML) en una transacción de HTTP.

http-url El localizador de recursos uniforme (URL) en una petición HTTP según aparece en la secuencia de datos.

http-url-parsed Una cadena de texto “normalizada” que se decodificó a partir de una cadena unicode que comprime un URL utilizado en HTTP.

http-url-variable-parsed

Una variable de interfaz de puerta de enlace común decodificada (CGI) en URL de una petición HTTP-GET.

IMAP imap-authenticate Un argumento en un comando AUTHENTICATE del protocolo de acceso de correo de Internet (IMAP). El argumento indica el tipo de mecanismo de autenticación que el cliente de IMAP propone al servidor. Algunos ejemplos son KERBEROS_V4, GSSAPI (consulte RFC 1508, Interfaz de programa de aplicación de servicio de seguridad genérico) y SKEY.

Para obtener información sobre IMAP, consulte RFC 1730, Protocolo de acceso de mensajes de Internet - Versión 4y RFC 1731, Mecanismos de autenticación de IMAP4.

imap-login El nombre de usuario o la contraseña en texto sin formato en un comando IMAP LOGIN.

imap-mailbox La cadena de texto de buzón en un comando IMAP SELECT.

imap-user El nombre de usuario en un comando IMAP LOGIN.

MSN Messenger

msn-display-name El nombre de visualización de un usuario en una sesión de mensajería instantánea de Microsoft Network (MSN).

msn-get-file El nombre de un archivo que un cliente descarga de un interlocutor.

msn-put-file El nombre de un archivo que un cliente envía a un interlocutor.

msn-sign-in-name El nombre de la pantalla (nombre de inicio de sesión) de un usuario de Mensajes instantáneos de MSN.

POP3 pop3-auth El comando AUTH en una sesión del protocolo de oficina postal, versión 3 (POP3). Para obtener más información sobre POP3, consulte la norma RFC 1939, Protocolo de oficina postal, Versión 3.

pop3-header-from La cadena de texto en el encabezado “De:” de un correo electrónico en una transacción de POP3.

pop3-header-line La cadena de texto en cualquier línea del encabezado de un correo electrónico en una transacción de POP3.

pop3-header-subject La cadena de texto en el encabezado “Asunto:” de un correo electrónico en una transacción de POP3.


Apéndice A: Contextos para las firmas definidas por el usuario

pop3-header-to La cadena de texto en el encabezado “Para:” de un correo electrónico en una transacción de POP3.

pop3-mime-content-filename

El nombre del archivo de contenido de un documento adjunto de extensiones de correo de Internet multiuso (MIME) en una sesión POP3.

pop3-user El nombre de usuario en una sesión POP3.

SMB smb-account-name El nombre de una cuenta de bloques de mensajes de servidor (SMB) en una petición SESSION_SETUP_ANDX en una sesión de SMB.

smb-connect-path La ruta de conexión en la petición TREE_CONNECT_ANDX en una sesión de SMB.

smb-connect-service El nombre del servicio de conexión en la petición TREE_CONNECT_ANDX en una sesión de SMB.

smb-copy-filename El nombre de un archivo en una petición COPY en una sesión de SMB.

smb-delete-filename El nombre de un archivo en una petición DELETE en una sesión de SMB.

smb-open-filename El nombre de un archivo en las peticiones NT_CREATE_ANDX y OPEN_ANDX en una sesión de SMB.

SMTP smtp-from La cadena de texto en una línea de comando “MAIL FROM” en una sesión del protocolo de transferencia de correo sencillo (SMTP), según se describe en RFC 2821, Protocolo de transferencia de correo sencillo.

smtp-header-from La cadena de texto en el encabezado “De:” en una sesión de SMTP.

smtp-header-line La cadena de texto en cualquier línea del encabezado en una sesión de SMTP.

smtp-header-subject La cadena de texto en el encabezado “Asunto:” en una sesión de SMTP.

smtp-header-to La cadena de texto en el encabezado “Para:” en una sesión de SMTP.

smtp-mime-content-filename

El nombre del archivo de contenido de un documento adjunto de extensiones de correo de Internet de múltiples propósitos (MIME) en una sesión SMTP.

smtp-rcpt La cadena de texto en una línea de comando “RCPT TO” en una sesión SMTP.

stream256 Los primeros 256 bytes de una secuencia de datos reensamblados y normalizados de TCP.

Yahoo! Messenger

ymsg-alias El nombre de identificación alterno asociado con el nombre de usuario principal de un usuario de mensajes instantáneos de Yahoo!

ymsg-chatroom-message

El texto en mensajes intercambiados en una sala de chat de mensajería instantánea de Yahoo!

ymsg-chatroom-name

El nombre de un sala de chat de mensajería instantánea de Yahoo!

ymsg-nickname El apodo de un usuario de mensajería instantánea de Yahoo!

ymsg-p2p-get-filename-url

La ubicación de un archivo en la máquina de un interlocutor de mensajería instantánea de Yahoo! desde la cual se puede descargar.

ymsg-p2p-put-filename-url

La ubicación de un archivo en la máquina de un interlocutor de mensajería instantánea de Yahoo! al cual se puede descargar.


A-III


A-IV

Índice
Aacciones de ataque ............................................ 143 a 151
close........................................................................143close client .............................................................144close server ............................................................143drop ........................................................................144drop packet ............................................................144ignore......................................................................144none........................................................................144

Actualización del motor IDP.......................................239Actualizaciones de la base de datos de ataques

descargar................................................................239introducción...........................................................238

Administración en base a funcionesBases de normas de IDP ......................................188Configuración de un administrador sólo de

IDP........................................................................237agentes zombie........................................................29, 31AIM................................................................................135ALG..................................................................................59análisis antivirus .................................................... 62 a 88

descompresión ........................................................92extensiones de archivo...........................................93FTP............................................................................73goteo HTTP ..............................................................87HTTP .........................................................................74HTTP “keep-alive” ...................................................86IMAP .........................................................................76MIME.........................................................................75modo de fallo...........................................................85POP3.........................................................................76recursos de AV por cliente .....................................84SMTP.........................................................................78suscripción ...............................................................81

análisis FIN .....................................................................16anomalías en el protocolo ..........................................138

ALG .........................................................................136Aplicaciones de mensajería inmediata ...............135Aplicaciones P2P ...................................................135configuración de parámetros...............................167protocolos admitidos .................................. 133 a 137protocolos básicos de red.....................................133

applets Java, bloquear .................................................174archivos exe, bloquear ................................................174archivos zip, bloquear .................................................174

asignación de grandes cantidades de paquetes simultáneos de la tabla de sesiones .........................19

ataquesasignación de grandes cantidades de paquetes

simultáneos de la tabla de sesiones....................19direcciones MAC desconocidas .............................43DOS...................................................................29 a 56etapas .........................................................................2Fragmentos de paquetes IP .................................247Fragmentos SYN....................................................248ICMP

fragmentos........................................................243inundaciones ......................................................49

inundación de la tabla de sesiones .......................30Inundaciones SYN ...........................................37 a 43Inundaciones UDP...................................................51objetivos comunes ....................................................1opciones de detección y defensa ......................2 a 5paquetes ICMP grandes ........................................244Ping of Death ...........................................................53protocolos desconocidos ......................................246Teardrop...................................................................54terrestres ..................................................................52WinNuke...................................................................55

Bbarrida de puertos ...........................................................9barrido de direcciones ....................................................8base de datos de objetos de ataque.................124 a 132

actualización automática..............................127, 128actualización inmediata........................................127actualización manual ............................................130cambiar la URL predeterminada .........................130notificación automática y actualización

manual .................................................................129Base de normas de exclusión

Adición a una directiva de seguridad..................206introducción...........................................................205

Base de normas de puerta de atrásAdición a una directiva de seguridad..................211introducción...........................................................210

Bases de normas de IDPAdición a una directiva de seguridad..................192Administración en base a funciones...................188introducción...........................................................191

Índice IX-I

IX-II


tipos ........................................................................ 187Bloque de mensajes del servidor

Consulte SMBBobinadora LPR........................................................... 134

CChargen ........................................................................ 133claves de licencia

actualización del patrón de ataques ................... 122modo avanzado..................................................... 122

comprobación de SYN .................................... 16, 16 a 19agujero de reconocimiento .................................... 18asignación de grandes cantidades de paquetes

simultáneos de la tabla de sesiones ................... 19enrutamiento asimétrico........................................ 18interrupción de sesión............................................ 18

controles ActiveX, bloqueo......................................... 173Cookies SYN................................................................... 47

DDDoS............................................................................... 29Deep Inspection (DI) ......................................... 140 a 165

acciones de ataque ..................................... 143 a 151anomalías en el protocolo.................................... 138base de datos de objetos de ataque.......... 124 a 132cambio de gravedad ............................................. 140claves de licencia .................................................. 122contexto ...................................................................... Idesactivar objetos de ataque ............................... 142expresiones regulares................................. 161 a 162firmas completas .................................................. 137firmas de secuencias ............................................ 138firmas personalizadas................................. 161 a 165grupos de objetos de ataque................................ 139introducción........................................................... 120negación de objetos de ataque............................ 168objetos de ataque.................................................. 122objetos de ataque personalizados ....................... 160paquetes de firmas ............................................... 124registro de grupos de objetos de ataque ............ 154servicios personalizados ............................ 156 a 160volver a habilitar objetos de ataque.................... 143

Denegación de serviciovéase DoS

descompresión, análisis antivirus ............................... 92Detección y prevención de intrusión, definida........ 175DHCP ............................................................................134directivas

contexto ................................................................. 124sección central ................................................ 18, 123

Directivas de seguridad .............................................. 185Base de normas..................................................... 186Ejecución de bases de normas ............................ 189normas ................................................................... 186

plantillas .................................................................189Discard..........................................................................134DNS ...............................................................................133DoS

asignación de grandes cantidades de paquetes simultáneos de la tabla de sesiones ...................19

ataque específico del sistema operativo....... 53 a 56cortafuegos ...................................................... 30 a 36inundación de la tabla de sesiones .......................30red..................................................................... 37 a 52

DoS, ataques .......................................................... 29 a 56drop-no-rpf-route ...........................................................20

EEcho ..............................................................................134Entradas de registros

Habilitación en las normas IDP...........................241establecimientos de conexión en tres pasos..............37estado................................................................................3

firmas .....................................................................137inspección ..................................................................3

evasión.................................................................... 15 a 27expiración dinámica.............................................. 33 a 35exploits

véase ataquesexpresiones regulares........................................ 161 a 162extensiones de archivo, análisis de AV .......................93

Ffiltrado de contenido........................................... 57 a 118filtrado de paquetes dinámico .......................................3filtrado de Web

aplicar perfiles a directivas ..................................108caché.......................................................................103categorías de URL .................................................104enrutamiento .........................................................116estado del servidor................................................116integrado ................................................................101mensaje de URL bloqueada .................................115nombre del servidor SurfControl ........................113nombre del servidor Websense ..........................113perfiles....................................................................106puerto del servidor SurfControl ...........................113puerto del servidor Websense .............................113redirigir...................................................................110servidores CPA de SurfControl ............................101servidores de SurfControl.....................................102servidores por vsys ...............................................112SurfControl SCFP...................................................113tiempo de espera de comunicaciones ................114tipo de mensaje de URL bloqueada ....................115

FIN sin indicador ACK...................................................14Finger............................................................................134firmas

Índice

Índice

estado .....................................................................137firmas de secuencias...................................................138Fragmentos SYN ..........................................................248fuerza bruta

acciones de ataque................................................151

GGopher ..........................................................................134grupos de objetos de ataque ......................................139

cambio de gravedad .............................................140inicio sesión ...........................................................154niveles de gravedad ..............................................139que se aplican en directivas.................................132URL de ayuda ........................................................136

grupos VSD...................................................................185

HHTTP

“keep-alive”..............................................................86bloqueo de componentes........................... 173 a 174goteo .........................................................................87tiempo de espera de la sesión ...............................34

IICMP..............................................................................134

fragmentos.............................................................243paquetes grandes ..................................................244

IDENT............................................................................134IDP

configuración básica .............................................178Configuración de un dispositivo para IDP

independiente .....................................................235Configuración del modo en línea o tap en

línea......................................................................190Habilitación en una norma de cortafuegos........189

indicadores SYN y FIN activados .................................13inicio sesión

grupos de objetos de ataque................................154inspecciones.....................................................................3inundación de la tabla de sesiones..............................30inundaciones

ICMP .........................................................................49SYN ............................................................. 37 a 43, 47tabla de sesiones .....................................................30UDP...........................................................................51

inundaciones de SYN-ACK-ACK a través de un servidor proxy ............................................................................35

Inundaciones ICMP .......................................................49Inundaciones SYN ................................................. 37 a 43

ataques .....................................................................37Cookies SYN.............................................................47descartar las direcciones MAC desconocidas ......43tamaño de la cola....................................................42tiempo de espera ....................................................42

umbral ......................................................................38umbral de alarma....................................................41umbral de ataque ....................................................40umbral de destino ...................................................41umbral de origen.....................................................41

IPfragmentos de paquetes .......................................247

IRC.................................................................................135

LLand Attack, ataques terrestres ....................................52LDAP..............................................................................134límites de sesiones ................................................30 a 33

según su destino................................................31, 32según su origen..................................................30, 32

Llamada de procedimiento remoto de MicrosoftConsulte MS-RPC

MMensajería inmediata ..................................................135

AIM..........................................................................135IRC...........................................................................135Mensajero Yahoo!..................................................135MSN Messenger .....................................................135Yahoo! Messenger .................................................135

Mensajería inmediata de America OnlineConsulte AIM

Mensajero Yahoo! ........................................................135Microsoft Network Instant Messenger

Consulte MSN Instant MessengerMIME, análisis antivirus ................................................75modo de fallo .................................................................85Modo en línea ..............................................................190Modo tap en línea........................................................190Modo transparente

descartar las direcciones MAC desconocidas.......43Modos de IDP...............................................................190Motor IDP

actualizar ................................................................239MS RPC .........................................................................136MSN Messenger ...........................................................135

Nnegación, Deep Inspection (DI)..................................168NetBIOS ........................................................................136NFS ................................................................................134NNTP .............................................................................134normas de exclusión .........................................205 a 210

configuración .........................................................207Configuración de las columnas de

coincidencia.........................................................207Configuración de los ataques...............................208Configuración de objetivos...................................209Configuración de zonas ........................................207

Índice IX-III

IX-IV


Configuración del origen y destino..................... 208Configuración desde el visualizador de

registros ............................................................... 209Normas de IDP ............................................................ 191

configuración......................................................... 193Configuración de acciones................................... 199Configuración de la gravedad del ataque........... 205Configuración de la notificación ......................... 204Configuración de las acciones de IP ................... 202Configuración de las columnas de

coincidencia ........................................................ 193Configuración de los ataques .............................. 200Configuración de los servicios............................. 195Configuración de normas definitivas.................. 198Configuración de objetivos .................................. 205Configuración de objetos de ataque de IDP ...... 188configuración de objetos de dirección................ 188Configuración de objetos de servicio.................. 188Configuración del origen y destino..................... 194Introducción de comentarios .............. 205, 209, 215

normas de puerta de atrás ............................... 210 a 215Configuración de acciones................................... 213Configuración de la gravedad.............................. 215Configuración de las columnas de

coincidencia ........................................................ 212Configuración de los servicios............................. 213Configuración de objetivos .................................. 215Configuración de zonas........................................ 212Configuración del funcionamiento ..................... 213Configuración del origen y destino..................... 212

NSRPgrupos VSD ............................................................ 185

NTP ............................................................................... 134

Oobjetos

objetos de ataque.................................................. 215Objetos de ataque, anomalías de protocolo ...... 216Objetos de ataque, creación personalizada ....... 219Objetos de ataque, firma ..................................... 216

objetos AVtiempo de espera .................................................... 91

objetos de ataque ...................................... 122, 132 a 138anomalía del protocolo......................................... 216anomalías en el protocolo............................ 138, 167desactivar............................................................... 142firma ....................................................................... 216firmas completas .................................................. 137firmas de secuencias ............................................ 138firmas de secuencias de TCP............................... 165fuerza bruta ................................................... 151, 152IDP .......................................................................... 188introducción........................................................... 215negación................................................................. 168

personalizados.......................................................219volver a habilitar ...................................................143

Objetos de ataque IDP ................................................188objetos de ataques de fuerza bruta ...........................152opción de marca de tiempo de IP .........................11, 12opción de seguridad IP ...........................................11, 12opción IP de grabación de ruta ..............................11, 12opción IP de ID de secuencia.................................11, 12opción IP de ruta de origen abierta............... 11, 26 a 27opción IP de ruta de origen estricta .............. 11, 26 a 27Opciones IP ............................................................ 10 a 12

atributos ........................................................... 10 a 11formateadas incorrectamente .............................245grabación de ruta ..............................................11, 12ID de secuencia .................................................11, 12marca de hora ...................................................11, 12ruta de origen ..........................................................26ruta de origen abierta ............................... 11, 26 a 27ruta de origen estricta .............................. 11, 26 a 27seguridad............................................................11, 12

PP2P ................................................................................135

BitTorrent ...............................................................135DC ...........................................................................135eDonkey .................................................................136FastTrack................................................................136Gnutella ..................................................................136KaZaa......................................................................136MLdonkey ..............................................................136Skype ......................................................................136SMB.........................................................................136WinMX....................................................................136

paquetes de firmas, DI................................................124Ping of Death .................................................................53plantillas

directiva de seguridad ..........................................189Portmapper ..................................................................134protección contra ataques

nivel de directivas .....................................................5nivel de zona de seguridad ......................................5

protección contra URL maliciosas ....................... 58 a 61protocolos desconocidos ............................................246Puerta de enlace en la capa de aplicación

Véase ALGPunto a punto

Consulte P2P

RRADIUS .........................................................................134reconocimiento........................................................ 7 a 27

análisis FIN...............................................................16barrida de puertos.....................................................9barrido de direcciones..............................................8

Índice

Índice

indicadores SYN y FIN activados ..........................13Opciones IP..............................................................10paquete TCP sin indicadores .................................15

reensamblaje de fragmentos................................ 58 a 61rexec..............................................................................134RFC

1038, Opción de seguridad IP revisada ................ 11791, Internet Protocol......................................... 11791, protocolo de Internet................................... 10793, Protocolo de control de transmisión............. 14

rlogin .............................................................................134rsh..................................................................................134RTSP ..............................................................................134

SSCREEN

Ataques terrestres ...................................................52Ataques WinNuke ...................................................55barrida de puertos.....................................................9barrido de direcciones..............................................8descartar las direcciones MAC desconocidas ......43FIN sin ACK..............................................................16FIN sin indicador ACK, descartar ..........................14fragmentos de paquetes IP, bloquear.................247fragmentos SYN, detectar ....................................248ICMP

fragmentos, bloquear ......................................243indicadores SYN y FIN activados ..........................13inundaciones de SYN-ACK-ACK a través de un

servidor proxy .......................................................35Inundaciones ICMP .................................................49Inundaciones SYN........................................... 37 a 43Inundaciones UDP ..................................................51opción IP de ruta de origen abierta, detectar ......27opción IP de ruta de origen estricta, detectar .....27opción IP de ruta de origen, rechazar ..................27Opciones IP..............................................................10opciones IP incorrectas, descartar ......................245paquete TCP sin indicadores, detectar .................15paquetes ICMP grandes, bloquear ......................244Ping of Death ...........................................................53protocolos desconocidos, descartar....................246Simulación de IP ............................................. 20 a 25Teardrop...................................................................54zonas VLAN y MGT ...................................................3

serviciospersonalizados.......................................................156

Simulación de IPCapa 2.................................................................21, 24Capa 3.................................................................20, 22drop-no-rpf-route.....................................................20

simulación de IP .................................................... 20 a 25Sistema con capacidad para IDP ...............................176sistemas operativos, sondeos de host para ........ 12 a 15

SMBNetBIOS ..................................................................136

SNMPTRAP ...................................................................135sondeo

puertos abiertos.........................................................9red ...............................................................................8sistemas operativos...........................................12, 15

SSH ................................................................................135SSL.................................................................................135SurfControl ...........................................................101, 110SYN, cookies...................................................................47syslog.............................................................................135

TTCP

firmas de secuencias.............................................165paquete sin indicadores..........................................15tiempos de espera de sesiones..............................34

Teardrop, ataques ..........................................................54Telnet.............................................................................135TFTP ..............................................................................135tiempo de espera de la sesión

HTTP .........................................................................34tiempos de espera de sesiones

TCP............................................................................34UDP...........................................................................34

UUDP

tiempos de espera de sesiones..............................34umbral

umbral inferior ........................................................33umbral superior .......................................................33

umbral inferior ...............................................................33umbral superior .............................................................33

VVisualizador de registros

Creación de una norma de exclusión .................209VNC ...............................................................................135

Wweb, filtrado........................................................110 a 118Whois ............................................................................135WinNuke, ataques..........................................................55

YYahoo! Messenger........................................................135

Zzombie, agentes .......................................................29, 31

Índice IX-V

IX-VI


Índice

Juniper denegacion de servicio (DoS) (y)

Education

Transcript of Juniper denegacion de servicio (DoS) (y)