Juniper denegacion de servicio (DoS) (y)
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Juniper denegacion de servicio (DoS) (y)

on

  • 878 views

Manual de DoS para equipos Juniper

Manual de DoS para equipos Juniper

Statistics

Views

Total Views
878
Views on SlideShare
878
Embed Views
0

Actions

Likes
0
Downloads
10
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Juniper denegacion de servicio (DoS) (y) Document Transcript

  • 1. 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 Conceptos y ejemplos Manual de referencia de ScreenOS Volumen 4: Detección ataques y mecanismos de defensa Versión 6.0.0, Rev. 02
  • 2. 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.
  • 3. Contenido iii Contenido Acerca de este volumen ix Convenciones del documento ..........................................................................x Convenciones de la interfaz de usuario web..............................................x Convenciones de interfaz de línea de comandos ......................................xi Convenciones de nomenclatura y conjuntos de caracteres.......................xi Convenciones para las ilustraciones ........................................................ xii Asistencia y documentación técnica.............................................................. xiii Capítulo 1 Protección de una red 1 Etapas de un ataque.........................................................................................2 Mecanismos de detección y defensa ................................................................2 Supervisió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 .................................................................................8 Barrida de puertos ...........................................................................................9 Reconocimiento de red mediante opciones IP ...............................................10 Sondeos del sistema operativo.......................................................................12 indicadores SYN y FIN activados .............................................................13 Indicador FIN sin indicador ACK..............................................................14 Encabezado TCP sin indicadores activados..............................................15 Técnicas de evasión .......................................................................................15 Análisis FIN .............................................................................................16 Indicadores no SYN .................................................................................16 Simulación de IP......................................................................................20 Ejemplo: Protección contra simulación de IP en la capa 3.................22 Ejemplo: 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.................................................................30 Inundaciones de la tabla de sesiones.......................................................30 Límites a la cantidad de sesiones según sus orígenes y destinos .......30 Ejemplo: Limitación de sesiones según su origen..............................32 Ejemplo: Limitación de sesiones según su destino ............................32 Expiración dinámica .........................................................................33 Ejemplo: Expiración dinámica de sesiones........................................34 Inundaciones de SYN-ACK-ACK a través de un servidor proxy ................35 Ataques DoS contra la red..............................................................................37 Inundaciones SYN ...................................................................................37 Cookie SYN..............................................................................................47
  • 4. iv Contenido Manual de referencia de ScreenOS: Conceptos y ejemplos Inundaciones ICMP..................................................................................49 Inundaciones UDP...................................................................................51 Ataque terrestre.......................................................................................52 Ataques de DoS específicos de cada sistema operativo ..................................53 Ping of Death...........................................................................................53 Ataque Teardrop......................................................................................54 WinNuke .................................................................................................55 Capítulo 4 Supervisión y filtrado de contenidos 57 Reensamblaje de fragmentos.........................................................................58 Protección contra URL maliciosas............................................................58 Puerta de enlace en la capa de aplicación................................................59 Ejemplo: Bloquear URL maliciosas en paquetes fragmentados..........60 Análisis antivirus............................................................................................62 Análisis AV externo .................................................................................62 Servidores de análisis ICAP de equilibrio de carga ............................64 Análisis AV interno ..................................................................................64 Análisis AV del tráfico de IM....................................................................66 Clientes de IM ...................................................................................66 Servidor de IM ..................................................................................67 Protocolos de IM ...............................................................................67 Aspectos de seguridad de la mensajería instantánea.........................68 Asuntos de seguridad de IM ..............................................................68 Análisis de mensajes de chat.............................................................69 Análisis de la transferencia de archivos.............................................69 Resultados del análisis AV .......................................................................70 Análisis AV basado en directivas..............................................................71 Análisis de protocolos de aplicación ........................................................72 Aálisis del tráfico de FTP ...................................................................73 Análisis del tráfico de HTTP ..............................................................74 Actualización de los archivos de patrones AV para el analizador incorporado ......................................................................................81 Suscripción al servicio de firma AV ...................................................81 Ajustes globales del analizador de AV......................................................84 Asignación de recursos de AV ...........................................................84 Comportamiento en modo de fallo: ..................................................85 Tamaño máximo del contenido y número máximo de mensajes (sólo AV interno).........................................................................85 HTTP Keep-Alive ...............................................................................86 Goteo HTTP (únicamente AV interno) ...............................................87 Perfiles de AV ..........................................................................................88 Asignación de un perfil AV a una directiva de cortafuegos ................89 Inicio de un perfil de AV para AV interno..........................................90 Ejemplo: Análisis para todo tipo de tráfico (AV interno) ....................90 Filtrado anti spam..........................................................................................95 Listas blancas y listas negras ...................................................................96 Configuración básica ...............................................................................97 Filtrado del tráfico spam ...................................................................97 Descarte de los mensajes de spam....................................................97 Definición de una lista negra ...................................................................98 Definición de una lista blanca..................................................................98 Definición de una acción predeterminada ...............................................99 Habilitación de un servidor con lista de bloqueo de spam .......................99 Prueba del sistema antispam...................................................................99
  • 5. Contenido Contenido v Filtrado de Web ...........................................................................................100 Uso de la CLI para iniciar los modos de filtrado de Web........................100 Filtrado de Web integrado .....................................................................101 Servidores de SurfControl ...............................................................102 Caché de filtrado de Web................................................................103 Configuración del filtrado de Web integrado...................................103 Ejemplo: Filtrado de Web integrado................................................109 Redireccionamiento del filtrado de Web................................................110 Admisión del sistema virtual ...........................................................112 Configuración de la redirección de filtrado de Web.........................113 Ejemplo: Redirigir el filtrado de Web ..............................................116 Capítulo 5 Deep Inspection 119 Vista general ................................................................................................120 Servidor de la base de datos de objetos de ataque .......................................124 Paquetes de firmas predefinidas............................................................124 Actualización de paquetes de firmas......................................................125 Antes de empezar a actualizar los objetos de ataque.......................126 Actualización inmediata..................................................................127 Actualización automática ................................................................127 Notificación automática y actualización inmediata..........................129 Actualización manual......................................................................130 Objetos de ataque y grupos..........................................................................132 Protocolos admitidos.............................................................................133 Firmas completas ..................................................................................137 Firmas de secuencias TCP .....................................................................138 Anomalías en el protocolo .....................................................................138 Grupos de objetos de ataque..................................................................139 Cambio de los niveles de gravedad .................................................140 Ejemplo: Deep Inspection para P2P ................................................141 Desactivación de objetos de ataque.......................................................142 Acciones de ataque ......................................................................................143 Ejemplo: Acciones de ataque – Close Server, Close, Close Client.....145 Acciones de ataques de fuerza bruta .....................................................151 Objetos de ataques de fuerza bruta.................................................152 Destinos de ataques de fuerza bruta ...............................................152 Tiempo de espera de ataques de fuerza bruta.................................153 Ejemplo 1........................................................................................153 Ejemplo 2........................................................................................154 Ejemplo 3........................................................................................154 Registro de ataques......................................................................................154 Ejemplo: Desactivación del registro por grupo de ataque................154 Asignación de servicios personalizados a aplicaciones .................................156 Ejemplo: Asignación de una aplicación a un servicio personalizado ...........................................................................157 Ejemplo: Asignación de aplicación a servicio para ataques HTTP....159 Objetos de ataque y grupos personalizados .................................................160 Objetos de ataque de firma completa que define el usuario ..................160 Expresiones regulares .....................................................................161 Ejemplo: Objetos de ataque de firma completa que define un usuario .....................................................................................163 Objetos de ataque de la firma de la secuencia de TCP...........................165 Ejemplo: Objeto de ataque de firma de secuencia que define el usuario .....................................................................................166
  • 6. vi Contenido Manual de referencia de ScreenOS: Conceptos y ejemplos Parámetros configurables de anomalías en protocolos ..........................167 Ejemplo: Modificación de parámetros.............................................167 Negación......................................................................................................168 Ejemplo: Negación de objeto de ataque ..........................................168 Bloqueo granular de los componentes de HTTP ...........................................173 Controles ActiveX ..................................................................................173 Applets de Java......................................................................................174 Archivos EXE.........................................................................................174 Archivos ZIP ..........................................................................................174 Capítulo 6 Detección y prevención de intrusiones 175 Dispositivos de seguridad con capacidad para IDP.......................................176 Flujo de tráfico en un dispositivo con capacidad de IDP...............................176 Configuración de la detección y prevención de intrusiones..........................177 Tareas de configuración previa..............................................................178 Ejemplo 1: Configuración básica de IDP ................................................178 Ejemplo 2: Configuración de IDP para cambio en caso de fallo activo, pasivo .............................................................................................181 Ejemplo 3: Configuración de IDP para cambio en caso de fallo activo, activo..............................................................................................183 Configuración de directivas de seguridad.....................................................185 Acerca de las directivas de seguridad ....................................................186 Administración de las directivas de seguridad .......................................186 Instalación de las directivas de seguridad ..............................................186 Uso de las bases de normas de IDP..............................................................187 Administración de las bases de normas de IDP según roles...................188 Configuración de objetos para normas de IDP.......................................188 Uso de las plantillas de directivas de seguridad .....................................189 Habilitación de IDP en las normas de cortafuegos .......................................189 Habilitación de IDP................................................................................190 Especificación del modo en línea o tap en línea ....................................190 Configuración de las normas de IDP ............................................................191 Adición de la base de normas de IDP ....................................................192 Tráfico coincidente................................................................................193 Zonas de origen y de destino ..........................................................194 Objetos de dirección de origen y de destino....................................194 Ejemplo: Establecimiento de origen y de destino............................194 Ejemplo: Establecimiento de múltiples orígenes y destinos.............195 Servicios .........................................................................................195 Ejemplo: Establecimiento de los servicios predeterminados ...........196 Ejemplo: Establecimiento de servicios específicos...........................196 Ejemplo: Establecimiento de servicios no estándar.........................196 Normas definitivas..........................................................................198 Ejemplo: Establecimiento de normas definitivas.............................198 Definición de acciones...........................................................................199 Establecimiento de objetos de ataque....................................................200 Adición de objetos de ataque individualmente................................201 Adición de objetos de ataque por categoría.....................................201 Ejemplo: Adición de objetos de ataque por servicio ........................201 Adición de objetos de ataque por sistema operativo .......................201 Adición de objetos de ataque por gravedad.....................................202 Establecimiento de la acción de IP ........................................................202 Selección de una acción de IP .........................................................203 Selección de una opción de bloqueo ...............................................203
  • 7. Contenido Contenido vii Establecimiento de las opciones de registro....................................203 Establecimiento de las opciones de tiempo de espera.....................203 Establecimiento de la notificación .........................................................204 Establecimiento de los registros......................................................204 Establecimiento de una alerta .........................................................204 Paquetes de registro........................................................................204 Establecimiento de la gravedad .............................................................205 Establecimiento de objetivos .................................................................205 Introducción de comentarios.................................................................205 Configuración de las normas de exclusión ...................................................205 Adición de la base de normas de exclusión ...........................................206 Definición de una coincidencia..............................................................207 Zonas de origen y de destino ..........................................................207 Objetos de dirección de origen y de destino....................................208 Ejemplo: Exclusión de un par origen/destino ..................................208 Establecimiento de los objetos de ataque ..............................................208 Ejemplo: Exclusión de objetos de ataque específicos ......................208 Establecimiento de objetivos .................................................................209 Introducción de comentarios.................................................................209 Creación de una norma de exclusión desde el visualizador de registros..........................................................................................209 Configuración de las normas de puerta de atrás ..........................................210 Adición de la base de normas de puerta de atrás...................................211 Definición de una coincidencia..............................................................212 Zonas de origen y de destino ..........................................................212 Objetos de dirección de origen y de destino....................................212 Servicios .........................................................................................213 Establecimiento del funcionamiento......................................................213 Establecimiento de acciones..................................................................213 Establecimiento de la notificación .........................................................214 Establecimiento de los registros......................................................214 Establecimiento de una alerta .........................................................214 Paquetes de registro........................................................................214 Establecimiento de la gravedad .............................................................215 Establecimiento de objetivos .................................................................215 Introducción de comentarios.................................................................215 Configuración de los objetos de ataque de IDP ............................................215 Acerca de los tipos de objeto de ataque de IDP .....................................216 Objetos de ataque de firma.............................................................216 Objetos de ataque de anomalías de protocolo.................................216 Objetos de ataque compuestos .......................................................216 Visualización de grupos y objetos de ataque de IDP predefinidos..........217 Visualización de ataques predefinidos.............................................217 Visualización de grupos predefinidos ..............................................218 Creación de objetos de ataque IDP personalizados................................219 Creación de un objeto de ataque de firma.......................................220 Creación de un Ataque de anomalía de protocolo ...........................226 Creación de un ataque compuesto ..................................................227 Edición de un objeto de ataque personalizado ................................230 Eliminación de un objeto de ataque personalizado .........................230 Creación de objetos de ataque IDP personalizados................................230 Configuración de grupos estáticos...................................................230 Configuración de grupos dinámicos ................................................232 Ejemplo: Creación de un grupo dinámico........................................233
  • 8. viii Contenido Manual de referencia de ScreenOS: Conceptos y ejemplos Actualización de grupos dinámicos .................................................234 Edición de un grupo de ataques personalizado ...............................235 Eliminación de un grupo de ataques personalizado.........................235 Configuración del dispositivo como un dispositivo IDP independiente.........235 Habilitació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 ......................237 Ejemplo: Configuración de un administrador sólo de IDP ...............237 Administración de IDP.................................................................................238 Acerca de las actualizaciones de la base de datos de ataques ................238 Descarga de las actualizaciones de la base de datos de ataques ............239 Uso de los objetos de ataque actualizados.......................................239 Actualización del motor IDP............................................................239 Visualización de los registros IDP ..........................................................241 Capítulo 7 Atributos de los paquetes sospechosos 243 Fragmentos ICMP ........................................................................................243 Paquetes ICMP grandes................................................................................244 Opciones IP incorrectas ...............................................................................245 Protocolos desconocidos..............................................................................246 Fragmentos de paquetes IP..........................................................................247 Fragmentos SYN ..........................................................................................248 Apéndice A Contextos para las firmas definidas por el usuario A-I Índice ........................................................................................................................IX-I
  • 9. ix 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.
  • 10. Manual de referencia de ScreenOS: Conceptos y ejemplos x Convenciones del documento 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 web En 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_1 IP Address/Domain Name: IP/Netmask: (seleccione), 10.2.2.5/32 Zone: 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.
  • 11. Convenciones del documento xi Acerca de este volumen 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 comandos Las 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 caracteres ScreenOS emplea las siguientes convenciones relativas a los nombres de objetos (como direcciones, usuarios administradores, servidores de autenticación, puertas de enlace IKE, sistemas virtuales, túneles de VPN y zonas) 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.
  • 12. Manual de referencia de ScreenOS: Conceptos y ejemplos xii Convenciones del documento 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.
  • 13. Convenciones del documento xiii Acerca de este volumen Convenciones para las ilustraciones La 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ónomo o bien dominio 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 subred o bien zona de seguridad Interfaz de túnel Motor de directivas
  • 14. Manual de referencia de ScreenOS: Conceptos y ejemplos xiv Asistencia y documentación técnica 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 techpubs-comments@juniper.net.
  • 15. 1 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.
  • 16. Manual de referencia de ScreenOS: Conceptos y ejemplos 2 Etapas de un ataque 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.
  • 17. Mecanismos de detección y defensa 3 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.
  • 18. Manual de referencia de ScreenOS: Conceptos y ejemplos 4 Mecanismos de detección y defensa 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
  • 19. Supervisión de vulnerabilidades 5 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 Untrust En 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.
  • 20. Manual de referencia de ScreenOS: Conceptos y ejemplos 6 Supervisión de vulnerabilidades 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-drop set zone untrust screen ip-spoofing save
  • 21. 7 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
  • 22. Manual de referencia de ScreenOS: Conceptos y ejemplos 8 Barrido de direcciones IP Barrido de direcciones IP 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. ethernet2 1.2.2.1/24 Untrust Paquetes ICMP Rechazado ethernet3 1.1.1.1/24 Dir. origen 2.2.2.5 2.2.2.5 2.2.2.5 2.2.2.5 2.2.2.5 2.2.2.5 2.2.2.5 2.2.2.5 2.2.2.5 2.2.2.5 2.2.2.5 Dir. destino 1.2.2.5 1.2.2.160 1.2.2.84 1.2.2.211 1.2.2.10 1.2.2.20 1.2.2.21 1.2.2.240 1.2.2.17 1.2.2.123 1.2.2.6 11 paquetes ICMP en 0,005 segundos DMZ
  • 23. Barrida de puertos 9 Capítulo 2: Bloqueo de reconocimiento CLI set zone zona screen port-scan threshold número set 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. ethernet2 1.2.2.1/24 Untrust Paquetes IP con segmentos TCP SYN Rechazado ethernet3 1.1.1.1/24 Dir orig:puerto 2.2.2.5:17820 2.2.2.5:42288 2.2.2.5:22814 2.2.2.5:15401 2.2.2.5:13373 2.2.2.5:33811 2.2.2.5:17821 2.2.2.5:19003 2.2.2.5:26450 2.2.2.5:38087 2.2.2.5:24111 Dir dest:puert 1.2.2.5:21 1.2.2.160:23 1.2.2.84:53 1.2.2.211:80 1.2.2.10:111 1.2.2.20:113 1.2.2.21:123 1.2.2.240:129 1.2.2.17:137 1.2.2.123:138 1.2.2.6:139 11 segmentos SYN en 0,005 segundos DMZ Destino: 1.2.2.5
  • 24. Manual de referencia de ScreenOS: Conceptos y ejemplos 10 Reconocimiento de red mediante opciones IP Para bloquear la barrida de puertos 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: 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úmero set 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.
  • 25. Reconocimiento de red mediante opciones IP 11 Capítulo 2: Bloqueo de reconocimiento 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
  • 26. Manual de referencia de ScreenOS: Conceptos y ejemplos 12 Sondeos del sistema operativo 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 Screening > Screen (Zone: seleccione un nombre de zona): Introduzca los siguientes datos, luego haga clic en Apply: IP Record Route Option Detection: (seleccione) IP Timestamp Option Detection: (seleccione) IP Security Option Detection: (seleccione) IP Stream Option Detection: (seleccione) CLI set zone zona screen ip-record-route set zone zona screen ip-timestamp-opt set zone zona screen ip-security-opt set zone zona screen ip-stream-opt Sondeos del sistema operativo 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.
  • 27. Sondeos del sistema operativo 13 Capítulo 2: Bloqueo de reconocimiento indicadores SYN y FIN activados Los 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 bits Encabezado TCP Número de reconocimiento de 32 bits Tamaño de ventana de 16 bits U 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 A C K P S H R S T S Y N F I N Tamaño de encabezado
  • 28. Manual de referencia de ScreenOS: Conceptos y ejemplos 14 Sondeos del sistema operativo Indicador FIN sin indicador ACK La 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. 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 bits U R Número de puerto de origen de 16 bits Sólo está activado el indicador FIN. Número de secuencia de 32 bits Reservado Opciones (si las hay) Datos (si los hay) Puntero urgente 16 bits A C K P S H R S T S Y N F I N Tamaño de encabezado 4 bits F I N
  • 29. Técnicas de evasión 15 Capítulo 2: Bloqueo de reconocimiento Encabezado TCP sin indicadores activados Un 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 Técnicas de evasión 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. Suma de comprobación de TCP 16 bits Número de puerto de destino de 16 bits Número de reconocimiento de 32 bits Tamaño de ventana de 16 bits U R Número de puerto de origen de 16 bits No hay ningún indicador activado. Número de secuencia de 32 bits Reservado Opciones (si las hay) Datos (si los hay) Puntero urgente 16 bits A C K P S H R S T S Y N F I N Tamaño de encabezado 4 bits Encabezado TCP
  • 30. Manual de referencia de ScreenOS: Conceptos y ejemplos 16 Técnicas de evasión Análisis FIN Un 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 SYN De 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).
  • 31. Técnicas de evasión 17 Capítulo 2: Bloqueo de reconocimiento 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-check unset 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í REDIRECCIONAMIENTO Creación de sesión Comprobación de indicador SYN Con la comprobación de indicador SYN habilitada No en sesión Rechazado No DESCARTARDESCARTAR Consultade directivas El paquete llega a la interfaz de entrada Consultade 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
  • 32. Manual de referencia de ScreenOS: Conceptos y ejemplos 18 Técnicas de evasión 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.
  • 33. Técnicas de evasión 19 Capítulo 2: Bloqueo de reconocimiento 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.
  • 34. Manual de referencia de ScreenOS: Conceptos y ejemplos 20 Técnicas de evasión Simulación de IP Un 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 Interfaz eth 1 Puerta de enlace 0.0.0.0 P C
  • 35. Técnicas de evasión 21 Capítulo 2: Bloqueo de reconocimiento 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 ethernet2 0.0.0.0/0 Subred: 1.2.2.0/24 Nombre de zona de dirección: V1-DMZ serv A Nombre 1.2.2.5 Dirección Máscara de red 255.255.255.255 C serv A
  • 36. Manual de referencia de ScreenOS: Conceptos y ejemplos 22 Técnicas de evasión Ejemplo: Protección contra simulación de IP en la capa 3 En 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 Enrutador 1.1.1.250 Zona DMZ Zona Untrust ethernet2 1.2.2.1/24 1.2.3.0/24 1.2.2.0/24 Zona Trust 10.1.1.0/24 ethernet1 10.1.1.1/24 ethernet3 1.1.1.1/24 Enrutador 10.1.1.250 1.1.1.0/24 0.0.0.0/0 Enrutador 1.2.2.250
  • 37. Técnicas de evasión 23 Capítulo 2: Bloqueo de reconocimiento WebUI 1. Interfaces Network > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos, luego haga clic en Apply: Zone Name: Trust Static IP: (seleccione esta opción si es posible) IP Address/Netmask: 10.1.1.1/24 Introduzca los siguientes datos y haga clic en OK: Interface Mode: NAT Network > Interfaces > Edit (para ethernet2): Introduzca los siguientes datos y haga clic en OK: Zone Name: DMZ Static IP: (seleccione esta opción si es posible) IP Address/Netmask: 1.2.2.1/24 Network > Interfaces > Edit (para ethernet3): Introduzca los siguientes datos y haga clic en OK: Zone Name: Untrust Static IP: (seleccione esta opción si es posible) IP Address/Netmask: 1.1.1.1/24 2. Rutas Network > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK: Network Address/Netmask: 10.1.2.0/24 Gateway: (seleccione) Interface: ethernet1 Gateway IP Address: 10.1.1.250 Network > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK: Network Address/Netmask: 1.2.3.0/24 Gateway: (seleccione) Interface: ethernet2 Gateway IP Address: 1.2.2.250 Network > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK: Network Address/Netmask: 0.0.0.0/0 Gateway: (seleccione) Interface: ethernet3 Gateway IP Address: 1.1.1.250
  • 38. Manual de referencia de ScreenOS: Conceptos y ejemplos 24 Técnicas de evasión 3. Protección contra simulación de IP Screening > Screen (Zone: Trust): Seleccione IP Address Spoof Protection y haga clic en Apply. Screening > Screen (Zone: DMZ): Seleccione IP Address Spoof Protection y haga clic en Apply. Screening > Screen (Zone: Untrust): Seleccione IP Address Spoof Protection y haga clic en Apply. CLI 1. Interfaces set interface ethernet1 zone trust set interface ethernet1 ip 10.1.1.1/24 set interface ethernet1 nat set interface ethernet2 zone dmz set interface ethernet2 ip 1.2.2.1/24 set interface ethernet3 zone untrust set interface ethernet3 ip 1.1.1.1/24 2. Rutas set vrouter trust-vr route 10.1.2.0/24 interface ethernet1 gateway 10.1.1.250 set vrouter trust-vr route 1.2.3.0/24 interface ethernet2 gateway 1.2.2.250 set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250 3. Protección contra simulación de IP set zone trust screen ip-spoofing set zone dmz screen ip-spoofing set zone untrust screen ip-spoofing save Ejemplo: Protección contra simulación de IP en la capa 2 En 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.
  • 39. Técnicas de evasión 25 Capítulo 2: Bloqueo de reconocimiento WebUI 1. Direcciones Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK: Address Name: servA IP Address/Domain Name: IP/Netmask: (seleccione), 1.2.2.10/32 Zone: V1-DMZ Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK: Address Name: servB IP Address/Domain Name: IP/Netmask: (seleccione), 1.2.2.20/32 Zone: V1-DMZ Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK: Address Name: servC IP Address/Domain Name: IP/Netmask: (seleccione), 1.2.2.30/32 Zone: V1-DMZ 2. Protección contra simulación de IP Screening > Screen (Zone: V1-Trust): Seleccione IP Address Spoof Protection y haga clic en Apply. CLI 1. Direcciones set address v1-dmz servA 1.2.2.10/32 set address v1-dmz servB 1.2.2.20/32 set address v1-dmz servC 1.2.2.30/32 2. Protección contra simulación de IP set zone v1-untrust screen ip-spoofing save
  • 40. Manual de referencia de ScreenOS: Conceptos y ejemplos 26 Técnicas de evasión Opciones IP de ruta de origen El 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 paquete La 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
  • 41. Técnicas de evasión 27 Capítulo 2: Bloqueo de reconocimiento 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 paquete Dirección de origen real: 6.6.6.5 Dirección de origen simulada: 2.2.2.5 Dirección de destino: 1.1.1.5 IP 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.5 Directiva: set policy from untrust to trust 2.2.2.0/24 MIP(1.1.1.5) HTTP permit ethernet3 1.1.1.1/24 Zona Untrust ethernet1 10.1.1.1/24 Zona Trust ServidorHTTP 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.
  • 42. Manual de referencia de ScreenOS: Conceptos y ejemplos 28 Técnicas de evasión 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 Screening > Screen (Zone: seleccione un nombre de zona): Introduzca los siguientes datos, luego haga clic en Apply: IP Loose Source Route Option Detection: (seleccione) IP Strict Source Route Option Detection: (seleccione) CLI set zone zona screen ip-loose-src-route set zone zona screen ip-strict-src-route
  • 43. 29 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
  • 44. Manual de referencia de ScreenOS: Conceptos y ejemplos 30 Ataques DoS contra el cortafuegos “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 sesiones Un 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 destinos Ademá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.
  • 45. Ataques DoS contra el cortafuegos 31 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
  • 46. Manual de referencia de ScreenOS: Conceptos y ejemplos 32 Ataques DoS contra el cortafuegos 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 origen En 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 1 set zone dmz screen limit-session source-ip-based set zone trust screen limit-session source-ip-based 80 set zone trust screen limit-session source-ip-based save Ejemplo: Limitación de sesiones según su destino En este ejemplo desea limitar la cantidad de tráfico dirigido 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.
  • 47. Ataques DoS contra el cortafuegos 33 Capítulo 3: Defensas contra los ataques de denegación de servicio 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 4000 set zone untrust screen limit-session destination-ip-based save Expiración dinámica De 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:
  • 48. Manual de referencia de ScreenOS: Conceptos y ejemplos 34 Ataques DoS contra el cortafuegos 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 sesiones En 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 superior Expiració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
  • 49. Ataques DoS contra el cortafuegos 35 Capítulo 3: Defensas contra los ataques de denegación de servicio WebUI CLI set flow aging low-watermark 70 set flow aging high-watermark 80 set flow aging early-ageout 4 save Inundaciones de SYN-ACK-ACK a través de un servidor proxy Cuando un usuario de autenticación inicia una conexión Telnet o FTP, envía un segmento SYN al servidor Telnet o FTP correspondiente. El dispositivo 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”).
  • 50. Manual de referencia de ScreenOS: Conceptos y ejemplos 36 Ataques DoS contra el cortafuegos 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 Screening > Screen (Zone: seleccione un nombre de zona): Introduzca los siguientes datos, luego haga clic en Apply: 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úmero set 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 Trust Servidor 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.
  • 51. Ataques DoS contra la red 37 Capítulo 3: Defensas contra los ataques de denegación de servicio Ataques DoS contra la red 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 SYN El 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
  • 52. Manual de referencia de ScreenOS: Conceptos y ejemplos 38 Ataques DoS contra la red 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 IP inalcanzables 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
  • 53. Ataques DoS contra la red 39 Capítulo 3: Defensas contra los ataques de denegación de servicio 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 Screening > Screen (Zone: seleccione un nombre de zona): Introduzca los siguientes datos, luego haga clic en Apply: 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. DireccionesIP 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.
  • 54. Manual de referencia de ScreenOS: Conceptos y ejemplos 40 Ataques DoS contra la red 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.
  • 55. Ataques DoS contra la red 41 Capítulo 3: Defensas contra los ataques de denegación de servicio 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
  • 56. Manual de referencia de ScreenOS: Conceptos y ejemplos 42 Ataques DoS contra la red 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
  • 57. Ataques DoS contra la red 43 Capítulo 3: Defensas contra los ataques de denegación de servicio 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 SYN En 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 ethernet3 1.1.1.1/24 ethernet2 1.2.2.1/24 Servidores Web Zona DMZ 1.2.2.10 1.2.2.20 1.2.2.30 Dispositivo de seguridad Internet 1.2.2.40
  • 58. Manual de referencia de ScreenOS: Conceptos y ejemplos 44 Ataques DoS contra la red 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).
  • 59. Ataques DoS contra la red 45 Capítulo 3: Defensas contra los ataques de denegación de servicio WebUI 1. Interfaces Network > Interfaces > Edit (para ethernet2): Introduzca los siguientes datos y haga clic en OK: Zone Name: DMZ Static IP: (seleccione esta opción si es posible) IP Address/Netmask: 1.2.2.1/24 Network > Interfaces > Edit (para ethernet3): Introduzca los siguientes datos y haga clic en OK: Zone Name: Untrust Static IP: (seleccione esta opción si es posible) IP Address/Netmask: 1.1.1.1/24 2. Direcciones Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK: Address Name: ws1 IP Address/Domain Name: IP/Netmask: (seleccione), 1.2.2.10/32 Zone: DMZ Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK: Address Name: ws2 IP Address/Domain Name: IP/Netmask: (seleccione), 1.2.2.20/32 Zone: 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
  • 60. Manual de referencia de ScreenOS: Conceptos y ejemplos 46 Ataques DoS contra la red Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK: Address Name: ws3 IP Address/Domain Name: IP/Netmask: (seleccione), 1.2.2.30/32 Zone: DMZ Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK: Address Name: ws4 IP Address/Domain Name: IP/Netmask: (seleccione), 1.2.2.40/32 Zone: DMZ 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”. Seleccione ws2 y utilice el botón << para trasladar la dirección de la columna “Available Members” a la columna “Group Members”. Seleccione ws3 y utilice el botón << para trasladar la dirección de la columna “Available Members” a la columna “Group Members”. Seleccione ws4 y utilice el botón << para trasladar la dirección de la columna “Available Members” a la columna “Group Members”. 3. Directiva Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK: Source Address: Address Book Entry: (seleccione), Any Destination Address: Address Book Entry: (seleccione), web_servers Service: HTTP Action: Permit 4. Screen Screening > Screen (Zone: Untrust): Introduzca los siguientes datos, luego haga clic en Apply: SYN Flood Protection: (seleccione) Threshold: 625 Alarm Threshold: 250 Source Threshold: 25 Destination Threshold: 0 Timeout Value: 20 Queue Size: 1000
  • 61. Ataques DoS contra la red 47 Capítulo 3: Defensas contra los ataques de denegación de servicio CLI 1. Interfaces set interface ethernet2 zone dmz set interface ethernet2 ip 1.2.2.1/24 set interface ethernet3 zone untrust set interface ethernet3 ip 1.1.1.1/24 2. Direcciones set address dmz ws1 1.2.2.10/32 set address dmz ws2 1.2.2.20/32 set address dmz ws3 1.2.2.30/32 set address dmz ws4 1.2.2.40/32 set group address dmz web_servers add ws1 set group address dmz web_servers add ws2 set group address dmz web_servers add ws3 set group address dmz web_servers add ws4 3. Directiva set policy from untrust to dmz any web_servers HTTP permit 4. Screen set zone untrust screen syn-flood attack-threshold 625 set zone untrust screen syn-flood alarm-threshold 250 set zone untrust screen syn-flood source-threshold 25 set zone untrust screen syn-flood timeout 20 set zone untrust screen syn-flood queue-size 1000 set zone untrust screen syn-flood save Cookie SYN Una 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.
  • 62. Manual de referencia de ScreenOS: Conceptos y ejemplos 48 Ataques DoS contra la red 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 validada 3. Restablecimiento de MSS 4. Primer paquete aprobado--enrutamiento, consulta de directivas, configuración de sesión 5. Envío de SYN al servidor 1. Consulta de sesiones -- Sin coincidencia de sesión 2. Cookie SYN activada 3. Cálculo de ISN 4. Envío de SYN/ACK al host Envío de ACK a ambos extremos Dispositivo de seguridad
  • 63. Ataques DoS contra la red 49 Capítulo 3: Defensas contra los ataques de denegación de servicio 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 ICMP Las 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.
  • 64. Manual de referencia de ScreenOS: Conceptos y ejemplos 50 Ataques DoS contra la red 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 Screening > Screen (Zone: seleccione un nombre de zona): Introduzca los siguientes datos, luego haga clic en Apply: 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úmero set 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.
  • 65. Ataques DoS contra la red 51 Capítulo 3: Defensas contra los ataques de denegación de servicio Inundaciones UDP De 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 Screening > Screen (Zone: seleccione un nombre de zona): Introduzca los siguientes datos, luego haga clic en Apply: 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 DNS IP: 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 protegida Datagrama UDP Datagrama UDP Datagramas UDP dentro de los paquetes IP procedentes de variasdirecciones 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.
  • 66. Manual de referencia de ScreenOS: Conceptos y ejemplos 52 Ataques DoS contra la red CLI set zone zona screen udp-flood threshold número set zone zona screen udp-flood Ataque terrestre Al 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
  • 67. Ataques de DoS específicos de cada sistema operativo 53 Capítulo 3: Defensas contra los ataques de denegación de servicio Ataques de DoS específicos de cada sistema operativo 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 Death El 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 fragmentado Encabezado IP Encabezado ICMP Datos ICMP 65.510 bytes8 bytes20 bytes
  • 68. Manual de referencia de ScreenOS: Conceptos y ejemplos 54 Ataques de DoS específicos de cada sistema operativo 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 Teardrop Los ataques Teardrop explotan la función de reensamblaje de paquetes IP fragmentados. En el encabezado IP, uno de los campos es el de desplazamiento del fragmento, que indica la posición inicial o desplazamiento de los datos contenidos en un paquete fragmentado con respecto a los datos del paquete original sin fragmentar. 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 IP El dispositivo de seguridad comprueba si existen discrepancias en el campo de desplazamiento del fragmento. Versión Longitu d del Tipo de servicio Longitud total del paquete (en bytes) Identificación Tiempo de vida (TTL) Protocolo Suma de comprobación del encabezado 20 bytes Desplazamiento del fragmento Dirección de origen Dirección de destino Opciones (si las hay) Carga de datos x D M
  • 69. Ataques de DoS específicos de cada sistema operativo 55 Capítulo 3: Defensas contra los ataques de denegación de servicio 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 WinNuke WinNuke 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 = 0 Longitud = 820 Más fragmentos = 1 20 bytes Desplazamiento = 800 Longitud = 620 Más fragmentos = 0 600 bytes DatosEncabezado IP
  • 70. Manual de referencia de ScreenOS: Conceptos y ejemplos 56 Ataques de DoS específicos de cada sistema operativo 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” Opciones (si las hay) Datos (si los hay) U R G Suma de comprobación de TCP A C K P S H R S T S Y N F I N El indicador URG está establecido.
  • 71. 57 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
  • 72. Manual de referencia de ScreenOS: Conceptos y ejemplos 58 Reensamblaje de fragmentos Reensamblaje de fragmentos 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 maliciosas Ademá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.
  • 73. Reensamblaje de fragmentos 59 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ón ScreenOS 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.
  • 74. Manual de referencia de ScreenOS: Conceptos y ejemplos 60 Reensamblaje de fragmentos 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 deny set 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 fragmentados En 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
  • 75. Reensamblaje de fragmentos 61 Capítulo 4: Supervisión y filtrado de contenidos 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: perl Pattern: scripts/perl.exe Length: 14 Security > Screening > Mal-URL (Zone: Untrust): Introduzca los siguientes datos y haga clic en OK: ID: cmf Pattern: cgi-bin/phf Length: 11 Security > Screening > Mal-URL (Zone: Untrust): Introduzca los siguientes datos y haga clic en OK: ID: dll Pattern: 210.1.1.5/msadcs.dll Length: 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” 14 set zone untrust screen mal-url cmf “cgi-bin/phf” 11 set zone untrust screen mal-url dll “210.1.1.5/msadcs.dll” 18 set zone untrust reassembly-for-alg save
  • 76. Manual de referencia de ScreenOS: Conceptos y ejemplos 62 Análisis antivirus 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 externo Se 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
  • 77. Análisis antivirus 63 Capítulo 4: Supervisión y filtrado de contenidos Admite una conexión persistente con el mismo servidor ICAP Una 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álisis Una 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 FLA SH PW R FA N A LA RM M O D 1 TEM P M O D 2 STATU 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/SMTP remotos
  • 78. Manual de referencia de ScreenOS: Conceptos y ejemplos 64 Análisis antivirus Servidores de análisis ICAP de equilibrio de carga El 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 interno El 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.
  • 79. Análisis antivirus 65 Capítulo 4: Supervisión y filtrado de contenidos 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
  • 80. Manual de referencia de ScreenOS: Conceptos y ejemplos 66 Análisis antivirus 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 IM Cada 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.
  • 81. Análisis antivirus 67 Capítulo 4: Supervisión y filtrado de contenidos Servidor de IM El 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 IM La 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áfico en 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)
  • 82. Manual de referencia de ScreenOS: Conceptos y ejemplos 68 Análisis antivirus 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ánea Generalmente, 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.
  • 83. Análisis antivirus 69 Capítulo 4: Supervisión y filtrado de contenidos Análisis de mensajes de chat Cuando 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 archivos El 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.
  • 84. Manual de referencia de ScreenOS: Conceptos y ejemplos 70 Análisis antivirus Resultados del análisis AV El 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 Error Scan 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.
  • 85. Análisis antivirus 71 Capítulo 4: Supervisión y filtrado de contenidos 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 directivas Los 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) “Análisis del tráfico de IMAP y POP3” en la página 76 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
  • 86. Manual de referencia de ScreenOS: Conceptos y ejemplos 72 Análisis antivirus 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ón El 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 IMAP y POP3” en la página 76 “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 FTP local Si no se encuentran virus, los datos se 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ón se 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.
  • 87. Análisis antivirus 73 Capítulo 4: Supervisión y filtrado de contenidos Cada una de las aplicaciones anteriores puede configurarse para uno o varios de los siguientes: Aálisis del tráfico de FTP Para 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 exceden el tamaño máximo de contenido 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
  • 88. Manual de referencia de ScreenOS: Conceptos y ejemplos 74 Análisis antivirus 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 está establecida la opción drop 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 exceden los mensajes simultáneos máximos no está establecida la opción drop pasa los datos al cliente FTP a través del canal de datos Si los datos Y El dispositivo de seguridad Zona Trust Servidor FTP remoto Analizador AV interno Canal de control Canal de datos Zona Untrust Cliente FTP local 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. Si los datos Y El dispositivo de seguridad 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
  • 89. Análisis antivirus 75 Capítulo 4: Supervisión y filtrado de contenidos 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/ exceden el tamaño máximo de contenido está establecida la opción drop descarta los datos y envía un mensaje “file too large” (archivo demasiado grande) al cliente HTTP exceden el tamaño máximo de contenido no está establecida la opción drop 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 exceden los mensajes simultáneos máximos está establecida la opción drop 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 exceden los mensajes simultáneos máximos no está establecida la opción drop pasa los datos al cliente HTTP a través del canal de datos Si los datos Y El dispositivo de seguridad Zona Trust Servidor Web remoto Analizador AV interno Zona Untrust ClienteHTTP 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.
  • 90. Manual de referencia de ScreenOS: Conceptos y ejemplos 76 Análisis antivirus 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)-> exit save Análisis del tráfico de IMAP y POP3 Para 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: Si los datos Y El dispositivo de seguridad 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 contaminado Virus Name: nombre del virus
  • 91. Análisis antivirus 77 Capítulo 4: Supervisión y filtrado de contenidos exceden el tamaño máximo de contenido o bien no se pueden analizar con éxito o bien exceden los mensajes simultáneos máximos está establecida la opción drop 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. exceden el tamaño máximo de contenido o bien no se pueden analizar con éxito o bien exceden los mensajes simultáneos máximos no está establecida la opción drop traffic permit está establecido (fail mode tiene el valor permit) drop no está establecido está establecida la opción email notification 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) notifica al remitente/destinatario sobre los virus detectados o los errores en el análisis. Si los datos Y El dispositivo de seguridad
  • 92. Manual de referencia de ScreenOS: Conceptos y ejemplos 78 Análisis antivirus 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 Analizador AV interno Zona Untrust Servidor de correo local 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 Si los datos Y El dispositivo de seguridad 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 archivo Virus Name: nombre_virus
  • 93. Análisis antivirus 79 Capítulo 4: Supervisión y filtrado de contenidos exceden el tamaño máximo de contenido o bien no se pueden analizar con éxito o bien exceden los mensajes simultáneos máximos está establecida la opción drop no está establecida la opción fail mode (drop) está establecida la opción 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 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 notifica al remitente/destinatario sobre los virus detectados o los errores en el análisis. exceden el nivel máximo de contenido o bien no se pueden analizar con éxito o bien exceden los mensajes simultáneos máximos está desactivada la opción drop traffic permit está establecido (fail mode está permitido) no está activada la opción drop está establecida la opción email notification 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) notifica al remitente/destinatario sobre los virus detectados o los errores en el análisis. Si los datos Y El dispositivo de seguridad 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.
  • 94. Manual de referencia de ScreenOS: Conceptos y ejemplos 80 Análisis antivirus Figura 37: Análisis de antivirus para el tráfico de SMTP Desvío del tráfico a los servidores de análisis AV ICAP El 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 Analizador AV interno 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.
  • 95. Análisis antivirus 81 Capítulo 4: Supervisión y filtrado de contenidos WebUI Objects > Antivirus > ICAP Server >New: Introduzca los siguientes datos y haga clic en Apply: ICAP AV Server Name: ICAP_Server1 Enable: (seleccione), Scan Server Name/IP: 1.1.1.1 Scan Server Port: 1344, Scan URL: /SYMCScan-Resp-AV Probe Interval: 10, Max Connections: CLI set icap server icap_server1 host 1.1.1.1 save El servidor ICAP se habilita automáticamente cuando se configura. Actualización de los archivos de patrones AV para el analizador incorporado El 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 AV Para 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
  • 96. Manual de referencia de ScreenOS: Conceptos y ejemplos 82 Análisis antivirus Actualización de los patrones AV La 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 seguridad Petició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.
  • 97. Análisis antivirus 83 Capítulo 4: Supervisión y filtrado de contenidos 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/5gt Auto 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 Dispositivo de seguridad 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.
  • 98. Manual de referencia de ScreenOS: Conceptos y ejemplos 84 Análisis antivirus WebUI Security > Antivirus > Scan Manager: Introduzca los siguientes datos y haga clic en Apply: Pattern Update Server: http://update.juniper-updates.net/av/5gt Update 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 AV Se 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 AV Un 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.
  • 99. Análisis antivirus 85 Capítulo 4: Supervisión y filtrado de contenidos CLI set av all resources número unset 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 permit unset av all fail-mode traffic El comando unset av restablece el comportamiento en modo de fallo a su valor predeterminado (bloquear el tráfico no analizado). 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.
  • 100. Manual de referencia de ScreenOS: Conceptos y ejemplos 86 Análisis antivirus 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 drop unset 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.
  • 101. Análisis antivirus 87 Capítulo 4: Supervisión y filtrado de contenidos 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-alive unset 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.
  • 102. Manual de referencia de ScreenOS: Conceptos y ejemplos 88 Análisis antivirus 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.
  • 103. Análisis antivirus 89 Capítulo 4: Supervisión y filtrado de contenidos 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 2 set http decompress-layer 2 set imap decompress-layer 2 set pop3 decompress-layer 2 set smtp decompress-layer 2 set http skipmime enable set 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-profile ftp Setting: status: enable mode: scan-intelligent decompress layer: 3 timeout: 180 seconds include ext list: N/A exclude ext list: N/A http Setting: status: enable mode: scan-intelligent decompress layer: 2 timeout: 180 seconds include ext list: N/A exclude ext list: N/A skip 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
  • 104. Manual de referencia de ScreenOS: Conceptos y ejemplos 90 Análisis antivirus 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 interno Los 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-profile device(av:jnpr-profile)-> device-> set av profile jnpr-profile device(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.
  • 105. Análisis antivirus 91 Capítulo 4: Supervisión y filtrado de contenidos (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)-> exit save Ejemplo: Análisis de AV únicamente para el tráfico SMTP y HTTP De 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)-> exit save 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.
  • 106. Manual de referencia de ScreenOS: Conceptos y ejemplos 92 Análisis antivirus Ajustes de perfiles de AV Las 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. WebUI Security > Antivirus > Profile: Seleccione New o Edit para editar un perfil existente. Actualice el valor de Decompress Layer a 2, luego haga clic en Apply. CLI set 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).
  • 107. Análisis antivirus 93 Capítulo 4: Supervisión y filtrado de contenidos 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. WebUI Security > 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: Enable Scan Mode: Scan by Extension Exclude Extension List: elist1 CLI set av extension-list elist1 ace;arj;chm set 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.
  • 108. Manual de referencia de ScreenOS: Conceptos y ejemplos 94 Análisis antivirus WebUI Security > 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. CLI set av profile jnpr-profile (av:jnpr-profile)-> unset av http skipmime (av:jnpr-profile)-> exit save 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 WebUI Security > 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 Sender Email Notify > Select Scan-error Sender Email Notify > Select Scan-error Recipient CLI set 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)-> exit save
  • 109. Filtrado anti spam 95 Capítulo 4: Supervisión y filtrado de contenidos 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. WebUI Security > 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) CLI set av scan-mgr max-msgs drop set av scan-mgr max-content-size 3000 set av scan-mgr max-content-size drop set av profile jnpr-profile (av:jnpr-profile)-> set http decompress-layer 3 (av:jnpr-profile)-> exit save 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.
  • 110. Manual de referencia de ScreenOS: Conceptos y ejemplos 96 Filtrado anti spam 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 negras La 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.
  • 111. Filtrado anti spam 97 Capítulo 4: Supervisión y filtrado de contenidos 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ásica Los 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-profile set 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 spam En 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.2 AS: anti spam result: action Tag email subject, reason: Match local black list exec anti-spam testscan spammer.org AS: anti spam result: action Tag email subject, reason: Match local black list Descarte de los mensajes de spam Al 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-profile device(ns-profile)-> set default action drop
  • 112. Manual de referencia de ScreenOS: Conceptos y ejemplos 98 Filtrado anti spam 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)-> exit device-> save Definición de una lista negra Utilice 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-profile device(anti-spam:ns-profile)-> set blacklist www.wibwaller.com device(anti-spam:ns-profile)-> exit device-> set policy id 2 anti-spam ns-profile Definición de una lista blanca Utilice 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. 3. Salga del contexto de spam y aplique el perfil a una directiva existente (id 2). device-> set anti-spam profile ns-profile device(anti-spam:ns-profile)-> set whitelist www.fiddwicket.com device(anti-spam:ns-profile)-> exit device-> set policy id 2 anti-spam ns-profile
  • 113. Filtrado anti spam 99 Capítulo 4: Supervisión y filtrado de contenidos Definición de una acción predeterminada Utilice 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. 1. Inicie el contexto de un perfil (ns-profile). 2. Especifique que los mensajes de correo electrónico que parecen ser spam incluyan la cadena “Esto es spam” en el encabezado del mensaje. 3. Salga del contexto de spam y aplique el perfil a una directiva existente (id 2). device-> set anti-spam profile ns-profile device(anti-spam:ns-profile)-> set default action tag header “Esto es spam” device(anti-spam:ns-profile)-> exit device-> set policy id 2 anti-spam ns-profile Habilitación de un servidor con lista de bloqueo de spam Utilice 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: 1. Inicie el contexto de un perfil (ns-profile). 2. Active el uso del servicio anti spam predeterminado. 3. Salga del contexto de spam y aplique el perfil a una directiva existente (id 2). device-> set anti-spam profile ns-profile device(anti-spam:ns-profile)-> set sbl default-server-enable device(anti-spam:ns-profile)-> exit device-> set policy id 2 anti-spam ns-profile Prueba del sistema antispam Utilice 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.3 device-> get dbuf stream anti spam result: action Pass, reason: No match
  • 114. Manual de referencia de ScreenOS: Conceptos y ejemplos 100 Filtrado de Web 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 Web Puede 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.
  • 115. Filtrado de Web 101 Capítulo 4: Supervisión y filtrado de contenidos 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 integrado Para 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
  • 116. Manual de referencia de ScreenOS: Conceptos y ejemplos 102 Filtrado de Web 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 SurfControl SurfControl 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).
  • 117. Filtrado de Web 103 Capítulo 4: Supervisión y filtrado de contenidos 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-cpa device(url:sc-cpa)-> exec cate-list-update Caché de filtrado de Web De 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-cpa device(url:sc-cpa)-> set caché size 500 device(url:sc-cpa)-> set caché timeout 18 device(url:sc-cpa)-> exit device-> save Configuración del filtrado de Web integrado Para 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
  • 118. Manual de referencia de ScreenOS: Conceptos y ejemplos 104 Filtrado de Web Cada paso se describe detalladamente en las siguientes secciones. 1. Establecimiento de un servidor de nombres de dominio 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. Habilitación del filtrado de Web Puede 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-cpa device-> set url protocol sc-cpa device(url:sc-cpa)-> set enable device(url:sc-cpa)-> exit device-> 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-cpa device-> set url protocol sc-cpa device(url:sc-cpa)-> get category pre
  • 119. Filtrado de Web 105 Capítulo 4: Supervisión y filtrado de contenidos 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: Competidores URL: www.juegos1.com Introduzca los siguientes datos y haga clic en OK: 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.
  • 120. Manual de referencia de ScreenOS: Conceptos y ejemplos 106 Filtrado de Web CLI device-> set url protocol sc-cpa device(url:sc-cpa)-> set category ompetidores url www.juegos1.com device(url:sc-cpa)-> set category competidores url www.juegos2.com device(url:sc-cpa)-> exit device-> 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-cpa device(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-profile Black-List category: Ninguna White-List category: Ninguna Default Action: Permit
  • 121. Filtrado de Web 107 Capítulo 4: Supervisión y filtrado de contenidos 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-perfil Default Action: Permit Introduzca los siguientes datos y haga clic en OK: Subscribers Identified by: Category Name: Competidores (seleccione) Action: Block (seleccione) Configure: Add (seleccione) Advertisements block Arts & Entertainment permit Chat permit Computing & Internet permit . . . Violence block Weapons block Web-based Email permit other permit NOTA: Debe utilizar WebUI para clonar ns-profile.
  • 122. Manual de referencia de ScreenOS: Conceptos y ejemplos 108 Filtrado de Web CLI device-> set url protocol type sc-cpa device-> set url protocol sc-cpa device(url:sc-cpa)-> set profile mi-perfil other permit device(url:sc-cpa)-> set profile mi-perfil competidores block device(url:sc-cpa)-> exit device-> save 5. Habilitación del perfil y la directiva de filtrado de Web Las 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 la lista negra? ¿En la lista blanca? ¿Categoría definida por el usuario? ¿Categoría definida por el usuario? Acción predeterminada - Bloquear/Permitir
  • 123. Filtrado de Web 109 Capítulo 4: Supervisión y filtrado de contenidos 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 integrado En 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 Web Security > 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 URL Security > Web Filtering > Profile > Custom List > New: Introduzca los siguientes datos y haga clic en Apply: Category Name: Competidores URL: www.comp1.com Introduzca los siguientes datos y haga clic en OK: URL: www.comp2.com 3. Perfil de filtrado de Web Security > Web Filtering > Profile > Custom Profile > New: Introduzca los siguientes datos y haga clic en Apply: Profile Name: mi-perfil Default Action: Permit Category Name: Competidores (seleccione) Action: Block (seleccione) Configure: Add (seleccione)
  • 124. Manual de referencia de ScreenOS: Conceptos y ejemplos 110 Filtrado de Web 4. Directiva Policies > (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: HTTP Web Filtering: (seleccione), mi-perfil Action: Permit CLI 1. Filtrado de Web device-> set url protocol sc-cpa device(url:sc-cpa)-> set enable 2. Categoría de URL device(url:sc-cpa)-> set category competidores url www.comp1.com device(url:sc-cpa)-> set category competidores url www.comp2.com 3. Perfil de filtrado de Web device(url:sc-cpa)-> set profile mi-perfil other permit device(url:sc-cpa)-> set profile mi-perfil competidores block device(url:sc-cpa)-> exit 4. Directiva de cortafuegos device-> set policy id 23 from trust to untrust any any http permit url-filter device-> set policy id 23 device(policy:23)-> set url protocol sc-cpa profile mi-perfil device(policy:23)-> exit device-> save Redireccionamiento del filtrado de Web Los 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.
  • 125. Filtrado de Web 111 Capítulo 4: Supervisión y filtrado de contenidos 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 Trust SYN 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 decomunicació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 Trust SYN 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
  • 126. Manual de referencia de ScreenOS: Conceptos y ejemplos 112 Filtrado de Web 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 virtual Los 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 websense device-> set url protocol websense device(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.
  • 127. Filtrado de Web 113 Capítulo 4: Supervisión y filtrado de contenidos Configuración de la redirección de filtrado de Web Para 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 Web Configure 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.
  • 128. Manual de referencia de ScreenOS: Conceptos y ejemplos 114 Filtrado de Web 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 websense device-> set url protocol websense device(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”.
  • 129. Filtrado de Web 115 Capítulo 4: Supervisión y filtrado de contenidos 4. Defina los parámetros de comportamiento de nivel del sistema Defina 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 Security > Web Filtering > Protocol > Seleccione Redirect (Websense) o Redirect (SurfControl), luego haga clic en Apply. 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 individuales Configure 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.
  • 130. Manual de referencia de ScreenOS: Conceptos y ejemplos 116 Filtrado de Web Ejemplo: Redirigir el filtrado de Web En 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 ntwksec@mycompany.com.” 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. Interfaces Network > Interfaces > List >Edit (para ethernet1): Introduzca los siguientes datos y haga clic en Apply: Zone Name: Trust Static IP: (seleccione esta opción si es posible) IP Address/Netmask: 10.1.1.1/24 Introduzca los siguientes datos y haga clic en OK: Interface Mode: NAT Network > Interfaces > List >Edit (para ethernet3): Introduzca los siguientes datos y haga clic en OK: Zone Name: Untrust Static IP: (seleccione esta opción si es posible) IP Address/Netmask: 1.1.1.1/24 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: Security > Web Filtering > Protocol > Seleccione Redirect (Websense) o Redirect (SurfControl), luego haga clic en Apply.
  • 131. Filtrado de Web 117 Capítulo 4: Supervisión y filtrado de contenidos 2. Servidor de filtrado de Web Security > 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.5 Server Port: 62252 Communication Timeout: 10 (segundos) If connectivity to the server is lost … all HTTP requests: Permit Blocked URL Message Type: Juniper Networks Juniper Blocked URL Message: Lo sentimos, la dirección URL solicitada está prohibida. Póngase en contacto con ntwksec@mycompany.com. 3. Rutas Network > Routing > Destination > trust-vr New: Introduzca los siguientes datos y haga clic en OK: Network Address/Netmask: 0.0.0.0/0 Gateway: (seleccione) Interface: ethernet3 Gateway 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/24 Gateway: (seleccione) Interface: ethernet1 Gateway IP Address: 10.1.1.250 4. Directiva Policy > Policies > (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: HTTP Action: Permit Web Filtering: (seleccione)
  • 132. Manual de referencia de ScreenOS: Conceptos y ejemplos 118 Filtrado de Web CLI 1. Interfaces set interface ethernet1 zone trust set interface ethernet1 ip 10.1.1.1/24 set interface ethernet3 zone untrust set interface ethernet3 ip 1.1.1.1/24 2. Servidor de filtrado de Web device-> set url protocol type scfp device-> set url protocol scfp device(url:scfp)-> set server 10.1.2.5 62252 10 device(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 ntwksec@mycompany.com.” device(url:scfp)-> set config enable 3. Rutas set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250 set vrouter trust-vr route 10.1.2.0/24 interface ethernet1 gateway 10.1.1.250 4. Directiva set policy from trust to untrust any any http permit url-filter save
  • 133. 119 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
  • 134. Manual de referencia de ScreenOS: Conceptos y ejemplos 120 Vista general 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.
  • 135. Vista general 121 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.
  • 136. Manual de referencia de ScreenOS: Conceptos y ejemplos 122 Vista general 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 carga IP ORIG IP DEST PTO ORIG PTO DEST PROTO IP ORIG IP DEST PTO ORIG PTO DEST PROTO Datos de carga
  • 137. Vista general 123 Capítulo 5: Deep Inspection 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 1 device(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 Dirección de destino Dirección de origen Zona de destino Zona de origen Sección central de una directiva
  • 138. Manual de referencia de ScreenOS: Conceptos y ejemplos 124 Servidor de la base de datos de objetos de ataque 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 1 device(policy:1)-> set dst-address websrv2 device(policy:1)-> set service https device(policy:1)-> set attack CRITICAL:HTTP:SIGS action close-server device(policy:1)-> set attack HIGH:HTTP:ANOM action drop device(policy:1)-> set attack HIGH:HTTP:SIGS action close-server device(policy:1)-> exit device-> 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 predefinidas La 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.
  • 139. Servidor de la base de datos de objetos de ataque 125 Capítulo 5: Deep Inspection 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 firmas Juniper 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
  • 140. Manual de referencia de ScreenOS: Conceptos y ejemplos 126 Servidor de la base de datos de objetos de ataque “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 ataque Debe 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.
  • 141. Servidor de la base de datos de objetos de ataque 127 Capítulo 5: Deep Inspection Actualización inmediata La 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: Client Haga clic en el botón Update Now. CLI set attack db sigpack client exec attack-db update Loading attack database............. Done. Done. Switching attack database...Done Saving attack database to flash...Done. Actualización automática La 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. 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ón Dispositivo de seguridad local Base de datos de objetos de ataque
  • 142. Manual de referencia de ScreenOS: Conceptos y ejemplos 128 Servidor de la base de datos de objetos de ataque 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: Servidor Update Mode: Automatic Update Schedule: Weekly on: Monday Time (hh:mm): 04:00 CLI set attack db sigpack server set attack db mode update set attack db schedule weekly monday 04:00 save S M T W T F S Dispositivo de seguridad local 1. 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 Servidor de la base de datos de objetos de ataque Base de datos de objetos de ataque 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.
  • 143. Servidor de la base de datos de objetos de ataque 129 Capítulo 5: Deep Inspection Notificación automática y actualización inmediata Las 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 datos Configuration > Update > Attack Signature: Introduzca los siguientes datos y haga clic en OK: Signature Pack: Client Update Mode: Automatic Notification Schedule: Daily Time (hh:mm): 07:00 S M T W T F S Dispositivo de seguridad local 1. 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 Servidor de la base de datos de objetos de ataque Base de datos de objetos de ataque
  • 144. Manual de referencia de ScreenOS: Conceptos y ejemplos 130 Servidor de la base de datos de objetos de ataque 2. Actualización inmediata de la base de datos Cuando reciba un aviso de que la base de datos de ataques del servidor está más actualizada que la del dispositivo de seguridad, realice lo siguiente: Configuration > Update > Attack Signature Signature pack: Client Haga clic en el botón Update Now. CLI 1. Comprobación programada de la base de datos set attack db sigpack client set attack db mode notification set attack db schedule daily 07:00 2. Actualización inmediata de la base de datos Cuando reciba un aviso de que la base de datos de ataques del servidor está más actualizada que la del dispositivo de seguridad, realice lo siguiente: exec attack-db update Actualización manual La 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:netscreenattacks-db” (si desea utilizar WebUI para cargar la base de datos) o en C:Archivos de ProgramaTFTP 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.
  • 145. Servidor de la base de datos de objetos de ataque 131 Capítulo 5: Deep Inspection 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?s n=0043012001000213 Figura 49: Actualización manual de firmas de DI 1. Descarga del paquete de firmas Para 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?s n=0043012001000213 Guarde el archivo attacks.bin en el directorio local “C:netscreenattacks-db” (para cargar a través de WebUI) o en el directorio “C:Archivos de programaTFTP 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:netscreenattacks-dbattacks.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:netscreenattacks-db C:Archivos de programaTFTP Server Base de datos de objetos de ataque URL = https://services.netscreen.com/ /restricted/sigupdates/5.4/ns200/attacks .bin?sn=0043012001000213 Servidor de la base de datos de objetos de ataque Base de datos de objetos de ataque 2. Actualización manual de la base de datos
  • 146. Manual de referencia de ScreenOS: Conceptos y ejemplos 132 Objetos de ataque y grupos 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 websrv1 1.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 ORIG 1.1.1.3 1.2.2.5 IP DEST PTO ORIG 25611 80 PTO DEST PROTO HTTP Zona DMZ Dispositivo de seguridad revlog/. *revlog/.* /phorum/plugin/replace/pluring.php?*p .*%255(c|C).* .*[.asp::$data].*
  • 147. Objetos de ataque y grupos 133 Capítulo 5: Deep Inspection 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 grp1 set group service grp1 add smtp set group service grp1 add pop3 set policy id 2 from trust to untrust any any grp1 permit attack CRIT:SMTP:SIGS action close set policy id 2 attack CRIT:POP3:SIGS action close Protocolos admitidos El 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 Protocolo Firmas 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
  • 148. Manual de referencia de ScreenOS: Conceptos y ejemplos 134 Objetos de ataque y grupos 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. Protocolo Firmas completas Anomalía en el protocolo Definición
  • 149. Objetos de ataque y grupos 135 Capítulo 5: Deep Inspection 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. Protocolo Firmas completas Anomalía en el protocolo Definición Protocolo Firmas completas Anomalía en el protocolo Definición 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. Protocolo Firmas completas Anomalía en el protocolo Definición 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.
  • 150. Manual de referencia de ScreenOS: Conceptos y ejemplos 136 Objetos de ataque y grupos 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.html http://help.juniper.net/sigupdates/english/DNS.html http://help.juniper.net/sigupdates/english/FTP.html http://help.juniper.net/sigupdates/english/GNUTELLA.html http://help.juniper.net/sigupdates/english/HTTP.html http://help.juniper.net/sigupdates/english/IMAP.html http://help.juniper.net/sigupdates/english/MSN.html http://help.juniper.net/sigupdates/english/NBDS.html http://help.juniper.net/sigupdates/english/NBNAME.html http://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. Protocolo Firmas completas Anomalía en el protocolo Definición NOTA: Varias de las aplicaciones de P2P enumeradas, utilizan sus propios protocolos patentados. Protocolo Firmas completas Anomalía en el protocolo Definición MSRPC Sí Sí MSRPC (llamada del procedimiento remoto de Microsoft) es un mecanismo que se utiliza para llevar a cabo procesos en equipos remotos.
  • 151. Objetos de ataque y grupos 137 Capítulo 5: Deep Inspection http://help.juniper.net/sigupdates/english/SMTP.html http://help.juniper.net/sigupdates/english/MSRPC.html http://help.juniper.net/sigupdates/english/SMB.html http://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 completas Una 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.
  • 152. Manual de referencia de ScreenOS: Conceptos y ejemplos 138 Objetos de ataque y grupos 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 TCP Como 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 protocolo Los 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.
  • 153. Objetos de ataque y grupos 139 Capítulo 5: Deep Inspection Grupos de objetos de ataque Los grupos de objetos de ataque predefinidos contienen los objetos de ataque para un protocolo específico. Por cada protocolo, los grupos se dividen en anomalías de protocolos y firmas completas, y luego se organizan 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.
  • 154. Manual de referencia de ScreenOS: Conceptos y ejemplos 140 Objetos de ataque y grupos Cambio de los niveles de gravedad Aunque 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úmero device(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
  • 155. Objetos de ataque y grupos 141 Capítulo 5: Deep Inspection CLI device-> set policy id número device(policy:número)-> unset di-severity Ejemplo: Deep Inspection para P2P En 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 Destination 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.
  • 156. Manual de referencia de ScreenOS: Conceptos y ejemplos 142 Objetos de ataque y grupos > 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: Default Group: HIGH:HTTP:SIGS Action: Close Client Log: (seleccione) Severity: Default Group: INFO:GNUTELLA:ANOM Action: Close Client Log: (seleccione) Severity: Default Group: INFO:HTTP:SIGS Action: Close Client Log: (seleccione) CLI set policy id 1 from trust to untrust any any dns permit attack HIGH:HTTP:SIGS action close-client set policy id 1 device(policy:1)-> set service gnutella device(policy:1)-> set service http device(policy:1)-> set attack INFO:GNUTELLA:ANOM action close-client device(policy:1)-> set attack INFO:HTTP:SIGS action close-client device(policy:1)-> exit save Desactivación de objetos de ataque Cuando 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.
  • 157. Acciones de ataque 143 Capítulo 5: Deep Inspection 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.
  • 158. Manual de referencia de ScreenOS: Conceptos y ejemplos 144 Acciones de ataque 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.
  • 159. Acciones de ataque 145 Capítulo 5: Deep Inspection Ejemplo: Acciones de ataque – Close Server, Close, Close Client En este ejemplo hay tres zonas: Trust, Untrust y DMZ. Suponga que ha terminado de analizar ataques y ha llegado a la conclusión de que necesita las tres directivas siguientes: 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. Ajuste de ataque para Directiva con ID 2: 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 Registro: Habilitado (ajuste predeterminado) 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.
  • 160. Manual de referencia de ScreenOS: Conceptos y ejemplos 146 Acciones de ataque Ajuste de ataque para Directiva con ID 3: 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 Client Registro: Habilitado (ajuste predeterminado) 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 1. Interfaces Network > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos, luego haga clic en Apply: Zone Name: Trust Static IP: (seleccione esta opción si es posible) IP Address/Netmask: 10.1.1.1/24 ethernet3 1.1.1.1/24 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 ethernet2 1.2.2.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
  • 161. Acciones de ataque 147 Capítulo 5: Deep Inspection Introduzca los siguientes datos y haga clic en OK: Interface Mode: NAT Service Options: Management Services: (seleccione todos) Other services: Ping Network > Interfaces > Edit (para ethernet3): Introduzca los siguientes datos y haga clic en OK: Zone Name: Untrust Static IP: (seleccione esta opción si es posible) IP Address/Netmask: 1.1.1.1/24 Network > Interfaces > Edit (para ethernet2): Introduzca los siguientes datos y haga clic en OK: Zone Name: DMZ Static IP: (seleccione esta opción si es posible) IP Address/Netmask: 1.2.2.1/24 2. Direcciones Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK: Address Name: websrv1 IP Address/Domain Name: IP/Netmask: (seleccione), 1.2.2.5/32 Zone: DMZ Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK: Address Name: websrv2 IP Address/Domain Name: IP/Netmask: (seleccione), 1.2.2.6/32 Zone: DMZ 3. Ruta Network > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK: Network Address/Netmask: 0.0.0.0/0 Gateway: (seleccione) Interface: ethernet3 Gateway IP Address: 1.1.1.250 4. ID de directiva 1 Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK: Source Address: Address Book Entry: (seleccione), Any Destination Address: Address Book Entry: (seleccione), websrv1
  • 162. Manual de referencia de ScreenOS: Conceptos y ejemplos 148 Acciones de ataque > 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 > 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: Group: CRITICAL:HTTP:ANOM Action: Close Server Log: (seleccione) Group: CRITICAL:HTTP:SIGS Action: Close Server Log: (seleccione) Group: HIGH:HTTP:ANOM Action: Close Server Log: (seleccione) Group: HIGH:HTTP:SIGS Action: Close Server Log: (seleccione) Group: MEDIUM:HTTP:ANOM Action: Close Server Log: (seleccione) Group: MEDIUM:HTTP:SIGS Action: Close Server Log: (seleccione) Group: CRITICAL:FTP:SIGS Action: Close Server Log: (seleccione) 5. ID de directiva 2 Policies > (From: Trust, 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), 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 > 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
  • 163. Acciones de ataque 149 Capítulo 5: Deep Inspection > 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: Group: CRITICAL:HTTP:ANOM Action: Close Log: (seleccione) Group: CRITICAL:HTTP:SIGS Action: Close Log: (seleccione) Group: HIGH:HTTP:ANOM Action: Close Log: (seleccione) Group: HIGH:HTTP:SIGS Action: Close Log: (seleccione) Group: MEDIUM:HTTP:ANOM Action: Close Log: (seleccione) Group: MEDIUM:HTTP:SIGS Action: Close Log: (seleccione) Group: CRITICAL:FTP:SIGS Action: Close Log: (seleccione) 6. ID de directiva 3 Policies > (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: 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 > 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: Group: CRITICAL:HTTP:ANOM Action: Close Client Log: (seleccione) Group: CRITICAL:HTTP:SIGS Action: Close Client Log: (seleccione) Group: HIGH:HTTP:ANOM Action: Close Client Log: (seleccione) Group: HIGH:HTTP:SIGS Action: Close Client Log: (seleccione)
  • 164. Manual de referencia de ScreenOS: Conceptos y ejemplos 150 Acciones de ataque Group: MEDIUM:HTTP:ANOM Action: Close Client Log: (seleccione) Group: MEDIUM:HTTP:SIGS Action: Close Client Log: (seleccione) Group: CRITICAL:FTP:SIGS Action: Close Client Log: (seleccione) CLI 1. Interfaces set interface ethernet1 zone trust set interface ethernet1 ip 10.1.1.1/24 set interface ethernet1 manage set interface ethernet3 zone untrust set interface ethernet3 ip 1.1.1.1/24 set interface ethernet2 zone dmz set interface ethernet2 ip 2.1.1.1/24 2. Direcciones set address dmz websrv1 1.2.2.5/32 set address dmz websrv2 1.2.2.6/32 3. Ruta set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250 4. ID de directiva 1 set policy id 1 from untrust to dmz any websrv1 http permit attack CRITICAL:HTTP:ANOM action close-server set policy id 1 device(policy:1)-> set dst-address websrv2 device(policy:1)-> set service ftp-get device(policy:1)-> set service https device(policy:1)-> set service ping device(policy:1)-> set attack CRITICAL:HTTP:SIGS action close-server device(policy:1)-> set attack HIGH:HTTP:ANOM action close-server device(policy:1)-> set attack HIGH:HTTP:SIGS action close-server device(policy:1)-> set attack MEDIUM:HTTP:ANOM action close-server device(policy:1)-> set attack MEDIUM:HTTP:SIGS action close-server device(policy:1)-> set attack CRITICAL:FTP:SIGS action close-server device(policy:1)-> exit
  • 165. Acciones de ataque 151 Capítulo 5: Deep Inspection 5. ID de directiva 2 set policy id 2 from trust to dmz any websrv1 http permit attack CRITICAL:HTTP:ANOM action close set policy id 2 device(policy:2)-> set dst-address websrv2 device(policy:2)-> set service ftp device(policy:2)-> set service https device(policy:2)-> set service ping device(policy:2)-> set attack CRITICAL:HTTP:SIGS action close device(policy:2)-> set attack HIGH:HTTP:ANOM action close device(policy:2)-> set attack HIGH:HTTP:SIGS action close device(policy:2)-> set attack MEDIUM:HTTP:ANOM action close device(policy:2)-> set attack MEDIUM:HTTP:SIGS action close device(policy:2)-> set attack CRITICAL:FTP:SIGS action close device(policy:2)-> exit 6. ID de directiva 3 set policy id 3 from trust to untrust any any http permit attack CRITICAL:HTTP:ANOM action close-client set policy id 3 device(policy:3)-> set service ftp-get device(policy:3)-> set service https device(policy:3)-> set service ping device(policy:3)-> set attack CRITICAL:HTTP:SIGS action close-client device(policy:3)-> set attack HIGH:HTTP:ANOM action close-client device(policy:3)-> set attack HIGH:HTTP:SIGS action close-client device(policy:3)-> set attack MEDIUM:HTTP:ANOM action close-client device(policy:3)-> set attack MEDIUM:HTTP:SIGS action close-client device(policy:3)-> set attack CRITICAL:FTP:SIGS action close-client device(policy:3)-> exit save Acciones de ataques de fuerza bruta Un 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.
  • 166. Manual de referencia de ScreenOS: Conceptos y ejemplos 152 Acciones de ataque 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 bruta En 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 bruta Las 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
  • 167. Acciones de ataque 153 Capítulo 5: Deep Inspection Tabla 13: Opciones de destino Tiempo de espera de ataques de fuerza bruta El 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 1 En 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:ANOM GROUP "HIGH:HTTP:ANOM" está predefinido. Contiene los siguientes miembros ID 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 none device> set policy id 1 from Untrust to DMZ Any Any Any permit attack MEDIUM:HTTP:HIGH:SIGS action none device> set policy id 1 device(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)
  • 168. Manual de referencia de ScreenOS: Conceptos y ejemplos 154 Registro de ataques 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 2 En 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 3 En 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 ataque En 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
  • 169. Registro de ataques 155 Capítulo 5: Deep Inspection 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ón Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK: Address Name: mail1 IP Address/Domain Name: IP/Netmask: (seleccione), 1.2.2.10/32 Zone: DMZ 2. Directiva Policies > (From: Trust, 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), mail1 Service: IMAP Action: Permit > 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: Group: HIGH:IMAP:ANOM Action: Close Log: (seleccione) Group: HIGH:IMAP:SIGS Action: Close Log: (seleccione) Group: MEDIUM:IMAP:ANOM Action: Close Log: (anule la selección) Group: LOW:IMAP:ANOM Action: Close Log: (anule la selección) Group: INFO:IMAP:ANOM Action: Close Log: (anule la selección) CLI 1. Dirección set address dmz mail1 1.2.2.10/32
  • 170. Manual de referencia de ScreenOS: Conceptos y ejemplos 156 Asignación de servicios personalizados a aplicaciones 2. Directiva device-> set policy id 1 from trust to dmz any mail1 imap permit attack HIGH:IMAP:ANOM action close device-> set policy id 1 device(policy:1)-> set attack HIGH:IMAP:SIGS action close device(policy:1)-> set attack MEDIUM:IMAP:ANOM action close device(policy:1)-> unset attack MEDIUM:IMAP:ANOM logging device(policy:1)-> set attack LOW:IMAP:ANOM action close device(policy:1)-> unset attack LOW:IMAP:ANOM logging device(policy:1)-> set attack INFO:IMAP:ANOM action close device(policy:1)-> unset attack INFO:IMAP:ANOM logging device(policy:1)-> exit device-> 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-2121 set policy id 1 from untrust to trust any ftp-srv1 custom-ftp permit Sin embargo, si incluye un componente de DI en una directiva que haga referencia al servicio personalizado, el módulo 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.
  • 171. Asignación de servicios personalizados a aplicaciones 157 Capítulo 5: Deep Inspection 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 personalizado En 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: CRITICAL:HTTP:ANOM, CRITICAL:HTTP:SIGS HIGH:HTTP:ANOM, HIGH:HTTP:SIGS MEDIUM:HTTP:ANOM, MEDIUM:HTTP:SIGS Acción para todos los grupos de objetos de ataque: Close Server Registro: Habilitado (ajuste predeterminado) WebUI 1. Servicio personalizado Policy > Policy Elements > Services > Custom > New: Introduzca los siguientes datos y haga clic en OK: Service Name: HTTP1 Transport Protocol: TCP (seleccione) Source Port Low: 0 Source Port High: 65535 Destination Port Low: 8080 Destination Port High: 8080 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)
  • 172. Manual de referencia de ScreenOS: Conceptos y ejemplos 158 Asignación de servicios personalizados a aplicaciones 2. Dirección Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK: Address Name: servidor1 IP Address/Domain Name: IP Address/Netmask: 1.2.2.5/32 Zone: DMZ 3. Directiva Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK: Source Address: Address Book Entry: (seleccione), Any Destination Address: Address Book Entry: (seleccione), servidor1 Service: HTTP1 Application: HTTP Action: Permit > 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: Group: CRITICAL:HTTP:ANOM Action: Close Server Log: (seleccione) Group: CRITICAL:HTTP:SIGS Action: Close Client Log: (seleccione) Group: HIGH:HTTP:ANOM Action: Close Client Log: (seleccione) Group: HIGH:HTTP:SIGS Action: Close Client Log: (seleccione) Group: MEDIUM:HTTP:ANOM Action: Close Client Log: (seleccione) Group: MEDIUM:HTTP:SIGS Action: Close Client Log: (seleccione) CLI 1. Servicio personalizado set service HTTP1 protocol tcp src-port 0-65535 dst-port 8080-8080 2. Dirección set address dmz servidor1 1.2.2.5/32
  • 173. Asignación de servicios personalizados a aplicaciones 159 Capítulo 5: Deep Inspection 3. Directiva device-> set policy id 1 from untrust to dmz any servidor1 HTTP1 permit attack CRITICAL:HTTP:ANOM action close-server device-> set policy id 1 device(policy:1)-> set attack CRITICAL:HTTP:SIGS action close-server device(policy:1)-> set attack HIGH:HTTP:ANOM action close-server device(policy:1)-> set attack HIGH:HTTP:SIGS action close-server device(policy:1)-> set attack MEDIUM:HTTP:ANOM action close-server device(policy:1)-> set attack MEDIUM:HTTP:SIGS action close-server device(policy:1)-> exit device-> set policy id 1 application http save Ejemplo: Asignación de aplicación a servicio para ataques HTTP Algunos 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 personalizado Policy > Policy Elements > Services > Custom > New: Introduzca los siguientes datos y haga clic en OK: Service Name: HTTP2 Transport Protocol: TCP (seleccione) Source Port Low: 0 Source Port High: 65535 Destination Port Low: 8000 Destination 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.
  • 174. Manual de referencia de ScreenOS: Conceptos y ejemplos 160 Objetos de ataque y grupos personalizados 2. Directiva Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK: Source Address: Address Book Entry: (seleccione), Any Destination Address: Address Book Entry: (seleccione), Any Service: HTTP2 Application: HTTP Action: Permit > 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: Group: CRITICAL:HTTP:SIGS Action: Close Log: (seleccione) Group: MEDIUM:HTTP:SIGS Action: Close Log: (seleccione) CLI 1. Servicio personalizado set service HTTP2 protocol tcp src-port 0-65535 dst-port 8000-8000 2. Directiva device-> set policy id 1 from untrust to dmz any any HTTP2 permit attack CRITICAL:HTTP:SIGS action close device-> set policy id 1 device(policy:1)-> set attack MEDIUM:HTTP:SIGS action close device(policy:1)-> exit device-> set policy id 1 application http save 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 usuario Se puede crear un objeto de ataque de firma completa para FTP, HTTP y SMTP. Para crear un objeto de ataque, realice los pasos siguientes: Asigne un nombre el objeto de ataque. (Todos los objetos de ataque que define el usuario deben comenzar con “CS:”).
  • 175. Objetos de ataque y grupos personalizados 161 Capítulo 5: Deep Inspection 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 regulares Cuando 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 0162 Coincide con: 162 Coincidir exactamente con este número octal: 162 Coincidencia binaria directa (hexadecimal)2 Xnúmero_hexadecimalX X01 A5 00 00X Coincide 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 . t Coincide con: cat, cbt, cct, … czt cAt, cBt, cCt, … cZt c1t, c2t, c3t, … c9t Busca c, cualquier carácter, t
  • 176. Manual de referencia de ScreenOS: Conceptos y ejemplos 162 Objetos de ataque y grupos personalizados Buscar el carácter anterior cero o más veces, en lugar de sólo una vez. * a*b+c Coincide 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+c Coincide 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-?packet Coincide 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
  • 177. Objetos de ataque y grupos personalizados 163 Capítulo 5: Deep Inspection Ejemplo: Objetos de ataque de firma completa que define un usuario En 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-stor Objects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK: Attack Name: cs:ftp-stor Attack Context: FTP Command Attack Severity: Medium Attack Pattern: STOR 2. Objeto de ataque 2: ftp-user-dm Objects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK: Attack Name: cs:ftp-user-dm Attack Context: FTP User Name Attack Severity: Low Attack Pattern: dmartin 3. Objeto de ataque 3: url-index Objects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK: Attack Name: cs:url-index Attack Context: HTTP URL Parsed Attack Severity: High Attack 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”
  • 178. Manual de referencia de ScreenOS: Conceptos y ejemplos 164 Objetos de ataque y grupos personalizados 4. Objeto de ataque 4: spammer Objects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK: Attack Name: cs:spammer Attack Context: SMTP From Attack Severity: Info Attack Pattern: .*@spam.com 5. Grupo de objetos de ataque Objects > Attacks > Custom Groups > New: Introduzca el siguiente nombre de grupo, mueva los siguientes objetos de ataque personalizados y 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. 6. Directiva Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK: Source Address: Address Book Entry: (seleccione), Any Destination Address: Address Book Entry: (seleccione), Any 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 > 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: Group: CS:DMZ DI Action: Close Server Log: (seleccione)
  • 179. Objetos de ataque y grupos personalizados 165 Capítulo 5: Deep Inspection CLI 1. Objeto de ataque 1: ftp-stor set attack cs:ftp-stor ftp-command STOR severity medium 2. Objeto de ataque 2: ftp-user-dm set attack cs:ftp-user-dm ftp-username dmartin severity low 3. Objeto de ataque 3: url-index set attack cs:url-index http-url-parsed index.html severity high 4. Objeto de ataque 4: spammer set attack cs:spammer smtp-from .*@spam.com severity info 5. Grupo de objetos de ataque set attack group “CS:DMZ DI” set attack group “CS:DMZ DI” add cs:ftp-stor set attack group “CS:DMZ DI” add cs:ftp-user-dm set attack group “CS:DMZ DI” add cs:url-index set attack group “CS:DMZ DI” add cs:spammer 6. Directiva set policy id 1 from untrust to dmz any any http permit attack “CS:DMZ DI” action close-server set policy id 1 device(policy:1)-> set service ftp device(policy:1)-> exit save Objetos de ataque de la firma de la secuencia de TCP Las firmas completas dependen de los contextos de aplicaciones específicas, como un nombre de usuario de FTP o un campo de encabezado de SMTP. Las firmas de la secuencia 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.
  • 180. Manual de referencia de ScreenOS: Conceptos y ejemplos 166 Objetos de ataque y grupos personalizados 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 usuario En este ejemplo definirá el objeto de firma de secuencia “.*satori.*”. Definirá su nombre como “CS:A1” y su nivel de gravedad como crítico. Debido a que una directiva puede hacer referencia solamente a grupos de objetos de ataque, creará un grupo llamado “CS:Gr1” y luego le agregará este objeto. Finalmente, definirá una directiva que haga referencia a CS:Gr1 y que ordene al dispositivo 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 secuencia Objects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK: Attack Name: CS:A1 Attack Context: Stream Attack Severity: Critical Attack Pattern: .*satori.* 2. Grupo de objetos de ataque de firma de secuencia Objects > Attacks > Custom Groups > New: Introduzca los siguientes datos y haga clic en OK: Group Name: CS:Gr1 Seleccione CS:A1 en la columna Available Members y haga clic en << para moverlo a la columna Selected Members. 3. Directiva Policies > (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: ANY Action: Permit set attack "CS:A1" stream ".*satori.*" severity critical Nombre Tipo Definición Nivel de gravedad
  • 181. Objetos de ataque y grupos personalizados 167 Capítulo 5: Deep Inspection > 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: Group: CS:Gr1 Action: Close Client Log: (seleccione) CLI 1. Objeto de ataque de firma de secuencia set attack “CS:A1” stream “.*satori.*” severity critical 2. Grupo de ataques de firma de secuencia set attack group “CS:Gr1” set attack group “CS:Gr1” add “CS:A1” 3. Directiva set policy from trust to untrust any any any permit attack CS:Gr1 action close-client save Parámetros configurables de anomalías en protocolos Es 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ámetros En 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 protocolo Valor 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
  • 182. Manual de referencia de ScreenOS: Conceptos y ejemplos 168 Negación 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 8 set di service gnutella max_ttl_hops 10 set di service aim max_flap_length 5000 set di service aim max_oft_frame 5000 save 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 ataque En 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 protocolo Valor 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.
  • 183. Negación 169 Capítulo 5: Deep Inspection 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.
  • 184. Manual de referencia de ScreenOS: Conceptos y ejemplos 170 Negación Figura 55: Negación de objeto de ataque WebUI 1. Interfaces Network > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos, luego haga clic en Apply: Zone Name: Trust Static 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) Network > Interfaces > Edit (para ethernet2): Introduzca los siguientes datos y haga clic en OK: Zone Name: DMZ Static IP: (seleccione esta opción si es posible) IP Address/Netmask: 1.2.2.1/24 Network > Interfaces > Edit (para ethernet3): Introduzca los siguientes datos y haga clic en OK: Zone Name: Untrust Static IP: (seleccione esta opción si es posible) IP Address/Netmask: 1.1.1.1/24 ethernet2 1.2.2.1/24 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 ethernet3 1.1.1.1/24 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: anon Contraseñ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.
  • 185. Negación 171 Capítulo 5: Deep Inspection 2. Dirección Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK: Address Name: ftp1 IP Address/Domain Name: IP/Netmask: (seleccione), 1.2.2.5/32 Zone: DMZ 3. Objeto de ataque 1: CS:FTP1_USR_OK Objects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK: Attack Name: CS:FTP1_USR_OK Attack Context: ftp-username Attack Severity: High Attack Pattern: admin1 Pattern Negation: (seleccione) 4. Objeto de ataque 2: CS:FTP1_PASS_OK Objects > Attacks > Custom > New: Introduzca los siguientes datos y haga clic en OK: Attack Name: CS:FTP1_PASS_OK Attack Context: ftp-password Attack Severity: High Attack Pattern: pass1 Pattern Negation: (seleccione) 5. Grupo de objetos de ataque Objects > Attacks > Custom Groups > New: Introduzca el siguiente nombre de grupo, mueva los siguientes objetos de ataque personalizados y 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. Ruta Network > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK: Network Address/Netmask: 0.0.0.0/0 Gateway: (seleccione) Interface: ethernet3 Gateway IP Address: (seleccione) 1.1.1.250
  • 186. Manual de referencia de ScreenOS: Conceptos y ejemplos 172 Negación 7. Directivas Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK: Source Address: Address Book Entry: (seleccione), Any Destination Address: Address Book Entry: (seleccione), ftp1 Service: FTP Action: Permit > 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: Group: CS:FTP1_LOGIN Action: Drop Log: (seleccione) Policies > (From: Trust, 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), ftp1 Service: FTP Action: Permit > 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: Group: CS:FTP1_LOGIN Action: Drop Log: (seleccione) CLI 1. Interfaces set interface ethernet1 zone trust set interface ethernet1 ip 10.1.1.1/24 set interface ethernet1 nat set interface ethernet2 zone dmz set interface ethernet2 ip 1.2.2.1/24 set interface ethernet3 zone untrust set interface ethernet3 ip 1.1.1.1/24 2. Dirección set address dmz ftp1 1.2.2.5/32 3. Objetos de ataque set attack CS:FTP1_USR_OK ftp-username not admin1 severity high set attack CS:FTP1_PASS_OK ftp-password not pass1 severity high set attack group CS:FTP1_LOGIN set attack group CS:FTP1_LOGIN add CS:FTP1_USR_OK set attack group CS:FTP1_LOGIN add CS:FTP1_PASS_OK
  • 187. Bloqueo granular de los componentes de HTTP 173 Capítulo 5: Deep Inspection 4. Ruta set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250 5. Directivas set 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 drop save Bloqueo granular de los componentes de HTTP 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 ActiveX La 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.
  • 188. Manual de referencia de ScreenOS: Conceptos y ejemplos 174 Bloqueo granular de los componentes de HTTP 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 Java Con 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 EXE En 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 ZIP Un archivo ZIP (es decir, un archivo con la extensión .zip), es un tipo de archivo que contiene unos o más archivos comprimidos. El peligro de descargar un archivo “.exe” como el presentado en la sección anterior que trata sobre archivos “.exe” también puede aplicarse a los archivos “.zip”, ya que éstos pueden contener archivos “.exe”. Ejemplo: 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 jar set zone untrust screen component-block exe save
  • 189. 175 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
  • 190. Manual de referencia de ScreenOS: Conceptos y ejemplos 176 Dispositivos de seguridad con capacidad para IDP 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.
  • 191. Configuración de la detección y prevención de intrusiones 177 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 FLA SH PW R FA N A LA RM M O D 1 TEM P M O D 2 STATU 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 Módulo de seguridad Módulo de seguridad Se crea la sesión y el paquete sale del dispositivo Flujo de tráfico
  • 192. Manual de referencia de ScreenOS: Conceptos y ejemplos 178 Configuración de la detección y prevención de intrusiones Tareas de configuración previa Antes 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 IDP En 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
  • 193. Configuración de la detección y prevención de intrusiones 179 Capítulo 6: Detección y prevención de intrusiones 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 policy Total regular policies 5, Default deny. ID From To Src-address Dst-address Service Action State ASTLCB 9 Trust Untrust Any Any MAIL Permit enabled ---X-X 4 blade1 dmz2 Any Any ANY Permit enabled ---X-X 6 dmz2 blade1 Any Any ANY Permit enabled ---X-X 10 Untrust Trust Any MIP(172.24.~ HTTP Permit enabled ---X-X HTTPS device-> get policy id 4 name:"none" (id 4), zone blade1 -> dmz2,action Permit, status "enable src "Any", dst "Any", serv "ANY" Policies on this vpn tunnel: 0 nat off, Web filtering : disabled vpn unknown vpn, policy flag 00010000, session backup: on policy IDP mode : disable traffic shapping off, scheduler n/a, serv flag 00 log yes, log count 0, alert no, counter no(0) byte rate(sec/min) 0/0 total octets 0, counter(session/packet/octet) 0/0/0 No Authentication No User, User Group or Group expression set device-> set policy id 4 device (policy:4)-> set idp device (policy:4)-> exit device-> get policy id 4 policy 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.
  • 194. Manual de referencia de ScreenOS: Conceptos y ejemplos 180 Configuración de la detección y prevención de intrusiones 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 status SM CPU aval ena Sess_cnt 1 1 1 10 2 1 1 8 3 0 1 0 4 0 1 0 5 0 1 0 6 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 Módulo de seguridad 2 Módulo de seguridad 3
  • 195. Configuración de la detección y prevención de intrusiones 181 Capítulo 6: Detección y prevención de intrusiones 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, pasivo En 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 FLA SH PW R FA N A LA RM M O D 1 TEM P M O D 2 STATU S M O D 3 ISG 2000 H A FLA SH PW R FA N A LA RM M O D 1 TEM P M O D 2 STATU 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 IDVSD0 Dispositivo B (respaldo) Dispositivo A (maestro)
  • 196. Manual de referencia de ScreenOS: Conceptos y ejemplos 182 Configuración de la detección y prevención de intrusiones 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.
  • 197. Configuración de la detección y prevención de intrusiones 183 Capítulo 6: Detección y prevención de intrusiones set nsrp rto-mirror sync set nsrp monitor interface ethernet1 set nsrp monitor interface ethernet3 set nsrp cluster id 0 save 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, activo En 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.
  • 198. Manual de referencia de ScreenOS: Conceptos y ejemplos 184 Configuración de la detección y prevención de intrusiones 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. HA FLASH PW R FAN ALARM M O D1 TEM P M O D2 STATUS M O D3 ISG 2000 HA FLASH PW R FAN ALARM M O D1 TEM P M O D2 STATUS M O D3 ISG 2000 Zona Untrust Dispositivos de seguridad Zona Trust Internet Dispositivo A Dispositivo B FTP-Srv1 Cambio en caso de fallo activo/activo IDVSD0 Dispositivo B (respaldo) Dispositivo A (maestro) IDVSD1 Dispositivo A (maestro) Dispositivo A (respaldo) NOTA: Recomendamos que instale el mismo número de módulos de seguridad en ambos dispositivos.
  • 199. Configuración de directivas de seguridad 185 Capítulo 6: Detección y prevención de intrusiones 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 A set nsrp vsd-group id 0 priority 1 set nsrp vsd-group id 0 preempt hold-down 10 set nsrp vsd-group id 0 preempt set nsrp vsd-group id 1 save Dispositivo B set nsrp vsd-group id 1 priority 1 set nsrp vsd-group id 1 preempt hold-down 10 set nsrp vsd-group id 1 preempt save 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.
  • 200. Manual de referencia de ScreenOS: Conceptos y ejemplos 186 Configuración de directivas de seguridad Acerca de las directivas de seguridad Cada 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 seguridad Dentro 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 seguridad Despué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.
  • 201. Uso de las bases de normas de IDP 187 Capítulo 6: Detección y prevención de intrusiones 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.
  • 202. Manual de referencia de ScreenOS: Conceptos y ejemplos 188 Uso de las bases de normas de IDP Administración de las bases de normas de IDP según roles La 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.
  • 203. Habilitación de IDP en las normas de cortafuegos 189 Capítulo 6: Detección y prevención de intrusiones Uso de las plantillas de directivas de seguridad Al 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.
  • 204. Manual de referencia de ScreenOS: Conceptos y ejemplos 190 Habilitación de IDP en las normas de cortafuegos Figura 60: Cuadro de diálogo DI Profile/Enable IDP Habilitación de IDP De 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ínea IDP 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.
  • 205. Configuración de las normas de IDP 191 Capítulo 6: Detección y prevención de intrusiones 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.
  • 206. Manual de referencia de ScreenOS: Conceptos y ejemplos 192 Configuración de las normas de IDP 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 IDP Antes 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
  • 207. Configuración de las normas de IDP 193 Capítulo 6: Detección y prevención de intrusiones 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 coincidente Al 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.
  • 208. Manual de referencia de ScreenOS: Conceptos y ejemplos 194 Configuración de las normas de IDP Zonas de origen y de destino Puede 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 destino En 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 destino Desea 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.
  • 209. Configuración de las normas de IDP 195 Capítulo 6: Detección y prevención de intrusiones Ejemplo: Establecimiento de múltiples orígenes y destinos Desea detectar ataques entre dos redes. Seleccione múltiples objetos de dirección para el origen y destino. Su norma se parece al ejemplo que se muestra en la Figura 65. 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. Servicios Los 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.
  • 210. Manual de referencia de ScreenOS: Conceptos y ejemplos 196 Configuración de las normas de IDP Ejemplo: Establecimiento de los servicios predeterminados Desea 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. Su norma se parece al ejemplo que se muestra en la Figura 66. Figura 66: Establecimiento de servicios predeterminados Ejemplo: Establecimiento de servicios específicos Su 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. Su norma se parece al ejemplo que se muestra en la Figura 67. 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ándar Utilizará 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.
  • 211. Configuración de las normas de IDP 197 Capítulo 6: Detección y prevención de intrusiones 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. Su norma se parece al ejemplo que se muestra en la Figura 69. 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.
  • 212. Manual de referencia de ScreenOS: Conceptos y ejemplos 198 Configuración de las normas de IDP Normas definitivas El 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 definitivas En 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.
  • 213. Configuración de las normas de IDP 199 Capítulo 6: Detección y prevención de intrusiones 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 acciones Puede 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.
  • 214. Manual de referencia de ScreenOS: Conceptos y ejemplos 200 Configuración de las normas de IDP 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 ataque Los 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.
  • 215. Configuración de las normas de IDP 201 Capítulo 6: Detección y prevención de intrusiones 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 individualmente La 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ía Los 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 servicio Dependerá 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 operativo Los 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.
  • 216. Manual de referencia de ScreenOS: Conceptos y ejemplos 202 Configuración de las normas de IDP Adición de objetos de ataque por gravedad IDP 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 IP La 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 Packet Drop Connection Logging Alert 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 Packet Drop Connection Logging Alert 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
  • 217. Configuración de las normas de IDP 203 Capítulo 6: Detección y prevención de intrusiones 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 IP Para 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 bloqueo Cada 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 registro Cuando 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 espera Puede 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.
  • 218. Manual de referencia de ScreenOS: Conceptos y ejemplos 204 Configuración de las normas de IDP Establecimiento de la notificación La 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 registros En 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 alerta En 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 registro Puede 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.
  • 219. Configuración de las normas de exclusión 205 Capítulo 6: Detección y prevención de intrusiones Establecimiento de la gravedad La 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 objetivos Para 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 comentarios Puede 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.
  • 220. Manual de referencia de ScreenOS: Conceptos y ejemplos 206 Configuración de las normas de exclusión 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ón Antes 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.
  • 221. Configuración de las normas de exclusión 207 Capítulo 6: Detección y prevención de intrusiones 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 coincidencia Especifique 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 destino Puede 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. 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.
  • 222. Manual de referencia de ScreenOS: Conceptos y ejemplos 208 Configuración de las normas de exclusión Objetos de dirección de origen y de destino En 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/destino Para 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 ataque El 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íficos Constantemente 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:
  • 223. Configuración de las normas de exclusión 209 Capítulo 6: Detección y prevención de intrusiones Figura 75: Exclusión de un objeto de ataque Establecimiento de objetivos Para 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 comentarios Puede 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 registros Tambié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.
  • 224. Manual de referencia de ScreenOS: Conceptos y ejemplos 210 Configuración de las normas de puerta de atrás 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.
  • 225. Configuración de las normas de puerta de atrás 211 Capítulo 6: Detección y prevención de intrusiones 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ás Antes 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.
  • 226. Manual de referencia de ScreenOS: Conceptos y ejemplos 212 Configuración de las normas de puerta de atrás Figura 78: Norma de puerta de atrás agregada Definición de una coincidencia Especificará 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 destino Puede 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 destino En 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. 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.
  • 227. Configuración de las normas de puerta de atrás 213 Capítulo 6: Detección y prevención de intrusiones 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. Servicios Seleccione 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 funcionamiento Establezca 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 acciones Utilice 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.
  • 228. Manual de referencia de ScreenOS: Conceptos y ejemplos 214 Configuración de las normas de puerta de atrás Establecimiento de la notificación La 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 registros En 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 alerta En 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 registro Puede 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.
  • 229. Configuración de los objetos de ataque de IDP 215 Capítulo 6: Detección y prevención de intrusiones 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 gravedad Puede 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 objetivos Para 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 comentarios Puede 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.
  • 230. Manual de referencia de ScreenOS: Conceptos y ejemplos 216 Configuración de los objetos de ataque de IDP Acerca de los tipos de objeto de ataque de IDP En 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 firma Una 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 protocolo Los 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 compuestos Un 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.
  • 231. Configuración de los objetos de ataque de IDP 217 Capítulo 6: Detección y prevención de intrusiones Visualización de grupos y objetos de ataque de IDP predefinidos Juniper 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 predefinidos La 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.
  • 232. Manual de referencia de ScreenOS: Conceptos y ejemplos 218 Configuración de los objetos de ataque de IDP Figura 79: Visualizador de ataques Visualización de grupos predefinidos La 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.
  • 233. Configuración de los objetos de ataque de IDP 219 Capítulo 6: Detección y prevención de intrusiones 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 personalizados Puede 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: 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 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.
  • 234. Manual de referencia de ScreenOS: Conceptos y ejemplos 220 Configuración de los objetos de ataque de IDP 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 firma Para 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.
  • 235. Configuración de los objetos de ataque de IDP 221 Capítulo 6: Detección y prevención de intrusiones 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.
  • 236. Manual de referencia de ScreenOS: Conceptos y ejemplos 222 Configuración de los objetos de ataque de IDP 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
  • 237. Configuración de los objetos de ataque de IDP 223 Capítulo 6: Detección y prevención de intrusiones 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
  • 238. Manual de referencia de ScreenOS: Conceptos y ejemplos 224 Configuración de los objetos de ataque de IDP 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. 4. Haga clic en Next. 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).
  • 239. Configuración de los objetos de ataque de IDP 225 Capítulo 6: Detección y prevención de intrusiones 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.
  • 240. Manual de referencia de ScreenOS: Conceptos y ejemplos 226 Configuración de los objetos de ataque de IDP 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 protocolo Realice 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
  • 241. Configuración de los objetos de ataque de IDP 227 Capítulo 6: Detección y prevención de intrusiones 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. 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 Finish. Creación de un ataque compuesto Observe 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.
  • 242. Manual de referencia de ScreenOS: Conceptos y ejemplos 228 Configuración de los objetos de ataque de IDP 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. 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.
  • 243. Configuración de los objetos de ataque de IDP 229 Capítulo 6: Detección y prevención de intrusiones 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.
  • 244. Manual de referencia de ScreenOS: Conceptos y ejemplos 230 Configuración de los objetos de ataque de IDP 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 personalizado Para 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 personalizado Para 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 personalizados El 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áticos Un 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
  • 245. Configuración de los objetos de ataque de IDP 231 Capítulo 6: Detección y prevención de intrusiones 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: 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 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.
  • 246. Manual de referencia de ScreenOS: Conceptos y ejemplos 232 Configuración de los objetos de ataque de IDP Configuración de grupos dinámicos Un 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: 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 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.
  • 247. Configuración de los objetos de ataque de IDP 233 Capítulo 6: Detección y prevención de intrusiones 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ámico Realice 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.
  • 248. Manual de referencia de ScreenOS: Conceptos y ejemplos 234 Configuración de los objetos de ataque de IDP 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ámicos Cuando 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).
  • 249. Configuración del dispositivo como un dispositivo IDP independiente 235 Capítulo 6: Detección y prevención de intrusiones Edición de un grupo de ataques personalizado Para 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 personalizado Para 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 IDP Para 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.
  • 250. Manual de referencia de ScreenOS: Conceptos y ejemplos 236 Configuración del dispositivo como un dispositivo IDP independiente 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 independiente En 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
  • 251. Configuración del dispositivo como un dispositivo IDP independiente 237 Capítulo 6: Detección y prevención de intrusiones Configuración de la administración basada en funciones La 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 IDP En 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.
  • 252. Manual de referencia de ScreenOS: Conceptos y ejemplos 238 Administración de IDP 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 ataques Juniper 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ó.
  • 253. Administración de IDP 239 Capítulo 6: Detección y prevención de intrusiones Descarga de las actualizaciones de la base de datos de ataques Las 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 actualizados No 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 IDP El 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.
  • 254. Manual de referencia de ScreenOS: Conceptos y ejemplos 240 Administración de IDP 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. 2. Haga clic en Next. 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.
  • 255. Administración de IDP 241 Capítulo 6: Detección y prevención de intrusiones 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 IDP Cuando 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.
  • 256. Manual de referencia de ScreenOS: Conceptos y ejemplos 242 Administración de IDP 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
  • 257. Fragmentos ICMP 243 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.
  • 258. Manual de referencia de ScreenOS: Conceptos y ejemplos 244 Paquetes ICMP grandes 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 Paquetes ICMP grandes 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 del encabezado Tiempo de vida (TTL) Identificación Tipo Código Identificador Encabezado ICMP (Carga del paquete IP) Datos Opciones Dirección de destino Dirección de origen Protocolo (ICMP = 1) Tipo de servicio Si el tipo de protocolo es 1 para ICMP... y el indicador de más fragmentos está activado... o hay un valor distinto de cero en el campo desplazamiento del fragmento... Longitud total del paquete (en bytes) Desplazamiento del fragmento Suma de comprobación del encabezado 0 D M Suma de comprobación Número de secuencia …el dispositivo de seguridad bloquea el paquete.
  • 259. Opciones IP incorrectas 245 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 del encabezado Tiempo de vida (TTL) Identificación Tipo Código Identificador Encabezado ICMP (Carga del paquete IP) Datos Opciones Dirección de destino Dirección de origen 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) Desplazamiento del fragmento Suma de comprobación del encabezado 0 D M Suma de comprobación Número de secuencia …el dispositivo de seguridad bloquea el paquete. Encabezado IP
  • 260. Manual de referencia de ScreenOS: Conceptos y ejemplos 246 Protocolos desconocidos 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 Protocolos desconocidos 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. Encabezado IP Versión Longitud del encabezado Tiempo de vida (TTL) Identificación Opciones Dirección de destino Dirección de origen Protocolo Tipo de servicio Longitud total del paquete (en bytes) Desplazamiento del fragmento Suma de comprobación del encabezado 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.
  • 261. Fragmentos de paquetes IP 247 Capítulo 7: Atributos de los paquetes sospechosos 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. Encabezado IP Versión Longitud del encabezado Tiempo de vida (TTL) Identificación Opciones Dirección de destino Dirección de origen Protocolo Tipo de servicio Longitud total del paquete (en bytes) Desplazamiento del fragmento Suma de comprobación del encabezado 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.
  • 262. Manual de referencia de ScreenOS: Conceptos y ejemplos 248 Fragmentos SYN 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. Encabezado IP Versión Longitud del encabezado Tiempo de vida (TTL) Identificación Opciones Dirección de destino Dirección de origen Protocolo Tipo de servicio Longitud total del paquete (en bytes) Desplazamiento del fragmento Suma de comprobación del encabezado 0 D M Carga de datos …el dispositivo de seguridad bloquea el paquete. Si el indicador de más fragmentos está activado... o hay un valor distinto de cero en el campo desplazamiento del fragmento...
  • 263. Fragmentos SYN 249 Capítulo 7: Atributos de los paquetes sospechosos 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 del encabezado Tiempo de vida (TTL) Identificación Número de puerto de origen de 16 bits Número de secuencia de 32 bits Tamaño de encabezado de 4 bits Encabezado ICMP Reservado (6 bits) Opciones (si las hay) Dirección de destino Dirección de origen Protocolo Tipo de servicio Longitud total del paquete (en bytes) Desplazamientodel fragmento Suma de comprobación del encabezado 0 D M Número de puerto de destino de 16 bits Encabezado IP Si el indicador de más fragmentos está activado... o hay un valor distinto de cero en el campo desplazamiento del fragmento... Número de reconocimiento de 32 bits Suma de comprobación de TCP 16 bits Opciones (si las hay) Datos (si los hay) Puntero urgente 16 bits Tamaño de ventana de 16 bits U R G A C K P S H R S T S Y N F I N …y el indicador SYN está activado… ...el dispositivo descarta el paquete.
  • 264. Manual de referencia de ScreenOS: Conceptos y ejemplos 250 Fragmentos SYN
  • 265. A-I 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.
  • 266. Manual de referencia de ScreenOS: Conceptos y ejemplos 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. Protocolo Contexto Descripción (Establece el contexto como…)
  • 267. A-III 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. Protocolo Contexto Descripción (Establece el contexto como…)
  • 268. Manual de referencia de ScreenOS: Conceptos y ejemplos A-IV
  • 269. Índice IX-I Índice A acciones de ataque............................................143 a 151 close........................................................................143 close client .............................................................144 close server............................................................143 drop ........................................................................144 drop packet............................................................144 ignore......................................................................144 none........................................................................144 Actualización del motor IDP.......................................239 Actualizaciones de la base de datos de ataques descargar................................................................239 introducción...........................................................238 Administración en base a funciones Bases de normas de IDP ......................................188 Configuración de un administrador sólo de IDP........................................................................237 agentes zombie........................................................29, 31 AIM................................................................................135 ALG..................................................................................59 análisis antivirus....................................................62 a 88 descompresión ........................................................92 extensiones de archivo...........................................93 FTP............................................................................73 goteo HTTP ..............................................................87 HTTP.........................................................................74 HTTP “keep-alive”...................................................86 IMAP .........................................................................76 MIME.........................................................................75 modo de fallo...........................................................85 POP3.........................................................................76 recursos de AV por cliente .....................................84 SMTP.........................................................................78 suscripción...............................................................81 análisis FIN.....................................................................16 anomalías en el protocolo ..........................................138 ALG .........................................................................136 Aplicaciones de mensajería inmediata...............135 Aplicaciones P2P...................................................135 configuración de parámetros...............................167 protocolos admitidos ..................................133 a 137 protocolos básicos de red.....................................133 applets Java, bloquear.................................................174 archivos exe, bloquear ................................................174 archivos zip, bloquear.................................................174 asignación de grandes cantidades de paquetes simultáneos de la tabla de sesiones .........................19 ataques asignación de grandes cantidades de paquetes simultáneos de la tabla de sesiones....................19 direcciones MAC desconocidas .............................43 DOS...................................................................29 a 56 etapas .........................................................................2 Fragmentos de paquetes IP .................................247 Fragmentos SYN....................................................248 ICMP fragmentos........................................................243 inundaciones ......................................................49 inundación de la tabla de sesiones .......................30 Inundaciones SYN ...........................................37 a 43 Inundaciones UDP...................................................51 objetivos comunes ....................................................1 opciones de detección y defensa ......................2 a 5 paquetes ICMP grandes........................................244 Ping of Death ...........................................................53 protocolos desconocidos ......................................246 Teardrop...................................................................54 terrestres ..................................................................52 WinNuke...................................................................55 B barrida de puertos ...........................................................9 barrido de direcciones ....................................................8 base de datos de objetos de ataque.................124 a 132 actualización automática..............................127, 128 actualización inmediata........................................127 actualización manual ............................................130 cambiar la URL predeterminada .........................130 notificación automática y actualización manual .................................................................129 Base de normas de exclusión Adición a una directiva de seguridad..................206 introducción...........................................................205 Base de normas de puerta de atrás Adición a una directiva de seguridad..................211 introducción...........................................................210 Bases de normas de IDP Adición a una directiva de seguridad..................192 Administración en base a funciones...................188 introducción...........................................................191
  • 270. IX-II Índice Manual de referencia de ScreenOS: Conceptos y ejemplos tipos........................................................................187 Bloque de mensajes del servidor Consulte SMB Bobinadora LPR...........................................................134 C Chargen ........................................................................133 claves de licencia actualización del patrón de ataques ...................122 modo avanzado.....................................................122 comprobación de SYN.................................... 16, 16 a 19 agujero de reconocimiento ....................................18 asignación de grandes cantidades de paquetes simultáneos de la tabla de sesiones ...................19 enrutamiento asimétrico........................................18 interrupción de sesión............................................18 controles ActiveX, bloqueo.........................................173 Cookies SYN...................................................................47 D DDoS...............................................................................29 Deep Inspection (DI)......................................... 140 a 165 acciones de ataque ..................................... 143 a 151 anomalías en el protocolo....................................138 base de datos de objetos de ataque.......... 124 a 132 cambio de gravedad .............................................140 claves de licencia ..................................................122 contexto ......................................................................I desactivar objetos de ataque ...............................142 expresiones regulares................................. 161 a 162 firmas completas ..................................................137 firmas de secuencias ............................................138 firmas personalizadas................................. 161 a 165 grupos de objetos de ataque................................139 introducción...........................................................120 negación de objetos de ataque............................168 objetos de ataque..................................................122 objetos de ataque personalizados.......................160 paquetes de firmas ...............................................124 registro de grupos de objetos de ataque ............154 servicios personalizados ............................ 156 a 160 volver a habilitar objetos de ataque....................143 Denegación de servicio véase DoS descompresión, análisis antivirus ...............................92 Detección y prevención de intrusión, definida........175 DHCP ............................................................................134 directivas contexto .................................................................124 sección central ................................................18, 123 Directivas de seguridad ..............................................185 Base de normas.....................................................186 Ejecución de bases de normas............................189 normas ...................................................................186 plantillas.................................................................189 Discard..........................................................................134 DNS ...............................................................................133 DoS asignación de grandes cantidades de paquetes simultáneos de la tabla de sesiones ...................19 ataque específico del sistema operativo.......53 a 56 cortafuegos ......................................................30 a 36 inundación de la tabla de sesiones .......................30 red.....................................................................37 a 52 DoS, ataques ..........................................................29 a 56 drop-no-rpf-route ...........................................................20 E Echo ..............................................................................134 Entradas de registros Habilitación en las normas IDP...........................241 establecimientos de conexión en tres pasos..............37 estado................................................................................3 firmas .....................................................................137 inspección..................................................................3 evasión....................................................................15 a 27 expiración dinámica..............................................33 a 35 exploits véase ataques expresiones regulares........................................161 a 162 extensiones de archivo, análisis de AV .......................93 F filtrado de contenido...........................................57 a 118 filtrado de paquetes dinámico .......................................3 filtrado de Web aplicar perfiles a directivas ..................................108 caché.......................................................................103 categorías de URL .................................................104 enrutamiento.........................................................116 estado del servidor................................................116 integrado................................................................101 mensaje de URL bloqueada .................................115 nombre del servidor SurfControl ........................113 nombre del servidor Websense ..........................113 perfiles....................................................................106 puerto del servidor SurfControl...........................113 puerto del servidor Websense.............................113 redirigir...................................................................110 servidores CPA de SurfControl ............................101 servidores de SurfControl.....................................102 servidores por vsys ...............................................112 SurfControl SCFP...................................................113 tiempo de espera de comunicaciones................114 tipo de mensaje de URL bloqueada ....................115 FIN sin indicador ACK...................................................14 Finger............................................................................134 firmas
  • 271. Índice IX-III Índice estado .....................................................................137 firmas de secuencias...................................................138 Fragmentos SYN..........................................................248 fuerza bruta acciones de ataque................................................151 G Gopher ..........................................................................134 grupos de objetos de ataque ......................................139 cambio de gravedad .............................................140 inicio sesión ...........................................................154 niveles de gravedad ..............................................139 que se aplican en directivas.................................132 URL de ayuda ........................................................136 grupos VSD...................................................................185 H HTTP “keep-alive”..............................................................86 bloqueo de componentes...........................173 a 174 goteo.........................................................................87 tiempo de espera de la sesión...............................34 I ICMP..............................................................................134 fragmentos.............................................................243 paquetes grandes ..................................................244 IDENT............................................................................134 IDP configuración básica.............................................178 Configuración de un dispositivo para IDP independiente .....................................................235 Configuración del modo en línea o tap en línea......................................................................190 Habilitación en una norma de cortafuegos........189 indicadores SYN y FIN activados.................................13 inicio sesión grupos de objetos de ataque................................154 inspecciones.....................................................................3 inundación de la tabla de sesiones..............................30 inundaciones ICMP .........................................................................49 SYN .............................................................37 a 43, 47 tabla de sesiones.....................................................30 UDP...........................................................................51 inundaciones de SYN-ACK-ACK a través de un servidor proxy............................................................................35 Inundaciones ICMP .......................................................49 Inundaciones SYN .................................................37 a 43 ataques .....................................................................37 Cookies SYN.............................................................47 descartar las direcciones MAC desconocidas ......43 tamaño de la cola....................................................42 tiempo de espera ....................................................42 umbral ......................................................................38 umbral de alarma....................................................41 umbral de ataque ....................................................40 umbral de destino ...................................................41 umbral de origen.....................................................41 IP fragmentos de paquetes.......................................247 IRC.................................................................................135 L Land Attack, ataques terrestres....................................52 LDAP..............................................................................134 límites de sesiones ................................................30 a 33 según su destino................................................31, 32 según su origen..................................................30, 32 Llamada de procedimiento remoto de Microsoft Consulte MS-RPC M Mensajería inmediata..................................................135 AIM..........................................................................135 IRC...........................................................................135 Mensajero Yahoo!..................................................135 MSN Messenger.....................................................135 Yahoo! Messenger.................................................135 Mensajería inmediata de America Online Consulte AIM Mensajero Yahoo! ........................................................135 Microsoft Network Instant Messenger Consulte MSN Instant Messenger MIME, análisis antivirus................................................75 modo de fallo .................................................................85 Modo en línea ..............................................................190 Modo tap en línea........................................................190 Modo transparente descartar las direcciones MAC desconocidas.......43 Modos de IDP...............................................................190 Motor IDP actualizar ................................................................239 MS RPC .........................................................................136 MSN Messenger ...........................................................135 N negación, Deep Inspection (DI)..................................168 NetBIOS ........................................................................136 NFS................................................................................134 NNTP.............................................................................134 normas de exclusión .........................................205 a 210 configuración .........................................................207 Configuración de las columnas de coincidencia.........................................................207 Configuración de los ataques...............................208 Configuración de objetivos...................................209 Configuración de zonas ........................................207
  • 272. IX-IV Índice Manual de referencia de ScreenOS: Conceptos y ejemplos Configuración del origen y destino.....................208 Configuración desde el visualizador de registros ...............................................................209 Normas de IDP ............................................................191 configuración.........................................................193 Configuración de acciones...................................199 Configuración de la gravedad del ataque...........205 Configuración de la notificación .........................204 Configuración de las acciones de IP ...................202 Configuración de las columnas de coincidencia ........................................................193 Configuración de los ataques ..............................200 Configuración de los servicios.............................195 Configuración de normas definitivas..................198 Configuración de objetivos ..................................205 Configuración de objetos de ataque de IDP ......188 configuración de objetos de dirección................188 Configuración de objetos de servicio..................188 Configuración del origen y destino.....................194 Introducción de comentarios ..............205, 209, 215 normas de puerta de atrás ............................... 210 a 215 Configuración de acciones...................................213 Configuración de la gravedad..............................215 Configuración de las columnas de coincidencia ........................................................212 Configuración de los servicios.............................213 Configuración de objetivos ..................................215 Configuración de zonas........................................212 Configuración del funcionamiento .....................213 Configuración del origen y destino.....................212 NSRP grupos VSD ............................................................185 NTP ...............................................................................134 O objetos objetos de ataque..................................................215 Objetos de ataque, anomalías de protocolo ......216 Objetos de ataque, creación personalizada .......219 Objetos de ataque, firma .....................................216 objetos AV tiempo de espera ....................................................91 objetos de ataque ...................................... 122, 132 a 138 anomalía del protocolo.........................................216 anomalías en el protocolo............................138, 167 desactivar...............................................................142 firma.......................................................................216 firmas completas ..................................................137 firmas de secuencias ............................................138 firmas de secuencias de TCP...............................165 fuerza bruta ...................................................151, 152 IDP..........................................................................188 introducción...........................................................215 negación.................................................................168 personalizados.......................................................219 volver a habilitar ...................................................143 Objetos de ataque IDP ................................................188 objetos de ataques de fuerza bruta ...........................152 opción de marca de tiempo de IP .........................11, 12 opción de seguridad IP ...........................................11, 12 opción IP de grabación de ruta..............................11, 12 opción IP de ID de secuencia.................................11, 12 opción IP de ruta de origen abierta...............11, 26 a 27 opción IP de ruta de origen estricta ..............11, 26 a 27 Opciones IP............................................................10 a 12 atributos ...........................................................10 a 11 formateadas incorrectamente .............................245 grabación de ruta ..............................................11, 12 ID de secuencia .................................................11, 12 marca de hora ...................................................11, 12 ruta de origen ..........................................................26 ruta de origen abierta...............................11, 26 a 27 ruta de origen estricta ..............................11, 26 a 27 seguridad............................................................11, 12 P P2P................................................................................135 BitTorrent...............................................................135 DC ...........................................................................135 eDonkey.................................................................136 FastTrack................................................................136 Gnutella ..................................................................136 KaZaa......................................................................136 MLdonkey ..............................................................136 Skype......................................................................136 SMB.........................................................................136 WinMX....................................................................136 paquetes de firmas, DI................................................124 Ping of Death .................................................................53 plantillas directiva de seguridad ..........................................189 Portmapper ..................................................................134 protección contra ataques nivel de directivas .....................................................5 nivel de zona de seguridad ......................................5 protección contra URL maliciosas .......................58 a 61 protocolos desconocidos ............................................246 Puerta de enlace en la capa de aplicación Véase ALG Punto a punto Consulte P2P R RADIUS.........................................................................134 reconocimiento........................................................7 a 27 análisis FIN...............................................................16 barrida de puertos.....................................................9 barrido de direcciones..............................................8
  • 273. Índice IX-V Índice indicadores SYN y FIN activados ..........................13 Opciones IP..............................................................10 paquete TCP sin indicadores .................................15 reensamblaje de fragmentos................................58 a 61 rexec..............................................................................134 RFC 1038, Opción de seguridad IP revisada................11 791, Internet Protocol.........................................11 791, protocolo de Internet...................................10 793, Protocolo de control de transmisión.............14 rlogin.............................................................................134 rsh..................................................................................134 RTSP ..............................................................................134 S SCREEN Ataques terrestres ...................................................52 Ataques WinNuke ...................................................55 barrida de puertos.....................................................9 barrido de direcciones..............................................8 descartar las direcciones MAC desconocidas ......43 FIN sin ACK..............................................................16 FIN sin indicador ACK, descartar..........................14 fragmentos de paquetes IP, bloquear.................247 fragmentos SYN, detectar ....................................248 ICMP fragmentos, bloquear ......................................243 indicadores SYN y FIN activados ..........................13 inundaciones de SYN-ACK-ACK a través de un servidor proxy.......................................................35 Inundaciones ICMP.................................................49 Inundaciones SYN...........................................37 a 43 Inundaciones UDP ..................................................51 opción IP de ruta de origen abierta, detectar ......27 opción IP de ruta de origen estricta, detectar .....27 opción IP de ruta de origen, rechazar ..................27 Opciones IP..............................................................10 opciones IP incorrectas, descartar......................245 paquete TCP sin indicadores, detectar.................15 paquetes ICMP grandes, bloquear ......................244 Ping of Death...........................................................53 protocolos desconocidos, descartar....................246 Simulación de IP .............................................20 a 25 Teardrop...................................................................54 zonas VLAN y MGT ...................................................3 servicios personalizados.......................................................156 Simulación de IP Capa 2.................................................................21, 24 Capa 3.................................................................20, 22 drop-no-rpf-route.....................................................20 simulación de IP ....................................................20 a 25 Sistema con capacidad para IDP ...............................176 sistemas operativos, sondeos de host para ........12 a 15 SMB NetBIOS..................................................................136 SNMPTRAP ...................................................................135 sondeo puertos abiertos.........................................................9 red...............................................................................8 sistemas operativos...........................................12, 15 SSH................................................................................135 SSL.................................................................................135 SurfControl ...........................................................101, 110 SYN, cookies...................................................................47 syslog.............................................................................135 T TCP firmas de secuencias.............................................165 paquete sin indicadores..........................................15 tiempos de espera de sesiones..............................34 Teardrop, ataques ..........................................................54 Telnet.............................................................................135 TFTP ..............................................................................135 tiempo de espera de la sesión HTTP .........................................................................34 tiempos de espera de sesiones TCP............................................................................34 UDP...........................................................................34 U UDP tiempos de espera de sesiones..............................34 umbral umbral inferior ........................................................33 umbral superior.......................................................33 umbral inferior...............................................................33 umbral superior .............................................................33 V Visualizador de registros Creación de una norma de exclusión .................209 VNC ...............................................................................135 W web, filtrado........................................................110 a 118 Whois ............................................................................135 WinNuke, ataques..........................................................55 Y Yahoo! Messenger........................................................135 Z zombie, agentes.......................................................29, 31
  • 274. IX-VI Índice Manual de referencia de ScreenOS: Conceptos y ejemplos