Volumen 1: Vista General: Conceptos Y Ejemplos Manual de Referencia de Screenos

Conceptos y ejemplos
Manual de referencia de ScreenOS
Volumen 1:
Vista general
Release 6.0.0, Rev. 02
Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Part Number: 530-017767-01-SP, Revision 02
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.
ii
Contenido
Volumen 1:
Vista general
Acerca del Manual de referencia de ScreenOS: conceptos y
ejemplos xlvii
Organización de los volúmenes.................................................................... xlix
Convenciones del documento ......................................................................... lv
Convenciones de la interfaz de usuario web ............................................ lvi
Convenciones de interfaz de línea de comandos ..................................... lvi
Convenciones de nomenclatura y conjuntos de caracteres ..................... lvii
Convenciones para las ilustraciones ...................................................... lviii
Asistencia y documentación técnica............................................................... lix
Índice maestro .......................................................................................................IX-I
Volumen 2:
Fundamentos
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 ....................................... x
Convenciones de nomenclatura y conjuntos de caracteres ....................... xi
Convenciones para las ilustraciones ........................................................ xii
Asistencia y documentación técnica.............................................................. xiii
Capítulo 1 Arquitectura de ScreenOS 1

Zonas de seguridad .......................................................................................... 2
Interfaces de zonas de seguridad ..................................................................... 3
Interfaces físicas ........................................................................................ 3
Subinterfaces............................................................................................. 3
Enrutadores virtuales ....................................................................................... 4
Directivas......................................................................................................... 5
Redes privadas virtuales................................................................................... 7
Sistemas virtuales ............................................................................................ 8
Secuencia de flujo de paquetes ...................................................................... 10
Tramas jumbo................................................................................................ 13
Ejemplo de arquitectura de ScreenOS ............................................................ 13
Ejemplo: (Parte 1) Empresa con seis zonas.............................................. 13
Ejemplo: (Parte 2) Interfaces para las seis zonas...................................... 15
Ejemplo: (Parte 3) Dos dominios de enrutamiento .................................. 18
Ejemplo: (Parte 4) Directivas ................................................................... 19
Contenido iii
Manual de referencia de ScreenOS: Conceptos y ejemplos
Capítulo 2 Zonas 25
Ver las zonas preconfiguradas........................................................................ 26
Zonas de seguridad ........................................................................................ 27
Zona Global ............................................................................................. 28
Opciones SCREEN ................................................................................... 28
Asociar una interfaz de túnel a una zona de túnel .......................................... 28
Configuración de zonas de seguridad y zonas de túnel .................................. 30
Creación de una zona .............................................................................. 30
Modificación de una zona........................................................................ 31
Eliminación de una zona ......................................................................... 32
Zonas de función ........................................................................................... 32
Capítulo 3 Interfaces 33
Tipos de interfaces......................................................................................... 33
Interfaces lógicas ..................................................................................... 33
Interfaces físicas ............................................................................... 34
Interfaces inalámbricas ..................................................................... 34
Interfaces de grupos en puente ......................................................... 34
Subinterfaces .................................................................................... 35
Interfaces agregadas ......................................................................... 35
Interfaces redundantes...................................................................... 35
Interfaces de seguridad virtuales ....................................................... 36
Interfaces de zonas de función ................................................................ 36
Interfaces de administración ............................................................. 36
Interfaces de alta disponibilidad........................................................ 36
Interfaces de túnel................................................................................... 37
Eliminación de interfaces de túnel ....................................................40
Visualización de interfaces ............................................................................. 41
Configuración de interfaces de la zona de seguridad...................................... 42
Asociación de una interfaz a una zona de seguridad................................ 43
Desasociación de una interfaz de una zona de seguridad ........................ 44
Direccionamiento de una interfaz de la zona de seguridad L3 ................. 45
Direcciones IP públicas ..................................................................... 45
Direcciones IP privadas..................................................................... 46
Direccionamiento de una interfaz ..................................................... 46
Modificar los ajustes de interfaz............................................................... 47
Creación de una subinterfaz en el sistema raíz ........................................ 48
Eliminación de una subinterfaz ............................................................... 49
Creación de una dirección IP secundaria........................................................ 49
Interfaces del sistema de respaldo .................................................................50
Configuración de una interfaz de respaldo............................................... 51
Configuración de una interfaz de respaldo de seguimiento de IP ...... 51
Configuración de una interfaz de respaldo de túnel-if .......................52
Configuración de una interfaz de respaldo de supervisión de rutas ... 56
Interfaces de bucle invertido (o “loopback”)................................................... 57
Creación de una interfaz de bucle invertido............................................. 58
Configuración de la interfaz de bucle invertido para la administración.... 58
Configuración de BGP en una interfaz de bucle invertido ........................ 58
Configuración de VSI en una interfaz de bucle invertido.......................... 59
Configuración de la interfaz de bucle invertido como interfaz de
origen ............................................................................................... 59
Cambios de estado de la interfaz ................................................................... 60
Supervisión de la conexión física ............................................................. 62
iv Contenido
Contenido
Seguimiento de direcciones IP.................................................................62

Supervisión de interfaces......................................................................... 67
Supervisión de dos interfaces............................................................ 68
Supervisión de un bucle de interfaces ............................................... 69
Supervisión de zonas de seguridad .......................................................... 72
Interfaces fuera de línea y flujo de tráfico ................................................ 73
Error en la interfaz de salida ............................................................. 74
Fallo en la interfaz de entrada........................................................... 75
Capítulo 4 Modos de las interfaces 79

Modo transparente......................................................................................... 79
Ajustes de zona ....................................................................................... 80
Zona VLAN........................................................................................ 80
Zonas de capa 2 predefinidas............................................................ 81
Reenvío de tráfico ................................................................................... 81
Opciones “unicast” desconocidas ............................................................ 82
Método de inundación ...................................................................... 83
Método ARP/Trace-Route .................................................................. 84
Configurar la interfaz VLAN1 para administración ............................ 87
Configuración del modo transparente ............................................... 89
Modo NAT...................................................................................................... 92
Tráfico NAT entrante y saliente ............................................................... 94
Ajustes de interfaz ................................................................................... 95
Configuración de modo NAT ................................................................... 95
Modo de rutas ................................................................................................ 98
Configuración del modo de rutas............................................................. 99
Capítulo 5 Bloques para la construcción de directivas 103

Direcciones ..................................................................................................103
Entradas de direcciones.........................................................................104
Adición de una dirección.................................................................104
Modificación de una dirección ........................................................105
Eliminación de una dirección ..........................................................105
Grupos de direcciones ...........................................................................105
Creación de un grupo de direcciones ..............................................107
Edición de una entrada de grupo de direcciones .............................108
Eliminación de un miembro y un grupo..........................................108
Servicios ......................................................................................................109
Servicios predefinidos............................................................................109
Protocolo de mensajes de control de Internet .................................110
Manejo de errores de destinos inalcanzables de ICMP ....................113
Servicios predefinidos relacionados con Internet ............................113
Servicios de llamadas de procedimiento remoto de Microsoft.........115
Protocolos de enrutamiento dinámico.............................................117
Vídeo de secuencias ........................................................................117
Servicios de llamadas de procedimiento remoto de Sun .................118
Servicios de túnel y seguridad .........................................................119
Servicios relacionados con IP ..........................................................119
Servicios de mensajes instantáneos ................................................120
Servicios de administración ............................................................120
Servicios de correo..........................................................................121
Servicios UNIX ................................................................................121
Contenido v
Servicios varios ...............................................................................122

Servicios personalizados........................................................................122
Adición de un servicio personalizado ..............................................123
Modificación de un servicio personalizado ......................................124
Eliminación de un servicio personalizado .......................................124
Establecimiento del tiempo de espera de un servicio ............................124
Configuración y consulta del tiempo de espera de un servicio ........125
Contingencias .................................................................................126
Ejemplo...........................................................................................127
Definición de un servicio personalizado de protocolo de mensajes de
control de Internet ..........................................................................127
ALG de Shell remoto ..............................................................................128
Capa de aplicación de llamada al procedimiento remoto de Sun ...........129
Situación típica de llamadas RPC ....................................................129
Personalización de los servicios de Sun RPC ...................................130
Personalización del procedimiento remoto de Microsoft Call ALG .........130
Puerta de enlace de la capa de aplicación del protocolo de secuencias
en tiempo real.................................................................................132
Métodos de petición RTSP...............................................................133
Códigos de estado de RTSP .............................................................135
Configuración de un servidor de medios en un dominio privado ....136
Configuración de un servidor de medios en un dominio público.....138
Grupos de servicios................................................................................140
Modificación de un grupo de servicios ............................................141
Eliminación de un grupo de servicios..............................................142
Conjuntos de IP dinámicas...........................................................................142
Traducción de direcciones de puertos....................................................143
Creación de un conjunto de DIP con PAT ..............................................144
Modificación de un conjunto de DIP ......................................................145
Direcciones DIP persistentes .................................................................145
Uso de DIP en una subred distinta.........................................................146
Uso de una DIP en una interfaz de bucle invertido ................................151
Creación de un grupo DIP......................................................................155
Configuración de una programación recurrente ...........................................158
Capítulo 6 Directivas 161

Elementos básicos .......................................................................................162
Tres tipos de directivas ................................................................................163
Directivas interzonales ..........................................................................163
Directivas intrazonales ..........................................................................163
Directivas globales.................................................................................164
Listas de conjuntos de directivas ..................................................................164
Definición de directivas................................................................................165
Directivas y reglas .................................................................................166
Anatomía de una directiva.....................................................................166
ID....................................................................................................167
Zonas ..............................................................................................168
Direcciones .....................................................................................168
Servicios .........................................................................................168
Acción.............................................................................................168
Aplicación .......................................................................................169
Nombre...........................................................................................170
Encapsulamiento VPN.....................................................................170
Encapsulamiento L2TP....................................................................170
vi Contenido
Contenido
Deep Inspection ..............................................................................171

Colocación al principio de la lista de directivas ...............................171
Traducción de direcciones de origen ...............................................171
Traducción de direcciones de destino .............................................171
Autenticación de usuarios ...............................................................172
Copia de seguridad de la sesión HA ................................................174
Filtrado de Web ..............................................................................174
Registro...........................................................................................174
Recuento.........................................................................................174
Umbral de alarma de tráfico ...........................................................174
Tareas programadas........................................................................175
Análisis antivirus .............................................................................175
Asignación de tráfico.......................................................................175
Directivas aplicadas .....................................................................................176
Visualización de directivas.....................................................................177
Creación de directivas ...........................................................................177
Creación del servicio de correo de directivas interzonales...............177
Creación de un conjunto de directivas interzonales.........................180
Creación de directivas intrazonales .................................................185
Creación de una directiva global .....................................................186
Introducción del contexto de una directiva............................................187
Varios elementos por componente de directiva .....................................188
Ajuste de la negación de direcciones .....................................................189
Modificación y desactivación de directivas ............................................191
Verificación de directivas.......................................................................192
Reordenamiento de directivas ...............................................................193
Eliminación de una directiva .................................................................194
Capítulo 7 Asignación de tráfico 195

Administración del ancho de banda a nivel de directivas .............................195
Establecimiento de la asignación de tráfico..................................................196
Establecimiento de las prioridades del servicio ............................................200
Establecer colas de prioridades ....................................................................201
Directivas de entrada ...................................................................................205
Asignación de tráfico en interfaces virtuales ................................................206
Asignación de tráfico a nivel de interfaz ................................................206
Asignación de tráfico a nivel de directiva...............................................208
Flujo de paquetes ..................................................................................208
Ejemplo: VPN basada en rutas con directiva de entrada ........................209
Ejemplo: VPN basada en directivas con directiva de entrada.................212
Asignación de tráfico utilizando la interfaz de bucle invertido......................216
Asignación y marcado de DSCP ...................................................................216
Capítulo 8 Parámetros del sistema 219

Compatibilidad con DNS (sistema de nombres de dominio) ........................219
Consulta DNS ........................................................................................220
Tabla de estado de DNS.........................................................................221
Establecimiento del servidor DNS y programación de
actualizaciones .........................................................................222
Establecimiento de un intervalo de actualización de DNS ...............222
Sistema de nombres de dominio dinámicos ..........................................223
Establecimiento de DDNS para un servidor DynDNS ......................223
Contenido vii
Establecimiento de DDNS para un servidor DDO ............................224

División de direcciones DNS del proxy ..................................................225
Protocolo de configuración dinámica de host...............................................227
Configuración de un servidor DHCP ......................................................229
Personalización de las opciones de servidor DHCP .........................232
Colocación del servidor DHCP en un clúster de NSRP .....................234
Detección del servidor DHCP ..........................................................234
Habilitación de detección del servidor DHCP ..................................234
Desactivación de la detección del servidor DHCP............................235
Asignar un dispositivo de seguridad como agente de retransmisión de
DHCP ..............................................................................................235
Redireccionamiento de todos los paquetes DHCP ...........................239
Configuración de la IP del siguiente servidor...................................240
Utilización de un dispositivo de seguridad como cliente DHCP..............241
Propagación de ajustes TCP/IP...............................................................242
Configuración de DHCP en sistemas virtuales .......................................245
Establecimiento de la retransmisión de un mensaje DHCP en sistemas
virtuales.................................................................................................245
Protocolo punto a punto sobre Ethernet.......................................................246
Configuración de PPPoE ........................................................................246
Configuración de PPPoE en las interfaces principal y de respaldo de la
zona Untrust ...................................................................................249
Configuración de múltiples sesiones PPPoE a través de una sola
interfaz ...........................................................................................250
PPPoE y alta disponibilidad ...................................................................253
Claves de licencia.........................................................................................253
Registro y activación de los servicios de suscripción ....................................254
Servicio de prueba.................................................................................255
Actualización de las claves de suscripción .............................................255
Adición de antivirus, filtrado de Web, antispam e inspección minuciosa
a un nuevo dispositivo o a uno existente.........................................256
Reloj del sistema ..........................................................................................256
Fecha y hora..........................................................................................257
Horario de verano .................................................................................257
Huso horario..........................................................................................257
Protocolo de hora de la red....................................................................258
Configuración de múltiples servidores NTP .....................................258
Configuración de un servidor NTP de respaldo................................258
Desfase temporal máximo ..............................................................259
Protocolos NTP y NSRP ...................................................................260
Establecimiento de un valor máximo de desfase horario para un
servidor NTP.............................................................................260
Seguridad de los servidores NTP .....................................................261
Índice ........................................................................................................................IX-I
viii Contenido
Contenido
Volumen 3:
Administración
Acerca de este volumen vii
Convenciones del documento ........................................................................ vii
Convenciones de la interfaz de usuario web ............................................ vii
Convenciones de interfaz de línea de comandos .................................... viii
Convenciones de nomenclatura y conjuntos de caracteres ..................... viii
Convenciones para las ilustraciones .......................................................... x
Asistencia y documentación técnica................................................................ xi
Capítulo 1 Administración 1
Administración a través de la interfaz de usuario web ..................................... 2
Ayuda de la interfaz gráfica (WebUI) ......................................................... 2
Copia de los archivos de ayuda a una unidad local.............................. 3
Desvío de WebUI a la nueva ubicación de la ayuda............................. 3
Protocolo de transferencia de hipertextos ................................................. 4
Identificación de sesión ............................................................................. 4
Secure Sockets Layer ................................................................................. 5
Configuración de SSL .......................................................................... 7
Redireccionamiento de HTTP a SSL .................................................... 8
Administración a través de la interfaz de línea de comandos......................... 10
Telnet ...................................................................................................... 10
Conexiones Telnet seguras ...................................................................... 11
Secure Shell ............................................................................................. 11
Requisitos del cliente ........................................................................ 13
Configuración básica de SSH en el dispositivo................................... 13
Autenticación .................................................................................... 14
SSH y Vsys ........................................................................................ 16
Clave de host .................................................................................... 17
Ejemplo: SSHv1 con PKA para inicios de sesión de automatizados ... 17
Copia segura............................................................................................ 18
Consola serie ........................................................................................... 19
Consola remota ....................................................................................... 20
Consola remota con el puerto de módem V.92 ................................. 20
Consola remota con el puerto AUX ................................................... 21
Puerto de módem.................................................................................... 22
Administración a través de NetScreen-Security Manager................................ 23
Inicio de la conectividad entre el agente de NSM y el sistema MGT ......... 24
Habilitar, inhabilitar y desactivar el agente de NSM ................................. 25
Ajustar la dirección IP del servidor principal del sistema de
administración (Management System) .............................................. 26
Ajustar la generación de informes de alarmas y de estadísticas............... 26
Sincronización de la configuración .......................................................... 28
Ejemplo: Visualizar al estado de la configuración .............................. 28
Ejemplo: Consultar el hash de configuración..................................... 28
Consultar la marca de hora de configuración........................................... 29
Control del tráfico administrativo................................................................... 29
Interfaces MGT y VLAN1.......................................................................... 30
Ejemplo: Administración a través de la interfaz MGT ........................ 30
Ejemplo: Administración a través de la interfaz VLAN1..................... 31
Ajuste de las opciones de la interfaz administrativa................................. 31
Contenido ix
Ajuste de las direcciones IP de administración para múltiples

interfaces .......................................................................................... 33
Niveles de administración .............................................................................. 35
Administrador raíz................................................................................... 35
Administrador de lectura/escritura........................................................... 36
Administrador de sólo lectura.................................................................. 36
Administrador de sistema virtual............................................................. 36
Administrador de sólo lectura del sistema virtual .................................... 37
Definición de usuarios con permisos de administrador.................................. 37
Ejemplo: Agregar un administrador de sólo lectura ................................. 37
Ejemplo: Modificar un administrador ...................................................... 37
Ejemplo: Eliminar un administrador........................................................ 38
Ejemplo: Configurar las cuentas del administrador para las conexiones
de acceso telefónico.......................................................................... 38
Ejemplo: Borrar una sesión de administrador.......................................... 39
Tráfico administrativo seguro......................................................................... 40
Cambiar el número de puerto.................................................................. 41
Cambio de nombre y contraseña de inicio de sesión del
administrador ................................................................................... 41
Ejemplo: Cambiar el nombre de inicio de sesión y la contraseña de
un usuario administrador ........................................................... 42
Ejemplo: Cambiar su propia contraseña............................................ 43
Ajuste de la longitud mínima de la contraseña del administrador
raíz ............................................................................................. 43
Restablecimiento del dispositivo con los ajustes predeterminados de
fábrica............................................................................................... 44
Restricción del acceso administrativo ...................................................... 44
Ejemplo: Restringir la administración a una sola estación de
trabajo ........................................................................................ 45
Ejemplo: Restringir la administración a una subred .......................... 45
Restringir el administrador raíz a acceder desde la consola .............. 45
Túneles de VPN para tráfico administrativo ............................................. 46
Administración a través de un túnel VPN de clave manual basado
en rutas ...................................................................................... 47
en directivas ............................................................................... 51
Directiva de contraseñas ................................................................................ 55
Establecimiento de una directiva de contraseñas .................................... 55
Eliminación de una directiva de contraseñas ........................................... 56
Visualización de una directiva de contraseñas ......................................... 56
Recuperación de una contraseña de administrador predeterminada
rechazada ......................................................................................... 56
Creación de un mensaje de bienvenida de inicio de sesión............................ 57
Capítulo 2 Supervisión de dispositivos de seguridad 59

Almacenamiento de la información del registro............................................. 59
Registro de eventos........................................................................................ 61
Ver el registro de eventos según nivel de gravedad y palabra clave ......... 62
Clasificación y filtrado del registro de eventos ......................................... 63
Descargar el registro de eventos.............................................................. 64
Ejemplo: Descargar el registro de eventos completo ......................... 64
Ejemplo: Descargar los eventos críticos del registro de eventos ........ 64
x Contenido
Contenido
Registro de tráfico.......................................................................................... 65
Visualización del registro de tráfico ......................................................... 66
Ejemplo: Visualizar las entradas del registro de tráfico...................... 66
Clasificación y filtrado del registro de tráfico..................................... 67
Ejemplo: Clasificar el registro de tráfico por horas ............................ 67
Descarga del registro de tráfico ............................................................... 68
Eliminación del campo del motivo de cierre............................................ 68
Registro propio ..............................................................................................70
Visualización del registro propio .............................................................. 70
Clasificación y filtrado del registro propio ......................................... 71
Ejemplo: Filtrar el registro propio por horas...................................... 71
Descargar el registro propio..................................................................... 72
Descargar el registro de recuperación de posición ......................................... 72
Alarmas de tráfico.......................................................................................... 73
Ejemplo: Detección de intrusiones basada en directivas.......................... 74
Ejemplo: Notificación de sistema comprometido..................................... 74
Ejemplo: Enviar alertas de correo electrónico .......................................... 75
Syslog ............................................................................................................ 76
Ejemplo: Habilitar múltiples servidores Syslog......................................... 77
Activación de WebTrends para eventos de notificación ........................... 77
Protocolo simple de administración de redes................................................. 78
Vista general de implementación............................................................. 81
Definición de una comunidad SNMP de lectura/escritura......................... 82
Túneles VPN para tráfico autogenerado ......................................................... 83
Ejemplo: Tráfico autogenerado a través de túnel basado en rutas ........... 85
Ejemplo: Tráfico autogenerado a través de túnel basado en directivas .... 91
Visualizar contadores de pantalla ................................................................... 98
Índice ........................................................................................................................IX-I
Volumen 4:
Detección ataques y mecanismos de defensa
Convenciones de interfaz de línea de comandos ...................................... xi
Convenciones para las ilustraciones ....................................................... xiii
Asistencia y documentación técnica.............................................................. xiv
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
Contenido xi
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
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
Ejemplo: Protección contra inundaciones SYN .................................. 43
Cookie SYN..............................................................................................47
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
Modos de análisis.............................................................................. 63
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
xii Contenido
Contenido
Análisis de protocolos de aplicación ........................................................ 72

Aálisis del tráfico de FTP ................................................................... 73
Análisis del tráfico de HTTP .............................................................. 74
Análisis del tráfico de IMAP y POP3 .................................................. 76
Análisis del tráfico de SMTP .............................................................. 78
Desvío del tráfico a los servidores de análisis AV ICAP...................... 80
Actualización de los archivos de patrones AV para el analizador
incorporado ...................................................................................... 81
Suscripción al servicio de firma AV ................................................... 81
Actualización de los patrones AV ...................................................... 82
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
Ejemplo: Análisis de AV únicamente para el tráfico SMTP y HTTP .... 91
Ajustes de perfiles de AV................................................................... 92
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
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
Contenido xiii
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
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
Ejemplo: Bloqueo de applets de Java y archivos “.exe” ...................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
activo ..............................................................................................183
xiv Contenido
Contenido
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
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
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
Contenido xv
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
Servicios .........................................................................................213
Establecimiento del funcionamiento......................................................213
Establecimiento de acciones..................................................................213
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
Configuración de grupos estáticos...................................................230
Configuración de grupos dinámicos ................................................232
Ejemplo: Creación de un grupo dinámico........................................233
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
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
xvi Contenido
Contenido
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
Volumen 5:
Redes privadas virtuales
Convenciones del documento ....................................................................... viii
Convenciones de la interfaz de usuario web ........................................... viii
Convenciones de nomenclatura y conjuntos de caracteres ....................... ix
Capítulo 1 Seguridad del protocolo de Internet 1

Introducción a las redes privadas virtuales....................................................... 2
Conceptos de IPSec.......................................................................................... 3
Modos ....................................................................................................... 4
Modo de transporte............................................................................. 4
Modo de túnel ..................................................................................... 4
Protocolos ................................................................................................. 6
Encabezado de autenticación .............................................................. 6
Carga de seguridad encapsulada ......................................................... 6
Administración de claves........................................................................... 7
Clave manual ...................................................................................... 7
AutoKey IKE........................................................................................ 7
Asociaciones de seguridad......................................................................... 8
Negociación de túnel........................................................................................ 9
Fase 1........................................................................................................ 9
Modo principal y modo dinámico ..................................................... 10
Intercambio Diffie-Hellman............................................................... 11
Fase 2...................................................................................................... 11
Confidencialidad directa perfecta ...................................................... 12
Protección contra reprocesamiento de paquetes............................... 12
Paquetes IKE e IPSec ..................................................................................... 12
Paquetes IKE ........................................................................................... 13
Paquetes IPSec ........................................................................................ 16
Capítulo 2 Criptografía de claves públicas 19

Introducción a la criptografía de claves públicas ............................................ 20
Firma de un certificado ........................................................................... 20
Verificación de una firma digital .............................................................. 20
Infraestructura de claves públicas .................................................................. 22
Certificados y CRL.......................................................................................... 24
Petición manual de un certificado ........................................................... 26
Carga de certificados y listas de revocación de certificados ..................... 28
Contenido xvii
Configuración de ajustes de CRL.............................................................. 29

Obtención automática de un certificado local .......................................... 31
Renovación automática de certificado ..................................................... 34
Generación de pares de claves.................................................................35
Protocolo de estado de certificado en línea (OCSP) ........................................ 35
Especificación de un método de comprobación de revocación de
certificados ....................................................................................... 36
Visualización de los atributos de comprobación de estado ...................... 37
Especificación de una URL del servidor de respuesta del protocolo de
estado de certificado en línea............................................................ 37
Eliminación de atributos de comprobación de estado.............................. 37
Certificados autofirmados .............................................................................. 38
Validación de certificados ........................................................................ 39
Creación manual de certificados autofirmados ........................................ 40
Establecimiento de un certificado autofirmado y definido por el
administrador ................................................................................... 41
Autogeneración de certificados................................................................ 45
Eliminar certificados autofirmados .......................................................... 46
Capítulo 3 Directrices para las redes privadas virtuales 49

Opciones criptográficas.................................................................................. 50
Opciones criptográficas punto a punto ....................................................50
Opciones VPN de acceso telefónico ......................................................... 57
Túneles basados en directivas y en rutas ....................................................... 64
Flujo de paquetes: VPN punto a punto ........................................................... 66
Directrices para la configuración de túneles ................................................... 72
Consideraciones sobre seguridad en redes privadas virtuales basadas en
rutas ........................................................................................................ 74
Ruta Null.................................................................................................. 74
Línea de acceso telefónico o arrendada ................................................... 76
Conmutación por error de la VPN hacia la línea arrendada o la ruta
Null ................................................................................................... 77
Interfaz Tunnel ficticia ............................................................................. 79
Enrutador virtual para interfaces Tunnel.................................................. 80
Reenrutamiento a otro túnel.................................................................... 80
Capítulo 4 Redes privadas virtuales de punto a punto 81

Configuraciones VPN punto a punto............................................................... 82
VPN punto a punto basada en rutas, AutoKey IKE ................................... 88
VPN punto a punto basada en directivas, AutoKeyIKE............................. 97
VPN punto a punto basada en rutas, interlocutor dinámico ...................103
VPN punto a punto basada en directivas, interlocutor dinámico............112
VPN punto a punto basada en rutas, clave manual ................................120
VPN punto a punto basada en directivas, clave manual.........................127
Puertas de enlace IKE dinámicas con FQDN ................................................132
Alias ......................................................................................................133
Ajuste del interlocutor AutoKey IKE con FQDN......................................134
Sitios VPN con direcciones superpuestas......................................................142
VPN en modo transparente..........................................................................154
Capítulo 5 Redes privadas virtuales de acceso telefónico 163

Acceso telefónico .........................................................................................164
VPN de acceso telefónico basada en directivas, AutoKey IKE ................165
xviii Contenido
Contenido
VPN de acceso telefónico basada en rutas, interlocutor dinámico .........170

VPN de acceso telefónico basada en directivas, interlocutor
dinámico.........................................................................................177
Directivas bidireccionales para usuarios de VPN de acceso telefónico ...184
Identificación IKE de grupo ..........................................................................188
Identificación IKE de grupo con certificados ..........................................189
Tipos de identificación IKE ASN1-DN Wildcard y Container ..................191
Creación de una identificación IKE de grupo (certificados) ....................194
Configuración de una ID IKE de grupo con claves previamente
compartidas ....................................................................................198
Identificación IKE compartida ......................................................................204
Capítulo 6 Protocolo de encapsulamiento de la capa 2 211

Introducción al L2TP ....................................................................................211
Encapsulado y desencapsulado de paquetes ................................................214
Encapsulado ..........................................................................................215
Desencapsulado.....................................................................................216
Ajuste de los parámetros L2TP .....................................................................217
L2TP y L2TP sobre IPSec..............................................................................219
Configuración de L2TP ..........................................................................219
Configuración de L2TP sobre IPSec .......................................................224
L2TP sobre IPSec bidireccional ..............................................................232
Capítulo 7 Funciones avanzadas de redes privadas virtuales 239

NAT-Traversal ..............................................................................................240
Sondeos de NAT ....................................................................................241
Atravesar un dispositivo NAT.................................................................243
Suma de comprobación de UDP ............................................................245
Paquetes de mantenimiento de conexión..............................................246
Simetría iniciador/respondedor .............................................................246
Habilitación de NAT-Traversal ...............................................................248
Uso de identificaciones de IKE con NAT-Traversal .................................249
Supervisión de VPN......................................................................................250
Opciones de reencriptación y optimización ...........................................251
Interfaz de origen y dirección de destino...............................................252
Consideraciones sobre directivas...........................................................253
Configuración de la función de supervisión de VPN...............................254
Objetos y capturas SNMP para la supervisión de VPN............................262
Múltiples túneles por interfaz de túnel .........................................................263
Asignación de rutas a túneles ................................................................264
Direcciones de interlocutores remotos...................................................266
Entradas de tabla manuales y automáticas ............................................267
Entradas manuales en la tabla ........................................................267
Entradas automáticas en la tabla.....................................................267
Ajuste de VPN en una interfaz de túnel para subredes
superpuestas ............................................................................269
Asociación de entradas automáticas en la tabla de rutas y en la
tabla NHTB ...............................................................................288
Uso de OSPF para entradas automáticas en la tabla de rutas ..........300
Puertas de enlace VPN redundantes.............................................................301
Grupos VPN ...........................................................................................302
Mecanismos de supervisión...................................................................303
Pulsos de IKE ..................................................................................304
Contenido xix
Detección de interlocutor muerto....................................................304

Procedimiento de recuperación IKE ................................................306
Comprobación de indicador TCP SYN....................................................307
Creación de puertas de enlace VPN redundantes ............................308
Creación de VPN adosadas...........................................................................314
Creación de VPN radiales .............................................................................321
Capítulo 8 Redes privadas virtuales de AutoConnect 331

Vista general ................................................................................................331
Cómo funciona ............................................................................................332
Mensajes NHRP .....................................................................................332
Iniciación del túnel AC-VPN ...................................................................333
Configuración de AC-VPN ......................................................................334
Traducción de direcciones de red....................................................335
Configuración en el concentrador ...................................................335
Configuración en cada red radial.....................................................335
Ejemplo .................................................................................................336
Índice ........................................................................................................................IX-I
Volumen 6:
Voz sobre el protocolo de Internet (VoIP)
Capítulo 1 Puerta de enlace en la capa de aplicación H.323 1

Vista general .................................................................................................... 1
Ejemplos .......................................................................................................... 2
Ejemplo: Equipo selector en la zona Trust ................................................. 2
Ejemplo: Equipo selector en la zona Untrust.............................................. 3
Ejemplo: Llamadas salientes con NAT ....................................................... 5
Ejemplo: Llamadas entrantes con NAT ......................................................8
Ejemplo: Equipo selector en la zona Untrust con NAT ............................. 10
Capítulo 2 Puerta de enlace de la capa de aplicación del protocolo de inicio

de sesión 13
Vista general .................................................................................................. 13
Métodos de petición del protocolo SIP ..................................................... 14
Clases de respuestas SIP .......................................................................... 16
Puerta de enlace en la capa de aplicación SIP.......................................... 17
Sesiones con protocolo de descripción de sesiones ................................. 18
Creación de ojos de aguja ........................................................................ 20
Tiempo de espera por inactividad de la sesión ........................................ 21
Protección contra ataques SIP .................................................................22
Ejemplo: SIP Protect Deny ................................................................ 22
xx Contenido
Contenido
Ejemplo: Tiempos de espera por inactividad de señalización o de

medios ....................................................................................... 23
Ejemplo: Protección contra inundaciones UDP ................................. 23
Ejemplo: Máximo de conexiones SIP ................................................ 24
SIP con traducción de direcciones de red (NAT) ............................................. 24
Llamadas salientes................................................................................... 25
Llamadas entrantes ................................................................................. 25
Llamadas reenviadas ............................................................................... 26
Terminación de la llamada ...................................................................... 26
Mensajes de llamada Re-INVITE .............................................................. 26
Temporizadores de sesiones de llamadas ................................................ 26
Cancelación de la llamada ....................................................................... 27
Bifurcación ..............................................................................................27
Mensajes SIP ........................................................................................... 27
Encabezados SIP ..................................................................................... 28
Cuerpo SIP............................................................................................... 29
Supuesto de NAT con el protocolo SIP ..................................................... 30
Ejemplos ........................................................................................................ 31
Soporte de llamadas SIP entrantes utilizando el registrador SIP............... 32
Ejemplo: Llamada entrante (DIP de interfaz)..................................... 33
Ejemplo: Llamada entrante (conjunto de DIP) ................................... 36
Ejemplo: Llamada entrante con MIP ................................................. 38
Ejemplo: Proxy en la zona privada....................................................40
Ejemplo: Proxy en la zona pública ....................................................43
Ejemplo: Zona triple, proxy en DMZ ................................................. 45
Ejemplo: Untrust intrazonal .............................................................. 49
Ejemplo: Trust intrazonal .................................................................. 52
Ejemplo: VPN de malla completa para SIP ........................................ 55
Administración del ancho de banda para servicios de VoIP ..................... 65
Capítulo 3 Puerta de enlace en la capa de aplicación de protocolo de control

de la puerta de medios 67
Vista general .................................................................................................. 67
Seguridad de MGCP........................................................................................ 68
Protocolo MGCP ............................................................................................. 68
Entidades en MGCP ................................................................................. 69
Punto final ........................................................................................ 69
Conexión .......................................................................................... 69
Llamada ............................................................................................ 69
Agente de llamada ............................................................................ 70
Comandos ............................................................................................... 70
Códigos de respuesta............................................................................... 73
Ejemplos ........................................................................................................ 74
Puerta de enlace en las residencias de los abonados: agente de llamada
en el ISP............................................................................................ 74
Servicio alojado en ISP ............................................................................ 77
Capítulo 4 Puerta de enlace en la capa de aplicación del protocolo Skinny de

control de clientes 83
Vista general .................................................................................................. 83
Seguridad del SCCP........................................................................................ 84
Protocolo SCCP ..............................................................................................85
Componentes del SCCP ........................................................................... 85
Contenido xxi
Cliente del SCCP ............................................................................... 85

Gestor de llamadas............................................................................ 85
Clúster ..............................................................................................85
Transacciones con SCCP.......................................................................... 86
Inicialización del cliente .................................................................... 86
Registro del cliente............................................................................ 86
Establecimiento de la llamada........................................................... 87
Configuración de medios .................................................................. 87
Mensaje de control del SCCP y flujo del RTP............................................ 88
Mensajes del SCCP .................................................................................. 89
Ejemplos ........................................................................................................ 89
Ejemplo: Gestor de llamadas/servidor TFTP en la zona Trust ............ 90
Ejemplo: Gestor de llamadas/servidor TFTP en la zona Untrust......... 92
Ejemplo: Zona triple, gestor de llamadas/servidor TFTP en DMZ....... 94
Ejemplo: Intrazonal, gestor de llamadas/servidor TFTP en la zona
Trust ........................................................................................... 98
Untrust .....................................................................................102
Ejemplo: VPN de malla completa para el SCCP ...............................104
Índice ........................................................................................................................IX-I
Volumen 7:
Enrutamiento
Acerca de este volumen xi
Convenciones del documento ........................................................................ xii
Convenciones de la interfaz de usuario web ............................................ xii
Convenciones de interfaz de línea de comandos ..................................... xii
Convenciones de nomenclatura y conjuntos de caracteres ..................... xiii
Convenciones para las ilustraciones ....................................................... xiv
Asistencia y documentación técnica............................................................... xv
Capítulo 1 Enrutamiento estático 1

Vista general .................................................................................................... 1
Cómo funciona el enrutamiento estático ................................................... 2
Cuándo configurar rutas estáticas .............................................................. 3
Configuración de rutas estáticas ................................................................ 4
Ajuste de rutas estáticas ...................................................................... 5
Establecimiento de una ruta estática para una interfaz de túnel.......... 8
Habilitación del seguimiento de puertas de enlace .................................... 9
Reenvío de tráfico a la interfaz Null ............................................................... 10
Impedir las consultas de rutas en otras tablas de enrutamiento............... 10
Impedir que el tráfico de túnel se envíe a través de interfaces que no
sean de túnel .................................................................................... 10
Evitar bucles creados por las rutas resumidas.......................................... 11
Rutas permanentemente activas .................................................................... 11
Cambiar la preferencia de enrutamiento con enrutamiento multidireccional
de igual coste........................................................................................... 12
xxii Contenido
Contenido
Capítulo 2 Enrutamiento 13
Vista general .................................................................................................. 14
Tablas de enrutamiento del enrutador virtual................................................. 15
Tabla de enrutamiento basada en destinos.............................................. 16
Tabla de enrutamiento basada en el origen ............................................. 18
Tabla de enrutamiento según la interfaz de origen .................................. 20
Creación y modificación de enrutadores virtuales .......................................... 22
Modificación de enrutadores virtuales ..................................................... 22
Asignación de una ID de enrutador virtual............................................... 23
Reenvío de tráfico entre enrutadores virtuales......................................... 24
Configuración de dos enrutadores virtuales ............................................. 24
Creación y eliminación de enrutadores virtuales ..................................... 26
Creación de un enrutador virtual personalizado ................................ 26
Eliminación de un enrutador virtual personalizado ........................... 27
Enrutadores virtuales y sistemas virtuales ............................................... 27
Creación de un enrutador virtual en un Vsys..................................... 28
Compartir rutas entre enrutadores virtuales...................................... 29
Limitación del número máximo de entradas de la tabla de
enrutamiento .................................................................................... 30
Ejemplos y funciones del enrutamiento ......................................................... 30
Selección de rutas.................................................................................... 31
Establecimiento de una preferencia de ruta ...................................... 31
Métricas de ruta ................................................................................ 32
Cambio de la secuencia predeterminada de consulta de rutas .......... 33
Consulta de rutas en múltiples enrutadores virtuales ........................ 35
Configuración del enrutamiento multidireccional de igual coste .............. 36
Redistribución de rutas............................................................................ 38
Configuración de un mapa de rutas .................................................. 39
Filtrado de rutas................................................................................ 41
Configuración de una lista de acceso................................................. 41
Redistribución de rutas en OSPF ....................................................... 42
Exportación e importación de rutas entre enrutadores virtuales.............. 43
Configuración de una regla de exportación ....................................... 44
Configuración de la exportación automática ..................................... 45
Capítulo 3 Abrir primero la ruta más corta 47

Vista general .................................................................................................. 48
Áreas ....................................................................................................... 48
Clasificación de enrutadores .................................................................... 49
Protocolo de saludo ................................................................................. 50
Tipos de redes ......................................................................................... 50
Redes de difusión.............................................................................. 50
Redes punto a punto ......................................................................... 50
Redes punto a multipunto .................................................................51
Notificaciones de estado de conexiones .................................................. 51
Configuración básica de OSPF ....................................................................... 51
Creación y eliminación de una instancia de enrutamiento OSPF ............. 53
Creación de una instancia de OSPF................................................... 53
Eliminación de una instancia de OSPF .............................................. 53
Creación y eliminación de un área OSPF ................................................. 54
Creación de un área OSPF.................................................................54
Eliminación de un área OSPF............................................................ 55
Contenido xxiii
Asignación de interfaces a un área OSPF................................................. 55

Asignación de interfaces a áreas ....................................................... 55
Configuración de un rango de áreas.................................................. 56
Habilitación de OSPF en interfaces.......................................................... 56
Habilitación de OSPF en interfaces ................................................... 56
Inhabilitar OSPF en una interfaz ....................................................... 57
Verificación de la configuración............................................................... 57
Redistribución de rutas en protocolos de enrutamiento ................................. 59
Resumen de rutas redistribuidas .................................................................... 60
Resumen de rutas redistribuidas ............................................................. 60
Parámetros globales de OSPF ........................................................................ 61
Notificación de la ruta predeterminada....................................................62
Conexiones virtuales ............................................................................... 62
Creación de una conexión virtual ...................................................... 63
Creación de una conexión virtual automática.................................... 64
Ajuste de parámetros OSPF de interfaz .......................................................... 64
Configuración de seguridad............................................................................ 67
Autenticación de vecinos ......................................................................... 67
Configuración de una contraseña de texto no cifrado .......................67
Configuración de una contraseña MD5 ............................................. 67
Configuración de una lista de vecinos de OSPF ....................................... 68
Rechazo de rutas predeterminadas.......................................................... 69
Protección contra inundaciones............................................................... 69
Configuración de un umbral de saludo.............................................. 70
Configuración de un umbral de LSA .................................................. 70
Habilitación de la inundación reducida ............................................. 70
Creación de un circuito de demanda OSPF en una interfaz de túnel .............. 71
Interfaz de túnel punto a multipunto.............................................................. 71
Establecer el tipo de conexión OSPF ....................................................... 72
Inhabilitación de la restricción Route-Deny ............................................. 72
Creación de una red punto a multipunto ................................................. 73
Capítulo 4 Protocolo de información de enrutamiento 79

Vista general .................................................................................................. 80
Configuración básica de RIP........................................................................... 81
Creación y eliminación de una instancia RIP ........................................... 82
Creación de una instancia RIP........................................................... 82
Eliminación de una instancia RIP ...................................................... 83
Habilitación y deshabilitación de RIP en interfaces.................................. 83
Habilitar RIP en una interfaz ............................................................. 83
Inhabilitación de RIP en una interfaz ................................................ 83
Visualización de la información de RIP .......................................................... 85
Visualización de la base de datos RIP ...................................................... 85
Visualización de los detalles de RIP ......................................................... 86
Visualización de información de vecino RIP ............................................ 87
Visualización de detalles de RIP para una interfaz específica ................... 88
Parámetros globales de RIP............................................................................ 89
Notificación de la ruta predeterminada .......................................................... 90
Configuración de los parámetros de interfaz de RIP....................................... 90
Autenticar vecinos al establecer una contraseña...................................... 92
Configuración de vecinos fiables ............................................................. 93
xxiv Contenido
Contenido

Configuración de un umbral de actualización.................................... 95
Habilitación de RIP en interfaces de túnel ......................................... 95
Configuraciones opcionales de RIP ................................................................ 96
Configuración de la versión de RIP .......................................................... 96
Habilitación e inhabilitación de un resumen de prefijos........................... 98
Habilitación de un resumen de prefijos ............................................. 98
Inhabilitar un resumen de prefijo ...................................................... 99
Establecimiento de rutas alternas ............................................................ 99
Circuitos de demanda en interfaces de túnel .........................................101
Configuración de un vecino estático ......................................................102
Configuración de una interfaz de túnel punto a multipunto..........................102
Capítulo 5 Protocolo de puertas de enlace de límite 109

Vista general ................................................................................................110
Tipos de mensajes BGP..........................................................................110
Atributos de ruta....................................................................................111
BGP externo e interno ...........................................................................112
Configuración básica de BGP........................................................................112
Creación y habilitación de una instancia de BGP ...................................113
Creación de una instancia BGP........................................................113
Eliminación de una instancia de BGP ..............................................114
Habilitación e inhabilitación de BGP en interfaces .................................114
Habilitación de BGP en interfaces ...................................................114
Inhabilitación de BGP en interfaces.................................................115
Configuración de grupos de interlocutores e interlocutores BGP ............115
Configuración de un interlocutor BGP .............................................117
Configuración de un grupo de interlocutores IBGP ..........................117
Comprobación de la configuración BGP.................................................119
Configuración de seguridad..........................................................................120
Autenticación de vecinos BGP ...............................................................120
Rechazo de rutas predeterminadas........................................................121
Configuraciones opcionales de BGP .............................................................122
Redistribución de rutas en BGP .............................................................123
Configuración de una lista de acceso AS-Path ........................................124
Agregar rutas a BGP...............................................................................125
Notificación de ruta condicional......................................................125
Establecimiento del peso de la ruta.................................................126
Establecimiento datributos de ruta..................................................126
Capacidad de route-refresh....................................................................127
Solicitud de una actualización de la tabla de enrutamiento
entrante....................................................................................128
saliente .....................................................................................128
Configuración de la reflexión de rutas ...................................................128
Configurar una confederación ...............................................................131
Comunidades BGP .................................................................................133
Agregación de rutas ...............................................................................134
Agregación de rutas con diferentes AS-Paths...................................134
Supresión de las rutas más específicas en actualizaciones ..............134
Selección de rutas para el atributo Path ..........................................136
Cambiar atributos de una ruta agregada .........................................137
Contenido xxv
Capítulo 6 Enrutamiento basado en directivas 139

Vista general del enrutamiento basado en directivas....................................140
Listas de acceso extendidas...................................................................140
Grupos de coincidencias ........................................................................141
Grupos de acciones................................................................................141
Consulta de rutas con enrutamiento basado en directivas............................142
Configuración del enrutamiento basado en directivas ..................................143
Configuración de una lista de acceso extendida.....................................143
Configuración de un grupo de coincidencias .........................................145
Configuración de un grupo de acciones .................................................145
Configuración de una directiva de PBR..................................................146
Enlace de una directiva de enrutamiento basado en directivas..............146
Enlace de una directiva de enrutamiento basado en directivas a
una interfaz ..............................................................................146
una zona...................................................................................147
Enlace de una directiva de enrutamiento basado en directivas a un
enrutador virtual.......................................................................147
Visualización de la salida de enrutamiento basado en directivas..................147
Visualización de una lista de acceso extendida ......................................147
Visualización de un grupo de coincidencias ...........................................148
Visualización de un grupo de acciones...................................................148
Visualización de la configuración de una directiva de enrutamiento
basado en directivas .......................................................................149
Visualización de la configuración completa de enrutamiento basado en
directivas ........................................................................................150
Ejemplo de PBR avanzado ...........................................................................150
Enrutamiento ........................................................................................152
Elementos PBR ......................................................................................153
Listas de acceso extendidas ............................................................153
Grupos de coincidencias..................................................................154
Grupos de acciones .........................................................................154
Directivas de PBR............................................................................154
Asociación de interfaces ........................................................................155
PBR avanzado con alta disponibilidad y posibilidad de ampliación ..............155
Solución de resistencia en PBR ..............................................................155
Solución con posibilidad de ampliación en PBR.....................................156
Capítulo 7 Enrutamiento multicast 157

Vista general ................................................................................................157
Direcciones multicast ............................................................................158
Reenvío por rutas inversas ....................................................................158
Enrutamiento multicast en dispositivos de seguridad...................................159
Tabla de enrutamiento multicast ...........................................................159
Configuración de una ruta multicast estática .........................................160
Listas de acceso .....................................................................................161
Configurar Encapsulado de enrutamiento genérico en interfaces de
túnel ...............................................................................................161
Directivas multicast......................................................................................163
xxvi Contenido
Contenido
Capítulo 8 Protocolo de administración de grupos de Internet 165

Vista general ................................................................................................166
Hosts .....................................................................................................166
Enrutadores multicast............................................................................167
IGMP en dispositivos de seguridad ...............................................................167
Habilitación e inhabilitación de IGMP en interfaces ...............................167
Habilitación de IGMP en una interfaz ..............................................168
Desactivación de IGMP en una interfaz ...........................................168
Configuración de una lista de accesos para grupos aceptados ...............168
Configuración de IGMP ..........................................................................169
Verificación de una configuración de IGMP ...........................................171
Parámetros operativos de IGMP.............................................................172
Proxy de IGMP .............................................................................................173
Informes de miembros en sentido ascendente hacia el origen ..............174
Datos multicast en sentido descendente a los receptores ......................175
Configuración del proxy de IGMP ..........................................................176
Configuración de un proxy de IGMP en una interfaz..............................176
Directivas multicast para configuraciones de IGMP y proxy de IGMP ....178
Creación de una directiva de grupo multicast para IGMP ................178
Creación de una configuración de proxy de IGMP...........................178
Configuración de un proxy de remitente de IGMP .................................185
Capítulo 9 Multicast independiente de protocolo 191

Vista general ................................................................................................192
PIM-SM ..................................................................................................193
Árboles de distribución multicast ....................................................194
Enrutador designado.......................................................................194
Asignación de puntos de encuentro a grupos ..................................195
Reenvío de tráfico a través del árbol de distribución .......................195
PIM-SSM ................................................................................................197
Configuración de PIM-SM en dispositivos de seguridad ................................198
Habilitación y eliminación de una instancia PIM-SM en un VR ..............199
Habilitación de una instancia PIM-SM .............................................199
Eliminación de una instancia PIM-SM .............................................199
Habilitación e inhabilitación de PIM-SM en interfaces............................200
Habilitación de PIM-SM en una interfaz...........................................200
Desactivación de PIM-SM en una interfaz........................................200
Directivas de grupo multicast ................................................................200
Mensajes Static-RP-BSR...................................................................201
Mensajes Join-Prune........................................................................201
Definición de una directiva de grupo multicast para PIM-SM...........201
Ajuste de una configuración de PIM-SM básica.............................................202
Verificación de la configuración ...................................................................207
Configuración de puntos de encuentro.........................................................209
Configuración de un punto de encuentro estático..................................209
Configuración de un punto de encuentro candidato ..............................210
Consideraciones sobre seguridad .................................................................211
Restricción de grupos multicast .............................................................211
Restricción de orígenes multicast ..........................................................212
Restricción de puntos de encuentro.......................................................213
Parámetros de la interfaz PIM-SM ................................................................214
Definición de una directiva vecina.........................................................214
Definición de un límite bootstrap ..........................................................215
Contenido xxvii
Configuración de un punto de encuentro del proxy .....................................215

PIM-SM e IGMPv3 ........................................................................................225
Capítulo 10 Protocolo de descubrimiento de enrutador de ICMP 227

Vista general ................................................................................................227
Configuración del protocolo de descubrimiento de enrutador de ICMP ........228
Habilitación del protocolo de descubrimiento de enrutador de ICMP.....228
Configuración del protocolo de descubrimiento del enrutador de ICMP
desde WebUI ..................................................................................228
desde CLI ........................................................................................229
Notificación de una interfaz ............................................................229
Difusión de la dirección...................................................................229
Configuración de un intervalo máximo de notificación ...................230
Configuración de un intervalo mínimo de notificación ....................230
Configuración de un valor de duración de la notificación ................230
Configuración de un retardo de respuesta.......................................230
Configuración de un intervalo de notificación inicial .......................231
Configuración de un número de paquetes de notificación inicial.....231
Deshabilitación de IRDP...............................................................................231
Visualización de los ajustes de IRDP.............................................................231
Índice ........................................................................................................................IX-I
Volumen 8:
Traducción de direcciones
Acerca de este volumen v
Convenciones del documento ......................................................................... vi
Convenciones de la interfaz de usuario web ............................................. vi
Convenciones de interfaz de línea de comandos ...................................... vi
Convenciones de nomenclatura y conjuntos de caracteres ...................... vii
Convenciones para las ilustraciones ....................................................... viii
Asistencia y documentación técnica................................................................ ix
Capítulo 1 Traducción de direcciones 1

Introducción a la traducción de direcciones ..................................................... 1
Traducción de direcciones de red de origen .............................................. 1
Traducción de direcciones de red de destino ............................................. 3
NAT-Dst basada en directivas.............................................................. 4
Dirección IP asignada.......................................................................... 6
IP virtual ............................................................................................. 6
Opciones de la traducción basada en directivas ............................................... 7
Ejemplo: NAT-Src desde un conjunto DIP con PAT .................................... 7
Ejemplo: NAT-Src desde un conjunto DIP sin PAT ..................................... 8
Ejemplo: NAT-Src desde un conjunto DIP con desplazamiento de
direcciones.......................................................................................... 8
Ejemplo: NAT-Src desde la dirección IP de la interfaz de salida ................. 9
Ejemplo: NAT-Dst a una dirección IP única con asignación de puerto........ 9
Ejemplo: NAT-Dst a una dirección IP única sin asignación de puerto......... 9
xxviii Contenido
Contenido
Ejemplo: NAT-Dst desde un rango de direcciones IP a una sola

dirección IP....................................................................................... 10
Ejemplo: NAT-Dst entre rangos de direcciones IP .................................... 10
Naturaleza direccional de NAT-Src y NAT-Dst ................................................ 11
Capítulo 2 Traducción de direcciones de red de origen 13

Introducción a NAT-Src .................................................................................. 13
NAT-Src desde un conjunto DIP con PAT habilitada ....................................... 15
Ejemplo: NAT-Src con PAT habilitada ...................................................... 15
NAT-Src desde un conjunto DIP con PAT inhabilitada .................................... 18
Ejemplo: NAT-Src con PAT inhabilitada ................................................... 18
NAT-Src desde un conjunto de DIP con desplazamiento de direcciones......... 20
Ejemplo: NAT-Src con desplazamiento de direcciones............................. 21
NAT-Src desde la dirección IP de la interfaz de salida .................................... 24
Ejemplo: NAT-Src sin DIP ........................................................................ 24
Capítulo 3 Traducción de direcciones de red de destino 27

Introducción a NAT-Dst.................................................................................. 28
Flujo de paquetes para NAT-Dst............................................................... 29
Enrutamiento para NAT-Dst..................................................................... 32
Ejemplo: Direcciones conectadas a una interfaz................................ 33
Ejemplo: Direcciones conectadas a una interfaz
pero separadas por un enrutador................................................ 34
Ejemplo: Direcciones separadas por una interfaz .............................. 34
NAT-Dst: Asignación de “1:1” ........................................................................ 35
Ejemplo: Traducción de destinos “1:1”....................................................36
Traducción de una dirección a múltiples direcciones............................... 38
Ejemplo: Traducción de destinos “1:n” ............................................. 38
NAT-Dst: Asignación de “n:1” ........................................................................ 41
Ejemplo: Traducción de destinos “n:1”....................................................41
NAT-Dst:Asignación de “n:n” ......................................................................... 44
Ejemplo: Traducción de destinos “n:n”....................................................45
NAT-Dst con asignación de puertos................................................................ 47
Ejemplo: NAT-dst con asignación de puertos ........................................... 47
NAT-Src y NAT-Dst en la misma directiva ...................................................... 50
Ejemplo: NAT-Src y NAT-Dst combinadas................................................ 50
Capítulo 4 Direcciones virtuales y asignadas 63

Direcciones IP asignadas................................................................................ 63
MIP y la zona Global ................................................................................ 65
Ejemplo: MIP en una interfaz de la zona Untrust............................... 65
Ejemplo: Acceso a una MIP desde diferentes zonas .......................... 67
Ejemplo: Adición de una MIP a una interfaz de túnel ........................ 70
MIP-Same-as-Untrust ............................................................................... 71
Ejemplo: MIP en la interfaz Untrust................................................... 72
MIP y la interfaz de bucle invertido ......................................................... 74
Ejemplo: MIP para dos interfaces de túnel ........................................ 74
Agrupamiento de MIP.............................................................................. 80
Ejemplo: Agrupamiento de MIP con directivas de celdas múltiples ... 80
Direcciones IP virtuales.................................................................................. 81
VIP y la zona Global................................................................................. 83
Ejemplo: Configuración de servidores de IP virtuales ........................ 83
Ejemplo: Edición de una configuración de VIP .................................. 85
Contenido xxix
Ejemplo: Eliminación de una configuración VIP ................................ 85

Ejemplo: VIP con servicios personalizados y de múltiples puertos .... 85
Índice ........................................................................................................................IX-I
Volumen 9:
Autenticación de usuariosn
Acerca de este manual vii
Capítulo 1 Autenticación 1
Tipos de autenticaciones de usuarios ............................................................... 1
Usuarios con permisos de administrador ......................................................... 2
Usuarios de múltiples tipos .............................................................................. 4
Expresiones de grupos ..................................................................................... 5
Ejemplo: Expresiones de grupos (AND) ..................................................... 6
Ejemplo: Expresiones de grupos (OR)........................................................ 8
Ejemplo: Expresiones de grupos (NOT)......................................................9
Personalización de mensajes de bienvenida .................................................. 10
Ejemplo: Personalizar un mensaje de bienvenida de WebAuth................ 10
Mensaje de bienvenida de inicio de sesión..................................................... 11
Ejemplo: Crear un mensaje de bienvenida de inicio de sesión................. 11
Capítulo 2 Servidores de autenticación 13

Tipos de servidores de autenticación ............................................................. 13
Base de datos local......................................................................................... 15
Ejemplo: Tiempo de espera de la base de datos local .............................. 16
Servidores de autenticación externos............................................................. 17
Propiedades del objeto “servidor de autenticación”................................. 18
Tipos de servidores de autenticación ............................................................. 19
Servicio de autenticación remota de usuarios de acceso telefónico.......... 19
Propiedades del objeto servidor de autenticación RADIUS ................ 20
Características y tipos de usuarios admitidos .................................... 21
Archivo de diccionario de RADIUS ....................................................22
RADIUS Access Challenge .................................................................23
Mejoras de RADIUS compatibles para los usuarios Auth y XAuth ...... 25
SecurID.................................................................................................... 28
Propiedades del objeto servidor de autenticación SecurID ................ 29
Protocolo ligero de acceso a directorios................................................... 30
Propiedades del objeto servidor de autenticación LDAP.................... 31
Sistema plus de control de acceso de control de acceso de terminal Plus
(TACACS+) ....................................................................................... 32
Propiedades del objeto del servidor TACACS+ ................................. 33
Pioridad de la autenticación de administrador ............................................... 33
xxx Contenido
Contenido
Definición de objetos de servidor de autenticación ........................................ 34

Ejemplo: Servidor de autenticación RADIUS ............................................ 34
Ejemplo: Servidor de autenticación SecurID ............................................ 36
Ejemplo: Servidor de autenticación LDAP................................................ 38
Ejemplo: Servidor de autenticación TACACS+ ........................................ 39
Definición de los servidores de autenticación predeterminados..................... 40
Ejemplo: Cambiar los servidores de autenticación predeterminados ....... 41
Capítulo 3 Autenticación de infranet 43

Solución de control de acceso unificado......................................................... 43
Funcionamiento del cortafuegos con el controlador de infranet..................... 45
Configuración de la autenticación de infranet ................................................ 46
Capítulo 4 Usuarios de autenticación 47

Referencias a usuarios autenticados en directivas .......................................... 48
Autenticación en tiempo de ejecución ..................................................... 48
Autenticación de comprobación previa a la directiva (WebAuth) ............. 49
Referencias a grupos de usuarios de autenticación en directivas.................... 50
Ejemplo: Autenticación en tiempo de ejecución (usuario local)................ 51
Ejemplo: Autenticación en tiempo de ejecución (grupo de usuarios
locales)..............................................................................................53
Ejemplo: Autenticación en tiempo de ejecución (usuario externo) ........... 54
Ejemplo: Autenticación en tiempo de ejecución (grupo de usuarios
externos)........................................................................................... 56
Ejemplo: Usuario de autenticación local en múltiples grupos................... 58
Ejemplo: WebAuth (grupo de usuarios locales) ........................................ 61
Ejemplo: WebAuth (grupo de usuarios externos) ..................................... 62
Ejemplo: WebAuth + SSL solamente (grupo de usuarios externos) ......... 65
Capítulo 5 Usuarios IKE, XAuth y L2TP 69

Usuarios y grupos de usuarios IKE .................................................................69
Ejemplo: Definir usuarios IKE .................................................................. 70
Ejemplo: Creación de un grupo de usuarios IKE ...................................... 71
Referencias a usuarios IKE en puertas de enlace ..................................... 72
Usuarios y grupos de usuarios XAuth ............................................................. 72
Registro de eventos para el modo IKE ..................................................... 74
Usuarios XAuth en negociaciones IKE ..................................................... 74
Ejemplo: Autenticación XAuth (usuario local) .................................... 76
Ejemplo: Autenticación de XAuth (grupo de usuarios local)............... 78
Ejemplo: Autenticación XAuth (usuario externo) ............................... 79
Ejemplo: Autenticación XAuth (grupo de usuarios externo)............... 81
Ejemplo: Autenticación y asignación de direcciones
XAuth (Local User Group) ........................................................... 84
Cliente XAuth .......................................................................................... 88
Ejemplo: Dispositivo de seguridad como cliente XAuth..................... 88
Usuarios y grupos de usuarios L2TP ............................................................... 89
Ejemplo: Servidores de autenticación L2TP locales y externos ................ 90
Capítulo 6 Autenticación extensible para interfaces inalámbricas y Ethernet 93

Vista general .................................................................................................. 94
Tipos de EAP admitidos ................................................................................. 94
Habilitación e inhabilitación de la autenticación 802.1X ................................ 95
Contenido xxxi
Interfaces Ethernet .................................................................................. 95

Interfaces inalámbricas............................................................................ 95
Configuración de los ajustes de 802.1X.......................................................... 96
Configuración del control del puerto 802.1X ........................................... 96
Configuración del modo de control de 802.1X ........................................ 97
Ajuste del número máximo de usuarios simultáneos ............................... 97
Configuración del periodo de reautenticación.......................................... 98
Habilitación de las retransmisiones EAP .................................................. 98
Configuración de la cuenta de retransmisiones de EAP ........................... 99
Configuración del periodo de retransmisión de EAP ................................ 99
Configuración del periodo inactivo (sin actividad) ................................... 99
Configuración de las opciones del servidor de autenticación........................100
Especificar un servidor de autenticación................................................100
Interfaces Ethernet..........................................................................100
Interfaces inalámbricas ...................................................................100
Ajuste del tipo de cuenta .......................................................................101
Habilitación de la verificación de zonas .................................................101
Visualizacion de la información de 802.1X ..................................................102
Visualizacion de la información de configuración global de 802.1X.......102
Visualizacion de la información de 8021.X para una interfaz ................103
Visualizacion de estadísticas de 802.1X.................................................103
Visualizacion de estadísticas de la sesión de 802.1X..............................104
Visualizacion de detalles de la sesión de 802.1X....................................104
Ejemplos de configuración ...........................................................................104
Configuración del dispositivo de seguridad con un cliente conectado
directamente y el servidor RADIUS .................................................104
Configuración de un dispositivo de seguridad con un concentrador
entre un cliente y el dispositivo de seguridad..................................105
Configuración del servidor de autenticación con una interfaz
inalámbrica .....................................................................................107
Índice ........................................................................................................................IX-I
Volumen 10:
Sistemas virtuales
Convenciones del documento .......................................................................... v
Convenciones de la interfaz de usuario web .............................................. v
Convenciones de nomenclatura y conjuntos de caracteres ....................... vi
Capítulo 1 Sistemas virtuales 1

Vista general .................................................................................................... 2
Objetos Vsys .................................................................................................... 4
Creación de un objeto Vsys y administrador.............................................. 4
Establecimiento de un enrutador virtual predeterminado para Vsys.......... 6
Enlace de las zonas a un enrutador virtual compartido.............................. 7
Acceso como administrador Vsys..................................................................... 8
Perfiles del sistema virtual ............................................................................... 9
Contadores de sesiones vsys ................................................................... 10
xxxii Contenido
Contenido
Información de sesión de vsys.................................................................10

Comportamiento en pares de alta disponibilidad..................................... 10
Creación de un perfil de vsys................................................................... 11
Establecimiento de límites de recursos ....................................................11
Agregar límites de sesión por medio de asignación de perfiles de vsys ... 13
Establecimiento de una anulación de sesión............................................ 14
Anulación de una alarma de límite de sesiones alcanzado ................ 14
Eliminación de un perfil de vsys .............................................................. 15
Visualización de las configuraciones de vsys ........................................... 15
Visualización de anulaciones............................................................. 15
Visualización de un perfil .................................................................. 16
Visualización de estadísticas de sesión .............................................. 17
Compartir y organizar recursos de la CPU en particiones............................... 18
Configuración del peso de la CPU ............................................................ 19
Flujo de paquetes en modo razonable ..................................................... 20
Volver del modo razonable al modo compartido ..................................... 21
Habilitación de la función de límite de la CPU ......................................... 21
Medición del uso de la CPU ..................................................................... 21
Establecimiento del umbral de utilización de la CPU de modo
compartido a modo razonable .......................................................... 24
Configuración de un método para volver al modo compartido ................ 27
Establecimiento de un peso fijo de la CPU de vsys raíz............................ 28
Vsys y redes privadas virtuales ...................................................................... 29
Visualización de asociaciones de seguridad ............................................. 29
Visualización de las cookies de IKE.......................................................... 30
Programador de directivas ............................................................................. 31
Creación de un programador de directivas .............................................. 31
Vinculación de un programa de directivas a una directiva .......................32
Visualización de programas de directivas ................................................ 32
Eliminación de un programa de directivas............................................... 32
Capítulo 2 Clasificación del tráfico 33

Vista general .................................................................................................. 33
Clasificación del tráfico............................................................................ 33
Clasificación del tráfico de tránsito .......................................................... 34
Interfaces compartidas y dedicadas......................................................... 39
Interfaces dedicadas ......................................................................... 39
Interfaces compartidas...................................................................... 39
Importación y exportación de interfaces físicas ............................................. 41
Importación de una interfaz física a un sistema virtual............................ 41
Exportación de una interfaz física de un sistema virtual .......................... 42
Capítulo 3 Clasificación del tráfico según VLAN 43

Vista general .................................................................................................. 43
Redes VLAN............................................................................................. 44
VLAN con Vsys ........................................................................................ 45
Configuración de sistemas virtuales de capa 2 ............................................... 46
Ejemplo 1: Configuración de un solo puerto...................................... 47
Ejemplo 2: Configuración de dos agregados de 4 puertos con zonas
Untrust separadas....................................................................... 51
Ejemplo 3: Configurar dos agregados de 4 puertos que comparten
una zona Untrust ........................................................................ 57
Definición de subinterfaces y etiquetas VLAN ................................................ 63
Contenido xxxiii
Comunicación entre sistemas virtuales .......................................................... 66

Reetiquetado de VLAN ................................................................................... 70
Ejemplo:............................................................................................ 71
Capítulo 4 Clasificación del tráfico según IP 73

Vista general .................................................................................................. 73
Designación de un rango IP al sistema raíz ....................................................74
Configuración de la clasificación del tráfico según IP ..................................... 75
Índice ........................................................................................................................IX-I
Volumen 11:
Alta disponibilidad
Capítulo 1 Protocolo de redundancia de NetScreen 1

Vista general de la alta disponibilidad .............................................................. 1
Introducción al protocolo NSRP ....................................................................... 2
Ajustes predeterminados de NSRP............................................................. 4
NSRP-Lite .................................................................................................. 4
Ajustes predeterminados de NSRP-Lite ......................................................6
Configuración básica de NSRP ...................................................................6
Mensajes de conexión de control ........................................................ 6
Mensajes de conexión de datos........................................................... 7
Advertencia sobre el enrutamiento dinámico...................................... 8
Sondeos de conexiones dobles............................................................ 9
Clústeres NSRP ..............................................................................................10
Nombres de clúster ................................................................................. 11
Configuración activa/pasiva............................................................... 12
Configuración activa/activa ............................................................... 12
Configuración de malla completa activa/activa.................................. 14
Autenticación y encriptación del clúster de NSRP .................................... 15
Objetos en tiempo de ejecución............................................................... 16
Estados de funcionamiento de réplica de RTO ........................................ 17
Sincronización del clúster de NSRP.......................................................... 18
Sincronización del archivo ................................................................ 19
Sincronización de la configuración....................................................19
Sincronización de ruta ...................................................................... 20
Sincronización de objetos en tiempo de ejecución ............................ 21
Sincronización del reloj del sistema .................................................. 21
Grupos VSD.................................................................................................... 22
Opción de prioridad ................................................................................ 22
Estados de miembros .............................................................................. 23
Mensaje de pulso ..................................................................................... 24
VSI y las rutas estáticas............................................................................ 25
xxxiv Contenido
Contenido
Ejemplos de configuración ............................................................................. 26

Cableado de los dispositivos para el NSRP de malla completa
activa/activa ...................................................................................... 26
Creación de un clúster de NSRP............................................................... 29
Configuración de un clúster NSRP activo/pasivo ...................................... 31
Configuración de un clúster de NSRP activo/activo .................................. 35
Sincronización de RTO manualmente...................................................... 41
Configuración de sondeos de conexión manual....................................... 41
Configuración de sondeos de conexión automática ................................. 42
Capítulo 2 Redundancia de interfaces y conmutación por error 43

Interfaces y zonas redundantes...................................................................... 43
Ajustes del tiempo de espera ................................................................... 44
Interfaces agregadas................................................................................ 45
Cambio en caso de fallo de interfaces ............................................................ 46
Tráfico de la interfaz de respaldo............................................................. 46
Tráfico de interfaz principal..................................................................... 47
Conmutación por error automática del tráfico ......................................... 47
Interfaces serie ........................................................................................ 48
Eliminación de ruta predeterminada................................................. 48
Adición de ruta predeterminada........................................................ 49
Policy Deactivation ........................................................................... 49
Supervisión del cambio por fallo.............................................................. 49
Cambio en caso de fallo de interfaces con seguimiento de IP .................. 51
Cambio en caso de fallo del túnel de activo a respaldo ............................ 51
Cambio en caso de fallo de interfaces con supervisión de túneles VPN ... 51
Supervisión de objetos de NSRP para activar la conmutación por error ......... 52
Módulo de seguridad ............................................................................... 54
Interfaz física........................................................................................... 54
Objetos de zona....................................................................................... 54
Objetos IP sometidos a seguimiento ........................................................ 55
Seguimiento de IP para conmutación por error del dispositivo ................ 57
Cambio en caso de fallo del grupo del dispositivo de seguridad virtual .......... 58
Cambio en caso de fallo del sistema virtual....................................................58
Cambio en caso de fallo del dispositivo.......................................................... 59
Configuración de seguimiento IP para el cambio en caso de fallo del
dispositivo......................................................................................... 60
Configuración de un túnel VPN redundante............................................. 63
Configuración de interfaces de seguridad virtuales .................................. 67
Configuración de túneles activos dobles .................................................. 71
Configuración del cambio en caso de fallo de la interfaz con el
seguimiento de IP ............................................................................. 75
Configuración de los pesos de cambio en caso de fallo del túnel ............. 78
Configuración de la conmutación por error del sistema virtual ................ 84
Índice ........................................................................................................................IX-I
Contenido xxxv
Volumen 12:
WAN, DSL, acceso telefónico e inalámbrico
Convenciones del documento ......................................................................... ix
Capítulo 1 Redes de área extensa 1

Introducción de WAN....................................................................................... 1
Serie .......................................................................................................... 2
T1.............................................................................................................. 3
E1.............................................................................................................. 3
T3.............................................................................................................. 4
E3.............................................................................................................. 5
RDSI .......................................................................................................... 5
Opciones de la interfaz WAN ........................................................................... 7
Tiempo de retención ................................................................................. 9
Suma de comprobación de la trama ........................................................ 10
Indicador de ciclo de inactividad ............................................................. 10
Indicador de inicio/final ........................................................................... 10
Codificación de la línea............................................................................ 11
Codificación de inversión de marcas alternas ................................... 11
Codificación de la línea B8ZS y HDB3 ............................................... 12
Codificación de bytes ........................................................................ 12
Tendido de la línea............................................................................ 12
Modo de trama ........................................................................................ 13
Supertrama para T1 .......................................................................... 13
Supertrama extendida para T1.......................................................... 13
Trama de paridad de bits C para T3 .................................................. 14
Sincronización de reloj ............................................................................ 14
Modo de sincronización de reloj........................................................ 14
Fuente de sincronización de reloj...................................................... 15
Velocidad del reloj interno ................................................................ 16
Inversión del reloj de transmisión ..................................................... 17
Manejo de la señal................................................................................... 17
Señal de bucle invertido .......................................................................... 18
Bucle invertido remoto y local........................................................... 18
Modo de bucle invertido.................................................................... 19
Modo de compatibilidad de CSU ...................................................... 21
Respuesta de bucle invertido remoto ................................................ 22
Respuesta FEAC ................................................................................ 23
Franjas de tiempo.................................................................................... 23
T1 fraccionado .................................................................................. 23
E1 fraccionado .................................................................................. 24
Prueba de tasa de errores por bit............................................................. 24
Opciones de RDSI.................................................................................... 25
Tipo de conmutador.......................................................................... 26
SPID.................................................................................................. 26
Negociación TEI ................................................................................ 26
xxxvi Contenido
Contenido
Número de llamada........................................................................... 27
Valor T310 ........................................................................................ 27
Envío completo ................................................................................. 27
Modo BRI................................................................................................. 28
Modo de línea arrendada .................................................................. 28
Activación de marcador .................................................................... 28
Opciones de marcador ............................................................................ 29
Desactivación de una interfaz WAN......................................................... 30
Encapsulado de la interfaz WAN .................................................................... 30
Protocolo punto a punto .......................................................................... 31
Retransmisión de tramas......................................................................... 31
Control de la conexión de datos de alto nivel de Cisco (Cisco-HDLC)....... 32
Opciones básicas de encapsulado............................................................ 33
Interfaces sin numerar ...................................................................... 33
Configuración de la unidad de transmisión máxima del protocolo .... 34
Configuración de la dirección IP estática ........................................... 34
Mensajes de mantenimientos de conexión ....................................... 34
Opciones de encapsulado PPP.................................................................35
Perfil de acceso PPP.......................................................................... 36
Método de autenticación PPP............................................................ 37
Contraseña........................................................................................ 37
Protocolos de autenticación PPP.............................................................. 37
Protocolo de autenticación de establecimiento de conexión por
desafío........................................................................................ 38
Protocolo de autenticación de contraseña ......................................... 38
Usuario de base de datos local .......................................................... 39
Opciones de encapsulado de retransmisión de tramas ............................ 39
Mensajes de mantenimiento de conexión ......................................... 39
Tipo de LMI de retransmisión de tramas........................................... 40
Creación y configuración de PVC ...................................................... 41
Protocolo de resolución de dirección inversa .................................... 42
Encapsulado de conexión múltiple.................................................................43
Vista general............................................................................................ 43
Configuración básica del grupo de conexión múltiple.............................. 44
Identificador de grupo....................................................................... 44
Tiempo de espera para descartar ...................................................... 45
Umbral de fragmentación .................................................................45
Conexiones mínimas ........................................................................ 46
Pasos básicos de la configuración ..................................................... 47
Unidad reconstruida recibida máxima .............................................. 47
Formato del encabezado de secuencia.............................................. 47
Opciones de configuración de retransmisión de tramas de conexión
múltiple............................................................................................. 48
Pasos básicos de la configuración ..................................................... 48
Asignación de conexión para MLFR .................................................. 49
Reintentos de acuse de recibo........................................................... 50
Temporizador de acuse de recibo ..................................................... 50
Temporizador de saludo.................................................................... 50
Ejemplos de configuración de la interfaz WAN............................................... 50
Configuración de una interfaz serie ......................................................... 51
Configuración de una interfaz T1............................................................. 52
Configuración de una interfaz E1............................................................. 53
Configuración de una interfaz T3............................................................. 53
Configuración de una interfaz E3............................................................. 54
Contenido xxxvii
Configuración de un dispositivo para conectividad de RDSI .................... 54

Paso 1: Selección del tipo de conmutador RDSI....................................... 55
Paso 2: Configuración de un perfil PPP....................................................55
Paso 3: Configuración de la interfaz RDSI BRI ......................................... 55
Acceso telefónico a un solo destino................................................... 56
Acceso telefónico utilizando la interfaz de marcador......................... 56
Uso del modo de línea arrendada...................................................... 60
Paso 4: Enrutamiento de tráfico al destino .............................................. 61
Ejemplos de configuración de encapsulado....................................................62
Configuración del encapsulado PPP......................................................... 63
Configuración del encapsulado MLPPP ....................................................64
Configuración del encapsulado de retransmisión de tramas .................... 65
Configuración del encapsulado MLFR ...................................................... 66
Configuración del encapsulado HDLC de Cisco ........................................ 67
Capítulo 2 Línea de abonado digital 69

Vista general de la línea de abonado digital ................................................... 69
Modo de transferencia asíncrona............................................................. 70
Calidad de servicio ATM.................................................................... 71
Protocolo punto a punto a través de ATM ......................................... 72
Protocolo punto a punto de conexión múltiple.................................. 73
Multitono discreto para las interfaces DSL ............................................... 74
Modo de anexo........................................................................................ 74
Circuitos virtuales .................................................................................... 75
Método VPI/VCI y multiplexado......................................................... 76
PPPoE o PPPoA................................................................................. 76
Dirección IP estática y máscara de red ....................................................77
Interfaz ADSL................................................................................................. 78
Interfaz G.SHDSL ........................................................................................... 79
Modo de bucle invertido .......................................................................... 80
Funcionamiento, administración y mantenimiento ................................. 80
Relación de señal y ruido......................................................................... 81
Ejemplos de configuración de ADSL............................................................... 81
Ejemplo 1: (residencial/comercial pequeño) PPPoA en interfaz de
ADSL................................................................................................. 82
Ejemplo 2: (residencial/comercial pequeño) Puenteo 1483 en interfaz
de ADSL ............................................................................................ 85
Ejemplo 3: (comercial pequeño) Enrutamiento 1483 en interfaz ADSL.... 87
Ejemplo 4: (residencial/comercial pequeño) Respaldo de acceso
telefónico .......................................................................................... 89
Ejemplo 5: (residencial/comercial pequeño) Respaldo de Ethernet .......... 92
Ejemplo 6: (residencial/comercial pequeño) Respaldo de ADSL ............... 95
Ejemplo 7: (comercial pequeño) MLPPP ADSL......................................... 98
Ejemplo 8: (negocio pequeño) Permite acceso a los servidores
locales.............................................................................................101
Ejemplo 9: (sucursal) Túnel VPN a través de ADSL ................................103
Ejemplo 10: (Sucursal) Túnel VPN secundario........................................107
Capítulo 3 Conmutación por error de ISP y recuperación por acceso

telefónico 115
Ajuste de prioridad de ISP para conmutación por error................................115
Definición de condiciones para conmutación por error de ISP .....................116
Configuración de una solución de recuperación por acceso telefónico .........117
xxxviii Contenido
Contenido
Capítulo 4 Red de área local inalámbrica 121

Vista general ................................................................................................122
Diferencias de denominación de interfaz de producto inalámbrico .......123
Configuración básica de la función de red inalámbrica ................................123
Creación de un identificador de conjunto de servicios ...........................124
Supresión de difusión de SSID.........................................................124
Aislamiento de un cliente................................................................125
Configuración del modo de funcionamiento para un transceptor de
2,4 GHz...........................................................................................125
Configuración del modo de funcionamiento para un transceptor de
5 GHz..............................................................................................126
Configuración de la velocidad mínima de transmisión de datos ............126
Configuración de la potencia de la transmisión .....................................127
Reactivación de una configuración WLAN .............................................128
Configuración de la autenticación y la encriptación para SSID .....................128
Configuración de la privacidad equivalente a cable ...............................129
Varias claves WEP...........................................................................129
Configuración de la autenticación abierta .......................................131
Configuración de la autenticación de la clave compartida de
WEP .........................................................................................133
Configuración de acceso protegido de Wi-Fi ..........................................134
Configuración de autenticación de 802.1X para WPA y WPA2........135
Configuración de la autenticación con clave previamente
compartida para WPA o WPA2.................................................136
Especificación del uso de la antena ..............................................................137
Configuración del código de país, canal y frecuencia ...................................138
Uso de canales extendidos ...........................................................................138
Realización de un sondeo del sitio ...............................................................139
Localización de los canales disponibles ........................................................139
Configuración de entradas de lista de control de acceso ..............................140
Configuración de Super G.............................................................................141
Configuración de Atheros XR (rango extendido) ..........................................141
Configuración de la calidad de servicio multimedia de Wi-Fi........................142
Habilitación de WMM ............................................................................142
Configuración de la calidad del servicio de WMM ..................................143
Categorías de acceso ......................................................................143
Ajustes predeterminados de WMM..................................................144
Ejemplo...........................................................................................146
Configuración de los parámetros inalámbricos avanzados ...........................147
Configuración del intervalo de envejecimiento ......................................147
Configuración del intervalo de baliza .....................................................148
Configuración del período de mensaje de indicación de tráfico de
envío...............................................................................................149
Configuración del umbral de ráfagas .....................................................149
Configuración del umbral de fragmentos...............................................149
Configuración del umbral de la solicitud de envío..................................150
Configuración del modo de vía libre para enviar ...................................150
Configuración de la tasa de vía libre para enviar ...................................151
Configuración del tipo de vía libre para enviar ......................................151
Configuración del tiempo de franja........................................................152
Configuración de la longitud del preámbulo ..........................................152
Trabajo con interfaces inalámbricas.............................................................153
Asociación de un SSID a una interfaz inalámbrica .................................153
Asociación de una interfaz inalámbrica a una radio...............................153
Contenido xxxix
Creación de grupos en puente inalámbricos ..........................................154

Desactivación de una interfaz inalámbrica ............................................155
Visualización de la Información de configuración inalámbrica .....................155
Ejemplo 1: Autenticación abierta y encriptación WEP ...........................156
Ejemplo 2: Autenticación de WPA-PSK con Passphrase y
encriptación automática..................................................................157
Ejemplo 3: WLAN en modo transparente ..............................................157
Ejemplo 4: Perfiles múltiples y diferenciados.........................................161
Apéndice A Información de conexión inalámbrica A-I

Números de canal 802.11a ...........................................................................A-I
Canales 802.11b y 802.11g ........................................................................ A-III
Números de canal de modo turbo .............................................................. A-IV
Índice ........................................................................................................................IX-I
Volumen 13:
Servicio general de radio por paquetes
Capítulo 1 GPRS 1
El dispositivo de seguridad como cortafuegos del protocolo de
encapsulamiento de GPRS ......................................................................... 2
Interfaces Gp y Gn ..................................................................................... 2
Interfaz Gi.................................................................................................. 3
Modos de funcionamiento ......................................................................... 4
Compatibilidad con el sistema virtual ........................................................ 5
Protocolo de encapsulamiento de GPRS según directivas................................. 5
Ejemplo: Configuración de directivas para habilitar la inspección de
GTP ..................................................................................................... 6
Objeto de inspección en el protocolo de encapsulamiento de GPRS (GTP) ....... 7
Ejemplo: Creación de un objeto de inspección de GTP .............................. 8
Filtrado de mensajes de GTP............................................................................ 8
Comprobación de coherencia del paquete ................................................. 9
Filtrado de la longitud del mensaje ............................................................ 9
Ejemplo: Ajuste de las longitudes del mensaje de GTP ...................... 10
Filtrado del tipo de mensaje .................................................................... 10
Ejemplo: Permiso y rechazo de los tipos de mensajes.......................10
Tipos de mensaje admitidos.............................................................. 11
Limitación de velocidad de los mensajes ................................................. 12
Ejemplo: Establecimiento de un límite de velocidad ......................... 13
Validación del número de secuencia........................................................ 13
Ejemplo: Habilitación de la validación del número de secuencia....... 14
Fragmentación de IP ............................................................................... 14
xl Contenido
Contenido
Filtrado de paquetes de GTP-en-GTP........................................................ 14

Ejemplo: Habilitación del filtrado de paquetes de GTP-en-GTP .......... 14
Deep Inspection ...................................................................................... 14
Ejemplo: Habilitación de Deep Inspection en la TEID........................ 15
Elementos de información de GTP .................................................................15
Filtrado del nombre de punto de acceso.................................................. 16
Ejemplo: Establecimiento de un APN y un modo de selección .......... 17
Filtrado del prefijo de IMSI ...................................................................... 17
Ejemplo: Configuración de un filtro APN y prefijo de IMSI
combinado ................................................................................. 18
Tecnología de acceso de radio .................................................................18
Ejemplo: Ajuste de un filtro de RAT y APN ........................................ 18
Identidad de área de enrutamiento e información de ubicación de
usuario ..............................................................................................19
Ejemplo: Ajuste de un filtro RAI y APN.............................................. 19
Ejemplo: Ajuste de un filtro ULI y APN .............................................. 19
Restricción de APN .................................................................................. 20
IMEI-SV.................................................................................................... 20
Ejemplo: Ajuste de un filtro IMEI-SV y APN ....................................... 20
Requisitos de protocolo y señalización ....................................................21
Compatibilidad combinada para filtrado IE ............................................. 21
Elementos de información R6 compatibles ............................................. 22
Eliminación de 3GPP R6 IE...................................................................... 24
Ejemplo: Eliminación de R6 .............................................................. 24
Túneles de GTP ..............................................................................................25
Limitación del túnel GTP.......................................................................... 25
Ejemplo: Establecimiento de los límites de túnel GTP .......................25
Inspección de estado ............................................................................... 25
Establecimiento y desmantelamiento del túnel de GTP ..................... 26
Actualización del área de enrutamiento dentro de SGSN................... 26
Conmutación por error del túnel para alta disponibilidad ........................ 26
Limpieza de túneles de GTP colgados ...................................................... 27
Ejemplo: Establecimiento del tiempo de espera para los túneles de
GTP ............................................................................................ 27
Redirección de SGSN y GGSN ......................................................................... 28
Prevención de ataque de sobrefacturación..................................................... 28
Descripción del ataque de sobrefacturación ............................................ 28
Solución del ataque de sobrefacturación.................................................. 30
Ejemplo: Configuración de la característica de prevención de ataque
de sobrefacturación .................................................................... 31
Supervisión de tráfico de GTP ........................................................................ 33
Registro de tráfico ................................................................................... 33
Ejemplo: Habilitación del registro de paquetes de GTP...................... 34
Recuento de tráfico ................................................................................. 35
Ejemplo: Habilitación del recuento de tráfico de GTP........................ 35
Intercepción legal .................................................................................... 36
Ejemplo: Habilitación de intercepción legal....................................... 36
Índice ........................................................................................................................IX-I
Contenido xli
Volumen 14:
Arquitectura de doble pila con IPv6
Audiencia del documento.............................................................................. viii
Convenciones de la interfaz de usuario web ............................................. ix
Convenciones de interfaz de línea de comandos ...................................... ix
Convenciones de nomenclatura y conjuntos de caracteres ........................ x
Convenciones para las ilustraciones ......................................................... xi
Asistencia y documentación técnica............................................................... xii
Capítulo 1 Introducción al protocolo de Internet versión 6 1

Vista general .................................................................................................... 1
Direccionamiento de IPv6................................................................................ 2
Notación.................................................................................................... 2
Prefijos ...................................................................................................... 3
Tipos de dirección ..................................................................................... 3
Direcciones unicast ............................................................................. 3
Direcciones anycast ............................................................................ 4
Direcciones multicast .......................................................................... 4
Encabezados de IPv6 ....................................................................................... 4
Encabezado básico .................................................................................... 4
Encabezados de extensión ........................................................................ 6
Manejo de paquetes de IPv6 ............................................................................ 7
Modos de enrutador y host de IPv6.................................................................. 8
Directivas de encapsulamiento de IPv6............................................................ 8
Capítulo 2 Configuración de IPv6 9

Vista general .................................................................................................. 10
Configuración automática de direcciones ................................................ 10
Identificador único extendido ........................................................... 11
Mensajes de notificación del enrutador ............................................. 11
Mensajes de solicitud del enrutador .................................................. 11
Listas de prefijos ............................................................................... 12
Descubrimiento de vecinos ..................................................................... 12
Tabla de caché de vecinos.................................................................13
Detección de inaccesibilidad del vecino ............................................ 13
Categorías de entrada de vecino ....................................................... 13
Estado de accesibilidad del vecino ....................................................14
Cómo ocurren las transiciones de estado de accesibilidad ................ 15
Habilitación de un entorno de IPv6 ................................................................ 18
Habilitación de IPv6 en el nivel del dispositivo ........................................ 18
Inhabilitación de IPv6 en el nivel del dispositivo...................................... 19
Configuración de un host de IPv6 .................................................................. 19
Asociación de la interfaz de IPv6 a una zona ........................................... 20
Activación del modo host de IPv6............................................................ 20
Establecimiento de un identificador de interfaz....................................... 20
Configuración de la configuración automática de direcciones.................. 21
Configuración del descubrimiento de vecinos.......................................... 21
Configuración de un enrutador de IPv6.......................................................... 22
Asociación de la interfaz de IPv6 a una zona ........................................... 22
xlii Contenido
Contenido
Activación del modo de enrutador de IPv6 .............................................. 22

Establecimiento de un identificador de interfaz....................................... 23
Ajuste de la configuración automática de direcciones.............................. 23
Indicador de notificaciones de enrutadores salientes ........................ 23
Indicador de configuración administrada .......................................... 24
Indicador de configuración de otros parámetros ............................... 24
Inhabilitación de la configuración automática de direcciones .................. 24
Establecimiento de los intervalos de tiempo de notificaciones ................ 25
Intervalo de tiempo accesible notificado ........................................... 25
Intervalo de tiempo de retransmisión notificado............................... 26
Intervalo máximo de notificación...................................................... 26
Intervalo mínimo de notificación ...................................................... 26
Duración del enrutador predeterminada y notificada ........................ 27
Características del paquete de notificación .............................................. 27
Valor de MTU de enlace .................................................................... 27
Límite de saltos actual....................................................................... 28
Notificación de las características del enrutador ...................................... 28
Establecimiento de la dirección de capa de enlace............................ 28
Preferencia de enrutador notificada .................................................. 28
Configuración de los parámetros de descubrimiento de vecinos ............. 29
Detección de inaccesibilidad del vecino ............................................ 29
Caché de sesiones de MAC................................................................ 29
Entradas estáticas de caché de vecinos ............................................. 30
Tiempo accesible base ...................................................................... 30
Tiempo de sondeo ............................................................................ 31
Tiempo de retransmisión .................................................................. 31
Recuento de reintentos de detección de direcciones duplicadas ....... 31
Visualización de los parámetros de interfaz de IPv6....................................... 32
Visualización de las configuraciones de descubrimiento de vecinos ........ 32
Visualización de la configuración actual de RA ........................................ 32
Enrutador de IPv6 ................................................................................... 33
Host de IPv6 ............................................................................................ 33
Capítulo 3 Servicios de conexión y red 35

Vista general .................................................................................................. 36
Protocolo de configuración de host dinámico versión 6 ................................. 36
Identificación única de dispositivo........................................................... 37
Identificación de delegación de prefijo de asociación de identidad .......... 37
Características del prefijo......................................................................... 37
Preferencia del servidor........................................................................... 38
Configuración de un servidor DHCPv6 ....................................................38
Configuración de un cliente DHCPv6 ....................................................... 40
Visualización de las configuraciones de DHCPv6 ..................................... 42
Configuración de los servidores del sistema de nombres de dominio ............ 42
Solicitud de información de DNS y de la lista de búsqueda de DNS ......... 43
Configuración de la división de direcciones DNS proxy ........................... 44
Configuración de PPPoE................................................................................. 46
Establecimiento de fragmentación .................................................................47
Capítulo 4 Enrutamiento estático y dinámico 49

Vista general .................................................................................................. 50
Tablas de enrutamiento doble .................................................................50
Contenido xliii
Enrutamiento estático y dinámico ........................................................... 51

Delegación de prefijos en sentido ascendente y descendente.................. 51
Enrutamiento estático .................................................................................... 52
Configuración de RIPng ................................................................................. 53
Creación y eliminación de una instancia RIPng ....................................... 54
Creación de una instancia RIPng....................................................... 54
Eliminación de una instancia RIPng .................................................. 54
Habilitación y deshabilitación de RIPng en interfaces.............................. 55
Habilitación de RIPng en una interfaz ............................................... 55
Desactivación de RIPng en una interfaz ............................................ 55
Parámetros globales de RIPng........................................................................ 55
Protección contra inundaciones mediante un umbral de actualización.... 59
Parámetros de la interfaz de RIPng ................................................................ 60
Ruta, interfaz y métricas de diferencia ....................................................61
Listas de acceso y mapas de rutas..................................................... 61
Redistribución de rutas estáticas ....................................................... 61
Configuración de horizonte dividido con rutas inalcanzables................... 64
Visualización de información de RIPng y enrutamiento ................................. 64
Visualización de la tabla de enrutamiento................................................ 64
Visualización de la base de datos de RIPng.............................................. 65
Visualización de detalles de RIPng por enrutador virtual ......................... 66
Visualización de detalles de RIPng por interfaz........................................ 67
Visualización de información de vecinos RIPng ....................................... 67
Habilitación de RIPng en interfaces de túnel ........................................... 68
Prevención de bucles de tráfico a un enrutador de ISP ............................ 70
Configuración del equipo de las instalaciones del cliente .................. 71
Configuración de la puerta de enlace ................................................ 74
Configuración del enrutador de ISP................................................... 77
Establecimiento de una redistribución de interfaces Null a OSPF ............ 78
Redistribución de rutas descubiertas a OSPF ........................................... 79
Configuración de importación del resumen de OSPF............................... 79
Capítulo 5 Traducción de direcciones 81

Vista general .................................................................................................. 81
Traducción de direcciones IP de origen ................................................... 82
DIP de IPv6 a IPv4 ............................................................................ 83
DIP de IPv4 a IPv6 ............................................................................ 83
Traducción de direcciones IP destino ...................................................... 84
MIP de IPv6 a IPv4............................................................................ 84
MIP de IPv4 a IPv6............................................................................ 84
Hosts IPv6 a varios hosts IPv4 .................................................................85
Hosts de IPv6 a un host IPv4 individual................................................... 87
Hosts IPv4 a varios hosts IPv6 .................................................................89
Hosts IPv4 a un host IPv6 individual........................................................ 90
Traducción de direcciones para servidores de sistemas de nombres de
dominio ............................................................................................ 92
xliv Contenido
Contenido
Capítulo 6 IPv6 en un entorno IPv4 95

Vista general .................................................................................................. 95
Configuración del encapsulamiento manual................................................... 96
Configuración de encapsulamiento 6a4 ......................................................... 99
Enrutadores 6a4 ...................................................................................... 99
Enrutadores de retransmisión 6a4.........................................................100
Túneles a hosts nativos remotos............................................................100
Túneles a hosts 6a4 remoto...................................................................104
Capítulo 7 Encapsulamiento de IPSec 109

Vista general ................................................................................................109
Encapsulamiento de IPSec 6en6 ..................................................................110
Encapsulamiento manual con fragmentación habilitada ..............................122
Túnel IPv6 a IPv6 con VPN basada en rutas...........................................122
Túnel IPv4 a IPv6 con VPN basada en rutas...........................................125
Capítulo 8 Autenticación de usuarios IPv6 XAuth 129

Vista general ................................................................................................129
RADIUSv6..............................................................................................130
Un solo cliente, un solo servidor .....................................................130
Varios clientes, un solo servidor......................................................130
Un solo cliente, varios servidores ....................................................131
Varios hosts, un solo servidor..........................................................131
Administración de sesiones de acceso IPSec .........................................131
Sesión de acceso IPSec....................................................................132
Activación y desactivación de funcionalidad IAS .............................134
Liberación de una sesión IAS ..........................................................134
Limitación de configuraciones IAS ..................................................134
Detección de interlocutor muerto ..........................................................135
XAuth con RADIUS ................................................................................136
RADIUS con VPN basada en rutas XAuth...............................................137
RADIUS con XAuth y eliminación parcial de nombres de dominio ........141
Asignación del rango de conjunto de IP .................................................145
Reintentos de RADIUS ...........................................................................151
ID de estación de llamada .....................................................................151
Sesión de acceso IPSec ..........................................................................152
Detección de interlocutor muerto ..........................................................161
Apéndice A Conmutación A-I
Índice ........................................................................................................................IX-I
Contenido xlv
xlvi Contenido
Acerca del Manual de referencia de
ScreenOS: conceptos y ejemplos
Los dispositivos de seguridad de Juniper Networks integran el siguiente cortafuegos,

red privada virtual (VPN) y funciones de asignación de tráfico para proporcionar
una protección flexible para las zonas de seguridad cuando se conecta a Internet:
Cortafuegos: Un cortafuegos analiza el tráfico que atraviesa el límite entre una

LAN privada y una red pública, como Internet.
Seguridad en capas: La solución de seguridad en capas se implementa en

diferentes ubicaciones para evitar ataques. Si falla una capa, la siguiente retiene
el ataque. Algunas funciones ayudan a proteger ubicaciones remotas con VPN
de punto a punto. Los dispositivos implementados en el perímetro evitan los
ataques basados en red. Otra capa, con prevención y detección de intrusión
(IDP) y Deep Inspection detecta y evita automáticamente que los ataques
ocasionen daños.
La segmentación de red, la capa final de seguridad (también conocida como

virtualización), divide la red en dominios para proteger los recursos esenciales
de los usuarios de ataques de red y usuarios de itinerancia no autorizados.
Seguridad de contenido: Protege a los usuarios de URL maliciosas y

proporciona el filtro de Web y el análisis antivirus incorporado. Además,
funciona con productos de otros fabricantes que proporcionan filtrado de Web,
anti-spam y análisis de antivirus externo.
VPN: Una VPN ofrece un canal de comunicaciones seguro entre dos o más
dispositivos de red remotos.
Funciones de red integradas: Los protocolos de enrutamiento dinámico

averiguan la accesibilidad y notifican topologías de red que cambian
dinámicamente. Además, la funcionalidad de asignación de tráfico permite la
supervisión y el control administrativos del tráfico que atraviesa el cortafuegos
de Juniper Networks para mantener un nivel de calidad de servicio de red
(QoS).
Administración centralizada: La herramienta Netscreen-Security Manager

simplifica la configuración, implementación y administración de los
dispositivos de seguridad.
xlvii
Redundancia: Alta disponibilidad de interfaces, rutas de encaminamiento,

dispositivos de seguridad y (en dispositivos Juniper Networks de gama alta)
fuentes de alimentación y ventiladores, para evitar la existencia de un único
punto de error en cualquiera de estas áreas.
NOTA: Para obtener más información sobre el cumplimiento de los productos de

Juniper Networks con las normas federales para procesamiento de la información
(FIPS) y para obtener instrucciones sobre configuración de un dispositivo de
seguridad que cumple con FIPS en modo FIPS, consulte el documento de
Directivas de seguridad criptográfica específico de la plataforma en el CD de
documentación.
Figura 1: Funciones clave en ScreenOS
Zona Untrust
LAN LAN
Internet
Redundancia: El dispositivo de
respaldo mantiene una
configuración y unas sesiones
idénticas a las del dispositivo
principal para asumir el puesto del
VPN: Túneles de comunicación dispositivo principal si es necesario.
segura entre dos puntos para el (Nota: las interfaces, las rutas de
tráfico que atraviesa Internet encaminamiento, las fuentes de
alimentación y los ventiladores
Dispositivo de también pueden ser redundantes).
respaldo
Cortafuegos: Análisis del tráfico
entre la LAN protegida e Internet
Asignación de tráfico: priorización

Funciones de red integradas: eficaz del tráfico a medida que
Realiza funciones de atraviesa la pared de fuego
enrutamiento, y se comunica e
interactúa con dispositivos de
enrutamiento del entorno.
LAN Enrutamiento dinámico: Dest Utilice
la tabla de enrutamiento se 0.0.0.0/0 1.1.1.250
Zona Trust actualiza automáticamente
comunicándose con los 1.1.1.0/24 eth3
interlocutores de 1.2.1.0/24 eth2
enrutamiento dinámico.
10.1.0.0/16 trust-vr
10.2.2.0/24 tunnel.1
10.3.3.0/24 tunnel.2
El sistema ScreenOS ofrece todas las funciones necesarias para configurar y

administrar cualquier dispositivo o sistema de seguridad. Este documento es un
manual de referencia para configurar y gestionar un dispositivo de seguridad de
Juniper Networks a través de ScreenOS.
xlviii
Acerca del Manual de referencia de ScreenOS: conceptos y ejemplos
Organización de los volúmenes

El manual de referencia de ScreenOS: conceptos y ejemplos es un manual de varios
volúmenes. A continuación se resume el contenido de cada volumen:
Volumen 1: Vista general
“Contenido” incluye un índice global de todos los volúmenes del manual.
“Índice maestro” es un índice de todos los volúmenes en el manual.
Volumen 2: Fundamentos
Capítulo 1, “Arquitectura de ScreenOS,” describe los elementos fundamentales

de la arquitectura de ScreenOS y se incluye un ejemplo de cuatro partes con el
que se muestra una configuración empresarial que incorpora la mayor parte de
dichos elementos. En éste y en todos los siguientes capítulos, cada concepto va
acompañado de ejemplos ilustrativos.
Capítulo 2, “Zonas,” explica las zonas de seguridad, las zonas de túnel y las
zonas de función.
Capítulo 3, “Interfaces,” describe las diferentes interfaces físicas, lógicas y

virtuales de los dispositivos de seguridad.
Capítulo 4, “Modos de las interfaces,” explica los conceptos relacionados con

los modos de funcionamiento de interfaz transparente, NAT y de rutas.
Capítulo 5, “Bloques para la construcción de directivas,” explica los elementos

utilizados para crear directivas y redes privadas virtuales (VPN): direcciones
(incluyendo direcciones VIP), servicios y conjuntos de DIP. También se incluyen
diversos ejemplos de configuración compatibles con el protocolo H.323.
Capítulo 6, “Directivas,” examina los componentes y las funciones de las

directivas y se ofrecen instrucciones para su creación y aplicación.
Capítulo 7, “Asignación de tráfico,” se explica cómo gestionar el ancho de

banda en los niveles de interfaz y directivas y cómo priorizar servicios.
Capítulo 8, “Parámetros del sistema,” se describen los conceptos relacionados

con el direccionamiento de sistemas de nombres de dominio (DNS), el uso del
protocolo dinámico de configuración de host (DHCP) para asignar o
retransmitir ajustes TCP/IP, la carga y descarga de las configuraciones y el
software del sistema y el ajuste del reloj del sistema.
Organización de los volúmenes xlix

Volumen 3: Administración
Capítulo 1, “Administración,” explica los distintos medios disponibles para

gestionar un dispositivo de seguridad de forma local y remota. En este capítulo
también se explican los privilegios asociados a cada uno de los cuatro niveles
de administradores de red que se pueden definir.
Capítulo 2, “Supervisión de dispositivos de seguridad,” explica los diversos

métodos de supervisión y se ofrecen instrucciones para interpretar los
resultados de dicha supervisión.
Volumen 4: Detección ataques y mecanismos de defensa
Capítulo 1, “Protección de una red,” resume 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,” describe 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,” explica 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,” describe cómo proteger a los

usuarios del protocolo de transferencia de hipertexto (HTTP) frente a los
localizadores uniformes de recursos (URL) maliciosos y cómo configurar el
dispositivo de seguridad para trabajar con productos de otros fabricantes y así
proporcionar análisis antivirus y filtrado de web.
Capítulo 5, “Deep Inspection,” describe cómo configurar el dispositivo de

seguridad para obtener actualizaciones de objetos de ataques Deep Inspection
(DI), 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.
Capítulo 6, “Detección y prevención de intrusiones,” se describe la tecnología

de detección y prevención de intrusiones (IDP) de Juniper Networks, la cual
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,” explica una serie de

opciones SCREEN que bloquean los paquetes potencialmente peligrosos.
Apéndice A, “Contextos para las firmas definidas por el usuario,” proporciona

una lista y descripciones de los contextos que se pueden especificar al definir
un objeto de ataque de firma completa.
l Organización de los volúmenes

Volumen 5: Redes privadas virtuales
Capítulo 1, “Seguridad del protocolo de Internet,” ofrece información sobre

IPSec, presenta una secuencia de flujo para la fase 1 en negociaciones IKE en
los modos dinámico y principal, y concluye con información sobre el
encapsulado de paquetes IKE e IPSec.
Capítulo 2, “Criptografía de claves públicas,” explica la forma de obtención y

carga de certificados digitales y listas de revocación de certificados (CRL).
Capítulo 3, “Directrices para las redes privadas virtuales,” contiene información

útil para seleccionar las opciones VPN disponibles. También contiene un gráfico
de flujo de paquetes para contribuir a desmitificar el procesamiento de
paquetes VPN.
Capítulo 4, “Redes privadas virtuales de punto a punto,” ofrece numerosos

ejemplos de configuraciones VPN para interconectar dos redes privadas.
Capítulo 5, “Redes privadas virtuales de acceso telefónico,” ofrece numerosos

ejemplos de comunicación cliente/LAN mediante AutoKey IKE. También ofrece
información detallada sobre las configuraciones de ID IKE de grupo e ID IKE
compartida.
Capítulo 6, “Protocolo de encapsulamiento de la capa 2,” explica el protocolo

de encapsulamiento de la capa 2 (L2TP), su utilización en solitario y en
conjunto con IPSec (L2TP sobre IPSec).
Capítulo 7, “Funciones avanzadas de redes privadas virtuales,” contiene

información y ejemplos sobre las configuraciones VPN más avanzadas, como
NAT-Traversal, supervisión VPN, asociación de múltiples túneles a una única
interfaz de túnel y diseños de túnel radial y adosado.
Capítulo 8, “Redes privadas virtuales de AutoConnect,” describe la manera en

la cual ScreenOS utiliza los mensajes del protocolo de resolución de salto
siguiente (NHRP) para permitir que los dispositivos de seguridad configuren
VPN de conexión automática según sea necesario. Este capítulo proporciona un
ejemplo de un escenario típico en el cual se podría utilizar AC-VPN.
Volumen 6: Voz sobre el protocolo de Internet (VoIP)
Capítulo 1, “Puerta de enlace en la capa de aplicación H.323,” describe el

protocolo H.323 y proporciona ejemplos de situaciones típicas.
Capítulo 2, “Puerta de enlace de la capa de aplicación del protocolo de inicio de

sesión,” describe el protocolo de inicio de sesión (SIP) y muestra cómo la ALG
con SIP procesa llamadas con los modos de rutas y de traducción de
direcciones de red NAT. Después de un resumen de la arquitectura del SIP se
presentan ejemplos de las situaciones típicas.
Capítulo 3, “Puerta de enlace en la capa de aplicación de protocolo de control

de la puerta de medios,” ofrece una vista general de la ALG del protocolo de
control de la puerta de medios (MGCP) y enumera las funciones de seguridad
de cortafuegos de la implementación. Después de un resumen de la
arquitectura de MGCP se presentan ejemplos de las situaciones típicas.
Organización de los volúmenes li

Capítulo 4, “Puerta de enlace en la capa de aplicación del protocolo Skinny de

control de clientes,” ofrece una vista general de la ALG con el protocolo Skinny
de control de clientes (SCCP) y enumera las funciones de seguridad de
cortafuegos de la implementación. Después de un resumen de la arquitectura
del SCCP se presentan ejemplos de las situaciones típicas.
Volumen 7: Enrutamiento
Capítulo 1, “Enrutamiento estático,” describe la tabla de enrutamiento de

ScreenOS, el proceso de enrutamiento básico que realiza el dispositivo de
seguridad y cómo configurar rutas estáticas en dispositivos de seguridad.
Capítulo 2, “Enrutamiento,” explica cómo configurar los enrutadores virtuales

en los dispositivos de seguridad y cómo redistribuir las entradas de la tabla de
enrutamiento entre protocolos o entre enrutadores virtuales.
Capítulo 3, “Abrir primero la ruta más corta,” describe cómo configurar el

protocolo de enrutamiento dinámico OSPF en los dispositivos de seguridad.
Capítulo 4, “Protocolo de información de enrutamiento,” describe cómo

configurar el protocolo de enrutamiento dinámico RIP en los dispositivos de
seguridad.
Capítulo 5, “Protocolo de puertas de enlace de límite,” describe cómo

configurar el protocolo de enrutamiento dinámico BGP en los dispositivos de
seguridad.
Capítulo 6, “Enrutamiento basado en directivas,” explica la manera de obligar a

que el tráfico interesante pase a lo largo de una ruta específica en la red.
Capítulo 7, “Enrutamiento multicast,” presenta los conceptos básicos sobre el

enrutamiento multicast.
, “Protocolo de administración de grupos de Internet,” describe cómo

configurar el protocolo de administración del grupo de Internet (IGMP) en los
dispositivos de seguridad.
Capítulo 9, “Multicast independiente de protocolo,” describe cómo configurar

el protocolo de enrutamiento de multicast independiente de protocolo (PIM) en
los dispositivos de seguridad.
Capítulo 10, “Protocolo de descubrimiento de enrutador de ICMP,” explica la

forma de configurar un intercambio de mensajes del protocolo de mensajes de
control de Internet (ICMP) entre un host y un enrutador.
Volumen 8: Traducción de direcciones
Capítulo 1, “Traducción de direcciones,” proporciona una vista general de

varias opciones de traducción, las cuales se abarcan en detalle en los capítulos
subsiguientes.
Capítulo 2, “Traducción de direcciones de red de origen,” describe NAT-src, la

traducción de la dirección IP de origen en un encabezado de paquetes, con o
sin traducción de direcciones de puerto (PAT).
lii Organización de los volúmenes

Capítulo 3, “Traducción de direcciones de red de destino,” describe NAT-dst, la

traducción de la dirección IP de destino en un encabezado de paquetes, con o
sin asignación de dirección de puerto de destino. Esta sección incluye también
información sobre el flujo de paquetes cuando realiza NAT-scr, consideraciones
de enrutamiento y cambio de direcciones.
Capítulo 4, “Direcciones virtuales y asignadas,” describe la asignación de una

dirección IP de destino a otra en base a la dirección IP exclusiva (IP asignada) o
en base a la dirección IP de destino y el número de puerto de destino (IP
virtual).
Volumen 9: Autenticación de usuariosn
Capítulo 1, “Autenticación,” detalla los distintos usos y métodos de

autenticación que admite ScreenOS.
Capítulo 2, “Servidores de autenticación,” presenta las opciones de utilización

de cada uno de los tres tipos de servidor posibles (RADIUS, SecurID o LDAP) o
de la base de datos interna y muestra cómo configurar el dispositivo de
seguridad para trabajar con cada tipo.
Capítulo 3, “Autenticación de infranet,” describe cómo se implementa el

dispositivo de seguridad en una solución de control de acceso unificado (UAC).
La solución de control de acceso unificado (UAC) de Juniper Networks garantiza
y asegura la entrega de aplicaciones y servicios a través de Infranet
empresarial.
Capítulo 4, “Usuarios de autenticación,” explica cómo definir los perfiles para

los usuarios de autenticación y cómo agregarlos a los grupos de usuarios
almacenados localmente o en un servidor de autenticación RADIUS externo.
Capítulo 5, “Usuarios IKE, XAuth y L2TP,” explica cómo definir usuarios IKE,
XAuth y L2TP. Aunque la sección XAuth se centra sobre todo en el uso del
dispositivo de seguridad como servidor de XAuth, también incluye una
subsección sobre la configuración de determinados dispositivos de seguridad
actuando como clientes XAuth.
Capítulo 6, “Autenticación extensible para interfaces inalámbricas y Ethernet,”

explica las opciones disponibles y los ejemplos sobre la forma de utilizar el
protocolo de autenticación extensible (EAP) para autenticar interfaces
inalámbricas y Ethernet.
Volumen 10: Sistemas virtuales
Capítulo 1, “Sistemas virtuales,” abarca los sistemas virtuales, objetos y tareas

administrativas.
Capítulo 2, “Clasificación del tráfico,” explica cómo ScreenOS ordena el tráfico.
Capítulo 3, “Clasificación del tráfico según VLAN,” describe la clasificación de

tráfico basado en VLAN para sistemas virtuales y reetiquetación de VLAN.
Capítulo 4, “Clasificación del tráfico según IP,” explica la clasificación de tráfico

basado en IP para sistemas virtuales.
Organización de los volúmenes liii

Volumen 11: Alta disponibilidad
Capítulo 1, “Protocolo de redundancia de NetScreen,” explica cómo cablear,

configurar y administrar dispositivos de seguridad de Juniper Networks en un
grupo redundante para proporcionar alta disponibilidad (HA) mediante el
protocolo de redundancia de Netscreen (NSRP).
Capítulo 2, “Redundancia de interfaces y conmutación por error,” describe las

distintas formas en que los dispositivos de seguridad de Juniper Networks
proporcionan redundancia de interfaces.
Volumen 12: WAN, DSL, acceso telefónico e inalámbrico
Capítulo 1, “Redes de área extensa,” describe cómo configurar una red de área
extensa (WAN).
Capítulo 2, “Línea de abonado digital,” describe la interfaz de línea asimétrica

de abonado digital (ADSL) en la interfaz del dispositivo de seguridad. ADSL es
una tecnología de línea de abonado digital (DSL) que permite que las líneas
telefónicas transmitan servicios de telefonía de voz y transmisión digital de alta
velocidad.
Capítulo 3, “Conmutación por error de ISP y recuperación por acceso

telefónico,” describe cómo establecer prioridades y definir condiciones para la
conmutación por errores del ISP y cómo configurar una solución de
recuperación de acceso telefónico.
Capítulo 4, “Red de área local inalámbrica,” describe las interfaces

inalámbricas en los dispositivos inalámbricos de Juniper Networks y
proporciona configuraciones de ejemplo.
Apéndice A, “Información de conexión inalámbrica,” enumera los canales,

frecuencias y dominios reguladores disponibles y también los canales que
están disponibles en los dispositivos inalámbricos para cada país.
Volumen 13: Servicio general de radio por paquetes
Capítulo 1, “GPRS,” describe las funciones del protocolo de encapsulamiento

de GPRS (GTP) en ScreenOS y demuestra cómo configurar la funcionalidad de
GTP en un dispositivo de seguridad de Juniper Networks.
Volumen 14: Arquitectura de doble pila con IPv6
Capítulo 1, “Introducción al protocolo de Internet versión 6,” explica los

encabezados de IPv6, conceptos y lineamientos de encapsulamiento.
Capítulo 2, “Configuración de IPv6,” explica cómo configurar una interfaz para

que funcione como un host o enrutador de IPv6.
Capítulo 3, “Servicios de conexión y red,” explica cómo configurar el protocolo

de Configuración del host dinámico versión 6 (DHCPv6), servicios de nombre
de dominio (DNS), protocolo de punto a punto sobre Ethernet (PPPoE) y
fragmentación.
liv Organización de los volúmenes

Capítulo 4, “Enrutamiento estático y dinámico,” explica cómo configurar un

enrutamiento estático y dinámico. Este capítulo explica la compatibilidad de
ScreenOS para el protocolo de información de enrutamiento de siguiente
generación (RIPng).
Capítulo 5, “Traducción de direcciones,” explica cómo utilizar la traducción de

direcciones de red (NAT) con dirección IP dinámica (DIP) e IP asignada (MIP)
para atravesar los límites IPv4/IPv6.
Capítulo 6, “IPv6 en un entorno IPv4,” explica el encapsulamiento manual y

dinámico.
Capítulo 7, “Encapsulamiento de IPSec,” explica cómo configurar el

encapsulamiento de IPSec para conectar a host diferentes.
Capítulo 8, “Autenticación de usuarios IPv6 XAuth,” explica cómo configurar el

servicio remoto de autentificación de usuarios de acceso telefónico (RADIUS) y
la administración de sesiones de acceso de IPSec (IAS).
Apéndice A, “Conmutación,” enumera las opciones para utilizar el dispositivo

de seguridad como un conmutador para pasar el tráfico de IPv6.
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 lvi
“Convenciones de interfaz de línea de comandos” en la página lvi
“Convenciones de nomenclatura y conjuntos de caracteres” en la página lvii
“Convenciones para las ilustraciones” en la página lviii
Convenciones del documento lv

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.
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.
lvi Convenciones del documento

NOTA: Para introducir palabras clave, basta con introducir los primeros caracteres para
identificar la palabra de forma inequívoca. Al escribir set adm u whee j12fmt54
se ingresará el comando set admin user wheezer j12fmt54. Sin embargo, todos
los comandos documentados aquí se encuentran presentes en su totalidad.
Convenciones 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:
Conjuntos de caracteres de un byte (SBCS) y conjuntos de caracteres de

múltiples bytes (MBCS). Algunos ejemplos de SBCS son los conjuntos de
caracteres ASCII, europeo y hebreo. Entre los conjuntos MBCS, también
conocidos como conjuntos de caracteres de doble byte (DBCS), se encuentran
el chino, el coreano y el japonés.
Caracteres ASCII desde el 32 (0x20 en hexadecimal) al 255 (0xff); a excepción

de las comillas dobles ( “ ), que tienen un significado especial como
delimitadores de cadenas de nombres que contengan espacios.
NOTA: Una conexión de consola sólo admite conjuntos SBCS. La WebUI admite tanto
SBCS como MBCS, según el conjunto de caracteres que admita el explorador.
Convenciones del documento lvii

Convenciones para las ilustraciones

La siguiente figura muestra el conjunto básico de imágenes utilizado en las
ilustraciones de este volumen:
Figura 2: Imágenes de las ilustraciones
Sistema autónomo Red de área local (LAN) con

o bien una única subred
dominio de enrutamiento virtual o bien
zona de seguridad
Rango dinámico de IP (DIP)

Internet
Interfaces de zonas de seguridad: Motor de directivas

Blanco = Interfaz de zona protegida
(ejemplo = zona Trust)
Negro = Interfaz de zona externa
(ejemplo = zona Untrust)
Dispositivo de red genérico
Interfaz de túnel
Servidor
Túnel VPN
Enrutador
Dispositivos de seguridad
Conmutador Juniper Networks
Concentrador
lviii Convenciones del documento

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.
Asistencia y documentación técnica lix

lx Asistencia y documentación técnica

Índice maestro
Numerics AES ................................................................................ 5-7
3DES ............................................................................. 5-6 Agente de NSM ................................................ 3-23, 3-24
6a4 comunicar eventos .............................................. 3-26
Direcciones ................................. 14-8, 14-99, 14-104 habilitar ................................................................ 3-25
encapsulamiento ....................................14-95, 14-99 agentes zombie ................................................ 4-29, 4-31
encapsulamiento, descripción ......................... 14-99 Agregador de nivel superior (TLA) ......................... 14-37
enrutadores ........................................................ 14-99 Agregador local de sitio (SLA)..................... 14-37, 14-39
enrutadores de retransmisión ......................... 14-99 AH .......................................................................... 5-3, 5-6
hosts ................................................................. 14-104 AIM ............................................................................ 4-135
ajustes de configuración, requisitos del
A explorador ................................................................. 3-2
a una zona con NAT basada en interfaces .............. 2-94 Ajustes de L2TP, DNS .............................................. 5-217
acciones de ataque .....................................4-143 a 4-151 ajustes predeterminados de fábrica, restablecer ... 3-44
close .................................................................... 4-143 alarmas
close client ......................................................... 4-144 alerta de correo electrónico ............................... 3-73
close server ........................................................ 4-143 comunicar a NetScreen-Security Manager ....... 3-26
drop .................................................................... 4-144 tráfico .........................................................3-73 a 3-76
drop packet ........................................................ 4-144 umbrales ............................................................... 3-73
ignore.................................................................. 4-144 alarmas de tráfico ...........................................3-73 a 3-76
none .................................................................... 4-144 alarmas, umbrales ................................................... 2-174
ACL .......................................................................... 12-140 ALG .................................................................... 4-59, 6-17
Actualización del motor IDP ................................... 4-239 MS RPC ............................................................... 2-130
Actualizaciones de la base de datos de ataques para servicios personalizados .......................... 2-169
descargar ............................................................ 4-239 RTSP.................................................................... 2-132
introducción ....................................................... 4-238 SIP ......................................................................... 6-13
adaptadores virtuales ................................................ 9-73 SIP NAT................................................................. 6-24
administración Sun RPC .............................................................. 2-129
CLI ......................................................................... 3-10 almacenamiento en segundo plano ...................... 3-100
restringir ............................................................... 3-45 almacenamiento flash interno ................................. 3-60
WebUI ..................................................................... 3-2 alta disponibilidad
Administración en base a funciones cableado ................................................11-26 a 11-29
Bases de normas de IDP .................................. 4-188 conexión de datos ............................................... 11-8
Configuración de un administrador sólo de interfaces virtuales ............................................ 11-28
IDP .................................................................... 4-237 mensajes .............................................................. 11-7
administración, vsys ................................................. 10-8 seguimiento de IP.............................................. 11-55
administrador fiduciario ....................................... 12-115 sondeo de conexiones ........................................ 11-9
administrador raíz, inicio de sesión ........................ 3-45 alta disponibilidad (HA)................................. 13-4, 13-26
administradores ......................................................... 10-2 análisis antivirus .............................................4-62 a 4-88
cambiar contraseñas..................................10-4, 10-8 descompresión .................................................... 4-92
tipos ...................................................................... 10-4 extensiones de archivo ....................................... 4-93
ADSL FTP ........................................................................ 4-73
configuración de la interfaz ............................. 12-78 goteo HTTP .......................................................... 4-87
introducción ....................................................... 12-78 HTTP ..................................................................... 4-74
Túnel VPN ........................................................ 12-103 HTTP “keep-alive” ............................................... 4-86
Advanced Encryption Standard (AES) ....................... 5-7 IMAP ..................................................................... 4-76
Índice maestro IX-I

MIME .................................................................... 4-75 asociaciones de seguridad

modo de fallo ...................................................... 4-85 véase SA
POP3..................................................................... 4-76 asociaciones de seguridad (SA) .............................. 3-102
recursos de AV por cliente ................................. 4-84 ataques
SMTP .................................................................... 4-78 asignación de grandes cantidades de paquetes
suscripción ........................................................... 4-81 simultáneos de la tabla de sesiones ............... 4-19
análisis FIN ................................................................. 4-16 direcciones MAC desconocidas ......................... 4-43
ancho de banda ....................................................... 2-175 DOS ............................................................4-29 a 4-56
administrar ........................................................ 2-195 etapas ..................................................................... 4-2
garantizado ................................. 2-175, 2-195, 2-201 Fragmentos de paquetes IP ............................. 4-247
máximo ....................................... 2-175, 2-195, 2-201 Fragmentos SYN................................................ 4-248
máximo, ilimitado ............................................ 2-196 ICMP
prioridad fragmentos.................................................... 4-243
de banda ....................................................... 2-200 inundaciones .................................................. 4-49
niveles ........................................................... 2-200 inundación de la tabla de sesiones ................... 4-30
predeterminadas .......................................... 2-200 Inundaciones SYN ....................................4-37 a 4-43
anomalías en el protocolo ...................................... 4-138 Inundaciones UDP .............................................. 4-51
ALG ..................................................................... 4-136 objetivos comunes ................................................ 4-1
Aplicaciones de mensajería inmediata ........... 4-135 opciones de detección y defensa ...............4-2 a 4-5
Aplicaciones P2P ............................................... 4-135 paquetes ICMP grandes .................................... 4-244
configuración de parámetros .......................... 4-167 Ping of Death ....................................................... 4-53
protocolos admitidos ........................... 4-133 a 4-137 protocolos desconocidos .................................. 4-246
protocolos básicos de red ................................ 4-133 repetición ............................................................. 5-12
APN Teardrop ............................................................... 4-54
filtrado ................................................... 13-16 a 13-17 terrestres .............................................................. 4-52
modo de selección ............................................ 13-16 WinNuke .............................................................. 4-55
applets Java, bloquear ............................................. 4-174 Ataques de sobrefacturación .....................13-28 a 13-30
Archivos de ayuda ....................................................... 3-2 descripción ......................................................... 13-28
archivos exe, bloquear ............................................ 4-174 prevención ............................................13-28 a 13-33
archivos MIB, importación ..................................... 5-262 prevención, configuración ............................... 13-31
archivos zip, bloquear ............................................. 4-174 soluciones .......................................................... 13-30
Áreas OSPF ................................................................ 7-48 ATM ........................................................................... 12-71
definición ............................................................. 7-54 atributos específicos de cada fabricante ................. 9-22
interfaces, asignación a ...................................... 7-55 Autenticación .............................. 14-109, 14-113, 14-136
ARP ..................................................................2-82, 11-55 algoritmos ........................5-6, 5-53, 5-57, 5-60, 5-63
consulta .............................................................. 11-40 Allow Any ........................................................... 2-173
difusiones ........................................................... 11-30 directivas ............................................................ 2-172
ARP, dirección IP de entrada .................................... 2-84 usuarios .............................................................. 2-172
Arquitectura de doble pila ...................................... 14-50 autenticación
áreas troncales de WAN, distintas .................. 14-50 dar prioridad ........................................................ 9-33
redes, distintas .................................................. 14-50 NSRP ................................................................... 11-30
tablas de enrutamiento .................................... 14-50 NSRP-Lite ........................................................... 11-15
asignación Autenticación de RSA ............................................ 14-119
host, IPv4 a IPv6 ............................................... 14-90 Autenticación en infranet ......................................... 9-46
host, IPv6 a IPv4 ............................................... 14-87 autenticación en tiempo de ejecución .........2-172, 9-48
red, IPv4 a IPv6 ................................................. 14-89 Autenticación y encriptación
asignación de grandes cantidades de paquetes Varias claves WEP ........................................... 12-129
simultáneos de la tabla de sesiones ..................... 4-19 Wi-Fi Protected Access
asignación de host de IPv6 a IPv4 ........................ 14-87 véase WPA
asignación de prioridades ........................................ 9-33 Wireless Equivalent Privacy
asignación de tráfico ............................................... 2-195 véase WEP
automática ......................................................... 2-196 Autenticación y encriptación con servidor
prioridades del servicio .................................... 2-200 RADIUS ................................................................ 12-130
IX-II Índice maestro

Índice maestro
autenticación, servidores de Bloque de mensajes del servidor

véase servidores de autenticación Consulte SMB
autenticación, usuarios de Bobinadora LPR ....................................................... 4-134
véase usuarios de autenticación bypass-auth ................................................................ 9-74
B C
barrida de puertos ....................................................... 4-9 cables serie ................................................................. 3-19
barrido de direcciones ................................................ 4-8 cambio en caso de fallo
base de datos de objetos de ataque .........4-124 a 4-132 dispositivos ........................................................ 11-59
actualización automática .......................4-127, 4-128 grupos VSD......................................................... 11-58
actualización inmediata.................................... 4-127 interfaces Dual Untrust ......................... 11-46, 11-49
actualización manual ........................................ 4-130 sistemas virtuales .............................................. 11-58
cambiar la URL predeterminada ..................... 4-130 supervisión de objetos ...................................... 11-52
notificación automática y actualización cambio en caso de fallo de alta disponibilidad
manual ............................................................. 4-129 activa/activa ....................................................... 11-12
base de datos local activa/pasiva ...................................................... 11-12
tiempo de espera ................................................ 9-16 cambio en caso de fallo del dispositivo ................ 11-59
tipos de usuarios admitidos ............................... 9-16 Canales, encontrar disponibles ............................ 12-139
usuarios IKE ......................................................... 9-70 Canales extendidos, configuración para
Base de normas de exclusión WLAN ................................................................... 12-138
Adición a una directiva de seguridad ............. 4-206 canales y códigos de países .................................. 12-138
introducción ....................................................... 4-205 Capa de adaptación ATM 5 ..................................... 12-78
Base de normas de puerta de atrás capturas SNMP
Adición a una directiva de seguridad ............. 4-211 100, problemas de hardware............................. 3-80
introducción ....................................................... 4-210 200, problemas de cortafuegos ......................... 3-80
Bases de normas de IDP 300, problemas de software .............................. 3-80
Adición a una directiva de seguridad ............. 4-192 400, problemas de tráfico .................................. 3-80
Administración en base a funciones ............... 4-188 500, problemas de VPN...................................... 3-80
introducción ....................................................... 4-191 alarma de tráfico ................................................. 3-79
tipos .................................................................... 4-187 alarma del sistema .............................................. 3-79
BGP permitir o denegar .............................................. 3-81
atributos de ruta ................................................ 7-111 tipos ...................................................................... 3-80
comunidades ..................................................... 7-133 carga de seguridad encapsulada
confederaciones ................................................ 7-131 véase ESP
configuraciones, seguridad .............................. 7-120 certificado local .......................................................... 5-25
configuraciones, verificación ........................... 7-119 certificados ................................................................... 5-8
enrutador ........................................................... 7-112 CA ................................................................ 5-22, 5-25
enrutador virtual, creación de una instancia carga ..................................................................... 5-28
en ...................................................................... 7-113 carga de CRL ........................................................ 5-23
equilibrio de carga .............................................. 7-37 local ....................................................................... 5-25
expresiones regulares ....................................... 7-124 petición ................................................................. 5-26
interno ................................................................ 7-112 por medio del correo electrónico ...................... 5-25
introducción al protocolo ................................. 7-110 revocación .................................................. 5-25, 5-35
lista de acceso AS-path ..................................... 7-124 certificados de CA ............................................ 5-22, 5-25
parámetros ......................................................... 7-122 Challenge Handshake Authentication Protocol
tipos de mensaje ............................................... 7-110 véase CHAP
vecinos, autenticación ...................................... 7-120 CHAP ....................................................5-213, 5-217, 9-84
BGP, configuración Chargen ..................................................................... 4-133
grupos de interlocutores................................... 7-115 circuito virtual
interlocutores ..................................................... 7-115 véase VC
pasos ................................................................... 7-112 circuitos de demanda, RIP ...................................... 7-101
BGP, habilitación clasificación del tráfico según IP ............................ 10-73
en interfaz .......................................................... 7-114 clasificación del tráfico según
en VR .................................................................. 7-113 VLAN ............................................. 10-42, 10-43 a 10-69
Índice maestro IX-III

clave manual Configuración automática de direcciones sin

administración ...................................................... 5-7 estado ..................................................................... 14-11
claves configuración de modos ........................................... 9-74
manuales .................................................5-120, 5-127 configuración en malla completa .......................... 11-59
previamente compartidas ................................ 5-165 configuración punto a multipunto
claves de licencia ..................................................... 2-253 OSPF ..................................................................... 7-71
actualización del patrón de ataques ............... 4-122 configuraciones
modo avanzado ................................................. 4-122 malla completa .................................................. 11-59
claves manuales......................................................... 9-14 conjuntos de DIP
claves manuales, VPN ......................................3-46, 3-84 consideraciones sobre direcciones ................... 8-14
claves previamente compartidas ....................5-8, 5-165 interfaces extendidas ........................................ 5-143
claves software ........................................................ 10-39 NAT para VPNs .................................................. 5-143
claves, vsys ............................................................... 10-39 NAT-src ................................................................... 8-1
CLI ........................................................ 3-10, 14-30, 14-32 tamaño ................................................................. 8-14
CLI, set arp always-on-dest..............................2-73, 2-76 Conjuntos de direcciones IP
CLI, set vip multi-port ............................................... 8-82 véase Conjuntos de DIP
clientes SecurID consola ........................................................................ 3-60
reintentos ............................................................. 9-29 consulta de rutas
tiempo de espera ................................................ 9-29 múltiple VR .......................................................... 7-35
clústeres .........................................................11-11, 11-35 secuencia .............................................................. 7-33
Clústeres NSRP .............................................11-31, 11-35 contenedores............................................................ 5-193
nombres ..................................................11-11, 11-29 contraseñas
código de autenticación de mensajes basado en administrador raíz............................................... 3-43
hash ............................................................................ 5-6 olvidadas .............................................................. 3-41
Códigos de país y canales, dominio regulador .. 12-138 contraseñas del administrador, cambiar .......10-4, 10-8
códigos token ............................................................. 9-28 Controlador de infranet
comodines .....................................................5-192, 13-16 acciones ................................................................ 9-45
CompactFlash ............................................................ 3-60 directivas de recursos ......................................... 9-45
compatibilidad con el sistema virtual ..................... 13-5 introducción ......................................................... 9-44
Compatibilidad de CSU, interfaces T3 .................. 12-21 controles ActiveX, bloqueo ..................................... 4-173
comprobación contra reprocesamiento de Cookies SYN ............................................................... 4-47
paquetes .........................................................5-55, 5-61 CRL
comprobación de SYN ......................... 4-16, 4-16 a 4-19 véase Lista de revocación de certificados
agujero de reconocimiento ................................ 4-18
asignación de grandes cantidades de paquetes D
simultáneos de la tabla de sesiones ............... 4-19 Datos de NSRP
enrutamiento asimétrico .................................... 4-18 conexión............................................................... 11-8
interrupción de sesión ........................................ 4-18 mensajes .............................................................. 11-7
comunidad SNMP DDoS ........................................................................... 4-29
privada ................................................................. 3-82 Deep Inspection (DI) ..................................4-140 a 4-165
pública .................................................................. 3-82 acciones de ataque...............................4-143 a 4-151
Concentrador de acceso (AC) ................................. 14-46 anomalías en el protocolo ................................ 4-138
conexión principal ................................................... 3-102 base de datos de objetos de ataque ...4-124 a 4-132
confidencialidad directa perfecta cambio de gravedad ......................................... 4-140
véase PFS claves de licencia .............................................. 4-122
configuración contexto .................................................................. 4-I
ADSL 2/2+ PIM................................................. 12-78 desactivar objetos de ataque ........................... 4-142
circuitos virtuales .............................................. 12-75 expresiones regulares ..........................4-161 a 4-162
Par VPI/VCI ........................................................ 12-76 firmas completas ............................................... 4-137
Configuración automática firmas de secuencias ........................................ 4-138
configuración automática de direcciones ...... 14-11 firmas personalizadas ..........................4-161 a 4-165
mensajes de notificación del enrutador ......... 14-11 grupos de objetos de ataque ............................ 4-139
sin estado ........................................................... 14-11 introducción ....................................................... 4-120
negación de objetos de ataque ........................ 4-168
IX-IV Índice maestro

Índice maestro
objetos de ataque .............................................. 4-122 dirección local de conexión .................................... 14-12

objetos de ataque personalizados ................... 4-160 Direcciones
paquetes de firmas ........................................... 4-124 asignaciones L2TP ............................................... 9-89
registro de grupos de objetos de ataque ........ 4-154 Configuración automática ................................ 14-11
servicios personalizados ......................4-156 a 4-160 definidas ............................................................. 2-168
volver a habilitar objetos de ataque ................ 4-143 división ............................................................... 14-44
Denegación de servicio en directivas ....................................................... 2-168
véase DoS entradas en la libreta de
DES ................................................................................ 5-6 direcciones ..........................................2-104 a 2-108
descompresión, análisis antivirus............................ 4-92 IP, identificaciones de host y de red ................. 2-46
Descubrimiento de vecinos (ND) ........................... 14-29 local de conexión .............................................. 14-12
aceptar RA entrantes ........................................ 14-21 MAC .............................................14-13, 14-21, 14-29
antigüedad de la entrada del vecino ............... 14-13 Período de vigencia de la dirección IP para los
definición ........................................................... 14-12 usuarios XAuth .................................................. 9-74
estado de accesibilidad ..................................... 14-29 privadas ................................................................ 2-46
estado de accesibilidad del vecino .......14-13, 14-30 públicas................................................................. 2-45
habilitar .............................................................. 14-29 Direcciones de protocolo de Internet (IP)
omisión de caché de sesión de MAC .............. 14-29 véase direcciones IP
paquetes en cola para transmisión ................. 14-13 Direcciones del sistema de nombre de dominio (DNS)
tabla de caché de vecinos .....................14-13, 14-29 división ................................................... 14-44, 14-45
Descubrimiento de vecinos (ND), mostrar ........... 14-32 traducción .......................................................... 14-92
Detección de dirección duplicada (DAD) Direcciones globales unicast .................... 14-99, 14-119
función ............................................................... 14-31 Direcciones IP
recuento de reintentos ..................................... 14-31 Administrar .......................................................... 2-95
detección de inaccesibilidad de vecinos (NUD) ... 14-13 extendidas .......................................................... 5-143
Tabla de caché de vecinos ............................... 14-25 identificaciones de host ...................................... 2-46
Detección de inaccesibilidad de vecinos (NUD), identificaciones de la red ................................... 2-46
tabla de caché de vecinos .................................... 14-13 interfaces, seguimiento a ................................... 2-62
Detección y prevención de intrusión, definida .... 4-175 IP administrativa ................................................. 3-33
DHCP ....................................... 2-96, 2-100, 2-246, 4-134 privadas ................................................................ 2-45
agente de retransmisión................................... 2-227 públicas................................................................. 2-45
cliente ................................................................. 2-227 puertos, definición para cada uno................... 2-104
Escenario PXE ................................................... 2-239 rangos de direcciones privadas ......................... 2-46
HA ....................................................................... 2-234 secundarias .......................................................... 2-49
servidor .............................................................. 2-227 secundarias, enrutamiento entre ...................... 2-50
DHCPv6 secundarios .......................................................... 2-49
cliente y servidor. .............................................. 14-36 Servidores de NetScreen-Security Manager ..... 3-26
prefijos delegados ............................................. 14-38 zonas de seguridad L3 .............................2-45 a 2-46
propósitos .......................................................... 14-35 direcciones IP de cliente de administración ........... 3-44
TLA y SLA ........................................................... 14-37 direcciones IP secundarias ....................................... 2-49
Diffie-Hellman ............................................................ 5-11 Direcciones IP, virtuales ............................................ 8-81
Diffie-Hellman, grupos .......................................... 14-119 direcciones locales de conexión ............................ 14-14
DiffServ .............................................. 2-176, 2-202, 2-216 Direcciones MAC ...............................14-13, 14-21, 14-29
véase también DS Codepoint Marking direcciones privadas .................................................. 2-46
DIP...........................................2-99, 2-142 a 2-146, 3-101 direcciones públicas .................................................. 2-45
conjuntos ............................................................ 2-171 direcciones XAuth
grupos ....................................................2-155 a 2-158 asignaciones ......................................................... 9-73
PAT ..........................................................2-143, 2-144 autenticación, y ................................................... 9-84
puerto fijo ........................................................... 2-145 período de vigencia de la dirección IP ...9-74 a 9-76
rangos, modificación ........................................ 2-145 tiempo de espera................................................. 9-74
dirección IP asignada Direcciones, manejo
véase MIP DIP de IPv4 a IPv6 ............................................ 14-83
dirección IP estática ................................................ 12-79 DIP de IPv6 a IPv4 ............................................ 14-83
Dirección IP ISP y máscara de red ........................ 12-77 encapsulamiento 4en6 ................................... 14-114
Índice maestro IX-V

encapsulamiento 6a4 ..................................... 14-101 rechazo ............................................................... 2-168

encapsulamiento manual ................................. 14-96 recuento ............................................................. 2-174
Hosts IPv4 a un solo host IPv6 ...................... 14-110 registro de tráfico .............................................. 2-174
Hosts IPv6 a varios hosts IPv4 ........................ 14-86 reglas internas ................................................... 2-166
traducción de direcciones de destino ............. 14-84 reordenar ........................................................... 2-193
direcciones, negación ............................................. 2-189 sección central ..........................................4-18, 4-123
direcciones, rangos superpuestos de .........10-64, 10-74 secuencia de consulta ....................................... 2-165
directiva de conexión para Intranet Enforcer ........ 9-44 servicios.............................................................. 2-168
directiva de SA ......................................................... 3-102 servicios en .............................................2-109, 2-168
directivas .............................................................2-3, 13-5 sistema raíz ........................................................ 2-166
acciones ............................................................. 2-168 sistemas virtuales .............................................. 2-166
administración .................................................. 2-176 tareas programadas .......................................... 2-175
administrar ancho de banda ........................... 2-195 tipos .......................................................2-163 a 2-164
alarmas ............................................................... 2-174 túnel .................................................................... 2-169
aplicación, vínculo explícito de servicio a ...... 2-169 túneles L2TP ...................................................... 2-170
asignación de tráfico ........................................ 2-175 verificación......................................................... 2-192
Autenticación ..................................................... 2-172 VPN ..................................................................... 2-170
cambiar .............................................................. 2-191 VPN bidireccionales ...............................2-170, 5-128
colocar al principio ................................2-171, 2-193 zonas de seguridad ........................................... 2-168
contexto ............................................................. 4-124 directivas de acceso
contexto de una directiva ................................ 2-187 véase directivas
copia de seguridad de la sesión HA ................ 2-174 directivas de L2TP ................................................... 2-170
Deep Inspection (DI) ......................................... 2-171 Directivas de seguridad........................................... 4-185
denegar .............................................................. 2-168 Base de normas ................................................. 4-186
desactivar ........................................................... 2-191 Ejecución de bases de normas ........................ 4-189
direcciones ......................................................... 2-168 normas ............................................................... 4-186
direcciones en ................................................... 2-168 plantillas ............................................................. 4-189
edición ................................................................ 2-191 directivas, configuración ........................................... 13-6
elementos requeridos ....................................... 2-162 Discard ...................................................................... 4-134
eliminación ........................................................ 2-194 dispositivos, restablecer a los ajustes
funciones de ...................................................... 2-161 predeterminados de fábrica .................................. 3-44
global ........................................... 2-164, 2-177, 2-186 distintas pilas IP ............................................14-84, 14-85
grupos de DIP .................................................... 2-156 distribución del protocolo, comunicar a
grupos de direcciones....................................... 2-168 NetScreen-Security Manager ................................. 3-26
grupos de servicios ........................................... 2-140 DMT........................................................................... 12-74
grupos de usuarios de acceso telefónico a DN ............................................................................. 5-189
VPN................................................................... 2-168 DNS ................................................................2-219, 4-133
habilitar .............................................................. 2-191 consultas ............................................................ 2-220
ID ........................................................................ 2-167 consultas, dominios .......................................... 2-225
interzonales ................................ 2-163, 2-177, 2-180 direcciones, división ......................................... 2-226
intrazonales ................................ 2-163, 2-177, 2-185 servidores ........................................................... 2-247
L2TP .................................................................... 2-170 servidores, encapsulamiento a ........................ 2-225
libro de servicios ............................................... 2-109 tabla de estado .................................................. 2-221
límite máximo ................................................... 2-107 DoS
listas de conjuntos de directivas ..................... 2-164 asignación de grandes cantidades de paquetes
multicast............................................................. 7-163 simultáneos de la tabla de sesiones ............... 4-19
múltiples elementos por componente............ 2-188 ataque específico del sistema
NAT-dst............................................................... 2-171 operativo .................................................4-53 a 4-56
NAT-src ............................................................... 2-171 cortafuegos ...............................................4-30 a 4-36
negación de direcciones................................... 2-189 inundación de la tabla de sesiones ................... 4-30
nombre ............................................................... 2-170 red ..............................................................4-37 a 4-52
ocultación ........................................................... 2-192 DoS, ataques ...................................................4-29 a 4-56
orden .................................................................. 2-193 drop-no-rpf-route ....................................................... 4-20
permitir .............................................................. 2-168
IX-VI Índice maestro

Índice maestro
DS Codepoint Marking ..................... 2-196, 2-202, 2-216 Enrutadores BGP

DSL .................................................................2-242, 2-247 adición ................................................................ 7-125
agregación .......................................................... 7-134
E atributos, configuración .................................... 7-126
Echo .......................................................................... 4-134 notificación condicional.................................... 7-125
ECMP..................................................................7-37, 7-61 peso, establecimiento ....................................... 7-126
Ejemplos de configuración predeterminado, rechazo ................................. 7-121
encapsulamiento de IPv4 a través de IPv6 redistribución ..................................................... 7-123
(autokey IKE) ................................................. 14-115 reflexión ............................................................. 7-129
encapsulamiento de IPv6 a través de IPv4 supresión ............................................................ 7-134
(autokey IKE) ................................................. 14-119 enrutadores de retransmisión
encapsulamiento manual ................................. 14-97 6a4 .................................................................... 14-100
host 6a4, encapsulamiento a un ................... 14-104 Enrutadores OSPF
host nativo, encapsulamiento a..................... 14-101 adyacencia ........................................................... 7-50
información del servidor DNS, solicitud ......... 14-43 creación de instancia OSPF en enrutador
instancia de PPPoE, configuración ................. 14-46 virtual ................................................................. 7-53
listas de acceso y mapas de rutas ................... 14-61 designado ............................................................. 7-50
prefijos, delegados .................................14-38, 14-40 designado de respaldo ........................................ 7-50
red IPv6 a IPv4 a través de IPv4 ................... 14-111 tipos ...................................................................... 7-49
redistribución de ruta estática ......................... 14-61 Enrutadores RIP
Solicitudes de IPv6 a varios hosts de IPv4 ..... 14-86 alternativa ............................................................ 7-99
email alert notification .............................................. 3-78 predeterminado, rechazo ................................. 14-57
Encabezado de autenticación (AH)............................ 5-6 rechazo predeterminado .................................... 7-94
Encapsulaciones de AAL5 ....................................... 12-70 redistribución ........................................... 7-84, 14-58
Encapsulado de enrutamiento genérico (GRE) .... 7-161 resumen, configuración ...................................... 7-98
Encapsulamiento ........................ 14-100, 14-109, 14-115 enrutadores virtuales ................................... 14-50, 14-99
encapsulamiento 4en6 véase VR
configuración básica ....................................... 14-113 enrutadores virtuales, MIP predeterminada ........... 8-67
definición ......................................................... 14-113 enrutadores virtuales, RIP ..........................14-53 a 14-70
Encapsulamiento 6en4 ......................................... 14-109 enrutamiento estático ................................ 7-1, 7-2 a 7-9
a través de WAN IPv4 ..................................... 14-118 configuración ......................................................... 7-4
configuración básica ....................................... 14-118 Interfaz Null, reenvío en ..................................... 7-10
Encapsulamiento 6por4 multicast ............................................................. 7-160
cuándo utilizarlo ................................................ 14-95 utilización ............................................................... 7-3
definición ........................................................... 14-95 enrutamiento multicast
Direcciones, manejo ......................................... 14-96 IGMP ................................................................... 7-165
encapsulamiento manual ................................. 14-96 PIM ...................................................................... 7-191
tipos .................................................................... 14-95 enrutamiento según el origen (SBR) ........................ 7-18
encapsulamiento manual ....................................... 14-96 enrutamiento según la interfaz de origen (SIBR) ... 7-20
Encapsulamiento manual 6por4 ............................ 14-95 enrutamiento, multicast .......................................... 7-157
Encriptación ..............................................14-109, 14-113 entrada de la tabla de autenticación ....................... 9-45
3DES ................................................................. 14-119 Entradas de registros
AES128 ............................................................. 14-119 Habilitación en las normas IDP ....................... 4-241
encriptación equilibrio de cargas según coste de cada ruta....... 7-37,
algoritmos ................................5-6, 5-53, 5-56 a 5-63 7-61
NSRP ................................................................... 11-30 Equipo de instalaciones del cliente
NSRP-Lite ........................................................... 11-15 (CPE) ......................................................... 14-39, 14-131
Encriptación AES128 ............................................ 14-119 error de vector NAT ................................................. 3-102
Encriptación de 3DES ........................................... 14-119 ESP ........................................................................ 5-3, 5-6
encriptación, SecurID ................................................ 9-29 encriptación y autenticación .................... 5-56, 5-63
enrutadores sólo autenticación ............................................... 5-56
ascendentes ....................................................... 14-38 sólo encriptación ................................................. 5-56
virtuales ...................................................14-50, 14-99 establecimientos de conexión en tres pasos .......... 4-37
enrutadores ascendentes ........................................ 14-38 estación móvil (MS) ................................................. 13-16
Índice maestro IX-VII

Estadísticas, comunicar a NSM ................................ 3-27 firmas

estado ........................................................................... 4-3 estado ................................................................. 4-137
firmas ................................................................. 4-137 firmas de secuencias ............................................... 4-138
inspección .............................................................. 4-3 flujo de paquetes ............................................2-10 a 2-12
Estados de accesibilidad ......................................... 14-14 VPN basada en directivas ........................5-70 a 5-71
estados de accesibilidad, transiciones .................. 14-15 VPN basada en rutas ................................5-66 a 5-70
etiquetas, VLANs .......................................................... 2-3 VPN de entrada ........................................5-68 a 5-70
evasión ............................................................. 4-15 a 4-27 VPN de salida ....................................................... 5-68
expiración dinámica....................................... 4-33 a 4-35 flujo de paquetes, NAT-dst .............................8-29 a 8-31
exploits Fragmentos SYN ...................................................... 4-248
véase ataques fuerza bruta
expresiones de grupos ....................................... 9-5 a 9-9 acciones de ataque............................................ 4-151
operadores ............................................................. 9-5 funcionales básicos, requisitos ................................. 10-4
servidores admitidos .......................................... 9-14 funcionamiento, modos de
usuarios .................................................................. 9-5 NAT ....................................................................... 13-4
expresiones regulares ................................ 4-161 a 4-162 Ruta....................................................................... 13-4
extensiones de archivo, análisis de AV ................... 4-93 transparente ........................................................ 13-4
F G
Fase 1 ............................................................................ 5-9 gatekeeper (equipos selectores) ................................. 6-1
propuestas ............................................................. 5-9 gestión de colas de prioridades ............................. 2-200
propuestas, predefinidas ...................................... 5-9 Gi, interfaz .................................................................. 13-2
Fase 2 .......................................................................... 5-11 globales, zonas ........................................................... 8-83
propuestas ........................................................... 5-11 Gn, interfaz ................................................................. 13-2
propuestas, predefinidas .................................... 5-12 Gopher ...................................................................... 4-134
filtrado de contenido .................................... 4-57 a 4-118 Gp, interfaz ................................................................. 13-2
filtrado de paquetes dinámico ................................... 4-3 gráficos de historial ................................................. 2-174
filtrado de URL Grupo de IP dinámico (DIP) ........................2-145, 2-171
véase filtrado de web grupos
filtrado de Web ........................................................ 2-174 Direcciones ........................................................ 2-105
aplicar perfiles a directivas .............................. 4-108 servicios.............................................................. 2-140
caché .................................................................. 4-103 grupos de direcciones ..................................2-105, 2-168
categorías de URL ............................................. 4-104 crear .................................................................... 2-107
enrutamiento ..................................................... 4-116 edición ................................................................ 2-108
estado del servidor............................................ 4-116 entradas, eliminación ....................................... 2-108
integrado ............................................................ 4-101 opciones ............................................................. 2-106
mensaje de URL bloqueada ............................. 4-115 grupos de dispositivos de seguridad virtuales
nombre del servidor SurfControl .................... 4-113 véase grupos VSD
nombre del servidor Websense ...................... 4-113 grupos de objetos de ataque .................................. 4-139
perfiles ................................................................ 4-106 cambio de gravedad ......................................... 4-140
puerto del servidor SurfControl ....................... 4-113 inicio sesión ....................................................... 4-154
puerto del servidor Websense ......................... 4-113 niveles de gravedad .......................................... 4-139
redirigir............................................................... 4-110 que se aplican en directivas ............................. 4-132
servidores CPA de SurfControl ........................ 4-101 URL de ayuda .................................................... 4-136
servidores de SurfControl ................................ 4-102 grupos de servicios .....................................2-140 a 2-142
servidores por vsys ........................................... 4-112 crear .................................................................... 2-140
SurfControl SCFP............................................... 4-113 eliminar .............................................................. 2-142
tiempo de espera de comunicaciones ............ 4-114 modificar ............................................................ 2-141
tipo de mensaje de URL bloqueada ................ 4-115 grupos de servicios (WebUI) ................................... 2-140
filtrado del prefijo de IMSI ...................................... 13-17 grupos en puente
filtrar ruta de origen ................................................ 3-102 interfaz lógica ...................................................... 2-34
FIN sin indicador ACK............................................... 4-14 separar.................................................................. 2-44
Finger ........................................................................ 4-134 Grupos en puente inalámbricos ........................... 12-154
firma digital ................................................................ 5-20 grupos VSD ....................................................4-185, 11-22
IX-VIII Índice maestro

Índice maestro
cambio en caso de fallo .................................... 11-58 identificador de ruta virtual

estados de los miembros ....................11-23 a 11-24 véase VPI
números de prioridad ....................................... 11-22 Identificador de trayecto virtual/Identificador de canal
pulsos .......................................................11-24, 11-30 virtual
tiempo de retención ..............................11-37, 11-39 Veáse VPI/VCI
GTP Ident-Reset.................................................................. 3-30
comprobación de coherencia del paquete ....... 13-9 IDP
estándares ............................................................ 13-9 configuración básica ......................................... 4-178
filtrado del nombre de punto de acceso Configuración de un dispositivo para IDP
(APN) ................................................................ 13-16 independiente ................................................. 4-235
filtrado del paquete de GTP-en-GTP ................ 13-14 Configuración del modo en línea o tap en
filtrado del prefijo de IMSI ............................... 13-17 línea .................................................................. 4-190
fragmentación de IP ......................................... 13-14 Habilitación en una norma de cortafuegos .... 4-189
inspección de estado ........................................ 13-25 IDs de proxy
objetos de inspección ..............................13-5 a 13-7 VPNs y NAT ...........................................5-142 a 5-144
protocolo .............................................................. 13-2 IGMP
según directivas ................................................... 13-5 configuración, básica ........................................ 7-169
tiempo de espera del túnel .............................. 13-27 configuración, verificación ............................... 7-171
consultador ........................................................ 7-167
H directivas, multicast .......................................... 7-178
HA interfaces, habilitar en ...................................... 7-167
DHCP .................................................................. 2-234 listas de accesos, uso ........................................ 7-168
Interfaces de HA virtuales .................................. 2-36 Mensajes de host ............................................... 7-166
véase alta disponibilidad parámetros ............................................. 7-171, 7-172
véase también NSRP IKE .................................................. 5-7, 5-88, 5-97, 5-165
Hashing, algoritmo de hashing seguro (SHA) ..... 14-119 ID de proxy .......................................................... 5-12
historial, gráficos ..................................................... 2-174 ID IKE, Windows 2000 ......................... 5-225, 5-233
HMAC ............................................................................ 5-6 ID local, ASN1-DN ............................................. 5-192
Host nativos ................................................14-99, 14-100 ID remota, ASN1-DN ......................................... 5-192
HTTP identificación IKE ................5-53 a 5-55, 5-60 a 5-61
“keep-alive”.......................................................... 4-86 identificación IKE de grupo, comodines......... 5-192
bloqueo de componentes ....................4-173 a 4-174 identificación IKE de grupo, container ........... 5-193
goteo ..................................................................... 4-87 mensajes de saludo ........................................... 5-304
tiempo de espera de la sesión ........................... 4-34 propuestas de fase 1, predefinidas ..................... 5-9
HTTP, ID de sesión ...................................................... 3-4 propuestas de fase 2, predefinidas ................... 5-12
huso horario ............................................................. 2-257 puertas de enlace redundantes...........5-301 a 5-314
pulsos .................................................................. 5-304
I recomendaciones de ID IKE .............................. 5-73
ICMP .......................................................................... 4-134 usuario de identificación IKE compartida ... 5-204 a
fragmentos ......................................................... 4-243 5-210
paquetes grandes .............................................. 4-244 usuario de identificación IKE de grupo ........ 5-189 a
ID de fabricante, VSA ................................................ 9-22 5-204
ID de proxy ................................................................ 5-12 inactividad en sesión, tiempo de espera ................ 9-19
coincidencia ................................................5-65, 5-72 indicadores SYN y FIN activados ............................. 4-13
ID de sesión.................................................................. 3-4 infraestructura de claves públicas
IDENT........................................................................ 4-134 véase PKI
Identificación de delegación de prefijo de asociación Infranet Enforcer
de identidad (IAPD-ID) ..............................14-37, 14-39 directiva, configuración ...................................... 9-44
identificación IKE de grupo introducción ......................................................... 9-44
certificados ............................................5-189 a 5-198 iniciar sesión ....................................... 2-174, 3-59 a 3-73
claves previamente compartidas .......5-198 a 5-204 CompactFlash (PCMCIA)..................................... 3-60
Identificación única de dispositivo (DUID) ........... 14-37 consola.................................................................. 3-60
identificador de canal virtual correo electrónico ............................................... 3-60
véase VCI interno .................................................................. 3-60
Índice maestro IX-IX

NetScreen-Security Manager ............................. 3-26 Seguimiento de IP (véase seguimiento de IP)

registro de eventos ............................................. 3-61 supervisión ......................................................... 11-30
registro de recuperación de activos .................. 3-72 tablas de enrutamiento doble .......................... 14-50
registro propio ..................................................... 3-70 tablas de interfaces, visualización ..................... 2-41
SNMP ...........................................................3-60, 3-78 túnel ...................................................................... 2-37
syslog ...........................................................3-60, 3-76 VIP......................................................................... 8-81
USB ....................................................................... 3-60 visualizar tabla de interfaces ............................. 2-41
WebTrends .................................................3-60, 3-77 VLAN1................................................................... 2-80
inicio sesión VSI ..............................................................2-36, 11-25
grupos de objetos de ataque ............................ 4-154 zona de función ................................................... 2-36
in-short, error ........................................................... 3-100 zona de función de HA ....................................... 2-36
inspecciones................................................................. 4-3 zonas de seguridad L3 ........................................ 2-45
intercambio de claves de Internet zonas, separar de ................................................ 2-44
véase IKE interfaces
intercepción legal .................................................... 13-36 túnel ...........................................................2-37 a 2-41
Interfaces interfaces agregadas.......................................2-35, 11-45
agregadas ..................................................2-35, 11-45 interfaces de alta disponibilidad
asociar a zonas .................................................... 2-43 agregadas ........................................................... 11-45
bucle invertido..................................................... 2-57 red de cableado como conexiones HA ........... 11-28
cambios de estado .............................................. 2-60 redundantes ....................................................... 11-43
compartidas ............................................10-39, 10-73 interfaces de bucle invertido .................................... 2-57
conexiones, supervisión ..................................... 2-62 interfaces de HA virtuales....................................... 11-28
dedicadas ................................................10-39, 10-73 interfaces de ScreenOS
DHCPv6 .............................................................. 14-35 subinterfaces.......................................................... 2-3
DIP ...................................................................... 2-142 zonas de seguridad ............................................... 2-3
direccionamiento ................................................ 2-45 interfaces de túnel ..................................................... 2-37
direcciones IP secundarias................................. 2-49 definición ............................................................. 2-37
en línea lógicamente .......................................... 2-60 NAT basada en directivas................................... 2-37
en línes físicamente ............................................ 2-60 interfaces de zonas de función ................................ 2-36
extendidas ......................................................... 5-143 administración..................................................... 2-36
física, exportación desde vsys ......................... 10-42 HA ......................................................................... 2-36
física, importación de vsys .............................. 10-41 interfaces físicas
físicas en zonas de seguridad ............................ 2-34 compatibilidad de CSU ..................................... 12-21
fuera de línea físicamente.................................. 2-60 exportación desde vsys .................................... 10-42
fuera de línea lógicamente ................................ 2-60 importación de vsys.......................................... 10-41
gestionables ......................................................... 3-33 modo de paridad de bits C............................... 12-14
Gi ........................................................................... 13-2 Interfaces HA virtuales .............................................. 2-36
Gn.......................................................................... 13-2 Interfaces inalámbricas
Gp.......................................................................... 13-2 asociación a radio ........................................... 12-153
HA virtual ............................................................. 2-36 asociación de SSI a.......................................... 12-153
HA virtuales ....................................................... 11-28 configuración ................................................... 12-153
HA, duales ............................................................ 11-8 desactivar ......................................................... 12-155
MGT ...................................................................... 2-36 Interfaces T3
MIP........................................................................ 8-64 compatibilidad de CSU ..................................... 12-21
modificar .............................................................. 2-47 modo de paridad de bits C............................... 12-14
NAT basada en directivas .................................. 2-37 interfaces, habilitar IGMP en .................................. 7-167
ND ....................................................................... 14-29 interfaces, supervisión ...................................2-67 a 2-72
NDP .................................................................... 14-30 bucles.................................................................... 2-68
NUD .................................................................... 14-29 zonas de seguridad ............................................. 2-72
null ........................................................................ 5-87 interfaz de línea de comandos
opciones de administración............................... 3-29 véase CLI
PPPoE ................................................................. 14-46 interfaz de seguridad virtual
predeterminadas ................................................. 2-46 véase VSI
redundantes ..............................................2-35, 11-43
IX-X Índice maestro

Índice maestro
interfaz de usuario SA ................................................... 5-2, 5-8, 5-9, 5-11

véase WebUI SPI ........................................................................... 5-2
Interfaz física túnel ........................................................................ 5-2
interfaz lógica ...................................................... 2-34 IPv4
interfaz inalámbrica direcciones, asignadas .......................... 14-82, 14-86
interfaz lógica ...................................................... 2-34 WAN .................................................................. 14-110
Interfaz MGT, opciones de administración ............. 3-30 IPv4 a IPv6
Interfaz Null, definiendo las rutas con .................... 7-10 asignación de host............................................. 14-90
inundación de la tabla de sesiones.......................... 4-30 asignación de red .............................................. 14-89
inundaciones IPv6
ICMP ..................................................................... 4-49 área troncal .......................................... 14-84, 14-113
SYN .................................................. 4-37 a 4-43, 4-47 direcciones, SLA ................................................ 14-37
tabla de sesiones ................................................. 4-30 direcciones, TLA ................................................ 14-37
UDP ....................................................................... 4-51 redes, aisladas ................................................. 14-110
inundaciones de SYN-ACK-ACK a través de un IRC ............................................................................. 4-135
servidor proxy ......................................................... 4-35 ISP ............................................................................. 2-225
Inundaciones ICMP ................................................... 4-49 prioridad ........................................................... 12-115
Inundaciones SYN ..........................................4-37 a 4-43 tiempo de espera de conmutación por
ataques ................................................................. 4-37 error ................................................................ 12-116
Cookies SYN......................................................... 4-47
descartar las direcciones MAC desconocidas .. 4-43 L
tamaño de la cola ................................................ 4-42 L2TP ................................................... 5-211 a 5-237, 13-3
tiempo de espera ................................................ 4-42 asignaciones de direcciones............................... 9-89
umbral .................................................................. 4-38 autenticación de usuarios ................................... 9-89
umbral de alarma ................................................ 4-41 autenticado del túnel
umbral de ataque ................................................ 4-40 Windows 2000 .................................... 5-222, 5-227
umbral de destino ............................................... 4-41 base de datos local .............................................. 9-90
umbral de origen ................................................. 4-41 bidireccional....................................................... 5-213
IP concentrador de accesos: véase LAC
fragmentos de paquetes ................................... 4-247 configuración obligatoria .................................. 5-211
IP asignada (MIP) ..........................................14-82, 14-84 configuración voluntaria ................................... 5-212
asignación de red de IPv6 a IPv4 .................... 14-85 desencapsulado ................................................. 5-216
Hosts IPv4 a hosts IPv6 múltiples ................... 14-89 Encapsulamiento ............................................... 5-214
hosts IPv4 a un solo host IPv6 ......................... 14-90 Keep Alive .............................................. 5-222, 5-227
Hosts IPv6 a un host IPv4 individual .............. 14-87 L2TP en solitario sobre Windows 2000 .......... 5-213
Hosts IPv6 a varios hosts IPv4......................... 14-85 modo de funcionamiento ................................. 5-214
MIP de IPv6 a IPv4 ............................................ 14-84 parámetros predeterminados .......................... 5-217
IP de administración ........................................2-95, 3-33 señal hello .............................................. 5-222, 5-227
IP de administración, VSD grupo 0 ......................... 11-3 servidor de autenticación externo..................... 9-90
IP de servidor SMTP .................................................. 3-76 servidor de red: véase LNS
IP dinámica .............................................................. 14-81 Servidor RADIUS ............................................... 5-217
IP dinámica, de IPv6 a IPv4 ................................... 14-83 servidor SecurID ................................................ 5-217
IP dinámico soporte de ScreenOS......................................... 5-213
véase DIP túnel .................................................................... 5-219
IP virtual L2TP sobre IPSec ..................................5-4, 5-219, 5-224
véase VIP bidireccional....................................................... 5-213
IPSec túnel .................................................................... 5-219
AH ........................................................ 5-2, 5-56, 5-62 LAC ............................................................................ 5-211
ESP ....................................................... 5-2, 5-56, 5-62 NetScreen-Remote 5.0 ...................................... 5-212
firma digital.......................................................... 5-20 Windows 2000 .................................................. 5-212
L2TP sobre IPSec................................................... 5-4 Land Attack, ataques terrestres ................................ 4-52
modo de transporte ........... 5-4, 5-213, 5-219, 5-224 Layer 2 Tunneling Protocol
modo de túnel ....................................................... 5-4 véase L2TP
negociación de túnel ............................................. 5-9 LDAP ..................................................... 4-134, 9-30 a 9-31
Índice maestro IX-XI

estructura ............................................................. 9-30 Mensajería inmediata .............................................. 4-135

identificadores de nombre común.................... 9-31 AIM...................................................................... 4-135
nombres completos ............................................ 9-31 IRC ...................................................................... 4-135
puertos del servidor ............................................ 9-31 Mensajero Yahoo! ............................................. 4-135
tipos de usuarios admitidos ............................... 9-31 MSN Messenger ................................................. 4-135
libretas de direcciones Yahoo! Messenger ............................................. 4-135
Direcciones Mensajería inmediata de America Online
adición........................................................... 2-104 Consulte AIM
eliminación ................................................... 2-108 Mensajero Yahoo! .................................................... 4-135
modificar....................................................... 2-105 mensajes
entradas ............................................................. 2-104 alerta ..................................................................... 3-61
entradas de grupo, edición .............................. 2-108 control ................................................................ 11-13
grupos ................................................................. 2-105 críticos .................................................................. 3-61
véase también direcciones datos ..................................................................... 11-7
libro de servicio, grupos de servicios (WebUI) ....... 6-66 depurar ................................................................. 3-61
libro de servicios emergencia .......................................................... 3-61
agregado ............................................................ 2-123 error ...................................................................... 3-61
entradas, eliminación (CLI) .............................. 2-124 HA ......................................................................... 11-7
entradas, modificación de (CLI) ...................... 2-124 información ......................................................... 3-61
personalizado (CLI) ........................................... 2-123 notificación .......................................................... 3-61
personalizados................................................... 2-109 WebTrends........................................................... 3-78
preconfigurado .................................................. 2-109 mensajes de bienvenida ........................................... 9-10
licencia, claves ......................................................... 2-253 mensajes de control ................................................ 11-13
limitación de velocidad, mensajes GTP-C ............. 13-12 HA ......................................................................... 11-7
Límites de IPv4/IPv6 ...................... 14-81 a 14-85, 14-89 pulsos de conexión física HA ............................. 11-7
límites de sesiones ......................................... 4-30 a 4-33 pulsos RTO ........................................................... 11-7
según su destino ........................................4-31, 4-32 mensajes de datos ..................................................... 11-7
según su origen ..........................................4-30, 4-32 mensajes GTP ........................................................... 13-11
Límites IPv6/IPv4 ........................... 14-82 a 14-87, 14-88 longitud, filtrar por .............................................. 13-9
lista de control de acceso tipo, filtrar por ................................................... 13-10
véase ACL tipos .......................................................13-10 a 13-11
Lista de revocación de certificados ................5-23, 5-35 velocidad, limitación por .................................. 13-12
carga ..................................................................... 5-23 versiones 0 y 1 .................................................. 13-11
listas de acceso Message Digest versión 5 (MD5)................................ 5-6
enrutamiento multicast .................................... 7-161 métodos de administración
IGMP ................................................................... 7-168 CLI ......................................................................... 3-10
para rutas ............................................................. 7-41 consola ................................................................. 3-19
PIM-SM ............................................................... 7-211 SSL .......................................................................... 3-5
listas de prefijos ....................................................... 14-12 Telnet .................................................................... 3-10
Llamada de procedimiento remoto de Microsoft WebUI ..................................................................... 3-2
Consulte MS-RPC MGT, interfaz .............................................................. 2-36
LNS ............................................................................ 5-211 MIB II..................................................................3-29, 3-79
locales, bases de datos ................................... 9-15 a 9-17 Microsoft Network Instant Messenger
Consulte MSN Instant Messenger
M MIME, análisis antivirus ............................................ 4-75
Management Information Base II MIP .....................................................................2-11, 8-63
véase MIB II agrupamiento, directivas de celdas
mantenimiento de conexión múltiples ............................................................ 8-80
frecuencia, NAT-T de ........................................ 5-246 alcanzable desde otras zonas ............................ 8-67
L2TP .................................................................... 5-222 definición ............................................................... 8-6
máscaras de red .............................................2-46, 2-168 rangos de direcciones ......................................... 8-67
máscaras de red, MIP predeterminada ................... 8-67 same-as-untrust, interfaz .........................8-71 a 8-73
MD5 .............................................................................. 5-6 traducción bidireccional ....................................... 8-6
zona global ........................................................... 8-65
IX-XII Índice maestro

Índice maestro
MIP, creación Host ....................................................... 14-46, 14-114

direcciones ........................................................... 8-65 NAT y de ruta ....................................................... 11-2
en interfaz de túnel ............................................. 8-70 NAT, tráfico a la zona Untrust ........................... 2-79
en interfaz de zona ............................................. 8-65 operacional L2TP ............................................... 5-214
MIP, predeterminada principal................................................................ 5-10
enrutadores virtuales .......................................... 8-67 prioridad ............................................................. 11-22
máscaras de red .................................................. 8-67 transparente ......................................................... 2-79
MIP, sistemas virtuales ............................................ 10-33 Transporte ..................5-4, 5-62, 5-213, 5-219, 5-224
MIP, VPNs ................................................................. 5-143 túnel .............................................................. 5-4, 5-62
Modo caducado de host de punto final modos de funcionamiento
Detección de dirección duplicada (DAD) ....... 14-31 NAT ....................................................................... 13-4
estado de sondeo periódico ............................. 14-31 Ruta ....................................................................... 13-4
modo caducado ................................................. 14-30 transparente ......................................................... 13-4
tiempo accesible................................................ 14-30 Modos de funcionamiento de WLAN WAP
tiempo accesible base....................................... 14-30 clientes 802.11b, configuración ...... 12-125, 12-126
tiempo de retransmisión .................................. 14-31 Modos de funcionamiento de WLAN WAP clientes
tiempo de sondeo ............................................. 14-31 802.11g, configuración ....................................... 12-125
Modo de enrutador .................................................. 14-52 Modos de IDP ........................................................... 4-190
modo de fallo ............................................................. 4-85 modos de selección
modo de paridad de bits C ..................................... 12-14 APN ..................................................................... 13-16
modo de prioridad .................................................. 11-22 estación móvil (MS) ........................................... 13-16
modo de red ............................................................. 13-16 red ....................................................................... 13-16
modo de rutas ............................2-98 a 2-101, 11-2, 13-4 verificado ............................................................ 13-16
ajustes de interfaz ............................................... 2-99 módulo ........................................................................ 5-11
NAT-src ................................................................. 2-99 Motor IDP
Modo de transferencia asíncrona actualizar ............................................................ 4-239
véase ATM MS RPC ..................................................................... 4-136
modo de transporte.................. 5-4, 5-213, 5-219, 5-224 MS RPC ALG, definido ............................................. 2-130
Modo de túnel .............................................................. 5-4 MSN Messenger ....................................................... 4-135
modo dinámico.......................................................... 5-10 multicast
Modo en línea .......................................................... 4-190 árboles de distribución ..................................... 7-194
Modo host ....................................................14-46, 14-114 direcciones ......................................................... 7-158
modo NAT .....................................2-92 a 2-98, 11-2, 13-4 directivas ............................................................ 7-163
ajustes de interfaz ............................................... 2-95 directivas para IGMP ......................................... 7-178
tráfico a la zona Untrust ............................2-79, 2-94 reenvío por rutas inversas ................................ 7-158
modo principal........................................................... 5-10 rutas estáticas .................................................... 7-160
Modo tap en línea .................................................... 4-190 tablas de enrutamiento..................................... 7-159
Modo transparente .........................................2-79 a 2-92 Multicast independiente de protocolo
ARP/trace-route ................................................... 2-83 véase PIM
bloquear tráfico no ARP ..................................... 2-81 Multiplexado AAL5 .................................................. 12-78
bloquear tráfico no IP ......................................... 2-81 multiplexado, configuración ................................... 12-76
descartar las direcciones MAC desconocidas .. 4-43 Multitono discreto
inundación ........................................................... 2-83 véase DMT
opciones unicast .................................................. 2-83
rutas ...................................................................... 2-82 N
tráfico broadcast ................................................. 2-81 NAT
modo transparente ............................. 10-44, 10-45, 13-4 definición................................................................ 8-1
Modo transparente, opciones de administración .. 3-30 IPSec y NAT ....................................................... 5-240
modo verificado ....................................................... 13-16 NAT-src con NAT-dst ................................8-50 a 8-61
modos servidores NAT .................................................. 5-240
Caducado ........................................................... 14-30 NAT basada en directivas
Criptografía Fase 1 .....................................5-51, 5-58 Véase NAT-dst y NAT-src
dinámico .............................................................. 5-10 NAT basada en directivas, interfaces de túnel ........ 2-37
Enrutador ........................................................... 14-52
Índice maestro IX-XIII

NAT-dst ............................................................. 8-28 a 8-61 opción NAT-T ..................................................... 5-240

asignación de puertos........................ 8-4, 8-28, 8-47 VPN AutoKey IKE .............................................. 5-165
con MIP o VIP ........................................................ 8-4 NetScreen-Security Manager
consideraciones sobre las rutas ... 8-29, 8-32 a 8-34 administración del sistema ............. 3-23, 3-24, 3-26
desplazamiento de direcciones ........................... 8-5 Agente de NSM ...........................................3-23, 3-26
flujo de paquetes ...................................... 8-29 a 8-31 comunicar eventos.....................................3-26, 3-27
traducción unidireccional............................8-7, 8-11 configuración de la conectividad inicial ........... 3-24
VPN ..................................................................... 5-143 definición ............................................................. 3-23
NAT-dst, direcciones habilitación del agente de NSM ......................... 3-25
desplazamiento ..........................................8-28, 8-44 iniciar sesión ........................................................ 3-26
rango a IP única .........................................8-10, 8-41 interfaz de usuario .............................................. 3-23
rango a rango .............................................8-10, 8-44 opciones de administración ............................... 3-30
rangos ..................................................................... 8-4 NFS ............................................................................ 4-134
NAT-dst, IP individual NNTP ......................................................................... 4-134
con asignación de puerto ..................................... 8-9 nombre completo (DN) ........................................... 5-189
sin asignación de puerto ...................................... 8-9 Nombre de punto de acceso
NAT-dst, traducción véase APN
“1:1” ..................................................................... 8-35 nombres completos ................................................... 9-31
“1:n” ..................................................................... 8-38 nombres comunes ..................................................... 9-31
NAT-PT ...................................................................... 14-81 nombres de clústeres, NSRP .......................11-11, 11-29
NAT-PT, IPSec, cuándo se utiliza .......................... 14-110 Norma de encriptación de datos (DES) ..................... 5-6
NAT-src ..................................................... 8-1, 8-13 a 8-26 norma VLAN IEEE 802.1Q ..................................... 10-43
basada en interfaces ............................................. 8-2 normas de exclusión ..................................4-205 a 4-210
interfaz de salida .............................. 8-9, 8-24 a 8-26 configuración ..................................................... 4-207
puerto fijo........................................ 8-14, 8-18 a 8-19 Configuración de las columnas de
VPN ..................................................................... 5-145 coincidencia..................................................... 4-207
NAT-src, conjuntos de DIP .......................................... 8-1 Configuración de los ataques ........................... 4-208
con desplazamiento de direcciones.................... 8-8 Configuración de objetivos .............................. 4-209
con PAT ............................................. 8-7, 8-15 a 8-17 Configuración de zonas .................................... 4-207
puerto fijo............................................................... 8-8 Configuración del origen y destino ................. 4-208
NAT-src, direcciones Configuración desde el visualizador de
desplazamiento ........................................ 8-20 a 8-24 registros ........................................................... 4-209
desplazamiento, consideraciones sobre el Normas de IDP ........................................................ 4-191
rango .................................................................. 8-20 configuración ..................................................... 4-193
NAT-src, modo de rutas ............................................. 2-99 Configuración de acciones ............................... 4-199
NAT-src, traducción Configuración de la gravedad del ataque ....... 4-205
direcciones de puerto ........................................... 8-2 Configuración de la notificación ...................... 4-204
unidireccional ...............................................8-7, 8-11 Configuración de las acciones de IP ............... 4-202
NAT-T ............................................................ 5-240 a 5-248 Configuración de las columnas de
frecuencia de mantenimiento de conexión ... 5-246 coincidencia..................................................... 4-193
habilitar .............................................................. 5-248 Configuración de los ataques ........................... 4-200
iniciador y respondedor ................................... 5-246 Configuración de los servicios ......................... 4-195
obstáculos para VPN ......................................... 5-243 Configuración de normas definitivas .............. 4-198
Paquete IKE ....................................................... 5-244 Configuración de objetivos .............................. 4-205
Paquete IPSec .................................................... 5-245 Configuración de objetos de ataque de IDP ... 4-188
sondeos de NAT ................................... 5-241 a 5-243 configuración de objetos de dirección ............ 4-188
NAT-Traversal Configuración de objetos de servicio .............. 4-188
Véase NAT-T Configuración del origen y destino ................. 4-194
negación de direcciones ......................................... 2-189 Introducción de comentarios .... 4-205, 4-209, 4-215
negación, Deep Inspection (DI) ............................. 4-168 normas de puerta de atrás ........................4-210 a 4-215
NetBIOS .................................................................... 4-136 Configuración de acciones ............................... 4-213
NetInfo ...................................................................... 2-228 Configuración de la gravedad .......................... 4-215
NetScreen-Remote Configuración de las columnas de
interlocutor dinámico ............................5-170, 5-177 coincidencia..................................................... 4-212
IX-XIV Índice maestro

Índice maestro
Configuración de los servicios ......................... 4-213 seguridad de comunicaciones ......................... 11-15

Configuración de objetivos .............................. 4-215 NTP ................................................... 2-258 a 2-261, 4-134
Configuración de zonas .................................... 4-212 desfase horario máximo................................... 2-259
Configuración del funcionamiento .................. 4-213 múltiples servidores .......................................... 2-258
Configuración del origen y destino ................. 4-212 servidores ........................................................... 2-258
notificación de alerta por correo electrónico ......... 3-76 servidores seguros............................................. 2-261
Notificación de enrutador (RA) .............................. 14-11 sincronización NSRP ......................................... 2-260
Notificación de vecino (NA) .................................... 14-30 tipos de autenticación ....................................... 2-261
NRTP ......................................................................... 11-20 NTP, sincronización de NSRP ................................. 11-21
NSRP ........................................................................... 11-1 Números de sistema autónomo (AS) ..................... 7-113
ajustes predeterminados .................................... 11-6
cableado ................................................11-26 a 11-29 O
comando clear cluster ...................................... 11-11 objetos
comando debug cluster .................................... 11-11 objetos de ataque .............................................. 4-215
configuración en malla completa .........11-26, 11-59 Objetos de ataque, anomalías de
consulta de ARP ................................................ 11-40 protocolo .......................................................... 4-216
copia de seguridad de la sesión HA ................ 2-174 Objetos de ataque, creación personalizada ... 4-219
DHCP .................................................................. 2-234 Objetos de ataque, firma .................................. 4-216
difusiones ARP................................................... 11-30 objetos AV
grupos de DIP .......................................2-155 a 2-158 tiempo de espera................................................. 4-91
grupos VSD ................................. 4-185, 11-22, 11-35 objetos de ataque ............................ 4-122, 4-132 a 4-138
interfaces redundantes ....................................... 2-35 anomalía del protocolo ..................................... 4-216
IP administrativa ............................................... 11-55 anomalías en el protocolo .................... 4-138, 4-167
maestro .............................................................. 11-12 desactivar ........................................................... 4-142
mensajes de control .................................11-7, 11-13 firma ................................................................... 4-216
modo de prioridad ............................................ 11-22 firmas completas ............................................... 4-137
modos NAT y de rutas ........................................ 11-2 firmas de secuencias ......................................... 4-138
números de prioridad ....................................... 11-22 firmas de secuencias de TCP ........................... 4-165
puertos redundantes ........................................... 11-2 fuerza bruta ............................................ 4-151, 4-152
redirección de paquetes y enrutamiento IDP ...................................................................... 4-188
dinámico ............................................................ 11-8 introducción ....................................................... 4-215
reparto de carga ................................................ 11-84 negación ............................................................. 4-168
respaldo .............................................................. 11-12 personalizados ................................................... 4-219
RTO ..................................................................... 11-35 volver a habilitar ................................................ 4-143
ruta secundaria .................................................. 11-30 Objetos de ataque IDP ............................................ 4-188
seguridad de comunicaciones ......................... 11-30 objetos de ataques de fuerza bruta ........................ 4-152
sincronización de configuraciones .................. 11-20 Objetos en tiempo de ejecución
sincronización NTP ................................2-260, 11-21 véase RTO
sistemas virtuales .................................11-58 a 11-88 objetos, supervisión ................................................. 11-52
supervisión de interfaces ................................. 11-30 OCSP (Online Certificate Status Protocol) ............... 5-35
tiempo de retención ..............................11-37, 11-39 cliente ................................................................... 5-35
VSI ......................................................................... 11-2 servidor de respuesta .......................................... 5-35
VSI, rutas estáticas .................................11-25, 11-70 ojos de aguja............................................................... 6-20
VSIs ....................................................................... 2-36 opción de aplicación, en directivas ....................... 2-169
NSRP HA opción de marca de tiempo de IP ................. 4-11, 4-12
cableado, interfaces de red .............................. 11-28 opción de reencriptación, supervisión de VPN .... 5-251
copia de seguridad de la sesión ....................... 11-16 opción de seguridad IP ................................... 4-11, 4-12
interfaces .............................................................. 11-6 Opción del modo de compatibilidad
puertos, interfaces redundantes ...................... 11-43 Interfaces T3 ...................................................... 12-21
NSRP RTO ....................................................11-16 a 11-17 opción IP de grabación de ruta ...................... 4-11, 4-12
estados ............................................................... 11-17 opción IP de ID de secuencia ......................... 4-11, 4-12
sync..................................................................... 11-21 opción IP de ruta de origen abierta .... 4-11, 4-26 a 4-27
NSRP-Lite .................................................................. 11-20 opción IP de ruta de origen estricta ... 4-11, 4-26 a 4-27
clústeres ............................................................. 11-11 opciones “unicast” desconocidas .................2-82 a 2-87
Índice maestro IX-XV

ARP ............................................................ 2-84 a 2-87 configuración de seguridad ................................ 7-67

inundación ................................................ 2-83 a 2-84 equilibrio de carga .............................................. 7-37
trace-route ............................................................ 2-85 interfaces, asignación a áreas ............................ 7-55
opciones criptográficas .................................. 5-50 a 5-64 interfaces, túnel ................................................... 7-71
acceso telefónico ...................................... 5-57 a 5-64 inundación, LSA reducida .................................. 7-71
algoritmos de autenticación ..5-53, 5-57, 5-60, 5-63 inundaciones, protección contra ....................... 7-69
algoritmos de encriptación ........... 5-53 a 5-59, 5-63 LSA, supresión ..................................................... 7-70
comprobación contra reprocesamiento de notificaciones de estado de conexiones ........... 7-48
paquetes ...................................................5-55, 5-61 parámetros de interfaz ....................................... 7-64
ESP ...............................................................5-56, 5-63 parámetros globales............................................ 7-61
identificación IKE ................ 5-53 a 5-55, 5-60 a 5-61 pasos de configuración ....................................... 7-52
longitudes de bits de los certificados .......5-52, 5-59 protocolo de saludo ............................................ 7-50
métodos de administración de claves .............. 5-51 punto a multipunto ............................................. 7-71
modo de transporte ............................................ 5-62 red punto a punto ............................................... 7-50
Modo de túnel ..................................................... 5-62 redes de difusión ................................................. 7-50
modos de fase 1 .........................................5-51, 5-58 soporte de ECMP ................................................. 7-61
PFS ...............................................................5-55, 5-61 tipo de conexión, establecimiento .................... 7-72
protocolos IPSec .........................................5-56, 5-62 vecinos, autenticación ........................................ 7-67
punto a punto ........................................... 5-50 a 5-57 vecinos, filtrado ................................................... 7-68
recomendaciones VPN de acceso telefónico ... 5-64
recomendaciones VPN punto a punto .............. 5-57 P
tipos de autenticación ...............................5-52, 5-58 p de redundancia de NetScreen
opciones de administración véase NSRP
gestionables ......................................................... 3-33 P2P ............................................................................ 4-135
interfaces ............................................................. 3-29 BitTorrent ........................................................... 4-135
MGT, interfaz ....................................................... 3-30 DC ....................................................................... 4-135
modo transparente ............................................. 3-30 eDonkey ............................................................. 4-136
NetScreen-Security Manager ............................. 3-30 FastTrack ............................................................ 4-136
ping ....................................................................... 3-30 Gnutella .............................................................. 4-136
SNMP .................................................................... 3-29 KaZaa .................................................................. 4-136
SSH ....................................................................... 3-29 MLdonkey .......................................................... 4-136
SSL ........................................................................ 3-30 Skype .................................................................. 4-136
Telnet.................................................................... 3-29 SMB ..................................................................... 4-136
VLAN1 .................................................................. 3-30 WinMX................................................................ 4-136
WebUI .................................................................. 3-29 PAP .................................................................5-213, 5-217
Opciones de administración de SSL........................ 3-30 paquetes ................................................................... 3-102
Opciones de administración de Telnet ................... 3-29 ataque de simulación de dirección ................. 3-101
Opciones de administración del comando ping .... 3-30 colisión ............................................................... 3-100
Opciones IP ..................................................... 4-10 a 4-12 descartados .............................................3-101, 3-102
atributos .................................................... 4-10 a 4-11 entrantes ............................................................ 3-100
formateadas incorrectamente ......................... 4-245 fragmentados..................................................... 3-102
grabación de ruta .......................................4-11, 4-12 IPSec ................................................................... 3-101
ID de secuencia ..........................................4-11, 4-12 land attack ......................................................... 3-101
marca de hora ............................................4-11, 4-12 no enrutables ..................................................... 3-102
ruta de origen ...................................................... 4-26 Protocolo de encapsulamiento de punto a
ruta de origen abierta .................... 4-11, 4-26 a 4-27 punto (PPTP).................................................... 3-101
ruta de origen estricta ................... 4-11, 4-26 a 4-27 Protocolo de mensajes de control de Internet
seguridad.....................................................4-11, 4-12 (ICMP) ......................................................3-99, 3-101
Open Shortest Path First que no se pueden recibir.................................. 3-100
véase OSPF rechazados ......................................................... 3-102
OSPF recibidos ...................................... 3-100, 3-101, 3-102
área de rutas internas ......................................... 7-49 Traducción de direcciones de red (NAT) ........ 3-101
área no exclusiva de rutas internas .................. 7-49 transmitidos por defecto (underrun) .............. 3-100
conexiones virtuales ........................................... 7-62 paquetes de firmas, DI ............................................ 4-124
IX-XVI Índice maestro

Índice maestro
paquetes de petición, sale de IPv6 a IPv4 ............ 14-84 protocolo ligero de acceso a directorios
par de claves pública/privada ................................... 5-23 véase LDAP
parámetro de descubrimiento de vecinos protocolo punto a punto
(NDP) ...........................................................14-21, 14-30 véase PPP
parámetros del sistema .......................................... 2-260 Protocolo punto a punto (PPP) ............................... 14-46
Password Authentication Protocol Protocolo punto a punto a través de ATM
véase PAP Veáse PPPoA
PAT ....................................................................2-143, 8-14 Protocolo punto a punto a través de Ethernet
PCMCIA ....................................................................... 3-60 Véase PPPoE
PFS ........................................................... 5-12, 5-55, 5-61 Protocolo punto a punto sobre Ethernet
PIM-SM ...................................................................... 7-193 (PPPoE) ................................................................... 14-46
configuración de puntos de encuentro ........... 7-209 Protocolos
configuraciones de seguridad .......................... 7-211 CHAP................................................................... 5-213
enrutador designado ......................................... 7-194 IGP ....................................................................... 14-51
IGMPv3 ............................................................... 7-225 NRTP ................................................................... 11-20
instancias, creación .......................................... 7-199 NSRP ..................................................................... 11-1
parámetros de interfaz ..................................... 7-214 PAP...................................................................... 5-213
pasos de configuración ..................................... 7-198 PPP .......................................................... 5-212, 14-46
proxy RP............................................................. 7-215 PPPoE ................................................................. 14-46
puntos de encuentro ......................................... 7-195 VRRP ................................................................... 11-55
tráfico, reenvío .................................................. 7-195 protocolos desconocidos ......................................... 4-246
PIM-SSM.................................................................... 7-197 protocolos, CHAP ....................................................... 9-84
Ping of Death ............................................................. 4-53 Proveedor de servicios de Internet
PKI ............................................................................... 5-22 (ISP) ..................................... 2-225, 14-36, 14-44, 14-96
PKI keys ........................................................................ 3-6 proveedor de servicios, información del ............... 12-70
plantillas Proxies de IGMP ....................................................... 7-173
directiva de seguridad ...................................... 4-189 emisor ................................................................. 7-185
Portmapper .............................................................. 4-134 en interfaces ...................................................... 7-176
PPP .................................................................5-212, 12-70 Puerta de enlace de destino ................................... 14-96
PPPoA................................................. 12-70, 12-72, 12-79 Puerta de enlace de siguiente salto ....................... 14-31
PPPoE .............................................................12-70, 12-79 Puerta de enlace en la capa de aplicación
PPPoE - Protocolo punto a punto sobre véase ALG
Ethernet ................................................................. 14-46 puertas de enlace redundantes .................5-301 a 5-314
propuestas comprobación de indicador TCP SYN............. 5-307
Fase 1 ............................................................5-9, 5-72 procedimiento de recuperación ...................... 5-306
Fase 2 ..........................................................5-11, 5-72 puertos
protección contra ataques asignación .................................................... 8-4, 8-28
nivel de directivas ................................................. 4-5 cambio en caso de fallo .................................... 11-43
nivel de zona de seguridad .................................. 4-5 números ............................................................... 8-88
protección contra reprocesamiento de paquetes... 5-12 principales, trusted y untrusted ....................... 11-43
protección contra URL maliciosas ................4-58 a 4-61 redundantes ......................................................... 11-2
Protocolo de administración de grupos de Internet secundarios, trusted y untrusted ..................... 11-43
véase IGMP puertos de módem .......................................... 3-20, 3-22
Protocolo de encapsulamiento de GPRS (GTP) Puertos NSRP
véase GTP cambio en caso de fallo .................................... 11-43
Protocolo de encapsulamiento de punto a punto puertos troncales ..................................................... 10-45
(PPTP)..................................................................... 3-101 puertos troncales, modo transparente .................. 10-44
Protocolo de información de enrutamiento puertos, módem............................................... 3-20, 3-22
véaseRIP pulsos
protocolo de puerta de enlace interior (IGP) ........ 14-51 conexión física HA .............................................. 11-7
Protocolo de transferencia de hipertexto (HTTP), RTO ....................................................................... 11-7
ID de sesión ............................................................... 3-4 Punto a punto
protocolo de transporte fiable de NetScreen Consulte P2P
véase NRTP Punto de terminación remoto ................ 14-100, 14-104
Índice maestro IX-XVII

Puntos de finalización de túnel .............................. 14-99 2326, Protocolo de secuencias en tiempo real
PXE ............................................................................ 2-239 (RTSP) .............................................2-132, 2-136
2474, Definición del campo de Servicios
Q diferenciados (campo DS) en los encabezados
QoS (calidad del servicio) ....................................... 2-195 de IPv4 e IPv6............................................. 2-176
791, Internet Protocol ..................................... 4-11
R 791, protocolo de Internet ............................... 4-10
RA – Notificación de enrutador ............................. 14-12 793, Protocolo de control de transmisión ......... 4-14
RADIUS .......................................3-42, 4-134, 9-19 a 9-23 RFC 1777, Protocolo ligero de acceso a
archivo de diccionario .................................9-3, 9-22 directorios ......................................................... 9-31
L2TP .................................................................... 5-217 RIP
objetos de servidor auth ..................................... 9-34 autenticación de vecinos .................................... 7-92
propiedades del objeto ....................................... 9-20 base de datos ....................................................... 7-99
puertos ................................................................. 9-20 configuración ..................................................... 14-53
secreto compartido ............................................. 9-20 configuración de circuito de demanda ........... 7-101
tiempo de espera entre reintentos.................... 9-20 equilibrio de carga .............................................. 7-37
RADIUS, archivo de diccionario de ........................... 9-3 filtrado de vecinos ............................................... 7-93
RADIUSv6 ............................................................... 14-130 instancias, creación en VR ......................7-82, 14-54
reconocimiento ................................................. 4-7 a 4-27 interfaces, habilitar en .............................7-83, 14-55
análisis FIN .......................................................... 4-16 inundaciones, protección contra ............7-94, 14-59
barrida de puertos ................................................ 4-9 parámetros de interfaz ............................7-90, 14-60
barrido de direcciones .......................................... 4-8 parámetros globales.................................7-89, 14-55
indicadores SYN y FIN activados ...................... 4-13 punto a multipunto ........................................... 7-103
Opciones IP.......................................................... 4-10 resumen de prefijo .............................................. 7-98
paquete TCP sin indicadores ............................. 4-15 vecinos, filtrado ................................................. 14-57
Red de área local inalámbrica versiones .............................................................. 7-96
véase WLAN versiones, protocolo............................................ 7-96
red, ancho de banda ............................................... 2-195 RIP, configuración
redes privadas virtuales circuitos de demanda ....................................... 7-101
véase VPNs pasos ..................................................................... 7-81
reensamblaje de fragmentos ......................... 4-58 a 4-61 seguridad .............................................................. 7-92
registro de eventos .................................................... 3-61 RIP, visualización
registro de recuperación de activos......................... 3-72 base de datos ............................................7-86, 14-66
registro propio ........................................................... 3-70 detalles de interfaz .............................................. 7-88
registro, tráfico .......................................................... 13-5 detalles de protocolo................................7-86, 14-66
reglas, derivadas de las directivas ......................... 2-166 información de vecinos ...........................7-87, 14-67
reloj del sistema.......................................... 2-256 a 2-261 RIPng..............................................................14-49, 14-51
fecha y hora ....................................................... 2-257 cálculo del valor métrico .................................. 14-62
huso horario ...................................................... 2-257 métrica de diferencia .............................14-61, 14-62
sincronización con cliente ............................... 2-257 métrica de ruta .......................................14-61, 14-62
reparto de carga....................................................... 11-84 redistribución de rutas...................................... 14-51
requisitos del explorador ............................................ 3-2 valor métrico del coste de la interfaz ..14-61, 14-62
requisitos del explorador web .................................... 3-2 rlogin ......................................................................... 4-134
rexec ......................................................................... 4-134 rsh.............................................................................. 4-134
RFC RSH ALG ................................................................... 2-128
0792, Protocolo de mensajes de control de RTO
Internet ...................................................... 2-128 estados de funcionamiento .............................. 11-17
1038, Opción de seguridad IP revisada ............ 4-11 interlocutores ..................................................... 11-23
1349, Tipo de servicio en el Suite de protocolo sincronización ................................................... 11-21
de Internet.................................................. 2-176 RTOs .............................................................11-16 a 11-17
1918, Asignación de direcciones para Internet RTSP .......................................................................... 4-134
privadas ....................................................... 2-46 RTSP ALG
2132, Opciones de DHCP y extensiones de códigos de estado.............................................. 2-135
proveedores de BOOTP ................................ 2-233 definido .............................................................. 2-132
IX-XVIII Índice maestro

Índice maestro
métodos de petición ......................................... 2-133 Inundaciones SYN ....................................4-37 a 4-43

servidor en dominio privado ........................... 2-136 Inundaciones UDP ............................................... 4-51
servidor en dominio público ............................ 2-138 opción IP de ruta de origen abierta,
ruta de origen ........................................................... 3-102 detectar .............................................................. 4-27
ruta Null ...................................................................... 5-87 opción IP de ruta de origen estricta,
ruta secundaria ........................................................ 11-30 detectar .............................................................. 4-27
rutas opción IP de ruta de origen, rechazar............... 4-27
exportación .......................................................... 7-43 opciones IP ........................................................... 4-10
filtrado .................................................................. 7-41 opciones IP incorrectas, descartar .................. 4-245
importar ............................................................... 7-43 paquete TCP sin indicadores, detectar ............. 4-15
mapas ................................................................... 7-39 paquetes ICMP grandes, bloquear ................... 4-244
métricas ................................................................ 7-32 Ping of Death ....................................................... 4-53
null ........................................................................ 5-87 protocolos desconocidos, descartar ................ 4-246
preferencia ........................................................... 7-31 Simulación de IP .......................................4-20 a 4-25
redistribución....................................................... 7-38 Teardrop ............................................................... 4-54
selección ............................................................... 7-31 zonas VLAN y MGT................................................ 4-3
Rutas BGP, agregadas SCREEN, zona MGT ................................................... 2-28
agregación .......................................................... 7-134 ScreenOS
AS-Path en .......................................................... 7-136 directivas ................................................................ 2-3
AS-Set en ............................................................ 7-134 flujo de paquetes ......................................2-10 a 2-12
atributos de ........................................................ 7-137 ID de fabricante de RADIUS ............................... 9-22
Rutas OSPF sistemas virtuales .................................................. 2-8
predeterminadas, rechazo ................................. 7-69 vista general ........................................................... 2-1
redistribución....................................................... 7-59 VR .......................................................................... 10-6
redistribuido, resumen ....................................... 7-60 zona de seguridad global ...................................... 2-2
restricción route-deny, inhabilitación ............... 7-72 zona global ........................................................... 2-28
zonas ................................................ 2-25 a 2-32, 10-7
S zonas de función ................................................. 2-32
SA ................................................................. 5-8, 5-9, 5-11 zonas de seguridad ..................................... 2-2, 2-27
Servicios VIP zonas de seguridad predefinidas ......................... 2-2
personalizados, números de puerto bajos ....... 8-82 zonas de túnel...................................................... 2-28
SA inactiva ................................................................ 3-102 SDP ...................................................................6-18 a 6-19
SAs secuencia de bits ..................................................... 3-100
comprobación en flujo de paquetes.................. 5-68 Secure Copy
SCEP (Simple Certificate Enrollment Protocol) ...... 5-31 Veáse SCP
SCP Secure Hash Algorithm-1
ejemplo de comando del cliente ....................... 3-19 véase SHA-1
habilitar ................................................................ 3-18 Secure Shell
SCREEN Consulte SSH
Ataques terrestres ............................................... 4-52 Secure Sockets Layer
Ataques WinNuke ............................................... 4-55 véase SSL
barrida de puertos ................................................. 4-9 SecurID ....................................................................... 9-28
barrido de direcciones .......................................... 4-8 autenticador ......................................................... 9-28
descartar las direcciones MAC desconocidas .. 4-43 códigos token ....................................................... 9-28
FIN sin ACK .......................................................... 4-16 L2TP .................................................................... 5-217
FIN sin indicador ACK, descartar ...................... 4-14 objeto servidor de autenticación ....................... 9-36
fragmentos de paquetes IP, bloquear ............. 4-247 opción Use Duress............................................... 9-29
fragmentos SYN, detectar ................................ 4-248 puerto de autenticación ...................................... 9-29
ICMP servidores ACE..................................................... 9-29
fragmentos, bloquear .................................. 4-243 tipos de encriptación .......................................... 9-29
indicadores SYN y FIN activados ...................... 4-13 usuarios, tipos admitidos ................................... 9-30
inundaciones de SYN-ACK-ACK a través de un seguimiento de IP ...................................... 11-55, 12-117
servidor proxy ................................................... 4-35 ejecución del comando ping y ARP ................ 11-55
Inundaciones ICMP ............................................. 4-49 interfaces, compartidas ...................................... 2-63
Índice maestro IX-XIX

interfaces, compatibles ...................................... 2-62 respaldo ................................................................ 9-18

opción “dynamic” ............................................... 2-63 SecurID ................................................................. 9-28
pesos..................................................................... 2-64 SecurID, definición.............................................. 9-36
redireccionamiento de tráfico ................ 2-62 a 2-78 tiempo de espera por inactividad ..................... 9-18
umbral de fallos del objeto ................................ 2-64 tipos ...................................................................... 9-18
vsys ....................................................................... 2-63 véase servidores de autenticación
seguimiento de IP, fallo servidores de autenticación, objetos de
interfaz de entrada, en ............................ 2-75 a 2-78 nombres ............................................................... 9-18
interfaz de salida, en ............................... 2-74 a 2-75 propiedades ......................................................... 9-18
umbral de IP marcado ........................................ 2-64 servidores de autenticación, RADIUS ..........9-19 a 9-23
seguimiento de ruta .............................................. 12-117 definición ............................................................. 9-34
seguimiento de túnel ............................................ 12-117 usuarios, tipos admitidos ................................... 9-21
seguridad servidores de autenticación, TACACS+
asignación de prioridades .................................. 9-33 definición ............................................................. 9-39
Seguridad IP servidores, SecurID ACE ........................................... 9-29
véase IPSec Sesión de acceso IPSec (IAS) ................................ 14-132
selección, modos sesiones multimedia, SIP.......................................... 6-14
APN ..................................................................... 13-16 SHA-1 ............................................................................ 5-6
estación móvil (MS) .......................................... 13-16 Simulación de IP
red ....................................................................... 13-16 Capa 2 .........................................................4-21, 4-24
verificado ........................................................... 13-16 Capa 3 .........................................................4-20, 4-22
serie, cables ................................................................ 3-19 drop-no-rpf-route ................................................. 4-20
Servicio de autenticación remota de usuarios de acceso simulación de IP .............................................4-20 a 4-25
telefónico sincronización
véase RADIUS configuración ..................................................... 11-20
servicios .................................................................... 2-109 RTO ..................................................................... 11-21
definido .............................................................. 2-168 Sincronización de NSRP-Lite
en directivas ...................................................... 2-168 desactivar ........................................................... 11-19
ICMP ................................................................... 2-127 sincronización NSRP
lista desplegable ................................................ 2-109 NTP, NSRP ......................................................... 11-21
personalizados................................................... 4-156 RTO ..................................................................... 11-21
umbral del tiempo de espera .......................... 2-124 SIP
servicios ICMP ......................................................... 2-127 ALG ..............................................................6-17, 6-21
códigos de mensaje .......................................... 2-128 anuncios de medios ............................................ 6-19
tipos de mensaje ............................................... 2-128 códigos de respuesta .......................................... 6-16
servicios personalizados ......................................... 2-122 definido ................................................................ 6-13
servicios personalizados, en raíz y vsys................ 2-123 información de la conexión ............................... 6-19
Servicios VIP mensajes .............................................................. 6-14
personalizados y multipuerto ................. 8-85 a 8-89 métodos de petición ........................................... 6-14
servicios, personalizados ........................................ 2-122 ojos de aguja ........................................................ 6-18
ALG ..................................................................... 2-169 RTCP ..................................................................... 6-19
en vsys ............................................................... 2-123 RTP ....................................................................... 6-19
Servidor PXE ............................................................ 2-240 SDP ............................................................6-18 a 6-19
Servidor WINS ....................................................... 14-129 señalización ......................................................... 6-17
servidores de autenticación .......................... 9-13 a 9-42 sesiones multimedia ........................................... 6-14
consultas de XAuth ............................................. 9-73 SIP NAT
definición .................................................. 9-34 a 9-42 configuración de llamadas ........................6-24, 6-30
direcciones ........................................................... 9-18 definido ................................................................ 6-24
enrutador ............................................................. 9-17 DIP, utilizar entrante .......................................... 6-32
LDAP .......................................................... 9-30 a 9-31 entrante, con MIP.......................................6-36, 6-38
número de identificación ................................... 9-18 proxy en DMZ...................................................... 6-45
número máximo ................................................. 9-14 proxy en zona privada...............................6-40, 6-90
predeterminadas ........................................9-40, 9-41 proxy en zona pública ........................................ 6-43
proceso de autenticación ................................... 9-17 trust intrazonal .................................................... 6-52
IX-XX Índice maestro

Índice maestro
untrust intrazonal ................................................ 6-98 SSH ....................................................... 3-11 a 3-16, 4-135

untrust intrazone ................................................. 6-49 autenticación mediante contraseña .................. 3-14
utilizar DIP de interfaz ........................................ 6-33 autenticación mediante PKA ............................. 3-14
utilizar un rango DIP ........................................... 6-36 cargar claves públicas, CLI ................................. 3-15
VPN, con uso de malla completa ...........6-55, 6-104 cargar claves públicas, TFTP .................... 3-15, 3-18
Sistema con capacidad para IDP ........................... 4-176 cargar claves públicas, WebUI ........................... 3-15
Sistema de nombres de dominio forzar la autenticación mediante PKA
véase DNS exclusivamente ................................................. 3-16
Sistema de nombres de dominio (DNS) inicios de sesión automatizados ........................ 3-17
actualizar ............................................................ 14-42 opciones de administración ............................... 3-29
consultas de dominios ...................................... 14-44 PKA ....................................................................... 3-15
direcciones IPv4 o IPv6 .................................... 14-42 prioridad del método de autenticación ............ 3-16
host del cliente DHCP ....................................... 14-43 procedimiento de conexión ............................... 3-12
lista de búsqueda .............................................. 14-43 SSID
lista de búsqueda de DHCPv6 ......................... 14-36 asociación a interfaz inalámbrica .................. 12-153
nombres de dominio parciales ........................ 14-36 SSL ..................................................................... 3-5, 4-135
proxy .................................................................. 14-44 SSL Handshake Protocol
servidores ......................................................... 14-129 véase SSLHP
servidores, encapsulamiento a ........................ 14-44 SSL, con WebAuth ...................................................... 9-65
sistema, reloj SSLHP ............................................................................ 3-5
véase reloj del sistema subinterfaces .................................................... 2-3, 10-63
sistemas operativos, sondeos de host configuración (vsys) .......................................... 10-63
para ...............................................................4-12 a 4-15 creación (vsys) ................................................... 10-63
sistemas virtuales ........................................................ 2-8 crear (sistema raíz) .............................................. 2-48
administradores .................................................. 3-36 eliminar ................................................................ 2-49
administradores de sólo lectura ........................ 3-36 varias por vsys ................................................... 10-63
cambio en caso de fallo .................................... 11-58 Subvelocidad, opción .............................................. 12-21
manejabilidad y seguridad de.......................... 10-75 Sun RPC ALG
NSRP ................................................................... 11-58 definido .............................................................. 2-129
reparto de carga ................................................ 11-84 supuestos de llamadas ...................................... 2-129
VIP....................................................................... 10-33 Super G ................................................................... 12-141
SMB superpuestas, redes ................................................. 10-64
NetBIOS .............................................................. 4-136 supervisión de VPN ...................... 5-250 a 5-262, 12-118
SNMP .................................................................3-29, 3-78 cambios de estado ................................ 5-250, 5-254
archivos MIB, importación ............................... 5-262 dirección de destino .............................5-252 a 5-255
captura de inicio en frío ..................................... 3-79 dirección de destino, XAuth ............................. 5-253
configuración ....................................................... 3-82 directivas ............................................................ 5-253
encriptación ................................................3-82, 3-83 diseño de rutas .................................................... 5-74
opciones de administración ............................... 3-29 interfaz de salida ..................................5-252 a 5-255
supervisión de VPN ........................................... 5-262 opción de reencriptación...................... 5-251, 5-268
SNMPTRAP ............................................................... 4-135 peticiones de eco ICMP .................................... 5-262
Solicitud de vecino (NS) ...............................14-14, 14-31 SNMP .................................................................. 5-262
ajuste .................................................................. 14-30 Supresión de notificaciones de estado de
Solicitud del enrutador (RS) .................................... 14-11 conexiones (LSA) ..................................................... 7-70
solicitudes de servicio, saliente ...................14-85, 14-87 SurfControl ................................................... 4-101, 4-110
Solución de control de acceso unificado suscripciones
introducción de ....................................................1-liii registro y activación .............................2-254 a 2-256
solución de control de acceso unificado servicio temporal ............................................... 2-255
vista general de .......................................... 9-vii, 9-43 SYN, cookies............................................................... 4-47
sondeo ...................................................................... 14-31 syslog............................................................... 3-60, 4-135
puertos abiertos ..................................................... 4-9 encriptación ......................................................... 3-83
red ........................................................................... 4-8 host ....................................................................... 3-76
sistemas operativos ...................................4-12, 4-15 mensajes .............................................................. 3-76
sondeo del sitio ...................................................... 12-139 nombre de host ...................... 3-77, 3-78, 3-86, 3-94
Índice maestro IX-XXI

puerto ................................................ 3-77, 3-86, 3-94 UDP ....................................................................... 4-34

servicio de seguridad ....................... 3-77, 3-86, 3-94 Tipos de atributos VSA .............................................. 9-23
utilidad .............................................. 3-77, 3-86, 3-94 trace-route .................................................................. 2-85
traducción de direcciones
T Véase NAT, NAT-dst y NAT-src
Tabla de caché de vecinos ....14-13, 14-15, 14-25, 14-30 traducción de direcciones de puertos
Tabla de caché de vecinos, categorías de entrada de véase PAT
vecinos ................................................................... 14-13 Traducción de direcciones de red (NAT) ............... 3-101
tabla NHTB .................................................. 5-263 a 5-268 Traducción de direcciones de red-Traducción de
asignación de rutas a túneles .......................... 5-264 puerto (NAT-PT) ..................................................... 14-81
entradas automáticas ....................................... 5-267 Traducción de direcciones de red-Traducción de
entradas manuales ............................................ 5-267 puertos
esquema de direccionamiento ........................ 5-266 cuándo utilizarla ................................................ 14-82
tablas de enrutamiento ............................................. 7-15 DIP de IPv6 a IPv4 ............................................ 14-83
consulta ................................................................ 7-33 Direcciones DIP, traducción ............................ 14-84
consulta en múltiples VR.................................... 7-35 Hosts IPv4 a hosts IPv6 múltiples ................... 14-89
multicast............................................................. 7-159 Hosts IPv4 a un solo host IPv6 ........................ 14-90
selección de rutas ............................................... 7-31 Hosts IPv6 a un host IPv4 individual .............. 14-87
tipos ...................................................................... 7-15 Hosts IPv6 a varios hosts IPv4 ........................ 14-85
TACACS+ IP dinámica (DIP) .............................................. 14-81
objetos servidor de autenticación ..................... 9-39 MIP ...................................................................... 14-82
propiedades del objeto ....................................... 9-33 MIP de IPv4 a IPv6 ............................................ 14-84
puertos ................................................................. 9-33 solicitudes de servicio saliente .............14-82, 14-85
reintentos de clienteS ......................................... 9-33 traducción de direcciones origen .................... 14-82
secreto compartido ............................................. 9-33 traducción de direcciones origen........................... 14-82
tiempo de espera de clientes ............................. 9-33 tráfico
tiempo de espera entre reintentos.................... 9-33 asignación .......................................................... 2-195
tareas programadas......................................2-158, 2-175 clasificación ..........................................10-33 a 10-41
TCP iniciar sesión ...................................................... 2-174
comprobación de indicador SYN .................... 5-307 prioridad ............................................................. 2-175
firmas de secuencias ........................................ 4-165 recuento ....................................................2-174, 13-5
paquete sin indicadores ..................................... 4-15 registro ................................................................. 13-5
tiempos de espera de sesiones.......................... 4-34 según IP .............................................................. 10-73
TCP proxy ................................................................. 3-102 según VLAN............................... 10-42, 10-43 a 10-69
Teardrop, ataques ...................................................... 4-54 tráfico de tránsito, clasificación de vsys ...... 10-34 a
Telnet ...............................................................3-10, 4-135 10-38
Telnet, inicio de sesión mediante ............................ 3-11 tráfico administrativo ................................................ 3-30
TFTP .......................................................................... 4-135 tráfico GTP
tiempo de espera ..................................................... 13-27 iniciar sesión ...................................................... 13-33
usuarios administradores ................................... 9-18 recuento ............................................................. 13-35
usuarios de autenticación .................................. 9-18 Transiciones de estado
tiempo de espera de la sesión enrutador de puerta de enlace de siguiente
HTTP ..................................................................... 4-34 salto .................................................................. 14-16
tiempo de espera por sesión inactiva ..................... 9-19 entrada estática ................................................. 14-18
Tiempo de espera SIP host de punto final ............................................ 14-15
por inactividad .................................................... 6-21 puerta de enlace de túnel ................................. 14-17
por inactividad de la sesión ............................... 6-21 Transparente, modo ................................................ 10-44
por inactividad de medios ........................6-22, 6-23 Triple DES
por inactividad de señalización ................6-22, 6-23 véase 3DES
tiempo de inactividad de VPN ................................. 9-75 troncales, puertos .........................................10-44, 10-45
Tiempo de retransmisión ....................................... 14-31 túnel de GTP en espera ........................................... 13-27
Tiempo de sondeo................................................... 14-31 túneles de GTP colgados ......................................... 13-27
tiempos de espera de sesiones túneles GTP
TCP ....................................................................... 4-34 conmutación por error ..................................... 13-26
IX-XXII Índice maestro

Índice maestro
límite ................................................................... 13-25 XAuth .................................................................... 9-72

tiempo de espera .............................................. 13-27 usuarios de autenticación, tiempo de ejecución
autenticación........................................................ 9-48
U externos, usuarios ............................................... 9-54
UDP grupo de usuarios, externos ............................... 9-56
encapsulación NAT-T ........................................ 5-240 grupos de usuarios locales ................................. 9-53
suma de comprobación .................................... 5-245 locales, usuarios .................................................. 9-51
tiempos de espera de sesiones .......................... 4-34 proceso de autenticación ................................... 9-49
umbral usuarios de autenticación, WebAuth ....................... 9-49
umbral inferior .................................................... 4-33 con SSL (externos, grupos de usuarios) ............ 9-65
umbral superior ................................................... 4-33 grupo de usuarios, externos ............................... 9-62
Unidad máxima de transmisión (MTU) ................ 14-11 grupos de usuarios locales ................................. 9-61
USB .............................................................................. 3-60 usuarios IKE .......................................... 9-14, 9-69 a 9-72
usuarios con otros tipos de usuario .................................... 9-4
administrador, tiempo de espera ...................... 9-18 definición.............................................................. 9-70
administradores .................................................... 9-2 grupos ................................................................... 9-70
de múltiples tipos .................................................. 9-4 grupos, definir ..................................................... 9-71
grupos, servidores admitidos............................. 9-14 grupos, y ............................................................... 9-69
identificación IKE compartida ............5-204 a 5-210 identificación IKE ...................................... 9-69, 9-84
identificación IKE de grupo.................5-188 a 5-204 servidores admitidos ........................................... 9-14
IKE usuarios L2TP ............................................................. 9-89
véase usuarios IKE con XAuth............................................................... 9-4
L2TP ...........................................................9-89 a 9-92 servidores admitidos ........................................... 9-14
WebAuth .............................................................. 9-14 usuarios XAuth ................................................9-72 a 9-87
XAuth .........................................................9-72 a 9-87 autenticación........................................................ 9-72
usuarios administradores ........................................... 9-2 autenticación de grupo local .............................. 9-78
dar prioridad a la autenticación ........................ 9-33 autenticación local .............................................. 9-76
privilegios desde RADIUS ..................................... 9-3 con L2TP................................................................. 9-4
servidores admitidos .......................................... 9-14 servidores admitidos ........................................... 9-14
tiempo de espera ................................................ 9-18 usuarios, IKE
usuarios autorizados, autenticación de véase usuarios IKE
previa a la directiva ............................................. 9-49 usuarios, múltiples administrativos ......................... 3-35
punto de ................................................................. 9-1
servidores de autenticación, con ....................... 9-14 V
usuarios de autenticación ..............................9-47 a 9-68 validación del número de secuencia ..................... 13-13
administradores .................................................... 9-2 VC .............................................................................. 12-70
autenticación en tiempo de ejecución ............ 2-172 VCI ............................................................................. 12-70
autenticación previa a la directiva .................. 2-173 Verisign ....................................................................... 5-35
base de datos local ...................................9-15 a 9-17 VIP ............................................................................... 2-11
clave manual ........................................................ 9-14 alcanzable desde otras zonas ............................ 8-83
de múltiples tipos .................................................. 9-4 configuración ....................................................... 8-83
en directivas......................................................... 9-48 definición................................................................ 8-6
grupos ..........................................................9-47, 9-50 edición .................................................................. 8-85
IKE ...............................................................9-14, 9-69 eliminación .......................................................... 8-85
inicio de sesión, con diferentes nombres .......... 9-5 información necesaria ........................................ 8-82
L2TP ...................................................................... 9-89 zonas globales...................................................... 8-83
proceso de autenticación en tiempo de Visualizador de registros
ejecución .......................................................... 2-172 Creación de una norma de exclusión ............. 4-209
servidores admitidos .......................................... 9-14 VLAN
tiempo de espera ................................................ 9-18 clasificación del tráfico según
tipos de usuarios ................................................. 9-13 VLAN ........................................ 10-42, 10-43 a 10-69
tipos y aplicaciones ......................................9-1 a 9-5 comunicación con otra
véase usuarios de autenticación VLAN ........................................ 10-41, 10-66 a 10-69
WebAuth ...................................................2-173, 9-14 crear .......................................................10-45 a 10-66
Índice maestro IX-XXIII

entroncamiento ................................................. 10-44 VPN basadas en rutas ....................................5-64 a 5-65

etiqueta ...................................................10-45, 10-63 VPNs
modo transparente ................................10-44, 10-45 FQDN para puertas de enlace.............5-132 a 5-142
subinterfaces ..................................................... 10-63 NAT para direcciones superpuestas ...5-142 a 5-154
VLAN1 VR ........................................................... 7-38 a 7-44, 10-6
interfaz ........................................................2-80, 2-87 BGP ........................................................7-112 a 7-120
zonas .................................................................... 2-81 compartido, crear un ........................................ 10-40
VLAN1, opciones de administración ....................... 3-30 compartidos ....................................................... 10-39
VLANs, etiquetas .......................................................... 2-3 ECMP .................................................................... 7-37
VNC ........................................................................... 4-135 en vsys.................................................................. 7-27
voz sobre IP ID de enrutador ................................................... 7-23
administración del ancho de banda ................. 6-65 introducción ........................................................... 2-4
VPI ............................................................................. 12-70 listas de acceso .................................................... 7-41
VPI/VCI métricas de ruta .................................................. 7-32
configuración ..................................................... 12-76 modificar .............................................................. 7-22
valores ................................................................ 12-78 OSPF ..........................................................7-51 a 7-70
VPN reenviar tráfico entre ............................................ 2-4
a una zona con NAT basada en interfaces ....... 2-94 RIP .............................................................7-81 a 7-96
alias FQDN ......................................................... 5-133 SBR........................................................................ 7-18
AutoKey IKE ....................................... 3-46, 3-84, 5-7 SIBR ...................................................................... 7-20
basadas en rutas o basadas en directivas ........ 5-64 uso de dos ............................................................ 7-24
claves manuales .........................................3-46, 3-84 VR compartidos ....................................................... 10-39
consejos de configuración....................... 5-72 a 5-73 VR, rutas
Diffie-Hellman, grupos ....................................... 5-11 exportación .......................................................... 7-43
directiva para bidireccionales .......................... 5-128 filtrado .................................................................. 7-41
directivas ............................................................ 2-170 importar ............................................................... 7-43
Fase 1 ..................................................................... 5-9 mapas ................................................................... 7-39
Fase 2 ................................................................... 5-11 preferencia ........................................................... 7-31
flujo de paquetes ...................................... 5-66 a 5-71 redistribución....................................................... 7-38
grupos redundantes, procedimiento de selección ............................................................... 7-31
recuperación.................................................... 5-306 VR, tablas de enrutamiento
grupos VPN ........................................................ 5-302 consulta ................................................................ 7-33
ID de proxy, coincidencia .................................. 5-72 consulta en múltiples VR .................................... 7-35
intercambio Diffie-Hellman ............................... 5-11 entradas máximas .............................................. 7-30
MIP...................................................................... 5-143 VRRP ......................................................................... 11-55
modo de transporte .............................................. 5-4 VSA .............................................................................. 9-22
modo dinámico ................................................... 5-10 VSI ....................................................................11-2, 11-22
modo principal .................................................... 5-10 rutas estáticas .................................................... 11-25
múltiples túneles por interfaz de túnel .........5-263 a varias VSI por grupo VSD ................................. 11-58
5-300 vsys
NAT-dst............................................................... 5-143 administradores .................................................. 10-8
NAT-src ............................................................... 5-145 claves .................................................................. 10-39
opciones criptográficas ........................... 5-50 a 5-64 objetos, crear ....................................................... 10-4
para tráfico administrativo ................................ 3-83
protección contra reprocesamiento de W
paquetes ............................................................ 5-12 web, filtrado ................................................4-110 a 4-118
puertas de enlace redundantes .......... 5-301 a 5-314 WebAuth ............................................................9-14, 9-49
SA ............................................................................ 5-8 con SSL (externos, grupos de usuarios) ............ 9-65
supervisión y reencriptación de VPN ............. 5-251 grupos de usuarios externos .............................. 9-62
túnel siempre activo ......................................... 5-251 grupos de usuarios locales ................................. 9-61
zonas de túnel ..................................................... 2-28 proceso de autenticación previo a directivas .. 9-49
VPN AutoKey IKE ...................................... 3-46, 3-84, 5-7 WebAuth, proceso de autenticación previo a
administración ...................................................... 5-7 directivas................................................................ 2-173
VPN basada en directivas ......................................... 5-64 WebTrends .........................................................3-60, 3-77
IX-XXIV Índice maestro

Índice maestro
encriptación ................................................3-77, 3-83 bypass-auth .......................................................... 9-74

mensajes .............................................................. 3-78 consultar ajustes remotos................................... 9-73
WebUI ................................................................3-2, 14-32 cuándo utilizarlo .............................................. 14-129
Archivos de ayuda ................................................. 3-2 definición.............................................................. 9-72
opciones de administración ............................... 3-29 ScreenOS como cliente....................................... 9-88
WebUI, en cliente de muestra, enrutador supervisión de VPN ........................................... 5-253
descendente .......................................................... 14-40 tiempo de inactividad de VPN ........................... 9-75
WEP......................................................................... 12-129 XAuth, direcciones
Whois ........................................................................ 4-135 asignaciones ......................................................... 9-73
WinNuke, ataques ...................................................... 4-55 autenticación, y ................................................... 9-84
WINS tiempo de espera................................................. 9-74
ajustes de L2TP.................................................. 5-217 XAuth, externo
Wired Equivalent Privacy autenticación de grupo de usuarios .................. 9-81
véase WEP autenticación de usuarios ................................... 9-79
WLAN consultas al servidor de autenticación .............. 9-73
autenticación y encriptación.......................... 12-128 XR, configuración .................................................. 12-141
canales extendidos.......................................... 12-138
canales y códigos de países ........................... 12-138 Y
configuración de Super G ............................... 12-141 Yahoo! Messenger .................................................... 4-135
configuraciones, reactivación ........................ 12-141
DTIM ................................................................. 12-149 Z
encontrar canales disponibles ....................... 12-139 zombie, agentes ............................................... 4-29, 4-31
grupos en puente ............................................ 12-154 zona VLAN .................................................................. 2-80
intervalo de baliza ........................................... 12-148 zonas ...................................................... 2-25 a 2-32, 10-7
intervalo de envejecimiento .......................... 12-147 capa 2 ................................................................... 2-81
lista de control de acceso ............................... 12-140 compartidas ....................................................... 10-39
longitud del preámbulo .................................. 12-152 definición.............................................................. 2-30
modo de vía libre para enviar ....................... 12-150 edición .................................................................. 2-31
parámetros avanzados ................................... 12-147 función .................................................................. 2-32
sondeo del sitio ............................................... 12-139 función, interfaz MGT ......................................... 2-36
tasa de vía libre para enviar........................... 12-151 global .................................................................... 2-28
tiempo de franja .............................................. 12-152 seguridad global .................................................... 2-2
tipo de vía libre para enviar ........................... 12-151 túnel ...................................................................... 2-28
umbral de fragmentos .................................... 12-149 VLAN ........................................................... 2-32, 2-80
umbral de ráfagas ........................................... 12-149 vsys ....................................................................... 10-7
umbral de solicitud de envío ......................... 12-150 zonas compartidas................................................... 10-39
visualización de la información de configuración zonas de seguridad ...................................................... 2-2
inalámbrica .................................................... 12-155 determinación, zona de destino ........................ 2-12
WMM ................................................................ 12-142 determinación, zona de origen.......................... 2-10
XR ..................................................................... 12-141 global ...................................................................... 2-2
WLAN, interfaces inalámbricas predefinido ............................................................. 2-2
asociación ........................................................ 12-153 véase zonas
WMM zonas de seguridad, interfaces ................................... 2-3
ajustes predeterminados ................................ 12-144 físicas .................................................................... 2-34
categorías de acceso ....................................... 12-143 zonas globales ............................................................ 8-83
configuración de la calidad del servicio ....... 12-143 zonas, ScreenOS .............................................2-25 a 2-32
habilitar ............................................................ 12-142 interfaces de seguridad......................................... 2-3
predefinido ............................................................. 2-2
X zonas, seguridad ................................................ 2-2, 2-27
XAuth determinación, zona de destino ........................ 2-12
adaptadores virtuales.......................................... 9-73 determinación, zona de origen.......................... 2-10
asignaciones TCP/IP ............................................ 9-74 global ...................................................................... 2-2
Autenticación ................................................... 14-136 interfaces, físicas ................................................. 2-34
autenticación del cliente..................................... 9-88 interfaces, supervisión ........................................ 2-72
Índice maestro IX-XXV

IX-XXVI Índice maestro

Volumen 2:
Fundamentos
Versión 6.0.0, Rev. 02

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Número de pieza: 530-017768-01-SP, Revisión 02
Copyright Notice
without notice.
FCC Statement
Disclaimer
ii
Contenido
Capítulo 1 Arquitectura de ScreenOS 1

Zonas de seguridad .......................................................................................... 2
Interfaces de zonas de seguridad ..................................................................... 3
Interfaces físicas ........................................................................................ 3
Subinterfaces............................................................................................. 3
Enrutadores virtuales ....................................................................................... 4
Directivas......................................................................................................... 5
Redes privadas virtuales................................................................................... 7
Sistemas virtuales ............................................................................................ 8
Secuencia de flujo de paquetes ...................................................................... 10
Tramas jumbo................................................................................................ 13
Ejemplo de arquitectura de ScreenOS ............................................................ 13
Ejemplo: (Parte 1) Empresa con seis zonas.............................................. 13
Ejemplo: (Parte 2) Interfaces para las seis zonas...................................... 15
Ejemplo: (Parte 3) Dos dominios de enrutamiento .................................. 18
Ejemplo: (Parte 4) Directivas ................................................................... 19
Capítulo 2 Zonas 25
Ver las zonas preconfiguradas........................................................................ 26
Zonas de seguridad ........................................................................................ 27
Zona Global ............................................................................................. 28
Opciones SCREEN ................................................................................... 28
Asociar una interfaz de túnel a una zona de túnel .......................................... 28
Configuración de zonas de seguridad y zonas de túnel .................................. 30
Creación de una zona .............................................................................. 30
Modificación de una zona........................................................................ 31
Eliminación de una zona ......................................................................... 32
Zonas de función ........................................................................................... 32
Capítulo 3 Interfaces 33
Tipos de interfaces......................................................................................... 33
Interfaces lógicas ..................................................................................... 33
Interfaces físicas ............................................................................... 34
Interfaces inalámbricas ..................................................................... 34
Contenido iii
Interfaces de grupos en puente ......................................................... 34

Subinterfaces .................................................................................... 35
Interfaces agregadas ......................................................................... 35
Interfaces redundantes...................................................................... 35
Interfaces de seguridad virtuales ....................................................... 36
Interfaces de zonas de función ................................................................ 36
Interfaces de administración ............................................................. 36
Interfaces de alta disponibilidad........................................................ 36
Interfaces de túnel................................................................................... 37
Eliminación de interfaces de túnel ....................................................40
Visualización de interfaces ............................................................................. 41
Configuración de interfaces de la zona de seguridad...................................... 42
Asociación de una interfaz a una zona de seguridad................................ 43
Desasociación de una interfaz de una zona de seguridad ........................ 44
Direccionamiento de una interfaz de la zona de seguridad L3 ................. 45
Direcciones IP públicas ..................................................................... 45
Direcciones IP privadas..................................................................... 46
Direccionamiento de una interfaz ..................................................... 46
Modificar los ajustes de interfaz............................................................... 47
Creación de una subinterfaz en el sistema raíz ........................................ 48
Eliminación de una subinterfaz ............................................................... 49
Creación de una dirección IP secundaria........................................................ 49
Interfaces del sistema de respaldo .................................................................50
Configuración de una interfaz de respaldo............................................... 51
Configuración de una interfaz de respaldo de seguimiento de IP ...... 51
Configuración de una interfaz de respaldo de túnel-if .......................52
Configuración de una interfaz de respaldo de supervisión de rutas ... 56
Interfaces de bucle invertido (o “loopback”)................................................... 57
Creación de una interfaz de bucle invertido............................................. 58
Configuración de la interfaz de bucle invertido para la administración.... 58
Configuración de BGP en una interfaz de bucle invertido ........................ 58
Configuración de VSI en una interfaz de bucle invertido.......................... 59
Configuración de la interfaz de bucle invertido como interfaz de origen.. 59
Cambios de estado de la interfaz ................................................................... 60
Supervisión de la conexión física ............................................................. 62
Seguimiento de direcciones IP.................................................................62
Supervisión de interfaces......................................................................... 67
Supervisión de dos interfaces............................................................ 68
Supervisión de un bucle de interfaces ............................................... 69
Supervisión de zonas de seguridad .......................................................... 72
Interfaces fuera de línea y flujo de tráfico ................................................ 73
Error en la interfaz de salida ............................................................. 74
Fallo en la interfaz de entrada........................................................... 75
Capítulo 4 Modos de las interfaces 79

Modo transparente......................................................................................... 79
Ajustes de zona ....................................................................................... 80
Zona VLAN........................................................................................ 80
Zonas de capa 2 predefinidas............................................................ 81
Reenvío de tráfico ................................................................................... 81
Opciones “unicast” desconocidas ............................................................ 82
Método de inundación ...................................................................... 83
Método ARP/Trace-Route .................................................................. 84
Configurar la interfaz VLAN1 para administración ............................ 87
iv Contenido
Contenido
Configuración del modo transparente ............................................... 89

Modo NAT...................................................................................................... 92
Tráfico NAT entrante y saliente ............................................................... 94
Configuración de modo NAT ................................................................... 95
Modo de rutas ................................................................................................ 98
Configuración del modo de rutas............................................................. 99
Capítulo 5 Bloques para la construcción de directivas 103

Direcciones ..................................................................................................103
Entradas de direcciones.........................................................................104
Adición de una dirección.................................................................104
Modificación de una dirección ........................................................105
Eliminación de una dirección ..........................................................105
Grupos de direcciones ...........................................................................105
Creación de un grupo de direcciones ..............................................107
Edición de una entrada de grupo de direcciones .............................108
Eliminación de un miembro y un grupo..........................................108
Servicios ......................................................................................................109
Servicios predefinidos............................................................................109
Protocolo de mensajes de control de Internet .................................110
Manejo de errores de destinos inalcanzables de ICMP ....................113
Servicios predefinidos relacionados con Internet ............................113
Servicios de llamadas de procedimiento remoto de Microsoft.........115
Protocolos de enrutamiento dinámico.............................................117
Vídeo de secuencias ........................................................................117
Servicios de llamadas de procedimiento remoto de Sun .................118
Servicios de túnel y seguridad .........................................................119
Servicios relacionados con IP ..........................................................119
Servicios de mensajes instantáneos ................................................120
Servicios de administración ............................................................120
Servicios de correo..........................................................................121
Servicios UNIX ................................................................................121
Servicios varios ...............................................................................122
Servicios personalizados........................................................................122
Adición de un servicio personalizado ..............................................123
Modificación de un servicio personalizado ......................................124
Eliminación de un servicio personalizado .......................................124
Establecimiento del tiempo de espera de un servicio ............................124
Configuración y consulta del tiempo de espera de un servicio ........125
Contingencias .................................................................................126
Ejemplo...........................................................................................127
Definición de un servicio personalizado de protocolo de mensajes de
control de Internet ..........................................................................127
ALG de Shell remoto ..............................................................................128
Capa de aplicación de llamada al procedimiento remoto de Sun ...........129
Situación típica de llamadas RPC ....................................................129
Personalización de los servicios de Sun RPC ...................................130
Personalización del procedimiento remoto de Microsoft Call ALG .........130
Puerta de enlace de la capa de aplicación del protocolo de secuencias en
tiempo real .....................................................................................132
Métodos de petición RTSP...............................................................133
Códigos de estado de RTSP .............................................................135
Contenido v
Configuración de un servidor de medios en un dominio privado ....136

Configuración de un servidor de medios en un dominio público.....138
Grupos de servicios................................................................................140
Modificación de un grupo de servicios ............................................141
Eliminación de un grupo de servicios..............................................142
Conjuntos de IP dinámicas...........................................................................142
Traducción de direcciones de puertos....................................................143
Creación de un conjunto de DIP con PAT ..............................................144
Modificación de un conjunto de DIP ......................................................145
Direcciones DIP persistentes .................................................................145
Uso de DIP en una subred distinta.........................................................146
Uso de una DIP en una interfaz de bucle invertido ................................151
Creación de un grupo DIP......................................................................155
Configuración de una programación recurrente ...........................................158
Capítulo 6 Directivas 161

Elementos básicos .......................................................................................162
Tres tipos de directivas ................................................................................163
Directivas interzonales ..........................................................................163
Directivas intrazonales ..........................................................................163
Directivas globales.................................................................................164
Listas de conjuntos de directivas ..................................................................164
Definición de directivas................................................................................165
Directivas y reglas .................................................................................166
Anatomía de una directiva.....................................................................166
ID....................................................................................................167
Zonas ..............................................................................................168
Direcciones .....................................................................................168
Servicios .........................................................................................168
Acción.............................................................................................168
Aplicación .......................................................................................169
Nombre...........................................................................................170
Encapsulamiento VPN.....................................................................170
Encapsulamiento L2TP....................................................................170
Deep Inspection ..............................................................................171
Colocación al principio de la lista de directivas ...............................171
Traducción de direcciones de origen ...............................................171
Traducción de direcciones de destino .............................................171
Autenticación de usuarios ...............................................................172
Copia de seguridad de la sesión HA ................................................174
Filtrado de Web ..............................................................................174
Registro...........................................................................................174
Recuento.........................................................................................174
Umbral de alarma de tráfico ...........................................................174
Tareas programadas........................................................................175
Análisis antivirus .............................................................................175
Asignación de tráfico.......................................................................175
Directivas aplicadas .....................................................................................176
Visualización de directivas.....................................................................177
Creación de directivas ...........................................................................177
Creación del servicio de correo de directivas interzonales...............177
Creación de un conjunto de directivas interzonales.........................180
Creación de directivas intrazonales .................................................185
Creación de una directiva global .....................................................186
vi Contenido
Contenido
Introducción del contexto de una directiva............................................187

Varios elementos por componente de directiva .....................................188
Ajuste de la negación de direcciones .....................................................189
Modificación y desactivación de directivas ............................................191
Verificación de directivas.......................................................................192
Reordenamiento de directivas ...............................................................193
Eliminación de una directiva .................................................................194
Capítulo 7 Asignación de tráfico 195

Administración del ancho de banda a nivel de directivas .............................195
Establecimiento de la asignación de tráfico..................................................196
Establecimiento de las prioridades del servicio ............................................200
Establecer colas de prioridades ....................................................................201
Directivas de entrada ...................................................................................205
Asignación de tráfico en interfaces virtuales ................................................206
Asignación de tráfico a nivel de interfaz ................................................206
Asignación de tráfico a nivel de directiva...............................................208
Flujo de paquetes ..................................................................................208
Ejemplo: VPN basada en rutas con directiva de entrada ........................209
Ejemplo: VPN basada en directivas con directiva de entrada.................212
Asignación de tráfico utilizando la interfaz de bucle invertido......................216
Asignación y marcado de DSCP ...................................................................216
Capítulo 8 Parámetros del sistema 219

Compatibilidad con DNS (sistema de nombres de dominio) ........................219
Consulta DNS ........................................................................................220
Tabla de estado de DNS.........................................................................221
actualizaciones .........................................................................222
Establecimiento de un intervalo de actualización de DNS ...............222
Sistema de nombres de dominio dinámicos ..........................................223
Establecimiento de DDNS para un servidor DynDNS ......................223
Establecimiento de DDNS para un servidor DDO ............................224
División de direcciones DNS del proxy ..................................................225
Protocolo de configuración dinámica de host...............................................227
Configuración de un servidor DHCP ......................................................229
Personalización de las opciones de servidor DHCP .........................232
Colocación del servidor DHCP en un clúster de NSRP .....................234
Detección del servidor DHCP ..........................................................234
Habilitación de detección del servidor DHCP ..................................234
Desactivación de la detección del servidor DHCP............................235
Asignar un dispositivo de seguridad como agente de retransmisión de
DHCP ..............................................................................................235
Redireccionamiento de todos los paquetes DHCP ...........................239
Configuración de la IP del siguiente servidor...................................240
Utilización de un dispositivo de seguridad como cliente DHCP..............241
Propagación de ajustes TCP/IP...............................................................242
Configuración de DHCP en sistemas virtuales .......................................245
Establecimiento de la retransmisión de un mensaje DHCP en sistemas
virtuales.................................................................................................245
Protocolo punto a punto sobre Ethernet.......................................................246
Configuración de PPPoE ........................................................................246
Contenido vii
Configuración de PPPoE en las interfaces principal y de respaldo de la

zona Untrust ...................................................................................249
Configuración de múltiples sesiones PPPoE a través de una sola
interfaz ...........................................................................................250
PPPoE y alta disponibilidad ...................................................................253
Claves de licencia.........................................................................................253
Registro y activación de los servicios de suscripción ....................................254
Servicio de prueba.................................................................................255
Actualización de las claves de suscripción .............................................255
Adición de antivirus, filtrado de Web, antispam e inspección minuciosa
a un nuevo dispositivo o a uno existente.........................................256
Reloj del sistema ..........................................................................................256
Fecha y hora..........................................................................................257
Horario de verano .................................................................................257
Huso horario..........................................................................................257
Protocolo de hora de la red....................................................................258
Configuración de múltiples servidores NTP .....................................258
Configuración de un servidor NTP de respaldo................................258
Desfase temporal máximo ..............................................................259
Protocolos NTP y NSRP ...................................................................260
servidor NTP.............................................................................260
Seguridad de los servidores NTP .....................................................261
Índice ........................................................................................................................IX-I
viii Contenido
Acerca de este volumen
El Volumen 2: Fundamentos describe la arquitectura de ScreenOS y sus elementos e

incluye ejemplos de configuración de algunos de ellos. Este volumen contiene los
siguientes capítulos:
Capítulo 1, “Arquitectura de ScreenOS,” que describe los elementos

fundamentales de la arquitectura de ScreenOS y se incluye un ejemplo de
cuatro partes con el que se muestra una configuración empresarial que
incorpora la mayor parte de dichos elementos. En éste y en todos los siguientes
capítulos, cada concepto va acompañado de ejemplos ilustrativos.
Capítulo 2, “Zonas,” donde se explican las zonas de seguridad, de túneles y de

funciones.
Capítulo 3, “Interfaces,” que describe las diferentes interfaces físicas, lógicas y

virtuales.
Capítulo 4, “Modos de las interfaces,” donde se explican los conceptos

relacionados con los modos de funcionamiento de interfaz transparente, NAT
(Network Address Translation) y de rutas.
Capítulo 5, “Bloques para la construcción de directivas,” donde se explican los

elementos utilizados para crear directivas y redes privadas virtuales (“Virtual
Private Network” o VPN): direcciones (incluyendo direcciones VIP), servicios y
conjuntos de DIP.
Capítulo 6, “Directivas,” donde se examinan los componentes y las funciones

de las directivas y se ofrecen instrucciones para su creación y aplicación.
Capítulo 7, “Asignación de tráfico,” que explica la manera de dar prioridad a los

servicios y administrar el ancho de banda a nivel de interfaz y directivas.
Capítulo 8, “Parámetros del sistema,” donde se describen los conceptos

relacionados con el direccionamiento de sistemas de nombres de dominio
(“Domain Name System” o DNS), el uso del protocolo dinámico de
configuración de host (“Dynamic Host Configuration Protocol” o DHCP) para
asignar o retransmitir ajustes TCP/IP, la carga y descarga de las configuraciones
y el software del sistema y el ajuste del reloj del sistema.
ix

siguientes:
“Convenciones de la interfaz de usuario web” en esta página
“Convenciones de interfaz de línea de comandos” en la página x
“Convenciones de nomenclatura y conjuntos de caracteres” en la página xi
“Convenciones para las ilustraciones” en la página xii


de una dirección:
Address Name: dir_1

Zone: Untrust


En ejemplos:
x Convenciones del documento







Convenciones del documento xi



zona de seguridad

Internet

Interfaz de túnel
Servidor
Túnel VPN
Enrutador
Concentrador
xii Convenciones del documento




Asistencia y documentación técnica xiii

xiv Asistencia y documentación técnica

Capítulo 1
Arquitectura de ScreenOS
La arquitectura de ScreenOS de Juniper Networks le ofrece flexibilidad en el diseño

de la estructura de seguridad de la red. En los dispositivos de seguridad de
Juniper Networks con más de dos interfaces, es posible crear numerosas zonas de
seguridad y configurar directivas para regular el tráfico dentro de una misma zona
y entre zonas distintas. Usted puede enlazar una o más interfaces a cada zona
y permitir diferentes opciones de administración y de cortafuegos para cada una de
ellas. ScreenOS le permite crear el número de zonas que el entorno de su red
necesita, asignar el número de interfaces que cada zona necesita y diseñar cada
interfaz según sus necesidades específicas.
En este capítulo se proporciona una vista general de ScreenOS. Incluye las

siguientes secciones:
“Zonas de seguridad” en la página 2
“Interfaces de zonas de seguridad” en la página 3
“Enrutadores virtuales” en la página 4
“Directivas” en la página 5
“Redes privadas virtuales” en la página 7
“Sistemas virtuales” en la página 8
“Secuencia de flujo de paquetes” en la página 10
“Tramas jumbo” en la página 13
El capítulo concluye con un ejemplo en cuatro partes que ilustra la configuración

básica de un dispositivo de seguridad utilizando ScreenOS.
“Ejemplo: (Parte 1) Empresa con seis zonas” en la página 13
“Ejemplo: (Parte 2) Interfaces para las seis zonas” en la página 15
“Ejemplo: (Parte 3) Dos dominios de enrutamiento” en la página 18
“Ejemplo: (Parte 4) Directivas” en la página 19
1
Zonas de seguridad
Una zona de seguridad es un conjunto de uno o varios segmentos de red que
requieren que se controle el tráfico entrante y saliente por medio de directivas
(consulte “Directivas” en la página 5). Las zonas de seguridad son entidades lógicas
que tienen asociadas una o varias interfaces. Si dispone de distintos tipos de
dispositivos de seguridad de Juniper Networks, podrá definir múltiples zonas de
seguridad, la cantidad exacta de éstas dependerá de las necesidades de su red.
Además de las zonas definidas por el usuario, también puede utilizar las zonas
predefinidas: Trust, Untrust y DMZ (para el funcionamiento de la capa 3),
o V1-Trust, V1-Untrust y V1-DMZ (para el funcionamiento de la capa 2). Si lo desea,
puede seguir utilizando sólo las zonas predefinidas. También puede ignorar las
zonas predefinidas y utilizar exclusivamente las zonas definidas por el usuario.
También es posible utilizar los dos tipos de zonas (predefinidas y definidas por el
usuario) simultáneamente. Esta flexibilidad en la configuración de las zonas
permite diseñar la red que mejor responda a sus necesidades específicas. Consulte
la Figura 2.
NOTA: La única zona de seguridad que no necesita ningún segmento de red es la zona
global. (Para obtener más información, consulte “Zona Global” en la página 28).
Se considera que una zona sin interfaces asociadas y sin registros en la libreta de
direcciones no contiene segmentos de red.
Si actualiza una versión anterior de ScreenOS, todas las configuraciones para estas
zonas permanecerán intactas.
No es posible eliminar las zonas de seguridad predefinidas. Por el contrario, sí se

pueden eliminar las zonas definidas por el usuario. Cuando se elimina una zona
de seguridad, se eliminan automáticamente todas las direcciones configuradas
para esa zona.
La Figura 2 muestra una red configurada con cinco zonas de seguridad, tres zonas
predeterminadas (Trust, Untrust, DMZ) y dos zonas definidas por el usuario
(Finance, Ingeniería). El tráfico pasa de una zona de seguridad a otra únicamente si
lo permite una directiva.
Figura 2: Zonas de seguridad predefinidas
Finance
Untrust
Trust
Motor de Dispositivo
directivas de seguridad
Eng DMZ
2 Zonas de seguridad
Capítulo 1: Arquitectura de ScreenOS
Interfaces de zonas de seguridad

Cada interfaz de una zona de seguridad es como una puerta que el tráfico TCP/IP
debe cruzar para pasar de una zona a otra.
Mediante las directivas que usted defina, podrá permitir que el tráfico entre zonas
fluya en un solo sentido o en ambos. Al definir las rutas, estará especificando las
interfaces que el tráfico tendrá que utilizar para pasar de una zona a otra. Como es
posible asociar múltiples interfaces a una zona, las rutas diseñadas tienen una gran
importancia a la hora de dirigir el tráfico a las interfaces deseadas.
NOTA: Para intercambiar tráfico entre dos interfaces asociadas a una misma zona no se
requiere ninguna directiva, ya que ambas tendrán el mismo nivel de seguridad.
ScreenOS necesita directivas para controlar el tráfico entre zonas, no dentro de
ellas.
Para permitir que el tráfico fluya de una zona a otra, debe enlazar una interfaz a la
zona, en el caso de una interfaz en modo de ruta o en modo NAT (consulte “Modos
de las interfaces” en la página 79), asigne una dirección IP a la interfaz. Dos tipos
de interfaz comúnmente utilizados son las interfaces físicas y, en dispositivos que
admitan sistemas virtuales, las subinterfaces (es decir, la realización de una interfaz
física en la capa 2). Para obtener más información, consulte “Interfaces” en la
página 33.
Interfaces físicas
Una interfaz física se refiere a los componentes físicamente presentes en el
dispositivo de seguridad. Las convenciones de nomenclatura de interfaces difieren
de un dispositivo a otro.
NOTA: Para conocer la convención de nomenclatura de un dispositivo de seguridad

determinado, consulte la guía de configuración para ese dispositivo.
Subinterfaces
En los dispositivos que admiten redes LAN virtuales (VLAN), una interfaz física se
puede dividir lógicamente en varias subinterfaces virtuales, que ocupan el ancho de
banda que precisan en cada momento de la interfaz física de la que proceden. Una
subinterfaz es un elemento abstracto con funciones idénticas a las de una interfaz
física, de la que se diferencia por el etiquetado VLAN 802.1 Q. El dispositivo de
seguridad dirige el tráfico desde o hacia una zona con una subinterfaz a través de su
dirección IP y su etiqueta VLAN. Por razones prácticas, los administradores
normalmente utilizan el mismo número para la etiqueta VLAN y para la subinterfaz.
Por ejemplo, la interfaz ethernet1/2 con la etiqueta VLAN 3 se llamará ethernet1/2.3.
Así se identifica el módulo de interfaz que se encuentra en el primer bastidor, el
segundo puerto del módulo y la subinterfaz número 3 (ethernet1/2.3).
NOTA: 802.1Q es una norma IEEE que define los mecanismos para implementar redes
LAN virtuales enlazadas y los formatos de trama Ethernet utilizados para indicar la
pertenencia a una VLAN mediante etiquetas VLAN.
Interfaces de zonas de seguridad 3

Observe que aunque una subinterfaz comparte parte de su identidad con una
interfaz física, la zona a la que se asocia es independiente de la zona a la que se
asocia la interfaz física. Puede asociar la subinterfaz ethernet1/2.3 a una zona
distinta de la utilizada para la interfaz física ethernet1/2 o a la que desee asociar
ethernet1/2.2. Asimismo, no hay restricciones en cuanto a la asignación de
direcciones IP. El término subinterfaz no implica que su dirección se encuentre en
una subred dentro del espacio de direcciones de la interfaz física.
Enrutadores virtuales
Un enrutador virtual (VR) funciona como un enrutador. Dispone de sus propias
interfaces y de sus propias tablas de enrutamiento unicast y multicast. En
ScreenOS, un dispositivo de seguridad admite dos enrutadores virtuales
predefinidos. Esto permite al dispositivo de seguridad mantener dos tablas de
enrutamiento unicast y multicast independientes y ocultar la información de
enrutamiento de un enrutador al otro. Por ejemplo, untrust-vr se suele utilizar para
la comunicación con interlocutores sin confianza, por lo que no contiene
información de enrutamiento para las zonas protegidas. La información de
enrutamiento de las zonas protegidas se actualiza por medio de trust-vr. Por lo
tanto, no es posible recopilar información interna de la red mediante la extracción
no autorizada de información sobre las rutas, desde untrust-vr, consulte la Figura 3.
Figura 3: Zonas de seguridad del enrutador virtual
Dominio de enrutamiento Dominio de enrutamiento

trust-vr untrust-vr
Finance
Untrust
Trust
Eng DMZ Nota: El icono del castillo

representa una interfaz en una
zona de seguridad.
Reenvío de rutas
Cuando hay dos enrutadores virtuales en un dispositivo de seguridad, el tráfico no

se redirecciona automáticamente entre zonas que se encuentran en distintos VR,
incluso aunque existan directivas que permitan el tráfico. Si desea intercambiar
tráfico entre enrutadores virtuales, tendrá que exportar las rutas entre los VR
o configurar una ruta estática en un VR que defina el otro VR como el siguiente
salto ("next-hop"). Para obtener más información sobre el uso de enrutadores
virtuales, consulte el Volumen 7: Enrutamiento.
4 Enrutadores virtuales
Directivas
Los dispositivos de seguridad de Juniper Networks aseguran la red inspeccionando,
y luego permitiendo o denegando, todo intento de conexión que necesite pasar de
una zona de seguridad a otra.
De forma predeterminada, un dispositivo de seguridad denegará todo el tráfico en

todos los sentidos. La creación de directivas permite controlar el flujo de tráfico
entre zonas definiendo qué tipo de tráfico puede pasar de los orígenes a los
destinos especificados en determinado momento de acuerdo con una
programación. En el nivel más permisivo, es posible permitir que todo tipo de
tráfico pase de cualquier origen en una zona a cualquier destino en el resto de
zonas sin ninguna restricción en el tiempo. En el nivel más restrictivo, se puede
crear una directiva que sólo permita un tipo de tráfico entre un host determinado
en una zona y otro en otra zona durante un periodo de tiempo programado,
consulte la Figura 4.
NOTA: Algunos dispositivos de seguridad se suministran con una directiva

predeterminada que permite cualquier tráfico saliente de la zona Trust a la zona
Untrust, pero rechaza todo el tráfico entrante que procede de la zona Untrust
hacia la zona Trust.
Figura 4: Directivas predeterminadas

Acceso a Internet permisivo: cualquier servicio desde Acceso a Internet restrictivo: servicio SMTP desde un
cualquier punto de la zona Trust hacia cualquier servidor de correo en la zona Trust hacia un servidor de
punto de la zona Untrust en cualquier momento correo en la zona Untrust de 05:00 a 19:00 horas
Zona Zona
Untrust Untrust
Zona Zona
Trust Trust
Directivas 5
Cada vez que un paquete intenta pasar de una zona a otra o entre dos interfaces
enlazadas a la misma zona, el dispositivo de seguridad comprueba si en su lista de
directivas existe alguna que permita ese tipo de tráfico (consulte “Listas de
conjuntos de directivas” en la página 164). Para que el tráfico pueda pasar de una
zona de seguridad a otra (p. ej., de la zona A a la zona B), es necesario configurar
una directiva que permita que la zona A envíe tráfico a la zona B. Para que el tráfico
pueda pasar en sentido inverso, se debe configurar otra directiva que permita el
tráfico de la zona B a la zona A. Para que cualquier tipo de tráfico pase de una zona
a otra, debe haber una directiva que lo permita. Asimismo, cuando está habilitado
el bloqueo intrazonal (bloqueo del interior de una zona), deberá existir una directiva
que permita que el tráfico pase de una interfaz a otra dentro de esa misma zona.
Consulte la Figura 5 en la página 6.
Figura 5: Arquitectura de directivas

trust-vr untrust-vr
Finance
Untrust
Motor de
Trust directivas
DMZ
Eng Nota: El icono del castillo
representa una interfaz en una
zona de seguridad.
Reenvío de rutas
NOTA: Para obtener más información, consulte “Directivas” en la página 161.
Si configura el enrutamiento multicast en un dispositivo de seguridad, es posible

que tenga que configurar directivas multicast. De forma predeterminada, los
dispositivos de seguridad no permiten tráfico de control multicast entre zonas. Por
tráfico de control de multicast se entienden los mensajes transmitidos por
protocolos multicast, tales como el multicast independiente del protocolo (“Protocol
Independent Multicast” o PIM). Las directivas multicast solamente controlan el flujo
del tráfico de control multicast. Para permitir el tráfico de datos (tanto unicast como
multicast) entre zonas, debe configurar directivas de cortafuegos. (Para obtener más
información, consulte “Directivas multicast” en la página 7-163).
6 Directivas

ScreenOS dispone de varias opciones para la configuración de redes privadas
virtuales (VPN). Los dos tipos más importantes son:
VPN basada en rutas: mediante una consulta de rutas se determina qué tráfico
encapsulará el dispositivo de seguridad. Las directivas permiten o deniegan el
tráfico hacia el destino especificado en la ruta. Si la directiva permite el tráfico
y la ruta hace referencia a una interfaz de túnel asociada a un túnel VPN, el
dispositivo de seguridad también encapsulará dicho tráfico. Esta configuración
gestiona por separado la aplicación de directivas de la aplicación de túneles
VPN. Una vez configurados, estos túneles estarán disponibles como recursos
para asegurar el tráfico que circula entre una zona de seguridad y otra.
VPN basada en directivas: mediante una consulta de las directivas se

determina qué tráfico encapsulará el dispositivo de seguridad cuando la
directiva haga referencia a un túnel VPN determinado y se especifique “tunnel”
como la acción.
Una VPN basada en rutas es la opción adecuada para configuraciones VPN punto
a punto, ya que es posible aplicar múltiples directivas al tráfico que pasa a través de
un único túnel VPN. La VPN basada en directivas resulta adecuada para
configuraciones VPN de acceso telefónico, ya que el cliente de acceso telefónico
probablemente no dispone de una dirección IP interna hacia la que establecer una
ruta. Consulte la Figura 6.
En las siguientes instrucciones se muestran los principales pasos a seguir para

configurar una VPN basada en rutas:
1. Cuando configure el túnel VPN (p. ej., vpn-a-SF, donde SF es el destino

o entidad final), especifique una interfaz física o una subinterfaz en el
dispositivo local como interfaz de salida. (El interlocutor remoto deberá utilizar
la dirección IP de esta interfaz para configurar su puerta de enlace remota.)
2. Cree una interfaz de túnel (p. ej., tunnel.1) y asóciela a una zona de seguridad.
NOTA: No es necesario asociar la interfaz de túnel a la misma zona a la que está

destinado el tráfico de VPN. El tráfico hacia cualquier zona puede acceder a una
interfaz de túnel siempre que haya alguna ruta que apunte a esa interfaz.
3. Asocie la interfaz de túnel tunnel.1 al túnel VPN vpn-a-SF.
4. Para dirigir el tráfico a través de este túnel, configure una ruta indicando que el
tráfico hacia SF debe utilizar tunnel.1.
Figura 6: Tráfico VPN

Motor de Interfaz
Zona de origen directivas de túnel Zona de destino
Túnel VPN
Tabla de
enrutamiento
tunnel.1 vpn-a-SF
Paquete enviado Paquete entrando
Redes privadas virtuales 7

Llegados a este punto, el túnel está listo para el tráfico dirigido a SF. Ahora puede
crear registros en la libreta de direcciones, como “Trust LAN” (10.1.1.0/24) y “SF
LAN” (10.2.2.0/24), y configurar directivas para permitir o bloquear distintos tipos
de tráfico desde un origen determinado, como “Trust LAN”, y hacia un destino
determinado, como “SF LAN”. Consulte la Figura 7 en la página 8.
Figura 7: Tráfico VPN desde una zona de seguridad no fiable

El dispositivo de seguridad local enruta el tráfico desde la zona Trust a “SF LAN”, que se
encuentra en la zona Untrust, a través de la interfaz tunnel.1. Como la interfaz tunnel.1 está
enlazada al túnel VPN “vpn-a-SF”, el dispositivo encripta el tráfico y lo envía a través de ese túnel
al interlocutor remoto.
Dominio de enrutamiento untrust-vr

SF LAN
Zona Untrust 10.2.2.0/24
Para llegar, utilice Interfaz de salida
1.1.1.0/24 eth1/2 eth1/2, 1.1.1.1/24
10.2.2.0/24 tunnel.1
0.0.0.0/0 1.1.1.250
Interfaz
tunnel.1
Dispositivo local Puerta de enlace Túnel VPN

predeterminada: vpn-a-SF
1.1.1.250
Dominio de
enrutamiento trust-vr
Zona Trust
eth3/2–10.1.1.1/24
Para llegar, utilice
10.1.1.0/24 eth3/2
0.0.0.0/0 untrust-vr
NOTA: Para obtener información detallada sobre las VPN, consulte el Volumen 5:
Redes privadas virtuales.
Sistemas virtuales
Algunos dispositivos de seguridad de Juniper Networks admiten sistemas virtuales
(vsys). Un sistema virtual es una subdivisión del sistema principal que para el
usuario aparece como una entidad independiente. Los sistemas virtuales se
encuentran separados del sistema raíz y entre sí dentro de un mismo dispositivo de
seguridad. La aplicación de ScreenOS a los sistemas virtuales implica la
coordinación de tres componentes principales: zonas, interfaces y enrutadores
virtuales. La Figura 8 presenta de forma conceptual cómo ScreenOS integra estos
componentes tanto a nivel de raíz como a nivel de sistema virtual.
8 Sistemas virtuales
Figura 8: Arquitectura Vsys
Nota: El icono del castillo

representa una interfaz de una
zona de seguridad. trust-vr
untrust-vr Finance
DMZ
Mail Trust Eng
Interfaz compartida
por vsys1 y raíz
sistema raíz vsys1-vr
Untrust
Trust-vsys1
Subinterfaz vsys1
dedicada para
vsys2 vsys2-vr
vsys2
Trust-vsys2
vsys3
interfaz física
dedicada para vsys3 vsys3-vr
Trust-vsys3
NOTA: Para obtener más información sobre sistemas virtuales y la aplicación de zonas,
interfaces y enrutadores virtuales en el contexto de sistemas virtuales, consulte el
Volumen 10: Sistemas virtuales.
Sistemas virtuales 9
Secuencia de flujo de paquetes

En ScreenOS, la secuencia de flujo de un paquete entrante ocurre según se muestra
a continuación en la Figura 9.
Figura 9: Secuencia de flujo de paquetes a través de las zonas de seguridad
Paquete
entrante
Filtro Consulta MIP/VIP Consulta Consulta de NAT-Dst y Crear Realizar
SCREEN de sesiones Host IP de rutas directivas NAT-Src sesión operación
Interfaz Si el paquete no coincide PBR Lista de directivas

Tabla de sesiones
entrante con una sesión existente,
lleve a cabo los pasos 4 a 9. src dst service action d 977 vsys id 0, flag
000040/00,
Tabla de reenvíos pid -1, did 0, time 180
Zona 13 (01) 10.10.10.1/1168 ->
10.10.10.0/24 eth1/1
origen 0.0.0.0/0 untrust-vr 211.68.1.2/80, 6,
Si es así, vaya directamente 002be0c0066b,
al paso 9. Permit = reenviar paquete subif 0, tun 0
Deny = descartar paquete
Interfaz de destino Reject = descartar paquete
Zonas de y Zona de destino y enviar TCP RST al origen
Si hay tráfico de red, seguridad Tunnel = utilizar el túnel
zona de origen = zona especificado para encriptación
de VPN
de seguridad a la que
está asociada la
interfaz o subinterfaz.
Si zona de destino = zona de
Si hay tráfico VPN
a la interfaz de seguridad, utilizar esa zona para la
túnel asociada al consulta de directivas.
túnel VPN, zona de
origen = zona de
seguridad donde
está configurado el
túnel. Si zona de destino = zona del túnel,
Si hay tráfico VPN a la utilizar su zona de origen para la
interfaz de túnel en consulta de directivas.
una zona de túnel, Zona
zona de origen = zona de túnel
portadora.
1. El módulo de interfaz identifica la interfaz entrante y, por lo tanto, la zona de
origen a la que está asociada.
El módulo de interfaz utiliza el siguiente criterio para determinar la zona de

origen:
Si el paquete no está encapsulado, la zona de origen es la zona de

seguridad a la que la interfaz o subinterfaz entrante está asociada.
Si el paquete está encapsulado y la interfaz de túnel está asociada a un

túnel VPN, la zona de origen es la zona de seguridad en la que está
configurada la interfaz de túnel.
Si el paquete está encapsulado y la interfaz de túnel se encuentra en una

zona de túnel, la zona de origen es la zona portadora (zona de seguridad
que porta el túnel) correspondiente a esa zona de túnel.
10 Secuencia de flujo de paquetes

2. Si ha habilitado las opciones SCREEN para la zona de origen, el dispositivo de

seguridad activa el módulo SCREEN en este momento. La comprobación de
SCREEN puede producir uno de los tres resultados siguientes:
Si un mecanismo SCREEN detecta un comportamiento anómalo y está

configurado para bloquear el paquete correspondiente, el dispositivo de
seguridad descarta el paquete y genera una entrada en el registro de
eventos.

configurado para registrar el evento pero no bloquear el paquete, el
dispositivo de seguridad registra el evento en la lista de contadores SCREEN
para la interfaz de entrada y procede al paso siguiente.
Si el mecanismo SCREEN no detecta ningún comportamiento anómalo,

el dispositivo de seguridad procede al paso siguiente.
3. El módulo de sesiones realiza una consulta de sesiones para comprobar si el

paquete coincide con una sesión existente.
Si el paquete no coincide con ninguna sesión existente, el dispositivo de

seguridad ejecuta el procesamiento de primer paquete, un procedimiento
que implica los pasos del 4 al 9.
Si el paquete coincide con una sesión existente, el dispositivo de seguridad

ejecuta el procesamiento rápido utilizando la información disponible en la
entrada de sesiones existente para procesar el paquete. El procesamiento
rápido (“Fast Processing”) omite los pasos 4 a 8 porque la información que
generan ya se obtuvo durante el procesamiento del primer paquete de la
sesión.
4. Si se utiliza una dirección IP asignada (MIP) o dirección IP virtual (VIP), el

módulo de asignación de direcciones resuelve la dirección MIP o VIP de modo
que la tabla de enrutamiento pueda buscar la dirección real del host.
5. ScreenOS comprueba si aplica al paquete un enrutamiento según directivas

(PBR), antes de efectuar una consulta de rutas. Si PBR está habilitado en esa
interfaz de entrada, las siguientes acciones se aplican al paquete:
La directiva PBR enlazada a esa interfaz de entrada se aplica al paquete.
Si no existe una directiva PBR al nivel de la interfaz, se aplica al paquete la

directiva PBR enlazada a la zona asociada con la interfaz de entrada.
Si no existe una directiva PBR al nivel de la zona, se aplica al paquete la

directiva PBR enlazada al VR asociado con la interfaz de entrada.
NOTA: Para obtener más información acerca de PBR, consulte el Volumen 7:

Enrutamiento.
Si PBR no está habilitado, la operación de consulta en la tabla de rutas

determina cuál interfaz conduce a la dirección de destino. De esta forma, el
módulo de interfaz identifica la zona de destino a la que está asociada esa
interfaz.
Secuencia de flujo de paquetes 11

El módulo de interfaz utiliza el siguiente criterio para determinar la zona de destino:
Si la zona de destino es una zona de seguridad, esa zona se utiliza para la

consulta de directivas.
Si la zona de destino es una zona de túnel, se utiliza la zona portadora

correspondiente para la consulta de directivas.
Si la zona de destino es igual a la zona de origen y el bloqueo dentro de una

zona está desactivado para esa zona, el dispositivo de seguridad omite los
pasos 6 y 7 y crea una sesión (paso 8). Si el bloqueo dentro de una zona
está activado, el dispositivo de seguridad descarta el paquete.
6. El motor de directivas busca en las listas de conjuntos de directivas una

directiva entre las direcciones de las zonas de origen y de destino identificadas.
La acción configurada en la directiva determina la forma en que el dispositivo

de seguridad maneja el paquete:
Si la acción es permit, el dispositivo de seguridad redireccionará el paquete

a su destino.
Si la acción es deny, el dispositivo de seguridad descartará el paquete.
Si la acción es reject, el dispositivo de seguridad descartará el paquete y,

si el protocolo es TCP, enviará una señal de restablecimiento (RST) a la
dirección IP de origen.
Si la acción es tunnel, el dispositivo de seguridad redireccionará el paquete

al módulo VPN, que encapsula el paquete y lo transmite utilizando los
ajustes especificados del túnel VPN.
7. Si en la directiva está especificado que se traduzcan las direcciones de destino

(NAT-dst), el módulo NAT traduce la dirección de destino original del
encabezado del paquete IP a otra dirección.
Si está especificada la traducción de direcciones de origen (NAT basada en

interfaz o NAT-src basada en directivas), el módulo NAT traduce la dirección de
origen del encabezado del paquete IP antes de reenviarlo a su destino o al
módulo VPN.
(Si en la misma directiva están especificados tanto NAT-dst como NAT-src,

el dispositivo de seguridad realiza primero NAT-dst y luego NAT-src).
8. El módulo de sesiones crea una nueva entrada en la tabla de sesiones que

contiene los resultados de los pasos 1 a 7.
Al procesar los paquetes subsiguientes de la misma sesión, el dispositivo de

seguridad utiliza la información contenida en la entrada de la sesión.
9. El dispositivo de seguridad realiza la operación especificada en la sesión.
Algunas operaciones típicas son la traducción de direcciones de origen,

la selección y encriptación del túnel VPN, la desencriptación y el reenvío
de paquetes.
12 Secuencia de flujo de paquetes

Tramas jumbo
En algunos es posible aumentar el rendimiento aumentando el tamaño máximo de
paquete o la unidad de transmisión del mensaje (MTU), que el dispositivo puede
procesar. Consulte el manual del hardware para verificar si su dispositivo es
compatible con las tramas jumbo.
Los rangos de tamaño de trama van desde 1514 hasta 9830 bytes. Para colocar el
dispositivo en modo de trama jumbo, ajuste el tamaño máximo de la trama a un
valor desde 1515 hasta 9830 inclusive, por ejemplo: set envar
max-frame-size=9830. Utilice el comando unset envar max-frame-size para que
el dispositivo recupere un tamaño normal máximo de trama, que es de 1.514 bytes
(si lo prefiere, puede utilizar el comando: set envar max-frame-size=1514). El
tamaño máximo de trama no incluye la secuencia de verificación de trama de
4 bytes al final de la trama. Debe reiniciar el sistema para que los cambios a las
variables de entorno tengan vigencia.
En el modo de trama jumbo, sucede lo siguiente:
No es compatible con Deep inspection (DI).
Los paquetes enviados a través de interfaces agregadas pueden salir

desordenados.
No es compatible el reenvío de NSRP.
El rendimiento máximo del cortafuegos o VPN requiere por lo menos de cuatro

sesiones (para cortafuegos) o túneles (para VPN)
Ejemplo de arquitectura de ScreenOS

Las siguientes secciones abarcan un ejemplo de cuatro partes que muestran
algunos de los conceptos que se abarcan en las secciones anteriores:
“Ejemplo: (Parte 1) Empresa con seis zonas”
“Ejemplo: (Parte 2) Interfaces para las seis zonas” en la página 15
“Ejemplo: (Parte 3) Dos dominios de enrutamiento” en la página 18
“Ejemplo: (Parte 4) Directivas” en la página 19
Ejemplo: (Parte 1) Empresa con seis zonas

Ésta es la primera de las cuatro partes de un ejemplo cuya finalidad es aclarar
algunos de los conceptos expuestos en las secciones anteriores. Para la segunda
parte, en la que las interfaces de cada zona están ya establecidas, consulte
“Ejemplo: (Parte 2) Interfaces para las seis zonas” en la página 15. Aquí se
configuran las seis zonas siguientes de una empresa:
Finance
Trust
Tramas jumbo 13
Eng
Mail
Untrust
DMZ
Las zonas Trust, Untrust y DMZ están configuradas previamente. Usted definirá las
zonas Finance, Eng y Mail. De forma predeterminada, las zonas definidas por el
usuario se ubican en el dominio de enrutamiento trust-vr. Por lo tanto, no es
necesario especificar un enrutador virtual para las zonas Finance y Eng. Sin
embargo, además de configurar la zona Mail, también deberá especificar que se
encuentre en el dominio de enrutamiento untrust-vr. Asimismo debe transferir los
enlaces de los enrutadores virtuales de las zonas DMZ y Untrust de trust-vr a
untrust-vr, consulte la Figura 10 en la página 14.
NOTA: Para obtener más información sobre enrutadores virtuales y sus dominios de
enrutamiento, consulte el Volumen 7: Enrutamiento.
Figura 10: Enlaces de enrutador de zona a virtual

trust-vr untrust-vr
Finance Mail
Trust Untrust
Eng DMZ
WebUI
Network > Zones > New: Introduzca los siguientes datos y haga clic en OK:
Zone Name: Finance

Virtual Router Name: trust-vr
Zone Type: Layer 3: (seleccione)
Zone Name: Eng

14 Ejemplo de arquitectura de ScreenOS

Zone Name: Mail

Virtual Router Name: untrust-vr
Network > Zones > Edit (para Untrust): Seleccione untrust-vr en la lista
desplegable Virtual Router Name, luego haga clic en OK.
Network > Zones > Edit (para DMZ): Seleccione untrust-vr en la lista
CLI
set zone name finance
set zone name eng
set zone name mail
set zone mail vrouter untrust-vr
set zone untrust vrouter untrust-vr
set zone dmz vrouter untrust-vr
save
Ejemplo: (Parte 2) Interfaces para las seis zonas

Ésta es la segunda parte de un ejemplo fragmentado. Si desea ver la primera parte,
en la que se configuran las zonas, consulte “Ejemplo: (Parte 1) Empresa con seis
zonas” en la página 13. Si desea ver la siguiente parte, en la que se configuran
enrutadores virtuales, consulte “Ejemplo: (Parte 3) Dos dominios de enrutamiento”
en la página 18. Esta parte del ejemplo demuestra cómo asociar interfaces a las
zonas y configurarlas con una dirección IP y diversas opciones de administración,
consulte la Figura 11.
Figura 11: Enlaces de interfaz a zona

1.3.3.1/24
eth1/1
Finance
10.1.2.1/24
Etiqueta VLAN 1 Mail
eth3/2.1 1.4.4.1/24
Etiqueta VLAN 2
eth1/1.2
Trust Untrust
10.1.1.1/24 1.1.1.1/24
eth3/2 eth1/2
Eng
10.1.3.1/24 DMZ
eth3/1 1.2.2.1/24
eth2/2
Ejemplo de arquitectura de ScreenOS 15

WebUI
1. Interfaz ethernet3/2
Network > Interfaces > Edit (para ethernet3/2): Introduzca los siguientes
Zone Name: Trust

Static IP: (seleccione esta opción si es posible)
IP Address/Netmask: 10.1.1.1/24
Manageable: (seleccione)
Management Services: WebUI, Telnet, SNMP, SSH (seleccione)
Other Services: Ping (seleccione)
2. Interfaz ethernet3/2.1
Network > Interfaces > Sub-IF New: Introduzca los siguientes datos y haga clic
en OK:
Interface Name: ethernet3/2.1

Zone Name: Finance
VLAN Tag: 1
Zone Name: Eng

Zone Name: Mail

Network > Interfaces > Sub-IF New: Introduzca los siguientes datos y haga clic
en OK:

Zone Name: Mail
VLAN Tag: 2

Zone Name: Untrust

Manageable: (seleccione)
Management Services: SNMP (seleccione)
Zone Name: DMZ

Static IP: (seleccione)
CLI
set interface ethernet3/2 zone trust
set interface ethernet3/2 ip 10.1.1.1/24
set interface ethernet3/2 manage ping
set interface ethernet3/2 manage webui
set interface ethernet3/2 manage telnet
set interface ethernet3/2 manage snmp
set interface ethernet3/2 manage ssh
set interface ethernet3/2.1 tag 1 zone finance
set interface ethernet3/2.1 ip 10.1.2.1/24
set interface ethernet3/2.1 manage ping
set interface ethernet3/1 zone eng
set interface ethernet3/1 manage ping
set interface ethernet1/1 zone mail
set interface ethernet1/1.2 tag 2 zone mail
set interface ethernet1/1.2 ip 1.4.4.1 /24
set interface ethernet1/2 zone untrust
set interface ethernet1/2 manage snmp
set interface ethernet2/2 zone dmz
save

Ejemplo: (Parte 3) Dos dominios de enrutamiento

Ésta es la tercera parte de un ejemplo fragmentado. Si desea ver la parte anterior,
en la que se definen las interfaces para las diferentes zonas de seguridad, consulte
“Ejemplo: (Parte 2) Interfaces para las seis zonas” en la página 15. Si desea ver la
parte siguiente, en la que se establecen las directivas, consulte el “Ejemplo: (Parte 4)
Directivas” en la página 19. En este ejemplo solamente se configura una ruta para
la puerta de enlace predeterminada a Internet. Las otras rutas son creadas
automáticamente por el dispositivo de seguridad al generar las direcciones IP de las
interfaces, consulte la Figura 12 en la página 18.
Figura 12: Dominios de enrutamiento
trust-vr untrust-vr
Finance
10.1.2.1/24 1.3.3.1/24
Etiqueta VLAN 1 eth1/1, ruta Mail
eth3/2.1, NAT
1.4.4.1/24
Etiqueta VLAN 2
eth1/1.2, ruta
Trust Untrust
10.1.1.1/24 1.1.1.1/24
eth3/2, NAT eth1/2, ruta
Eng DMZ
10.1.3.1/24 1.2.2.1/24
eth3/1, NAT eth2/2, ruta
Reenvío de rutas
WebUI
Network > Routing > Destination > (select trust-vr) New: Introduzca los
siguientes datos y haga clic en OK:
Network Address/Netmask: 0.0.0.0/0

Next Hop Virtual Router Name: (seleccione); untrust-vr
Network > Routing > Destination > (select untrust-vr) New: Introduzca los

Gateway: (seleccione)
Interface: ethernet1/2
Gateway IP Address: 1.1.1.254
CLI
set vrouter trust-vr route 0.0.0.0/0 vrouter untrust-vr
set vrouter untrust-vr route 0.0.0.0/0 interface eth1/2 gateway 1.1.1.254
save

El dispositivo de seguridad crea automáticamente las rutas que se muestran en la

Tabla 1 y en la Tabla 2 (excepto en los casos indicados).
Tabla 1: Tabla de rutas para trust-vr
Utilizar puerta de
Para llegar a: Utilizar interfaz: enlace/Vrouter: Creada por:
0.0.0.0/0 n/a untrust-vr Configurado por el usuario
10.1.3.0/24 eth3/1 0.0.0.0 Dispositivo de seguridad
10.1.2.0/24 eth3/2.1 0.0.0.0 Dispositivo de seguridad
Tabla 2: Tabla de rutas para untrust-vr
Utilizar puerta de
Para llegar a: Utilizar interfaz: enlace/Vrouter: Creada por:
1.4.4.0/24 eth1/1.2 0.0.0.0 Dispositivo de seguridad
0.0.0.0/0 eth1/2 1.1.1.254 Configurado por el usuario
Ejemplo: (Parte 4) Directivas

Ésta es la última parte de un ejemplo fragmentado. La parte anterior es “Ejemplo:
(Parte 3) Dos dominios de enrutamiento” en la página 18. En esta parte del ejemplo
se muestra cómo configurar nuevas directivas. Consulte la Figura 13.
Figura 13: Directivas
dominio de enrutamiento dominio de enrutamiento

trust-vr trust-vr
Finance
Mail
Motor de
Trust directivas Untrust
Eng
DMZ
Reenvío de rutas

Para que este ejemplo funcione, antes de comenzar a configurar nuevas directivas
es necesario crear nuevos grupos de servicios.
NOTA: Cuando crea una zona, el dispositivo de seguridad crea automáticamente la

dirección Any para todos los hosts existentes en esa zona. Este ejemplo utiliza la
dirección Any para los hosts.
WebUI
1. Grupos de servicios
Policy > Policy Elements > Services > Groups > New: Introduzca los
Group Name: Mail-Pop3
Seleccione Mail y utilice el botón << para mover ese servicio desde la
columna “Available Members” hacia la columna “Group Members”.
Seleccione Pop3 y utilice el botón << para mover ese servicio desde la
Group Name: HTTP-FTPGet
Seleccione HTTP y utilice el botón << para mover ese servicio desde la
Seleccione FTP-Get y utilice el botón << para mover ese servicio desde la
2. Directivas
Policy > Policies > (From: Finance, To: Mail} New: Introduzca los siguientes
Source Address:
Address Book Entry: (seleccione), Any
Destination Address:
Service: Mail-Pop3
Action: Permit
Policy > Policies > (From: Trust, To: Mail} New: Introduzca los siguientes datos
y haga clic en OK:
Source Address:
Service: Mail-Pop3
Action: Permit

Policy > Policies > (From: Eng, To: Mail} New: Introduzca los siguientes datos
y haga clic en OK:
Source Address:
Service: Mail-Pop3
Action: Permit
Policy > Policies > (From: Untrust, To: Mail} New: Introduzca los siguientes
Source Address:
Service: Mail
Action: Permit
Policy > Policies > (From: Finance, To: Untrust} New: Introduzca los
Source Address:
Service: HTTP-FTPGet
Action: Permit
Policy > Policies > (From: Finance, To: DMZ} New: Introduzca los siguientes
Source Address:
Action: Permit
Policy > Policies > (From: Trust, To: Untrust} New: Introduzca los siguientes
Source Address:
Action: Permit

Policy > Policies > (From: Trust, To: DMZ} New: Introduzca los siguientes
Source Address:
Action: Permit
Policy > Policies > (From: Eng, To: DMZ} New: Introduzca los siguientes datos
y haga clic en OK:
Source Address:
Action: Permit
Policy > Policies > (From: Eng, To: DMZ} New: Introduzca los siguientes datos
y haga clic en OK:
Source Address:
Service: FTP-Put
Action: Permit
Policy > Policies > (From: Untrust, To: DMZ} New: Introduzca los siguientes
Source Address:
Action: Permit
CLI
set group service mail-pop3 add mail
set group service mail-pop3 add pop3
set group service http-ftpget add http
set group service http-ftpget add ftp-get

2. Directivas
set policy from finance to mail any any mail-pop3 permit
set policy from trust to mail any any mail-pop3 permit
set policy from eng to mail any any mail-pop3 permit
set policy from untrust to mail any any mail permit
set policy from finance to untrust any any http-ftpget permit
set policy from finance to dmz any any http-ftpget permit
set policy from trust to untrust any any http-ftpget permit
set policy from trust to dmz any any http-ftpget permit
set policy from eng to untrust any any http-ftpget permit
set policy from eng to dmz any any http-ftpget permit
set policy from eng to dmz any any ftp-put permit
set policy from untrust to dmz any any http-ftpget permit
save


Capítulo 2
Zonas
Una zona puede ser un segmento del espacio de red al que se aplican medidas de
seguridad (zona de seguridad), un segmento lógico que tiene asociada una interfaz
de túnel VPN (zona de túnel) o una entidad física o lógica que realiza una función
específica (zona de función).
Este capítulo examina cada uno de los tipos de zonas con un especial énfasis en la
zona de seguridad. Incluye las siguientes secciones:
“Ver las zonas preconfiguradas” en la página 26
“Zonas de seguridad” en la página 27
“Asociar una interfaz de túnel a una zona de túnel” en la página 28
“Configuración de zonas de seguridad y zonas de túnel” en la página 30
“Zonas de función” en la página 32
25
Ver las zonas preconfiguradas

La primera vez que se inicia un dispositivo de seguridad puede verse una serie de
zonas preconfiguradas. Para visualizar estas zonas utilizando la WebUI, haga clic en
Network > Zones en la columna de menú de la izquierda, consulte la Figura 14.
Para visualizar estas zonas con la CLI, utilice el comando get zone. Consulte la
Figura 15 en la página 27.
Figura 14: Página Network > Zones en la WebUI
26 Ver las zonas preconfiguradas

Capítulo 2: Zonas
La Figura 15 muestra el resultado del comando CLI get zone.
Figura 15: Resultado de Get Zone
device> get zone
Total de 13 zonas en vsys raíz

Los sistemas raíz y virtual comparten estas zonas.
ID Name) Type) Attr) VR) Default-IF) VSYS) Estas zonas (ID 0 y 10) no tienen ni
0) Null) Null) Shared) untrust-vr) null) Root) pueden tener una interfaz.
1) Untrust) Sec(L3)) Shared) trust-vr) ethernet1/2) Root)
2) Trust) Sec(L3)) ) trust-vr) ethernet3/2) Root)
3) DMZ) Sec(L3)) ) trust-vr) ethernet2/2) Root) Estas zonas (ID 1-3 y 11-14) proporcionan
4) Self) Func) ) trust-vr) self) Root) compatibilidad con versiones anteriores al actualizar
5) MGT) Func) ) trust-vr) mgt) Root) de una versión anterior a ScreenOS 3.1.0; las 3
6) HA) Func) ) trust-vr) ha) Root) superiores para dispositivos en modo NAT o de
10) Global) Sec(L3)) ) trust-vr) null) Root) rutas, las 3 inferiores para dispositivos en modo
11) V1-Untrust) Sec(L2))) trust-vr) v1-untrust) Root) transparente.
12) V1-Trust) Sec(L2)) ) trust-vr) v1-trust) Root)
13) V1-DMZ) Sec(L2)) ) trust-vr) v1-dmz) Root)
14) VLAN) Func) ) trust-vr vlan) Root)
16) Untrust-Tun) Tun)) trust-vr) null) Root)
-----------------------------------------------------------------------
De forma predeterminada, las interfaces de túnel VPN están asociadas a la zona Untrust-Tun,
cuya zona portadora es la zona Untrust. (Durante la actualización, los túneles existentes se
Los números de zona 7 a 9 y 15 están reservados para asocian a la zona Untrust-Tun).
uso futuro.
Las zonas preconfiguradas mostradas en la Figura 14 y en la Figura 15 se pueden

agrupar en tres tipos de zonas diferentes:
Seguridad: Untrust, Trust, DMZ, Global, V1-Untrust, V1-Trust, V1-DMZ
Túnel: Untrust-Tun
Función: Null, Self, MGT, HA, VLAN
Zonas de seguridad
En un solo dispositivo de seguridad puede configurar varias zonas de seguridad
dividiendo la red en segmentos a los que puede aplicar diversas opciones de
seguridad para satisfacer las necesidades de cada segmento. Deben definirse como
mínimo dos zonas de seguridad, básicamente para proteger un área de la red de la
otra. En algunas plataformas de seguridad puede definir muchas zonas de
seguridad, lo que refina aún más la granularidad del diseño de seguridad de la red,
y sin implementar múltiples dispositivos de seguridad para ello.
Zonas de seguridad 27
Zona Global
Puede identificar una zona de seguridad porque tiene una libreta de direcciones
y se puede hacer referencia a ella en directivas. La zona Global satisface estos
criterios. Sin embargo, le falta un elemento del que sí disponen las demás zonas de
seguridad: una interfaz. La zona Global sirve como área de almacenamiento de
direcciones IP asignadas (MIP) y direcciones IP virtuales (VIP). La dirección
predefinida “Any” de la zona Global puede aplicarse a todas las MIPs, VIPs y a otras
direcciones definidas por el usuario establecidas en la zona Global. Dado que el
tráfico dirigido a estas direcciones se asigna a otras direcciones, la zona Global no
requiere una interfaz para que el tráfico fluya a través de ella.
La zona Global también contiene direcciones para su utilización en directivas

globales. Para obtener más información acerca de directivas globales, consulte
“Directivas globales” en la página 164).
NOTA: Cualquier directiva que utilice la zona Global como su destino no puede admitir
NAT ni asignación de tráfico.
Opciones SCREEN
Un cortafuegos Juniper Networks asegura una red inspeccionando, y luego
permitiendo o denegando, todos los intentos de conexión que necesiten pasar de
una zona de seguridad a otra. Por cada zona de seguridad, y la zona MGT, puede
habilitar un conjunto de opciones SCREEN predefinidas que detecten y bloqueen
diversos tipos de tráfico que el dispositivo de seguridad identifica como
potencialmente dañinos.
Para obtener más información sobre las opciones SCREEN disponibles, consulte el
Volumen 4: Detección ataques y mecanismos de defensa.
Asociar una interfaz de túnel a una zona de túnel

Una zona de túnel es un segmento lógico que contiene al menos una interfaz de
túnel. Las zonas de túnel están conceptualmente relacionadas con zonas de
seguridad en una relación “padre-hijo”. La zona de seguridad que actúa como
“padre”, que también puede imaginarse como una zona portadora, proporciona la
protección de cortafuegos al tráfico encapsulado. La zona de túnel proporciona el
encapsulado y desencapsulado de paquetes, y también puede proporcionar
servicios NAT basados en directivas, ya que admite interfaces de túnel con
direcciones IP y máscaras de red que pueden contener direcciones IP asignadas
(MIP) y dinámicas (DIP).
El dispositivo de seguridad utiliza la información de enrutamiento de la zona

portadora para dirigir el tráfico al punto final del túnel. La zona de túnel
predeterminada es Untrust-Tun, asociada a la zona Untrust. Puede crear otras zonas
de túnel y asociarlas a otras zonas de seguridad, con un máximo de una zona de
túnel por zona portadora y por sistema virtual.
NOTA: El sistema raíz y todos los sistemas virtuales pueden compartir la zona Untrust.
Sin embargo, cada sistema tiene su propia zona Untrust-Tun separada.
28 Asociar una interfaz de túnel a una zona de túnel

Capítulo 2: Zonas
De forma predeterminada, una zona de túnel se encuentra en el dominio de

enrutamiento trust-vr, pero también puede mover una zona de túnel a otro dominio
de enrutamiento. Consulte la Figura 16.
Figura 16: Dominio de enrutamiento de la zona de túnel
La interfaz de la zona de seguridad que

Zona de seguridad contiene la zona de túnel proporciona la
protección de cortafuegos para el tráfico
encapsulado.
Zona de túnel
Tráfico hacia o desde un túnel VPN Túnel VPN
Interfaz
de túnel Interfaz de la zona
La interfaz de túnel, que cuando está de seguridad
asociada a una zona de túnel debe
tener una dirección IP/máscara de red,
admite NAT basada en directivas para
el tráfico VPN pre-encapsulado y
post-desencapsulado.
El tráfico saliente entra en la zona de túnel a través de la interfaz de túnel, es encapsulado y sale a través de la interfaz de la zona de seguridad.
El tráfico entrante accede a través de la interfaz de la zona de seguridad, es desencapsulado en la zona de túnel, y sale a través de la interfaz de túnel.
Al actualizar una versión de ScreenOS anterior a 3.1.0, las interfaces de túnel

existentes se asocian de forma predeterminada a la zona de túnel preconfigurada
Untrust-Tun, que es un “hijo” de la zona de seguridad preconfigurada de Untrust.
Puede asociar múltiples zonas de túnel a la misma zona de seguridad; sin embargo,
no puede enlazar una zona de túnel a otra zona de túnel.
En este ejemplo creará una interfaz de túnel y la llamará tunnel.3. La asociará a la

zona Untrust-Tun y le asignará la dirección IP 3.3.3.3/24. Seguidamente definirá
una dirección IP asignada (MIP) en tunnel.3, traduciendo 3.3.3.5 a 10.1.1.5, que es
la dirección de un servidor en la zona Trust. Tanto la zona Untrust, que es la zona
portadora de la zona Untrust-Tun, como la zona Trust están en el dominio de
enrutamiento trust-vr.
WebUI
1. Interfaz de túnel
Network > Interfaces > New Tunnel IF: Introduzca los siguientes datos y haga
clic en OK:
Tunnel Interface Name: tunnel.3

Zone (VR): Untrust-Tun (trust-vr)
Fixed IP: (seleccione)
2. MIP
Network > Interfaces > Edit (para tunnel.3) > MIP > New: Introduzca los
Mapped IP: 3.3.3.5

Host IP Address: 10.1.1.5
Netmask: 255.255.255.255
Host Virtual Router Name: trust-vr
Asociar una interfaz de túnel a una zona de túnel 29

CLI
1. Interfaz de túnel
set interface tunnel.3 zone Untrust-Tun
set interface tunnel.3 ip 3.3.3.3/24
2. MIP
set interface tunnel.3 mip 3.3.3.5 host 10.1.1.5
save
Configuración de zonas de seguridad y zonas de túnel

Para que el funcionamiento sea óptimo, debe guardar siempre sus cambios
y reiniciar después de crear una zona. Los procesos para crear, modificar y eliminar
zonas de seguridad de capa 3 o capa 2 y zonas de túnel son bastante similares.
NOTA: No se pueden eliminar zonas de seguridad predefinidas ni la zona de túnel

predefinida, aunque sí se pueden editar.
Creación de una zona

Para crear una zona de seguridad de capa 3 (Layer 3) o capa 2 (Layer 2) o crear una
zona de túnel utilice la WebUI o la CLI.
WebUI
Zone Name: Escriba un nombre para la zona.
Virtual Router Name: Seleccione el enrutador virtual en cuyo dominio de

enrutamiento desea ubicar la zona.
Zone Type:
Seleccione Layer 3 para crear una zona a la que podrá asociar

interfaces en el modo NAT o de rutas.
Seleccione Layer 2 para crear una zona a la que pueda asociar

interfaces en modo transparente.
Seleccione Tunnel Out Zone cuando cree una zona de túnel y la asocie
a una zona portadora, luego seleccione una zona portadora específica
en la lista desplegable.
Block Intra-Zone Traffic: Seleccione esta opción para bloquear el tráfico

entre hosts dentro de la misma zona de seguridad. De forma
predeterminada, los bloqueos intrazonales están inhabilitados.
NOTA: El nombre de una zona de seguridad de capa 2 (Layer 2) debe comenzar con
“L2-”; por ejemplo, “L2-Corp” o “L2-XNet”.
30 Configuración de zonas de seguridad y zonas de túnel

Capítulo 2: Zonas
CLI
set zone name zona [ l2 núm_id_vlan | tunnel zona_seg ]
set zone zona block
set zone zona vrouter cadena_nombre
save
NOTA: Al crear una zona de seguridad de capa 2 (Layer 2), el número de identificación
VLAN-ID debe ser 1 (para VLAN1).
Modificación de una zona

Para modificar el nombre de una zona de seguridad o zona de túnel o para cambiar
la zona portadora de una zona de túnel, primero debe eliminar la zona y luego
volver a crearla con los cambios. Puede cambiar la opción de bloqueo entre zonas
y el enrutador virtual en una zona existente.
NOTA: Antes de poder eliminar una zona, primero debe desasociar todas las interfaces
asociadas a ella.
Antes de poder cambiar el enrutador virtual para una zona debe primero eliminar
cualquier interfaz asociada a ella.
WebUI
1. Modificación del nombre de una zona
Network > Zones: Haga clic en Remove (para la zona de seguridad o zona de
túnel cuyo nombre desea cambiar o para la zona de túnel cuya zona portadora
desea cambiar).
Cuando aparezca la petición de confirmación para eliminar, haga clic

en Yes.
Network > Zones > New: Introduzca los ajustes de zona con sus cambios,
luego haga clic en OK.
2. Cambiar la opción de bloqueo intrazonal o el enrutador virtual

Network > Zones > Edit (para las zonas que desea modificar): Introduzca los
Virtual Router Name: En la lista desplegable seleccione el enrutador virtual

a cuyo dominio de enrutamiento desea mover la zona.
Block Intra-Zone Traffic: Para habilitar, seleccione la casilla de verificación.

Para desactivar la opción, desactive la casilla.
CLI
1. Modificación del nombre de una zona
unset zone zona
set zone name zona [ l2 núm_id_vlan | tunnel zona_seg ]
Configuración de zonas de seguridad y zonas de túnel 31

2. Cambiar la opción de bloqueo intrazonal o el enrutador virtual

{ set | unset } zone zona block
set zone zona vrouter cadena_nombre
save
Eliminación de una zona

Para que el funcionamiento sea óptimo, debe guardar siempre sus cambios
y reiniciar después de eliminar una zona. Para eliminar una zona de seguridad o
zona de túnel, realice cualquiera de los siguientes procedimientos:
WebUI
Network > Zones: Haga clic en Remove (para la zona que desee eliminar).
Cuando aparezca la petición de confirmación para eliminar, haga clic en Yes.
CLI
unset zone zona
save
NOTA: Antes de poder eliminar una zona, primero debe desasociar todas las interfaces
asociadas a ella. Para desasociar una interfaz de una zona, consulte “Asociación de
una interfaz a una zona de seguridad” en la página 43.
Zonas de función
Las cinco zonas de función son Null, MGT, HA, Self y VLAN. Cada zona existe con un
solo propósito, según se explica en la Tabla 3.
Tabla 3: Zonas de función

Zona Descripción
Zona Null Esta zona sirve como almacenamiento temporal para cualquier interfaz que no
esté asociada a ninguna otra zona.
Zona MGT Esta zona contiene la interfaz de administración fuera de banda, MGT. Puede
establecer opciones de cortafuegos en esta zona para proteger la interfaz de
administración contra diversos tipos de ataques. Para obtener más información
sobre opciones de cortafuegos, consulte el Volumen 4:
Detección ataques y mecanismos de defensa.
Zona HA Esta zona contiene las interfaces de alta disponibilidad, HA1 y HA2. Aunque
puede configurar interfaces para la zona HA, la zona propiamente dicha no se
puede configurar.
Zona Self Esta zona contiene la interfaz para las conexiones de administración remotas.
Cuando se conecta al dispositivo de seguridad a través de HTTP, SCS o Telnet, se
conecta a la zona de Self.
Zona VLAN Esta zona contiene la interfaz VLAN1, que se utiliza para administrar el
dispositivo y terminar el tráfico VPN cuando el dispositivo está en modo
transparente. También puede establecer opciones de cortafuegos en esta zona
para proteger la interfaz VLAN1 de diversos ataques.
32 Zonas de función
Capítulo 3
Interfaces
Las interfaces y subinterfaces físicas permiten que entre y salga tráfico de una zona
de seguridad. Para permitir que el tráfico de una red fluya dentro y fuera de una
zona de seguridad, ésta debe tener asociada una interfaz y, si se trata de una zona
de capa 3, deberá asignársele una dirección IP. A continuación se deberán
configurar directivas para permitir que el tráfico pase de interfaz en interfaz entre
las diferentes zonas. Se pueden asignar varias interfaces a una zona, pero una
misma interfaz no se puede asignar a varias zonas.
Este capítulo consta de las siguientes secciones:
“Tipos de interfaces” en esta página
“Visualización de interfaces” en la página 41
“Configuración de interfaces de la zona de seguridad” en la página 42
“Creación de una dirección IP secundaria” en la página 49
“Interfaces del sistema de respaldo” en la página 50
“Interfaces de bucle invertido (o “loopback”)” en la página 57
“Cambios de estado de la interfaz” en la página 60
Tipos de interfaces
Esta sección describe las interfaces lógicas, las interfaces de zona de función y las
interfaces de túnel. Para obtener más información sobre cómo ver una tabla de
todas estas interfaces, consulte “Visualización de interfaces” en la página 41.
Interfaces lógicas
La finalidad de las interfaces lógicas es proporcionar una abertura por la que el
tráfico de red pueda pasar de una zona a otra. ScreenOS admite los siguientes tipos
de interfaces lógicas:
Interfaces físicas
Interfaces inalámbricas
Interfaces de grupos en puente
Tipos de interfaces 33
Subinterfaces
Interfaces agregadas
Interfaces redundantes
Interfaces de seguridad virtuales
Interfaces físicas
El nombre de una interfaz física está compuesto del tipo de medio, número de
ranuras (para algunos dispositivos) y número de índice, por ejemplo, ethernet3/2,
ethernet0/2, wireless2, wireless0/2, bgroup2, serial0/0, serial0/2, bri0/0, or adsl0/2.
Puede asociar una interfaz física a cualquier zona de seguridad en la que actúe
como entrada a través de la que el tráfico entre y salga de la zona. Sin una interfaz,
no hay tráfico que pueda entrar ni salir de una zona.
En los dispositivos de seguridad que admiten cambios en los enlaces de interfaz

a zona, tres de las interfaces físicas Ethernet están preasociadas a zonas de
seguridad específicas de capa 3: Trust, Untrust y DMZ. La interfaz que se asocia
a cada zona depende de la plataforma en cuestión. (Para obtener más información
sobre zonas de seguridad, consulte “Configuración de interfaces de la zona de
seguridad” en la página 42.)
Interfaces inalámbricas
Una interfaz inalámbrica, al igual que una interfaz física, actúa como puerta por la
que entra y sale el tráfico de una zona de seguridad. Cada dispositivo de seguridad
inalámbrico permite que hasta cuatro interfaces inalámbricas (wireless0/0 —
wireless0/3) estén en línea simultáneamente.
Una interfaz inalámbrica no se puede asociar a la zona de seguridad Untrust. (Para

obtener más información, consulte “Red de área local inalámbrica” en la
página 12-121).
Interfaces de grupos en puente

Algunos dispositivos de seguridad son compatibles con grupos en puente (bgroups).
Los Bgroups le permiten agrupar varias Ethernet e interfaces inalámbricas. Cada
bgroup constituye su propio dominio de difusión y proporciona una conmutación
de Ethernet de alta velocidad entre las interfaces dentro del grupo. Puede asignar
una dirección IP individual a cada interfaz de bgroup. Una interfaz bgroup se puede
asociar a cualquier zona.
Para los dispositivos que están configurados previamente con los grupos de puente,
existen dos sistemas diferentes de numeración de grupo de puente. En algunos
dispositivos, las interfaces de bgroup preconfiguradas se identifican como bgroup0
hasta bgroup3. En otros dispositivos, las interfaces de bgroup preconfiguradas se
identifican como bgroup0/0 hasta bgroup0/2.
En algunos dispositivos que son compatibles con los módulos instalables en campo
como PIM o mini-PIM, puede crear bgroups que contengan algunos o todos los
puertos Ethernet en el módulo. En estos dispositivos, cree bgroups identificados
como bgroupx/y, donde x es el número de ranura para el módulo que contiene los
puertos agrupados y es un número que asigna cuando crea el grupo de puente.
34 Tipos de interfaces
Capítulo 3: Interfaces
Puede asociar una interfaz de grupo en puente a cualquier zona. (Para obtener más
información, consulte “Asociación de una interfaz a una zona de seguridad” en la
página 43).
Subinterfaces
Una subinterfaz, como una interfaz física, actúa como puerta por la que entra y sale
el tráfico de una zona de seguridad. Una interfaz física se puede dividir lógicamente
en varias subinterfaces virtuales. Cada subinterfaz virtual toma prestado el ancho
de banda que necesita de la interfaz física de la que procede, por lo que su nombre
es una extensión del nombre de la interfaz física, por ejemplo, ethernet3/2.1
o ethernet0/2.1.
Una subinterfaz se puede asociar a cualquier zona de capa 3. Una subinterfaz se

puede asociar a la misma zona que su interfaz física, o bien a otra zona. (Para
obtener más información, consulte “Asociación de una interfaz a una zona de
seguridad” en la página 43).
Interfaces agregadas
Algunos dispositivos de seguridad admiten interfaces agregadas. Una interfaz
agregada es la acumulación de dos o más interfaces físicas, entre las que se
reparten equitativamente la carga de tráfico dirigida a la dirección IP de la interfaz
agregada. Utilizando interfaces agregadas se puede aumentar el ancho de banda
disponible para una dirección IP determinada. Asimismo, si falla algún miembro de
una interfaz agregada, los otros miembros pueden seguir procesando tráfico,
aunque con menos ancho de banda que el disponible anteriormente.
NOTA: Para obtener más información sobre interfaces agregadas, consulte “Redundancia
de interfaces y conmutación por error” en la página 11-43.
Interfaces redundantes
Dos interfaces físicas se pueden asociar para crear una interfaz redundante, que
entonces se puede asociar a una zona de seguridad. Una de las dos interfaces
físicas actúa como interfaz principal y gestiona todo el tráfico dirigido a la interfaz
redundante. La otra interfaz física actúa como interfaz secundaria y permanece en
estado de espera por si la interfaz activa experimenta algún fallo. En ese caso, el
tráfico dirigido a la interfaz redundante se desvía a la interfaz secundaria, que se
convierte en la nueva interfaz principal. El uso de interfaces redundantes
proporciona un primer frente de redundancia antes de que el fallo sea comunicado
como error al nivel de dispositivo.
NOTA: Para obtener más información sobre interfaces redundantes, consulte

“Redundancia de interfaces y conmutación por error” en la página 11-43.
Interfaces de seguridad virtuales

Las interfaces de seguridad virtuales (VSI) son las interfaces virtuales compartidas
por dos dispositivos de seguridad que forman un dispositivo de seguridad virtual
(VSD) cuando funcionan en el modo de alta disponibilidad (HA). Tanto el tráfico de
una red como el tráfico VPN utilizan la dirección IP y la dirección virtual MAC de un
VSI. A continuación, VSD asigna el tráfico a la interfaz, subinterfaz o interfaz
redundante a la que anteriormente había asociado el VSI. Cuando dos dispositivos
de seguridad están funcionando en el modo HA, es necesario asociar las interfaces
de la zona de seguridad a las que desee proporcionar un servicio ininterrumpido
por si se produce algún cambio en caso de error en uno o más dispositivos de
seguridad virtuales (VSD). Cuando se asocia una interfaz a un VSD, el resultado es
una interfaz de seguridad virtual (VSI).
NOTA: Para obtener más información sobre las VSI y cómo funcionan con los VSD en un
clúster HA, consulte el Volumen 11: Alta disponibilidad.
Interfaces de zonas de función

Las interfaces de las zonas de función, como la de administración y la de HA, tienen
una finalidad especial.
Interfaces de administración
En algunos dispositivos de seguridad, el dispositivo se puede administrar a través
de una interfaz física separada (la interfaz de administración o MGT) sacando el
tráfico administrativo fuera del tráfico de usuario de red habitual. Al separar el
tráfico administrativo del tráfico de los usuarios de red se aumenta
significativamente la seguridad y se garantiza un ancho de banda de administración
constante.
NOTA: Para obtener más información sobre la configuración del dispositivo para la
administración, consulte “Administración” en la página 3-1.
Interfaces de alta disponibilidad

La interfaz de alta disponibilidad (HA) es un puerto físico utilizado exclusivamente
para las funciones de HA. En un grupo redundante, una unidad actúa como
dispositivo principal (desempeñando las funciones de cortafuegos de la red, VPN
y asignación de tráfico), mientras que la otra unidad actúa como dispositivo de
respaldo, en espera de asumir las funciones de cortafuegos cuando la unidad
principal falla. Se trata de una configuración activa/pasiva. También se pueden
configurar ambos miembros del clúster para actuar mutuamente como principales
y respaldos. Esta configuración se denomina activa/activa. Ambas configuraciones
se explican en detalle en el Volumen 11: Alta disponibilidad.
Interfaces de HA virtuales
En los dispositivos de seguridad que no están equipados con una interfaz de HA
especializada, una interfaz HA virtual proporciona la misma funcionalidad. Al no
haber ningún puerto físico dedicado exclusivamente al tráfico de HA, deberá
asociar la interfaz HA virtual a uno de los puertos físicos de Ethernet. Para asociar
una interfaz de red a la zona de HA se utiliza el mismo procedimiento que para
asociar una interfaz de red a una zona de seguridad.
Interfaces de túnel
Una interfaz de túnel actúa como entrada a un túnel VPN. El tráfico entra y sale por
el túnel VPN a través de una interfaz de túnel.
Cuando se asocia una interfaz de túnel a un túnel VPN, se puede establecer una
referencia a esa interfaz de túnel en una ruta hacia un destino determinado
y después hacer referencia a ese destino en una o más directivas. Este método
permite un control muy detallado del flujo de tráfico a través del túnel. También
permite el enrutamiento dinámico para el tráfico VPN. Cuando no hay ninguna
interfaz de túnel asociada a un túnel VPN, se debe especificar el túnel mismo en la
directiva y elegir tunnel como acción. Dado que la acción tunnel lleva implícito un
permiso, no se puede rechazar específicamente el tráfico procedente de un túnel
VPN.
Se puede aplicar NAT basada en directivas al tráfico entrante o saliente usando un

conjunto de direcciones IP dinámicas (DIP) en la misma subred que la interfaz de
túnel. Un motivo típico para utilizar NAT basada en directivas en una interfaz de
túnel es evitar conflictos de direcciones IP entre los sitios de ambos extremos de un
túnel VPN.
Debe asociar un túnel VPN basado en rutas a una interfaz de túnel para que el
dispositivo de seguridad pueda dirigir el tráfico entrante y saliente. Un túnel VPN
basado en rutas se puede asociar a una interfaz de túnel numerada (con dirección
IP y máscara de red) o no numerada (sin dirección IP y máscara de red). Si la
interfaz de túnel no está numerada, debe especificar una interfaz que preste a la
interfaz de túnel una dirección IP. El dispositivo de seguridad solamente utiliza la
dirección IP prestada como dirección de origen cuando el dispositivo de seguridad
mismo genera tráfico (como el de los mensajes OSPF) a través del túnel. La interfaz
de túnel puede tomar prestada la dirección IP de otra interfaz en la misma zona de
seguridad, o bien de una interfaz en otra zona, siempre que ambas zonas se
encuentren en el mismo dominio de enrutamiento.
Se puede alcanzar un control muy fiable del enrutamiento del tráfico VPN
asociando todas las interfaces de túnel no numeradas a una zona, que se encuentra
en su propio dominio de enrutamiento virtual, y tomando la dirección IP de una
interfaz de bucle invertido asociada a la misma zona. Por ejemplo, se pueden
asociar todas las interfaces de túnel no numeradas a una zona definida definida por
el usuario llamada “VPN” y configurarlas para que tomen su dirección IP de la
interfaz loopback.1, también asociada a la zona VPN. La zona VPN se encuentra en
un dominio de enrutamiento definido por el usuario llamado “vpn-vr”. Usted
pondrá todas las direcciones de destino a las que conducen los túneles en la zona
VPN. Sus rutas a estas direcciones apuntan a las interfaces de túnel, y sus directivas
controlan el tráfico VPN entre otras zonas y la zona VPN, consulte Figura 17.
Figura 17: Asociaciones de interfaces de túnel no numeradas

set vrouter name vpn-vr
set zone name vpn vrouter vpn-vr
set interface loopback.1 zone vpn
set interface loopback.1 ip 172.16.1.1/24 ethernet0/1 ethernet0/3
set interface tunnel.1 zone vpn 10.1.1.1/24 1.1.1.1/24
set interface tunnel.1 ip unnumbered loopback.1 Zona Trust Zona Untrust
trust-vr
Enrutador
externo
Configure las direcciones para src-1 y dst-1. 1.1.1.250
Configure un túnel VPN y asócielo a tunnel.1. src- 10.1.1.5
set vrouter trust-vr route 10.2.2.5/32 vrouter vpn-vr

set vrouter trust-vr route 0.0.0.0/0 interface ethernet0/3
puerta de enlace 1.1.1.250
set vrouter vpn-vr route 10.2.2.5 interface tunnel.1 dst-1 10.2.2.5
tunnel.1 no
numerado loopback.1
set policy from trust to vpn scr-1 dst-1 any permit 172.16.1.1/24
Zona VPN
El dispositivo de seguridad envía el tráfico destinado a 10.2.2.5/32 de
trust-vr a vpn-vr. Si tunnel.1 se inhabilita por cualquier causa, el vpn-vr
dispositivo descarta el paquete. Dado que la ruta predeterminada (a
0.0.0.0/0) solamente se encuentra en trust-vr, el dispositivo no intenta
enviar el paquete en texto puro sin formato a través de ethernet0/3.
Poner todas las interfaces de túnel en una zona de estas características es muy
seguro porque no hay posibilidad de que, por un fallo de la VPN (que provocaría la
desactivación de la ruta hacia la interfaz de túnel asociada), el tráfico destinado al
túnel sea desviado hacia una ruta sin túnel, como la ruta predeterminada. (Para ver
varias sugerencias sobre cómo evitar este problema, consulte “Consideraciones
sobre seguridad en redes privadas virtuales basadas en rutas” en la página 5-74).
También puede asociar una interfaz de túnel a una zona de túnel. En tal caso, debe
tener una dirección IP. La finalidad de asociar una interfaz de túnel a una zona de
túnel es que los servicios de NAT estén disponibles para los túneles VPN basados en
directivas. Consulte la Figura 18 en la página 39.
NOTA: Los servicios de traducción de direcciones de red (NAT) incluyen conjuntos de

direcciones IP dinámicas (DIP) y direcciones IP asignadas (MIP) definidas en la
misma subred que una interfaz.
Figura 18: Enlaces de interfaz de túnel a zona

Interfaces Interfaces de zonas
de túnel de seguridad
Cuando una interfaz de túnel se encuentra en una zona de seguridad, debe asociarse un túnel
Numerada o Seguridad VPN a la interfaz de túnel. Esto permite crear una configuración de VPN basada en rutas. La
Túnel VPN interfaz de túnel puede estar numerada o no numerada. Si no está numerada, la interfaz de túnel
no numerada
toma prestada la dirección IP de la interfaz predeterminada de la zona de seguridad en la que fue
Zona creada.
Nota: Sólo una interfaz de túnel con una dirección IP y una máscara de red puede admitir NAT
basada en directivas.
Seguridad Cuando una interfaz de túnel numerada se encuentra en una zona de seguridad y es la única
Túnel VPN
Numerada interfaz en esa zona, no es necesario crear una interfaz de zona de seguridad. En este caso, la
Zona zona de seguridad admite tráfico VPN a través de la interfaz de túnel, pero ningún otro tipo de
tráfico.
Túnel Túnel VPN Cuando una interfaz de túnel está asociada a una zona de túnel, la interfaz de túnel debe tener
Numerada una dirección IP y una máscara de red. Esto permite definir conjuntos de DIP y direcciones MIP
en esa interfaz. Si asocia un túnel VPN a una zona de túnel, no puede asociarlo también a una
Zona interfaz de túnel. En tales casos, debe crear una configuración de VPN basada en directivas.
Conceptualmente, los túneles VPN pueden imaginarse como tuberías tendidas.

Abarcan desde el dispositivo local hasta las puertas de enlace remotas, siendo las
interfaces de túnel los orificios en los extremos de esas tuberías. Las tuberías
siempre están disponibles, listas para cuando el motor de enrutamiento envíe
tráfico a una de sus interfaces.
Generalmente, se asigna una dirección IP a una interfaz de túnel cuando se desea

que ésta admita uno o más conjuntos de direcciones IP dinámicas (DIP) para la
traducción de direcciones de origen (NAT-src) y conjuntos de direcciones IP
asignadas (MIP) para la traducción de direcciones de destino (NAT-dst). Para obtener
más información sobre VPN y la traducción de direcciones, consulte “Sitios VPN
con direcciones superpuestas” en la página 5-142). Se puede crear una interfaz de
túnel con una dirección IP y una máscara de red en una zona de seguridad o de
túnel.
Si la interfaz de túnel no necesita trabajar con traducción de direcciones y su

configuración no requiere que la interfaz de túnel esté asociada a una zona de túnel,
puede especificar la interfaz como no numerada. Una interfaz de túnel no
numerada debe asociarse a una zona de seguridad; no se puede asociar a una zona
de túnel. También debe especificar una interfaz con una dirección IP que
pertenezca al mismo dominio de enrutamiento virtual que la zona de seguridad a la
que está asociada la interfaz no numerada. La interfaz de túnel no numerada toma
prestada la dirección IP de esa interfaz.
NOTA: Para ver cómo asociar una interfaz de túnel a un túnel, consulte los ejemplos de
VPN basada en rutas en “Redes privadas virtuales de punto a punto” en la
página 5-81 y “Redes privadas virtuales de acceso telefónico” en la página 5-163.
Si está transmitiendo paquetes multicast a través de un túnel VPN, puede habilitar

la encapsulación de enrutamiento genérica (“Generic Routing Encapsulation”
o GRE) en las interfaces de túnel para encapsular los paquetes multicast en
paquetes unicast. Los dispositivos de seguridad de Juniper Networks admiten
GREv1 para encapsular paquetes IP en paquetes unicast IPv4. Para obtener más
información sobre GRE, consulte “Configurar Encapsulado de enrutamiento
genérico en interfaces de túnel” en la página 7-161.
Eliminación de interfaces de túnel

No se puede eliminar inmediatamente una interfaz de túnel que contenga
direcciones IP asignadas (MIP) o conjuntos de direcciones IP dinámicas (DIP). Antes
de eliminar una interfaz de túnel que contenga cualquiera de estas características,
primero debe eliminar cualquier directiva que contenga referencias a ellas.
A continuación debe eliminar las MIP y los conjuntos de DIP en la interfaz de túnel.
Asimismo, si una configuración de VPN basada en rutas contiene referencias a una
interfaz de túnel, antes de poder eliminar la interfaz de túnel, debe eliminar la
configuración de VPN.
En este ejemplo, la interfaz de túnel tunnel.2 está vinculada al conjunto de DIP 8.

Existen referencias al conjunto de DIP 8 en una directiva (ID 10) para el tráfico VPN
procedente de la zona Trust y destinado a la zona Untrust a través de un túnel VPN
llamado vpn1. Para eliminar la interfaz de túnel, primero debe eliminar la directiva
(o eliminar las referencias al conjunto de DIP 8 de la directiva) y a continuación el
conjunto de DIP. Después debe desasociar tunnel.2 de vpn1. Después de eliminar
todas las configuraciones que dependen de la interfaz de túnel, puede eliminar ésta.
WebUI
1. Eliminar la directiva 10, con referencias al conjunto de DIP 8
Policy > Policies (From: Trust, To: Untrust): Haga clic en Remove para la
directiva con ID 10.
2. Eliminar el rango DIP 8, vinculado a tunnel.2

Network > Interfaces > Edit (para tunnel.2) > DIP: Haga clic en Remove para
la DIP con ID 8.
3. Desasociar tunnel.2 de vpn1

VPNs > AutoKey IKE > Edit (para vpn1) > Advanced: Seleccione None en la
lista desplegable “Bind to: Tunnel Interface”, haga clic en Return y después
en OK.
4. Eliminar tunnel.2
Network > Interfaces: Haga clic en Remove para tunnel.2.
CLI
1. Eliminar la directiva 10, con referencias al conjunto de DIP 8
unset policy 10
2. Eliminar el rango DIP 8, vinculado a tunnel.2
unset interface tunnel.2 dip 8
3. Desasociar tunnel.2 de vpn1

unset vpn vpn1 bind interface
4. Eliminar tunnel.2
unset interface tunnel.2
save
Visualización de interfaces
Puede visualizar una tabla que muestre todas las interfaces existentes en su
dispositivo de seguridad. Al estar predefinidas, las interfaces físicas aparecen en la
lista tanto si se configuran como si no. Las subinterfaces e interfaces de túnel
solamente aparecen después de crearlas y configurarlas.
Para visualizar la tabla de interfaces en WebUI, haga clic en Network > Interfaces.
Puede especificar los tipos de interfaces que desea mostrar en la lista desplegable
“List Interfaces”.
Para ver la tabla de interfaces en CLI, utilice el comando get interface.
La tabla de interfaces muestra la información siguiente sobre cada interfaz:
Name: Este campo identifica el nombre de la interfaz.
IP/Netmask: Este campo identifica la dirección IP y la dirección de la máscara

de red de la interfaz.
Zone: Este campo identifica las zonas a las que está asociada la interfaz.
Type: Este campo indica el tipo de interfaz: capa 2, capa 3, túnel, redundante,
agregada, VSI.
Link: Este campo identifica si la interfaz está en línea (Up) o fuera de línea
(Down).
Configure: Este campo permite modificar o eliminar interfaces.
Visualización de interfaces 41
Figura 19: Tabla de interfaces de WebUI
Figura 20: Tabla de interfaces de CLI
Configuración de interfaces de la zona de seguridad

Esta sección describe cómo configurar los siguientes aspectos de las interfaces de la
zona de seguridad:
Asociar y desasociar una interfaz a una zona de seguridad
Asignar una dirección a una interfaz de la zona de seguridad de capa 3 (L3)
Modificar interfaces y subinterfaces físicas
42 Configuración de interfaces de la zona de seguridad

Crear subinterfaces
Eliminar subinterfaces
NOTA: Para obtener más información sobre cómo establecer el ancho de banda para una
interfaz, consulte “Asignación de tráfico” en la página 195. Para obtener más
información sobre las opciones de administración y otras opciones de servicios
disponibles para cada interfaz, consulte “Control del tráfico administrativo” en la
página 3-29.
Asociación de una interfaz a una zona de seguridad

Puede asociar algunas interfaces físicas a una zona de seguridad L2 o L3. Las
interfaces WAN, excepto para ADSL, no se pueden asociar a las zonas de seguridad
L2. Puede asociar una subinterfaz sólo a una zona de seguridad L3, porque una
subinterfaz requiere una dirección IP. Solamente puede asignar una dirección IP
a una interfaz después de haberla asociado a una zona de seguridad L3. Las
interfaces inalámbricas no se pueden asociar a la zona de seguridad Untrust.
Algunos dispositivos de seguridad le permiten agrupar varias interfaces. Antes de

agregar una interfaz a un grupo, la interfaz se debe establecer en la zona de
seguridad Null. Después de que las interfaces se agreguen a un grupo, la interfaz de
grupo se debe asignar a una zona de seguridad para que la conexión se establezca.
En este ejemplo asociará ethernet0/5 a la zona Trust.
WebUI
Network > Interfaces > Edit (para ethernet0/5): Seleccione Trust en la lista
desplegable Zone Name, luego haga clic en Apply.
CLI
save
En este ejemplo, establecerá ethernet0/3 y ethernet0/4 en la zona de seguridad

Null, agrupará las interfaces en bgroup1, luego asociará el grupo a la zona de
seguridad DMZ:
WebUI
Network > Interfaces > Edit (para ethernet0/3): Seleccione Null en la lista
Network > Interfaces > Edit (para ethernet0/4): Seleccione Null en la lista
Network > Interfaces > Edit (para bgroup1): Seleccione DMZ en la lista
Network > Interfaces > Edit (para bgroup1): Marque ethernet0/3

y ethernet0/4 en la columna Bind to Current Bgroup, luego haga clic en Apply.
Configuración de interfaces de la zona de seguridad 43

CLI
set interface ethernet0/3 zone null
set interface bgroup1 port ethernet0/3
set interface bgroup1 zone DMZ
save
Desasociación de una interfaz de una zona de seguridad

Si una interfaz no está numerada, puede desasociarla de una zona de seguridad
y asociarla a otra. Si una interfaz está numerada, primero debe establecer su
dirección IP y máscara de red en 0.0.0.0. A continuación, puede desasociarla de
una zona de seguridad y asociarla a otra, y (opcionalmente) reasignarle una
dirección IP y máscara de red.
En este ejemplo, ethernet0/3 tiene la dirección IP 210.1.1.1/24 y está asociada a la

zona Untrust. Establecerá su dirección IP y máscara de red en 0.0.0.0/0 y la
asociará a la zona Null.
WebUI
Zone Name: Null

CLI
save
Para separar una interfaz de un grupo y reasignarla a una zona de seguridad

diferente, la interfaz se debe separar del bgroup. Al separar la interfaz del bgroup,
ésta se coloca en la zona de seguridad Null. Cuando se encuentra en la zona de
seguridad Null, la interfaz se puede asociar a cualquier zona de seguridad y luego
configurarse con una dirección IP.
WebUI
Network > Interfaces > Edit (para bgroup1) > Bind Port: Cancele la selección
de ethernet0/3 en la columna Bind to Current Bgroup, luego haga clic
en Apply.
Network > Interfaces > Edit (para ethernet0/3): Seleccione Trust en la lista
CLI
unset interface bgroup1 port ethernet0/3
save

Direccionamiento de una interfaz de la zona de seguridad L3

Al definir una interfaz o subinterfaz de la zona de seguridad de capa 3 (L3), debe
asignarle una dirección IP y una máscara de red. Si se asocia la interfaz a una zona
en trust-vr, también se puede especificar el modo de la interfaz como NAT o de
rutas. (Si la zona a la que se asocia la interfaz se encuentra en untrust-vr, la interfaz
siempre estará en el modo de rutas).
NOTA: Para ver ejemplos de configuraciones de los modos NAT y rutas, consulte el
“Modos de las interfaces” en la página 79.
Los dos tipos básicos de direcciones IP que pueden utilizarse para asignar
direcciones de interfaces son:
Direcciones públicas, proporcionadas por los proveedores de servicios de

Internet (ISP) para su utilización en una red pública como Internet, y que deben
ser únicas
Direcciones privadas, que un administrador de red local asigna para utilizarse

en una red privada y que pueden ser asignadas por otros administradores para
utilizarse también en otras redes privadas
NOTA: Cuando agrega una dirección IP a una interfaz, el dispositivo de seguridad verifica
mediante una petición de ARP si la dirección IP existe en la red local. (El enlace
físico debe estar en línea en ese momento). Si la dirección IP ya existe, se genera
un aviso.
Direcciones IP públicas
Si una interfaz se conecta a una red pública, debe tener una dirección IP pública.
Asimismo, si una zona de seguridad L3 en untrust-vr se conecta a una red pública
y las interfaces de las zonas en trust-vr están en moto de rutas, todas las direcciones
de las zonas en trust-vr (para las interfaces y para los hosts) también deben ser
direcciones públicas. Los direcciones IP públicas se dividen en tres clases: A, B, y C,
como se muestra en la Tabla 4.
Tabla 4: Rangos de direcciones públicas
Clase de dirección Rango de direcciones Rango de direcciones excluidas

A 0.0.0.0 – 127.255.255.255 10.0.0.0 – 10.255.255.255, 127.0.0.0 – 127.255.255.255
B 128.0.0.0 – 191.255.255.255 172.16.0.0 – 172.31.255.255
C 192.0.0.0 – 223.255.255.255 192.168.0.0 – 192.168.255.255
NOTA: También existen direcciones de las clases D y E, reservadas para fines especiales.

Una dirección IP se compone de cuatro octetos, cada uno compuesto por 8 bits. En
una dirección de clase A, los primeros 8 bits indican la identificación de la red y los
24 bits finales indican la identificación del host (rrr.hhh.hhh.hhh). En una dirección
de clase B, los primeros 16 bits indican la identificación de la red y los 16 bits
finales indican la identificación del host (nnn.nnn.hhh.hhh). En una dirección de
clase C, los primeros 24 bits indican la identificación de la red y los 8 bits finales
indican la identificación del host (nnn.nnn.nnn.hhh).
Aplicando máscaras de subred (o máscaras de red), las redes se pueden subdividir

más aún. En esencia, una máscara de red enmascara parte de la identificación del
host, convirtiendo la parte enmascarada en una subred de la identificación de la
red. Por ejemplo, la máscara de 24 bits de la dirección 10.2.3.4/24 indica que los
primeros 8 bits (es decir, el primer octeto, 010) identifican la porción de la red de
esta dirección privada de clase A, los 16 bits siguientes (es decir, los octetos
segundo y tercero, 002.003) identifican la porción de subred de la dirección y los
últimos 8 bits (el último octeto, 004) identifican la porción del host de la dirección.
Utilizando subredes para reducir los espacios de direcciones de grandes redes en
subdivisiones más pequeñas, aumenta significativamente la eficacia en la entrega
de datagramas IP.
NOTA: El equivalente decimal con puntos de una máscara de 24 bits es 255.255.255.0.
Direcciones IP privadas
Si una interfaz se conecta a una red privada, un administrador de la red local puede
asignarle cualquier dirección, aunque es usual utilizar una dirección del rango de
direcciones reservado para uso privado (10.0.0.0/8, 172.16.0.0 – 172.31.255.255,
192.168.0.0/16) según se define en RFC 1918, Asignación de direcciones para
Internet privadas.
Si la zona de seguridad L3 en untrust-vr se conecta a una red pública y las interfaces

asociadas a las zonas en trust-vr están en el modo NAT, todas las direcciones de las
zonas en trust-vr (para interfaces y para hosts) pueden ser privadas.
Direccionamiento de una interfaz

En este ejemplo asignará a ethernet0/5 la dirección IP 210.1.1.1/24 y le dará la
dirección IP de administración 210.1.1.5. (Recuerde que la dirección IP de
administración debe encontrarse en la misma subred que la dirección IP de la
interfaz de la zona de seguridad). Por último, establecerá la interfaz en modo NAT,
que traduce todas las direcciones IP internas a las interfaces predeterminadas
asociadas a las otras zonas de seguridad.
NOTA: La interfaz predeterminada en una zona de seguridad es la primera interfaz

asociada a la zona. Para averiguar cuál es la interfaz predeterminada de una zona,
consulte la columna “Default IF” en la página “Network > Zones” de WebUI, o la
columna “Default-If” en el resultado del comando CLI get zone.

WebUI
Manage IP: 210.1.1.5
CLI
set interface ethernet0/5 manage-ip 210.1.1.5
save
Modificar los ajustes de interfaz

Una vez haya configurado una interfaz física, una subinterfaz, una interfaz
redundante, una interfaz agregada o una interfaz de seguridad virtual (VSI), puede
cambiar posteriormente cualquiera de los ajustes siguientes si surge la necesidad:
Dirección IP y máscara de red.
Dirección de IP de administración.
(Interfaces de la zona L3) Servicios de administración y de red.
(Subinterfaz) Número de identificación de la subinterfaz y número de etiqueta

VLAN.
(Interfaces asociadas a las zonas de seguridad L3 en trust-vr) Modo de la

interfaz: NAT o ruta.
(Interfaz física) Ajustes del ancho de banda del tráfico (consulte “Asignación de
tráfico” en la página 195).
(Interfaces físicas, redundantes y agregadas) Tamaño de la unidad de

transmisión máxima (MTU).
(Interfaces L3) Bloquee el tráfico que entra y sale por la misma interfaz,
incluyendo el tráfico entre una subred principal y secundaria o entre subredes
secundarias (esto se realiza mediante el comando CLI set interface con la
opción route-deny).
En las interfaces físicas de algunos dispositivos de seguridad se puede forzar el

estado físico del vínculo como en línea (up) o fuera de línea (down). Forzando el
estado físico del vínculo como fuera de línea, se puede simular una desconexión del
cable del puerto de la interfaz. (Esto se consigue mediante el comando CLI set
interface con la opción phy link-down.)
En este ejemplo hará algunas modificaciones a ethernet0/1, una interfaz asociada a

la zona Trust. Cambiará la dirección IP de administración de 10.1.1.2 a 10.1.1.12.
Para aumentar el nivel de seguridad del tráfico administrativo, también cambiará
las opciones de los servicios de administración, habilitando SCS y SSL
y desactivando Telnet y WebUI.

WebUI
Network > Interfaces > Edit (para ethernet0/1): Realice las modificaciones
siguientes, luego haga clic en OK:
Manage IP: 10.1.1.12

Management Services: (seleccione) SSH, SSL; (borre) Telnet, WebUI
CLI
set interface ethernet0/1 manage-ip 10.1.1.12
set interface ethernet0/1 manage ssh
set interface ethernet0/1 manage ssl
unset interface ethernet0/1 manage telnet
unset interface ethernet0/1 manage web
save
Creación de una subinterfaz en el sistema raíz

Puede crear una subinterfaz en cualquier interfaz física del sistema raíz o sistema
virtual. Una subinterfaz hace uso del etiquetado de VLAN para distinguir el tráfico
asociado a ella del tráfico asociado a otras interfaces. Observe que aunque una
subinterfaz tiene su origen en una interfaz física, de la cual toma prestado el ancho
de banda que necesita, una subinterfaz se puede asociar a cualquier zona, no
necesariamente la misma a la que está asociada su interfaz “padre”. Además, la
dirección IP de una subinterfaz debe encontrarse en una subred diferente que las
direcciones IP de todas las demás interfaces y subinterfaces físicas.
NOTA: También puede configurar subinterfaces en interfaces redundantes y VSIs. Para

ver un ejemplo que contenga la configuración de una subinterfaz en una interfaz
redundante, consulte “Cambio en caso de falla del sistema virtual” en la
página 11-97.
En este ejemplo creará una subinterfaz para la zona Trust en el sistema raíz.
Configurará la subinterfaz en ethernet0/1, que está asociada a la zona Trust.
Asociará la subinterfaz a una zona definida por el usuario llamada “contabilidad”,
que se encuentra en trust-vr. Le asignará la identificación de subinterfaz 3, dirección
IP 10.2.1.1/24 e identificación 3 de etiqueta VLAN. El modo de la interfaz es NAT.
WebUI
Network > Interfaces > New Sub-IF: Introduzca los siguientes datos y haga clic
en OK:

Zone Name: contabilidad
VLAN Tag: 3
CLI
set interface ethernet0/1.3 zone contabilidad
set interface ethernet0/1.3 ip 10.2.1.1/24 tag 3
save

Eliminación de una subinterfaz

No se puede eliminar inmediatamente una subinterfaz que contenga direcciones IP
asignadas (MIP), direcciones IP virtuales (VIP) o conjuntos de direcciones IP
dinámicas (DIP). Antes de eliminar una subinterfaz que contenga cualquiera de
estas características, primero debe eliminar todas las directivas o puertas de enlace
IKE que contengan referencias a ellas. Seguidamente, deberá eliminar las MIP, VIP y
los conjuntos de DIP de la subinterfaz.
En este ejemplo eliminará la subinterfaz ethernet0/1.1.
WebUI
Network > Interfaces: Haga clic en Remove para ethernet0/1.1.
Un mensaje del sistema le pedirá que confirme la eliminación.
Haga clic en Yes para eliminar la subinterfaz.
CLI
unset interface ethernet0/1.1
save
Creación de una dirección IP secundaria

Cada interfaz de ScreenOS tiene una sola dirección IP, única y principal . Sin
embargo, algunas situaciones exigen que una interfaz tenga varias direcciones IP.
Por ejemplo, una organización puede tener asignaciones de direcciones IP
adicionales y quizás no le interese agregar un enrutador para gestionarlas. Además,
una organización puede tener más dispositivos de red de los que su subred puede
manejar, como cuando hay más de 254 hosts conectados a una LAN. Para
solucionar tales problemas, puede agregar direcciones IP secundarias a una interfaz
en la zona Trust, DMZ o definida por el usuario.
NOTA: No se pueden crear direcciones IP secundarias múltiples para interfaces en la zona

Untrust.
Las direcciones secundarias tienen ciertas propiedades que afectan a cómo se

pueden implementar tales direcciones. Estas propiedades son las siguientes:
Entre dos direcciones IP secundarias cualesquiera no puede haber

solapamientos en las direcciones de subred. Tampoco puede haber
superposiciones de direcciones de subred entre una IP secundaria y cualquier
subred existente en el dispositivo de seguridad.
Cuando administra un dispositivo de seguridad a través de una dirección IP

secundaria, la dirección siempre tendrá las mismas propiedades de
administración que la dirección IP principal. Por lo tanto, no se puede
especificar una configuración de administración separada para la dirección IP
secundaria.
Creación de una dirección IP secundaria 49

Tampoco se puede configurar una puerta de enlace para una dirección IP

secundaria.
Siempre que cree una nueva dirección IP secundaria, el dispositivo de

seguridad creará automáticamente la correspondiente entrada en la tabla de
enrutamiento. Cuando se elimina una dirección IP secundaria, el dispositivo
elimina automáticamente la entrada correspondiente en la tabla de
enrutamiento.
Habilitar o inhabilitar el enrutamiento entre dos direcciones IP secundarias no

causa ningún cambio en la tabla de enrutamiento. Por ejemplo, si desactiva el
enrutamiento entre dos direcciones de ese tipo, el dispositivo de seguridad descarta
cualquier paquete dirigido de una interfaz a otra, pero no se producirá ningún
cambio en la tabla de enrutamiento.
En este ejemplo configurará una dirección IP secundaria (192.168.2.1/24) para

ethernet0/1, una interfaz con la dirección IP 10.1.1.1/24 asociada a la zona Trust.
WebUI
Network > Interfaces > Edit (para ethernet0/1) > Secondary IP: Introduzca
los siguientes datos y haga clic en Add:
CLI
set interface ethernet0/1 ip 192.168.2.1/24 secondary
save
Interfaces del sistema de respaldo

La función de respaldo de interfaz le permite configurar una interfaz de respaldo
que puede asumir el control del tráfico desde una interfaz principal configurada.
Puede crear un respaldo para cualquier tipo de interfaz con cualquier otro tipo de
interfaz que admita la plataforma. El único requisito es que ambas interfaces deben
estar en la zona untrust.
Establecerá una interfaz de respaldo de manera que el dispositivo de seguridad

pueda transferir el tráfico a ésta en caso de que la interfaz principal quede fuera de
línea (se desconecte o falle), los destinos de la interfaz principal se vuelvan
inaccesibles o el enlace del túnel con la interfaz principal se vuelva inactivo. Cuando
la conexión a través de la interfaz principal se restablezca, ScreenOS conmutará
automáticamente el tráfico de la interfaz de respaldo a la interfaz principal. La
función de respaldo de interfaz también proporciona un medio para obligar
manualmente a la interfaz principal para que cambie a la de respaldo y obligar a la
interfaz de respaldo para que cambie a la principal. Cada interfaz principal puede
tener sólo una interfaz de respaldo y cada interfaz de respaldo puede tener sólo una
principal.
50 Interfaces del sistema de respaldo

Puede configurar el dispositivo de seguridad para que cambie a la interfaz de

respaldo cuando se cumple cualquiera de las siguientes condiciones en la interfaz
principal:
Determinadas direcciones IP se vuelven inaccesibles a través de la interfaz.
Determinados túneles VPN en la interfaz se vuelven inaccesibles.
Una ruta previamente configurada se vuelve inaccesible a través de la interfaz.
Para que el dispositivo de seguridad transfiera el tráfico a una interfaz de respaldo

por cualquiera de estas razones, primero deberá configurar la interfaz principal para
ese fin y luego la interfaz de respaldo. También debe configurar dos rutas
predeterminadas, una para la interfaz principal y otra para la interfaz de respaldo.
Puede configurar la función de interfaz de respaldo por medio de WebUI o en la
CLI.
Configuración de una interfaz de respaldo

ScreenOS determina cuándo cambiar a una interfaz de respaldo mediante el
seguimiento o la supervisión de la actividad en la interfaz principal. Puede
configurar los siguientes tipos de interfaces de respaldo:
Seguimiento de IP
Seguimiento de túnel-if
Supervisión de rutas
Configuración de una interfaz de respaldo de seguimiento de IP

En este ejemplo, configurará ScreenOS para que dé seguimiento a la dirección
IP 10.1.1.1 en la interfaz principal (ethernet0/0) y para que cambie a la interfaz de
respaldo (dialer1), en caso de que esta dirección se vuelva inaccesible. Para obtener
más información sobre cómo funciona el seguimiento de IP, consulte “Cambio en
caso de fallo de interfaces con seguimiento de IP” en la página 11-51.
WebUI
1. Configurar interfaces
Network > Interfaces > (para ethernet0/0) Edit > Monitor > Add: Introduzca
los siguientes datos y haga clic en Apply:
Track IP: 10.1.1.1

Weight: 200
Interval: 2
Threshold: 5
Network > Interfaces > Backup: Introduzca los siguientes datos y haga clic
en Apply:
Primary interface (seleccione): ethernet0/0

Backup Interface (seleccione): dialer1
Interfaces del sistema de respaldo 51

2. Configure las rutas

Network > Routing > Destination > trust-tr New: Introduzca los siguientes
datos y haga clic en Apply:
interface (seleccione): ethernet0/0
Network > Routing > Destination > trust-tr New: Introduzca los siguientes
interface (seleccione): dialer1
CLI
set interface ethernet0/0 monitor track-ip
set interface ethernet0/0 monitor track-ip threshold 100
set interface ethernet0/0 monitor trackip ip 10.1.1.1 interval 2
set interface ethernet0/0 monitor trackip ip 10.1.1.1 threshold 5
set interface ethernet0/0 monitor trackip ip 10.1.1.1 weight 200
set interface ethernet0/0 backup interface dialer1 type track-ip
2. Configure las rutas
set route 0.0.0.0/0 interface ether0/0
set route 0.0.0.0/0 interface dialer1
save
Configuración de una interfaz de respaldo de túnel-if

En este ejemplo, configurará un par de túneles unidireccionales VPN en ethernet0/0
(uno en el enrutador-1 y otro en el enrutador-2) y configurará dialer1 como la
interfaz de respaldo en la ruta-1. Los túneles conectan hosts dentro de la zona Trust
en una sucursal a un servidor SMTP en la zona Trust de la empresa. Las zonas de
cada sitio se encuentran en el dominio de enrutamiento trust-vr.
Configure ambos túneles con la interfaz principal de la zona Untrust (ethernet0/0)

como la interfaz de salida y el túnel VPN de respaldo con la interfaz de respaldo de
la zona Untrust (dialer1) como la interfaz saliente. El dispositivo de seguridad
supervisa los túneles principales VPN para determinar cuándo cambiar a la interfaz
de respaldo. Esto se lleva a cabo mediante la comparación del peso del respaldo
con el umbral de monitor de VPN. Establecerá el umbral en 100 (set vpnmonitor
threshold 100) y el peso del respaldo en 200 (set vpn vpn backup-weight 200).
Cuando la interfaz principal se vuelve inactiva por alguna razón, ScreenOS compara
el umbral de monitor de VPN con el peso del respaldo y si el peso del respaldo es
mayor que el del umbral, cambia el dispositivo al de respaldo.
También se habilita la función de reencriptación de la supervisión de VPN. Si se

produce un cambio en caso de error, esta función le permite al dispositivo de
seguridad redirigir el tráfico de la interfaz de respaldo a la principal si el peso
acumulado de los túneles VPN en la interfaz principal resulta superior al del umbral
del monitor de VPN.

El dispositivo de seguridad de la sucursal recibe su dirección de interfaces de la

zona Untrust, puerta de enlace predeterminada y direcciones del servidor DNS
dinámicamente desde dos distintos ISP. Cada ISP utiliza un protocolo distinto. ISP-1
utiliza DHCP para asignar una dirección a ethernet0/0 e ISP-2 utiliza PPP para
asignar una dirección a dialer1. El dispositivo de seguridad en la empresa tiene una
dirección IP estática (2.2.2.2). La dirección IP de su puerta de enlace
predeterminada es 2.2.2.250.
La dirección de destino para supervisión de VPN no es la predeterminada, la

dirección IP de la puerta de enlace remota (2.2.2.2), sino las direcciones del
servidor (10.2.2.10). Si utiliza la dirección IP de la puerta de enlace remota y se
vuelve inaccesible, el túnel principal cambia siempre a la interfaz de respaldo.
NOTA: Debido a que este ejemplo es largo, únicamente la configuración CLI se incluye en
su totalidad. La sección WebUI detalla las rutas navegacionales a las páginas desde
las que puede establecer los diversos elementos de la configuración. Puede ver
qué necesita para establecerlos consultando los comandos CLI.
WebUI (para enrutador-1)

Network > Interfaces > Edit (para ethernet0/0)
Network > Interfaces > Edit (para bri1/0)
Network > Interfaces > New Tunnel IF
2. Configurar VPN
VPNs > AutoKey IKE > New
VPNs > AutoKey Advanced > Gateway > New
3. Configurar VPN asimétrica

Network > Zones > Edit (para Trust)
4. Configurar interfaz de respaldo

Network > Interfaces > Backup
5. Configurar las rutas

Network > Routing > Destination > trust-vr
CLI (para enrutador-1)

set interface ethernet0/0 dhcp client
set interface bri2/0 isdn switch-type etsi

set interface dialer1 zone untrust
set dialer pool name grupo-1
set interface bri2/0 dialer-pool-member pool-1
set interface marcador1 dialer-pool grupo-1

set ppp profile isdn-ppp

set ppp profile isdn-ppp auth type chap
set ppp profile isdn-ppp auth local-name juniper
set ppp profile isdn-ppp auth secret juniper
set ppp profile isdn-ppp passive
set ppp dialer1 ppp profile isdn-ppp
set interface tunnel.1 untrust

set interface tunnel.1 ip unnumbered interface bgroup0
set interface tunnel.2 untrust
2. Configurar VPN
set ike gateway corp1 address 2.2.2.2 aggressive local-id ssg5ssg20-e0
outgoing-interface ethernet0/0 preshare juniper1 sec-level basic
set ike gateway corp1 address 2.2.2.2 aggressive local-id ssg5ssg20-dialer
outgoing-interface dialer1 preshare juniper2 sec-level basic
set vpn vpn1 gateway corp1 sec-level basic

set vpn vpn1 bind interface tunnel.1
set vpn vpn1 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 smtp
set vpn vpn1 monitor source-interface bgroup0 destination-ip 10.2.2.10 rekey
set vpn vpn1 backup-weight 200
set vpn vpn2 gateway corp2 sec-level basic

set vpn vpn2 monitor source-interface bgroup0 destination-ip 10.2.2.10 rekey
set zone trust asymmetric-vpn
4. Configurar interfaz de respaldo
set interface ethernet0/0 backup interface dialer1 type tunnel-if
set vpnmonitor threshold 100
5. Configurar las rutas
set route 10.2.2.10/32 interface tunnel.1
set route 0.0.0.0/0 interface ethernet0/0
save
WebUI (para enrutador-2)

Network > Interfaces > Edit (para bgroup1)
Network > Interfaces > New Tunnel IF
2. Configurar direcciones
Policy > Policy Elements > Addresses > List > New
3. Configurar VPN
VPNs > AutoKey IKE > New
VPNs > AutoKey Advanced > Gateway > New


Network > Zones > Edit (para Trust)
5. Configurar ruta
Network > Routing > Destination > trust-vr
6. Configurar directiva
Policy > Policies (de Untrust a trust) > New
CLI (para enrutador-2)

set interface bgroup zone trust
set interface bgroup ip 10.2.2.1/24
set interface bgroup nat
set interface tunnel.1 zone trust
set interface tunnel.2 zone untrust
2. Configurar direcciones
set address untrust branch 10.1.1.0/24
set address trust smtp-1 10.2.2.10/24
set address trust http-1 10.2.2.15/32
set group address trust servers add smtp-1
set group service vpn-srv add smtp
3. Configurar VPN
set ike gateway branch1 dynamic ssg5ssg20-e0 aggressive outgoing-interface
ethernet0/0 preshare juniper1 sec-level basic
set ike gateway branch2 dynamic ssg5ssg20-dialer aggressive outgoing-interface
ethernet0/0 preshare juniper2 sec-level basic
set vpn vpn1 gateway branch1 sec-level basic

set vpn vpn2 gateway branch2 sec-level basic
set zone trust asymmetric-vpn
5. Configurar ruta
set vrouter trust-vr route 0.0.0.0/0 interface ethernet 0/0 gateway 2.2.2.250
6. Configurar directiva
set policy from untrust to trust branch servers vpn-srv permit
save

Configuración de una interfaz de respaldo de supervisión de rutas

En este ejemplo, en la interfaz principal (ethernet0/0) configurará una ruta al
segmento de la red 5.5.5.0/24 por medio de la puerta de enlace 10.10.10.1; además
configurará dialer1 como la interfaz de respaldo, con una ruta al mismo segmento
de red. Luego configurará una ruta predeterminada para la interfaz principal a la
misma puerta de enlace (10.10.10.1) y una ruta predeterminada para la interfaz
dialer1.
WebUI
Network > Routing > Destination > trust-vr > New: Introduzca los siguientes
Interface: (seleccione) ethernet0/0
Network > Interfaces > Backup: Introduzca los siguientes datos y haga clic
en Apply:
Primary Interface: (seleccione) ethernet0/0

Backup Interface: (seleccione), dialup1
Type: (seleccione) route vrouter: (seleccione) trust-vr
2. Configurar ruta
Network > Routing > Source Interface (para ethernet0/0) > New: Introduzca
los siguientes datos y haga clic en OK:
Gateway: 10.10.10.1
Network > Routing > Destination (para trust-vr) > New: Introduzca los
interface (seleccione): Null
CLI
set vrouter trust-vr route 5.5.5.0/24 interface ethernet0/0 gateway 10.10.10.1
set interface ethernet0/0 backup interface dialer1 type route vrouter trust-vr
5.5.5.0/24
set route 0.0.0.0/0 interface ethernet0/0 gateway 10.10.10.1
set route 0.0.0.0/0 interface dialer1
save

Interfaces de bucle invertido (o “loopback”)

Una interfaz de bucle invertido (loopback) es una interfaz lógica que emula una
interfaz física en el dispositivo de seguridad. Sin embargo, a diferencia de una
interfaz física, una interfaz de bucle invertido está siempre en línea mientras el
dispositivo en el que reside esté en línea. Las interfaces de bucle invertido se
denominan loopback. donde núm_id, donde núm_id es un número mayor o igual a
1 y denota una interfaz única de bucle invertido en el dispositivo. Como en una
interfaz física, se debe asignar una dirección IP a una interfaz de bucle invertido y
asociarla a una zona de seguridad.
NOTA: El valor máximo de núm_id que se puede especificar depende de cada plataforma.
Después de definir una interfaz de bucle invertido, puede definir otras interfaces
como miembros de su grupo. El tráfico puede alcanzar una interfaz de bucle
invertido si llega a través de una de las interfaces de su grupo. Cualquier tipo de
interfaz puede ser miembro de un grupo de interfaces de bucle invertido: interfaz
física, subinterfaz, interfaz de túnel, interfaz redundante o VSI.
Después de crear una interfaz de bucle invertido, puede utilizarla igual que una
interfaz física:
Configuración de la interfaz de bucle invertido para la administración
Configuración de BGP en una interfaz de bucle invertido
Configuración de VSI en una interfaz de bucle invertido
Configuración de la interfaz de bucle invertido como interfaz de origen
NOTA: No puede asociar una interfaz de bucle invertido a una zona HA ni configurar una
interfaz de bucle invertido para el funcionamiento de la capa 2, ni como interfaz
redundante o agregada. En interfaces de bucle invertido no se pueden configurar
las siguientes características: NTP, DNS, VIP, IP secundaria, seguimiento de IP
o WebAuth.
Cuando una interfaz de bucle invertido se utiliza como interfaz de salida en una
configuración VPN, la interfaz de bucle invertido debe estar en la misma zona que
la interfaz física de salida.
Puede definir una MIP en una interfaz de bucle invertido. Esto permite que la MIP
sea accesible por un grupo de interfaces; esta capacidad es exclusiva de las
interfaces de bucle invertido. Para obtener más información sobre cómo usar la
interfaz de bucle invertido con MIPs, consulte “MIP y la interfaz de bucle invertido”
en la página 8-74.
Puede administrar el dispositivo de seguridad utilizando la dirección IP de una

interfaz de bucle invertido o la dirección IP de administración que asignó a una
interfaz de bucle invertido.
Interfaces de bucle invertido (o “loopback”) 57

Creación de una interfaz de bucle invertido

En el ejemplo siguiente creará la interfaz loopback.1, la asociará a la zona Untrust
y le asignará la dirección IP 1.1.1.27/24.
WebUI
Network > Interfaces > New Loopback IF: Introduzca los siguientes datos
y haga clic en OK:
Interface Name: loopback.1

Zone: Untrust (seleccione)
CLI
set interface loopback.1 zone untrust
set interface loopback.1 ip 1.1.1.27
save
NOTA: La interfaz de bucle invertido no es directamente accesible desde redes o hosts

que residen en otras zonas. Debe definir una directiva para permitir tráfico desde
y hacia la interfaz.
Configuración de la interfaz de bucle invertido para la administración

En el ejemplo siguiente, configurará la interfaz loopback.1, definida anteriormente
como interfaz de administración para el dispositivo.
WebUI
Network > Interfaces > loopback.1 > Edit: Seleccione todas las opciones de
administración y haga clic en OK.
CLI
set interface loopback.1 manage
save
Configuración de BGP en una interfaz de bucle invertido

La interfaz de bucle invertido admite el protocolo de enrutamiento dinámico BGP
en el dispositivo de seguridad. En el ejemplo siguiente habilitará BGP en la interfaz
loopback.1.
NOTA: Para habilitar BGP en la interfaz de bucle invertido, primero debe crear una
instancia de BGP para el enrutador virtual al que planea asociar la interfaz. Para
obtener más información sobre cómo configurar BGP en dispositivos de seguridad
de Juniper Networks, consulte el Volumen 7: Enrutamiento.
WebUI
Network > Interfaces > loopback.1 > Edit: Seleccione Protocol BGP y haga
clic en OK.
58 Interfaces de bucle invertido (o “loopback”)

CLI
set interface loopback.1 protocol bgp
save
Configuración de VSI en una interfaz de bucle invertido

Puede configurar las interfaces de seguridad virtuales (VSIs) para NSRP en una
interfaz de bucle invertido. El estado físico de la VSI en la interfaz de bucle invertido
está siempre en línea. La interfaz puede estar activa o no, dependiendo del estado
del grupo VSD al que pertenece.
WebUI
Network > Interfaces > New VSI IF: Introduzca los siguientes datos y haga clic
en OK:
Interface Name: VSI Base: loopback.1

VSD Group: 1
CLI
set interface loopback.1:1 ip 1.1.1.1/24
save
Configuración de la interfaz de bucle invertido como interfaz de origen

Puede utilizar una interfaz de bucle invertido como interfaz de origen para
determinado tráfico originado en el dispositivo de seguridad. (Cuando se define una
interfaz de origen para una aplicación, se utiliza la dirección de la interfaz de origen
especificada en lugar de la dirección de la interfaz saliente para comunicarse con un
dispositivo externo). En el ejemplo siguiente, especificará que el dispositivo de
seguridad utiliza la interfaz loopback.1, definida anteriormente, para enviar
paquetes de syslog.
WebUI
Configuration > Report Settings > Syslog: Introduzca los siguientes datos
y haga clic en Apply:
Enable Syslog Messages: (seleccione)

Source interface: loopback.1 (seleccione)
Syslog Servers:
No.: 1 (seleccione)
IP/Hostname: 10.1.1.1
Traffic Log: (seleccione)
Event Log: (seleccione)
CLI
set syslog config 10.1.1.1 log all
set syslog src-interface loopback.1
set syslog enable
save
Interfaces de bucle invertido (o “loopback”) 59

Cambios de estado de la interfaz

Una interfaz puede estar en uno de los estados descritos en Tabla 5:
Tabla 5: Estados de interfaz
Estado Descripción
Físicamente en Para interfaces Ethernet físicas que operan en la capa 2 (modo transparente)
línea o en la capa 3 (moto de rutas) en el modelo de interconexión de sistemas
abiertos (“Open Systems Interconnection” u OSI). Una interfaz está
físicamente en línea cuando está cableada a otro dispositivo de red y puede
establecer un enlace a ese dispositivo.
Lógicamente en Tanto para interfaces físicas como para interfaces lógicas (subinterfaces,
línea interfaces redundantes e interfaces agregadas). Una interfaz está
lógicamente en línea cuando el tráfico que la atraviesa puede alcanzar los
dispositivos especificados (en las direcciones IP supervisadas) de una red.
Físicamente fuera Una interfaz está físicamente fuera de línea cuando no está cableada a otro
de línea dispositivo de la red o cuando, aún estando cableada, no puede establecer
un enlace. También puede forzar que una interfaz esté físicamente fuera de
línea ejecutando el comando CLI siguiente: set interface interface phy
link-down.
Lógicamente fuera Una interfaz está lógicamente fuera de línea cuando el tráfico que la
de línea atraviesa no puede alcanzar los dispositivos especificados (en las direcciones
IP marcadas) de una red.
El estado físico de una interfaz tiene prioridad sobre su estado lógico. Una interfaz
puede estar físicamente en línea y, al mismo tiempo, lógicamente en línea o fuera
de línea. Cuando una interfaz está físicamente fuera de línea, su estado lógico es
irrelevante.
Cuando el estado de una interfaz es en línea, todas las rutas que utilizan esa interfaz
permanecen activas y utilizables. Cuando el estado de una interfaz es fuera de línea,
el dispositivo de seguridad desactiva todas las rutas que utilizan esa interfaz
aunque, dependiendo de si la interfaz está físicamente o lógicamente fuera de
línea, el tráfico podría seguir atravesando una interfaz fuera de línea (consulte
“Interfaces fuera de línea y flujo de tráfico” en la página 73). Para compensar la
pérdida de rutas que implica la pérdida de una interfaz, puede configurar rutas
alternativas utilizando una interfaz alternativa.
Dependiendo de la acción configurada para ejecutarse al detectar un cambio de

estado en una interfaz supervisada, el cambio del estado en línea a fuera de línea
en una interfaz supervisada puede hacer que la interfaz supervisora cambie su
estado de fuera de línea a en línea. Para configurar este comportamiento, puede
utilizar el siguiente comando CLI:
set interface interfaz monitor threshold número action up { logically | physically }
Al introducir este comando, el dispositivo de seguridad fuerza automáticamente la

interfaz de supervisión al estado de fuera de línea. Si el objeto supervisado
(dirección IP, interfaz o zona supervisada) falla, el estado de la interfaz supervisora
queda en línea (lógica o físicamente, dependiendo de su configuración).
60 Cambios de estado de la interfaz

Una interfaz puede supervisar objetos en cuanto al menos uno de los eventos
siguientes. Consulte la Figura 21 en la página 61. Cada uno de estos eventos,
individual o combinado, puede provocar que el estado de la interfaz supervisora
cambie de en línea a fuera de línea o viceversa:
Desconexión/reconexión física
Fallo/éxito del seguimiento de IP
Fallo/éxito de una interfaz supervisada
Fallo/éxito de una zona de seguridad supervisada
Figura 21: Supervisión del estado de la interfaz

Si_un objeto supervisado falla… ...y el peso de ese objeto para el
umbral de fallos de supervisión…
Desconexión
física
...y la acción se establece como poner fuera de

La interfaz se desconecta. línea…
Fallo del
seguimiento
de IP ...entonces la interfaz de supervisión
queda fuera de línea.
Ninguna respuesta a las peticiones de eco ICMP.
Fallo de la interfaz
supervisada
Interfaz
supervisora
Los fallos de seguimiento de IP exceden
el umbral.
Zona de seguridad
Fallo de la zona
supervisada
Todas las interfaces de la misma zona se quedan fuera de línea.
Si, después de fallar, un objeto supervisado tiene éxito (la interfaz se reconecta o el
seguimiento de IP vuelve a tener éxito), la interfaz supervisora vuelve a activarse.
Existe un retraso de un segundo aproximadamente entre la supervisióni del objeto
y la reactivación de la interfaz de supervisión.
Cada uno de los eventos antedichos se presenta en las secciones siguientes.
Cambios de estado de la interfaz 61

Supervisión de la conexión física

Las interfaces físicas de un dispositivo de seguridad supervisan el estado de su
conexión física en otros dispositivos de la red. Cuando una interfaz está conectada
a otro dispositivo de la red y ha establecido un enlace con él, su estado es
físicamente en línea y todas las rutas que utiliza esa interfaz están activas.
Puede ver el estado de una interfaz en la columna “State” del resultado del
comando get interface y en la columna “Link” de la página “Network > Interfaces”
de WebUI. Puede estar en línea ("up") o fuera de línea (“down”).
Puede ver el estado de una ruta en el campo de estado del comando get route id
número y en la página “Network > Routing > Destination” de WebUI. Un asterisco
indica que la ruta está activa. Si no hay asterisco, está inactiva.
Seguimiento de direcciones IP
El dispositivo de seguridad puede realizar un seguimiento de direcciones IP
específicas a través de una interfaz, de forma que cuando una o varias de ellas
queden inaccesibles, el dispositivo de seguridad pueda desactivar todas las rutas
asociadas a esa interfaz, aunque la conexión física siga activa. Una ruta desactivada
se vuelve a activar después de que el dispositivo de seguridad retoma el contacto
con esas direcciones IP.
NOTA: En ciertos dispositivos con ScreenOS, esta acción también hace que se conmute
por error a la interfaz de respaldo asociada a la misma zona que la interfaz en la
que se configuró el seguimiento de IP (consulte “Cambio en caso de fallo de
interfaces con seguimiento de IP” en la página 11-51).
ScreenOS utiliza una supervisión de rutas de capa 3 o seguimiento de IP, similar a la

utilizada con NSRP para supervisar la accesibilidad de direcciones IP específicas
a través de una interfaz. Por ejemplo, si una interfaz se conecta directamente a un
enrutador, es posible hacer un seguimiento de la dirección de salto siguiente en la
interfaz para determinar si el enrutador sigue estando accesible. Al configurar el
seguimiento de IP en una interfaz, el dispositivo de seguridad envía peticiones de
comando ping a través de la interfaz a un máximo de cuatro direcciones IP de
destino en intervalos definidos por el usuario. El dispositivo de seguridad supervisa
estos objetivos para determinar si se recibe una respuesta. Si no se recibe respuesta
de un destino durante un número específico de veces, dicha dirección IP se
considera inaccesible. Si no se obtiene respuesta de uno o más destinos, es posible
que el dispositivo de seguridad desactive las rutas asociadas a dicha interfaz. Si hay
disponible otra ruta que conduzca al mismo destino, el dispositivo de seguridad
desvía el tráfico para utilizar la nueva ruta.
Puede definir el seguimiento de IP en las siguientes interfaces para las que haya
configurado una dirección IP de administración:
Interfaz física asociada a una zona de seguridad (no las zonas funcionales HA
o MGT)
NOTA: La interfaz puede operar en la capa 2 (modo transparente) o en la capa 3 (moto de

rutas).

Subinterfaz
Interfaz redundante
Interfaz agregada
NOTA: Aunque la interfaz puede ser una interfaz redundante o una interfaz agregada, no
puede ser un miembro de una interfaz redundante o agregada.
En los dispositivos que admiten sistemas virtuales, la interfaz en la que se

establezca el seguimiento de IP puede pertenecer al sistema raíz o a un sistema
virtual (vsys). Sin embargo, en una interfaz compartida el seguimiento de IP sólo se
puede establecer en el nivel raíz.
NOTA: Desde un vsys, puede establecer la supervisión de una interfaz compartida desde
una interfaz que pertenezca al vsys. Sin embargo, desde dentro del vsys no se
puede establecer la supervisión de interfaces desde una interfaz compartida. Para
obtener más información, consulte “Supervisión de interfaces” en la página 67.
Para cada interfaz, puede configurar el seguimiento de hasta cuatro direcciones IP

por parte del dispositivo de seguridad. En un mismo dispositivo, se pueden
configurar hasta 64 direcciones IP de seguimiento. En esta suma se incluyen todas
las direcciones IP de seguimiento, independientemente de si se utilizan para el
seguimiento de IP basado en interfaz, para el seguimiento de IP basado en NSRP, en
el nivel raíz o en el nivel vsys.
Las direcciones IP de seguimiento no tienen por qué estar en la misma subred que
la interfaz. Por cada dirección IP que desee someter a seguimiento, se puede
especificar lo siguiente:
Intervalo, en segundos, transcurrido el cual se enviarán las peticiones de eco

a la dirección IP especificada.
Número de intentos de petición de eco consecutivos sin éxito antes de que se

considere que la conexión con la dirección IP ha fallado.
Peso de la conexión IP fallida (una vez que la suma de pesos de todas las
conexiones IP fallidas supera un umbral determinado, se desactivan las rutas
asociadas a la interfaz).
También puede configurar el dispositivo de seguridad para supervisar la puerta de

enlace predeterminada de una interfaz que sea un cliente PPPoE o DHCP. Para ello,
utilice la opción “Dynamic”: (CLI) set interface interfaz monitor dynamic o bien
(WebUI) Network > Interfaces > Edit (para la interfaz cliente DHCP o PPPoE) >
Monitor > Track IP > Add: Seleccione Dynamic.
NOTA: Cuando se configura el dispositivo de seguridad para que realice un seguimiento

de una dirección IP, el dispositivo de seguridad no agrega ninguna ruta de host
para dicha dirección IP en la tabla de enrutamiento.

Pueden establecerse dos tipos de umbrales en la configuración del seguimiento de

direcciones IP:
Umbral de fallos de una determinada dirección IP supervisada: Número de

intentos fallidos consecutivos por obtener respuesta a una petición de eco
(“ping”) de una determinada dirección IP que deben producirse para que se
considere un fallo de acceso a esa dirección. Si no se supera el umbral, el nivel
de conectividad con la dirección será aceptable; si se supera, el nivel de
conectividad será inaceptable. Este umbral se establece para cada dirección IP
con un valor entre 1 y 200. El valor predeterminado es 3.
Umbral de fallos de seguimiento de IP en la interfaz: Peso total de los intentos

fallidos acumulados por acceder a direcciones IP de la interfaz que causa la
desactivación de las rutas asociadas a dicha interfaz. Este umbral se puede
ajustar en cualquier valor entre 1 y 255. El valor predeterminado es 1, lo que
significa que cualquier fallo producido al intentar acceder a una dirección IP
configurada y supervisada provoca la desactivación de las rutas asociadas a la
interfaz.
Si se aplica un peso (o valor) a una dirección IP supervisada, se puede ajustar la

importancia de la conectividad de esa dirección en relación con el acceso a otras
direcciones supervisadas. Puede asignar pesos relativamente mayores a direcciones
relativamente más importantes, y pesos menores a direcciones menos importantes.
Observe que los pesos asignados sólo tienen relevancia cuando se alcanza el
umbral de fallos de una dirección IP específica supervisada. Por ejemplo, si el
umbral de fallos para el seguimiento de IP en una interfaz es 3, el fallo de una única
dirección IP sometida a seguimiento con un peso de 3 completa el umbral de fallos
para el seguimiento de IP en la interfaz, lo que hace que se desactiven las rutas
asociadas a la interfaz. El fallo de una única dirección IP sometida a seguimiento
con un peso de 1 no completaría el umbral de fallos para el seguimiento de IP en la
interfaz, por lo que las rutas asociadas a la interfaz seguirían activas.
En el ejemplo siguiente, la interfaz ethernet0/1 está asociada a la zona Trust y tiene

asignada la dirección de red 10.1.1.1/24. Las interfaces ethernet0/3 y ethernet0/4
están asociadas a la zona Untrust. La interfaz ethernet0/3 tiene asignada la
dirección de red 1.1.1.1/24 y está conectada al enrutador en 1.1.1.250. La interfaz
ethernet0/4 tiene asignada la dirección de red 2.2.2.1/24 y está conectada al
enrutador en 2.2.2.250. Consulte la Figura 22.
Figura 22: Seguimiento de IP de interfaz

Enrutador 1.1.1.250
ethernet0/1
10.1.1.1/24 ethernet0/3 1.1.1.1/24
Zona Trust Zona Untrust
10.1.1.0/24 Internet
ethernet0/4 2.2.2.1/24
Enrutador 2.2.2.250

Hay dos rutas predeterminadas configuradas: en una se utiliza ethernet0/3 como

interfaz de salida con la dirección de enrutador 1.1.1.250 como puerta de enlace;
en la otra (configurada con un valor métrico de 10) se utiliza ethernet0/4 como
interfaz de salida con la dirección de enrutador 2.2.2.250 como puerta de enlace. La
ruta predeterminada en la que se utiliza ethernet0/3 es la ruta preferente, puesto
que tiene un valor métrico inferior (el valor métrico predeterminado para rutas
estáticas es 1). El siguiente resultado del comando get route indica cuatro rutas
activas para trust-vr (las rutas activas se señalan con un asterisco). La ruta
predeterminada que pasa por ethernet0/3 está activa; la ruta predeterminada que
pasa por ethernet4 no está activa, puesto que tiene menos prioridad.
Figura 23: Resultado de Get Route

device-> get route
untrust-vr (0 entries)
------------------------------------------------------------------------
C - Connected, S - Static, A - Auto-Exported, I - Imported, R - RIP
iB - IBGP, eB - EBGP, O - OSPF, E1 - OSPF external type 1
E2 - OSPF external type 2
trust-vr (4 entries)
------------------------------------------------------------------------
ID IP-Prefix InterfaceGateway P Pref Mtr Vsys
------------------------------------------------------------------------
* 4 0.0.0.0/0 eth0/3 1.1.1.250 S 20 1 Root
* 2 1.1.1.0/24 eth0/3 0.0.0.0 C 0 0 Root
3 0.0.0.0/0 eth0/4 2.2.2.250 S 20 10 Root
* 6 2.2.2.0/24 eth0/4 0.0.0.0 C 0 1 Root
* 5 10.1.1.0/24 eth0/1 0.0.0.0 C 20 1 Root
Si no está disponible la ruta a través de ethernet0/3, se activa la ruta

predeterminada a través de ethernet0/4. Active y configure el seguimiento de IP en
la interfaz ethernet0/3 para supervisar la dirección de enrutador 1.1.1.250. Si falla
el seguimiento de IP al acceder a 1.1.1.250, todas las rutas asociadas a la interfaz
ethernet0/3 pasan a ser inactivas en el dispositivo de seguridad. En consecuencia,
la ruta predeterminada que atraviesa ethernet0/4 se convierte en activa. Cuando el
seguimiento IP pueda acceder a 1.1.1.250 de nuevo, la ruta predeterminada que
pasa por ethernet0/3 se convertirá en la ruta activa y, al mismo tiempo, la ruta
predeterminada que atraviesa ethernet0/4 pasará a estado inactivo, ya que tiene un
nivel de prioridad menor que la ruta que pasa por ethernet0/3.
Con los siguientes ajustes se activa el seguimiento de IP con un umbral de fallos de

interfaz de 5 y se configura el seguimiento de IP en la interfaz ethernet0/3 para
supervisar la dirección IP de enrutador 1.1.1.250, que tiene asignado un peso
de 10.
WebUI
Network > Interfaces > Edit (para ethernet0/3) > Monitor: Introduzca los
siguientes datos y haga clic en Apply:
Enable Track IP: (seleccione)

Threshold: 5
> Monitor Track IP ADD: Introduzca los siguientes datos y haga clic en Add:
Static: (seleccione)
Track IP: 1.1.1.250
Weight: 10

CLI
set interface ethernet0/3 monitor track-ip ip 1.1.1.250 weight 10
set interface ethernet0/3 monitor track-ip threshold 5
set interface ethernet0/3 monitor track-ip
save
En este ejemplo, el umbral de fallos para la dirección de destino está ajustado al

valor predeterminado (3). Es decir, si el destino no devuelve una respuesta a tres
peticiones de eco consecutivas, se aplica un peso de 10 al umbral de fallos para el
seguimiento de IP en la interfaz. Como el umbral de error para el seguimiento de IP
en la interfaz es 5, un peso de 10 hace que se desactiven las rutas asociadas a la
interfaz en el dispositivo de seguridad.
Puede verificar el estado del seguimiento de IP en la interfaz introduciendo el

comando CLI get interface ethernet0/3 track-ip tal como se muestra en la
Figura 24.
Figura 24: Resultado de Get Interface

device-> get interface ethernet0/3 track-ip
ip address interval threshold wei gateway fail-count success-rate
1.1.1.250 1 1 10 0.0.0.0 343 46%
threshold: 5, failed: 1 ip(s) failed, weighted sum = 10
El comando get route indica que la ruta predeterminada que atraviesa ethernet0/4
está activa en estos momentos; todas las rutas que pasan por ethernet0/3 han
dejado de estar activas.
Figura 25: Resultado de Get Route con interfaces activas

device-> get route
untrust-vr (0 entries)
----------------------------------------------------------------------
C - Connected, S - Static, A - Auto-Exported, I - Imported, R - RIP
iB - IBGP, eB - EBGP, O - OSPF, E1 - OSPF external type 1
E2 - OSPF external type 2
trust-vr (4 entries)
----------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
----------------------------------------------------------------------
4 0.0.0.0/0 eth0/3 1.1.1.250 S 20 1 Root
2 1.1.1.0/24 eth0/3 0.0.0.0 C 0 0 Root
* 3 0.0.0.0/0 eth0/4 2.2.2.250 S 20 10 Root
* 6 2.2.2.0/24 eth0/4 0.0.0.0 C 0 1 Root
* 5 10.1.1.0/24 eth0/1 0.0.0.0 C 20 1 Root

Recuerde que aunque las rutas que pasan por ethernet0/3 no estén activas, el
seguimiento de IP utiliza las rutas asociadas a ethernet0/3 para continuar enviando
peticiones de eco a la dirección IP de destino. Cuando el seguimiento de IP puede
acceder de nuevo a 1.1.1.250, la ruta predeterminada que atraviesa ethernet0/3 se
vuelve a convertir en la ruta activa del dispositivo de seguridad. Al mismo tiempo,
la ruta predeterminada que pasa por ethernet0/4 se convierte en ruta inactiva, ya
que su nivel de prioridad es inferior al de la ruta predeterminada que pasa por
ethernet0/3.
Supervisión de interfaces
Un dispositivo de seguridad puede supervisar el estado físico y lógico de las
interfaces y ejecutar una determinada acción en función de los cambios
observados, consulte la Figura 26. Por ejemplo, si el estado de una interfaz
supervisada cambia de en línea a fuera de línea, puede ocurrir lo siguiente, como se
muestra en la Tabla 6.
Tabla 6: Interfaz supervisada
Si: Después:
El estado físico de una El cambio de estado puede provocar que también quede fuera de
interfaz cambia de en línea otra interfaz que esté supervisando a la que acaba de quedar
línea a fuera de línea fuera de línea. Puede especificar si la segunda interfaz debe quedar
física o lógicamente fuera de línea.
El cambio de estado de la interfaz que se está poniendo fuera de línea
físicamente, o el peso combinado de ambas interfaces
desactivándose físicamente juntas, puede desencadenar un fallo de
NSRP. Un cambio en caso de error del dispositivo NSRP o del grupo
VSD sólo se puede producir como resultado de un cambio en el
estado físico de una interfaz.
El estado lógico de una El cambio de estado puede provocar que también quede fuera de
interfaz cambia de en línea otra interfaz que esté supervisando a la que acaba de quedar
línea a fuera de línea fuera de línea. Aunque la primera interfaz esté lógicamente inactiva,
como resultado de un puede especificar si el estado fuera de línea de la segunda interfaz
fallo en el seguimiento debe ser lógico o físico.
de IP
Figura 26: Supervisión de la interfaz de Ethernet0/1 y Ethernet0/2

Una interfaz supervisando a otra interfaz
Utilizando el seguimiento de IP,

ethernet0/3 supervisa al
enrutador en 1.1.1.250.
Uso de la supervisión de interfaz,
ethernet0/2 supervisa
ethernet0/3.
ethernet0/3 ethernet0/2
IP 1.1.1.1 IP 2.1.1.1

Para establecer la supervisión de interfaces, ejecute cualquiera de los siguientes

procedimientos:
WebUI
Network > Interfaces > Edit (para la interfaz que desee supervisar) > Monitor
> Edit Interface: Introduzca los siguientes datos y haga clic en Apply:
Interface Name: Seleccione la interfaz que desea que sea supervisada.

Weight: Indique un peso entre 1 y 255.
CLI
set interface interfaz1 monitor interface interfaz2 [ weight number ]
save
Si no se indica un peso, el dispositivo de seguridad aplica el valor

predeterminado, 255.
Cuando dos interfaces se supervisan mutuamente, forman un bucle. En este caso, si

cualquiera de las interfaces cambia de estado, la otra interfaz del bucle también lo
hace. Consulte la Figura 27 en la página 68.
NOTA: Una interfaz sólo puede pertenecer a un único bucle. No se admiten

configuraciones en las que una interfaz pertenezca a varios bucles.
Figura 27: Supervisión de bucle

El primer estado cambia si: El segundo estado cambia si:
Bucle - Dos interfaces supervisándose mutuamente
• El número de intentos fallidos del • El peso del fallo de la primera
Utilizando el seguimiento de IP, ambas comando ping a cualquiera de los interfaz es mayor que o igual al del
interfaces supervisan enrutadores. enrutadores excede el umbral de umbral de error de supervisión de la
error de esa dirección IP segunda interfaz.
supervisada.
Utilizando la supervisión de interfaces,
también se supervisan mutuamente. • La acción en caso de error es
• El peso del seguimiento de IP cambiar de en línea a fuera de línea.
fallido es mayor que o igual al del
umbral de error del objeto de
seguimiento.
• El peso del objeto de seguimiento Después:

es mayor que o igual al del umbral de
error de supervisión. La segunda interfaz también cambia
su estado de en línea a fuera de línea.
• La acción en caso de error es
cambiar de en línea a fuera de línea.
IP 1.1.1.1 IP 2.1.1.1 Después:
La segunda interfaz también cambia su

estado de en línea a fuera de línea.
Supervisión de dos interfaces

En este ejemplo, usted configura ethernet0/3 para supervisar dos interfaces,
ethernet0/1 y ethernet0/2. Debido a que el peso de cada interfaz supervisada
(8 + 8) es igual al umbral de fallo de supervisión (16), tanto ethernet0/1 como
ethernet0/2 deben fallar (y cambiar su estado de en línea a fuera de línea)
simultáneamente para que falle ethernet0/3 (y cambie su estado de en línea a fuera
de línea). Consulte la Figura 28.

NOTA: Este ejemplo omite la configuración del seguimiento de IP en las interfaces

ethernet0/1 y ethernet0/2 (consulte “Seguimiento de direcciones IP” en la
página 62). Sin seguimiento de IP, la única manera de que ethernet0/1
y ethernet0/2 puedan fallar es que sean desconectadas físicamente de otros
dispositivos de la red o que no puedan mantener enlaces con esos dispositivos.
Si se establece el umbral de error de supervisión en 8 o se deja en 16 y se

establece el peso de cada interfaz supervisada en 16, el fallo de ethernet0/1 o de
ethernet0/2 puede hacer fallar a ethernet0/3.
Figura 28: Supervisión de interfaces de dos bucles

ethernet0/3 supervisa ethernet0/1 y ethernet0/2. Dado que el umbral de fallos
de supervisión (F-T) = los pesos (W) de ambas interfaces combinadas, para
hacer fallar a ethernet0/3 deben fallar las dos interfaces supervisadas.
Interfaces de dispositivo de
seguridad
ethernet0/1 – ethernet0/8 1 2 3 4 5 6 7 8
W=8 W=8 F-T: 16
Interfaces supervisadas:
ethernet0/1, peso 8
ethernet0/2, peso 8
Umbral de fallos de supervisión: 16
WebUI
Network > Interfaces > Edit (para ethernet0/3) > Monitor > Edit Interface:
Introduzca los siguientes datos y haga clic en Apply:
ethernet0/1: (seleccione), Weight: 8

Network > Interfaces > Edit (para ethernet0/3) > Monitor: Introduzca 16 en el
campo “Monitor Threshold”, luego haga clic en Apply.
CLI
set interface ethernet0/3 monitor interface ethernet0/1 weight 8
set interface ethernet0/3 monitor threshold 16
save
Supervisión de un bucle de interfaces

En este ejemplo, primero configure el seguimiento de IP para dos interfaces,
ethernet0/1 y ethernet0/3. Luego configure estas interfaces para supervisarse entre
sí de manera que si una cambia su estado, la otra cambie también. Por último,
definirá dos conjuntos de rutas. El primer conjunto reenvía el tráfico a través de
ethernet0/1 y ethernet0/3. El segundo conjunto tiene las mismas direcciones de
destino, pero estas rutas tienen métricas de menor rango y utilizan otras interfaces
de salida (ethernet0/2 y ethernet0/4) y otras puertas de enlace que el primer
conjunto. Con esta configuración, si el primer conjunto de interfaces falla, el
dispositivo de seguridad puede redirigir todo el tráfico a través del segundo
conjunto. Todas las zonas se encuentran en el dominio de enrutamiento trust-vr.

Figura 29: Supervisión de bucle de cuatro interfaces

A los hosts de la ethernet0/1 y ethernet0/3 realizan el seguimiento de
zona Trust A Internet IP. Ethernet0/1 supervisa al enrutador interno en
10.1.1.250. ethernet0/3 supervisa al enrutador
Enrutador interno externo en 1.1.1.250.
Enrutador externo
10.1.1.250 1.1.1.250
10.1.2.250 Umbral de fallos de la IP supervisada: 10
1.1.2.250 Peso de la IP supervisada: 8
Peso del objeto supervisado: 8
Zona Umbral de fallos de supervisión: 8
Zona Trust Zona Trust Untrust Zona Untrust
10.1.1.1/24 10.1.2.1/24 1.1.1.1/24 1.1.2.1/24
Interfaces de dispositivo de
seguridad
ethernet0/1 – ethernet0/8
1 2 3 4 5 6 7 8
ethernet0/1 y ethernet0/3 Si ethernet0/1 y ethernet0/3 quedan fuera de línea, las rutas que se refieren a
se supervisan entre sí. esas interfaces también quedan inactivas. Entonces, el dispositivo de
Dado que el peso de la Bucle de interfaz supervisora: seguridad redirige el tráfico a través de ethernet0/2 y ethernet0/4.
interfaz supervisada es
igual al umbral de error de ethernet0/1 y ethernet0/3
supervisión, el error de Rutas
cualquier interfaz hace que Peso de la interfaz supervisada: 8
la otra falle también. Umbral de fallos de supervisión: 8 set route 10.1.0.0/16 interface ethernet0/1 gateway 10.1.1.250 metric 10
set route 10.1.0.0/16 interface ethernet0/2 gateway 10.1.2.250 metric 12
WebUI
1. Seguimiento de IP
siguientes datos y haga clic en Apply.

Monitor Threshold: 8
Track IP Option: Threshold: 8
Weight: 8
NOTA: Para controlar si el estado de una interfaz se vuelve lógica o físicamente fuera de
línea (o en línea), debe utilizar el comando CLI set interface interfaz monitor
threshold número action { down | up } { logically | physically }. Sólo se pueden
poner en línea o fuera de línea físicamente las interfaces físicas asociadas a
cualquier zona de seguridad distinta de la zona Null.
> Monitor Track IP ADD: Introduzca los siguientes datos y haga clic
en Add:
Track IP: 10.1.1.250
Weight: 8
Interval: 3 Seconds
Threshold: 10
siguientes datos y haga clic en Apply.

Monitor Threshold: 8
Track IP Option: Threshold: 8
Weight: 8

> Monitor Track IP ADD: Introduzca los siguientes datos y haga clic
en Add:
Track IP: 1.1.1.250
Weight: 8
Interval: 3 Seconds
Threshold: 10
2. Supervisión de interfaces

3. Rutas
Network > Routing > Destination > trust-vr New: Introduzca los siguientes

Metric: 10

Metric: 12

Metric: 10

Metric: 12

CLI
1. Seguimiento de IP
set interface ethernet0/1 track-ip ip 10.1.1.250 weight 8
set interface ethernet0/1 track-ip threshold 8
set interface ethernet0/1 track-ip weight 8
set interface ethernet0/1 track-ip
set interface ethernet0/3 track-ip ip 1.1.1.250 weight 8
set interface ethernet0/3 track-ip threshold 8
set interface ethernet0/3 track-ip weight 8
set interface ethernet0/3 track-ip
2. Supervisión de interfaces
set interface ethernet0/1 monitor threshold 8 action down physically
set interface ethernet0/3 monitor threshold 8 action down physically
3. Rutas
metric 10
metric 12
metric 10
metric 12
save
Supervisión de zonas de seguridad

Además de supervisar interfaces individuales, una interfaz puede supervisar todas
las interfaces de una zona de seguridad (cualquier zona de seguridad salvo la suya
propia). Para que falle toda una zona de seguridad, debe fallar cada una de las
interfaces asociadas a esa zona. Mientras permanezca activa una sola interfaz
asociada a una zona supervisada, el dispositivo de seguridad considerará que toda
la zona está en línea.
Para configurar una interfaz de modo que supervise una zona de seguridad, ejecute
cualquiera de los siguientes procedimientos:
WebUI
Network > Interfaces > Edit (para la interfaz que desee supervisar) > Monitor
> Edit Zone: Introduzca los siguientes datos y haga clic en Apply:
Zone Name: Seleccione la zona que desee que sea supervisada.

Weight: Indique un peso entre 1 y 255.
CLI
set interface interfaz monitor zone zone [ weight número ]
Si no se indica un peso, el dispositivo de seguridad aplica el valor

predeterminado, 255.

Interfaces fuera de línea y flujo de tráfico

La configuración del seguimiento de IP en una interfaz permite al dispositivo de
seguridad redireccionar el tráfico saliente a través de una interfaz distinta cuando
determinadas direcciones IP dejan de ser accesibles a través de la primera interfaz.
Sin embargo, aunque es posible que el dispositivo de seguridad desactive las rutas
asociadas a una interfaz debido a un error en el seguimiento de IP, la interfaz puede
continuar físicamente en línea y seguir enviando y recibiendo tráfico. Por ejemplo,
el dispositivo de seguridad sigue procesando el tráfico entrante de una sesión
existente que puede llegar a la interfaz original en la que se haya producido el error
en el seguimiento de IP. Asimismo, el dispositivo de seguridad continúa utilizando
la interfaz para enviar peticiones del comando ping a las direcciones IP de destino
para determinar si los destinos son accesibles de nuevo. En estos casos, el tráfico
sigue atravesando una interfaz en la que ha fallado el seguimiento de IP y para la
que el dispositivo de seguridad ha desactivado las rutas.
El modo en el que el dispositivo de seguridad gestiona el tráfico de sesión en dicha

interfaz depende de los siguientes factores:
Si la interfaz en la que se configura el seguimiento de IP actúa como una

interfaz de salida para una sesión, es posible que las respuestas de la sesión
sigan llegando a la interfaz y que el dispositivo de seguridad continúe
procesándolas.
Si la interfaz en la que se configura el seguimiento de IP actúa como interfaz de

entrada para una sesión, la aplicación del comando set arp always-on-dest
hace que el dispositivo de seguridad redireccione las respuestas de la sesión
a otra interfaz. Si no se activa este comando, el dispositivo de seguridad
redireccionará las respuestas de la sesión a través de la interfaz en la que ha
fallado el seguimiento de IP aunque el dispositivo de seguridad haya
desactivado las rutas que utilizan dicha interfaz. (De forma predeterminada,
este comando está desactivado).
De forma predeterminada, un dispositivo de seguridad guarda en caché la

dirección MAC del iniciador de una sesión cuando recibe el paquete inicial de
una sesión nueva. Si se introduce el comando CLI set arp always-on-dest, el
dispositivo de seguridad no guardará en caché la dirección MAC del iniciador de
una sesión. En su lugar, el dispositivo de seguridad realizará una consulta ARP
cuando procese la respuesta correspondiente a dicho paquete inicial. Si la
dirección MAC del iniciador se encuentra en la tabla ARP, el dispositivo de
seguridad la utilizará. Si la dirección MAC no se encuentra en la tabla ARP, el
dispositivo de seguridad enviará una solicitud ARP para la dirección MAC de
destino y agregará la dirección MAC que reciba a su tabla ARP. El dispositivo de
seguridad realiza otra consulta ARP cada vez que se produce un cambio de ruta.
La sección “Error en la interfaz de salida” describe los diversos contextos en los que
falla el seguimiento de IP en la interfaz de salida y en la interfaz de entrada y, en el
caso de la última, qué ocurre cuando se utiliza el comando set arp always-on-dest.
NOTA: “Error en la interfaz de salida” describe cómo el seguimiento de IP activa los

cambios de enrutamiento y cómo esos cambios pueden afectar el flujo del
paquete a través de los dispositivos de seguridad de Juniper Networks.

Error en la interfaz de salida

En el siguiente contexto, configurará el seguimiento de IP en ethernet0/2, que es la
interfaz de salida para las sesiones del host “A” al host “B”. El host A inicia la sesión
enviando un paquete al host B, tal como se muestra en la Figura 30.
NOTA: Primero hay que crear dos rutas que conduzcan al Host B y ambas interfaces de
salida deben encontrarse en la misma zona para que se aplique la misma directiva
al tráfico antes y después del redireccionamiento.
Figura 30: Seguimiento de IP en Host A y Host B

Flujo de tráfico del host A al host B: solicitud (inicio de sesión)
Interfaz de entrada Primera interfaz de salida
ethernet0/1 ethernet0/2 1.1.1.1/24 Seguimiento de IP activado
10.1.1.1/24 desde ethernet0/2
2
Zona Untrust
Zona Trust Consulta de Consulta Consulta de
sesiones de rutas directivas
10.1.1.1/24 3 Host B
10.1.1.0/24
4
1
Host A Respondedor
10.1.1.5 Iniciador
Segunda interfaz de salida Puertas de

ethernet0/3 enlace: 1.1.1.254
1.1.2.1/24 1.1.2.254
Cuando el host B responde al host A, el tráfico de respuesta sigue una ruta de

regreso similar a través del dispositivo de seguridad, como se muestra en la
Figura 31.
Figura 31: Flujo de tráfico saliente del Host B al Host A

Flujo de tráfico del host A al host B: respuesta

ethernet0/1 ethernet0/2 Seguimiento de IP
10.1.1.1/24 1.1.1.1/24 desde ethernet0/2
correcto
3 Zona Untrust
Zona Trust Actualización
de sesiones
10.1.1.1/24
10.1.1.0/24
2 Host B
2.2.2.2
1
4
Host A
10.1.1.5 Iniciador Respondedor

ethernet0/3 enlace: 1.1.1.254
1.1.2.1/24 1.1.2.254

Si falla el seguimiento de IP en ethernet0/2, el dispositivo de seguridad desactiva las

rutas que utiliza ethernet0/2 y utiliza ethernet0/3 para el tráfico saliente destinado
al host B. Sin embargo, las respuestas del host B al host A pueden llegar tanto
a través de ethernet0/2 como a través de ethernet0/3 y el dispositivo de seguridad
las redirecciona a través de ethernet0/1 al host A. Consulte la Figura 32.
Figura 32: Fallo en el seguimiento de IP de salida

Flujo de tráfico del host B al host A: el fallo de seguimiento de IP dispara el redireccionamiento
Interfaz de entrada Primera interfaz de salida Seguimiento de IP desde
ethernet0/1 ethernet0/2 ethernet0/2 incorrecto
10.1.1.1/24 1.1.1.1/24
1
Zona Untrust
Zona Trust Cambio Actualización
de ruta de sesiones
10.1.1.1/24 3
10.1.1.0/24 4 Host B
2.2.2.2
2
Host A
10.1.1.5 Iniciador Respondedor
Puertas de
Segunda interfaz de salida enlace: 1.1.1.254
ethernet0/3 1.1.2.254
1.1.2.1/24
Fallo en la interfaz de entrada

En el siguiente contexto, configurará de nuevo el seguimiento de IP en ethernet0/2,
pero esta vez ethernet0/2 será la interfaz de entrada en el dispositivo de seguridad
para las sesiones del host B al host A. El host B iniciará la sesión enviando un
paquete al host A, tal como se muestra en la Figura 33.
Figura 33: Flujo de tráfico entrante del Host B al Host A

Flujo de tráfico del host B al host A: Solicitud (inicio de sesión)
ethernet0/1 ethernet0/2 Seguimiento de IP activado
10.1.1.1/24 1.1.1.1/24 desde ethernet0/2
2
Zona Untrust
Zona Trust Consulta de Consulta Consulta de
directivas de rutas sesiones
10.1.1.1/24 Host B
10.1.1.0/24
1 2.2.2.2
3
Host A
10.1.1.5 Respondedor Iniciador
Puertas de
enlace:
Segunda interfaz de salida 1.1.1.254
ethernet0/3 1.1.2.254
1.1.2.1/24

Cuando el host A responde al host B, el tráfico de respuesta sigue una ruta de

regreso similar a través del dispositivo de seguridad, como se muestra en la
Figura 34.
Figura 34: Flujo de tráfico entrante del Host A al Host B

Flujo de tráfico del host B al host A: respuesta
ethernet0/1 ethernet0/2 Seguimiento de IP
10.1.1.1/24 1.1.1.1/24 desde ethernet0/2
correcto
2
Zona Untrust
Zona Trust Consulta de
sesiones
10.1.1.1/24 3 Host B
10.1.1.0/24
4 2.2.2.2
1
Host A

ethernet0/3 enlace:
1.1.2.1/24 1.1.1.254
1.1.2.254
1. El host A en 10.1.1.5 envía un paquete de respuesta a ethernet0/1 en 10.1.1.1 destinado al host B (2.2.2.2).
2. El dispositivo de seguridad realiza una consulta de sesiones. Como se trata de una respuesta, el dispositivo de seguridad la
relaciona con una sesión existente y actualiza la entrada de la tabla de sesiones.
3. Utilizando la dirección MAC de la puerta de enlace en 1.1.1.254 guardada en caché o realizando una consulta ARP para averiguar la
dirección MAC, el dispositivo reenvía el paquete a través de ethernet0/2 a la puerta de enlace.
4. Cuando la puerta de enlace en 1.1.1.254 recibe la respuesta, la redirecciona al siguiente salto. El enrutamiento continúa hasta que el
host B recibe el paquete.
Si falla el seguimiento de IP en ethernet0/2, el dispositivo de seguridad desactiva las
rutas que utilicen ethernet0/2 y utiliza ethernet0/3 para el tráfico saliente destinado
al host B. Sin embargo, las peticiones del host B al host A pueden seguir llegando a
través de ethernet0/2, y el dispositivo de seguridad las reenvía a través de
ethernet0/1 al host A. El flujo de datos para las peticiones del host B al host A sigue
teniendo el mismo aspecto después de que se produzca un fallo de seguimiento de
IP. Sin embargo, las respuestas del host A pueden tomar una de dos rutas distintas,
dependiendo de la aplicación del comando set arp always-on-dest.
Si establece el comando set arp always-on-dest, el dispositivo de seguridad enviará

una petición ARP para la dirección MAC de destino cuando procese la respuesta al
primer paquete de una sesión o cuando se produzca un cambio de ruta. (Cuando
este comando está desactivado, el dispositivo de seguridad guarda el caché de la
dirección MAC del iniciador de la sesión y la utiliza para procesar las respuestas. De
forma predeterminada, este comando está desactivado).

Cuando falla el seguimiento de IP en ethernet0/2, el dispositivo de seguridad

desactiva primero todas las rutas que utilizan ethernet0/2 y luego realiza una
consulta de rutas. Encuentra otra ruta para acceder al host B a través de ethernet0/3
y la puerta de enlace en 1.1.2.254. A continuación, analiza la tabla de sesiones y
redirige todas las sesiones a la nueva ruta. Si se ha activado el comando set arp
always-on-dest, el dispositivo de seguridad realizará una consulta ARP cuando
reciba el siguiente paquete del host A porque el paquete pertenece a una sesión
afectada por el cambio de ruta. Independientemente de la interfaz de entrada a la
que lleguen los paquetes del host B, el dispositivo de seguridad envía todas las
respuestas siguientes del host A a través de ethernet0/3 a la puerta de enlace en
1.1.2.254. Consulte la Figura 35 en la página 77.
Figura 35: Fallo en el seguimiento de IP de ingreso con enrutamiento de tráfico

Flujo de tráfico del host B al host A: el fallo de seguimiento de IP dispara el redireccionamiento
Interfaz de entrada Primera interfaz de salida Seguimiento de IP

ethernet0/1 ethernet0/2 desde ethernet0/2
10.1.1.1/24 1.1.1.1/24 incorrecto
1 2
Zona Untrust
Zona Trust Cambio Actualización
de ruta de sesiones
10.1.1.1/24 Host B
10.1.1.0/24 2.2.2.2
3
Host A
Puertas de
enlace: 1.1.1.254
Segunda interfaz de salida 1.1.2.254
ethernet0/3
1.1.2.1/24

Si se ha activado el comando unset arp always-on-dest (que es la configuración

predeterminada), el dispositivo de seguridad utiliza la dirección MAC para la puerta
de enlace en 1.1.1.1 que guardó en caché cuando el host B envió el paquete de
sesión inicial. El dispositivo de seguridad continúa enviando las respuestas de
sesión a través de ethernet0/2. En este caso, el fallo en el seguimiento de IP no
afecta al flujo de datos a través del dispositivo de seguridad.
Figura 36: Fallo en el seguimiento de IP de entrada sin enrutamiento

Flujo de tráfico del host B al host A: el fallo de seguimiento de IP no dispara el redireccionamiento
Primera interfaz de salida
Interfaz de entrada ethernet0/2 Seguimiento de IP
ethernet0/1 1.1.1.1/24 desde ethernet0/2
10.1.1.1/24 incorrecto
2
Zona Untrust
Zona Trust Consulta de
sesiones
10.1.1.1/24 3
10.1.1.0/24 4 Host B
2.2.2.2
Segunda interfaz de
1 salida ethernet0/3
1.1.2.1/24
Host A
10.1.1.5 Puertas de
Respondedor Iniciador enlace: 1.1.1.254
1.1.2.254

Capítulo 4
Modos de las interfaces
Las interfaces pueden funcionar en tres modos diferentes: Traducción de

direcciones de red (NAT), modo de rutas (“Route”) y modo transparente
(“Transparent”). Si una interfaz asociada a una zona de capa 3 tiene una dirección
IP, es posible definir el modo de funcionamiento para esa interfaz como NAT
o como Ruta. Una interfaz asociada a una zona de capa 2 (como lo son las zonas
predefinidas v1-trust, v1-untrust y v1-dmz, o una zona de capa 2 definida por el
usuario) debe estar en modo transparente. El modo de funcionamiento se
selecciona al configurar la interfaz.
NOTA: Aunque puede definir el modo de funcionamiento para una interfaz asociada
a cualquier zona de capa 3 como podría ser NAT, el dispositivo de seguridad
solamente ejecuta NAT en tráfico que pasa a través de esa interfaz en dirección
hacia la zona Untrust. ScreenOS no lleva a cabo NAT en el tráfico destinado para
cualquier zona que no sea la zona Untrust. Asimismo, observe que ScreenOS le
permite establecer una interfaz de zona Untrust en modo NAT; sin embargo,
realizar esto no activa ninguna de las operaciones de NAT.
“Modo transparente” en esta página
“Modo NAT” en la página 92
“Modo de rutas” en la página 98
Modo transparente
Cuando una interfaz está en modo transparente, el dispositivo de seguridad filtra
los paquetes que atraviesan el cortafuegos sin modificar ninguna información de
origen ni de destino en el encabezado de los paquetes IP. Todas las interfaces se
comportan como si fuesen parte de la misma red, con el dispositivo de seguridad
actuando en gran medida como conmutador o puente de capa 2 (“Layer 2”). En el
modo transparente, las direcciones IP de las interfaces se establecen en 0.0.0.0,
haciendo que el dispositivo de seguridad parezca “transparente” (o “invisible”) a los
usuarios. Consulte la Figura 37.
Modo transparente 79
Figura 37: Modo transparente
209.122.30.3
209.122.30.2
209.122.30.2 209.122.30.4
209.122.30.1
209.122.30.5
Zona Trust
Conmutador
Espacio de
direcciones
público
Zona Untrust
Enrutador externo
A Internet
El modo transparente es un medio muy práctico para proteger servidores web,

o cualquier otra clase de servidor que reciba principalmente tráfico de fuentes no
fiables. Utilizar el modo transparente tiene las siguientes ventajas:
Elimina la necesidad de reconfigurar los ajustes IP de los enrutadores

y servidores protegidos.
Elimina la necesidad de crear direcciones IP asignadas o virtuales para que el

tráfico entrante llegue a los servidores protegidos.
Ajustes de zona
De forma predeterminada, ScreenOS crea una zona de función, la zona VLAN,
y tres zonas de seguridad L2: V1-Trust, V1-Untrust y V1-DMZ.
Zona VLAN
La zona VLAN contiene la interfaz VLAN1, que tiene la misma configuración y las
mismas posibilidades de administración que una interfaz física. Cuando el
dispositivo de seguridad está en modo transparente, se utiliza la interfaz VLAN1
para administrar el dispositivo y terminar con el tráfico VPN. Puede configurar la
interfaz VLAN1 para permitir que los hosts en las zonas de seguridad L2 puedan
administrar el dispositivo. Para ello, debe establecer la dirección IP de la interfaz
VLAN1 en la misma subred que los hosts de las zonas de seguridad L2.
80 Modo transparente
Capítulo 4: Modos de las interfaces
Para el tráfico administrativo, la IP de administración de VLAN1 tiene preferencia

sobre la IP de la interfaz VLAN1. Puede reservar la IP de administración de VLAN1
para el tráfico administrativo y dedicar la IP de la interfaz VLAN1 solamente a la
terminación del túnel VPN.
Zonas de capa 2 predefinidas

ScreenOS proporciona tres zonas de seguridad L2 predeterminadas: V1-Trust,
V1-Untrust y V1-DMZ. Estas tres zonas comparten el mismo dominio L2. Cuando se
configura una interfaz en una de las zonas, se agrega al dominio L2 compartido por
todas las interfaces en todas las zonas L2. Para poder comunicarse, todos los hosts
en las zonas L2 deben pertenecer a la misma subred.
De acuerdo con lo descrito en la sección anterior, cuando el dispositivo está en

modo transparente se utiliza la interfaz VLAN1 para administrar el dispositivo. Para
que el tráfico administrativo pueda alcanzar la interfaz VLAN1, es necesario
habilitar las opciones de administración en la interfaz VLAN1 y en la(s) zona(s) que
atravesará dicho tráfico. De forma predeterminada, todas las opciones de
administración están habilitadas en la zona V1-Trust. Para que los hosts de otras
zonas puedan administrar el dispositivo, debe establecer esas mismas opciones en
las zonas a las que pertenezcan.
NOTA: Para ver qué interfaces físicas están previamente asociadas con las zonas L2 para
cada plataforma de seguridad de las redes de Juniper Networks, consulte el
manual del instalador de esa plataforma.
Reenvío de tráfico
Un dispositivo de seguridad que opera en la capa 2 (L2) no permite ningún tráfico
interzonal ni intrazonal a menos que exista una directiva configurada en el
dispositivo. Para obtener más información sobre directivas de configuración,
consulte “Directivas” en la página 2-161. Una vez configurada una directiva en el
dispositivo de seguridad, éste hace lo siguiente:
Permite o deniega el tráfico especificado en la directiva.
Permite el tráfico ARP y L2 no IP “multicast” (de un emisor a múltiples

destinatarios) y “broadcast” (de múltiples emisores a múltiples destinatarios).
El dispositivo de seguridad puede entonces recibir y pasar el tráfico de difusión
L2 para el protocolo en árbol “Spanning Tree Protocol”.
Continúa bloqueando todo el tráfico “unicast” que no es de IP y que no es de

ARP, así como el tráfico IPSec.
El comportamiento de reenvío del dispositivo se puede modificar de la siguiente

forma:
Para bloquear todo el tráfico L2 no IP y no ARP, incluyendo el tráfico

“multicast” y “broadcast”, ejecute el comando unset interface vlan1
bypass-non-ip-all.
Para permitir que todo el tráfico L2 no IP pueda pasar por el dispositivo, ejecute
el comando set interface vlan1 bypass-non-ip.
Para restablecer el comportamiento predeterminado del dispositivo, que

consiste en bloquear todo el tráfico “unicast” que no es de IP y que no es de
ARP, introduzca el comando unset interface vlan1-bypass-non-ip.
Observe que el comando unset interface vlan1 bypass-non-ip-all siempre

sobrescribe al comando unset interface vlan1 bypass-non-ip cuando ambos
se encuentran en el archivo de configuración. Por lo tanto, si anteriormente
había introducido el comando unset interface vlan1 bypass-non-ip-all y ahora
desea que el dispositivo restablezca su comportamiento predeterminado de
bloquear únicamente el tráfico “unicast“ que no es de IP y que no es de ARP,
primero debe introducir el comando set interface vlan1 bypass-non-ip para
permitir que todo el tráfico que no es de IP y que no es de ARP, incluso el
multicast, unicast y broadcast, para que pueda pasar a través del dispositivo.
Entonces debe introducir el comando unset interface vlan1-bypass-non-ip
para bloquear solamente el tráfico unicast que no es de IP y que no es de ARP.
Para permitir que un dispositivo de seguridad pase tráfico IPSec sin intentar
terminar con el mismo, utilice el comando set interface vlan1
bypass-others-ipsec. El dispositivo de seguridad permitirá que el tráfico IPSec
pase a través de otros extremos remotos de la VPN.
NOTA: Un dispositivo de seguridad con interfaces en modo transparente requiere de

rutas para dos fines: dirigir el tráfico autogenerado, como las capturas SNMP,
y reenviar tráfico VPN después de encapsularlo o desencapsularlo.
Opciones “unicast” desconocidas

Cuando un host o cualquier clase de dispositivo de red desconoce la dirección MAC
asociada a la dirección IP de otro dispositivo, utiliza el protocolo de resolución de
direcciones (“Address Resolution Protocol” o “ARP”) para obtenerla. El solicitante
difunde mediante “broadcast” una consulta ARP (arp-q) al resto de dispositivos de
la misma subred. La consulta arp-q solicita al dispositivo con la dirección IP de
destino especificada que devuelva una respuesta ARP (arp-r), lo que proporcionará
al solicitante la dirección MAC del dispositivo que responde. Cuando los demás
dispositivos de la subred reciben la consulta arp-q, comprueban la dirección IP de
destino y, al no ser la suya, descartan el paquete. Sólo el dispositivo que tenga la
dirección IP especificada devolverá un mensaje arp-r. Cuando un dispositivo ha
establecido una correspondencia entre una dirección IP y una dirección MAC,
almacena la información en su cache de ARP.
A medida que el tráfico ARP pasa a través de un dispositivo de seguridad en modo

transparente, el dispositivo anota la dirección MAC de origen en cada paquete
y aprende qué interfaz conduce a esa dirección MAC. De hecho, el dispositivo de
seguridad aprende qué interfaz conduce a qué dirección MAC anotando las
direcciones MAC de origen en todos los paquetes que recibe. A continuación,
almacena esta información en su tabla de reenvíos.
NOTA: Un dispositivo de seguridad en modo transparente no permite ningún tráfico

interzonal a menos que exista una directiva configurada en el dispositivo. Para
obtener más información sobre cómo el dispositivo redirecciona tráfico cuando
está en modo transparente, consulte “Reenvío de tráfico” en la página 81.
Esta situación puede surgir cuando un dispositivo envía un paquete unicast con una
dirección MAC de destino, que se encuentra en caché ARP, pero que el dispositivo
de seguridad no tiene registrada en su tabla de redireccionamiento. Por ejemplo, el
dispositivo NetScreen borra su tabla de redireccionamiento cada vez que se reinicia.
(También el usuario podría haber borrado la tabla de reenvíos con el comando CLI
clear arp.) Cuando un dispositivo de seguridad en modo transparente recibe un
paquete unicast para el cual no tiene ninguna entrada en su tabla de
redireccionamiento, éste puede tomar una de estas dos opciones:
Después de realizar una consulta de directivas para determinar a qué zonas

está permitido enviar el tráfico procedente de la dirección de origen, inundar el
paquete inicial saliendo por las interfaces asociadas a esas zonas y seguir
utilizando la interfaz que reciba una respuesta. Se trata de la opción “Flood”,
que está habilitada de forma predeterminada.
Descartar el paquete inicial, inundar con consultas ARP (y, opcionalmente,

paquetes trace-route, que son peticiones de eco ICMP con el valor “time-to-live”
en 1) saliendo por todas las interfaces (excepto por la interfaz por la que entró
el paquete) y enviar los paquetes subsiguientes por cualquier interfaz que
reciba una respuesta ARP (o trace-route) del enrutador o del host cuya dirección
MAC coincida con la dirección MAC de destino en el paquete inicial. La opción
“trace-route” permite al dispositivo de seguridad descubra la dirección MAC de
destino, cuando esta dirección IP de destino se encuentre en una subred no
adyacente.
NOTA: De los dos métodos (inundación y “ARP/trace-route”), ARP/trace es más seguro

debido a que el dispositivo de seguridad inunda todas las interfaces con consultas
ARP y paquetes trace-route (no el paquete inicial).
Método de inundación
El método de inundación redirecciona paquetes de la misma manera que la
mayoría de conmutadores de la capa 2. Un conmutador actualiza una tabla de
redireccionamiento que contiene direcciones MAC y sus puertos asociados para
cada dominio de la capa 2. La tabla también contiene la interfaz correspondiente
a través de la cual el conmutador puede reenviar tráfico a cada dispositivo. Cada
vez que un paquete llega con una nueva dirección MAC de origen en su encabezado
de trama, el conmutador agrega la dirección MAC a su tabla de reenvíos. También
detecta a través de qué interfaz llegó el paquete. Si la dirección MAC de destino es
desconocida para el conmutador, éste duplica el paquete y lo inunda saliendo por
todas las interfaces (a excepción de la interfaz por la que llegó el paquete).
Memoriza la dirección MAC (desconocida hasta ese momento) y la interfaz
correspondiente cuando recibe una respuesta con esa dirección MAC en una de sus
interfaces.
Cuando se habilita el método de inundación y el dispositivo de seguridad recibe una

trama de Ethernet con una dirección MAC de destino que no figuraba en la tabla
MAC de dispositivos de seguridad, éste asigna el paquete a todas las interfaces.
Figura 38: Método de inundación

IP 0.0.0.0/0 IP 0.0.0.0/0
El paquete llega a
ethernet0/1. Zona
V1-DMZ
Zona V1-Trust Enrutador
Espacio común de direcciones
IP 0.0.0.0/0 IP 0.0.0.0/0
Zona V1-Untrust
Zona
L2-Finanzas
Enrutador Enrutador Se encontró Untrust
El dispositivo de seguridad asigna el paquete a ethernet0/2, pero no recibe ninguna respuesta.
Para habilitar el método de inundación para el tratamiento de paquetes unicast

desconocidos, ejecute cualquiera de los siguientes procedimientos:
WebUI
Network > Interfaces > Edit (para VLAN1): Para las opciones de multidifusión
(“broadcast”), seleccione Flood y haga clic en OK.
CLI
set interface vlan1 broadcast flood
save
Método ARP/Trace-Route
Cuando habilita el método ARP con la opción trace-route y el dispositivo de
seguridad recibe una trama de Ethernet con una dirección MAC de destino que no
consta en su tabla de MAC, el dispositivo de seguridad realiza la siguiente serie de
acciones:
NOTA: Cuando se habilita el método ARP, la opción “trace-route” se habilita de forma

predeterminada. También puede habilitar el método ARP sin la opción
“trace-route”. Sin embargo, este método solamente permite al dispositivo de
seguridad descubrir la dirección MAC de destino para un paquete unicast, si la
dirección IP de destino se encuentra en la misma subred que la dirección IP de
entrada. (Para obtener más información sobre la dirección IP de entrada, consulte
la siguiente nota).
1. El dispositivo de seguridad anota la dirección MAC de destino en el paquete

inicial (y, si aún no se encuentra allí, agrega la dirección MAC de origen y su
interfaz correspondiente a la tabla de redireccionamiento).
2. El dispositivo de seguridad descarta el paquete inicial.
3. El dispositivo de seguridad genera dos paquetes: la consulta ARP (arp-q) y un

trace-route (una petición de eco ICMP o PING) con un valor de 1 en el campo
“time-to-live” (TTL) y asigna esos paquetes a todas las interfaces excepto a la
que llegó el paquete inicial. Para los paquetes arp-q y las peticiones de eco
ICMP, el dispositivo de seguridad utiliza las direcciones IP de origen y de
destino del paquete inicial. Para los paquetes arp-q, el dispositivo de seguridad
reemplaza la dirección MAC de origen del paquete inicial con la dirección MAC
para VLAN1, y reemplaza la dirección MAC de destino del paquete inicial con
ffff.ffff.ffff. Para la opción “trace-route”, el dispositivo de seguridad utiliza las
direcciones MAC de origen y de destino del paquete inicial en las peticiones de
eco ICMP que difunde.
Si la dirección IP de destino pertenece a un dispositivo en la misma subred que

la dirección IP de entrada, el host devuelve una respuesta ARP (arp-r) con su
dirección MAC, indicando así la interfaz a través de la cual el dispositivo de
seguridad debe redireccionar el tráfico destinado a esa dirección. (Consulte
Figura 39, “Método ARP,” en la página 86.).
NOTA: La dirección IP de entrada hace referencia a la dirección IP del último dispositivo

para enviar el paquete al dispositivo de seguridad. Este dispositivo puede ser el
origen que envió el paquete o un enrutador que lo reenvió.
Si la dirección IP de destino pertenece a un dispositivo en una subred más allá

de la subred de la dirección IP de entrada, trace-route devuelve las direcciones
IP y MAC del enrutador que conduce al destino y, lo que es aún más
importante, indica la interfaz a través de la cual el dispositivo de seguridad
debe redireccionar el tráfico destinado a esa dirección MAC. (Consulte la
Figura 40 en la página 87.)
NOTA: De hecho, trace-route devuelve las direcciones IP y MAC de todos los enrutadores
en la subred. El dispositivo de seguridad compara entonces la dirección MAC de
destino del paquete inicial con la dirección MAC de origen en los paquetes arp-r
para determinar a qué enrutador dirigirse, y por lo tanto, qué interfaz utilizar para
alcanzar ese destino.
4. Al combinar la dirección MAC de destino que se obtuvo del paquete inicial con
la interfaz que conduce a esa dirección MAC, el dispositivo de seguridad agrega
una nueva entrada a su tabla de redireccionamiento.
5. El dispositivo de seguridad redirecciona al destino todos los paquetes que

reciba posteriormente por la interfaz correcta.
Para habilitar el método ARP/trace-route para tratar los paquetes unicast

desconocidos, ejecute cualquiera de los siguientes procedimientos:
WebUI
Network > Interfaces > Edit (para VLAN1): Para las opciones de difusión,
seleccione ARP entonces haga clic en OK.
CLI
set interface vlan1 broadcast arp
save
NOTA: De forma predeterminada, la opción trace-route está habilitada. Si desea utilizar

ARP sin la opción trace-route, introduzca el comando siguiente: unset interface
vlan1 broadcast arp trace-route. Este comando desactiva la opción trace-route,
pero no ARP como método seleccionado para tratar los paquetes de unidifusión
desconocidos.
La Figura 39 siguiente muestra de qué forma el método ARP puede localizar el

destino MAC cuando la dirección IP de destino se encuentra en una subred
adyacente.
Figura 39: Método ARP

Nota: A continuación, sólo se muestran los elementos relevantes VLAN1
del encabezado del paquete y los últimos cuatro dígitos en 210.1.1.1/24
las direcciones MAC. 0010.db15.39ce
PC A ethernet0/1 ethernet0/4 Enrutador A
Si el paquete siguiente: 210.1.1.5 0.0.0.0/0 0.0.0.0/0 210.1.1.100
00aa.11aa.11aa 0010.db15.39ce 0010.db15.39ce 00cc.11cc.11cc
Trama Ethernet Datagrama IP
dst src type src dst
11bb 11aa 0800 210.1.1.5 210.1.1.75
Zona
V1-DMZ
llega a ethernet0/1 y la tabla de Zona V1-Trust Enrutador
reenvíos no tiene una entrada para la dirección
MAC 00bb.11bb.11bb, el dispositivo de seguridad
inunda el siguiente paquete arp-q: Espación
Trama Ethernet Mensaje ARM común
de direcciones
ffff 39ce 0806 210.1.1.5 210.1.1.75 0.0.0.0/0 0.0.0.0/0
0010.db15.39ce 0010.db15.39ce
Cuando el dispositivo recibe el siguiente arp-r
en ethernet0/2: Zona
L2-Finanzas Zona
Trama Ethernet Mensaje ARM V1-Untrust
39ce 11bb 0806 210.1.1.75 210.1.1.5 PC B encontrado Enrutador B
PC B
210.1.1.200
210.1.1.75
00dd.11dd.11dd
Éste ahora puede asociar la dirección MAC con 00bb.11bb.11bb
la interfaz que conduce hacia ella.
La Figura 40 muestra cómo la opción trace-route puede localizar la dirección MAC

de destino, cuando la dirección IP de destino se encuentra en una subred no
adyacente.
Figura 40: Trace-Route
Nota: A continuación, sólo se muestran los elementos relevantes VLAN1

del encabezado del paquete y los últimos cuatro dígitos en 210.1.1.1/24
las direcciones MAC. 0010.db15.39ce
PC A ethernet0/1 ethernet0/4 Enrutador A
Si el paquete siguiente: 210.1.1.5 0.0.0.0/0 0.0.0.0/0 210.1.1.100
00aa.11aa.11aa 0010.db15.39ce 0010.db15.39ce 00cc.11cc.11cc
Trama Ethernet Datagrama IP
11dd 11aa 0800 210.1.1.5 195.1.1.5 Zona

V1-DMZ
llega a ethernet0/1 y la tabla Zona V1-Trust
de reenvíos no tiene una entrada para la dirección
MAC 00dd.11dd.11dd, el dispositivo de seguridad
inunda el siguiente paquete trace-route por
ethernet0/2, ethernet0/3 y ethernet0/4: Espacio
común
de direcciones
Trama Ethernet Mensaje ICMP ethernet0/3
ethernet0/2
0.0.0.0/0 0.0.0.0/0 Se
dst src type src dst TTL 0010.db15.39ce 0010.db15.39ce encontró
11dd 11aa 0800 210.1.1.5 195.1.1.5 1 Untrust
Zona
Zona V1-Untrust
Cuando el dispositivo recibe la siguiente respuesta L2-Finanzas
en ethernet0/3:
Trama Ethernet Mensaje ICMP

PC B Enrutador B
210.1.1.75 210.1.1.200 Servidor C
dst src type src dst msg 00bb.11bb.11bb 00dd.11dd.11dd 195.1.1.5
00dd.22dd.22dd
11aa 11dd 0800 210.1.1.200 210.1.1.5 Tiempo
excedido
Ahora se puede asociar la dirección MAC

con la interfaz que conduce hacia la misma.
Configurar la interfaz VLAN1 para administración

En este ejemplo puede configurar el dispositivo de seguridad para la administración
a su interfaz VLAN1 de la siguiente manera:
Asignará a la interfaz VLAN1 la dirección IP 1.1.1.1/24.
Habilite Web, Telnet, SSH y Ping tanto en la interfaz VLAN1 como en la zona de
seguridad V1-Trust.
NOTA: De forma predeterminada, ScreenOS habilita las opciones de administración para

la interfaz VLAN1 y la zona de seguridad V1-Trust. En este ejemplo se muestran
estas opciones habilitadas sólo con fines ilustrativos. A menos que las haya
inhabilitado previamente, realmente no es necesario habilitarlas manualmente.
Para administrar el dispositivo desde una zona de seguridad de capa 2, debe

establecer las mismas opciones de administración tanto para la interfaz VLAN1
como para la zona de seguridad de capa 2.
Agregue una ruta en el enrutador virtual trust (todas las zonas de seguridad de
capa 2 están en el dominio de enrutamiento trust-vr) para permitir que el
tráfico administrativo fluya entre el dispositivo de seguridad y una estación de
trabajo administrativa situada más allá de la subred inmediata del dispositivo
de seguridad. Todas las zonas de seguridad se encuentran en el dominio de
Figura 41: VLAN transparente

1.1.2.0/24 Enrutador interno 1.1.1.0/24 Enrutador externo
Subred 1.1.1.251 Subred 1.1.1.250
1.1.2.250
Internet
IP de VLAN1
Zona V1-Trust 1.1.1.1/24 Zona V1-Untrust
Estación de Interfaz V1-Trust Interfaz V1-Untrust

trabajo admin ethernet0/1 ethernet0/3
1.1.2.5 0.0.0.0/0 0.0.0.0/0
WebUI
1. Interfaz VLAN1
Network > Interfaces > Edit (para VLAN1): Introduzca los siguientes datos
y haga clic en OK:
Management Services: WebUI, Telnet, SSH (seleccione)
2. Zona V1-Trust
Network > Zones > Edit (para V1-Trust): Introduzca los siguientes datos y haga
clic en OK:
Management Services: WebUI, Telnet, SSH

Other Services: Ping
3. Ruta

Interface: vlan1(trust-vr)
Metric: 1
CLI
1. Interfaz VLAN1
set interface vlan1 ip 1.1.1.1/24
set interface vlan1 manage web
set interface vlan1 manage telnet
set interface vlan1 manage ssh
set interface vlan1 manage ping
2. Zona V1-Trust
set zone v1-trust manage web
set zone v1-trust manage telnet
set zone v1-trust manage ssh
set zone v1-trust manage ping
3. Ruta
set vrouter trust-vr route 1.1.2.0/24 interface vlan1 gateway 1.1.1.251 metric 1
save
Configuración del modo transparente

El ejemplo siguiente ilustra una configuración básica con una sola LAN protegida
por un dispositivo de seguridad en modo transparente. Las directivas permiten el
tráfico saliente para todos los hosts de la zona V1-Trust, servicios SMTP entrantes
para el servidor de correo y servicios entrantes FTP-GET para el servidor FTP.
Para aumentar la seguridad del tráfico administrativo, cambie el número del puerto
HTTP para la administración de WebUI de 80 a 5555, y el número de puerto Telnet
para la administración de CLI de 23 a 4646. Utilice la dirección IP de VLAN1
(1.1.1.1/24) para administrar el dispositivo de seguridad desde la zona de seguridad
V1-Trust. Se definen las direcciones para los servidores FTP y de correo. También
configura una ruta predeterminada al enrutador externo en 1.1.1.250, para que el
dispositivo de seguridad le pueda enviar tráfico VPN saliente. (La puerta de enlace
predeterminada en todos los hosts de la zona V1-Trust también será 1.1.1.250).
NOTA: Para ver un ejemplo de configuración de un túnel VPN para un dispositivo de

seguridad con las interfaces en modo transparente, consulte “VPN en modo
transparente” en la página 5-154.
Figura 42: Modo transparente básico

Servidor_FTP Servidor_Mail Enrutador externo
1.1.1.5 1.1.1.10 1.1.1.250
Espacio de direcciones
1.1.1.0/24
Internet
IP de VLAN1
Zona V1-Trust 1.1.1.1/24 Zona V1-Untrust
Interfaz V1-Trust Interfaz V1-Untrust

0.0.0.0/0 0.0.0.0/0
WebUI
1. Interfaz VLAN1
Network > Interfaces > Edit (para la interfaz VLAN1): Introduzca los siguientes
Management Services: WebUI, Telnet (seleccione)
2. Puerto HTTP
Configuration > Admin > Management: En el campo HTTP Port, escriba 5555,
y luego haga clic en Apply.
NOTA: El número de puerto predeterminado es 80. Se recomienda cambiarlo a cualquier

número entre 1024 y 32.767 para evitar cualquier acceso no autorizado a la
configuración. Cuando se conecte posteriormente para administrar el dispositivo,
introduzca lo siguiente en el campo “URL” de su explorador: http://1.1.1.1:5555.
3. Interfaces
Zone Name: V1-Trust

Zone Name: V1-Untrust

4. Zona V1-Trust
Network > Zones > Edit (para v1-trust): Introduzca los siguientes datos y haga
clic en OK:
Management Services: WebUI, Telnet

5. Direcciones
Address Name: FTP_Server

Zone: V1-Trust
Address Name: Mail_Server

Zone: V1-Trust
6. Ruta

Interface: vlan1(trust-vr)
Metric: 1
7. Directivas
Policy > Policies > (From: V1-Trust, To: V1-Untrust) New: Introduzca los
Source Address:
Service: Any
Action: Permit
Policy > Policies > (From: V1-Untrust, To: V1-Trust) New: Introduzca los
Source Address:
Address Book Entry: (seleccione), Mail_Server
Service: Mail
Action: Permit
Policy > Policies > (From: V1-Untrust, To: V1-Trust) New: Introduzca los
Source Address:
Address Book Entry: (seleccione), FTP_Server
Service: FTP-GET
Action: Permit
CLI
1. VLAN1
2. Telnet
set admin telnet port 4646
NOTA: El número de puerto predeterminado para Telnet es 23. Se recomienda cambiarlo

a cualquier número entre 1024 y 32,767 para evitar cualquier acceso
no autorizado a la configuración. Cuando se conecte posteriormente para
administrar el dispositivo a través de Telnet, introduzca la siguiente
dirección: 1.1.1.1 4646.
3. Interfaces
set interface ethernet0/1 zone v1-trust
set interface ethernet0/3 zone v1-untrust
4. Zona V1-Trust
5. Direcciones
set address v1-trust FTP_Server 1.1.1.5/32
set address v1-trust Mail_Server 1.1.1.10/32
6. Ruta
set vrouter trust-vr route 0.0.0.0/0 interface vlan1 gateway 1.1.1.250 metric 1
7. Directivas
set policy from v1-trust to v1-untrust any any any permit
set policy from v1-untrust to v1-trust any Mail_Server mail permit
set policy from v1-untrust to v1-trust any FTP_Server ftp-get permit
save
Modo NAT
Cuando una interfaz de entrada está en el modo de traducción de direcciones de
red (NAT), el dispositivo de seguridad, actuando como conmutador (o enrutador) de
capa 3, traduce dos componentes del encabezado de un paquete IP saliente
destinado a la zona Untrust: su dirección IP de origen y el número del puerto de
origen. El dispositivo de seguridad reemplaza la dirección IP de origen del host de
origen con la dirección IP de la interfaz de la zona Untrust. También reemplaza el
número del puerto de origen con otro número de puerto generado aleatoriamente
por el dispositivo de seguridad.
92 Modo NAT
Figura 43: Topología NAT
10.1.1.15
10.1.1.10 10.1.1.20
10.1.1.5
10.1.1.25
Zona Trust
Espacio de Interfaz de la
direcciones privado zona Trust
10.1.1.1/24
Interfaz de la
Espacio de zona Untrust
direcciones público 1.1.1.1/24
Enrutador externo
1.1.1.250
Zona Untrust
Internet
Cuando el paquete de respuesta llega al dispositivo de seguridad, éste traduce dos

componentes en el encabezado IP del paquete entrante: la dirección y el número de
puerto del destino, que se traducen inversamente para obtener los números
originales. Entonces, el dispositivo de seguridad redirecciona el paquete a su
destino.
NAT agrega un nivel de seguridad no disponible con el modo transparente: Las

direcciones de los hosts que están enviando tráfico a través de una interfaz de
entrada en modo NAT (como lo es una interfaz de la zona Trust) nunca quedan
expuestas a hosts en la zona de salida (como lo es la zona Untrust), salvo que
ambas zonas se encuentren en el mismo dominio de enrutamiento virtual y que el
dispositivo de seguridad esté publicando rutas a interlocutores a través de un
protocolo de enrutamiento dinámico (DRP). Incluso entonces, las direcciones de la
zona Trust son solamente accesibles si alguna directiva les permite recibir tráfico
entrante. (Si desea mantener ocultas las direcciones de la zona Trust mientras
utilice un DRP, ponga la zona Untrust en untrust-vr y la zona Trust en trust-vr, y no
exporte rutas de direcciones internas de trust-vr a untrust-vr).
Si el dispositivo de seguridad utiliza el enrutamiento estático y sólo un enrutador

virtual, las direcciones internas siguen ocultas cuando el tráfico es saliente, debido
a NAT basada en interfaces. Las directivas que configure controlan el tráfico
entrante. Si solamente utiliza direcciones IP asignadas (MIP) y direcciones IP
virtuales (VIP) como destinos en sus directivas de tráfico entrante, las direcciones
internas permanecerán ocultas.
Modo NAT 93
Asimismo, NAT preserva el uso de direcciones IP públicas. En muchos entornos, no

hay recursos disponibles para proporcionar direcciones IP públicas para todos los
dispositivos en la red. Los servicios NAT permiten que muchas direcciones IP
privadas tengan acceso a los recursos de Internet a través de una, o de unas pocas,
direcciones IP públicas. Los siguientes rangos de direcciones IP están reservados
para redes IP privadas y no deben enrutarse hacia Internet:
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255
Tráfico NAT entrante y saliente

Un host en una zona que envíe tráfico a través de una interfaz en modo NAT puede
iniciar tráfico hacia la zona Untrust (asumiendo que alguna directiva lo permita). En
versiones anteriores a ScreenOS 5.0.0, un host detrás de una interfaz en modo NAT
no podía recibir tráfico de la zona Untrust a menos que se configurara para él una
dirección IP asignada (MIP), IP virtual (VIP) o un túnel VPN. Sin embargo, en
ScreenOS 5.0.0, el tráfico hacia una zona con una interfaz habilitada para NAT
desde cualquier zona (incluyendo la zona Untrust) no necesita utilizar una MIP, VIP
o VPN. Si desea proteger la privacidad de las direcciones o si está utilizando
direcciones privadas inexistentes en una red pública como Internet, puede definir
una MIP, VIP o VPN para que el tráfico pueda alcanzarlas. Sin embargo, si los
posibles problemas de privacidad y las direcciones IP privadas no son una cuestión
relevante, el tráfico procedente de la zona Untrust puede llegar directamente a los
hosts que se encuentren detrás de una interfaz en modo NAT, sin necesidad de
utilizar una MIP, VIP ni VPN.
NOTA: Sólo se puede definir una dirección IP virtual (VIP) en una interfaz asociada a la
zona Untrust.
Figura 44: Flujo de tráfico NAT
ethernet0/3
1. NAT basada en interfaces aplicada al tráfico de Zona Untrust 1.1.1.1/24
la zona Trust a la zona Untrust. Modo de rutas
MIP 1.1.1.10 – 10.1.1.10
2. NAT basada en interfaces aplicada al tráfico de MIP 1.1.1.20 Ð 10.1.2.20
la zona definida por el usuario a la zona Untrust. 1 2
(Nota: Esto sólo es posible si las zonas definida NAT NAT
por el usuario y Untrust se encuentran en
diferentes dominios de enrutamiento virtuales).
3. Sin NAT basada en interfaces aplicada al tráfico

entre la zona Trust y la zona definida por el ethernet0/1 Las MIP son opcionales ethernet0/2
usuario. 10.1.1.1/24 10.1.2.1/24
Modo NAT 4 5 Modo NAT
4 y 5. Puede utilizar MIP, VIP or VPN para que el
tráfico de la zona Untrust llegue hasta la zona Trust
o a la zona definida por el usuario, pero no son Zona Trust 3 Sin NAT Zona definida
necesarias. Las MIP son por el usuario
opcionales 6
94 Modo NAT
NOTA: Para obtener más información sobre MIP, consulte “Direcciones IP asignadas” en
la página 8-63. Para obtener más información sobre VIP, consulte “Direcciones IP
virtuales” en la página 8-81.
Ajustes de interfaz
Para el modo NAT, defina los siguientes ajustes de interfaz, donde dir_ip1 y dir_ip2
representan los números de una dirección IP, máscara representa los números de
una máscara de red, núm_id_vlan representa el número de una etiqueta VLAN, zona
representa el nombre de una zona y número representa el tamaño del ancho de
banda en kbps:
Interfaces de zona Ajustes Subinterfaces de zona

Zonas Trust, DMZ y definidas IP: dir_ip1 IP: dir_ip1
por el usuario que utilizan Netmask: máscara Netmask: máscara
NAT Manage IP1: dir_ip2 VLAN Tag: núm_id_vlan
Traffic Bandwidth2: número Zone Name: zona
NAT3: (seleccione) NAT†: (seleccione)
Untrust4 IP: dir_ip1 IP: dir_ip1
Netmask: máscara Netmask: máscara
Manage IP*: dir_ip2 VLAN Tag: núm_id_vlan
Traffic Bandwidth†: número Zone Name: zona
1.Puede establecer una dirección IP de administración en cada interfaz. Su finalidad principal es

proporcionar una dirección IP para el tráfico administrativo separada del tráfico de red. También
puede utilizar la dirección IP de administración para tener acceso a un dispositivo específico
cuando se encuentre en una configuración de alta disponibilidad.
2.Ajuste opcional para la asignación de tráfico.
3.Al seleccionar NAT, el modo de interfaz se define como NAT. Al seleccionar Route, el modo de la
interfaz es de rutas.
4.Aunque puede seleccionar NAT como el modo de interfaz en una interfaz asociada con la zona
Untrust, el dispositivo de seguridad no realiza ninguna operación NAT en esa interfaz.
NOTA: En modo NAT, puede administrar un dispositivo de seguridad de cualquier interfaz

(y de múltiples interfaces) utilizando la dirección IP del sistema, direcciones IP de
la interfaz, direcciones IP de administración o la dirección IP de MGT.
Configuración de modo NAT

El siguiente ejemplo ilustra una configuración simple de una LAN con una sola
subred en la zona Trust. La LAN está protegida por un dispositivo de seguridad en
modo NAT. Las directivas permiten el tráfico saliente para todos los hosts de la zona
Trust y correo entrante para el servidor de correo. El correo entrante se enruta al
servidor de correo a través de una dirección IP virtual. Las dos zonas Trust y Untrust
se encuentran en el dominio de enrutamiento trust-vr.
NOTA: Compare la Figura 45 con la configuración para el modo de rutass en la Figura 47,
“Dispositivo en modo de rutas,” en la página 100.
Modo NAT 95
Figura 45: Dispositivo en modo NAT

Enrutador externo
1.1.1.250
Servidor de correo Internet

VIP 1.1.1.5 ->
10.1.1.5
10.1.1.1/24 1.1.1.1/24
Modo NAT Modo de rutas
WebUI
1. Interfaces
Zone Name: Trust

Introduzca los siguientes datos y haga clic en OK:
Interface Mode: NAT
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.
Zone Name: Untrust

Interface Mode: Route
NOTA: Si la dirección IP de la zona Untrust en el dispositivo de seguridad la asigna un ISP

dinámicamente, deje los campos de dirección IP y de máscara de red vacíos y
seleccione Obtain IP using DHCP. Si el ISP utiliza el protocolo punto a punto por
Ethernet (PPPoE, Point-to-Point Protocol over Ethernet), seleccione Obtain IP
using PPPoE, haga clic en el vínculo Create new PPPoE settings e introduzca su
nombre y contraseña.
2. VIP
Network > Interfaces > Edit (para ethernet0/3) > VIP: Introduzca los
siguientes datos y haga clic en Add:
Virtual IP Address: 1.1.1.5
Network > Interfaces > Edit (para ethernet0/3) > VIP > New VIP Service:
Virtual Port: 25
Map to Service: Mail
Map to IP: 10.1.1.5
96 Modo NAT
NOTA: Para obtener más información sobre direcciones IP virtuales (VIP), consulte
“Direcciones IP virtuales” en la página 8-81.
3. Ruta

4. Directivas
Policy > Policies > (From: Trust, To: Untrust) New: Introduzca los siguientes
Source Address:
Service: ANY
Action: Permit
Policy > Policies > (From: Untrust, To: Global) New: Introduzca los siguientes
Source Address:
Address Book Entry: (seleccione), VIP(1.1.1.5)
Service: MAIL
Action: Permit
CLI
1. Interfaces
set interface ethernet0/1 nat
set interface ethernet0/3 route
NOTA: El comando set interface ethernetn nat determina si el dispositivo de seguridad

está funcionando en modo NAT.
Si la dirección IP de la zona Untrust en el dispositivo de seguridad la asigna un ISP

dinámicamente, utilice el siguiente comando: set interface untrust dhcp. Si el ISP
utiliza el protocolo PPPoE, utilice los comandos set pppoe y exec pppoe. Para
obtener más información, consulte el manual ScreenOS CLI: IPv4 Command
Descriptions.
2. VIP
set interface ethernet0/3 vip 1.1.1.5 25 mail 10.1.1.5
Modo NAT 97
3. Ruta
4. Directivas
set policy from trust to untrust any any any permit
set policy from untrust to global any vip(1.1.1.5) mail permit
save
Modo de rutas
Cuando una interfaz está en modo de rutas, el dispositivo de seguridad enruta el
tráfico entre diferentes zonas sin realizar la NAT de origen (NAT-src); es decir, la
dirección de origen y el número de puerto en el encabezado del paquete IP
permanecen sin cambios mientras atraviesan el dispositivo de seguridad.
A diferencia de NAT-src, no es necesario establecer direcciones IP asignadas (MIP)
e IP virtuales (VIP) para permitir que el tráfico entrante llegue a los hosts cuando la
interfaz de la zona de destino está en modo de rutas. A diferencia del modo
transparente, las interfaces de cada zona se encuentran en subredes diferentes.
Figura 46: Topología NAT
10.1.1.15
10.1.1.10 10.1.1.20
10.1.1.5
10.1.1.25
Zona Trust
Espacio de
direcciones privado Interfaz de la
zona Trust
10.1.1.1/24
Interfaz de la
Espacio de zona Untrust
direcciones público 1.1.1.1/24
Enrutador externo
1.1.1.250
Zona Untrust
Internet
98 Modo de rutas
No es necesario aplicar la traducción de direcciones de red de origen (“NAT-src”) en

el nivel de la interfaz para que todas las direcciones de origen que inician tráfico
saliente sean traducidas a la dirección IP de la interfaz de la zona de destino. En
lugar de ello, puede aplicar NAT-src selectivamente a nivel de directivas. Puede
determinar qué tráfico enrutar y a qué tráfico aplicar NAT-src creando las directivas
que habilitan NAT-src para las direcciones de origen especificadas tanto en tráfico
entrante como saliente. Para el tráfico de red, NAT puede utilizar la dirección IP
(o direcciones IP) de la interfaz de la zona de destino de un rango de IP dinámicas
(DIP), que se encuentra en la misma subred que la interfaz de la zona de destino.
Para el tráfico VPN, NAT puede utilizar la dirección IP de una interfaz de túnel o una
dirección de su conjunto de DIP asociado.
NOTA: Para obtener más información sobre cómo configurar NAT-src basada en
directivas, consulte “Traducción de direcciones de red de origen” en la
página 8-13.
Ajustes de interfaz
Para el modo de rutas, defina los siguientes ajustes de interfaz, donde dir_ip1
y dir_ip2 representan los números de una dirección IP, máscara representa los
números de una máscara de red, núm_id_vlan representa el número de una
etiqueta VLAN, zona representa el nombre de una zona y número representa el
tamaño del ancho de banda en kbps:
Tabla 7: Ajustes de interfaz
Interfaces de zona Ajustes Subinterfaces de zona

Trust, Untrust, DMZ y zonas IP: dir_ip1 IP: dir_ip1
definidas por el usuario Netmask: máscara Netmask: máscara
Manage IP1: dir_ip2 VLAN Tag: núm_id_vlan
Traffic Bandwidth2: número Zone Name: zona
Route3: (seleccione) Route†: (seleccione)
1.Puede establecer una dirección IP de administración en cada interfaz. Su finalidad principal es

proporcionar una dirección IP para el tráfico administrativo separada del tráfico de red. También
puede utilizar la dirección IP de administración para tener acceso a un dispositivo específico
cuando se encuentre en una configuración de alta disponibilidad.
2.Ajuste opcional para la asignación de tráfico.
3.Al seleccionar la ruta, el modo de la interfaz se define como de rutas. Al seleccionar NAT, el
modo de la interfaz queda definido como NAT.
Configuración del modo de rutas

En “Configuración de modo NAT” en la página 95, los hosts en la LAN de la zona
Trust tienen direcciones IP privadas y una dirección IP asignada para el servidor de
correo. En el ejemplo siguiente, la misma red está protegida por un dispositivo de
seguridad que funciona en modo de rutas; observe que los hosts tienen direcciones
IP públicas y que no se requiere una MIP para el servidor de correo. Ambas zonas
de seguridad se encuentran en el dominio de enrutamiento trust-vr.
Modo de rutas 99
Figura 47: Dispositivo en modo de rutas

Enrutador externo
1.1.1.250
Servidor de Internet
correo
1.2.2.5
Zona Trust ethernet0/1 ethernet0/3 Zona Untrust

1.2.2.1/24 1.1.1.1/24
Modo de rutas Modo de rutas
WebUI
1. Interfaces
Zone Name: Trust

Zone Name: Untrust

NOTA: Al seleccionar Route se determina que el dispositivo de seguridad funciona en

modo de rutas, sin aplicar NAT al tráfico entrante o saliente de la zona Trust.
Si la dirección IP de la zona Untrust en el dispositivo de seguridad la asigna un ISP

dinámicamente, deje los campos de dirección IP y de máscara de red vacíos
y seleccione Obtain IP using DHCP. Si el ISP utiliza el protocolo PPPoE, seleccione
Obtain IP using PPPoE, haga clic en Create new PPPoE settings y luego
introduzca el nombre y la contraseña.
2. Dirección
Address Name: Mail Server

Zone: Trust
100 Modo de rutas

3. Ruta

4. Directivas
Source Address:
Service: ANY
Action: Permit
Policy > Policies > (From: Untrust, To: Trust) New: Introduzca los siguientes
Source Address:
Address Book Entry: (seleccione), Mail Server
Service: MAIL
Action: Permit
CLI
1. Interfaces
NOTA: El comando set interface ethernet número route establece que el dispositivo de
seguridad funcione en modo de rutas.
2. Dirección
set address trust mail_server 1.2.2.5/24
3. Ruta
4. Directivas
set policy from untrust to trust any mail_server mail permit
save
Modo de rutas 101

102 Modo de rutas

Capítulo 5
Bloques para la construcción de
directivas
Este capítulo explica los componentes, o bloques de construcción, a los que puede
hacerse referencia en las directivas. Incluye las siguientes secciones:
“Direcciones” en esta página
“Servicios” en la página 109
“Conjuntos de IP dinámicas” en la página 142
“Configuración de una programación recurrente” en la página 158
NOTA: Para obtener información sobre la autentificación de usuario, consulte el

Volumen 9: Autenticación de usuariosn.
Direcciones
ScreenOS clasifica las direcciones de todos los demás dispositivos según su
ubicación y máscara de red. Cada zona posee su propia lista de direcciones y sus
grupos de direcciones.
Los hosts individuales solamente tienen definida una dirección IP, por lo que su
máscara de red debe tener el valor 255.255.255.255 (que enmascara todos los
hosts salvo el propio).
Las subredes tienen una dirección IP y una máscara de red (por ejemplo,
255.255.255.0 o 255.255.0.0).
Para poder configurar directivas que permitan, rechacen o canalicen el tráfico a

través de un túnel desde y hacia determinados hosts y subredes, debe crear las
correspondientes entradas en las listas de direcciones de ScreenOS, que están
organizadas por zonas.
NOTA: Para “Any” no es necesario crear entradas de direcciones. Este término se aplica
automáticamente a todos los dispositivos situados físicamente dentro de sus
zonas respectivas.
Direcciones 103
Entradas de direcciones
Para poder establecer muchas de las funciones del cortafuegos de Juniper
Networks, de VPN y de asignación del tráfico, debe definir direcciones en una o
varias listas de direcciones. La lista de direcciones de una zona de seguridad incluye
las direcciones IP o nombres de dominios de los hosts o subredes cuyo tráfico está
permitido, bloqueado, encriptado o autentificado por el usuario.
NOTA: Para poder utilizar nombres de dominios para las entradas de direcciones es
necesario configurar el dispositivo de seguridad para los servicios del sistema de
nombres de dominios (DNS). Para obtener información sobre la configuración del
DNS, consulte “Compatibilidad con DNS (sistema de nombres de dominio)” en la
página 219.
Para obtener más información sobre las convenciones de nomenclatura de

ScreenOS, aplicables a los nombres creados para las direcciones, consulte
“Convenciones de interfaz de línea de comandos” en la página x.
Adición de una dirección

En este ejemplo agregará la subred “Sunnyvale_Eng” con la dirección
IP 10.1.10.0/24 como dirección en la zona Trust, y la dirección “www.juniper.net”
como dirección en la zona Untrust.
WebUI
Address Name: Sunnyvale_Eng

Zone: Trust
Address Name: Juniper

Domain Name: (seleccione), www.juniper.net
Zone: Untrust
CLI
set address trust Sunnyvale_Eng 10.1.10.0/24
set address untrust Juniper www.juniper.net
save
104 Direcciones
Capítulo 5: Bloques para la construcción de directivas
Modificación de una dirección

En este ejemplo cambiará la entrada de la dirección “Sunnyvale_Eng” para reflejar
que este departamento está dedicado específicamente a la ingeniería de software y
tiene otra dirección IP (10.1.40.0/24).
WebUI
Policy > Policy Elements > Addresses > List > Edit (para Sunnyvale_Eng):
Cambie el nombre y la dirección IP por los siguientes datos, luego haga clic
en OK:
Address Name: Sunnyvale_SW_Eng

Zone: Trust
CLI
unset address trust Sunnyvale_Eng
set address trust Sunnyvale_SW_Eng 10.1.40.0/24
save
NOTA: Después de definir una dirección, o un grupo de direcciones, y asociarla a una

directiva, no podrá cambiar la ubicación de la dirección a otra zona (como de
Trust a Untrust). Para cambiar su ubicación, primero debe desvincularla de la
directiva subyacente.
Eliminación de una dirección

En este ejemplo eliminará la entrada de la dirección “Sunnyvale_SW_Eng”.
WebUI
Policy > Policy Elements > Addresses > List: Haga clic en Remove en la
columna “Configure” para “Sunnyvale_SW_Eng”.
CLI
unset address trust “Sunnyvale_SW_Eng”
save
Grupos de direcciones
En “Entradas de direcciones” en la página 104 se explica cómo crear, modificar y
eliminar las entradas en la libreta de direcciones correspondientes a los diferentes
hosts y subredes. Según se vayan agregando direcciones a una lista de direcciones,
se hará más difícil controlar cómo las directivas afectan a cada entrada de
dirección. ScreenOS le permite crear grupos de direcciones. En lugar de administrar
un gran número de entradas de direcciones, puede administrar un pequeño
número de grupos. Los cambios que efectúe al grupo se aplicarán a todas las
entradas de direcciones que lo componen.
Direcciones 105
Figura 48: Grupos de direcciones

1 directiva por dirección 1 directiva por grupo de direcciones
Directiva
Dirección
acceso
del nombre
Name
Name
Address
Directiva Name
Dirección Address
acceso Address
del nombre Directiva
acceso
Dirección Directiva
del nombre acceso
La opción de grupo de direcciones tiene las siguientes características:
Puede crear grupos de direcciones en cualquier zona.
Puede crear grupos de direcciones con los usuarios existentes, o bien crear
grupos de direcciones vacíos e introducir posteriormente los usuarios.
Un grupo de direcciones puede ser miembro de otro grupo de direcciones.
NOTA: Para asegurarse de que un grupo no se incluya accidentalmente a sí mismo como

miembro, el dispositivo de seguridad realiza una comprobación de coherencia
cada vez que agrega un grupo a otro. Por ejemplo, si agrega el grupo A como
miembro del grupo B, el dispositivo de seguridad automáticamente verifica que A
no incluya a B como miembro.
En una directiva se puede hacer referencia a una entrada de grupo de

direcciones igual que a una entrada individual en la libreta de direcciones.
ScreenOS aplica las directivas a cada miembro del grupo creando internamente
directivas individuales para cada miembro del grupo. Aunque usted solamente
tiene que crear una directiva para un grupo, en realidad ScreenOS crea una
directiva interna para cada miembro del grupo (así como para cada servicio
configurado para cada usuario).
106 Direcciones
NOTA: La forma automática en la que el dispositivo de seguridad aplica directivas a cada

miembro del grupo de direcciones evita que tenga que crear una por una para
cada dirección. Además, ScreenOS escribe estas directivas en ASIC, lo cual acelera
considerablemente las consultas.
Cuando elimina de la libreta de direcciones una entrada individual, el

dispositivo de seguridad la elimina automáticamente de todos los grupos a los
que perteneció.
Los grupos de direcciones tienen las siguientes limitaciones:
Los grupos de direcciones solamente pueden contener direcciones que

pertenezcan a la misma zona.
Los nombres de direcciones no pueden coincidir con nombres de grupos. Si se

utiliza el nombre “Paris” para una entrada de dirección individual, no se puede
utilizar para un nombre de grupo.
No se pueden eliminar los grupos a los que se haga referencia en directivas. No

obstante, estos grupos pueden ser editados.
Cuando se asigna una directiva individual a un grupo de direcciones, ésta se

aplica de forma individual a cada miembro del grupo y el dispositivo de
seguridad genera una entrada para cada miembro en la lista de control de
accesos (ACL). Si el usuario no está pendiente, se puede exceder el número de
recursos de directivas disponibles, especialmente si tanto la dirección de origen
como la de destino son grupos de direcciones y el servicio especificado es un
grupo de servicios.
No se pueden agregar a grupos las direcciones predefinidas: “Any”, “All Virtual

IPs” ni “Dial-Up VPN”.
Creación de un grupo de direcciones

En el ejemplo siguiente creará un grupo denominado “Planta 2 Central” que
contendrá las dos direcciones “Ing Santa Clara” y “Publicaciones”, que ya habrá
introducido en la libreta de direcciones para la zona Trust.
WebUI
Policy > Policy Elements > Addresses > Groups > (para Zone: Trust) New:
Introduzca el siguiente nombre de grupo, mueva las siguientes direcciones y
haga clic en OK:
Group Name: Planta 2 Central
Seleccione Ing Santa Clara y utilice el botón << para trasladar la

dirección de la columna “Available Members” a la columna “Group
Members”.
Seleccione Publicaciones y utilice el botón << para trasladar la dirección

de la columna “Available Members” a la columna “Group Members”.
Direcciones 107
CLI
set group address trust “Planta 2 Central” add “Ing Santa Clara”
set group address trust “Planta 2 Central” add “Publicaciones”
save
Edición de una entrada de grupo de direcciones

En este ejemplo agregará “Asistencia” (una dirección que ya habrá introducido en la
libreta de direcciones) al grupo de direcciones “Planta 2 Central”.
WebUI
Policy > Policy Elements > Addresses > Groups > (para Zone: Trust) Edit
(para “Planta 2 Central”): Mueva la siguiente dirección, luego haga clic en OK:
Seleccione Asistencia y utilice el botón << para trasladar la dirección de

la columna “Available Members” a la columna “Group Members”.
CLI
set group address trust “Planta 2 Central” add Asistencia
save
Eliminación de un miembro y un grupo

En este ejemplo elimina el miembro “Asistencia” del grupo de direcciones “Planta 2
central” y elimina “Ventas”, un grupo de direcciones que creó previamente.
WebUI
Policy > Policy Elements > Addresses > Groups > (para Zone: Trust) Edit
(“Planta 2 Central”): Mueva la siguiente dirección, luego haga clic en OK:
Seleccione Asistencia y utilice el botón >> para trasladar la dirección de

la columna “Group Members” a la columna “Available Members”.
Policy > Policy Elements > Addresses > Groups > (Zone: Trust): Haga clic
en Remove en la columna “Configure” para “Ventas”.
CLI
unset group address trust “Planta 2 Central” remove Asistencia
unset group address trust Ventas
save
NOTA: El dispositivo de seguridad no elimina automáticamente un grupo del que haya

eliminado todos los nombres.
108 Direcciones
Servicios
Los servicios son tipos de tráfico para los que existen estándares de protocolos.
Cada servicio tiene asociados un protocolo de transporte y uno o varios números de
puertos de destino, como el puerto TCP nº 21 para FTP y el puerto TCP nº 23 para
Telnet. Al crear una directiva se debe especificar un servicio para ella. Puede
seleccionar uno de los servicios predefinidos del libro de servicios, o bien un
servicio personalizado o grupo de servicios que haya creado. Puede ver el servicio
que puede utilizar en una directiva en la lista desplegable Service de la página de
configuración de directivas (WebUI) o al utilizar el comando get service (CLI).
Servicios predefinidos
Puede visualizar la lista de servicios predefinidos o personalizados o bien los grupos
de servicios en el dispositivo de seguridad mediante WebUI o CLI.
Mediante WebUI:
Policy > Policy Elements > Services > Predefined
Policy > Policy Elements > Services > Custom
Policy > Policy Elements > Services > Groups
Mediante CLI:
get service [ group | predefined | user ]
NOTA: Cada servicio predefinido tiene un rango de puertos de origen entre 1 y 65535,
que abarca todo el conjunto de números de puerto válidos. Esto evita que posibles
atacantes obtengan acceso a través de un puerto de origen que se encuentre fuera
del rango. Si necesita utilizar un rango de puertos de origen distinto para cualquier
servicio predefinido, cree un servicio personalizado. Para obtener información,
consulte “Servicios personalizados” en la página 122.
Esta sección incluye información acerca de los siguientes servicios predefinidos:
“Protocolo de mensajes de control de Internet” en la página 110
“Servicios predefinidos relacionados con Internet” en la página 113
“Servicios de llamadas de procedimiento remoto de Microsoft” en la página 115
“Protocolos de enrutamiento dinámico” en la página 117
“Vídeo de secuencias” en la página 117
“Servicios de llamadas de procedimiento remoto de Sun” en la página 118
“Servicios de túnel y seguridad” en la página 119
“Servicios relacionados con IP” en la página 119
“Servicios de mensajes instantáneos” en la página 120
Servicios 109
“Servicios de administración” en la página 120
“Servicios de correo” en la página 121
“Servicios UNIX” en la página 121
“Servicios varios” en la página 122
Encontrará información más detallada acerca de algunos de los servicios

enumerados en las siguientes páginas:
“Definición de un servicio personalizado de protocolo de mensajes de control

de Internet” en la página 127
“ALG de Shell remoto” en la página 128
“Capa de aplicación de llamada al procedimiento remoto de Sun” en la

página 129
“Personalización del procedimiento remoto de Microsoft Call ALG” en la

página 130
“Puerta de enlace de la capa de aplicación del protocolo de secuencias en

tiempo real” en la página 132
Protocolo de mensajes de control de Internet

El protocolo de mensajes de control de Internet (ICMP) es una parte del protocolo
de Internet (IP) y permite realizar consultas en una red (mensajes de consulta del
ICMP) y recibir retroalimentación de la red para obtener patrones de error
(mensajes de error del ICMP). Sin embargo, el ICMP no garantiza el envío de los
mensajes de error ni informa sobre todos los datagramas perdidos, y no es un
protocolo fiable. El código ICMP y los códigos de tipos describen los mensajes de
consulta del ICMP y los mensajes de error del ICMP.
Puede optar por permitir o rechazar algunos o determinados tipos específicos de

mensajes del ICMP para mejorar la seguridad de la red. Algunos tipos de mensajes
del ICMP se pueden explotar para obtener información acerca de su red y pueden
comprometer la seguridad de la misma. Por ejemplo, los paquetes ICMP, TCP o UDP
se pueden construir de tal forma que devuelvan mensajes de error del ICMP que
contienen información acerca de una red, como su topología, listas de acceso y
características de filtrado. En la Tabla 8 en la página 111 se enumeran los nombres
de mensaje de ICMP, el código, tipo y descripción correspondientes.
110 Servicios
Tabla 8: Información de ICMP
Nombre de mensajes
del ICMP Tipo Código Descripción
ICMP-ANY todos todos ICMP-ANY afecta a cualquier protocolo que utilice el ICMP.
Al rechazar ICMP-ANY se impide cualquier intento de ejecutar el comando ping o
de supervisar una red por medio del ICMP.
Al permitir ICMP-ANY se autorizan todos los mensajes del ICMP.
ICMP-ADDRESS-MASK La consulta de máscara de dirección del ICMP es utilizada por los sistemas que
Request (solicitud) 17 0 necesitan la máscara de la subred local de un servidor bootstrap.
Rechazar los mensajes de solicitud de máscara de direcciones de ICMP puede
Reply (respuesta) 18 0
afectar a los sistemas sin disco.
Al permitir los mensajes de solicitud de máscara de direcciones del ICMP puede
permitir que otros detecten la huella dactilar del sistema operativo de un host en su
red.
ICMP-DEST-UNREACH 3 0 El mensaje de error de destino inalcanzable del ICMP indica que el host de destino
está configurado para rechazar los paquetes.
Los códigos 0, 1, 4 ó 5 pueden provenir de una puerta de enlace. Los códigos 2 ó 3,
de un host (RFC 792).
Al rechazar los mensajes de error de destino inalcanzable del ICMP se impide que
otros usuarios puedan deducir que un host está en línea y en ejecución detrás del
dispositivo de seguridad.
Al permitir los mensajes de error de destino inalcanzable del ICMP, puede facilitar
que se deduzcan datos acerca de la red tales como los filtros de seguridad.
ICMP Fragment Needed 3 4 El mensaje de error de fragmentación del ICMP indica que es necesaria la
fragmentación pero no está establecido el indicador de fragmentos.
Se recomienda rechazar estos mensajes de Internet (untrust) hacia la red fiable.
ICMP Fragment 11 1 El error de tiempo excedido de reensamblaje del fragmento ICMP indica que un
Reassembly host excedió el tiempo en el reensamblaje de un fragmento y descartó el paquete.
Algunas veces se envía este mensaje.
ICMP-HOST- 3 1 Los mensajes de error de host inalcanzable del ICMP indican que las entradas de la
UNREACH tabla de enrutamiento no enumeran un host particular, o lo enumeran como
infinito. Algunas veces este error lo envían las puertas de enlace que no pueden
fragmentar cuando reciben un paquete que necesita fragmentación.
Al permitir estos mensajes se permite que otros puedan determinar las direcciones
IP de sus hosts internos por medio de un proceso de eliminación, o que realicen
deducciones acerca de las puertas de enlace y de la fragmentación.
ICMP-INFO Los mensajes de consulta de ICMP-INFO permiten que los sistemas de host sin
Request (solicitud) 15 0 disco consulten la red y se configuren a sí mismos.
Rechazar los mensajes de solicitud de máscara de direcciones de ICMP puede
afectar de manera desfavorable a los sistemas sin disco.
Si se permiten los mensajes de consulta de máscara de direcciones de ICMP, otros
pueden transmitir consultas de información hacia un segmento de red para
determinar el tipo de computadora.
ICMP-PARAMETER- 12 0 Los mensajes de error de problemas de parámetros de ICMP avisan cuando hay
PROBLEM parámetros incorrectos de encabezado y provocan que se descarte un paquete.
Se recomienda rechazar estos mensajes de Internet (untrust) hacia una red fiable.
Si se permiten mensajes de error de problemas de parámetros de ICMP, otros
usuarios pueden deducir datos acerca de su red.
Servicios 111
Tabla 8: Información de ICMP (Continuación)
Nombre de mensajes
ICMP-PORT-UNREACH 3 3 Los mensajes de error de puerto inalcanzable indican que los datagramas de
procesamiento de puertas de enlace que solicitan determinados puertos, no están
disponibles o no son compatibles en la red.
Si se permiten los mensajes de error de puerto inalcanzable, otros pueden
determinar los puertos que se utilizan para determinados protocolos.
ICMP-PROTOCOL- 3 2 Los mensajes de error de protocolo ICMP indican que los datagramas de
UNREACH procesamiento de puertas de enlace que solicitan determinados protocolos, no
están disponibles o no son compatibles en la red.
Si se permiten los mensajes de error de protocolo inalcanzable de ICMP, otros
pueden determinar los protocolos que su red está ejecutando.
ICMP-REDIRECT 5 0 Los enrutadores envían los mensajes de error de red de desvío de ICMP.
ICMP-REDIRECT-HOST 5 1 Los mensajes de desvío de ICMP indican los datagramas destinados para que un
host específico los envíe por otra ruta.
ICMP-REDIRECT-TOS- 5 3 ICMP Redirect Type of Service (TOS) y Host Error son un tipo de mensaje.
HOST
ICMP-REDIRECT-TOS- 5 2 ICMP Redirect Type of Service (TOS) y Host Error son un tipo de mensaje.
NET
ICMP-SOURCE- 4 0 El mensaje de error de desconexión de origen de ICMP indica que un enrutador no
QUENCH tiene el espacio de búfer disponible para aceptar, consultar y enviar los paquetes
en el siguiente salto.
Rechazar estos mensajes no ayudará ni impedirá el funcionamiento interno de la
red.
Si se permiten estos mensajes, otros pueden saber que un enrutador se encuentra
congestionado y lo convierte en objetivo viable de ataque.
ICMP-SOURCE-ROUTE- 3 5 Mensaje de error de ruta de origen con fallo de ICMP
FAIL Se recomienda rechazar estos mensajes de Internet (untrust).
ICMP-TIME-EXCEEDED 11 0 El mensaje de error de tiempo de vida (TTL) excedido de ICMP indica que el ajuste
del TTL del paquete llegó a cero antes de que el paquete llegara a su destino. Esto
garantiza que los paquetes anteriores se desechen antes de que se procesen los
reenviados.
Se recomienda rechazar estos mensajes de una red fiable hacia la Internet.
ICMP-TIMESTAMP Los mensajes de consulta ICMP-TIMESTAMP proporcionan el mecanismo para
Request (solicitud) 13 0 sincronizar la hora y coordinar la distribución de la hora en una red amplia y
diversa.
112 Servicios
Tabla 8: Información de ICMP (Continuación)
Nombre de mensajes
Ping (ICMP ECHO) 8 0 El capturador de paquetes de Internet (Groper) es una utilidad para determinar si
un host específico es accesible por medio de su respuesta de eco de la dirección
0/0.
Si se rechaza la funcionalidad del comando ping, se elimina su capacidad para
verificar si un host está activo.
Si se permite el comando ping, otros pueden ejecutar una denegación de servicio
(DoS) o un ataque Smurf.
ICMP-ECHO- 11 1 El mensaje de error Fragment Echo Reassembly Time Expired de ICMP indica que
FRAGMENT-ASSEMBLY- se superó el tiempo de reensamblaje.
EXPIRE Se recomienda rechazar estos mensajes.
Traceroute Traceroute es una utilidad para indicar la ruta para acceder a un host específico.
Forward (reenviar) 30 0 Se recomienda rechazar esta utilidad de Internet (untrust) hacia su red (trust)
interna.
Discard (descartar) 30 1
Manejo de errores de destinos inalcanzables de ICMP

El comportamiento predeterminado de los distintos niveles de seguridad para los
errores de destinos inalcanzables de ICMP desde los enrutadores de sentido
descendente se gestiona de la siguiente forma:
Las sesiones no se cierran para los mensajes tipo 3 código 4 de ICMP.
Los mensajes de ICMP pasan sin descartar las sesiones. Sin embargo, los
paquetes se descartan en cada sesión.
Las sesiones no se cierran al recibir cualquier tipo de mensajes de destinos

inalcanzables de ICMP.
Las sesiones almacenan mensajes de destinos inalcanzables de ICMP, por lo

que restringen la cantidad de mensajes que fluyen para que sólo pueda fluir 1
mensaje.
Se genera globalmente un mensaje de destino inalcanzable de ICMP por

dispositivo. Los errores de destinos inalcanzables de ICMP restantes se
descartan.
Servicios predefinidos relacionados con Internet

La Tabla 9 enumera los servicios predefinidos relacionados con Internet. Es posible
elegir si permite o rechaza alguno o todos estos servicios, y dependerá de sus
requisitos de red. Cada entrada enumera el nombre del servicio, el puerto de
recepción predeterminado y la descripción del servicio.
Servicios 113
Tabla 9: Servicios predefinidos
Nombre del servicio Puertos Descripción del servicio

AOL 5190-5193 El proveedor de servicios de Internet (ISP) America Online proporciona los servicios
de Internet, chat y mensajes instantáneos.
DHCP-Relay 67 Configuración de host dinámico
(predetermi
nado)
DHCP 68 (cliente) El protocolo de configuración dinámica de host asigna direcciones de red y entrega
67 parámetros de configuración desde el servidor hacia los hosts.
(servidor)
DNS 53 El sistema de nombres de dominio traduce los nombres de dominios en direcciones
de IP.
FTP El protocolo de transferencia de archivos (FTP) permite el envío y la recepción de
FTP-Get 20 (datos) archivos entre equipos. Es posible optar por rechazar o permitir ANY (GET o PUT),
o bien, permitir o rechazar selectivamente por GET o PUT. GET recibe archivos de
FTP-Put 21 (control) otros equipos y PUT envía archivos a otro equipo.
Recomendamos que se rechacen servicios de FTP provenientes de fuentes no fiables
(Internet).
Gopher 70 Gopher organiza y presenta el contenido de servidores de Internet como una lista de
archivos estructurada jerárquicamente.
Recomendamos que rechace el acceso a Gopher para evitar la exposición de la
estructura de su red.
HTTP 8080 El protocolo de transferencia de hipertexto es el protocolo subyacente que utiliza la
World Wide Web (WWW).
Al rechazar el servicio HTTP se deshabilita la capacidad que tienen los usuarios para
ver Internet.
Si se permite el servicio HTTP, se permite que sus hosts fiables vean Internet.
HTTP-EXT — El protocolo de transferencia de hipertexto con puertos extendidos no estándar
HTTPS 443 El protocolo de transferencia de hipertexto con nivel de sockets seguro (SSL) es un
protocolo para transmitir documentos privados a través de Internet.
Si se rechaza HTTPS, sus usuarios quedan inhabilitados para comprar en Internet y
para acceder a determinados recursos en línea que requieren intercambios de
contraseñas de seguridad.
Al permitir HTTPS, se le permite a sus hosts fiables participar en intercambios de
contraseñas, comprar en línea y visitar varios recursos en línea protegidos que
requieren inicio de sesión de parte del usuario.
Internet Locator Service — El servicio de localizador de Internet incluye LDAP, servicio de localizador para el
usuario y LDAP sobre TSL/SSL.
IRC 6665-6669 El chat de retransmisión de Internet (IRC) permite a las personas conectadas a
Internet unirse a discusiones activas.
LDAP 389 El protocolo ligero de acceso a directorios es un conjunto de protocolos utilizado para
obtener acceso a directorios de información.
PC-Anywhere — PC-Anywhere es un software de transferencia de archivos y control remoto.
TFTP 69 TFTP es un protocolo para transferencias sencillas de archivos.
WAIS — El servidor de información de área extensa es un programa que encuentra
documentos en Internet.
114 Servicios
Servicios de llamadas de procedimiento remoto de Microsoft

La Tabla 10 enumera los servicios de Microsoft predefinidos, los parámetros
asociados con cada servicio y una breve descripción de cada uno. Los parámetros
incluyen los identificadores únicos universales (UUID) y los puertos de origen y de
destino de TCP/UDP. Un UUID es un número único de 128 bits generado desde una
dirección de hardware, una marca de hora y valores de inicialización.
Tabla 10: Servicios de Microsoft
Servicio Parámetro/UUID Descripción

MS-RPC-EPM 135 Protocolo Remote Procedure Call (RPC) Endpoint
e1af8308-5d1f-11c9-91a4-08002b14a0fa Mapper (EPM) de Microsoft
MS-RPC-ANY — Cualesquiera servicios Remote Procedure Call

(RPC) de Microsoft
MS-AD 4 miembros Active Directory Service Group de Microsoft
incluye:
MS-AD-BR
MS-AD-DRSUAPI
MS-AD-DSROLE
MS-AD-DSSETUP
MS-EXCHANGE 6 miembros Exchange Service Group de Microsoft incluye:

MS-EXCHANGE-DATABASE
MS-EXCHANGE-DIRECTORY
MS-EXCHANGE-INFO-STORE
MS-EXCHANGE-MTA
MS-EXCHANGE-STORE
MS-EXCHANGE-SYSATD
MS-IIS 6 miembros IIS Service Service Group de Microsoft incluye:

MS-IIS-COM
MS-IIS-IMAP4
MS-IIS-INETINFO
MS-IIS-NNTP
MS-IIS-POP3
MS-IIS-SMTP
MS-AD-BR ecec0d70-a603-11d0-96b1-00a0c91ece30 Servicios de copia de seguridad y restauración de

16e0cf3a-a604-11d0-96b1-00a0c91ece30 Active Directory de Microsoft
MS-AD-DRSUAPI e3514235-4b06-11d1-ab04-00c04fc2dcd2 Servicio de replicación de Active Directory de

Microsoft
MS-AD-DSROLE 1cbcad78-df0b-4934-b558-87839ea501c9 Servicio DSROLE de Active Directory de Microsoft
MS-AD-DSSETUP 3919286a-b10c-11d0-9ba8-00c04fd92ef5 Servicio de configuración de Active Directory de
Microsoft
MS-DTC 906b0ce0-c70b-1067-b317-00dd010662da Servicio distribuido de coordinación de
transacciones Distributed Transaction Coordinator
de Microsoft
MS-EXCHANGE-DATABASE 1a190310-bb9c-11cd-90f8-00aa00466520 Servicio de base de datos de Microsoft Exchange
Servicios 115
Tabla 10: Servicios de Microsoft (Continuación)

MS-EXCHANGE-DIRECTORY f5cc5a18-4264-101a-8c59-08002b2f8426 Servicio de directorios de Microsoft Exchange
f5cc5a7c-4264-101a-8c59-08002b2f8426
f5cc59b4-4264-101a-8c59-08002b2f8426
MS-EXCHANGE-INFO-STORE 0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde Servicio de almacenamiento de información
1453c42c-0fa6-11d2-a910-00c04f990f3b Microsoft Exchange Information Store
10f24e8e-0fa6-11d2-a910-00c04f990f3b
1544f5e0-613c-11d1-93df-00c04fd7bd09
MS-EXCHANGE-MTA 9e8ee830-4459-11ce-979b-00aa005ffebe Servicio Exchange MTA de Microsoft
38a94e72-a9bc-11d2-8faf-00c04fa378ff
MS-EXCHANGE-STORE 99e66040-b032-11d0-97a4-00c04fd6551d Servicio de almacén de Microsoft Exchange
89742ace-a9ed-11cf-9c0c-08002be7ae86
a4f1db00-ca47-1067-b31e-00dd010662da
a4f1db00-ca47-1067-b31f-00dd010662da
MS-EXCHANGE-SYSATD 67df7c70-0f04-11ce-b13f-00aa003bac6c Servicio System Attendant de Microsoft Exchange
f930c514-1215-11d3-99a5-00a0c9b61b04
83d72bf0-0d89-11ce-b13f-00aa003bac6c
469d6ec0-0d87-11ce-b13f-00aa003bac6c
06ed1d30-d3d3-11cd-b80e-00aa004b9c30
MS-FRS f5cc59b4-4264-101a-8c59-08002b2f8426 Servicio de replicación de archivos de Microsoft
d049b186-814f-11d1-9a3c-00c04fc9b232
a00c021c-2be2-11d2-b678-0000f87a8f8e
MS-IIS-COM 70b51430-b6ca-11d0-b9b9-00a0c922e750 Servicio COM GUID/UUID de Microsoft Internet
a9e69612-b80d-11d0-b9b9-00a0c922e70 Information Server
MS-IIS-IMAP4 2465e9e0-a873-11d0-930b-00a0c90ab17c Servicio IMAP4 de Microsoft Internet Information

Server
MS-IIS-INETINFO 82ad4280-036b-11cf-972c-00aa006887b0 Servicio Internet Information Server
Administration de Microsoft
MS-IIS-NNTP 4f82f460-0e21-11cf-909e-00805f48a135 Servicio NNTP de Microsoft Internet Information
Server
MS-IIS-POP3 1be617c0-31a5-11cf-a7d8-00805f48a135 Servicio POP3 de Microsoft Internet Information
Server
MS-IIS-SMTP 8cfb5d70-31a4-11cf-a7d8-00805f48a135 Servicio SMTP de Microsoft Internet Information
Server
MS-ISMSERV 68dcd486-669e-11d1-ab0c-00c04fc2dcd2 Servicio Microsoft Inter-site Messaging
130ceefb-e466-11d1-b78b-00c04fa32883
MS-MESSENGER 17fdd703-1827-4e34-79d4-24a55c53bb37 Servicio Microsoft Messenger
5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc
MS-MQQM fdb3a030-065f-11d1-bb9b-00a024ea5525 Servicio de administración de colas de mensajes
76d12b80-3467-11d3-91ff-0090272f9ea3 Microsoft Windows Message Queue Management
1088a980-eae5-11d0-8d9b-00a02453c33
5b5b3580-b0e0-11d1-b92d-0060081e87f0
41208ee0-e970-11d1-9b9e-00e02c064c39
116 Servicios
Tabla 10: Servicios de Microsoft (Continuación)

MS-NETLOGON 12345678-1234-abcd-ef00-01234567cffb Servicio Microsoft Netlogon
MS-SCHEDULER 1ff70682-0a51-30e8-076d-740be8cee98b Servicio Microsoft Scheduler
378e52b0-c0a9-11cf-822d-00aa0051e40f
0a74ef1c-41a4-4e06-83ae-dc74fb1cdd53
MS-WIN-DNS 50abc2a4-574d-40b3-9d66-ee4fd5fba076 Servidor DNS de Microsoft Windows
MS-WINS 45f52c28-7f9f-101a-b52b-08002b2efabe Servicio WINS de Microsoft
811109bf-a4e1-11d1-ab54-00a0c91e9b45
Protocolos de enrutamiento dinámico

Dependiendo de sus requisitos de red, puede optar por permitir o rechazar los
mensajes generados y los paquetes de estos protocolos de enrutamiento dinámico.
La Tabla 11 enumera cada uno de los protocolos de enrutamiento dinámicos
compatibles por nombre, puerto y descripción.
Tabla 11: Protocolo de enrutamiento dinámico
Protocolo de enrutamiento
dinámico Puerto Descripción
RIP 520 RIP es un protocolo de enrutamiento de vector de
distancia común.
OSPF 89 OSPF es un protocolo de enrutamiento de estado
de conexión común.
BGP 179 BGP es un protocolo de enrutamiento exterior/entre
dominios.
Vídeo de secuencias
La Tabla 12 enumera por nombre cada servicio de vídeo de secuencias compatible
e incluye el puerto predeterminado y la descripción. Es posible elegir si permite o
rechaza alguno o todos estos servicios, y dependerá de sus requisitos de red.
Tabla 12: Servicios de vídeo de secuencias
Servicio Puerto Descripción

H.323 TCP origen 1-65535; TCP destino 1720, H.323 es una norma aprobada por la Unión Internacional de
1503, 389, 522, 1731 Telecomunicaciones (ITU), la cual define cómo se transmiten los
UDP origen 1-65535; UDP origen 1719 datos de las conferencias audiovisuales a través de las redes.
NetMeeting TCP origen 1-65535; TCP destino 1720, Microsoft NetMeeting utiliza TCP para proporcionar servicios de
1503, 389, 522 teleconferencias (vídeo y sonido) sobre Internet.
UDP origen 1719
Real media TCP origen 1-65535; TCP destino 7070 Real Media es una tecnología de sonido y vídeo de secuencias.
RTSP 554 El protocolo de secuencias en tiempo real (RTSP) para aplicaciones
de medios de secuencias.
SIP 5056 El protocolo de inicio de sesión (SIP) es un protocolo de control del
nivel de aplicación para crear, modificar y terminar sesiones.
VDO Live TCP origen 1-65535; TCP destino 7000-7010 VDOLive es una tecnología de secuencia de vídeos con posibilidad
de ampliación.
Servicios 117
Servicios de llamadas de procedimiento remoto de Sun

La Tabla 13 enumera el nombre del servicio, los parámetros y el nombre completo
de cada puerta de enlace de aplicación de llamada a procedimiento remoto (RPC
ALG, Remote Procedure Call Application Layer Gateway) de Sun.
Tabla 13: Servicios de RPC ALG
Números del
Servicio programa Nombre completo
SUN-RPC-PORTMAPPER 111 Protocolo de asignación de puertos RPC de
100000 Sun
SUN-RPC-ANY ANY Cualquier servicio Sun RPC
SUN-RPC-PROGRAM-MOUNTD 100005 Demonio de montaje Sun RPC Mount
Daemon
SUN-RPC-PROGRAM-NFS 100003 Sistema de archivos en red Sun RPC
100227 Network File System
SUN-RPC-PROGRAM-NLOCKMGR 100021 Administrador de bloqueos de red Sun RPC

Network Lock Manager
SUN-RPC-PROGRAM-RQUOTAD 100011 Demonio de cuotas remotas Sun RPC
Remote Quota Daemon
SUN-RPC-PROGRAM-RSTATD 100001 Demonio de estado remoto Sun RPC
Remote Status Daemon
SUN-RPC-PROGRAM-RUSERD 100002 Demonio de usuarios remotos Sun RPC
Remote User Daemon
SUN-RPC-PROGRAM-SADMIND 100232 Demonio de administración del sistema
Sun RPC System Administration Daemon
SUN-RPC-PROGRAM-SPRAYD 100012 Demonio Sun RPC SPRAY Daemon
SUN-RPC-PROGRAM-STATUS 100024 Sun RPC STATUS
SUN-RPC-PROGRAM-WALLD 100008 Demonio Sun RPC WALL Daemon
SUN-RPC-PROGRAM-YPBIND 100007 Yellow Page Bind Service de Sun RPC
118 Servicios
Servicios de túnel y seguridad

La Tabla 14 enumera cada servicio compatible y proporciona los puertos
predeterminados y una descripción de cada entrada.
Tabla 14: Servicios de protocolo compatibles

IKE UDP origen 1-65535; UDP IKE es un protocolo que permite obtener material
destino 500 de claves autenticado para utilizarlo con ISAKMP.
4500 (para NAT traversal) Cuando se configura IKE automática, es posible
elegir entre tres propuestas fase 1 ó fase 2
predefinidas:
Estándar: AES y 3DES
Básicas: DES y dos distintos tipos de algoritmos
de autenticación
Compatibles: cuatro algoritmos de autenticación
y encriptación comúnmente utilizados
L2TP 1723 L2TP combina PPTP con capa 2 de desvío (L2F)
para acceso remoto.
PPTP — El protocolo de encapsulamiento punto a punto
permite a las empresas ampliar su propia red
privada por medio de túneles privados sobre la
Internet pública.
Servicios relacionados con IP

La Tabla 15 enumera los servicios predefinidos relacionados con IP. Cada entrada
incluye el puerto predefinido y una descripción del servicio.
Tabla 15: Servicios relacionados con IP

Any — Cualquier servicio
TCP-ANY 1-65535 Cualquier protocolo que utilice el protocolo de control de transporte
TCPMUX puerto 1
UDP-ANY 137 Cuaquier protocolo que utilice el protocolo de datagramas de usuarios
Servicios 119
Servicios de mensajes instantáneos

La Tabla 16 enumera los servicios predefinidos de mensajería de Internet. Cada
entrada incluye el nombre del servicio, el puerto predeterminado o asignado y una
descripción del servicio.
Tabla 16: Servicios de mensajería de Internet

Gnutella 6346 El protocolo de distribución de archivos Gnutella es un protocolo de distribución de archivos
(predeterminado) de dominio público que opera sobre una red distribuida. Puede asignar cualquier puerto, pero
el predeterminado es 6346.
MSN 1863 Network Messenger de Microsoft es una utilidad que le permite enviar mensajes instantáneos
y hablar en línea.
NNTP 119 El protocolo de transporte de noticias en red se utiliza para publicar, distribuir y recuperar
mensajes de USENET.
SMB 445 El protocolo de bloqueo de mensajes del servidor (SMB) por IP permite leer y escribir archivos
en un servidor en una red.
YMSG 5010 Yahoo! Messenger es una utilidad que le permite verificar cuando hay otras personas en línea,
enviar mensajes instantáneos y hablar en línea.
Servicios de administración
La Tabla 17 enumera los servicios predefinidos de administración. Cada entrada
incluye el nombre del servicio, el puerto predeterminado o asignado y una
descripción del servicio.
Tabla 17: Servicios de administración

NBNAME 137 El servicio de nombres de NetBIOS muestra todos los paquetes de nombres de NetBIOS
enviados en UPD puerto 137.
NDBDS 138 El servicio de datagramas de NetBIOS, publicado por IBM, proporciona servicios sin
conexión (datagramas) para los equipos conectados con un medio de difusión para
localizar recursos, iniciar y terminar sesiones. No es fiable y los paquetes no están en
secuencia.
NFS — El sistema de archivos de red utiliza UDP para permitir a los usuarios de la red acceder a
archivos distribuidos almacenados en computadoras de distintos tipos. SUN RPC es un
módulo de NFS.
NS Global — NS-Global es el protocolo de administración central para los dispositivos cortafuegos/VPN
de Juniper Networks.
NS Global PRO — NS Global-PRO es el sistema de supervisión con posibilidad de ampliación para la familia
de dispositivos cortafuegos/VPN de Juniper Networks.
NSM — NetScreen-Security Manager
NTP 123 El protocolo de hora de red proporciona una forma de sincronizar las computadoras
respecto a una hora de referencia.
RLOGIN 513 RLOGIN inicia una sesión terminal en un host remoto.
RSH 514 RSH ejecuta un comando shell en un host remoto.
SNMP 161 El protocolo sencillo de administración de redes es un conjunto de protocolos para
administrar redes complejas.
SQL*Net V1 66 SQL*Net versión 1 es un lenguaje de base de datos que permite la creación, el acceso, la
modificación y la protección de datos.
120 Servicios
Tabla 17: Servicios de administración (Continuación)

SQL*Net V2 66 SQL*Net versión 2 es un lenguaje de base de datos que permite la creación, el acceso, la
modificación y la protección de datos.
MSSQL 1433 (caso Microsoft SQL es una herramienta servidora de bases de datos propiedad de Microsoft
predeterminado) que permite la creación, el acceso, la modificación y la protección de datos.
SSH 22 Secure Shell es un programa para iniciar sesión en otra computadora a través de una red
por medio de una autenticación fuerte y comunicaciones seguras sobre un canal sin
seguridad.
SYSLOG 514 Syslog es un programa de UNIX que envía mensajes al usuario que inició sesión en el
sistema.
Talk 517-518 Talk es un programa de comunicación visual que copia líneas de su terminal a la de otro
usuario.
Telnet 23 Telnet es un programa de UNIX que proporciona un método estándar de dispositivos de
terminal para realizar interfaces y procesos orientados a las terminales entre sí.
WinFrame — WinFrame es una tecnología que permite a los usuarios que trabajan en equipos que no
tienen Windows ejecutar aplicaciones de Windows.
X-Windows — X-Windows es el sistema de gráficos y ventanas en el que se basa Motif y OpenLook.
Servicios de correo
La Tabla 18 enumera los servicios predefinidos de correo. Cada entrada incluye el
nombre del servicio, el puerto predeterminado o asignado y una descripción del
servicio.
Tabla 18: Servicios de correo

IMAP 143 El protocolo de acceso de mensajes de Internet es un protocolo que se utiliza para recuperar
mensajes.
Mail (SMTP) 25 El protocolo sencillo de transferencia de correo (SMTP) permite enviar mensajes entre servidores.
POP3 110 El protocolo de oficina postal es un protocolo que se utiliza para recuperar correo electrónico.
Servicios UNIX
La Tabla 19 enumera los servicios predefinidos de UNIX. Cada entrada incluye el
servicio.
Tabla 19: Servicios UNIX

FINGER 79 Finger es un programa de UNIX que proporciona información acerca de los usuarios.
UUCP 117 El protocolo de copia de Unix a Unix (UUCP) es una utilidad de UNIX que permite las transferencias
de archivos entre dos computadoras por medio de una conexión serie directa o por módem.
Servicios 121
Servicios varios
La Tabla 20 enumera los servicios predefinidos de otro tipo. Cada entrada incluye el
servicio.
Tabla 20: Servicios varios

CHARGEN 19 El protocolo generador de caracteres es una herramienta de medición y depuración basada en
UDP o TCP.
DISCARD 9 El protocolo de descarte es un protocolo de niveles de aplicación que describe un proceso para
descartar datos de TCP o UDP enviados al puerto 9.
IDENT 113 El protocolo de identificación es un protocolo de niveles de aplicación TCP/IP utilizado para la
autenticación de clientes TCP.
LPR 515 listen; Un protocolo de demonio de impresora de líneas es un protocolo basada en TCP utilizado para
721-731 rango servicios de impresión.
de origen
(inclusive)
RADIUS 1812 El servicio de usuarios de acceso telefónico de autenticación remota es un programa servidor
que se utiliza para propósitos de autenticación y contabilidad.
SQLMON 1434 (Puerto de Supervisor de SQL (Microsoft)
supervisión de
SQL)
VNC 5800 La computación de redes virtuales (VNC) facilita la visualización e interacción con otra
computadora o dispositivo móvil conectado a Internet.
WHOIS 43 El protocolo de servicios de directorio de redes es una forma de buscar nombres de dominios.
IPSEC-NAT — IPSEC-NET permite la traducción de direcciones de red para los paquetes ISAKMP y ESP.
SCCP 2000 El protocolo de control de llamadas de estación Cisco utiliza el puerto de control de conexión
de señalización (SCCP) para proporcionar alta disponibilidad y control de flujo.
VOIP — El grupo de servicios de voz sobre IP proporciona servicios de voz sobre Internet e incluye
H.323 y el protocolo de iniciación de sesiones (SIP).
Servicios personalizados
En lugar de utilizar servicios predefinidos, puede crear fácilmente servicios
personalizados. Puede asignar a cada servicio personalizado los atributos
siguientes:
Nombre
Protocolo de transporte
Números de los puertos de origen y de destino para los servicios que utilizan
TCP o UDP
Valores de tipos y códigos para los servicios que utilizan ICMP
Valor del tiempo de espera
122 Servicios
Si crea un servicio personalizado en un sistema virtual (vsys) que tiene el mismo

nombre que un servicio personalizado previamente definido en el sistema raíz, el
servicio en el vsys asume el tiempo de espera predeterminado para el protocolo de
transporte especificado (TCP, UDP o ICMP). Para definir el tiempo de espera
personalizado para un servicio en un vsys distinto del predeterminado cuando un
servicio personalizado con el mismo nombre en el sistema raíz ya disponga de su
propio tiempo de espera, cree el servicio personalizado en el vsys y en el sistema
raíz en el orden siguiente:
1. Primero, cree un servicio personalizado con un tiempo de espera personalizado

en vsys.
2. A continuación, cree otro servicio personalizado con el mismo nombre pero

con otro tiempo de espera en el sistema raíz.
Los ejemplos siguientes describen cómo agregar, modificar y eliminar un servicio

personalizado.
NOTA: Para obtener más información sobre las convenciones de nomenclatura de

ScreenOS (aplicables a los nombres creados para los servicios personalizados),
consulte “Convenciones de interfaz de línea de comandos” en la página x.
Adición de un servicio personalizado

Para agregar un servicio personalizado al libro de servicios se necesita la
información siguiente:
Un nombre para el servicio: en este ejemplo “cust-telnet.”
Un rango de números de puertos de origen: 1 – 65535.
Un rango de números de puertos de destino para recibir la solicitud del servicio:

por ejemplo: 23000 – 23000.
Si el servicio utiliza el protocolo TCP o UDP u otro protocolo compatible con las
especificaciones de Internet. En este ejemplo, el protocolo es TCP.
WebUI
Policy > Policy Elements > Services > Custom > New: Introduzca los
Service Name: cust-telnet

Service Timeout: Custom (seleccione), 30 (escriba)
Transport Protocol: TCP (seleccione)
Source Port Low: 1
Source Port High: 65535
Destination Port Low: 23000
Destination Port High: 23000
CLI
set service cust-telnet protocol tcp src-port 1-65535 dst-port 23000-23000
set service cust-telnet timeout 30
save
Servicios 123
NOTA: El valor del tiempo de espera se expresa en minutos. Si no se establece

expresamente, el valor del tiempo de espera de un servicio personalizado es de
180 minutos. Si no desea que un servicio caduque al cumplirse su tiempo de
espera, introduzca never.
Modificación de un servicio personalizado

En este ejemplo modificará el servicio personalizado “cust-telnet” cambiando el
rango de puertos de destino a 23230-23230.
Utilice el comando set service nombre_del_servicio clear para eliminar la definición

de un servicio personalizado sin eliminar el servicio del libro de servicios:
WebUI
Policy > Policy Elements > Services > Custom > Edit (para cust-telnet):

CLI
set service cust-telnet clear
set service cust-telnet + tcp src-port 1-65535 dst-port 23230-23230
save
Eliminación de un servicio personalizado

En este ejemplo eliminará el servicio personalizado “cust-telnet”.
WebUI
Policy > Policy Elements > Services > Custom: Haga clic en Remove en la
columna “Configure” para “cust-telnet”.
CLI
unset service cust-telnet
save
Establecimiento del tiempo de espera de un servicio

El valor del tiempo de espera que se establece para un servicio, determina el
tiempo de espera de la sesión. Puede ajustar el tiempo de espera para un servicio
predefinido o uno personalizado. Puede utilizar el tiempo de espera
predeterminado del servicio, especificar un tiempo de espera personalizado o no
utilizar tiempo de espera. El comportamiento del tiempo de espera del servicio es el
mismo en dominios de seguridad de sistemas virtuales (vsys) que a nivel de raíz.
124 Servicios
Configuración y consulta del tiempo de espera de un servicio

Los valores de tiempo de espera de los servicios se almacenan en la base de datos
de entradas de servicios en las tablas de tiempos de espera correspondientes que se
basan en TCP y UDP de sistemas virtuales. Cuando se ajusta un valor de tiempo de
espera de un servicio, el dispositivo de seguridad actualiza estas tablas con el valor
nuevo. También existen valores de tiempo de espera predeterminados en las bases
de datos de entrada de servicio, los cuales se toman de servicios predefinidos.
Puede establecer un tiempo de espera pero no puede alterar los valores
predefinidos.
Los servicios que incluyen varias entradas de reglas comparten el mismo valor de
tiempo de espera. Si hay varios servicios que comparte el mismo protocolo y rango
de puertos de destino, todos los servicios comparten el último valor de tiempo de
espera configurado.
En lo que respecta a las entradas de un único servicio, la consulta del tiempo de

espera de un servicio procede de la siguiente forma:
1. El tiempo de espera especificado en la base de datos de entrada de servicio, si

está establecido.
2. El tiempo de espera predeterminado en la base de datos de entradas de

servicio, si se especificó en el servicio predefinido.
3. La tabla de tiempos de espera predeterminados según el protocolo.
Tabla 21: Tabla de tiempo de espera predeterminado según el protocolo
Tiempo de espera
Protocolo predeterminado (minutos)
TCP 30
UDP 1
ICMP 1
OSPF 1
Otro 30
Para los grupos de servicios, incluso los grupos ocultos y creados en configuraciones
de directivas de células múltiples, y para el servicio predefinido “ANY” (si no está
establecido el tiempo de espera), la consulta del tiempo de espera del servicio
procede de la siguiente forma:
1. La tabla de tiempos de espera según el puerto TCP y UDP de vsys, si está

establecido un tiempo de espera.
2. La tabla de tiempos de espera predeterminados según el protocolo.
Servicios 125
Contingencias
Cuando se establecen los tiempos de espera, se debe poner atención en lo
siguiente:
Si un servicio contiene varias entradas de reglas de servicios, todas las entradas

de reglas comparten el mismo tiempo de espera. La tabla de tiempos de espera
se actualiza para cada entrada de regla que coincide con el protocolo (para UPD
y TCP, otros protocolos utilizan el predeterminado). Solamente se debe definir
el tiempo de espera del servicio una sola vez. Por ejemplo, si crea un servicio
con dos reglas, los siguientes comandos establecerán el tiempo de espera en
20 minutos para ambas reglas:
set service test protocol tcp dst-port 1035-1035 timeout 20

set service test + udp src-port 1-65535 dst-port 1111-1111
Si varios servicios están configurados con el mismo protocolo y puertos de

destino superpuestos, el último tiempo de espera de servicio configurado
sobrescribe a los otros en la tabla que está basada en el puerto. Por ejemplo:
set service ftp-1 protocol tcp src 0-65535 dst 2121-2121 timeout 10
set service telnet-1 protocol tcp src 0-65535 dst 2100-2148 timeout 20
Con esta configuración, el dispositivo de seguridad aplica el tiempo de espera

de 20 minutos para el puerto de destino 2121 en un grupo de servicio, ya que
los números del puerto de destino para telnet-1 (2100-2148) se superponen a
los de ftp-1 (2121), y se definió telnet-1 después de definir ftp-1.
Para modificar un tiempo de espera de un servicio cuando varios servicios

utilizan el mismo protocolo y un rango de puertos de destino superpuestos, es
necesario inhabilitar el servicio y restablecerlo con el nuevo valor de tiempo de
espera, ya que durante el reinicio los servicios se cargan según la hora de
creación, no la hora de modificación.
Para evitar la aplicación involuntaria del tiempo de espera incorrecto a un

servicio, no cree servicios con números de puertos de destino superpuestos.
Si se cancela el ajuste de un tiempo de espera de un servicio, se utiliza el

tiempo de espera predeterminado según el protocolo en la base de datos de
entradas de servicios, además de los valores de tiempo de espera, tanto en la
tabla de entradas de servicios como en la tabla de tiempo de espera según el
puerto, se actualizan con el valor predeterminado.
Si el servicio modificado tiene puertos de destino superpuestos con otros

servicios, el tiempo de espera predeterminado según el protocolo puede que no
sea el valor deseado. En dicho caso, reinicie el dispositivo de seguridad,
o ajuste de nuevo el tiempo de espera del servicio para que éste entre en
efecto.
Cuando se modifica un servicio predefinido y se reinicia el sistema, el servicio

modificado puede no aparecer el último en la configuración. Esto es debido a
que los servicios predefinidos se cargan antes de los servicios personalizados,
y cualquier cambio hecho a un servicio personalizado, incluso si se realizó
antes, se mostrará después del cambio del servicio predefinido, cuando
reinicie.
126 Servicios
Por ejemplo, suponga que crea el siguiente servicio:
set service mi_servicio protocol tcp dst-port 179-179 timeout 60
y luego modifica el tiempo de espera del BGP del servicio predefinido según
sigue:
set service bgp timeout 75
el servicio BGP utilizará el valor de tiempo de espera de 75 minutos, ya que no

está escrito en la base de datos de entradas de servicios. Pero el tiempo de
espera para el puerto 179, el que utiliza BGP, también cambia a 75 en la tabla
de tiempos de espera según el puerto. Después de reiniciar, el servicio BGP
seguirá utilizando el tiempo de espera de 75 minutos, el cual, como único
servicio, lo toma de la base de datos de la entrada de servicios. Pero el tiempo
de espera en la tabla según el puerto TCP del puerto 179 ahora será de 60. Es
posible verificar esto introduciendo el comando get service bgp.
Esto no tiene efecto en servicios individuales. Pero si agrega BGP o mi_servicio

a un grupo de servicios, se utilizará el valor de tiempo de espera de 60 minutos
para el puerto de destino 179. Esto es debido a que el tiempo de espera de los
grupos de servicios se toma de la tabla de tiempos de espera según el puerto, si
se ajusta uno.
Para asegurar que se puede pronosticar cuando se modifique un tiempo de

espera predefinido de un servicio, puede crear un servicio similar, por ejemplo:
set service my-bgp protocol tcp dst-port 179-179 timeout 75
Ejemplo
En el siguiente ejemplo cambiará el umbral del tiempo de espera del servicio
predefinido FTP a 75 minutos:
WebUI
Policy > Policy Elements > Services > Predefined > Edit (FTP): Introduzca los
CLI
set service FTP timeout 75
save
Definición de un servicio personalizado de protocolo de mensajes de control de Internet

ScreenOS es compatible con el protocolo de mensajes de control de Internet
(“Internet Control Message Protocol” o “ICMP”) y admite diversos mensajes ICMP,
como servicios predefinidos o personalizados. Al configurar un servicio ICMP
personalizado, deberá definir su tipo y código. Existen diversos tipos de mensajes
ICMP. Por ejemplo:
tipo 0 = mensaje de petición de eco (“Echo Request”)
tipo 3 = mensaje de destino inalcanzable (“Destination Unreachable”)
Servicios 127
NOTA: Para obtener más información sobre los tipos y códigos de ICMP, consulte
RFC 792, Protocolo de mensajes de control de Internet.
Los tipos de mensajes ICMP también pueden tener un código de mensaje. El código
proporciona información más específica acerca del mensaje, como se muestra en la
Tabla 22.
Tabla 22: Descripciones de mensajes
Tipo de mensaje Código de mensaje

5 = Reenviar (“Redirect”) 0 = Reenvía el datagrama de la red (o subred)
1 = Reenvía el datagrama del host
2 = Reenvía el datagrama del tipo de servicio y red
3 = Reenvía el datagrama del tipo de servicio y host
11 = Códigos de tiempo 0 = Tiempo de vida excedido en tránsito (“Time to Live

excedido (“Time Exceeded”) exceeded in Transit”)
1 = Tiempo de reensamblaje de fragmentos excedido
(“Fragment Reassembly Time Exceeded”)
ScreenOS admite cualquier tipo o código dentro del rango 0-255.
En este ejemplo definirá un servicio personalizado denominado “host-unreachable”

que utilizará ICMP como protocolo de transporte. El tipo es 3 (correspondiente a
“Destination Unreachable”) y el código es 1 (“Host Unreachable”). Establecerá el
valor del tiempo de espera en 2 minutos.
WebUI
Policy > Policy Elements > Services > Custom: Introduzca los siguientes datos
y haga clic en OK:
Service Name: host-unreachable

Transport Protocol: ICMP (seleccione)
ICMP Type: 3
ICMP Code: 1
CLI
set service host-unreachable protocol icmp type 5 code 0
set service host-unreachable timeout 2
save
ALG de Shell remoto

La puerta de enlace en la capa de aplicación de Shell remoto (RSH ALG) permite a
los usuarios autenticados ejecutar comandos shell en hosts remotos. Los
dispositivos de seguridad de Juniper Networks admiten el servicio RSH en los
modos tansparente (L2), rutas (L3) y NAT, pero los dispositivos no admiten la
traducción de puertos en el tráfico RSH.
128 Servicios
Capa de aplicación de llamada al procedimiento remoto de Sun

La llamada al procedimiento remoto de Sun (Sun Remote Procedure Call), también
conocida como llamada de procedimiento remoto de computación de redes
abiertas (Open Network Computing Remote Procedure Call u ONC RPC), permite
que un programa que se esté ejecutando en un host ejecute procedimientos de un
programa que se está ejecutando en otro host. Debido al gran número de servicios
RPC y a la necesidad de realizar difusiones broadcast, la dirección de transporte de
un servicio RPC se negocia dinámicamente basándose en el número de programa y
número de versión del servicio. Hay definidos varios protocolos para asignar el
número de programa y el número de versión de RPC a una dirección de transporte.
Los dispositivos de seguridad de Juniper Networks admiten Sun RPC como servicio
predefinido, lo que permite y rechaza el tráfico basándose en una directiva que
usted configure. La puerta de enlace de la capa de aplicación (“application layer
gateway” o ALG) proporciona la funcionalidad necesaria para que los dispositivos de
seguridad puedan manejar el mecanismo dinámico de negociación de direcciones
de transporte de Sun RPC y para asegurar el cumplimiento de las directivas de
cortafuegos basadas en el número de programa. Se puede definir una directiva de
cortafuegos para permitir o denegar todas las peticiones RPC, o bien para permitir
o denegar determinados números de programa. ALG también admite el modo de
rutas y NAT para las peticiones entrantes y salientes.
Situación típica de llamadas RPC

Cuando un cliente llama a un servicio remoto, necesita encontrar la dirección de
transporte del servicio, que en el caso de TCP/UDP es un número de puerto. Un
procedimiento típico para este caso es el siguiente:
1. El cliente envía el mensaje GETPORT al servicio RPCBIND del equipo remoto. El

mensaje GETPORT contiene los números de programa, versión y
procedimiento del servicio remoto que desea ejecutar.
2. El servicio RPCBIND responde con un número de puerto.
3. El cliente llama al servicio remoto usando el número de puerto devuelto.
4. El servicio remoto responde al cliente.
Un cliente también puede utilizar el mensaje CALLIT para llamar al servicio remoto
directamente sin conocer el número de puerto del servicio. En este caso, el
procedimiento es el siguiente:
1. El cliente envía el mensaje CALLIT al servicio RPCBIND del equipo remoto. El

mensaje CALLIT contiene los números de programa, versión y procedimiento
del servicio remoto que desea ejecutar.
2. RPCBIND llama al servicio para el cliente.
3. RCPBIND responde al cliente si la llamada se ha realizado con éxito. La

respuesta contiene el resultado de la llamada y el número de puerto del
servicio.
Servicios 129
Personalización de los servicios de Sun RPC

Dado que los servicios Sun RPC utilizan puertos negociados dinámicamente, no se
pueden utilizar objetos de servicios convencionales basándose en puertos TCP/UDP
fijos para autorizarlos en la directiva de seguridad. Para ello es necesario crear
objetos “sun rpc service” utilizando números de programa. Por ejemplo, NFS utiliza
dos números de programa: 100003 y 100227. Los puertos TCP/UDP
correspondientes son dinámicos. Para permitir los números de programa, cree un
objeto de servicio sun-rpc-nfs que contenga estos dos números. La ALG asignará los
números de programa a puertos TCP/UDP negociados dinámicamente y permitirá o
rechazará el servicio basándose en una directiva que usted configure.
En este ejemplo, creará un objeto de servicio denominado my-sunrpc-nfs para

utilizar el sistema de archivos de red de Sun RPC, identificado por dos
identificadores de programa: 100003 y 100227.
WebUI
Policy > Policy Elements > Services > Sun RPC Services > New: Introduzca
Service Name: my-sunrpc-nfs

Service Timeout: (seleccione)
Program ID Low: 100003
Program ID High: 100003
Program ID Low: 100227
Program ID High: 100227
CLI
set service my-sunrpc-nfs protocol sun-rpc program 100003-100003
set service my-sunrpc-nfs + sun-rpc program 100227-100227
save
Personalización del procedimiento remoto de Microsoft Call ALG

La llamada a procedimiento remoto de Microsoft (“Microsoft Remote Procedure
Call” o MS RPC) es la implementación de Microsoft del RPC del entorno de
computación distribuida (“Distributed Computing Environment” o DCE). Al igual
que Sun RPC (consulte “Capa de aplicación de llamada al procedimiento remoto de
Sun” en la página 129), MS RPC permite que un programa que se está ejecutando
en un equipo pueda ejecutar procedimientos de un programa que se está
ejecutando en otro equipo. Debido al gran número de servicios RPC y a la
necesidad de realizar difusiones broadcast, la dirección de transporte de un servicio
RPC se negocia dinámicamente basándose en el identificador universal único
(“Universal Unique IDentifier” o UUID). En ScreenOS, el protocolo de asociación
Endpoint Mapper está definido para asociar el UUID específico a una dirección de
transporte.
130 Servicios
Los dispositivos de seguridad de Juniper Networks admiten MS RPC como servicio

predefinido, lo que permite y rechaza el tráfico basándose en una directiva que
usted configure. La ALG proporciona la funcionalidad necesaria para que los
dispositivos de seguridad puedan manejar el mecanismo de negociación dinámica
de direcciones de transporte de MS RPC y garantizar el cumplimiento de las
directivas de cortafuegos basadas en UUID. Se puede definir una directiva de
cortafuegos para permitir o denegar todas las peticiones RPC, o bien para permitir
o denegar determinados números de UUID. ALG también admite el modo de rutas
y NAT para las peticiones entrantes y salientes.
Dado que los servicios MS RPC utilizan puertos negociados dinámicamente, no se

pueden utilizar objetos de servicios convencionales basándose en puertos TCP/UDP
fijos para autorizarlos en la directiva de seguridad. En lugar de ello, deben crearse
objetos de servicios MS RPC utilizando UUIDs. El servicio MS Exchange Info Store,
por ejemplo, utiliza los cuatro UUIDs siguientes:
0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde
1453c42c-0fa6-11d2-a910-00c04f990f3b
10f24e8e-0fa6-11d2-a910-00c04f990f3b
1544f5e0-613c-11d1-93df-00c04fd7bd09
Los puertos TCP/UDP correspondientes son dinámicos. Para permitirlos, cree un

objeto de servicio ms-exchange-info-store del servicio que contenga estos cuatro
UUIDs. Usando estos cuatro UUID, la ALG asignará los números de programa a
puertos TCP/UDP negociados dinámicamente y permitirá o rechazará el servicio
basándose en una directiva que usted configure.
En este ejemplo, creará un objeto de servicio denominado my-ex-info-store que

incluirá los UUIDs del servicio Info Store de MS Exchange.
WebUI
Policy > Policy Elements > Services > MS RPC: Introduzca los siguientes
Service Name: my-ex-info-store

UUID: 0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde
UUID: 1453c42c-0fa6-11d2-a910-00c04f990f3b
UUID: 10f24e8e-0fa6-11d2-a910-00c04f990f3b
UUID: 1544f5e0-613c-11d1-93df-00c04fd7bd09
CLI
set service my-ex-info-store protocol ms-rpc uuid
0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde
set service my-ex-info-store + ms-rpc uuid
1453c42c-0fa6-11d2-a910-00c04f990f3b
10f24e8e-0fa6-11d2-a910-00c04f990f3b
1544f5e0-613c-11d1-93df-00c04fd7bd09
save
Servicios 131
Puerta de enlace de la capa de aplicación del protocolo de secuencias en tiempo real

El protocolo de secuencias en tiempo real (“Real-Time Streaming Protocol” o RTSP)
es un protocolo de capa de aplicación que permite controlar la entrega de una o
varias secuencias multimedia sincronizadas, tales como audio y vídeo. Aunque
RTSP es capaz de suministrar secuencias de datos por sí mismo, interpolando las
secuencias de medios continuos con la secuencia de control, se suele utilizar más
como “control remoto de red” para servidores de multimedia. El protocolo fue
diseñado como medio para seleccionar canales de entrega, como UDP, multicast
UDP y TCP, así como para seleccionar el mecanismo de entrega basándose en el
protocolo RTP (“Real Time Protocol”). RTSP también puede utilizar el protocolo de
descripción de sesión (“Session Description Protocol ” o SDP) como un medio para
proporcionar información al cliente para el control agregado de una presentación
compuesta por secuencias de uno o varios servidores y el control no agregado de
una presentación compuesta por múltiples secuencias procedentes de un solo
servidor. Los orígenes de datos pueden ser suministrados en directo o corresponder
a clips almacenados.
Los dispositivos de Juniper Networks admiten RTSP como servicio y permiten o

rechazan el tráfico RTSP basándose en una directiva que usted configure. ALG es
necesario porque RTSP utiliza números de puerto asignados dinámicamente que se
incluyen en los datos del paquete durante el establecimiento de la conexión de
control. ALG realiza el seguimiento de los números de puerto asignados
dinámicamente y abre las correspondientes aberturas mínimas. En el modo NAT,
ALG traduce las direcciones y puertos IP según se requiera. Los dispositivos de
seguridad admiten RTSP en los modos de ruta, transparente, NAT basado en
interfaz y NAT basado en directivas.
La Figura 49 en la página 133 muestra una sesión RTSP típica. El cliente inicia una
sesión (por ejemplo, cuando el usuario hace clic en el botón de reproducción de
RealPlayer), establece una conexión TCP al servidor RTSP en el puerto 554 y envía
el mensaje OPTIONS (los mensajes también se denominan métodos) para descubrir
qué funciones de audio y vídeo soporta el servidor. El servidor responde al mensaje
OPTIONS especificando el nombre y la versión del servidor, así como un
identificador de sesión, por ejemplo 24256-1. (Para obtener más información sobre
métodos, consulte “Métodos de petición del protocolo SIP” en la página 6-14 y la
norma RFC 2326, sección 11).
A continuación, el cliente envía el mensaje DESCRIBE con la URL del archivo

multimedia que desea. El servidor responde al mensaje DESCRIBE con una
descripción del medio utilizando el formato SDP. Seguidamente, el cliente envía el
mensaje SETUP, que especifica los mecanismos de transporte de secuencias de
medios aceptables para el cliente, por ejemplo RTP/RTCP o RDT, y los puertos en los
que recibirá los medios. Con NAT, el ALG RTSP supervisa estos puertos y los traduce
cuando sea necesario. El servidor responde al método SETUP seleccionando uno de
los protocolos de transporte, lo que pone de acuerdo al cliente y al servidor en
cuanto al mecanismo para el transporte de los medios. A continuación, el cliente
envía el método PLAY y el servidor comienza a enviar la secuencia multimedia al
cliente.
132 Servicios
Figura 49: Sesión RTSP típica
Cliente de RealPlayer Dispositivo de seguridad Servidor RealMedia

Puerto 3408 Puerto 554
Métodos de petición RTSP

La Tabla 23 en la página 134 enumera los métodos que se pueden aplicar a un
recurso (objeto multimedia), la dirección o direcciones de flujo de la información y
si el método es obligatorio, recomendado u opcional. Por presentación se entiende
información tal como las direcciones de red, la codificación y el contenido de un
conjunto compuesto por una o varias secuencias presentadas al cliente como
provisión de medios completa. Una secuencia es una instancia de medios única,
por ejemplo de audio o de vídeo, así como todos los paquetes creados por un
origen durante la sesión.
Servicios 133
Tabla 23: Métodos de petición RTSP
Método Sentido Objeto Requisito Descripción

OPTIONS Cliente a Presentación, Cliente a El cliente consulta al servidor qué características de
servidor secuencia servidor audio o vídeo admite y otros datos como el nombre y la
requerido versión del servidor y la identificación de la sesión.
Servidor a Presentación, Servidor a
cliente secuencia cliente opcional
DESCRIBE Cliente a Presentación, Recomendado Para el intercambio de los datos de inicialización de
servidor secuencia medios, como velocidad del reloj, tablas de colores y
cualquier información independiente del transporte que
el cliente pueda necesitar para reproducir la secuencia
de medios. Generalmente, el cliente envía la URL del
archivo que está solicitando y el servidor responde con
una descripción del medio en formato SDP.
ANNOUNCE Cliente a Presentación, Opcional El cliente utiliza este método para publicar una
servidor secuencia descripción de la presentación o del objeto multimedia
identificado por la URL solicitada. El servidor utiliza este
Servidor a Presentación,
método para actualizar la descripción de la sesión en
cliente secuencia
tiempo real.
SETUP Cliente a Stream Requerido El cliente especifica los mecanismos de transporte
servidor aceptables, como los puertos en los que recibirá la
secuencia de medios y el protocolo de transporte.
GET_PARAMETER Cliente a Presentación, Opcional Consulta el valor de una presentación o el parámetro de
servidor secuencia la secuencia especificado en URL. Este método se puede
utilizar sin cuerpo de entidad para verificar la presencia
Servidor a
del cliente o del servidor. Para verificar si el cliente o
cliente
servidor está “vivo” también se puede utilizar el
comando “ping”.
SET_PARAMETER Cliente a Presentación, Opcional El cliente utiliza este método para establecer el valor de
servidor secuencia un parámetro de la presentación o secuencia
especificado por el URI. Por cuestiones relacionadas con
Servidor a
el cortafuegos, este método no se puede utilizar para
cliente
establecer parámetros de transporte.
PLAY Cliente a Presentación, Requerido Ordena al servidor que comience a enviar datos usando
servidor secuencia el mecanismo especificado en SETUP. El cliente no
enviará peticiones PLAY hasta que todas las solicitudes
SETUP se realicen de forma satisfactoria. El servidor
ordena en una cola las solicitudes PLAY y retrasa la
ejecución de nuevas peticiones PLAY hasta que se haya
completado una petición PLAY activa. Las peticiones
PLAY pueden o no contener un rango especificado. El
rango puede contener un parámetro de hora, expresado
en UTC (hora universal coordinada), para comenzar la
reproducción, que también se puede utilizar para
sincronizar secuencias procedentes de diversos
orígenes.
PAUSE Cliente a Presentación, Recomendado Detiene temporalmente la transmisión de una
servidor secuencia presentación activa. Si la URL solicitada especifica una
secuencia particular, por ejemplo de audio, esto
equivale a silenciarla. La sincronización de pistas se
mantiene al reanudar la reproducción o grabación,
aunque los servidores pueden cerrar la sesión si PAUSE
corresponde a la duración especificada en el parámetro
de tiempo de espera en SETUP. Una solicitud PAUSE
descarta todas las peticiones PLAY existentes en la cola.
134 Servicios
Tabla 23: Métodos de petición RTSP (Continuación)
Método Sentido Objeto Requisito Descripción

RECORD Cliente a Presentación, Opcional Comienza a grabar el rango de medios definido en la
servidor secuencia descripción de la presentación. Con una marca de hora
UTC se indican las horas de comienzo y de final, de lo
contrario el servidor utilizará las horas de comienzo y
de final de la descripción de la presentación.
REDIRECT Servidor a Presentación, Opcional Informa al cliente de que debe conectarse a otro
cliente secuencia servidor; también contiene tanto su información de
ubicación como, posiblemente, un parámetro de rango
de esa nueva URL. Para seguir recibiendo medios de
esta URL, el cliente debe generar una petición
TEARDOWN para la sesión actual y un SETUP para la
nueva sesión.
TEARDOWN Cliente a Presentación, Requerido Detiene la entrega de la secuencia del URI dado y libera
servidor secuencia los recursos asociados a la misma. Salvo que todos los
parámetros de transporte sean definidos por la
descripción de la sesión, debe publicarse una petición
SETUP para que la sesión pueda volver a reproducirse.
Códigos de estado de RTSP

RTSP utiliza códigos de estado para proporcionar información sobre peticiones del
cliente y del servidor. Los códigos de estado incluyen un código de resultado de tres
cifras interpretable por la máquina, así como una frase descriptiva del motivo. El
cliente puede elegir si desea visualizar la frase del motivo. Los códigos de estado se
describen en la Tabla 24.
Tabla 24: Códigos de estado de RSTP
Código Número Descripción

Informativo 100 a 199 Se recibió la petición y se está procesando
Éxito 200 a 299 La acción fue recibida, entendida y aceptada con éxito
Redirección 300 a 399 Es necesario realizar acciones adicionales para
completar la petición
Error del cliente 400 a 499 La petición contiene una mala sintaxis y no se puede
completar
Error del servidor 500 a 599 El servidor no pudo satisfacer una petición
aparentemente válida.
La Tabla 25 enumera todos los códigos de estado definidos para RTSP 1.0 y las
frases de motivo recomendadas. Las frases de motivo se pueden revisar o redefinir
sin que ello afecte al funcionamiento del protocolo.
Tabla 25: Códigos de estado de RTSP 1.0
Código de Código de
estado Frase del motivo estado Frase del motivo
100 Continue 414 Request-URI Too Large
200 OK 415 Unsupported Media Type
201 Created 451 Unsupported Media Type
250 Low on Storage Space 452 Conference Not Found
Servicios 135
Tabla 25: Códigos de estado de RTSP 1.0 (Continuación)
Código de Código de
estado Frase del motivo estado Frase del motivo
300 Multiple Choices 453 Not Enough Bandwidth
301 Moved Permanently 454 Session Not Found
303 See Other 455 Method Not Valid in This State
304 Not Modified 456 Header Field Not Valid for Resource
305 Use Proxy 457 Invalid Range
400 Bad Request 458 Parameter is Read-Only
401 Unauthorized 459 Aggregate operation not allowed
402 Payment Required 460 Only aggregate operation allowed
403 Forbidden 461 Unsupported transport
404 Not Found 462 Destination unreachable
405 Method Not Allowed 500 Internal Server Error
406 Not Acceptable 501 Not Implemented
407 Proxy Authentication 502 Bad Gateway
Required
408 Request Time-out 503 Service Unavailable
410 Gone 504 Gateway Time-out
411 Length Required 505 RTSP Version not supported
412 Precondition Failed 551 Option not supported
413 Request Entity Too Large
NOTA: Para ver las definiciones completas de los códigos de estado, consulte RFC 2326,
Protocolo de secuencias en tiempo real (Real Time Streaming Protocol o RTSP).
Configuración de un servidor de medios en un dominio privado

En este ejemplo, el servidor de medios se encuentra en la zona Trust y el cliente en
la zona Untrust. Usted decide colocar una MIP en la interfaz ethernet0/3 hacia el
servidor de medios en la zona Trust y luego crear una directiva para permitir que el
tráfico de RTSP pase desde el cliente en la zona Untrust al servidor de medios en la
zona Trust.
Figura 50: Dominio privado RTSP

10.1.1.1 1.1.1.1

Dispositivo de seguridad
LAN LAN
Dispositivo virtual
Servidor de medios MIP en ethernet0/3 Client1.1.1.5
10.1.1.3 1.1.1.3 -> 10.1.1.3
136 Servicios
WebUI
1. Interfaces
Zone Name: Trust

Manage IP: 10.1.1.2
Zone Name: Untrust

Manage IP: 1.1.1.2
2. Direcciones
Address Name: media_server

Zone: Trust
Address Name: client

Zone: Untrust
3. MIP
Network > Interfaces > Edit (para ethernet0/3) > MIP > New: Introduzca los
Mapped IP: 1.1.1.3

4. Directiva
Policy > Policies > (From: Untrust, To: Trust} > New: Introduzca los
Source Address:
Address Book Entry: (seleccione), cliente
Address Book Entry: (seleccione), MIP(1.1.1.3)
Service: RTSP
Action: Permit
Servicios 137
CLI
1. Interfaces
set interface ethernet0/1 trust
set interface ethernet0/1 ip 10.1.1.1
set interface ethernet0/3 untrust
2. Direcciones
set address trust media_server 10.1.1.3/24
set address untrust client 1.1.1.5
3. MIP
set interface ethernet0/3 mip (1.1.1.3) host 10.1.1.3
4. Directiva
set policy from untrust to trust client mip(1.1.1.3) rtsp permit
save
Configuración de un servidor de medios en un dominio público

En este ejemplo, el servidor de medios se encuentra en la zona Untrust y el cliente
en la zona Trust. Colocará un conjunto de DIP en la interfaz ethernet0/3 para
ejecutar NAT cuando el servidor de medios responda al cliente desde la zona
Untrust y luego creará una directiva para permitir que el tráfico RTSP fluya desde la
zona Trust a la zona Untrust.
Figura 51: Dominio público RTSP

Zona Trust 10.1.1.1 1.1.1.1 Zona Untrust
LAN
LAN LAN
Conjunto de DIP
Cliente en ethernet0/3 Servidor de medios
10.1.1.3 1.1.1.5 a 1.1.1.50 1.1.1.3
WebUI
1. Interfaz
Zone Name: Trust

Manage IP: 10.1.1.2
Zone Name: Untrust

Manage IP: 1.1.1.2
138 Servicios
2. Direcciones
Address Name: client

Zone: Trust
Address Name: media_server

Zone: Untrust
3. Conjunto de DIP
Network > Interfaces > Edit (para ethernet0/3) > DIP > New: Introduzca los
ID: 5
IP Address Range: (seleccione) 1.1.1.5 ~ 1.1.1.50
Port Translation: (seleccione)
4. Directiva
Policy > Policies > (From: Trust, To: Untrust} > New: Introduzca los
Source Address:
Address Book Entry (seleccione): client
Address Book Entry (seleccione): media_server
Service: RTSP
Action: Permit
> Advanced: Introduzca los siguientes datos y haga clic en OK:
NAT:
Source Translation: (seleccione)
(DIP on): 5 (1.1.1.5-1.1.1.50)/port-xlate
CLI
1. Interface
2. Direcciones
set address trust client ip 10.1.1.3/24
set address untrust media_server ip 1.1.1.3/24
3. Conjunto de DIP
set interface ethernet0/3 dip 5 1.1.5 1.1.1.50
Servicios 139
4. Directiva
set policy from trust to untrust client media_server rtsp nat dip 5 permit
save
Grupos de servicios
Un grupo de servicios es un conjunto de servicios agrupados bajo un nombre. Una
vez creado un grupo que contenga varios servicios, se pueden aplicar servicios a las
directivas a nivel de grupo, simplificando la administración.
La opción de grupo de servicios de ScreenOS tiene las siguientes funciones:
Se puede hacer referencia a cada entrada del libro de servicios en uno o más
grupos de servicios.
Cada grupo de servicios puede contener entradas predefinidas y entradas

definidas por el usuario en el libro de servicios.
Los grupos de servicios están sujetos a las siguientes limitaciones:
Los grupos de servicios no pueden llamarse igual que los servicios; por ejemplo,
si existe un servicio llamado “FTP”, no puede existir un grupo de servicios con
el mismo nombre.
Si en una directiva se hace referencia a un grupo de servicios, éste se puede

editar, pero para eliminarlo será necesario eliminar primero la referencia en la
directiva.
Si se elimina una entrada personalizada del libro de servicios, la entrada

también será eliminada en todos los grupos que contengan referencias a la
misma.
Un grupo de servicios no puede contener a otro grupo de servicios como

miembro.
El término “ANY” de servicio integral no se puede agregar a grupos.
Un servicio sólo puede pertenecer a un grupo a la vez.
Creación de un grupo de servicios

En este ejemplo creará un grupo de servicios llamado “grp1” que incluirá los
servicios IKE, FTP y LDAP.
WebUI
Policy > Policy Elements > Services > Groups > New: Introduzca el siguiente
nombre de grupo, mueva los siguientes servicios y haga clic en OK:
Group Name: grp1
Seleccione IKE y utilice el botón >> para mover el servicio de la columna

“Available Members” a la columna “Group Members”.
Seleccione FTP y utilice el botón << para mover el servicio de la columna
“Available Members” a la columna “Group Members”.
140 Servicios
Seleccione LDAP y utilice el botón << para mover el servicio de la

columna “Available Members” a la columna “Group Members”.
CLI
set group service grp1
set group service grp1 add ike
set group service grp1 add ftp
set group service grp1 add ldap
save
NOTA: Si intenta agregar un servicio a un grupo de servicios inexistente, el dispositivo de

seguridad creará ese grupo. Asegúrese también de que los grupos que contengan
referencias a otros grupos no se incluyen a sí mismos en la lista de referencias.
Modificación de un grupo de servicios

En este ejemplo cambiará los miembros del grupo de servicios llamado “grp1” que
creó en el “Creación de un grupo de servicios” en la página 140. Eliminará los
servicios IKE, FTP y LDAP, y agregará HTTP, FINGER e IMAP.
WebUI
Policy > Policy Elements > Services > Groups > Edit (para grp1): Mueva los
siguientes servicios, luego haga clic en OK:
Seleccione IKE y utilice el botón >> para mover el servicio de la columna
“Group Members” a la columna “Available Members”.
Seleccione FTP y utilice el botón >> para mover el servicio de la columna
“Group Members” a la columna “Available Members”.
Seleccione LDAP y utilice el botón >> para mover el servicio de la
columna “Group Members” a la columna “Available Members”.
Seleccione HTTP y utilice el botón << para mover el servicio de la
Seleccione Finger y utilice el botón << para mover el servicio de la
Seleccione IMAP y utilice el botón << para mover el servicio de la
CLI
unset group service grp1 clear
set group service grp1 add http
set group service grp1 add finger
set group service grp1 add imap
save
Servicios 141
Eliminación de un grupo de servicios

En este ejemplo eliminará un grupo de servicios denominado “grp1”.
WebUI
Policy > Policy Elements > Services > Groups: Haga clic en Remove (para
grp1).
CLI
unset group service grp1
save
NOTA: El dispositivo de seguridad no elimina automáticamente un grupo del que se

hayan eliminado todos los miembros.
Conjuntos de IP dinámicas
Un conjunto de IP dinámicas (DIP) es un rango de direcciones IP del cual el
dispositivo de seguridad toma direcciones de forma dinámica o determinista para
aplicar la traducción de direcciones de red a la dirección IP de origen (NAT-src) en
los encabezados de paquetes IP. (Para obtener más información sobre la traducción
determinista de direcciones de origen, consulte “NAT-Src desde un conjunto de DIP
con desplazamiento de direcciones” en la página 8-20). Si el rango de direcciones
de un conjunto de DIP pertenece a la misma subred que la dirección IP de la
interfaz, el conjunto debe excluir la dirección IP de la interfaz, las direcciones IP del
enrutador y cualquier dirección IP asignada (MIP) o virtual (VIP) que pueda haber
en esa misma subred. Si el rango de direcciones se encuentra en la subred de una
interfaz extendida, el conjunto debe excluir la dirección IP extendida de la interfaz.
Existen tres clases de interfaces que se pueden enlazar a conjuntos de IPs

dinámicas (DIP): interfaces físicas y subinterfaces para el tráfico de red y VPN,
e interfaces de túnel sólo para túneles VPN.
142 Conjuntos de IP dinámicas

Figura 52: Interfaces DIP

A la zona DMZ
A la zona Untrust
Túneles VPN
A la zona Trust
Pared de fuego
10.10.1.2– 210.10.1.2– 220.10.1.2– 10.20.1.2– 10.30.1.2–

10.10.1.20 210.10.1.20 220.10.1.20 10.20.1.20 10.30.1.20
Conjuntos de DIP
ethernet0/1 ethernet0/2 ethernet0/3 Zona Zona
Interfaces
10.10.1.1/24 210.10.1.1/24 220.10.1.1/24 10.20.1.1/24 10.30.1.1/24
Las interfaces físicas Las interfaces de túnel

conducen a redes o túneles solamente conducen a túneles
VPN. VPN.
Traducción de direcciones de puertos

Al utilizar la traducción de direcciones de puertos (“Port Address Translation” o
“PAT”), varios hosts pueden compartir la misma dirección IP, para lo cual el
dispositivo de seguridad mantiene una lista de los números de puertos asignados
con el fin de distinguir qué sesión pertenece a qué host. Con la PAT habilitada,
puede haber hasta unos 64.500 hosts compartiendo una misma dirección IP.
Algunas aplicaciones, como la interfaz de usuario extendida para NetBIOS

(“NetBIOS Extended User Interface” o “NetBEUI”) y el servicio de nombres de
Internet de Windows (“Windows Internet Naming Service” o “WINS”), requieren
números de puerto específicos y no funcionan correctamente si se les aplica PAT. Se
puede especificar que PAT no se ejecute para tales aplicaciones (es decir, que se
utilice un puerto fijo) aplicando DIP. Para DIP de puerto fijo, el dispositivo de
seguridad guarda en su tabla de “hash” la dirección IP del host original,
permitiendo así al dispositivo de seguridad asociar la sesión correcta a cada host.
Conjuntos de IP dinámicas 143

Creación de un conjunto de DIP con PAT

En este ejemplo creará un túnel VPN para que los usuarios locales puedan alcanzar
un servidor FTP en un sitio remoto. Sin embargo, las redes internas de ambos sitios
utilizan el mismo espacio de direcciones privado 10.1.1.0/24. Para solucionar este
problema de superposición de direcciones, creará una interfaz de túnel en la zona
Untrust del dispositivo de seguridad local, le asignará la dirección IP 10.10.1.1/24 y
le asociará un conjunto de DIP que contendrá un rango de una sola dirección
(10.10.1.2-10.10.1.2) y tendrá habilitada la traducción de direcciones de puertos
(PAT).
Los administradores del sitio remoto también deberán crear una interfaz de túnel
con una dirección IP en un espacio de direcciones neutral, tal como 10.20.2.1/24,
y configurar una dirección IP asignada (MIP) a su servidor FTP, como 10.20.2.5
hacia el host 10.1.1.5.
NOTA: Este ejemplo incluye solamente la configuración de la interfaz de túnel y del

conjunto de DIP que la acompaña. Para ver un ejemplo completo con todos los
pasos de configuración necesarios para este supuesto, consulte “Sitios VPN con
direcciones superpuestas” en la página 5-142.
WebUI
clic en OK:

Zone (VR): Untrust (trust-vr)
Network > Interfaces > Edit (para tunnel.1) > DIP > New: Introduzca los
ID: 5
IP Address Range: 10.10.1.2 ~ 10.10.1.2
In the same subnet as the interface IP or its secondary IPs: (seleccione)
NOTA: Puede utilizar el número de identificación mostrado, que es el siguiente número

correlativo disponible, o bien escribir otro número.
CLI
set interface tunnel.1 zone untrust-tun
set interface tunnel.1 dip 5 10.10.1.2 10.10.1.2
save

NOTA: Dado que PAT está habilitada de forma predeterminada, no existe ningún
argumento para habilitarla. Para crear el mismo conjunto de DIP según lo definido
anteriormente, pero sin PAT (es decir, con números de puerto fijos), haga lo
siguiente:
(WebUI) Network > Interfaces > Edit (para tunnel.1) > DIP > New: Borre la
casilla de verificación de Port Translation, luego haga clic en OK.
(CLI) set interface tunnel.1 dip 5 10.10.1.2 10.10.1.2 fix-port
Modificación de un conjunto de DIP

En este ejemplo cambiará el rango de direcciones de un conjunto de DIP existente
(ID 5) de 10.20.1.2 – 10.20.1.2 a 10.20.1.2 – 10.20.1.10. Este conjunto está
asociado a tunnel.1. Observe que para cambiar el rango del conjunto de DIP
mediante la interfaz de línea de comandos (“CLI”), primero debe eliminar
(o desactivar) el conjunto de DIP existente y crear un nuevo conjunto.
NOTA: No hay directivas que utilicen este conjunto de DIP en particular. Para que una
directiva utilice un conjunto de DIP, primero debe eliminar la directiva o
modificarla para que no pueda utilizar el conjunto de DIP antes de que usted lo
haya modificado.
WebUI
Network > Interfaces > Edit (para tunnel.1) > DIP > Edit (para ID 5):
IP Address Range: 10.20.1.2 ~ 10.20.1.10
CLI
unset interface tunnel.1 dip 5
save
Direcciones DIP persistentes

Cuando un host inicia varias sesiones que satisfacen las condiciones de una
directiva que requiere la traducción de direcciones de red (NAT) y se le asigna una
dirección de un conjunto de DIP con la traducción de puertos habilitada, el
dispositivo de seguridad asigna una dirección IP de origen distinta a cada sesión. Tal
asignación de direcciones aleatoria puede resultar problemática para los servicios
que generan múltiples sesiones que requieren la misma dirección IP de origen para
cada sesión.
NOTA: Para los conjuntos de DIP que no realizan la traducción de puertos, el dispositivo
de seguridad asigna una dirección IP a todas las sesiones simultáneas del mismo
host.

Por ejemplo, es importante tener la misma dirección IP para varias sesiones cuando
se utiliza el cliente AOL Instant Messaging (AIM). Creará una sesión durante el inicio
de su sesión y otra por cada chat. Para que el servidor AIM pueda verificar que un
nuevo chat pertenece a un usuario autenticado, debe comparar la dirección IP de
origen del inicio de sesión con la dirección de la sesión de chat. Si son diferentes
(posiblemente porque hubiesen sido asignadas aleatoriamente desde un conjunto
de DIP durante el proceso NAT), el servidor AIM rechazará la sesión de chat.
Para garantizar que el dispositivo de seguridad asigne la misma dirección IP de un

conjunto de DIP a las diferentes sesiones simultáneas de un host, puede habilitar la
función de persistencia (sticky, que literalmente significa pegajosa) de la dirección
DIP ejecutando el comando CLI set dip sticky.
Uso de DIP en una subred distinta

Si las circunstancias requieren que la dirección IP de origen del tráfico saliente por
el cortafuegos sea traducida a una dirección de una subred diferente de la subred
en la que se encuentra la interfaz de salida, puede utilizar la opción extendida de la
interfaz. Esta opción permite implantar una segunda dirección IP y un conjunto de
DIP auxiliar en una interfaz de otra subred. Después se puede habilitar NAT sobre
una base de directivas y especificar para la traducción el conjunto de DIP creado en
la interfaz extendida.
En este ejemplo, dos sucursales tienen líneas punto a punto con la sede central. La
oficina central les exige utilizar solamente las direcciones IP autorizadas que les ha
asignado. Sin embargo, las oficinas reciben de su proveedor de servicios (“ISP”)
otras direcciones IP para el tráfico de Internet. Para la comunicación con la oficina
central, utilizará la opción de interfaz extendida para configurar el dispositivo de
seguridad en cada sucursal de modo que traduzca la dirección IP de origen a la
dirección autorizada en todos los paquetes enviados a la oficina central. Las
direcciones IP autorizadas y asignadas para las sucursales A y B son las siguientes:
Tabla 26: Direcciones IP autorizadas para la oficina
Dirección IP asignada (por el Dirección IP autorizada (por la sede central)

ISP) y utilizada para la interfaz y utilizada para DIP de la interfaz extendida
física de la zona Untrust de la zona Untrust
Oficina A 195.1.1.1/24 211.10.1.1/24
Oficina B 201.1.1.1/24 211.20.1.1/24
En ambos sitios, los dispositivos de seguridad tienen una zona Trust y una zona
Untrust. Todas las zonas de seguridad se encuentran en el dominio de enrutamiento
trust-vr. Enlazará ethernet0/1 a la zona Trust y le asignará la dirección
IP 10.1.1.1/24. Enlazará ethernet0/3 a la zona Untrust y le asignará la dirección IP
generada por los correspondientes ISP: 195.1.1.1/24 para la Oficina A y
201.1.1.1/24 para la Oficina B. A continuación, creará una interfaz extendida con
un conjunto de DIP que contendrá la dirección IP autorizada en ethernet0/3:
Oficina A: IP de la interfaz extendida 211.10.1.10/24; conjunto de DIP

211.10.1.1 – 211.10.1.1; PAT habilitada
Oficina B: IP de la interfaz extendida 211.20.1.10/24; conjunto de DIP

211.20.1.1 – 211.20.1.1; PAT habilitada

Establecerá la interfaz de la zona Trust en modo NAT. Utilizará la dirección IP de la

interfaz de la zona Untrust como dirección de origen en todo el tráfico saliente,
salvo en el tráfico enviado a la sede central. Configurará una directiva para la sede
central que traducirá la dirección de origen a una dirección del conjunto de DIP en
la interfaz extendida. (El número de identificación del conjunto de DIP es 5.
Contiene una dirección IP que, mediante la traducción de direcciones de puertos o
PAT, permite gestionar las sesiones de unos 64,500 hosts). La dirección MIP
utilizada por la sede central para el tráfico entrante será 200.1.1.1, que deberá
introducir como “HQ” (oficina central) en la libreta de direcciones de la zona
Untrust de cada dispositivo de seguridad.
Figura 53: DIP bajo otra subred
Oficina
central (HQ)
Nota: Las líneas arrendadas conectan las
sucursales A y B directamente a la sede central.
200.1.1.1 Zona Untrust
Zona Untrust
ISP
Línea Línea
arrendada arrendada
Internet
Zona Untrust, ethernet0/3 Zona Untrust, ethernet0/3
El ISP asigna 195.1.1.1/24 El ISP asigna 201.1.1.1/24
(interfaz física) (interfaz física)
ISP ISP
La central autoriza HQ autoriza 211.20.1.1/24
211.10.1.1/24 (interfaz (interfaz extendida)
extendida) Puerta de enlace
Puerta de enlace predeterminada 201.1.1.254
predeterminada 195.1.1.254
Zona Trust, ethernet0/1 Oficina A Oficina B Zona Trust, ethernet0/1
10.1.1.1/24 10.1.1.1/24
NOTA: Para poder utilizar una línea punto a punto, cada ISP debe establecer una ruta para
el tráfico destinado al sitio que se encuentra en el extremo de esa línea. Los ISP
desviarán a Internet cualquier otro tráfico que reciban de un dispositivo de
seguridad local.
WebUI (sucursal A)
1. Interfaces
Zone Name: Trust

Interface Mode: NAT
Zone Name: Untrust


ID: 5
IP Address Range: 211.10.1.1 ~ 211.10.1.1
Extended IP/Netmask: 211.10.1.10/255.255.255.0
2. Dirección
Address Name: HQ
Zone: Untrust
3. Ruta

Gateway IP address: 195.1.1.254
4. Directivas
Source Address:
Service: ANY
Action: Permit
Source Address:
Address Book Entry: (seleccione), HQ
Service: ANY
Action: Permit
Position at Top: (seleccione)
> Advanced: Escriba lo siguiente y haga clic en Return para establecer las
opciones avanzadas y regresar a la página de configuración básica:
NAT:
(DIP on): 5 (211.10.1.1-211.10.1.1)/X-late

WebUI (sucursal B)
1. Interfaces
Zone Name: Trust

Interface Mode: NAT
Zone Name: Untrust

ID: 5
IP Address Range: 211.20.1.1 ~ 211.20.1.1
Extended IP/Netmask: 211.20.1.10/255.255.255.0
2. Dirección
Address Name: HQ
Zone: Untrust
3. Ruta

4. Directivas
Source Address:
Service: ANY
Action: Permit

Source Address:
Address Book Entry: (seleccione), HQ
Service: ANY
Action: Permit
NAT:
DIP On: (seleccione), 5 (211.20.1.1-211.20.1.1)/X-late
CLI (sucursal A)
1. Interfaces
set interface ethernet0/3 ext ip 211.10.1.10 255.255.255.0 dip 5 211.10.1.1
2. Dirección
set address untrust hq 200.1.1.1/32
3. Ruta
4. Directivas
set policy top from trust to untrust any hq any nat src dip 5 permit
save
CLI (sucursal B)
1. Interfaces
set interface ethernet0/3 ext ip 211.20.1.10 255.255.255.0 dip 5 211.20.1.1
2. Dirección
set address untrust hq 200.1.1.1/32
3. Ruta
4. Directivas
set policy top from trust to untrust any hq any nat src dip 5 permit
save

Uso de una DIP en una interfaz de bucle invertido

Una interfaz de bucle invertido es una interfaz lógica que siempre se encuentra en
línea mientras el dispositivo en el que reside permanezca en línea. En una interfaz
de bucle invertido se puede crear un conjunto de direcciones IP dinámicas (DIP)
accesible por el grupo de interfaces perteneciente al grupo asociado de interfaces
de bucle invertido al realizar la traducción de direcciones de origen. Las direcciones
que el dispositivo de seguridad toma de ese conjunto de DIP se encuentran en la
misma subred que la dirección IP de la interfaz de bucle invertido, no en la subred
de las interfaces miembro. (Observe que las direcciones del conjunto de DIP no
deben solaparse con la dirección IP de la interfaz ni con ninguna dirección MIP que
también se haya definido en la interfaz de bucle invertido).
NOTA: Para obtener más información sobre interfaces de bucle invertido, consulte
“Interfaces de bucle invertido (o “loopback”)” en la página 57.
La principal aplicación de ubicar un conjunto de DIP en una interfaz de bucle

invertido es traducir direcciones de origen a la misma dirección o rango de
direcciones aunque diferentes paquetes utilicen diferentes interfaces de salida.
Figura 54: DIP de bucle invertido
Traducción de direcciones de origen utilizando un

conjunto DIP en una interfaz de bucle invertido
IP de origen IP de destino IP de origen IP de destino
DATOS 1.3.3.2 DATOS
1.3.3.2 2.2.2.2 2.2.2.2
1.1.1.1/24 1.2.2.1/24
Interfaz de bucle Conjunto de DIP

Sea cual sea la interfaz de invertido loopback 1 1.3.3.2 - 1.3.3.2
salida, el dispositivo de 1.3.3.1/30
seguridad traduce las
direcciones IP de origen a la Dispositivo de seguridad
dirección del conjunto de DIP
definido en la interfaz ethernet0/1
loopback.1. 10.1.1.1/24
Host A Host B
IP de origen IP de destino 10.1.1.5 10.1.1.6 IP de origen IP de destino
10.1.1.5 2.2.2.2 DATOS 10.1.1.6 2.2.2.2 DATOS
En este ejemplo, el dispositivo de seguridad recibe las direcciones IP siguientes de

dos interfaces de la zona Untrust desde diferentes proveedores de servicios de
Internet (ISP): ISP-1 e ISP-2:
ethernet0/2, 1.1.1.1/24, ISP-1
ethernet0/3, 1.2.2.1/24, ISP-2
Asociará estas interfaces a la zona Untrust y después les asignará las direcciones IP
indicadas anteriormente. También asociará ethernet0/1 a la zona Trust y le asignará
la dirección IP 10.1.1.1/24.

Desea que el dispositivo de seguridad traduzca la dirección de origen del tráfico

saliente de la zona Trust a una oficina remota en la zona Untrust. La dirección
traducida debe ser la misma dirección IP (1.3.3.2), porque la oficina remota tiene
una directiva que permite el tráfico entrante solamente de esa dirección IP.
Previamente habrá obtenido las direcciones IP públicas 1.3.3.1 y 1.3.3.2 y habrá
notificado a ambos ISP que estará utilizando estas direcciones además de las
direcciones que ellos asignen al dispositivo.
Configurará una interfaz loopback.1 con la dirección IP 1.3.3.1/30 y un conjunto de

DIP de 1.3.3.2 – 1.3.3.2 en esa interfaz. El conjunto de DIP tendrá la identificación
número 10. Después hará a ethernet0/1 y ethernet0/2 miembros del grupo de bucle
invertido correspondiente a “loopback.1”.
Definirá una dirección “ofi_remota” con la dirección IP 2.2.2.2/32 para la oficina

remota. También definirá rutas predeterminadas para las interfaces ethernet0/1 y
ethernet0/2, que apuntarán a los enrutadores de los proveedores “ISP-1” e “ISP-2”,
respectivamente.
Definirá rutas a dos puertas de enlace para que el tráfico saliente las utilice. Dado
que no tiene ninguna preferencia por una ruta u otra, no incluirá ninguna métrica
en ninguna de ellas. El tráfico saliente podrá seguir cualquier ruta.
NOTA: Para indicar una ruta preferente, incluya métricas en ambas rutas y asigne a su
ruta preferida una métrica más alta, es decir, un valor más cercano a 1.
Por último, creará una directiva que aplicará la traducción de direcciones de red de
origen (NAT-src) al tráfico saliente hacia la oficina remota. La directiva hará
referencia al conjunto de DIP con la identificación 10.
Figura 55: Directiva de DIP de bucle invertido

ofi_remota
2.2.2.2
IP de origen IP de destino DATOS
1.3.3.2 2.2.2.2
ISP-1 Zona ISP-2

Untrust
ethernet0/2, 1.1.1.1/24 ethernet0/3, 1.2.2.1/24

puerta de enlace 1.1.1.250 puerta de enlace 1.2.2.250
El dispositivo de Conjunto de DIP
seguridad traduce todas con ID 10
las direcciones IP de (en Loopback.1)
origen de los paquetes 1.3.3.2 – 1.3.3.2
destinados a 2.2.2.2 de
ethernet0/1, 10.1.1.1/24 Loopback.1
10.1.1.X a 1.3.3.2,
NAT Mode Zona Untrust
independientemente de la
interfaz de salida utilizada. 1.3.3.1/30
Zona
10.1.1.0/24 Trust
IP de origen IP de destino DATOS

10.1.1.X 2.2.2.2

WebUI
1. Interfaces
Network > Interfaces > New Loopback IF: Introduzca los siguientes datos y
haga clic en OK:

Zone: Untrust (trust-vr)
As member of loopback group: loopback.1

Zone Name: Trust
Interface Mode: NAT
As member of loopback group: loopback.1

Zone Name: Untrust
Zone Name: Untrust

2. Conjunto de DIP
Network > Interfaces > Edit (para loopback.1) > DIP > New: Introduzca los
ID: 5
IP Address Range: 1.3.3.2 ~ 1.3.3.2
3. Dirección
Address Name: ofi_remota

Zone: Untrust

4. Rutas


5. Directiva
Source Address:
Address Book Entry: (seleccione), ofi_remota
Service: ANY
Action: Permit
NAT:
DIP On: (seleccione), 10 (1.3.3.2-1.3.3.2)/port-xlate
CLI
1. Interfaces
set interface loopback.1 ip 1.3.3.1/30
set interface ethernet0/2 loopback-group loopback.1
set interface ethernet0/3 loopback-group loopback.1
2. Conjunto de DIP
set interface loopback.1 dip 10 1.3.3.2 1.3.3.2
3. Dirección
set address untrust ofi_remota 2.2.2.2/32

4. Rutas
5. Directiva
set policy from trust to untrust any ofi_remota any nat src dip-id 10 permit
save
Creación de un grupo DIP

Cuando agrupe dos dispositivos de seguridad en un clúster redundante para
proporcionar alta disponibilidad (“high availability” o “HA”) en una configuración
activa/activa, ambos dispositivos comparten la misma configuración y ambos
procesan el tráfico simultáneamente. Puede presentarse un problema al definir una
directiva para realizar la traducción de direcciones de red (“Network Address
Translation” o NAT) si se utiliza un conjunto de DIP situado en una interfaz de
seguridad virtual (“Virtual Security Interface” o “VSI”). Debido a que esa VSI
solamente está activa en el dispositivo de seguridad que actúa como maestro
(“master”) del grupo VSD al que está asociada, ningún tráfico enviado al otro
dispositivo de seguridad (el que actúa como respaldo de dicho grupo VSD) puede
utilizar ese conjunto de DIP y se descarta.
Figura 56: Problemas de DIP con NAT con una VSI

Utilización problemática de un conjunto de DIP en una directiva en un clúster NSRP:
set policy name out-nat from trust to untrust any any any nat src dip-id 7 permit
Zona Untrust
VSI de la zona Untrust

ethernet0/2 ethernet0/3:1
1.1.1.1/24 1.1.1.2/24
Conjunto DIP ID 7
1.1.1.101 – 1.1.1.150
VSD Dispositivo A VSD de

maestro 0 respaldo 1
Clúster NSRP Grupo VSD: 0 Grupo VSD: 1
VSD de VSD
respaldo 0 Dispositivo B maestro 1
VSI de la zona Trust ethernet0/1 ethernet0/1:1

10.1.1.1/24 10.1.1.2/24
Debido a que el conjunto de DIP se encuentra en la

VSI de la zona Untrust del grupo VSD 1 (cuyo
maestro es el Dispositivo B), el Dispositivo A Zona Trust
(respaldo del grupo VSD 1) descarta el tráfico
recibido en ethernet0/1 (10.1.1.1/24) que cumple la
directiva “out-nat”.

Para solucionar este problema, cree dos conjuntos de DIP (uno en la VSI de la zona
Untrust por cada grupo VSD) y combine ambos conjuntos de DIP en un grupo de
DIP, al que luego hará referencia en la directiva. Cada VSI utiliza su propio conjunto
de VSD incluso aunque en la directiva se especifique el grupo de DIP.
Figura 57: Creación de dos conjuntos de DIP en un grupo DIP

Utilización recomendada de un grupo de DIP en una directiva cuando se
encuentra en un clúster NSRP: set policy name out-nat from trust to untrust
any any any nat dip-id 9 permit
Zona Untrust
Conjunto de DIP con ID 8 Conjunto DIP ID 7
1.1.1.151 – 210.1.1.200 1.1.1.101 – 1.1.1.150
ethernet0/3 ethernet0/3:1
VSI de la 1.1.1.1/24 1.1.1.2/24
Grupo de DIP 9
VSD VSD de
Dispositivo A respaldo 1
maestro 0
Clúster NSRP Grupo VSD: 0 Grupo VSD: 1
VSD de VSD
respaldo 0 Dispositivo B maestro 1
VSI de la zona Trust

ethernet0/1 ethernet0/1.1
10.1.1.1/24 10.1.1.2/24
Combinando los conjuntos de DIP situados en ambas
VSI de la zona Untrust (para los grupos VSD 0 y 1) en un
grupo de DIP, ambos Dispositivos A y B pueden
procesar el tráfico que cumpla la directiva “out-nat”, en la Zona Trust
que no se hace referencia a un conjunto de DIP
específico de interfaz, sino al grupo de DIP compartido.
NOTA: Para obtener más información sobre la configuración de dispositivos de seguridad

para HA, consulte el Volumen 11: Alta disponibilidad.
En este ejemplo proporcionará servicios NAT en dos dispositivos de seguridad

(Dispositivos A y B) en un par HA activo/activo.
Creará dos conjuntos de DIP, DIP 5 (1.1.1.20 – 1.1.1.29) en ethernet0/3 y DIP 6

(1.1.1.30 – 1.1.1.39) en ethernet0/3:1. Después los combinará en un grupo de DIP
identificado como DIP 7, al que hará referencia en una directiva.
Las VSI de los grupos VSD 0 y 1 son:
VSI de la zona Untrust ethernet0/3 1.1.1.1/24 (grupo VSD 0)
VSI de la zona Untrust ethernet0/3:1 1.1.1.2/24 (grupo VSD 1)
VSI de la zona Trust ethernet0/1 10.1.1.1/24 (grupo VSD 0)
VSI de la zona Trust ethernet0/1:1 10.1.1.1/24 (grupo VSD 1)

Presupongamos que previamente había configurado los dispositivos A y B en un

clúster NSRP, había creado el grupo VSD 1 (ScreenOS crea automáticamente el
grupo VSD 0 cuando se coloca un dispositivo en un clúster NSRP), y había
configurado las interfaces mencionadas. (Para obtener más información sobre la
configuración de dispositivos de seguridad para NSRP, consulte el Volumen 11:
Alta disponibilidad, ).
WebUI
1. Conjuntos de DIP
ID: 5
IP Address Range: 1.1.1.20 – 1.1.1.29
Network > Interfaces > Edit (para ethernet0/0/3) > DIP > New: Introduzca
ID: 6
IP Address Range: 1.1.1.30 – 1.1.1.39
NOTA: En el momento de publicar esta versión, los grupos de DIP solamente pueden
definirse desde la CLI.
2. Directiva
Source Address:
Service: ANY
Action: Permit
NAT:
DIP On: (seleccione), 7
CLI
1. Conjuntos de DIP
set interface ethernet0/3 dip 5 1.1.1.20 1.1.1.29
set interface ethernet0/3:1 dip 6 1.1.1.30 1.1.1.39
2. Grupos de DIP
set dip group 7 member 5
set dip group 7 member 6

3. Directiva
set policy from trust to untrust any any any nat src dip-id 7 permit
save
Configuración de una programación recurrente

Una tarea programada es un objeto configurable que se puede asociar a una o
varias directivas para definir cuándo deben entrar en vigor. Las tareas programadas
permiten controlar el flujo de tráfico en la red y hacer cumplir las normas de
seguridad de la red.
Para definir una tarea programada, introduzca los valores de los parámetros
siguientes:
Schedule Name: El nombre que aparece en la lista desplegable “Schedule” del

cuadro de diálogo “Policy Configuration”. Elija un nombre descriptivo que le
permita identificar la tarea programada. El nombre debe ser exclusivo y está
limitado a 19 caracteres.
Comment: Cualquier información adicional que desee agregar.
Recurring: Habilite esta opción cuando desee que el programa se repita con
una periodicidad semanal.
Start and End Times: Debe configurar tanto la hora de comienzo como la de
fin. Puede especificar hasta dos periodos de un mismo día.
Once: Habilite esta opción cuando desee que la tarea programada se ejecute y
termine una sola vez.
mm/dd/aaaa hh:mm: Debe introducir las fechas y las horas tanto de inicio
como de fin.
En este ejemplo hay un empleado a tiempo parcial llamado Tom que utiliza el
acceso a Internet de la empresa para asuntos personales después del trabajo. Usted
creará una tarea programada para el horario no comercial que asociará a una
directiva para denegar el tráfico TCP/IP saliente generado por el equipo de ese
trabajador (10.1.1.5/32) fuera del horario de oficina normal.
158 Configuración de una programación recurrente

WebUI
1. Tarea programada
Policy > Policy Elements > Schedules > New: Introduzca los siguientes datos
y haga clic en OK:
Schedule Name: Horas no laborables

Comment: Horario de oficina cerrada
Recurring: (seleccione)
Period 1:
Día de la semana Hora comienzo Hora final

Domingo 00:00 23:59
Lunes 00:00 06:00
Martes 00:00 06:00
Miércoles 00:00 06:00
Jueves 00:00 06:00
Viernes 00:00 06:00
Sábado 00:00 23:59
Period 2:
Día de la semana Hora comienzo Hora final

Domingo 17:00 23:59
Lunes 17:00 23:59
Martes 17:00 23:59
Miércoles 17:00 23:59
Jueves 17:00 23:59
Viernes 17:00 23:59
Sábado 17:00 23:59
2. Dirección
Address Name: Tom
Comment: Temp
Zone: Trust
Configuración de una programación recurrente 159

3. Directiva
Name: No Net
Source Address:
Address Book Entry: (seleccione), Tom
Service: HTTP
Action: Deny
Schedule: Horas no laborables
CLI
1. Tarea programada
set schedule “horas no laborables” recurrent sunday start 00:00 stop 23:59
set schedule “horas no laborables” recurrent monday start 00:00 stop 06:00
start 17:00 stop 23:59
set schedule “horas no laborables” recurrent tuesday start 00:00 stop 06:00
set schedule “horas no laborables” recurrent wednesday start 00:00 stop 06:00
set schedule “horas no laborables” recurrent thursday start 00:00 stop 06:00
set schedule “horas no laborables” recurrent friday start 00:00 stop 06:00 start
17:00 stop 23:59
set schedule “horas no laborables” recurrent saturday start 00:00 stop 23:59
comment “Horario de oficina cerrada”
2. Dirección
set address trust tom 10.1.1.5/32 “temp”
3. Directiva
set policy from trust to untrust tom any http deny schedule “horas no laborables”
save
160 Configuración de una programación recurrente

Capítulo 6
Directivas
El comportamiento predeterminado de un dispositivo de seguridad es rechazar

todo el tráfico interzonal de seguridad (tráfico interzonal) y, a excepción del tráfico
dentro de la zona Untrust, permitir todo el tráfico entre interfaces unidas a la
misma zona (tráfico intrazonal). Para permitir que el tráfico interzonal seleccionado
pase por un dispositivo de seguridad, debe crear directivas interzonales que tengan
preferencia sobre el comportamiento predeterminado. Del mismo modo, a fin de
impedir que el tráfico seleccionado interzonal pueda pasar por un dispositivo de
seguridad, debe crear las directivas interzonales.
En este capítulo se describe en qué consisten las directivas y cómo se relacionan

entre sí los diversos elementos que componen una directiva. Incluye las siguientes
secciones:
“Elementos básicos” en la página 162
“Tres tipos de directivas” en la página 163
“Listas de conjuntos de directivas” en la página 164
“Definición de directivas” en la página 165
“Directivas aplicadas” en la página 176
NOTA: Si configura el enrutamiento multicast en un dispositivo de seguridad, es posible

que tenga que configurar directivas multicast. Para obtener información sobre
directivas multicast, consulte “Directivas multicast” en la página 7-163.
161
Elementos básicos
Una directiva permite, deniega o encapsula los tipos de tráfico especificados de
forma unidireccional entre dos puntos. El tipo de tráfico (o “servicio”), la ubicación
de los dos puntos finales y la acción invocada componen los elementos básicos de
una directiva. Aunque puede haber otros componentes, los elementos requeridos,
que juntos constituyen el núcleo de una directiva, se describen en la Tabla 27.
Tabla 27: Elementos básicos de directivas
Elemento Descripción
Sentido El sentido del tráfico entre dos zonas de seguridad (desde una zona de
origen a una zona de destino)
Dirección de origen La dirección desde la cual se inicia el tráfico
Dirección de destino La dirección a la cual se envía el tráfico
Servicio El tipo de tráfico transmitido
Acción La acción que realiza el dispositivo de seguridad en el momento de recibir
el tráfico que cumple los cuatro principales criterios: denegar, permitir,
rechazar o tunelizar
Nota: La acción “tunnel” (túnel VPN o L2TP) contiene de manera implícita
el concepto “permit”.
Por ejemplo, la directiva indicada en el comando CLI siguiente permite el tráfico

FTP desde cualquier dirección de la zona Trust a un servidor FTP llamado
“servidor1” en la zona DMZ:
set policy from trust to untrust any servidor1 ftp permit

Sentido: from trust to untrust (es decir, de la zona Trust a la zona Untrust)
Dirección de origen: any (es decir, cualquier dirección en la zona Trust. El

término “any” significa una dirección predefinida aplicable a cualquier
dirección de una zona)
Dirección de destino: servidor1 (una dirección definida por el usuario en la

libreta de direcciones de la zona Untrust)
Servicio: ftp (protocolo de tranferencia de archivos o “File Transfer Protocol”)
Acción: permit (ese dispositivo de seguridad permite a este tráfico atravesar su

cortafuegos)
162 Elementos básicos

Capítulo 6: Directivas
Tres tipos de directivas

Puede controlar el flujo de tráfico con las tres clases de directivas siguientes:
Directivas interzonales: Le permiten regular el tipo de tráfico permitido para

pasar de una zona de seguridad a otra.
Directivas intrazonales: Le permiten regular qué tipo de tráfico se permite que

atraviese las interfaces unidas a la misma zona.
Directivas globales: Le permiten regular el tráfico entre direcciones, sin tomar

en cuenta las zonas de seguridad.
Directivas interzonales
Las directivas interzonales permiten controlar el tráfico entre zonas de seguridad.
Puede establecer directivas interzonales para denegar, permitir, rechazar o tunelizar
el tráfico desde una zona a otra. Por medio del uso de técnicas de inspección activa,
un dispositivo de seguridad actualiza una tabla de sesiones del TCP activas y de
“supuestas” sesiones del UDP activas de manera que pueda permitir respuestas a
las solicitudes de servicio. Por ejemplo, si tiene una directiva que permite enviar
solicitudes de HTTP del host A de la zona Trust al servidor B de la zona Untrust,
cuando el dispositivo de seguridad recibe respuestas de HTTP del servidor B para el
host A, el dispositivo de seguridad compara el paquete recibido con el contenido de
su tabla. Si detecta que el paquete es una respuesta a una solicitud HTTP aprobada,
el dispositivo de seguridad permite al paquete del servidor B de la zona Untrust
cruzar el cortafuegos hacia el host A en la zona Trust. Para permitir el tráfico
iniciado por el servidor B hacia el host A (no sólo respuestas al tráfico iniciado por el
host A), debe crear una segunda directiva del servidor B en la zona Untrust al host A
en la zona Trust.
Figura 58: Directiva interzonal
set policy from trust to untrust “host A” “servidor B” http permit

Host A Servidor B
Petición HTTP
Respuesta HTTP
Petición HTTP
Nota: El dispositivo de seguridad deniega la petición HTTP del servidor B porque no hay ninguna directiva que lo permita.
Directivas intrazonales
Las directivas intrazonales permiten controlar el tráfico entre interfaces asociadas a
la misma zona de seguridad. Las direcciones de origen y de destino se encuentran
en la misma zona de seguridad, pero llegaron al dispositivo de seguridad a través de
diferentes interfaces. Igual que las directivas interzonales, las directivas intrazonales
controlan el tráfico que fluye unidireccionalmente. Para permitir el tráfico iniciado
en cualquier extremo de una ruta de datos, debe crear dos directivas, una para cada
sentido.
Tres tipos de directivas 163

Figura 59: Directiva intrazonal
set policy from trust to trust “host A” “servidor B” any permit ethernet0/1 ethernet0/4
set policy from trust to trust “servidor B” “host A” any permit 10.1.1.1/24 10.1.2.1/24
Conmutadores de capa 2
Host A Servidor B
10.1.1.5 LAN 1 LAN
10.1.1.0/24 10.1.2.0/24 10.1.2.30
Zona Trust
Las directivas intrazonales no admiten túneles VPN ni la traducción de direcciones

de la red de origen (NAT-src) a nivel de interfaz (set interface interfaz nat). Sin
embargo, las directivas intrazonales admiten NAT-src y NAT-dst basada en
directivas. También admiten la traducción de direcciones de destino cuando la
directiva hace referencia a una dirección IP asignada (MIP) como dirección de
destino. (Para obtener más información sobre NAT-src, NAT-dst y MIPs, consulte el
Volumen 8: Traducción de direcciones).
Directivas globales
A diferencia de las directivas interzonales e intrazonales, las directivas globales no
hacen referencia a zonas de origen y de destino específicas. Las directivas globales
hacen referencia a direcciones de la zona Global definidas por el usuario o a la
dirección “any” de la zona predefinida Global. Estas direcciones pueden pasar por
varias zonas de seguridad. Por ejemplo, si desea proporcionar acceso hacia o desde
varias zonas, puede crear una directiva global con la dirección “any” de la zona
Global, la cual abarca todas las direcciones en todas las zonas.
NOTA: En el momento de publicar esta versión, las directivas globales no admiten la

traducción de direcciones de red de origen (NAT-src), túneles VPN ni el modo
transparente. Puede, sin embargo, especificar una MIP o VIP como dirección de
destino en una directiva global.
Listas de conjuntos de directivas

Un dispositivo de seguridad mantiene tres listas de conjuntos de directivas
diferentes para directivas interzonales, directivas intrazonales y directivas globales
respectivamente.
164 Listas de conjuntos de directivas

Cuando el dispositivo de seguridad recibe un paquete que inicia una nueva sesión,
éste detecta la interfaz de entrada y de este modo se informa de a qué zona de
origen está unida esa interfaz. A continuación, el dispositivo de seguridad realiza
una consulta de rutas para determinar la interfaz de salida y, por lo tanto,
determina a qué zona de destino está unida esa interfaz. Por medio del uso de las
zonas de origen y de destino, el dispositivo de seguridad puede realizar una
consulta de directivas, consultando las listas de conjuntos de directivas en el
siguiente orden:
1. Si las zonas de origen y de destino son diferentes, el dispositivo de seguridad

realiza una consulta de directivas en la lista de conjuntos de directivas
interzonales.
(o bien)
Si las zonas de origen y de destino son iguales, el dispositivo de seguridad

realiza una consulta de directivas en la lista de conjuntos de directivas
intrazonales.
2. Si el dispositivo de seguridad realiza la consulta de directivas interzonales o

intrazonales y no encuentra una coincidencia, éste consulta entonces la lista de
conjuntos de directivas globales en busca de una coincidencia.
3. Si el dispositivo de seguridad realiza las consultas de directivas interzonales y

globales y no encuentra una coincidencia, entonces aplica al paquete la
directiva predeterminada de permitir/rechazar: unset/set policy
default-permit-all.
(o bien)
Si el dispositivo de seguridad realiza las consultas de directivas intrazonales y

globales y no encuentra una coincidencia, entonces aplica al paquete el ajuste
de bloqueo intrazonal a esa zona: unset/set zone zona block.
El dispositivo de seguridad busca en cada lista de conjuntos de directivas desde la

parte superior hasta la parte inferior. Por lo tanto, las directivas más específicas
deben ubicarse en la lista por encima de las menos específicas. (Para obtener más
información sobre el orden de las directivas, consulte “Reordenamiento de
directivas” en la página 193).
Definición de directivas
Un cortafuegos representa el límite de una red con un solo punto de entrada y de
salida. Como todo el tráfico debe pasar a través de este punto, puede supervisarlo y
dirigirlo implementando listas de conjuntos de directivas (para directivas
interzonales, directivas intrazonales y directivas globales).
Las directivas permiten denegar, permitir, rechazar (denegar y enviar un mensaje

de puerto inalcanzable TCP RST o ICMP al host de origen), encriptar y desencriptar,
autenticar, priorizar, programar, filtrar y supervisar el tráfico que intente pasar de
una zona de seguridad a otra. Usted decide qué usuarios y qué datos pueden entrar
y salir, así como cuándo y a dónde pueden ir.
Definición de directivas 165

NOTA: Para los dispositivos de seguridad que admiten sistemas virtuales, las directivas
que se establecen en el sistema raíz no afectan a las directivas que se establecen
en los sistemas virtuales.
Directivas y reglas
Una sola directiva definida por el usuario produce internamente una o más reglas
lógicas, y cada regla lógica consta de un conjunto de componentes: la dirección de
origen, la dirección de destino y el servicio. Los componentes consumen recursos
de memoria. Las reglas lógicas que se refieren a los componentes no.
Dependiendo de si en una directiva se utilizan múltiples entradas o grupos para la

dirección de origen, la dirección de destino y los componentes del servicio, el
número de reglas lógicas puede ser mucho mayor de lo que puede parecer al crear
la directiva única. Por ejemplo, la directiva siguiente produce 125 reglas lógicas:
1 directiva: 5 direcciones de origen x 5 direcciones de destino x 5 servicios =

125 reglas lógicas
Sin embargo, el dispositivo de seguridad no duplica los componentes para cada

regla lógica. Las reglas utilizan el mismo conjunto de componentes en diferentes
combinaciones. Por ejemplo, la directiva antedicha que produce 125 reglas lógicas
solamente contiene 15 componentes:
5 direcciones de origen + 5 direcciones de destino + 5 servicios =

15 componentes
Estos 15 componentes se combinan de varias maneras para producir las 125 reglas
lógicas generadas por la directiva única. Al permitir que varias reglas lógicas utilicen
el mismo conjunto de componentes en diferentes combinaciones, el dispositivo de
seguridad consume muchos menos recursos que si cada regla lógica tuviera una
relación “uno a uno” con sus componentes.
Dado que el tiempo de instalación de una nueva directiva es proporcional al

número de componentes que el dispositivo de seguridad agrega, elimina o
modifica, la instalación de directivas es más rápida cuantos menos componentes
tenga. Asimismo, al permitir que un gran número de reglas lógicas comparta un
pequeño conjunto de componentes, ScreenOS le permite crear más directivas (y el
dispositivo de seguridad permite crear más reglas), que lo que sería posible si cada
regla requiriese componentes dedicados.
Anatomía de una directiva

Una directiva debe contener los elementos siguientes:
ID (generada automáticamente, aunque puede ser definida por el usuario

mediante CLI)
Zonas (de origen y de destino)
Direcciones (de origen y de destino)
166 Definición de directivas

Servicios
Acción (permitir, denegar, rechazar, encapsular en túnel)
Una directiva también puede contener los elementos siguientes:
Aplicación
Nombre
Encapsulamiento VPN
Encapsulamiento L2TP
Deep Inspection
Colocación al principio de la lista de directivas
Traducción de direcciones de origen
Traducción de direcciones de destino
Autenticación de usuarios
Copia de seguridad de la sesión HA
Filtrado de Web
Registro
Recuento
Umbral de alarma de tráfico
Tareas programadas
Análisis antivirus
Asignación de tráfico
El resto de esta sección examina cada uno de los elementos antedichos.
ID
Cada directiva tiene un número de identificación, bien porque el usuario lo defina,
bien porque el dispositivo de seguridad lo asigne automáticamente. Solamente se
puede definir un número de identificación para una directiva ejecutando el
comando “set policy” de CLI: set policy id número … Una vez conocido el número
de identificación, puede entrar en el contexto de la directiva para ejecutar otros
comandos con el fin de modificarla. (Para obtener más información sobre
contextos de directivas, consulte “Introducción del contexto de una directiva” en la
página 187).

Zonas
Una zona puede ser un segmento del espacio de red al que se aplican medidas de
seguridad (zona de seguridad), un segmento lógico que tiene asociada una interfaz
de túnel VPN (zona de túnel), o una entidad física o lógica que realiza una función
específica (zona de función). Una directiva permite que el tráfico fluya entre dos
zonas de seguridad (directiva interzonal) o entre dos interfaces asociadas a la
misma zona (directiva intrazonal). (Para obtener más información, consulte
“Zonas” en la página 25, “Directivas interzonales” en la página 163 y “Directivas
intrazonales” en la página 163).
Direcciones
Las direcciones son objetos que identifican dispositivos de red tales como hosts y
redes por su ubicación en relación al cortafuegos (en una de las zonas de
seguridad). Los hosts individuales se especifican utilizando la máscara
255.255.255.255, que indica que los 32 bits de la dirección son significativos. Las
redes se especifican utilizando su máscara de subred para indicar qué bits son
significativos. Para crear una directiva para direcciones específicas, primero debe
crear entradas para los hosts y redes correspondientes en la libreta de direcciones.
También puede crear grupos de direcciones y aplicarles directivas como haría con
otras entradas en la libreta de direcciones. Cuando utilice grupos de direcciones
como elementos de directivas, tenga presente que, debido a que el dispositivo de
seguridad aplica la directiva a cada dirección en el grupo, el número de reglas
lógicas internas disponibles y de componentes que conforman esas reglas se puede
agotar más rápidamente de lo esperado. Esto supone un peligro, especialmente
cuando se utilizan grupos de direcciones tanto para el origen como para el destino.
(Para obtener más información, consulte “Directivas y reglas” en la página 166).
Servicios
Los servicios son objetos que identifican los protocolos de aplicación usando la
información de la capa 4, como por ejemplo los números de puerto estándar y
aceptados de TCP y UDP para los servicios de aplicaciones como Telnet, FTP, SMTP
y HTTP. ScreenOS incluye servicios básicos de Internet predefinidos. También se
pueden definir servicios personalizados.
Puede definir directivas que especifiquen qué servicios deben permitirse,

denegarse, encriptarse, autenticarse, registrarse o contabilizarse.
Acción
Una acción es un objeto que describe el tratamiento que el cortafuegos debe dar al
tráfico que recibe.
Deny bloquea el paquete y le impide atravesar el cortafuegos.
Permit permite que el paquete atraviese el cortafuegos.
Reject bloquea el paquete y le impide atravesar el cortafuegos. El dispositivo de

seguridad descarta el paquete y envía un segmento de restablecimiento (RST)
de TCP al host de origen para el tráfico de TCP y un mensaje de “destination
unreachable, port unreachable” de ICMP (tipo 3, código 3) para el tráfico UDP.
Para los tipos de tráfico distintos de TCP y UDP, el dispositivo de seguridad
descarta el paquete sin notificar al host de origen, lo cual también ocurre
cuando la acción es “deny”.

NOTA: El dispositivo de seguridad envía un RST de TCP después de recibir (y descartar)

un segmento del TCP con cualquier bit de código activado que no sea otro de RST.
Cuando la interfaz de entrada opera en la capa 2 ó 3 y el protocolo es TCP, la

dirección IP de origen en el RST de TCP es la dirección IP de destino en el paquete
original (descartado). Cuando la interfaz de entrada opera en la capa 2 y el
protocolo es UDP, la dirección IP de origen en el mensaje de ICMP coincide con la
dirección IP de destino en el paquete original. Sin embargo, si la interfaz de
entrada opera en la capa 3 y el protocolo es UDP, la dirección IP de origen en el
mensaje de ICMP es la de la interfaz de entrada.
Tunnel encapsula los paquetes IP salientes y desencapsula los entrantes. Para

un túnel VPN IPSec, especifique qué túnel VPN utilizar. Para un túnel L2TP,
especifique qué túnel L2TP debe utilizarse. Para L2TP sobre IPSec, especifique
un túnel de VPN de IPSec y un túnel L2TP.
NOTA: Para L2TP sobre IPSec, las direcciones de origen y de destino del túnel VPN IPSec
deben ser iguales que las del túnel L2TP.
El dispositivo de seguridad aplica la acción especificada al tráfico que cumple con

los criterios que se presentaron anteriormente: zonas (origen y destino),
direcciones (origen y destino) y servicio.
Aplicación
La opción de la aplicación especifica la aplicación de la capa 7 que asigna el servicio
de la capa 4 al que se hace referencia en una directiva. Un servicio predefinido ya
dispone de una asignación a una aplicación de la capa 7. Sin embargo, para los
servicios personalizados es necesario vincular explícitamente el servicio a una
aplicación, especialmente si desea que la directiva aplique al servicio personalizado
una puerta de enlace de la capa de aplicación (ALG) o la inspección minuciosa
(Deep Inspection).
NOTA: ScreenOS admite ALG para varios servicios, que incluyen: DNS, FTP, H.323, HTTP,
RSH, SIP, Telnet y TFTP.
La aplicación de una ALG a un servicio personalizado incluye dos pasos:
Definir un servicio personalizado con un nombre, un tiempo de espera, un

protocolo de transporte y los puertos de origen y de destino.
Al configurar una directiva, hacer referencia a ese servicio y al tipo de

aplicación para la ALG que se desea aplicar.
Para obtener más información sobre cómo aplicar Deep Inspection a un servicio
personalizado, consulte “Asignación de servicios personalizados a aplicaciones” en
la página 4-156.

Nombre
Puede dar a una directiva un nombre descriptivo para permitir identificar
fácilmente su finalidad.
NOTA: Para obtener más información sobre las convenciones de nomenclatura de

ScreenOS (aplicables a los nombres creados para las directivas), consulte
“Convenciones de interfaz de línea de comandos” en la página x.
Encapsulamiento VPN
Puede aplicar una sola o varias directivas a cualquier túnel VPN que tenga
configurado. En WebUI, la opción “VPN Tunnel” abre una lista desplegable de todos
esos túneles. En CLI puede consultar todos los túneles disponibles ejecutando el
comando get vpn. (Para obtener más información, consulte “Redes privadas
virtuales de punto a punto” en la página 5-81 y “Redes privadas virtuales de acceso
telefónico” en la página 5-163).
Cuando las configuraciones VPN de ambos extremos de un túnel VPN utilizan NAT
basada en directivas, los administradores de ambos dispositivos de puerta de
enlace necesitan crear una directiva de tráfico saliente y otra de tráfico entrante
(cuatro directivas en total). Cuando las directivas de VPN coinciden en un par (es
decir, todo lo que se encuentra en las configuraciones de las directivas de tráfico
entrante y de tráfico saliente son iguales, salvo que las direcciones de origen y de
destino están invertidas), puede configurar una directiva y seleccionar la casilla de
verificación Modify matching bidirectional VPN policy para crear
automáticamente una segunda directiva para el sentido opuesto. Para la
configuración de una nueva directiva, la casilla de verificación “Matching VPN
Policy” está desactivada de forma predeterminada. Para la modificación de una
directiva existente que sea un miembro de un par coincidente, la casilla de
verificación está activada de forma predeterminada, y cualquier cambio realizado
en una directiva se realizará en la otra.
NOTA: Esta opción solamente está disponible a través de WebUI. No puede haber
múltiples entradas para ninguno de los componentes de directiva siguientes:
dirección de origen, dirección de destino o servicio.
Encapsulamiento L2TP
Puede aplicar una sola directiva o varias a cualquier túnel del protocolo de
encapsulamiento de la capa 2 (L2TP) que haya configurado. En WebUI, la opción
L2TP proporciona una lista desplegable de todos esos túneles. En la interfaz CLI,
puede visualizar el estado de los túneles L2TP activos mediante el comando get
l2tp cadena_túnel active y ver todos los túneles disponibles mediante el comando
get l2tp all. También puede combinar un túnel VPN con un túnel L2TP (si ambos
tienen el mismo punto final) para crear un túnel que combine las características de
cada uno. Esto se llama “L2TP-over-IPSec” (L2TP sobre IPSec).
NOTA: Un dispositivo de seguridad en el modo transparente no admite L2TP.

Deep Inspection
Deep Inspection (DI; inspección minuciosa) es un mecanismo para filtrar el tráfico
permitido en las capas de red y de transporte, ya que no solamente examina estas
capas, sino también las características de contenido y protocolo en la capa de
aplicación. El objetivo de DI es la detección y prevención de cualquier ataque o
comportamiento anómalo que pudiera existir en el tráfico que permite el
cortafuegos de Juniper Networks.
NOTA: En el modelo de interconexión de sistemas abiertos (OSI), la capa de red es la

capa 3, la capa de transporte es la capa 4 y la capa de aplicación es la capa 7. El
modelo de OSI es un modelo estándar en el sector industrial de redes de una
arquitectura de protocolos de red. El modelo de OSI se compone de siete capas.
Para configurar una directiva para la protección frente a ataques, debe elegir dos
opciones: qué grupo (o grupos) de ataque utilizar y qué acción tomar si se detecta
un ataque. (Para obtener más información, consulte “Deep Inspection” en la
página 4-119).
Colocación al principio de la lista de directivas

De forma predeterminada, ScreenOS coloca las directivas recién creadas al final de
la lista de conjuntos de directivas. Si necesita cambiar la ubicación de la directiva,
puede utilizar cualquiera de los métodos de reordenación de directivas explicados
en “Reordenamiento de directivas” en la página 193. Para evitar el paso adicional
de reubicar una directiva recién creada en la parte superior de una lista de
conjuntos de directivas, puede seleccionar la opción Position at Top de WebUI,
o bien utilizar la palabra clave top en el comando set policy (set policy top …) de
CLI.
Traducción de direcciones de origen

Puede aplicar la traducción de direcciones de origen (NAT-src) al nivel de directivas.
Con NAT-src puede traducir la dirección de origen en la red entrante o saliente y en
el tráfico VPN. La nueva dirección de origen puede proceder de un conjunto de IPs
dinámicas (DIP) o de la interfaz de salida. NAT-src también admite la traducción de
direcciones de los puertos de origen (PAT). Para obtener más información sobre
todas las opciones de NAT-src disponibles, consulte “Traducción de direcciones de
red de origen” en la página 8-13.
NOTA: También puede realizar la traducción de direcciones de origen a nivel de la

interfaz, conocida como traducción de direcciones de red (NAT). Para obtener más
información sobre el nivel de interfaz NAT-src, o simplemente NAT, consulte
“Modo NAT” en la página 92.
Traducción de direcciones de destino

Puede aplicar la traducción de direcciones de destino (NAT-dst) a nivel de directiva.
Con NAT-dst puede traducir la dirección de origen en la red entrante o saliente y en
el tráfico VPN. NAT-dst también admite la asignación de puertos de destino. Para
obtener más información sobre todas las opciones de NAT-dst disponibles, consulte
“Traducción de direcciones de red de destino” en la página 8-27.

Autenticación de usuarios
Seleccionar esta opción requiere que el usuario de autenticación en la dirección de
origen autentique su identidad proporcionando un nombre de usuario y la
contraseña antes de permitir al tráfico atravesar el cortafuegos o introducirse en el
túnel de VPN. El dispositivo de seguridad puede utilizar la base de datos local o un
servidor de autenticación RADIUS, SecurID o LDAP externo para realizar la
comprobación de la autenticación.
NOTA: Si una directiva que requiere autenticación puede aplicarse a una subred de
direcciones IP, se requerirá autenticación para cada dirección IP de esa subred.
Si un host admite varias cuentas de usuarios de autenticación (como ocurre con

un host UNIX que ejecuta Telnet), una vez que el dispositivo de seguridad
autentica al primer usuario, el resto de usuarios de ese host pueden enviar tráfico
a través del dispositivo de seguridad sin necesidad de autenticación, al heredar los
privilegios del primer usuario.
ScreenOS proporciona dos sistemas de autenticación:
Autenticación en tiempo de ejecución, en la cual el dispositivo de seguridad

solicita al usuario de autenticación que inicie una sesión al recibir tráfico HTTP,
FTP o Telnet que cumpla con una directiva en la que esté habilitada la
autenticación.
WebAuth, en la cual el usuario debe autenticarse para poder enviar tráfico a

través del dispositivo de seguridad.
Autenticación en tiempo de ejecución

El proceso de autenticación en tiempo de ejecución ocurre como sigue:
1. Cuando el usuario de autenticación envía una solicitud de conexión HTTP, FTP

o Telnet a la dirección de destino, el dispositivo de seguridad intercepta el
paquete y lo almacena en un búfer.
2. El dispositivo de seguridad envía al usuario de autenticación un mensaje de

solicitud de inicio de sesión.
3. El usuario de autenticación responde a esta solicitud con su nombre de usuario

y contraseña.
4. El dispositivo de seguridad autentica la información de inicio de sesión de

usuario de autenticación.
Si la autenticación es correcta, se establece una conexión entre el usuario de

autenticación y la dirección de destino.
Para la petición de conexión inicial, la directiva debe incluir uno o todos los
servicios siguientes: Telnet, HTTP o FTP. Sólo una directiva con uno o todos estos
servicios puede iniciar el proceso de autenticación. En una directiva que implique
autenticación de usuario se puede utilizar cualquiera de los siguientes servicios:
Any (porque “any” incluye los tres servicios requeridos).

Telnet, FTP o HTTP.
Un grupo de servicios que incluye el servicio o los servicios que desea, más
como mínimo uno de los tres servicios requeridos para iniciar el proceso de
autenticación (Telnet, FTP o HTTP). Por ejemplo, puede crear un grupo de
servicios personalizado denominado “Inic_ses” que proporcione los servicios
FTP, NetMeeting y H.323. Luego, cuando cree la directiva, especifique
“inic_ses” como el servicio.
Para cualquier conexión que sigue a una autenticación correcta, todos los servicios
especificados en la directiva son válidos.
NOTA: Una directiva con la autenticación habilitada no admite DNS (puerto 53) como
servicio.
Autenticación de comprobación previa a la directiva (WebAuth)

El proceso de autenticación de WebAuth es como sigue:
1. El usuario de autenticación establece una conexión HTTP a la dirección IP del

servidor de WebAuth.
2. El dispositivo de seguridad envía al usuario de autenticación un mensaje de

solicitud de inicio de sesión.
3. El usuario de autenticación responde a esta solicitud con su nombre de usuario

y contraseña.
4. El dispositivo de seguridad o un servidor de autenticación externo autentica la

información de inicio de sesión del usuario de autenticación.
Si el intento de autenticación tiene éxito, el dispositivo de seguridad permite al

usuario de autenticación iniciar el tráfico a los destinos que se especifican en
las directivas que obligan a la autenticación por el método de WebAuth.
NOTA: Para obtener más información sobre estos dos métodos de autenticación de
usuarios, consulte “Referencias a usuarios autenticados en directivas” en la
página 9-48.
Puede restringir o ampliar el rango de los usuarios de autenticación a quienes deba

aplicarse la directiva seleccionando un determinado grupo de usuarios, usuario
local o externo o una expresión de grupo. (Para obtener más información sobre
expresiones de grupos, consulte “Expresiones de grupos” en la página 9-5). Si en
una directiva no se hace referencia a un usuario de autenticación o a un grupo de
usuarios (en WebUI, seleccionando la opción Allow Any), la directiva se aplicará a
todos los usuarios de autenticación del servidor especificado.

NOTA: ScreenOS vincula los privilegios de autenticación a la dirección IP del host desde
la cual se conecta el usuario de autenticación. Si el dispositivo de seguridad
autentica a un usuario de un host situado detrás de un dispositivo de NAT que
utilice una sola dirección IP para todas las asignaciones de NAT, los usuarios de
otros hosts situados detrás de ese dispositivo de NAT recibirán automáticamente
los mismos privilegios.
Copia de seguridad de la sesión HA

Cuando dos dispositivos de seguridad se encuentran en un clúster de NSRP para
alta disponibilidad (HA), puede especificar a qué sesiones hacerles copias de
seguridad y a cuáles no. Para el tráfico cuyas sesiones no desee salvaguardar,
aplique una directiva con la opción HA session backup desactivada. En WebUI,
desactive la casilla de verificación HA Session Backup. En CLI, utilice el argumento
no-session-backup en el comando set policy. De forma predeterminada, los
dispositivos de seguridad de un clúster de NSRP realizan copias de seguridad de las
sesiones.
Filtrado de Web
El filtrado de Web, denominado también filtrado de URL, le permite administrar el
acceso a Internet y evitar el acceso a contenido de Web inapropiado. Para obtener
más información, consulte “Filtrado de Web” en la página 4-100.
Registro
Cuando se habilita el registro en una directiva, el dispositivo de seguridad registra
todas las conexiones a las que esa directiva en particular aplique. Los registros se
pueden visualizar con WebUI o CLI. En WebUI, haga clic en Reports > Policies >
Logging (para la directiva cuyo registro desee consultar). En CLI, utilice el comando
get log traffic policy núm_id.
NOTA: Para obtener más información sobre la visualización de registros y gráficos,

consulte “Supervisión de dispositivos de seguridad” en la página 3-59.
Recuento
Cuando se habilita el recuento en una directiva, el dispositivo de seguridad cuenta
el número total de bytes de tráfico para los que esa directiva se aplica y registra la
información en gráficos de historial. Para visualizar los gráficos de historial de una
directiva en WebUI, haga clic en Reports > Policies > Counting (para la directiva
cuyo recuento de tráfico desea consultar).
Umbral de alarma de tráfico

Puede establecer un umbral que dispare una alarma cuando el tráfico permitido por
la directiva exceda un número especificado de bytes por segundo, bytes por
minuto, o ambos. Debido a que la alarma de tráfico requiere que el dispositivo de
seguridad supervise el número total de bytes, también debe habilitar la función de
recuento.

NOTA: Para obtener más información sobre alarmas de tráfico, consulte “Alarmas de
tráfico” en la página 3-73.
Tareas programadas
Asociando una programación a una directiva se puede determinar cuándo debe
activarse esa directiva. Puede configurar programaciones repetitivas y como evento
único. Las programaciones proporcionan una potente herramienta para controlar el
flujo de tráfico de la red e implementar seguridad en ésta. Como ejemplo de esto
último, si le preocupa que algunos empleados puedan transmitir datos importantes
fuera de la empresa, puede establecer una directiva que bloquee los tipos de tráfico
saliente FTP-Put y MAIL después del horario de oficina normal.
En WebUI, defina tareas programadas en la página Policy > Policy Elements >
Schedules. En CLI, ejecute el comando set schedule.
NOTA: En WebUI, las directivas programadas aparecen con un fondo gris para indicar que
la hora actual no está dentro de la programación definida. Cuando una directiva
programada se activa, aparece con un fondo blanco.
Análisis antivirus
Algunos dispositivos de seguridad de Juniper Networks admiten un analizador
antivirus interno que puede configurar para filtrar el tráfico FTP, HTTP, IMAP, POP3
y SMTP. Si el analizador AV incorporado detecta un virus, descarta el paquete y
envía un mensaje al cliente que inició el tráfico para informarle sobre dicho virus.
NOTA: Para obtener más información sobre el análisis antivirus, consulte “Análisis
antivirus” en la página 175.
Puede establecer los parámetros de control y asignación del tráfico para cada
directiva. La Tabla 28 describe los parámetros de asignación de tráfico.
Tabla 28: Parámetros de asignación de tráfico
Parámetro Descripción
Guaranteed Tasa de transferencia garantizada en kilobits por segundo (kbps). El tráfico que
Bandwidth no alcanza este umbral pasa con la prioridad más alta sin ser sometido a ningún
mecanismo de administración o asignación del tráfico.
Maximum Ancho de banda garantizado disponible para el tipo de conexión en kilobits por
Bandwidth segundo (kbps). El tráfico más allá de este umbral se regula y descarta.
Nota: Se aconseja no utilizar tasas inferiores a 10 Kbps. Las tasas inferiores a

este umbral conducen al descarte de paquetes y a un número excesivo de
reintentos que contravienen el objetivo de la administración del tráfico.
Traffic Priority Cuando el ancho de banda del tráfico se encuentra entre los ajustes garantizado
y máximo, el dispositivo de seguridad permite pasar primero el tráfico de
mayor prioridad, y el tráfico de menor prioridad sólo cuando no hay otro tráfico
de prioridad superior. Existen ocho niveles de prioridad.

Tabla 28: Parámetros de asignación de tráfico (Continuación)
Parámetro Descripción
DiffServ Differentiated Services (DiffServ) es un sistema para etiquetar (o “marcar”) el
Codepoint tráfico de una posición dentro de una jerarquía de prioridades. Puede asignar
Marking los ocho niveles de prioridad de ScreenOS al sistema DiffServ. De forma
predeterminada, la prioridad más alta (prioridad 0) del sistema ScreenOS se
asigna a los tres primeros bits (111) en el campo DiffServ (consulte la norma
RFC 2474) o bien al campo de precedencia de IP en el byte TOS (consulte la
norma RFC 1349), en el encabezado de paquete de IP. La prioridad más baja
(prioridad 7) en ScreenOS asigna (000) en el sistema DiffServ de TOS. Cuando
habilita DSCP, ScreenOS sobrescribe los primeros 3 bits en el byte de ToS con la
prioridad de preferencia de IP. Cuando habilita DSCP y establece un value
dscp-byte, ScreenOS sobrescribe los primeros 6 bits del byte de ToS con el valor
de DSCP.
Nota: Algunos dispositivos necesitan que active explícitamente la marca de

DSCP al establecer una variable de entorno en todo el sistema. Consulte el
manual del hardware para saber si su dispositivo necesita que active
explícitamente la marca de DSCP antes de utilizarla en las directivas. Si su
dispositivo la necesita, utilice el siguiente comando para activar la marca de
DSCP en todo el sistema: set envar ipsec-dscp-mark=yes. Esta variable no se
puede establecer con WebUI. Utilice unset envar ipsec-dscp-mark para
desactivar la marca de DSCP en todo el sistema.
NOTA: Para averiguar más sobre la administración y asignación del tráfico, consulte
“Asignación de tráfico” en la página 195.
Para cambiar la asignación entre los niveles de prioridad de ScreenOS y el sistema

DiffServ, utilice el siguiente comando de la CLI:
set traffic-shaping ip_precedence número0 número1 número2 número3 número4

número5 número6 número7
donde número0 corresponde a la prioridad 0 (la prioridad más alta del sistema
DiffServ de TOS), número1 corresponde a la prioridad 1 y así sucesivamente.
Para incluir prioridades de IP en puntos de código selectores de clase (“class

selector codepoints”), es decir, poner a cero el segundo grupo de tres bits del
campo “DiffServ” para asegurar que los niveles de prioridad establecidos con
ip_precedence se conserven y sean correctamente tratados por los enrutadores de
bajada, utilice el comando CLI siguiente:
set traffic-shaping dscp-class-selector
Directivas aplicadas
Esta sección describe la administración de directivas: visualización, creación,
modificación, ordenación y reordenación y eliminación de directivas.
176 Directivas aplicadas

Visualización de directivas
Para visualizar directivas a través de WebUI, haga clic en Policies. Puede clasificar
las directivas que se muestran por zonas de origen y de destino eligiendo los
nombres de zonas de las listas desplegables From y To, y, posteriormente hacer clic
en Go. En la CLI, utilice el comando get policy [ all | from zona to zona | global | id
número ].
Creación de directivas
Para permitir el flujo de tráfico entre dos zonas, debe crear directivas para permitir,
denegar, rechazar o tunelizar el tráfico entre esas zonas. También puede crear
directivas para controlar el tráfico dentro de la misma zona si el dispositivo de
seguridad es el único dispositivo de red capaz de enrutar el tráfico intrazonal entre
las direcciones de origen y de destino a las que se hace referencia en la directiva.
También puede crear directivas globales que utilizan direcciones de origen y de
destino en la libreta de direcciones de la zona Global.
Para permitir tráfico bidireccional entre dos zonas (por ejemplo, entre la zona Trust
y la zona Untrust) se necesita crear una directiva para el tráfico de Trust a Untrust y
otra para el tráfico de Untrust a Trust. Dependiendo de sus necesidades, las
directivas pueden utilizar la misma dirección IP o bien direcciones diferentes,
invirtiendo las direcciones de origen y destino.
Se pueden definir directivas entre cualesquiera zonas situadas dentro del mismo
sistema, ya sea raíz o virtual. Para definir una directiva entre el sistema raíz y un
sistema virtual (vsys), una de las zonas debe ser compartida. (Para obtener más
información sobre las zonas compartidas en lo referente a los sistemas virtuales,
consulte el Volumen 10: Sistemas virtuales).
Creación del servicio de correo de directivas interzonales

En este ejemplo, se crean tres directivas para controlar el flujo de tráfico de correo
electrónico.
La primera directiva permite a los usuarios internos de la zona Trust enviar y recibir
correo electrónico de un servidor de correo local situado en la zona DMZ. Esta
directiva permitirá a los servicios MAIL (es decir, SMTP) y POP3 generados por los
usuarios internos atravesar el cortafuegos de Juniper Networks para alcanzar el
servidor de correo local.
Las directivas segunda y tercera permitirán al servicio MAIL atravesar el cortafuegos

existente entre el servidor de correo local de la zona DMZ y un servidor de correo
remoto de la zona Untrust.
Sin embargo, antes de crear directivas para controlar tráfico entre diferentes zonas
de seguridad, debe diseñar el entorno en el que aplicar esas directivas. Primero
asociará interfaces a zonas y les asignará direcciones IP de interfaces:
Asocie ethernet0/1 a la zona Trust y asígnele la dirección IP 10.1.1.1/24.
Asocie ethernet0/2 a la zona DMZ y asígnele la dirección IP 1.2.2.1/24.
Asocie ethernet0/3 a la zona Untrust y asígnele la dirección IP 1.1.1.1/24.
Directivas aplicadas 177

Todas las zonas de seguridad se encuentran en el dominio de enrutamiento

trust-vr.
En segundo lugar, creará las direcciones que se utilizarán en las directivas:
Defina una dirección en la zona Trust llamada “corp_net” y asígnele la dirección

IP 10.1.1.0/24.
Defina una dirección en la zona DMZ llamada “mail_svr” y asígnele la dirección

IP 1.2.2.5/32.
Defina una dirección en la zona Untrust llamada “r-mail_svr” y asígnele la

dirección IP 2.2.2.5/32.
En tercer lugar, creará un grupo de servicios llamado “MAIL-POP3” que contendrá

los dos servicios predefinidos MAIL y POP3.
En cuarto lugar, configurará una ruta predeterminada en el dominio de

enrutamiento trust-vr que señalará al enrutador externo en 1.1.1.250 a través de
ethernet0/3.
Una vez completados los pasos del 1 al 4, puede crear las directivas necesarias para
permitir la transmisión, recuperación y entrega de correo electrónico dentro y fuera
de su red protegida.
WebUI
1. Interfaces
Zone Name: Trust

Interface Mode: NAT
Zone Name: DMZ

Zone Name: Untrust


2. Direcciones
Address Name: corp_net

Zone: Trust
Address Name: mail_svr

Zone: DMZ
Address Name: r-mail_svr

Zone: Untrust
3. Grupo de servicios
Policy > Policy Elements > Services > Groups: Introduzca el siguiente nombre
de grupo, mueva los siguientes servicios y haga clic en OK:
Group Name: MAIL-POP3
Seleccione MAIL y utilice el botón << para mover el servicio de la

columna Available Members a la columna Group Members.
Seleccione POP3 y utilice el botón << para mover el servicio de la

4. Ruta

5. Directivas
Policy > Policies > (From: Trust, To: Untrust) > New: Introduzca los siguientes
Source Address:
Address Book Entry: (seleccione), corp_net
Address Book Entry: (seleccione), mail_svr
Service: Mail-POP3
Action: Permit

Policy > Policies > (From: DMZ, To: Untrust) New: Introduzca los siguientes
Source Address:
Address Book Entry: (seleccione), r-mail_svr
Service: MAIL
Action: Permit
Policy > Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes
Source Address:
Address Book Entry: (seleccione), r-mail_svr
Service: MAIL
Action: Permit
CLI
1. Interfaces
set interface ethernet0/2 zone dmz
2. Direcciones
set address trust corp_net 10.1.1.0/24
set address dmz mail_svr 1.2.2.5/32
set address untrust r-mail_svr 2.2.2.5/32
set group service MAIL-POP3
set group service MAIL-POP3 add mail
set group service MAIL-POP3 add pop3
4. Ruta
5. Directivas
set policy from trust to dmz corp_net mail_svr MAIL-POP3 permit
set policy from dmz to untrust mail_svr r-mail_svr MAIL permit
set policy from untrust to dmz r-mail_svr mail_svr MAIL permit
save
Creación de un conjunto de directivas interzonales

Una pequeña empresa de software, ABC Design, ha dividido su red interna en dos
subredes, y ambas están en la zona Trust. Estas dos subredes son:
Ingeniería (con la dirección definida como “Ing”)
El resto de la empresa (con la dirección definida como “Oficina”)

ABC Design También tiene una zona DMZ para sus servidores de Web y correo
electrónico.
El ejemplo siguiente presenta un conjunto típico de directivas para los siguientes

usuarios:
“Ing” puede utilizar todos los servicios de tráfico saliente salvo FTP-Put, IMAP,
MAIL y POP3.
“Oficina” puede utilizar el correo electrónico y el acceso a Internet, siempre

que se autentiquen a través de WebAuth. (Para obtener más información sobre
la autenticación de usuarios mediante WebAuth, consulte “Usuarios de
autenticación” en la página 9-47).
Todos los usuarios de la zona Trust pueden acceder a los servidores de web y de
correo electrónico en la zona DMZ.
Un servidor de correo remoto de la zona Untrust puede acceder al servidor de

correo local de la zona DMZ.
También hay un grupo de administradores de sistemas (con la dirección

definida por el usuario “sys-admins”), que disponen de permisos completos de
acceso de usuario y acceso administrativo a los servidores de la zona DMZ.
Figura 60: Conjunto de directivas interzonales
Zona Untrust
Internet
www.abc.com
mail.abc.com
Enrutador externo
Enrutador interno
Zona DMZ
LAN de “Oficina” LAN de “Ing”
Zona Trust
Se presupone que ya configuró las interfaces, direcciones, grupos de servicios y

rutas necesarias, que deben estar ya colocadas. Para obtener información sobre la
configuración de lo anterior, consulte “Interfaces” en la página 33, “Direcciones” en
la página 103, “Grupos de servicios” en la página 140 y el Volumen 7: Enrutamiento.

Tabla 29: Directivas configuradas
De zona - Dir origen A la zona - Dir destino Servicio Acción

Trust - Any Untrust - Any Com (grupo de servicios: Reject
FTP-Put, IMAP, MAIL, POP3)
Trust - Ing Untrust - Any Any Permit
Trust - Oficina Untrust - Any Internet (grupo de servicios: Permit (+WebAuth)
FTP-Get, HTTP, HTTPS)
Untrust - Any DMZ - mail.abc.com MAIL Permit
Untrust - Any DMZ - www.abc.com Web (grupo de servicios: Permit
HTTP, HTTPS)
Trust - Any DMZ - mail.abc.com Email (grupo de servicios: Permit
IMAP, MAIL, POP3)
Trust - Any DMZ - www.abc.com Internet (grupo de servicios: Permit
FTP-Get, HTTP, HTTPS)
Trust - sys-admins DMZ - Any Any Permit
DMZ - mail.abc.com Untrust - Any MAIL Permit
NOTA: La directiva predeterminada es denegar todo.
WebUI
1. De Trust a Untrust
Source Address:
Address Book Entry: (seleccione), Ing
Service: ANY
Action: Permit
Source Address:
Address Book Entry: (seleccione), Oficina
Service: Internet
Action: Permit
Authentication: (seleccione)
WebAuth: (seleccione)
NOTA: “Internet” es un grupo de servicios con los siguientes miembros: FTP-Get, HTTP y
HTTPS.

Source Address:
Service: Com
Action: Reject
NOTA: “Com” es un grupo de servicios con los siguientes miembros: FTP-Put, MAIL,
IMAP y POP3.
Para el tráfico de la zona Untrust a la zona Trust, la directiva de rechazo

predeterminada lo rechaza todo.
2. De Untrust a DMZ
Source Address:
Address Book Entry: (seleccione), mail.abc.com
Service: MAIL
Action: Permit
Source Address:
Address Book Entry: (seleccione), www.abc.com
Service: Web
Action: Permit
NOTA: “Web” es un grupo de servicios con los siguientes miembros: HTTP y HTTPS.
3. De Trust a DMZ
Policy > Policies > (From: Trust, To: DMZ) New: Introduzca los siguientes datos
y haga clic en OK:
Source Address:
Service: correo electrónico
Action: Permit

NOTA: “e-mail” es un grupo de servicios con los siguientes miembros: MAIL, IMAP y
POP3.
y haga clic en OK:
Source Address:
Address Book Entry: (seleccione), www.abc.com
Service: Internet
Action: Permit
y haga clic en OK:
Source Address:
Address Book Entry: (seleccione), sys-admins
Service: ANY
Action: Permit
4. De DMZ a Untrust
Policy > Policies > (From: DMZ, To: Untrust) New: Introduzca los siguientes
Source Address:
Service: MAIL
Action: Permit
CLI
1. De Trust a Untrust
set policy from trust to untrust eng any any permit
set policy from trust to untrust oficina any Internet permit webauth
set policy top from trust to untrust any any Com reject
NOTA: “Internet” es un grupo de servicios con los siguientes miembros: FTP-Get, HTTP y
HTTPS.
“Com” es un grupo de servicios con los siguientes miembros: FTP-Put, MAIL,

IMAP y POP3.
2. De Untrust a DMZ
set policy from untrust to dmz any mail.abc.com mail permit
set policy from untrust to dmz any www.abc.com Web permit
NOTA: “Web” es un grupo de servicios con los siguientes miembros: HTTP y HTTPS.

3. De Trust a DMZ
set policy from trust to dmz any mail.abc.com e-mail permit
set policy from trust to dmz any www.abc.com Internet permit
set policy from trust to dmz sys-admins any any permit
NOTA: “e-mail” es un grupo de servicios con los siguientes miembros: MAIL, IMAP y
POP3.
“Internet” es un grupo de servicios con los siguientes miembros: FTP-Get, HTTP y

HTTPS.
4. De DMZ a Untrust
set policy from dmz to untrust mail.abc.com any mail permit
save
Creación de directivas intrazonales

En este ejemplo creará una directiva intrazonal para permitir a un grupo de
contables acceder a un servidor confidencial de la LAN corporativa en la zona Trust.
Primero asociará ethernet0/1 a la zona Trust y le dará la dirección IP 10.1.1.1/24.
Después asociará ethernet0/2 a la zona Trust y le asignará la dirección
IP 10.1.5.1/24. Habilitará el bloqueo intrazonal en la zona Trust. A continuación,
definirá dos direcciones, una para un servidor en el que la empresa almacena sus
registros financieros (10.1.1.100/32) y otra para la subred que contiene los hosts del
departamento de contabilidad (10.1.5.0/24). Seguidamente creará una directiva
intrazonal para permitir el acceso al servidor desde esos hosts.
WebUI
1. Zona Trust: interfaces y bloqueo
Zone Name: Trust

Interface Mode: NAT
Zone Name: Trust

Interface Mode: NAT
Network > Zones > Edit (para Trust): Introduzca los siguientes datos y haga
clic en OK:
Block Intra-Zone Traffic: (seleccione)

2. Direcciones
Directiva > Elementos de directiva > Direcciones > Lista > Nuevo:
Address Name: Hamilton

Zone: Trust
Directiva > Elementos de directiva > Direcciones > Lista > Nuevo:
Address Name: contabilidad

Zone: Trust
3. Directiva
Policy > Policies > (From: Trust, To: Trust) > New: Introduzca los siguientes
Source Address:
Address Book Entry: (seleccione), contabilidad
Address Book Entry: (seleccione), Hamilton
Service: ANY
Action: Permit
CLI
1. Zona Trust: interfaces y bloqueo
set zone trust block
2. Direcciones
set address trust Hamilton 10.1.1.100/32
set address trust contabilidad 10.1.5.0/24
3. Directiva
set policy from trust to trust contabilidad Hamilton any permit
save
Creación de una directiva global

En este ejemplo, creará una directiva global de manera que todos los host en todas
las zonas puedan tener acceso al sitio Web de la compañía, que es www.juniper.net.
Cuando hay varias zonas de seguridad, el uso de una directiva global es un recurso
que facilita el trabajo. En este ejemplo, una directiva global logrará lo mismo que n
directivas interzonales (donde n = número de zonas).

NOTA: Para utilizar un nombre de dominio en lugar de una dirección IP, asegúrese de
tener configurado el servicio DNS en el dispositivo de seguridad.
WebUI
1. Dirección global
Address Name: servidor1

Domain Name: (seleccione), www.juniper.net
Zone: Global
2. Directiva
Policy > Policies > (From: Global, To: Global) > New : Introduzca los
Source Address:
Address Book Entry: (seleccione), servidor1
Service: HTTP
Action: Permit
CLI
1. Dirección global
set address global servidor1 www.juniper.net
2. Directiva
set policy global any servidor1 http permit
save
Introducción del contexto de una directiva

Al configurar por primera vez una directiva mediante CLI, puede introducir su
contexto para agregar o modificar datos. Por ejemplo, suponga que primero crea la
directiva siguiente:
set policy id 1 from trust to untrust host1 servidor1 HTTP permit attack
HIGH:HTTP:SIGS action close
Si desea efectuar algunos cambios en una directiva, como la inclusión de otra

dirección de origen o de destino, otro servicio u otro grupo de ataque, puede
introducirse en el contexto de la directiva 1 y luego ejecutar los comandos
pertinentes:
set policy id 1
device(policy:1)-> set src-address host2
device(policy:1)-> set dst-address servidor2
device(policy:1)-> set service FTP
device(policy:1)-> set attack CRITICAL:HTTP:SIGS

También puede eliminar varios elementos de un mismo componente de directiva,

siempre que no elimine todos. Por ejemplo, puede eliminar servidor2 de la
configuración anterior, pero no servidor2 y servidor1 a la vez, porque no quedaría
ninguna dirección de destino.
Varios elementos por componente de directiva

ScreenOS permite agregar múltiples elementos a los siguientes componentes de
una directiva:
Dirección de origen
Dirección de destino
Servicio
Grupo de ataque
En versiones anteriores a ScreenOS 5.0.0, la única manera de tener varias

direcciones de origen y destino o varios servicios es crear un grupo de direcciones o
de servicios con varios miembros y luego hacer referencia al mismo en una
directiva. En las directivas de ScreenOS 5.0.0 todavía se pueden utilizar grupos de
direcciones y de servicios. Además, puede simplemente agregar elementos
adicionales directamente a un componente de la directiva.
NOTA: Si la primera dirección o servicio al que se hace referencia en una directiva es

“Any”, no se le podrá agregar lógicamente nada más. ScreenOS impide este tipo
de errores de configuración y muestra un mensaje de error cuando ocurren.
Para agregar múltiples elementos a un componente de directiva, ejecute cualquiera

de los siguientes procedimientos:
WebUI
Para agregar más direcciones y servicios, haga clic en el botón Multiple junto al
componente al que desea agregar más elementos. Para agregar más grupos de
ataque, haga clic en el botón Attack Protection. Seleccione un elemento en la
columna “Available Members” y utilice la tecla << para moverlo a la columna
“Active Members”. Puede repetir esta acción con otros elementos. Cuando haya
terminado, haga clic en OK para regresar a la página de configuración de
directivas.
CLI
Entre al contexto de la directiva con el comando siguiente:
set policy id número
Ahora utilice uno de los comandos siguientes según convenga:
device(policy:number)-> set src-address string

device(policy:number)-> set dst-address string
device(policy:number)-> set service string
device(policy:number)-> set attack string

Ajuste de la negación de direcciones

Puede configurar una directiva de modo que sea aplicable a todas las direcciones
salvo a la especificada como origen o destino. Por ejemplo, suponga que desea
crear una directiva que permita el acceso a Internet a todos salvo al grupo de
direcciones “Subcontratistas”. Para lograrlo, puede utilizar la opción de negación de
direcciones.
En WebUI, esta opción está disponible en la ventana emergente que aparece al

hacer clic en el botón Multiple junto a Source Address o Destination Address en la
página de configuración de directivas.
En CLI, inserte un signo de exclamación ( ! ) inmediatamente antes de la dirección

de origen o de destino.
NOTA: La negación de direcciones ocurre en el nivel de componentes de directivas,

aplicándose a todos los elementos del componente negado.
En este ejemplo creará una directiva intrazonal que permitirá a todas las
direcciones de la zona Trust acceder a todos los servidores FTP salvo a un
determinado servidor FTP llamado “vulcan”, que los miembros del departamento
de ingeniería utilizan para intercambiar especificaciones funcionales entre sí.
Sin embargo, antes de crear la directiva deberá diseñar el entorno en el cual desea
aplicarlo. Primero habilitará el bloqueo intrazonal para la zona Trust. El bloqueo
intrazonal requiere efectuar una consulta de directivas antes de que el dispositivo
de seguridad pueda pasar tráfico entre dos interfaces unidas a la misma zona.
En segundo lugar, asociará dos interfaces a la zona Trust y les asignará direcciones
IP:
Asociará ethernet0/1 a la zona Trust y le asignará la dirección IP 10.1.1.1/24.
Asociará ethernet0/4 a la zona Trust y le asignará la dirección IP 10.1.2.1/24.
Tercero, creará una dirección (10.1.2.5/32) para el servidor FTP llamado “vulcan”
en la zona Trust.
Después de completar estos dos pasos, podrá crear las directivas intrazonales.
NOTA: No es necesario crear una directiva para que el departamento de ingeniería pueda
llegar a su servidor FTP, ya que los ingenieros también se encuentran en la subred
10.1.2.0/24 y no necesitan cruzar el cortafuegos de Juniper Networks para llegar a
su propio servidor.

Figura 61: Negación de directivas intrazonales
10.1.1.1/24 10.1.2.1/24
Conmutadores internos
10.1.1.0/24 10.1.2.0/24
(Resto de la empresa) (Ingeniería)
Zona Trust
Bloqueo intrazonal habilitado Servidor FTP
“vulcan” 10.1.2.5
WebUI
1. Bloqueo intrazonal
Network > Zones > Edit (para Trust): Introduzca los siguientes datos y haga
clic en OK:

2. Interfaces de la zona Trust
Zone Name: Trust

Interface Mode: NAT
Zone Name: Trust

Interface Mode: NAT
3. Dirección
Address Name: vulcan

Zone: Trust

4. Directiva
Policy > Policies > (From: Trust, To: Trust) New: Introduzca los siguientes
Source Address:
Address Book Entry: (seleccione), vulcan
> Haga clic en Multiple, seleccione Negate Following y después haga clic
en OK para regresar a la página de configuración básica de directivas.
Service: FTP
Action: Permit
CLI
1. Bloqueo intrazonal
set zone trust block
2. Interfaces de la zona Trust
3. Dirección
set address trust vulcan 10.1.2.5/32
4. Directiva
set policy from trust to trust any !vulcan ftp permit
save
Modificación y desactivación de directivas

Una vez creada una directiva, puede volver a ella en cualquier momento para
efectuar modificaciones. En WebUI, haga clic en el vínculo Edit de la columna
“Configure” para elegir la directiva que desea cambiar. En la página de
configuración de directivas correspondiente a esa directiva, realice sus cambios y
haga clic en OK. En CLI, ejecute el comando set policy.
ScreenOS también proporciona un medio para habilitar e inhabilitar directivas. De

forma predeterminada, las directivas están habilitadas. Para desactivarlas, haga lo
siguiente:
WebUI
Directivas: Desactive la casilla de verificación Enable de la columna Configure
para la directiva que desee desactivar.
La fila de texto de una directiva inhabilitada aparece en color gris.
CLI
set policy id núm_id disable
save

NOTA: Para volver a habilitar la directiva, seleccione Enable en la columna Configure de

la directiva que desee habilitar (WebUI) o ejecute el comando unset policy id
núm_id disable (CLI).
Verificación de directivas
ScreenOS ofrece una herramienta para verificar si el orden de las directivas dentro
de la lista de directivas es válido. Existe la posibilidad de que una directiva puede
eclipsar u “ocultar” otra directiva. Considere el ejemplo siguiente:
set policy id 1 from trust to untrust any any HTTP permit

set policy id 2 from trust to untrust any dst-A HTTP deny
Ya que el dispositivo de seguridad realiza una consulta de directivas comenzando

por el principio de la lista, deja de buscar tan pronto como encuentra una
coincidencia de tráfico recibido. En el ejemplo anterior, el dispositivo de seguridad
nunca alcanza la directiva 2 ya que la dirección de destino “any” de la directiva 1 ya
incluye la dirección “dst-A” más específica de la directiva 2. Cuando un paquete
HTTP llega al dispositivo de seguridad desde una dirección en la zona Trust
asociada a dst-A en la zona Untrust, el dispositivo de seguridad siempre encontrará
una coincidencia en la directiva 1.
Para corregir el ejemplo antedicho, basta con invertir el orden de las directivas,
poniendo la más específica en primer lugar:
set policy id 2 from trust to untrust any dst-A HTTP deny

set policy id 1 from trust to untrust any any HTTP permit
Por supuesto, este ejemplo tan simple sólo pretende ilustrar el concepto básico. En
casos donde hay docenas o incluso centenares de directivas, la detección de
directivas eclipsadas por otras directivas puede no resultar tan sencilla. Para
comprobar si hay alguna directiva oculta en su lista de directivas, ejecute el
siguiente comando CLI:
exec policy verify
Este comando informa sobre las directivas ocultadas y sobre la ocultación en

general. Es responsabilidad del administrador corregir la situación.
NOTA: El concepto de “ocultación” de directivas se refiere al hecho de que una directiva

situada más arriba en la lista de directivas siempre se encuentra antes que una
directiva situada más abajo. Debido a que la consulta de directivas utiliza siempre
la primera directiva en la que detecta una coincidencia con el registro de cinco
elementos de las zonas de origen y de destino, con las direcciones de origen y
destino y con el tipo de servicio, si hay otra directiva aplicable al mismo registro
(o a un subconjunto de registros), la consulta de directivas utilizará la primera
directiva de la lista y nunca alcanzará la segunda.

La herramienta de verificación de directivas no puede detectar los casos en los que

una combinación de directivas oculta otra directiva. En el siguiente ejemplo,
ninguna directiva oculta la directiva 3; sin embargo, las directivas 1 y 2 juntas sí la
ocultan:
set group address trust grp1 add host1

set group address trust grp1 add host2
set policy id 1 from trust to untrust host1 servidor1 HTTP permit
set policy id 2 from trust to untrust host2 servidor1 HTTP permit
set policy id 3 from trust to untrust grp1 servidor1 HTTP deny
Reordenamiento de directivas
El dispositivo de seguridad compara todos los intentos de atravesar el cortafuegos
con las directivas, comenzando por la primera que aparece en el conjunto de
directivas de la lista correspondiente (consulte “Listas de conjuntos de directivas”
en la página 164) y avanzando en la lista. Debido a que el dispositivo de seguridad
aplica la acción especificada en la directiva a la primera directiva que coincide en la
lista, es necesario reordenar las directivas desde la más específica a la más general.
(Aunque una directiva específica no impide la aplicación de una directiva más
general situada más abajo en la lista, una directiva general situada más arriba que
una específica sí lo impide).
De forma predeterminada, una directiva recién creada aparece al final de la lista de

conjuntos de directivas. Existe una opción que permite colocar una directiva al
principio de la lista. En la página de configuración de directivas de WebUI,
seleccione Position at Top. En CLI, agregue la palabra clave top al comando set
policy: set policy top …
Para mover una directiva a otra posición dentro de la lista, ejecute cualquiera de los
siguientes procedimientos:
WebUI
Hay dos maneras de reordenar directivas en WebUI: haciendo clic en las flechas
circulares o haciendo clic en la flecha de la columna “Configure”
correspondiente a la directiva que desee mover.
Si hace clic en las flechas circulares:
Aparecerá un cuadro de diálogo con un mensaje para el usuario.
Para mover la directiva al final de la lista, introduzca <-1>. Para moverla

hacia arriba en la lista, introduzca el número de identificación de la
directiva que desea mover.
Haga clic en OK para ejecutar el movimiento.
Si hace clic en la flecha:
Aparecerá la página “Policy Move” mostrando la directiva que desea mover

y una tabla mostrando las otras directivas.

En la tabla que muestra las otras directivas, la primera columna, “Move

Location”, contiene flechas señalando hacia las diversas ubicaciones a las
que puede mover la directiva. Haga clic en la flecha que apunte a la
ubicación en la lista a la que desea mover la directiva.
La página “Policy List” reaparecerá con la directiva movida en su nueva

ubicación.
CLI
set policy move núm_id { before | after } número
save
Eliminación de una directiva

Además de modificar y reubicar una directiva, también puede eliminarla. En
WebUI, haga clic en Remove en la columna “Configure” correspondiente a la
directiva que desea eliminar. Cuando el sistema le pida confirmación para proceder
con la eliminación, haga clic en Yes. En CLI, utilice el comando unset policy
núm_id.

Capítulo 7
Este capítulo presenta las múltiples formas de utilizar un dispositivo de seguridad

de Juniper Networks para administrar el ancho de banda limitado sin comprometer
la calidad y disponibilidad de la red para todos los usuarios. Incluye las siguientes
secciones:
“Administración del ancho de banda a nivel de directivas” en esta página
“Establecimiento de la asignación de tráfico” en la página 196
“Establecimiento de las prioridades del servicio” en la página 200
“Establecer colas de prioridades” en la página 201
“Directivas de entrada” en la página 205
“Asignación de tráfico en interfaces virtuales” en la página 206
“Asignación y marcado de DSCP” en la página 216
Por asignación de tráfico se entiende la asignación de la porción apropiada del

ancho de banda disponible en la red a cada usuario y aplicación en una
determinada interfaz. Por porción de ancho de banda apropiada se entiende la
combinación óptima entre capacidad de transmisión rentable y calidad de servicio
(“Quality of Service” o “QoS”) garantizada. Los dispositivos de seguridad permiten
configurar el tráfico creando directivas y aplicando los controles de velocidad
apropiados a cada clase de tráfico que pasa por ellos.
Administración del ancho de banda a nivel de directivas

Para clasificar el tráfico, cree directivas y especifique el ancho de banda
garantizado, el ancho de banda máximo y la prioridad de cada clase de tráfico. El
ancho de banda garantizado y el ancho de banda máximo no están basados
estrictamente en directivas. Con varias interfaces físicas en la zona de salida, el
ancho de banda se basa tanto en directivas como en el ancho de banda de interfaz
física de salida disponible total. El ancho de banda físico de cada interfaz se asigna
al parámetro de ancho de banda garantizado para todas las directivas para
asignación de tráfico. Cualquier porción de ancho de banda sobrante puede
compartirse con cualquier otro tráfico. Es decir, cada directiva obtiene su ancho de
banda garantizado y comparte con las demás directivas la porción sobrante
basándose en la prioridad (siendo el límite su ajuste de ancho de banda máximo).
Administración del ancho de banda a nivel de directivas 195

La función de asignación de tráfico se aplica al tráfico de todas las directivas. Si

desactiva la asignación de tráfico para una directiva específica, pero mantiene
activada la asignación de tráfico para otras directivas, el sistema aplica una directiva
de asignación de tráfico predeterminada a esa directiva en particular, con los
parámetros siguientes:
Ancho de banda garantizado 0
Ancho de banda máximo ilimitado
Prioridad de 7 (el ajuste de prioridad más bajo)
NOTA: Puede habilitar una correspondencia de los niveles de prioridad al sistema

DiffServ Codepoint Marking. Para obtener más información sobre DS Codepoint
Marking, consulte “Asignación de tráfico” en la página 175.
Si no desea que el sistema aplique esta directiva predeterminada a las directivas

para las que ha desactivado la asignación de tráfico, desactive el sistema de
asignación de tráfico ejecutando el comando CLI: set traffic-shaping mode off.
Utilice el siguiente comando CLI: set traffic-shaping mode on para activar la
asignación a una interfaz. También puede establecer la asignación de tráfico a la
opción automática en la WebUI: Configuration > Advanced > Traffic Shaping.
Esto le permite al sistema activar la asignación de tráfico cuando una directiva la
requiera y desactivarla cuando no la requiera.
Establecimiento de la asignación de tráfico

En este ejemplo distribuirá los 45 Mbps de ancho de banda de una interfaz T3 entre
tres departamentos de la misma subred. La interfaz ethernet0/1 está asociada a la
zona Trust y ethernet0/3 a la zona Untrust.
Figura 62: Asignación de tráfico
T3–45 Mbps
Marketing: 10 Mbps de entrada,
10 Mbps de salida
Internet
Enrutador Enrutador
Ventas: 5 Mbps de entrada,
10 Mbps de salida
DMZ para
servidores Zona DMZ
Asistencia: 5 Mbps de entrada,
5 Mbps de salida
196 Establecimiento de la asignación de tráfico

Capítulo 7: Asignación de tráfico
WebUI
1. Ancho de banda en interfaces
Traffic Bandwidth: 45000
NOTA: Si no especifica los ajustes de ancho de banda de una interfaz, el dispositivo de

seguridad utilizará el ancho de banda físico disponible.

2. Ancho de banda en directivas
Name: Asignación de tráfico de Marketing

Source Address:
Address Book Entry: (seleccione), Marketing
Service: Any
Action: Permit
VPN Tunnel: None
NOTA: También puede habilitar la asignación de tráfico en directivas que hagan

referencia a túneles VPN.
Traffic shaping: (seleccione)

Guaranteed Bandwidth: 10000
Maximum Bandwidth: 15000
Name: Directiva de asignación de tráfico de Ventas

Source Address:
Address Book Entry: (seleccione), Ventas
Service: Any
Action: Permit

Establecimiento de la asignación de tráfico 197

Name: Directiva de asignación de tráfico de Asistencia

Source Address:
Address Book Entry: (seleccione), Asistencia
Service: Any
Action: Permit

Name: Permitir acceso de entrada a Marketing

Source Address:
Service: Any
Action: Permit

Name: Permitir acceso de entrada a Ventas

Source Address:
Service: Any
Action: Permit

198 Establecimiento de la asignación de tráfico

Name: Permitir acceso de entrada a Asistencia

Source Address:
Service: Any
Action: Permit

CLI
Para habilitar la asignación de tráfico por cada directiva, haga lo siguiente:

set interface ethernet0/1 bandwidth 45000
NOTA: Si no especifica los ajustes de ancho de banda de una interfaz, el dispositivo de

seguridad utilizará el ancho de banda físico disponible.

set policy name “Asignación de tráfico de Marketing” from trust to untrust
marketing any any permit traffic gbw 10000 priority 0 mbw 15000
set policy name “Directiva de asignación de tráfico de Ventas” from trust to
untrust Ventas any any permit traffic gbw 10000 priority 0 mbw 10000
set policy name “Directiva de asignación de tráfico de Asistencia” from trust to
untrust Asistencia any any permit traffic gbw 5000 priority 0 mbw 10000
set policy name “Permitir acceso de entrada a Marketing” from untrust to trust any
marketing any permit traffic gbw 10000 priority 0 mbw 10000
set policy name “Permitir acceso de entrada a Ventas” from untrust to trust any
Ventas any permit traffic gbw 5000 priority 0 mbw 10000
set policy name “Permitir acceso de entrada a Asistencia” from untrust to trust
any Asistencia any permit traffic gbw 5000 priority 0 mbw 5000
save
Establecimiento de la asignación de tráfico 199

Establecimiento de las prioridades del servicio

La función de asignación de tráfico de los dispositivos de seguridad de
Juniper Networks permite gestionar mediante colas de prioridades el ancho de
banda no asignado al ancho de banda garantizado o el ancho de banda garantizado
que no se utiliza. La gestión mediante colas de prioridades es una característica que
permite a todos los usuarios y aplicaciones tener acceso al ancho de banda
disponible cuando lo necesiten, asegurando al mismo tiempo que el tráfico
importante pueda transmitirse, incluso a expensas del tráfico menos importante si
fuese necesario. La gestión mediante colas permite que el dispositivo de seguridad
canalice el tráfico en un máximo de ocho colas de prioridad diferentes. Estas ocho
colas son:
High priority (alta prioridad)
2nd priority (2ª prioridad)
3rd priority (3ª prioridad)
4th Priority (4ª prioridad)
7th (7ª prioridad)
Low priority (baja prioridad, predeterminada)
El ajuste de prioridad de una directiva significa que el ancho de banda aún no

garantizado a otras directivas se introduce en las colas dando preferencia a la alta
prioridad y luego a la baja. Las directivas que tengan el mismo ajuste de prioridad
competirán por el ancho de banda según el método denominado ronda recíproca
(round robin). El dispositivo de seguridad procesa primero todo el tráfico de todas
las directivas de alta prioridad, para luego procesar el tráfico del ajuste de prioridad
inmediatamente inferior, etcétera, hasta haber procesado todas las solicitudes de
tráfico. Si las solicitudes de tráfico superan el ancho de banda disponible, se
descarta el tráfico de menor prioridad.
PRECAUCIÓN: Tenga cuidado de no asignar un ancho de banda superior al

admitido por la interfaz. El proceso de configuración de directivas no impide crear
configuraciones incompatibles de directivas. Podría llegar a perder datos si el
ancho de banda garantizado de directivas con la misma prioridad sobrepasa el
ancho de banda establecido en la interfaz.
Si no asigna ningún ancho de banda garantizado, puede utilizar la gestión de colas

de prioridades para administrar todo el tráfico de su red. Es decir, todo el tráfico de
alta prioridad se envía antes que cualquier tráfico de 2ª prioridad, etcétera. El
dispositivo de seguridad procesa el tráfico de baja prioridad sólo después de haber
procesado el resto del tráfico.
200 Establecimiento de las prioridades del servicio

Establecer colas de prioridades

En este ejemplo configurará el ancho de banda garantizado y máximo (en Mbps)
para tres departamentos: Asistencia, Ventas y Marketing, según se muestra en la
Tabla 30.
Tabla 30: Configuración de ancho de banda máximo:
Tráfico
Tráfico saliente Tráfico entrante combinado
garantizado garantizado garantizado Prioridad
Asistencia 5 5 10 High
Ventas 2,5 3,5 6 2
Marketing 2,5 1,5 4 3
Total 10 10 20
Si los tres departamentos envían y reciben tráfico simultáneamente a través del

cortafuegos, el dispositivo de seguridad debe asignar 20 Mbps de ancho de banda
para satisfacer los requisitos garantizados de las directivas. La interfaz ethernet0/1
está asociada a la zona Trust y ethernet0/3 a la zona Untrust.
Figura 63: Gestionar colas de prioridades
T3–45 Mbps
Asistencia: 5 Mbps de salida, 5 Mbps
de entrada, alta prioridad
Internet
Enrutador Enrutador
Ventas: 2,5 Mbps de salida, 3,5 Mbps de
entrada, 2da prioridad
DMZ para
servidores Zona DMZ
Marketing: 2.5 Mbps de salida, 1.5 Mbps
de entrada, 3era prioridad
WebUI
Interfaces > Edit (para ethernet0/1): Introduzca los siguientes datos y haga clic
en OK:
en OK:
Establecer colas de prioridades 201


Name: Sup-out
Source Address:
Service: Any
Action: Permit

Traffic Priority: High priority (alta prioridad)
DiffServ Codepoint Marking: (seleccione)
NOTA: “Differentiated Services” (“DS”) es un sistema para etiquetar (o “marcar”) tráfico

en una posición dentro de una jerarquía de prioridades. DS Codepoint Marking
establece una correspondencia entre el nivel de prioridad de ScreenOS en la
directiva y los tres primeros bits de codepoint en el campo “DS” del encabezado
de paquetes IP. Para obtener más información sobre DS Codepoint Marking,
consulte “Asignación de tráfico” en la página 175.
Name: Sal-out
Source Address:
Service: Any
Action: Permit

Traffic Priority: 2nd priority (2ª prioridad)
DiffServ Codepoint Marking: Enable
202 Establecer colas de prioridades

Name: Mar-out
Source Address:
Service: Any
Action: Permit

Traffic Priority: 3rd priority (3ª prioridad)
Name: Sup-in
Source Address:
Service: Any
Action: Permit

Traffic Priority: High priority (alta prioridad)
Name: Sal-in
Source Address:
Service: Any
Action: Permit
Establecer colas de prioridades 203


Traffic Priority: 2nd priority (2ª prioridad)
Name: Mar-in
Source Address:
Service: Any
Action: Permit

Traffic Priority: 3rd priority (3ª prioridad)
CLI
set policy name sup-out from trust to untrust Asistencia any any permit traffic gbw
5000 priority 0 mbw 40000 enable
set policy name sal-out from trust to untrust Ventas any any permit traffic gbw
2500 priority 2 mbw 40000 dscp enable
NOTA: Algunos dispositivos necesitan que active explícitamente la marca de DSCP

estableciendo una variable de entorno en todo el sistema. Consulte el manual del
hardware para saber si su dispositivo necesita que active explícitamente la marca
de DSCP antes de utilizarlo en las directivas. Si su dispositivo lo necesita, utilice el
siguiente comando para activar la marca de DSCP en todo el sistema: set envar
ipsec-dscp-mark=yes. Esta variable no se puede establecer con WebUI. Utilice
unset envar ipsec-dscp-mark para desactivar la marca de DSCP en todo el
sistema.
204 Establecer colas de prioridades

set policy name mar-out from trust to untrust marketing any any permit traffic gbw
set policy name sup-in from untrust to trust any Asistencia any permit traffic gbw
set policy name sal-in from untrust to trust any Ventas any permit traffic gbw 3500
priority 2 mbw 40000 dscp enable
set policy name mar-in from untrust to trust any marketing any permit traffic gbw
save
Directivas de entrada
La directiva de entrada controla el tráfico en la entrada del dispositivo de seguridad.
Al limitar el flujo de tráfico en el punto de entrada, el tráfico que supera el ajuste del
ancho de banda se descarta a través de un proceso mínimo y se conservan los
recursos del sistema. Puede configurar la directiva de entrada a nivel de interfaz y
en las directivas de seguridad.
Configurará la directiva de entrada en una interfaz estableciendo el ancho de banda

máximo (la palabra clave mbw ). Por ejemplo, el comando siguiente limita a
22 Mbps el ancho de banda en ethernet0/1, la interfaz de entrada:
set interface ethernet0/1 bandwidth ingress mbw 22000
Se descartará el tráfico entrante de ethernet0/1 que supere este límite de ancho de

banda. Si se establece la asignación de tráfico en la interfaz, también se debe
acticar el modo de asignación de tráfico (set traffic-shaping mode on).
Sin embargo para aplicar la directiva de entrada a una aplicación específica se

requiere de una directiva. El comando siguiente crea una directiva denominada
mi_ftp que limita el ancho de banda FTP en la entrada del dispositivo de seguridad
a 10 Mbps:
set policy mi_ftp from untrust to trust any any ftp permit traffic pbw 10000
Se descartará el tráfico entrante de FTP que supere el ancho de banda configurado

de la directiva (la palabra clave pbw). También puede establecer mbw en la
directiva, pero a este nivel, el mbw se aplica únicamente a la salida del flujo de
tráfico; aún se procesa el tráfico que supera la velocidad configurada y se descarta
únicamente en la salida (consulte la Figura 65, “Flujo de paquetes en la asignación
de tráfico” en la página 208). Puede configurar mbw o pbw en una directiva, pero
no ambos.
La configuración y el cumplimiento de la directiva de entrada en interfaces virtuales

son iguales que los de las interfaces físicas, con la única excepción de que también
se puede configurar el ancho de banda garantizado (la palabra clave gbw) en las
interfaces virtuales (consulte Asignación de tráfico a nivel de directiva en la
página 208). En las interfaces físicas el ancho de banda garantizado es igual al
ancho de banda máximo.
NOTA: La directiva de entrada en interfaces de túnel entra en vigor después de que el

motor de la VPN haya desencriptado los paquetes encriptados.
Directivas de entrada 205

Asignación de tráfico en interfaces virtuales

En el contexto de asignación de tráfico, el término interfaces virtuales se refiere
únicamente a las subinterfaces y a las interfaces de túnel, y no a otra clase de
interfaces virtuales, como interfaces de seguridad virtual (VSI) o interfaces
agregadas o redundantes. No puede configurar parámetros de asignación en
directivas que se han creado en las VSI. De igual manera, el ancho de banda no
puede asignarse a interfaces que son propiedad (heredadas) de las VSI creadas por
un usuario. Para obtener más información, consulte el Volumen 10:
Sistemas virtuales.
La asignación de tráfico (a diferencia de las directivas de entrada) se refiere a la

administración del tráfico en la salida del dispositivo de seguridad. Al igual que con
las interfaces físicas, asignará el tráfico en interfaces virtuales estableciendo valores
de ancho de banda a nivel de interfaz y en las directivas.
Asignación de tráfico a nivel de interfaz

La asignación de tráfico a nivel de interfaz es el control de la velocidad mínima y
máxima del flujo del tráfico en una interfaz específica. Se controla el ancho de
banda mínimo especificando un ancho de banda garantizado (gbw). Esto significa
que independientemente de cualquier cosa que suceda en el dispositivo, la
velocidad mínima está garantizada para el tráfico correspondiente. El ancho de
banda máximo (mbw) que se establece, determina la velocidad que el tráfico no
podrá exceder en ningún momento. De forma predeterminada, el ancho de banda
máximo de una interfaz física es la capacidad de transmisión de una interfaz, por lo
que no podrá establecer un ancho de banda garantizado en una interfaz física.
En el contexto de asignación de tráfico, el término de interfaces virtuales se refiere

a subinterfaces asociadas a interfaces físicas y, por extensión, las interfaces de túnel
están asociadas a esas subinterfaces, lo que crea una jerarquía de interfaces. Se dice
que una subinterfaz asociada a una interfaz física es el hijo de la interfaz física, que
es su padre. Por consiguiente, una interfaz de túnel asociada a una subinterfaz es el
hijo de una subinterfaz, y la interfaz física es su abuelo. La Figura 64 en la
página 206 ilustra estas dependencias.
Figura 64: Jerarquía de interfaces
ethernet0/1
mbw 10000
ethernet0/1.1 ethernet0/1.2
gbw 5000 - mbw 7000 gbw 2000 - mbw 5000
Interfaces virtuales
Tunnel.1 Tunnel.2 Tunnel.3 Tunnel.4

Tunnel.1 Tunnel.2
gbw 2000 - mbw 3000 gbw 2000 - mbw 3000
206 Asignación de tráfico en interfaces virtuales

Al trabajar con interfaces virtuales, se deben tener en cuenta las siguientes reglas de
jerarquía de interfaz:
El ancho de banda garantizado asignado a una subinterfaz no puede ser

superior a la capacidad de transmisión de la interfaz física a la que está
asociada. Por ejemplo, en la Figura 64, gbw combinado de ethernet0/1.1 y
ethernet0/1.2 es de 7000 Kbps, 3000 Kbps debajo de mbw de ethernet0/1. Sin
embargo, tenga en cuenta que la banda ancha máxima combinada de estas dos
interfaces supera la capacidad de carga de la interfaz física a la que están
asociadas por 2000 Kbps. Esto es aceptable debido a que la palabra clave mbw
se utiliza únicamente para limitar el tráfico a una velocidad máxima. Si el
tráfico desciende por debajo del ajuste máximo de una subinterfaz, el ancho de
banda queda disponible para cualquier otra interfaz asociada a la misma
interfaz física.
El ancho de banda garantizado asignado a una interfaz de túnel no puede ser

superior al ancho de banda garantizado de la subinterfaz a la que están
asociados.
Si el ancho de banda garantizado no está configurado para el “padre”

inmediato, el ancho de banda se toma de la interfaz del “abuelo”.
El ancho de banda garantizado total de los hijos no puede superar el ancho de

banda garantizado del padre.
El ancho de banda máximo del hijo no puede superar el ancho de banda

máximo del padre.
Como ya se indicó anteriormente, no puede configurar el ancho de banda

garantizado en una interfaz física debido a que el ancho de banda garantizado es
igual que el ancho de banda máximo, que constituye el enlace de velocidad de la
interfaz. Sin embargo, en las interfaces virtuales se puede configurar los valores de
gbw y mbw de salida. También podrá configurar el valor de mbw de entrada, que
es la directiva de entrada a nivel de interfaz. El comando siguiente garantiza la
velocidad de bits de salida de 1000 Kbps en ethernet0/4.1 y la velocidad máxima,
tanto entrante como saliente, de 2000 Kbps:
set interface ethernet0/4.1 bandwidth egress gbw 1000 mbw 2000 ingress mbw
2000
El ancho de banda se establece en la WebUI, en la página Network > Interfaces >

Edit.
Después de establecer el ancho de banda, utilice el comando get traffic-shaping

interface para ver el ancho de banda real que fluye a través del dispositivo de
seguridad. Por ejemplo, puede tener tráfico de entrada en ethernet0/1 y de salida
en ethernet0/3. Si establece el ancho de banda de entrada en ethernet0/1, el
comando get traffic-shaping interface ethernet0/3 mostrará el resultado real en el
dispositivo.
Si se establece la asignación de tráfico en la interfaz, también se debe acticar el

modo de asignación de tráfico (set traffic-shaping mode on).
Asignación de tráfico en interfaces virtuales 207

Asignación de tráfico a nivel de directiva

Se asigna el tráfico a nivel de directiva para asignar ancho de banda para
determinados tipos de tráfico. El comando siguiente garantiza un ancho de banda
mínimo de 1 Mbps para tráfico FTP y descarta cualquier tráfico que supere los
2 Mbps:
set policy from trust to untrust any any ftp permit traffic gbw 1000 pbw 2000
Observe que este comando utiliza la palabra clave del ancho de banda de directiva
(pbw). Se pueden utilizar los valores de pbw o mbw en una directiva, pero no
ambos. La ventaja de utilizar pbw es que el tráfico se descarta en la entrada del
dispositivo de seguridad, lo que reduce el procesamiento y conserva los recursos del
sistema. (Consulte “Directivas de entrada” en la página 205.)
En la WebUI, después de crear una directiva, haga clic en el botón Advanced para
configurar los parámetros de asignación de tráfico.
A pesar de que se debe activar el modo de asignación de tráfico (on) para asignar el
tráfico en las interfaces, no es necesario activar la asignación de tráfico cuando se
asigna el tráfico en las directivas. Esto se debe a que el modo de asignación de
tráfico está establecido en auto de forma predeterminada. Cuando una sesión se
activa y una consulta de directivas descubre la asignación de tráfico, ScreenOS
activa la asignación de tráfico para esa sesión.
Flujo de paquetes
La Figura 65 ilustra la parte del flujo de paquetes a través del dispositivo de
seguridad a la que afecta la directiva y la asignación de tráfico. (Consulte
“Secuencia de flujo de paquetes” en la página 10 para ver el funcionamiento
completo del flujo de paquetes.) Los paquetes que sobrepasan el pbw (o el mbw
configurado en la interfaz) se descartan en el paso 9; la asignación y el marcado
DSP se llevan a cabo en el paso 10 y los paquetes que sobrepasan el mbw
(configurado en una directiva) se descartan en el paso 11.
Figura 65: Flujo de paquetes en la asignación de tráfico

Paquete
entrante 8 9 10 11
Crear Directivas Tareas programadas

sesión (si están habilitadas)
Tabla de sesiones
d 977 vsys id 0, flag 000040/00, Interfaz de entrada Asigne y marque DSCP Continúe con todas las
pid -1, did 0, time 180 en el paquete, luego interfaces de salida en el
o bien
13 (01) 10.10.10.1/1168 -> colóquelo en cola en la dispositivo y transmita los
211.68.1.2/80, 6, 002be0c0066b, Directiva interfaz de salida paquetes en cola
subif 0, tun 0

Ejemplo: VPN basada en rutas con directiva de entrada

Este ejemplo ilustra cómo aplicar la directiva de entrada a nivel de interfaz para
tráfico encriptado. La directiva de entrada se configura tanto en la subinterfaz
(ethernet0/2.1, ancho de banda máximo:1200 Kbps) como en la interfaz de túnel
(tunnel.1, ancho de banda máximo:1000 Kbps). Se establece la tasa de la directiva
en la subinterfaz con un valor superior a la interfaz de túnel asociada a ella que
permita el procesamiento de encriptación (se asume en este ejemplo que todo el
tráfico recibido en la interfaz es para la interfaz de túnel). La directiva de la
subinterfaz se aplica a los paquetes encriptados, mientras que la directiva de la
interfaz de túnel se aplica a los paquetes internos desencriptados. Se descarta
cualquier tráfico encriptado superior a 1200 Kbps en ethernet0/2.1. Y se descarta
cualquier tráfico desencriptado (texto legible sin formato) superior a 1000 Kbps en
la interfaz de tunnel.1.
Figura 66: VPN basada en rutas:
San Francisco Nueva York

Dispositivo1 ethernet0/2 ethernet0/2 Dispositivo2
ethernet2.1, ethernet0/2.1,
2.2.2.1/24 2.2.2.2/24
ethernet0/1, ethernet0/1,
10.1.1.1/24 Subinterfaces 10.2.0.2/24
tunnel.1 Interfaces de túnel tunnel.1
Clientes
Servidor
Zona Trust Zona Trust
WebUI (configuración para el dispositivo1)

1. Interfaces
Zone: Trust
Network > Interfaces > Sub-IF > New: Introduzca los siguientes datos y haga
clic en Apply:
Interface Name: (Seleccione) ethernet0/2 and enter: 1

Zone: Untrust
VLAN Tag: 128
clic en Apply:
Tunnel Interface Name: 1

Zone: Untrust
Unnumbered (seleccione) ethernet0/2.1
Interface: ethernet0/2.1

2. Ruta

interface (seleccione): Tunnel.1
3. IKE
VPN > AutoKey Advanced > Gateway > New: Introduzca los siguientes datos
y haga clic en OK:
Gateway Name: device1_ike

Security Level: Standard
Remote Gateway Type:
Static IP Address: (seleccione), IP Address/Hostname: 2.2.2.2
Clave previamente compartida
Preshared Key: secret

Outgoing Interface: ethernet0/2.1
VPNs > AutoKey IKE New: Introduzca los siguientes datos y haga clic en OK:
VPN Name: device1_vpn

> Advanced: Introduzca los siguientes ajustes avanzados y haga clic

en Return para regresar a la página de configuración básica de AutoKey
IKE:
Bind to: (seleccione) Tunnel Interface, (seleccione) tunnel.1
CLI (configuración para el dispositivo1)

1. Interfaces
set interface ethernet0/2.1 tag 128 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet0/2.1
set route 10.2.0.0/24 int tunnel.1
2. IKE
set ike gateway device1_ike address 2.2.2.2 outgoing-interface ethernet0/2.1
preshare sec-level standard
set vpn device1_vpn gateway 208a_ike sec-level standard
set vpn device1_vpn bind interface tunnel.1
save

1. Interfaces
Zone: Trust

Network > Interfaces > Sub-IF > New: Introduzca los siguientes datos y haga
clic en Apply:
Interface Name: (Seleccione) ethernet0/2 and enter: 1

Zone: Untrust
VLAN Tag: 128
Network > Interfaces > Tunnel IF > New: Introduzca los siguientes datos y
haga clic en Apply:

Unnumbered: (seleccione) ethernet0/2.1
Interface: ethernet0/2.1
Network > Interfaces > Edit (para ethernet0/2.1): Introduzca los siguientes
Traffic Bandwidth, Ingress: 1200
Network > Interfaces > Edit (para tunnel.1): Introduzca los siguientes datos y
haga clic en OK:
3. Ruta

interface (seleccione): Tunnel.1
4. IKE
y haga clic en OK:

Outgoing Interface: ethernet0/2.1


IKE:
Bind to: (seleccione) Tunnel Interface, (seleccione) tunnel.1

5. Directivas
Service: Any
Action: Permit
Service: Any
Action: Permit

1. Interfaces
set interface ethernet0/2.1 tag 128 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet0/2.1
set route 10.1.1.0/24
set interface ethernet0/2.1 bandwidth ingress mbw 1200
set interface tunnel.1 bandwidth ingress mbw 1000
3. IKE
set ike gateway device2_ike address 2.2.2.1 preshare secret sec-level standard
set vpn device2_vpn gateway 208b_ike sec-level standard
set vpn device2_vpn bind interface tunnel.1
4. Directiva
set policy from untrust to trust any any any permit
save
Ejemplo: VPN basada en directivas con directiva de entrada

Este ejemplo ilustra cómo aplicar la directiva de entrada a nivel de interfaz y en
directivas. En la interfaz ethernet0/1 en el Dispositivo1, se establece el ancho de
banda máximo de entrada en 20000 Kbps. Con este ajuste se descarta cualquier
tráfico superior a 20000 Kbps de clientes conectados al Dispositivo1 en la interfaz
ethernet0/1. La directiva de entrada de la interfaz se aplica a cualquier tráfico que
llegue a esa interfaz. Para aumentar la granularidad, podrá aplicar la directiva de
entrada al nivel de directiva. En este ejemplo se crean directivas para restringir
cualquier tráfico de entrada del protocolo FTP al dispositivo1 creando directivas
entre las zonas Trust y Untrust y estableciendo el ancho de banda de directiva en
5000 Kbps. Se descarta cualquier tráfico FTP superior a 5000 Kbps de la zona Trust
a la zona Untrust.

Figura 67: VPN basadas en directivas
San Francisco Nueva York

Dispositivo1 Dispositivo2
ethernet0/2, ethernet0/2,
ethernet0/1, 2.1.1.1 10.2.2.1 ethernet0/1,
10.1.1.1.1 1.1.1.2
Clientes
Servidor

1. Interfaces
Zone: Trust
Interface Mode: (seleccione) NAT
Zone: Untrust
Interface Mode: (seleccione) Route
2. IKE VPN
y haga clic en OK:


Outgoing Interface: ethernet0/2
> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en OK

para regresar a la página de configuración básica de la puerta de enlace:
Phase 1 Proposal: pre-g2-3des-sha


3. Directiva basada en interfaz

4. Enrutamiento
Network > Routing > Destination > New: Introduzca los siguientes datos y
haga clic en OK:
Network IP Address/Netmask: 10.2.1.0/24

5. Directivas
Name: 1
Service: FTP
Action: Tunnel
Tunnel VPN: (seleccione), device2_vpn
Modify matching bidirectional VPN policy: (seleccione)

en Return para regresar a la página de configuración básica de directivas:
Traffic Shaping (seleccione) Policing Bandwidth: 5000

1. Interfaces
2. IKE VPN
set ike gateway device2_ike address 2.2.2.2 main outgoing interface ethernet0/2
preshare secret proposal pre-g2-3des-sha
set vpn device2_vpn gateway device2_ike no-replay tunnel idletime 0 sec-level
standard
3. Enrutamiento
4. Directivas
set policy from trust to untrust any any ftp tunnel vpn device2_vpn pair-policy 2
traffic pbw 5000
set policy from untrust to trust any any ftp tunnel vpn netscreen2_vpn pair-policy 1
traffic pbw 5000
5. Directiva basada en interfaz
set interface ethernet0/1 bandwidth ingress mbw 20000
save


1. Interfaces
Zone: Trust
Interface Mode: (seleccione) Route
Zone: Untrust
Interface mode: (seleccione) NAT
2. IKE VPN
y haga clic en OK:

3. Clave previamente compartida

para regresar a la página de configuración básica de la puerta de enlace:
Phase 1 Proposal: pre-g2-3des-sha

4. Enrutamiento
haga clic en OK:
Network IP Address/Netmask: 10.1.1.0/24

5. Directivas
Name: 1
Service: FTP
Action: Tunnel
Tunnel VPN: (seleccione), device1_vpn


1. Interfaces
set interface ethernet0/1 1.1.1.2/24
2. IKE VPN
set ike gateway device1_ike address 2.1.1.1 main outgoing interface ethernet0/2
preshare secret proposal pre-g2-3des-sha
set vpn device1_vpn gateway device1_ike no-replay tunnel idletime 0 sec-level
standard
3. Enrutamiento
4. Directivas
set policy id 1 from trust to untrust any any ftp tunnel vpn device1_vpn pair-policy 2
set policy id 2 from untrust to trust any any ftp tunnel vpn device1_vpn pair-policy 1
save
Asignación de tráfico utilizando la interfaz de bucle invertido

La asignación de tráfico no se admite en las interfaces de bucle invertido debido a
que por la interfaz de bucle invertido no se llega a transmitir tráfico. Sin embargo,
una interfaz de bucle invertido generalmente se utiliza como punto de anclaje (por
ejemplo, en el caso de una VPN, para derivar la dirección IP de origen), al mismo
tiempo que los datos se transmiten en una interfaz de salida real. Por lo tanto,
cuando se utiliza una interfaz de bucle invertido en una VPN, se configura la
asignación de tráfico en la interfaz de salida. Luego ScreenOS asocia la sesión con la
verdadera interfaz de salida, que deduce a partir de la tabla de enrutamiento y
actualiza la asociación en forma dinámica de acuerdo con los cambios de la tabla
de enrutamiento.
Asignación y marcado de DSCP

Como se estableció anteriormente en este capítulo, “Differentiated Services” (“DS”)
es un sistema para etiquetar (o “marcar”) tráfico en una posición dentro de una
jerarquía de prioridades. El marcado de código de servicios diferenciados (DSCP)
asigna el nivel de prioridad de ScreenOS en la directiva y los tres primeros bits de
codepoint en el campo “DS” del encabezado de paquetes IP. (Consulte
Establecimiento de las prioridades del servicio en la página 200 para obtener más
información).
Se puede asignar tráfico en una directiva que utiliza el marcado DSCP o se puede
utilizar el marcado DSCP independientemente de la asignación de tráfico. La
asignación de tráfico permite controlar la forma en que se procesa el tráfico en el
dispositivo de seguridad y se puede configurar al nivel de interfaz o en las
directivas. El marcado DSCP que se establece a nivel de directiva, permite controlar
la forma en que procesan el tráfico los enrutadores en sentido descendente.
216 Asignación de tráfico utilizando la interfaz de bucle invertido

NOTA: Algunos dispositivos necesitan que active explícitamente la marca de DSCP

estableciendo una variable de entorno en todo el sistema. Consulte el manual del
hardware para saber si su dispositivo necesita que active explícitamente la marca
de DSCP antes de utilizarla en las directivas. Si su dispositivo la necesita, utilice el
siguiente comando para activar la marca de DSCP en todo el sistema: set envar
ipsec-dscp-mark=yes. Esta variable no se puede establecer con WebUI. Utilice
unset envar ipsec-dscp-mark para desactivar la marca de DSCP en todo el
sistema.
Si especifica el marcado DSCP en una directiva pero no se establece un valor,

ScreenOS establece una correspondencia entre la prioridad de la directiva y la
prioridad de precedencia IP equivalente en el sistema DSCP. Para ello, sobrescriba
los primeros 3 bits del byte ToS con la prioridad de precedencia IP. Por ejemplo, si
se crea una directiva que da una prioridad 2 (0 es la prioridad más alta) a todo el
tráfico y se habilita el marcado DSCP, ScreenOS pone en cola al tráfico con esa
directiva a un nivel de prioridad 2 en la interfaz de salida y la marca con una
prioridad de precedencia IP equivalente. El comando siguiente crea una directiva
que da prioridad 2 a todo el tráfico y habilita el marcado DSCP:
set policy from trust to untrust any any any permit traffic priority 2 dscp enable
Pero si se le da al DSCP un value dscp-byte de, por ejemplo, 46 (la prioridad más
alta), el dispositivo de seguridad seguirá poniendo en cola el tráfico de la interfaz de
salida en prioridad 2 pero sobrescribirá los primeros 6 bits del byte ToS con el valor
del DSCP.
set policy from trust to untrust any any any permit traffic priority 2 dscp enable
value 46
El marcado DSCP es compatible con todas las plataformas y se puede configurar

con la asignación de tráfico o independiente. La Tabla 31 muestra cómo funciona el
marcado DSCP para los paquetes de texto legible en las directivas, la Figura 66
muestra cómo funciona el marcado DSCP para los paquetes de texto legible en VPN
basada en directivas, la Tabla 33 muestra cómo funciona el marcado DSCP para
paquetes de texto legible en VPN basada en rutas.
Tabla 31: Marcado DSCP para tráfico en texto legible
Descripción Acción
Paquete de texto legible sin marca en la Sin marca.
directiva.
Paquete de texto legible marcado en la Se marca el paquete según la directiva.
directiva.
Paquete marcado previamente sin marca en la Conservar la marca del paquete.
directiva.
Paquete marcado previamente con marcado en Sobrescribir la marca del paquete según la
la directiva. directiva.
Asignación y marcado de DSCP 217

Tabla 32: Marcado DSCP para las VPN basadas en directivas
Paquete de texto legible en una VPN basada en Sin marca.
directivas sin marca en la directiva.
Paquete de texto legible en una VPN basada en Se marcan tanto el paquete interno como el
directivas con marca en la directiva. encabezado de la ESP, según la directiva.
Paquete marcado previamente en una VPN Copiar la marca del paquete interno en el
basada en directivas sin marca en la directiva. encabezado de la ESP, se conserva la marca en
el paquete interno.
Paquete marcado previamente en una VPN Sobrescribir la marca en el paquete interno
basada en directivas con marca en la directiva. según la directiva y copiar la marca del paquete
interno en el encabezado de la ESP.
Tabla 33: Marcado DSCP para las VPN basadas en rutas

Paquete de texto legible en VPN basada en Sin marca.
rutas sin marca en la directiva.
Paquete de texto legible en VPN basada en Se marcan tanto el paquete interno como el
rutas con marca en la directiva. encabezado de la ESP, según la directiva.
Paquete marcado previamente en una VPN Copiar la marca del paquete interno en el
basada en rutas sin marca en la directiva. encabezado de la ESP, se conserva la marca en
el paquete interno.
Paquete marcado previamente en una VPN Sobrescribir la marca en el paquete interno
basada en rutas con marca en la directiva. según la directiva y copiar la marca del paquete
interno en el encabezado de la ESP.
218 Asignación y marcado de DSCP

Capítulo 8
Parámetros del sistema
El tema principal de este capítulo son los conceptos relativos al establecimiento de

los parámetros del sistema que afectan a las siguientes áreas de un dispositivo de
seguridad. Incluye las siguientes secciones:
“Compatibilidad con DNS (sistema de nombres de dominio)” en esta página
“Protocolo de configuración dinámica de host” en la página 227
“Protocolo punto a punto sobre Ethernet” en la página 246
“Claves de licencia” en la página 253
“Registro y activación de los servicios de suscripción” en la página 254
“Reloj del sistema” en la página 256
Compatibilidad con DNS (sistema de nombres de dominio)

El dispositivo de seguridad de Juniper Networks admite el sistema de nombres de
dominio (DNS), que le permite utilizar tanto nombres de dominios como
direcciones IP para identificar ubicaciones. Un servidor DNS mantiene una tabla de
direcciones IP asociadas a los correspondientes nombres de dominio. El sistema
DNS permite referirse a una ubicación por medio de su nombre de dominio (como
www.juniper.net), además de utilizar la correspondiente dirección IP enrutable, que
en el caso de www.juniper.net es 207.17.137.68. Todos los programas siguientes
pueden realizar traducción de DNS:
Libreta de direcciones
Syslog
Correo electrónico
WebTrends
Websense
LDAP
SecurID
Compatibilidad con DNS (sistema de nombres de dominio) 219

RADIUS
NetScreen-Security Manager
Para poder utilizar el sistema DNS en la resolución de nombres de dominio y

direcciones, debe introducir las direcciones de los servidores DNS en el dispositivo
de seguridad.
NOTA: Para habilitar el dispositivo de seguridad como servidor del protocolo de

configuración de host dinámico (DHCP) (consulte “Protocolo de configuración
dinámica de host” en la página 227), también deberá introducir las direcciones IP
de los servidores DNS en la página DHCP de la WebUI o mediante el comando CLI
set interface interfaz dhcp.
Consulta DNS
El dispositivo de seguridad actualiza todas las entradas de su tabla DNS
comprobándolas en un servidor DNS especificado en los momentos siguientes:
Al producirse una conmutación por error de HA (alta disponibilidad)
A una hora determinada y a intervalos regulares programados a lo largo del día
Cuando se ordena manualmente al dispositivo realizar una consulta DNS
WebUI: Network > DNS > Host: Haga clic en Refresh
CLI: exec dns refresh
Además del método existente de establecer una hora para la actualización diaria y
automática de la tabla DNS, también puede definir un intervalo de tiempo entre 4 y
24 horas.
NOTA: Cuando se agrega un nombre de dominio totalmente clasificado (FQDN), como

una dirección o una puerta de enlace IKE, mediante la WebUI, el dispositivo de
seguridad lo resuelve al hacer clic en Apply o en OK. Cuando se escribe un
comando CLI que hace referencia a un FQDN, el dispositivo de seguridad intenta
resolverlo en el momento de introducirlo.
Cuando el dispositivo de seguridad se conecta al servidor DNS para resolver una

asignación de nombre de dominio o dirección IP, almacena esa entrada en su tabla
de estado de DNS. La lista siguiente contiene algunos de los detalles relativos a una
consulta DNS:
Cuando una consulta DNS devuelve varias entradas, la libreta de direcciones

acepta todas. Los otros programas enumerados en la página 219 solamente
aceptan la primera.
El dispositivo de seguridad reinstala todas las directivas si detecta cualquier

cambio en la tabla de nombres de dominios en el momento en que el usuario
actualiza una consulta con el botón Refresh de la WebUI o introduce el
comando CLI exec dns refresh.
220 Compatibilidad con DNS (sistema de nombres de dominio)

Capítulo 8: Parámetros del sistema
Cuando falla un servidor DNS, el dispositivo de seguridad vuelve a consultar

todo de nuevo.
Cuando falla una consulta, el dispositivo de seguridad la elimina de la tabla de

caché.
Si la consulta del nombre de dominio no consigue agregar direcciones a la

libreta de direcciones, el dispositivo de seguridad muestra un mensaje de error
indicando que la dirección fue agregada con éxito, pero la consulta del nombre
DNS falló.
El dispositivo de seguridad debe realizar una nueva consulta una vez al día, que
puede programar para que se realice a una hora específica.
WebUI
Network > DNS > Host: Introduzca los siguientes datos y haga clic en Apply:
DNS refresh every day at: Seleccione la casilla de verificación e introduzca la

hora <hh:mm>
CLI
set dns host schedule cadena_nombre
save
Tabla de estado de DNS

La tabla de estado de DNS comunica todos los nombres de dominios consultados,
sus correspondientes direcciones IP, si la consulta se efectuó con éxito y cuándo se
resolvió por última vez cada nombre de dominio o dirección IP.
Tabla 34: Tabla de estado de DNS
Nombre Dirección IP Estado Última consulta

www.yahoo.com 204.71.200.74 Éxito 8/13/2000 16:45:33
204.71.200.75
204.71.200.67
204.71.200.68
www.hotbot.com 209.185.151.28 Éxito 8/13/2000 16:45:38
209.185.151.210
216.32.228.18
Para visualizar la tabla de estado de DNS, ejecute cualquiera de los siguientes

procedimientos:
WebUI
Network > DNS > Host > Show DNS Lookup Table
CLI
get dns host report


actualizaciones
Para implementar la funcionalidad de DNS, se introducen en el dispositivo de
seguridad las direcciones IP de los servidores DNS en 24.1.64.38 y 24.0.0.3,
protegiendo un host único de una oficina central. El dispositivo de seguridad se
programa para actualizar los ajustes de DNS almacenados en su tabla de estado de
DNS diariamente a las 11:00 de la noche.
Figura 68: Actualización de DNS

Servidor DNS
secundario 24.1.64.38
Zona Trust Servidor DNS
Zona Untrust principal 24.0.0.3
Internet
WebUI
Primary DNS Server: 24.0.0.3

Secondary DNS Server: 24.1.64.38
DNS Refresh: (seleccione)
Every Day at: 23:00
CLI
set dns host dns1 24.0.0.3
set dns host dns2 24.1.64.38
set dns host schedule 23:00
save
Establecimiento de un intervalo de actualización de DNS

En este ejemplo configurará el dispositivo de seguridad para actualizar su tabla DNS
cada 4 horas, comenzando a las 00:01 horas cada día.
WebUI
DNS Refresh: (seleccione)

Every Day at: 00:01
Interval: 4
CLI
set dns host schedule 0:01:00 interval 4
save

Sistema de nombres de dominio dinámicos

El sistema de nombres de dominio dinámicos (DDNS) es un mecanismo que
permite a los clientes actualizar dinámicamente las direcciones IP de los nombres
de dominio registrados. Esta actualización es útil cuando un ISP utiliza PPP, DHCP o
XAuth para cambiar dinámicamente la dirección IP de un enrutador CPE (como un
dispositivo de seguridad) que protege un servidor Web. Los clientes procedentes de
Internet pueden obtener acceso al servidor Web utilizando un nombre de dominio,
aunque la dirección IP del enrutador CPE haya cambiado previamente. Este cambio
es posible gracias a un servidor DDNS como dyndns.org o ddo.jp, que contiene las
direcciones cambiadas dinámicamente y sus nombres de dominio asociados. El
CPE actualiza los servidores DDNS con esta información, periódicamente o en
respuesta a cambios de direcciones IP.
Para utilizar DDNS, cree una cuenta (nombre de usuario y contraseña) en el

servidor DDNS. El servidor utiliza esta información de cuenta para configurar el
dispositivo cliente.
Figura 69: DNS dinámico

Cliente Servidor Web
www.my_host.com
Dispositivo de
seguridad
(enrutador CPE)
Internet Zona Trust
Servidor DDNS
ethernet7
dyndns.org o ddo.jp
En la Figura 69, es posible que la dirección IP de la interfaz ethernet7 cambie.

Cuando ocurre un cambio, el cliente todavía puede obtener acceso al servidor Web
protegido indicando el nombre de host (www.my_host.com), a través del servidor
de dyndns.org o del servidor de ddo.jp. Cada uno de estos servidores requiere
diferentes configuraciones en el dispositivo de seguridad.
Establecimiento de DDNS para un servidor DynDNS

En el ejemplo siguiente configurará un dispositivo de seguridad para operar con
DDNS. El dispositivo utiliza el servidor dyndns.org para resolver direcciones
cambiantes. Para este servidor, especificará el host protegido usando el ajuste de
nombre de host, el cual se enlaza explícitamente a la interfaz DNS (ethernet7).
Cuando el dispositivo envía una actualización al servidor ddo.jp, éste asocia el
nombre de host con la dirección IP de la interfaz.

WebUI
Network > DNS > DDNS > New: Introduzca los siguientes datos y haga clic
en OK:
ID: 12
Server Settings
Server Type: dyndns
Server Name: dyndns.org
Refresh Interval: 24
Minimum Update Interval: 15
Account Settings
Username: espada
Password: ad93lvb
Bind to Interface: ethernet7
Host Name: www.my_host.com
NOTA: El intervalo de actualización mínimo especifica el intervalo mínimo de tiempo

(expresado en minutos) entre actualizaciones de DDNS. El valor predeterminado
es de 10 minutos y el rango admisible es 1-1440. En algunos casos, el dispositivo
puede no actualizar el intervalo porque primero el servidor DNS necesita esperar a
que el tiempo de espera de la entrada de DDNS caduque en su caché.
Adicionalmente, si establece el intervalo de actualización mínimo en un valor bajo,
entonces es posible que el dispositivo de seguridad le bloquee el acceso. El valor
recomendado es de 10 minutos o más.
CLI
set dns ddns
set dns ddns enable
set dns ddns id 12 server dyndns.org server-type dyndns refresh-interval 24
minimum-update-interval 15
set dns ddns id 12 src-interface ethernet7 host-name www.my_host.com
set dns ddns id 12 username espada password ad93lvb
save
Establecimiento de DDNS para un servidor DDO

En el ejemplo siguiente configurará un dispositivo de seguridad para DDNS. El
dispositivo utiliza el servidor ddo.jp para resolver direcciones. Para el servidor
ddo.jp, especificará el FQDN del host protegido como nombre de usuario para la
entrada de DDNS, en lugar de especificar el host protegido usando el ajuste Host
Name. El servicio deducirá automáticamente el nombre de host del valor de
Username. Por ejemplo, el servidor ddo.jp traduce un nombre de usuario de
my_host a my_host.ddo.jp. Cerciórese de que el nombre de dominio registrado en
ddo.jp coincida con el DNS deducido.

WebUI
Network > DNS > DDNS > New: Introduzca los siguientes datos y haga clic
en OK:
ID: 25
Server Settings
Server Type: ddo
Server Name: juniper.net
Refresh Interval: 24
Minimum Update Interval: 15
Account Settings
Username: my_host
Password: ad93lvb
Bind to Interface: ethernet7
CLI
set dns ddns
set dns ddns enable
set dns ddns id 25 server ddo.jp server-type ddo refresh-interval 24
minimum-update-interval 15
set dns ddns id 25 src-interface ethernet7
set dns ddns id 25 username my_host password ad93lvb
save
División de direcciones DNS del proxy

La función DNS proxy proporciona un mecanismo transparente que permite a los
clientes dividir consultas DNS. Con esta técnica, el proxy redirige selectivamente las
consultas de DNS a servidores DNS específicos, siguiendo nombres de dominio
parciales o completos. Esto resulta útil cuando los túneles VPN o los enlaces
virtuales PPPoE proporcionan conectividad a múltiple redes y es necesario dirigir
algunas consultas DNS a una red y otras a otra red.
Un proxy DNS tiene las siguientes ventajas:
Las operaciones de consulta de dominios son generalmente más eficientes. Por

ejemplo, las consultas de DNS destinadas al dominio corporativo (como
marketing.acme.com) podrían dirigirse al servidor DNS corporativo
exclusivamente, mientras que todas las demás irían al servidor DNS del ISP,
reduciendo la carga en el servidor corporativo. Esto también puede impedir la
filtración de información del dominio corporativo a Internet.
El proxy de DNS permite transmitir consultas DNS seleccionadas a través de

una interfaz de túnel, impidiendo así que usuarios maliciosos puedan obtener
información sobre la configuración interna de una red. Por ejemplo, las
consultas de DNS unidas al servidor corporativo pueden pasar a través de una
interfaz de túnel y utilizar funciones de seguridad tales como la autenticación,
encriptación y antirreprocesamiento.

Los comandos siguientes crean dos entradas DNS por proxy que reenvían
selectivamente las consultas DNS a diferentes servidores.
Figura 70: División de solicitudes de DNS
juniper.net => 63.126.135.170 Servidores DNS del ISP

juniper.net
1.1.1.23 Internet 63.126.135.170
acme.com => acme_eng.com =>

3.1.1.2 3.1.1.5
ethernet0/3
tunnel.1
*
acme.com
Servidores DNS
corporativos
2.1.1.21
acme_eng.com 2.1.1.34
Toda consulta de DNS con un FQDN que contenga el nombre de dominio

acme.com saldrá a través de la interfaz de túnel tunnel.1 al servidor DNS
corporativo en la dirección IP 2.1.1.21.
Por ejemplo, si un host envía una consulta DNS para resolver www.acme.com,
el dispositivo dirige automáticamente la consulta a este servidor. (Asumamos
que el servidor resuelve la consulta y devuelve la dirección IP 3.1.1.2.)
Cualquier consulta DNS con un FQDN que contenga el nombre de dominio

acme_engineering.com sale a través de la interfaz tunnel.1 al servidor DNS en
la dirección IP 2.1.1.34.
Por ejemplo, si un host envía una consulta DNS para resolver

intranet.acme_eng.com, el dispositivo dirige la consulta a este servidor.
(Asumiremos que el servidor resuelve la consulta devolviendo la dirección
IP 3.1.1.5.)
Todas las demás consultas DNS (marcadas con un asterisco) evitan a los
servidores corporativos y salen a través de la interfaz ethernet0/3 al servidor
DNS en la dirección IP 1.1.1.23.
Por ejemplo, si el host y el nombre de dominio son www.juniper.net, el

dispositivo evita automáticamente los servidores corporativos y dirige la
consulta a este servidor, que resuelve la consulta obteniendo la dirección
IP 207.17.137.68.
WebUI
1. Network > DNS > Proxy: Introduzca los siguientes datos, luego haga clic en Apply:
Initialize DNS Proxy: Enable
Enable DNS Proxy: Enable
2. Network > DNS > Proxy > New: Introduzca los siguientes datos y haga clic en OK:
Domain Name: acme.com
Outgoing Interface: tunnel.1

Domain Name: acme_eng.com
Domain Name: *
CLI
set dns proxy
set dns proxy enable
set interface ethernet0/3 proxy dns
set dns server-select domain acme.com outgoing-interface tunnel.1 primary-server
2.1.1.21
set dns server-select domain acme_eng.com outgoing-interface tunnel.1
primary-server 2.1.1.34
set dns server-select domain * outgoing-interface ethernet0/3 primary-server
1.1.1.23
save
Protocolo de configuración dinámica de host

El protocolo de configuración dinámica de hosts (DHCP: “Dynamic Host
Configuracion Protocol”) fue diseñado para aliviar el trabajo de los administradores
de red asignando automáticamente ajustes TCP/IP a los hosts de una red. En lugar
de obligar a los administradores a asignar, configurar, supervisar y modificar
(cuando sea necesario) todos los ajustes TCP/IP de cada equipo de una red, DHCP
hace todo automáticamente. Además, DHCP garantiza que no se utilicen
direcciones duplicadas, vuelve a asignar las direcciones que han dejado de utilizarse
y asigna automáticamente direcciones IP apropiadas para la subred a la que está
conectado un host.
Cada dispositivo de seguridad admite diferentes funciones CDP descritas en

Tabla 35.
Tabla 35: Funciones de DHCP
Función Descripción
Cliente DHCP Algunos dispositivos de seguridad pueden actuar como clientes de DHCP,
recibiendo una dirección IP asignada dinámicamente para cualquier
interfaz física en cualquier zona.
Servidor DHCP Algunos dispositivos de seguridad también pueden actuar como servidores
de DHCP, asignando direcciones IP dinámicas a hosts (que actúan como
clientes de DHCP) en cualquier interfaz física o VLAN de cualquier zona.
Nota: Aunque utilice el módulo del servidor DHCP para asignar direcciones
a hosts tales como las estaciones de trabajo de una zona, también puede
utilizar direcciones IP fijas para otros equipos, como servidores de correo y
servidores WINS.
Agente de Algunos dispositivos de seguridad también pueden actuar como agentes de
retransmisión de retransmisión de DHCP, recibiendo información de un servidor DHCP y
DHCP retransmitiéndola a los hosts de cualquier interfaz física o VLAN en
cualquier zona.
Protocolo de configuración dinámica de host 227

Tabla 35: Funciones de DHCP (Continuación)
Función Descripción
Cliente/servidor/age Algunos dispositivos de seguridad pueden actuar simultáneamente como
nte de cliente, servidor y agente de retransmisión de DHCP. En una sola interfaz
retransmisión solamente se puede configurar una función de DHCP. Por ejemplo, en la
DHCP misma interfaz no se pueden configurar el cliente y el servidor DHCP.
Opcionalmente, se puede configurar el módulo de cliente DHCP para que
reenvíe los ajustes TCP/IP que recibe al módulo de servidor DHCP, que los
utilizará para proporcionar ajustes TCP a los hosts de la zona Trust que
actúen como clientes DHCP.
DHCP consta de dos componentes: un protocolo para suministrar ajustes de

configuración TCP/IP específicos de cada host y un mecanismo para asignar
direcciones IP. Cuando el dispositivo de seguridad actúa como servidor DHCP, éste
proporciona los siguientes ajustes TCP/IP a cada host cuando se inicia:
Dirección IP y máscara de red predeterminadas de la puerta de enlace. Si deja

estos ajustes como 0.0.0.0/0, el módulo del servidor DHCP utiliza
automáticamente la dirección IP y la máscara de red de la interfaz
predeterminada de la zona Trust.
NOTA: En los dispositivos que pueden tener varias interfaces asociadas a la zona Trust, la
interfaz predeterminada es la primera interfaz asociada a esa zona a la que se
haya asignado una dirección IP.
Las direcciones IP de los servidores siguientes:
Servidores WINS (2): Un servidor del servicio de nombres de Internet de

Windows (WINS) asigna un nombre NetBIOS utilizado en un entorno de red
Windows NT a una dirección IP utilizada en una red basada en IP. El
número en paréntesis indica el número de servidores admitidos.
Servidores NetInfo (2): NetInfo es un servicio de red de Apple utilizado para

la distribución de datos administrativos dentro de una LAN.
Etiqueta de NetInfo (1): La etiqueta identificativa utilizada por la base de

datos de Apple NetInfo.
Servidores DNS (3): Los servidores del sistema de nombres de dominio

(“DNS”) asignan un localizador de recurso uniforme (“Uniform Resource
Locator” o “URL”) a una dirección IP.
Servidor SMTP (1): Los servidores del protocolo simple de transferencia de

correo (“Simple Mail Transfer Protocol” o “SMTP”) entregan mensajes
SMTP a un servidor de correo, por ejemplo un servidor POP3, que
almacena el correo entrante.
Servidor POP3 (1): Los servidores del protocolo de oficina de correo,

versión 3 (“Post Office Protocol” o “POP3”) almacenan el correo entrante.
Cada servidor POP3 debe trabajar conjuntamente con un servidor SMTP.
Servidor News (1): Los servidores de noticias reciben y almacenan avisos

de los grupos de noticias.
228 Protocolo de configuración dinámica de host

NOTA: Si un cliente DHCP al que el dispositivo de seguridad entrega los parámetros

anteriores tiene una dirección IP especificada, ésta dirección reemplaza toda la
información dinámica recibida del servidor DHCP.
Configuración de un servidor DHCP

Un dispositivo de seguridad puede admitir hasta ocho servidores DHCP en
cualquier interfaz física o VLAN de cualquier zona. Cuando actúa como servidor
DHCP, el dispositivo de seguridad asigna direcciones IP y máscaras de subred de
dos modos:
En el modo dinámico, el dispositivo de seguridad, actuando como servidor

DHCP, asigna (o “arrienda”) una dirección IP tomada de un conjunto de
direcciones a un cliente DHCP de host. La dirección IP se arrienda por un
tiempo determinado o hasta que el cliente renuncia a ella. (Para definir un
periodo de arrendamiento ilimitado, introduzca 0).
En el modo reservado, el dispositivo de seguridad asigna una dirección IP

designada tomada de un conjunto de direcciones exclusivamente para un
cliente específico cada vez que éste establece una conexión en línea.
NOTA: Un conjunto de direcciones es un rango de direcciones IP definido en la misma

subred de la que el dispositivo de seguridad puede tomar asignaciones de
direcciones DHCP. Puede agrupar hasta 255 direcciones IP.
El servidor DHCP admite hasta 64 entradas, que pueden incluir direcciones IP

únicas y rangos de dirección IP para direcciones IP reservadas y dinámicas.
El dispositivo de seguridad guarda cada dirección IP asignada mediante DHCP en

su memoria flash. Por lo tanto, el reinicio del dispositivo de seguridad no afecta las
asignaciones de direcciones.
En este ejemplo, mediante DHCP, se seccionará la red 172.16.10.0/24 de la zona

Trust en tres conjuntos de direcciones IP.
172.16.10.10 a 172.16.10.19
172.16.10.120 a 172.16.10.129
172.16.10.210 a 172.16.10.219
El servidor DHCP asigna todas las direcciones IP dinámicamente, excepto dos

estaciones de trabajo con direcciones IP reservadas y cuatro servidores que tienen
direcciones IP estáticas. La interfaz ethernet0/1 está asociada a la zona Trust, tiene
la dirección IP 172.16.10.1/24 y se encuentra en modo NAT. El nombre del dominio
es dynamic.com.

Figura 71: Dispositivo como servidor DHCP

Servidores DNS
Direcciones IP fijas
Zona Trust 172.16.10.240
172.16.10.241
ethernet0/1
172.16.10.1/24 (NAT)
172.16.10.0/24 Conjunto de direcciones

Conjunto de direcciones
LAN 172-16.10.210 – 172.16.10.219
172.16.10.10 – 172.16.10.19
Conjunto de direcciones
172.16.10.120 – 172.16.10.129
IP reservada
172.16.10.11
MAC: 12:34:ab:cd:56:78
Servidores SMTP y POP3
Direcciones IP fijas
IP reservada 172.16.10.25 y 172.16.10.10
172.16.10.112
MAC: ab:cd:12:34:ef:gh
WebUI
1. Direcciones
Address Name: DNS#1

Comment: Servidor DNS primario
Zone: Trust
Address Name: DNS#2

Comment: Servidor DNS secundario
Zone: Trust
Address Name: SMTP

Comment: Servidor SMTP
Zone: Trust

Address Name: POP3

Comment: Servidor POP3
Zone: Trust
2. Servidor DHCP
Network > DHCP > Edit (para ethernet0/1) > DHCP Server: Introduzca los
Lease: Unlimited (seleccione)

WINS#1: 0.0.0.0
DNS#1: 172.16.10.240
NOTA: Si deja los campos Gateway y Netmask como 0.0.0.0, el módulo de servidor
DHCP envía la dirección IP y la máscara de red establecida para ethernet0/1 a sus
clientes (172.16.10.1 y 255.255.255.0 en este ejemplo). Sin embargo, si habilita el
módulo de cliente DHCP para que redireccione ajustes de TCP/IP al módulo del
servidor DHCP (consulte “Propagación de ajustes TCP/IP” en la página 242),
después deberá introducir manualmente 172.16.10.1 y 255.255.255.0 en los
campos Gateway y Netmask, respectivamente.
> Advanced Options: Escriba lo siguiente y haga clic en OK para establecer

las opciones avanzadas y regresar a la página de configuración básica:
WINS#2: 0.0.0.0
DNS#2: 172.16.10.241
DNS#3: 0.0.0.0
SMTP: 172.16.10.25
POP3: 172.16.10.110
NEWS: 0.0.0.0
NetInfo Server # 1: 0.0.0.0
NetInfo Server # 2: 0.0.0.0
NetInfo Tag: (deje el campo vacío)
Domain Name: dynamic.com
> Addresses > New: Introduzca los siguientes datos y haga clic en OK:
Dynamic: (seleccione)
IP Address Start: 172.16.10.10
IP Address End: 172.16.10.19

Reserved: (seleccione)
Dirección IP: 172.16.10.11
Ethernet Address: 1234 abcd 5678
Reserved: (seleccione)
Ethernet Address: abcd 1234 efgh
CLI
1. Direcciones
set address trust dns1 172.16.10.240/32 “primary dns server”
set address trust dns2 172.16.10.241/32 “secondary dns server”
set address trust snmp 172.16.10.25/32 “snmp server”
set address trust pop3 172.16.10.110/32 “pop3 server”
2. Servidor DHCP
set interface ethernet0/1 dhcp server option domainname dynamic.com
set interface ethernet0/1 dhcp server option lease 0
set interface ethernet0/1 dhcp server option dns1 172.16.10.240
set interface ethernet0/1 dhcp server option smtp 172.16.10.25
set interface ethernet0/1 dhcp server option pop3 172.16.10.110
set interface ethernet0/1 dhcp server ip 172.16.10.10 to 172.16.10.19
set interface ethernet0/1 dhcp server ip 172.16.10.11 mac 1234abcd5678
set interface ethernet0/1 dhcp server ip 172.16.10.112 mac abcd1234efgh
set interface ethernet0/1 dhcp server service
save
NOTA: Si no establece una dirección IP para la puerta de enlace o una máscara de red, el
módulo del servidor DHCP envía a sus clientes la dirección IP y máscara de red
para ethernet0/1 (172.16.10.1 y 255.255.255.0 en este ejemplo). Sin embargo, si
habilita el módulo de cliente DHCP para reenviar ajustes TCP/IP al módulo del
servidor DHCP (consulte “Propagación de ajustes TCP/IP” en la página 242),
deberá establecer manualmente estas opciones: set interface ethernet0/1 dhcp
server option gateway 172.16.10.1 y set interface ethernet0/1 dhcp server
option netmask 255.255.255.0.
Personalización de las opciones de servidor DHCP

Al especificar servidores DHCP para una interfaz, es posible que necesite
especificar opciones que identifiquen a los servidores o proporcionen la
información utilizada por éstos. Por ejemplo, puede especificar la dirección IP de
los servidores DNS primario y secundario, o bien establecer el tiempo de
asignación (“lease time”) de la dirección IP.

Los siguientes son servicios DHCP predefinidos, según se describe en RFC 2132,
Opciones de DHCP y extensiones de proveedores de BOOTP.
Tabla 36: Servicios DHCP predefinidos
Código de
Terminología Terminología CLI ScreenOS opción
Máscara de subred netmask 1
Opción del enrutador gateway 3
Servidor del sistema de dns1, dns2, dns3 6
nombres de dominio (DNS)
Nombre de dominio domainname 15
Opción de NetBIOS a través wins1, wins2 44
de TCP/IP en el servidor de
nombres
Tiempo de arrendamiento de lease 51
la dirección IP
Opción del servidor SMTP smtp 69
Opción del servidor POP3 pop3 70
Opción del servidor NNTP news 71
(N/D) nis1, nis2 112
(N/D) nistag 113
En situaciones en las que las opciones predefinidas del servidor no son adecuadas,
puede definir opciones de servidor DHCP personalizadas. Por ejemplo, para
determinadas configuraciones de voz sobre IP (VoIP), es necesario enviar
información adicional de configuración que no es admitida por las opciones
predefinidas del servidor. En tales casos, debe definir opciones personalizadas
apropiadas.
En el ejemplo siguiente creará definiciones de servidor DHCP para teléfonos IP que

actúan como clientes DHCP. Los teléfonos utilizan las opciones personalizadas
siguientes:
Código de opción 444, conteniendo la cadena “Server 4”
Código de opción 66, conteniendo la dirección IP 1.1.1.1
Código de opción 160, conteniendo el número entero 2004

CLI
1. Direcciones
set address trust dns1 172.16.10.240/32 “primary dns server”
set address trust dns2 172.16.10.241/32 “secondary dns server”
2. Servidor DHCP
set interface ethernet0/1 dhcp server option domainname dynamic.com
set interface ethernet0/1 dhcp server option custom 444 string “Server 4”
set interface ethernet0/1 dhcp server option custom 66 ip 1.1.1.1
set interface ethernet0/1 dhcp server option custom 160 integer 2004
Colocación del servidor DHCP en un clúster de NSRP

Cuando la unidad principal de un clúster NSRP redundante actúa como servidor
DHCP, todos los miembros del clúster mantienen todas las configuraciones DHCP y
asignaciones de direcciones IP. Si se produce un cambio en caso de error, la nueva
unidad principal mantiene todas las asignaciones de DHCP. Sin embargo, la
finalización de la comunicación HA interrumpe la sincronización de las
asignaciones DHCP existentes entre miembros del clúster. Una vez restablecida la
comunicación de HA, puede resincronizar las asignaciones de DHCP mediante el
siguiente comando CLI en ambas unidades del clúster: set nsrp rto-mirror sync.
Detección del servidor DHCP

Cuando se inicia un servidor DHCP en un dispositivo de seguridad, el sistema
puede comprobar primero si la interfaz ya tiene un servidor DHCP. ScreenOS
impide automáticamente que se inicie el proceso del servidor DHCP local si detecta
la presencia de otro servidor DHCP en la red. Para detectar otro servidor DHCP, el
dispositivo envía peticiones de arranque DHCP en intervalos de 2 segundos. Si el
dispositivo no recibe ninguna respuesta a sus peticiones de arranque, inicia su
proceso local de servidor DHCP.
Si el dispositivo de seguridad recibe una respuesta de otro servidor DHCP, el

sistema genera un mensaje indicando que el servicio DHCP está habilitado en el
dispositivo de seguridad, pero no se ha iniciado porque hay otro servidor DHCP
presente en la red. El mensaje del registro incluye la dirección IP del servidor DHCP
existente.
Para detectar la presencia de un servidor DHCP en una interfaz, puede utilizarse

uno de los tres modos de funcionamiento siguientes: Auto, Enable o Disable. En el
modo Auto, el dispositivo de seguridad comprueba siempre si hay algún servidor
DHCP presente al iniciar. Puede configurar el dispositivo para que no intente
detectar otro servidor DHCP en una interfaz estableciendo el modo Enable o
Disable del servidor DHCP de seguridad. En el modo “Enable”, el servidor DHCP
está siempre encendido y el dispositivo no comprueba si hay algún servidor DHCP
en la red. En el modo “Disable”, el servidor DHCP está siempre apagado.
Habilitación de detección del servidor DHCP

En este ejemplo configurará el servidor DHCP de la interfaz ethernet0/1 para que,
antes de iniciarse, compruebe si hay algún servidor DHCP en la interfaz.

WebUI
Server Mode: Auto (seleccione)
CLI
set interface ethernet0/1 dhcp server auto
save
Desactivación de la detección del servidor DHCP

En este ejemplo configurará el servidor DHCP de la interfaz ethernet0/1 para que se
inicie sin comprobar si hay algún servidor DHCP existente en la red.
WebUI
Server Mode: Enable (seleccione)
CLI
set interface ethernet0/1 dhcp server enable
save
NOTA: Al emitir el comando CLI set interface interfaz dhcp server service se activa el
servidor DHCP. Si el modo de detección del servidor DHCP establecido para la
interfaz es Auto, el servidor DHCP del dispositivo de seguridad solamente se inicia
si no encuentra un servidor existente en la red. Con el comando unset interface
interfaz dhcp server service se desactiva el servidor DHCP en el dispositivo de
seguridad y también se elimina cualquier configuración DHCP existente.
Asignar un dispositivo de seguridad como agente de retransmisión de DHCP

Al actuar como agente de retransmisión de DHCP, el dispositivo de seguridad
redirecciona las asignaciones y solicitudes de DHCP entre clientes DHCP
directamente conectados a una interfaz y uno o más servidores DHCP accesibles a
través de otra interfaz. Los clientes y servidores pueden estar en la misma zona de
seguridad o en zonas de seguridad separadas.
Puede configurar un agente de retransmisión de DHCP en una o más interfaces

físicas o VLAN de un dispositivo de seguridad, pero no puede configurar un agente
de retransmisión de DHCP y funciones de servidor o cliente DHCP en la misma
interfaz.
Cuando el dispositivo de seguridad funciona como agente de retransmisión de

DHCP, sus interfaces deben estar en cualquier modo de ruta o funcionar como un
dispositivo de capa 3. En las interfaces que se encuentran en modo capa 3 (es decir
que tienen direcciones IP asignadas a las interfaces), se debe configurar una
directiva de seguridad (intrazonal o interzonal) para permitir la retransmisión de
DHCP de servicio predefinido antes de que se realice la redirección.

Se pueden configurar hasta tres servidores DHCP para cada agente de

retransmisión de DHCP. El agente de retransmisión envía una petición de dirección
procedente de un cliente DHCP a todos los servidores DHCP configurados. El
agente de retransmisión redirecciona al cliente todos los paquetes DHCP recibidos
de todos los servidores. Consulte la “Redireccionamiento de todos los paquetes
DHCP” en la página 239.
NOTA: Cuando un dispositivo de seguridad actúa como agente de retransmisión de

DHCP, éste no genera informes sobre el estado de asignación de DHCP debido a
que el servidor DHCP remoto controla todas las asignaciones de direcciones IP.
ScreenOS admite la retransmisión DHCP en diferentes vsys y de subinterfaces con

etiqueta VLAN.
La Figura 72 describe el proceso de utilización de un dispositivo de seguridad como

agente de retransmisión de DHCP. Para garantizar la seguridad, los mensajes DHCP
pasan por un túnel VPN al atravesar la red untrusted.
Figura 72: Tráfico de agente de retransmisión de DHCP
Zona Trust Agente de Túnel VPN en la

zona Untrust
Host Servidor
DHCP
Petición Petición
Host Servidor
DHCP
Asignación Asignación
Host Servidor
DHCP
Petición Petición

En la Figura 73, un dispositivo de seguridad recibe su información DHCP de un

servidor DHCP en 194.2.9.10 y la retransmite a los hosts en la zona Trust. Los hosts
reciben direcciones IP de un conjunto de direcciones IP definido en el servidor
DHCP. El rango de direcciones es 180.10.10.2—180.10.10.254. Los mensajes DHCP
pasan a través de un túnel VPN entre el dispositivo de seguridad local y el servidor
DHCP, ubicado detrás de un dispositivo de seguridad remoto cuya dirección IP en la
interfaz de la zona Untrust es 2.2.2.2/24. La interfaz ethernet0/1 está unida a la
zona Trust, tiene la dirección IP 180.10.10.1/24 y está en modo de rutas. La interfaz
ethernet0/3 está asociada a la zona Untrust y tiene la dirección IP 1.1.1.1/24. Todas
las zonas de seguridad se encuentran en el dominio de enrutamiento trust-vr.
Figura 73: Dispositivo como agente de retransmisión de DHCP

Zona Trust Zona Untrust Servidor
ethernet0/1 ethernet0/3 DHCP
180.10.10.1/24 1.1.1.1/24 194.2.9.10
Dispositivo de
seguridad local
Agente de retransmisión
de DHCP
WebUI
1. Interfaces
en Apply:
Zone: Trust
en OK:
Zone: Untrust
2. Dirección
Address Name: DHCP Server

Zone: Untrust

3. VPN
y haga clic en OK:
Gateway Name: dhcp server

Security Level: Custom
Static IP: (seleccione), Address/Hostname: 2.2.2.2
Security Level:
User Defined: Custom (seleccione)
Phase1 Proposal: rsa-g2-3des-sha
Mode (Initiator): Main (Protección de la identificación)
VPNs > AutoKey IKE > New: Introduzca los siguientes datos y haga clic en OK:
VPN Name: to_dhcp

Security Level: Compatible
Remote Gateway:
Predefined: (seleccione), to_dhcp
Bind to: Ninguna

4. Agente de retransmisión de DHCP
Network > DHCP > Edit (para ethernet0/1) > DHCP Relay Agent: Introduzca
Relay Agent Server IP or Domain Name: 194.2.9.10

Use Trust Zone Interface as Source IP for VPN: (seleccione)
5. Ruta

NOTA: Establecer una ruta al enrutador externo designado como puerta de enlace
predeterminada es esencial tanto para el tráfico VPN saliente como para el de red.
En este ejemplo, el dispositivo de seguridad envía tráfico VPN encapsulado a este
enrutador como primer salto a lo largo de su ruta al dispositivo de seguridad
remoto. En la Figura 73, el concepto se presenta por medio de una descripción del
túnel que pasa a través del enrutador.

6. Directivas
Source Address:
Address Book Entry: (seleccione), DHCP Server
Service: DHCP-Relay
Action: Zona
Tunnel VPN: to_dhcp
Modify matching outgoing VPN policy: (seleccione)
CLI
1. Interfaces
2. Dirección
set address untrust dhcp_server 194.2.9.10/32
3. VPN
set ike gateway “dhcp server” ip 2.2.2.2 main outgoing-interface ethernet0/3
proposal rsa-g2-3des-sha
set vpn to_dhcp gateway “dhcp server” proposal g2-esp-3des-sha
4. Agente de retransmisión de DHCP
set interface ethernet0/1 dhcp relay server-name 194.2.9.10
set interface ethernet0/1 dhcp relay vpn
5. Ruta
6. Directivas
set policy from trust to untrust any dhcp_server dhcp-relay tunnel vpn to_dhcp
set policy from untrust to trust dhcp_server any dhcp-relay tunnel vpn to_dhcp
save
Redireccionamiento de todos los paquetes DHCP

ScreenOS permite que su dispositivo de seguridad retransmita todas las respuestas
de DHCP de múltiples servidores a un cliente. Algunos entornos requieren que
múltiples servidores respondan con datos idénticos y sus clientes solamente
procesan la primera respuesta recibida; otros entornos tienen múltiples servidores
que responden con datos únicos y los clientes procesan los datos apropiados de
cada uno, por ejemplo en el escenario del entorno de ejecución previo al inicio
(PXE).
En casos comunes de PXE (como se muestra en la Figura 74), por lo menos dos
servidores DHCP sirven a los clientes. Cuando los servidores DHCP reciben una
solicitud del cliente DHCP, uno de los servidores, DHCP Server1, proporciona
información de la dirección DHCP al cliente mientras el DHCP Server 2 (como MS
RIS) proporciona la información de PXE. Esta versión de ScreenOS permite que el
dispositivo de seguridad redireccione todos los paquetes de DHCP al cliente.

Figura 74: Retransmisión de todos los paquetes DHCP desde múltiples servidores DHCP
ethernet0/1.5: ethernet0/2: Servidor DHCP 1

10.0.0.1 30.0.0.1 30.0.0.2
2 Conjunto de IP
Zona Trust Agente de 10.0.0.10-10.0.0.20
retransmisión de DHCP 4
31
Cliente Zona Untrust
DHCP 6 5
7 3
Agente de retransmisión
Servidor DHCP 2
ethernet0/3: 40.0.0.1 40.0.0.2
Conjunto de IP
1. El cliente DHCP envía un mensaje de solicitud de DHCP. 10.0.0.50-10.0.0.60
2. y 3. El dispositivo de seguridad retransmite el mensaje a todos los Servidor PXE: (MS RIS)
servidores DHCP.
4. y 5. Los servidores DHCP envían una respuesta de DHCP a la solicitud.
6. y 7. El dispositivo de seguridad retransmite las respuestas al cliente DHCP.
Normalmente, un servidor PXE proporciona un servidor de imagen de inicio para

clientes PXE sin discos, es decir, PC sin discos. Cuando un cliente de PXE se
conecta, envía una difusión DHCP-DISCOVER (un tipo de solicitud), lo que significa
que el cliente pide la IP y ruta de la imagen de inicio. En la mayoría de los casos,
dos tipos de servidores sirven al PXE: un servidor PXE (como un servidor RIS de
Microsoft) y un servidor DHCP. Ambos servidores reciben la solicitud DISCOVER. El
servidor PXE responde a la solicitud DISCOVER con información del servidor de
imagen de inicio. Al mismo tiempo, el servidor DHCP responde a la solicitud
DISCOVER con una información de asignación de IP. Ambas respuestas de los dos
servidores se redireccionan al cliente DHCP (PC sin discos).
Configuración de la IP del siguiente servidor

Si un dispositivo de seguridad recibe información conflictiva o confusa del servidor
DHCP, el dispositivo utiliza la dirección IP presente en el campo de IP de siguiente
servidor (Next-Server-IP). Este parámetro de configuración de DHCP se ha utilizado
tradicionalmente como la dirección del servidor TFTP en el proceso de
inicialización.
Por ejemplo, en escenarios de PXE, el primer servidor DHCP sirve a la dirección IP

y el segundo servidor DHCP proporciona información de OS. El campo
Next-Server-IP se configura con el propósito de especificar el siguiente servidor en
la cadena. La cadena y cada miembro pueden variar de sitio a sitio. Sin embargo,
normalmente, es un servidor DHCP encadenándose a un servidor TFTP. La cadena
se termina ya suministrando todo ceros (0.0.0.0) o especificando la IP de la interfaz
del dispositivo en este campo como se muestra en la Tabla 37.
La información de IP del siguiente servidor se devuelve al campo siaddr del

encabezado DHCP y a menudo se utiliza para encadenar varios servidores de
inicialización, donde cada uno sirve para una función específica. El campo siaddr es
obligatorio, si está disponible, debido a que algunos servidores DHCP colocarán su
propia dirección de IP en este campo cuando no esté configurado.

Tabla 37: Especificar IP del siguiente servidor
IP del siguiente
servidor Descripción
Ninguna siaddr = 0.0.0.0 (predeterminada)
(predeterminada)
Interface siaddr = la interfaz IP unida al servidor DHCP
Option66 siaddr = option66
(identifica al servidor TFTP para admitir PC sin discos)
Entrada siaddr = dirección IP personalizada
Si la IP del siguiente servidor no es cero y no es igual a la dirección de este servidor,

entonces, el cliente la interpreta como la dirección del siguiente servidor en una
cadena que suministra información adicional de inicio. En el siguiente ejemplo, la
IP del siguiente servidor se configura para Option66.
WebUI
Network > DHCP > Edit (Servidor DHCP): Seleccione uno de los siguientes
Next Server IP: From Option66
CLI
set interface ethernet0/1 dhcp server enable
set interface ethernet0/1 dhcp server option custom 66 ip 10.10.10.1
set interface ethernet0/1 dhcp server config next-server-ip option66
save
Utilización de un dispositivo de seguridad como cliente DHCP

Al actuar como cliente DHCP, el dispositivo de seguridad recibe una dirección IP
dinámicamente de un servidor DHCP para cualquier interfaz física en cualquier
zona de seguridad. Si hay varias interfaces unidas a una sola zona de seguridad,
puede configurar un cliente DHCP para cada interfaz, siempre que ninguna de ellas
esté conectada al mismo segmento de red. Si configura un cliente DHCP para dos
interfaces conectadas al mismo segmento de red, se utilizará la primera dirección
asignada por un servidor DHCP. (Si el cliente DHCP recibe una actualización de
dirección para la misma dirección IP, IKE no se reencripta).
NOTA: Aunque algunos dispositivos de seguridad pueden actuar como servidores de

DHCP, agentes de retransmisión de DHCP o clientes DHCP al mismo tiempo, no
se puede configurar más de una función DHCP en una misma interfaz.
En este ejemplo, la interfaz asociada a la zona Untrust tiene una dirección IP

asignada dinámicamente. Cuando el dispositivo de seguridad pide una dirección IP
a su ISP, éste recibe su dirección IP, la máscara de subred, la dirección IP de la
puerta de enlace y el período de arrendamiento de la dirección. La dirección IP del
servidor DHCP es 2.2.2.5.

Figura 75: Dispositivo como cliente DHCP

Zona Trust
LAN interna
1. Dirección IP solicitada para

ethernet0/3 (zona Untrust)
2. Dirección IP asignada
ISP
(servidor DHCP)
2.2.2.5
Internet
Zona Untrust
NOTA: Antes de establecer un sitio para servicio DHCP, debe contar con una línea de
abonado digital (DSL) y una cuenta con un proveedor de servicios de Internet
(ISP).
WebUI
Network > Interfaces > Edit (para ethernet0/3): Seleccione Obtain IP using
DHCP y haga clic en OK.
NOTA: La dirección IP del servidor DHCP no se puede especificar mediante WebUI; no

obstante, sí se puede especificar mediante comandos CLI.
CLI
set interface ethernet0/3 dhcp client
set interface ethernet0/3 dhcp settings server 2.2.2.5
save
Propagación de ajustes TCP/IP

Algunos dispositivos de seguridad pueden actuar como cliente del protocolo de
control dinámico de hosts (DHCP), recibiendo sus ajustes TCP/IP y dirección IP para
cualquier interfaz física en cualquier zona de seguridad de un servidor DHCP
externo. Algunos dispositivos de seguridad pueden actuar como servidores DHCP,
proporcionando ajustes TCP/IP y direcciones IP a los clientes en cualquier zona.
Cuando un dispositivo de seguridad actúa simultáneamente como cliente DHCP y
como servidor DHCP, puede transferir los ajustes TCP/IP, obtenidos a través de su
módulo de cliente DHCP, a su módulo de servidor DHCP predeterminado.

Los ajustes TCP/IP incluyen la dirección IP de la puerta de enlace predeterminada y

una máscara de subred, así como las direcciones IP para cualquiera o todos los
servidores siguientes:
DNS (3)
WINS (2)
NetInfo (2)
SMTP (1)
POP3 (1)
News (1)
En la Figura 76, el dispositivo de seguridad es a la vez un cliente del servidor DHCP

en la zona Untrust y un servidor DHCP para los clientes de la zona Trust. El
dispositivo toma los ajustes TCP/IP que recibe como cliente DHCP y los redirecciona
como servidor DHCP a los clientes de la zona Trust. La interfaz en la zona Untrust
es el cliente DHCP y recibe direcciones IP dinámicamente de un ISP.
Figura 76: Propagación de DHCP
Zona Untrust
ISP
Servidor DHCP
Ajustes TCP/IP y dirección IP
de la interfaz de la zona Untrust
Interfaz de la zona Untrust: Cliente DHCP
Interfaz de la zona Trust: Servidor

DHCP 10.1.1.1/0
Ajustes TCP/IP
Rango de DHCP:
10.1.1.50 - 10.1.1.200
Clientes de DHCP
Zona Trust
Para propagar todos los ajustes TCP/IP que reciba del módulo de cliente DHCP,
puede configurar el módulo del servidor DHCP ejecutando el comando set
interface interfaz dhcp-client settings update-dhcpserver. También puede dar
preferencia a cualquier ajuste sobre otro.
En este ejemplo, configurará el dispositivo de seguridad para actuar a la vez como

cliente DHCP en la interfaz ethernet0/3 y como servidor DHCP en la interfaz
ethernet0/1. (El servidor DHCP predeterminado se encuentra en la interfaz
ethernet0/1).

Como cliente DHCP, el dispositivo de seguridad recibe una dirección IP para la

interfaz ethernet0/3 y sus ajustes TCP/IP de un servidor DHCP externo con la
dirección 211.3.1.6. Habilitará el módulo de cliente DHCP en el dispositivo de
seguridad para transferir los ajustes TCP/IP que recibe al módulo de servidor DHCP.
Configurará el módulo de servidor DHCP para hacer lo siguiente con los ajustes
TCP/IP que reciba del módulo de cliente DHCP:
Reenviar las direcciones IP de DNS a sus clientes DHCP en la zona Trust.
Sobrescribir la puerta de enlace predeterminada, la máscara de red y las

direcciones IP de los servidores SMTP y POP3, con las siguientes:
10.1.1.1 (dirección IP de la interfaz ethernet0/1)
255.255.255.0 (máscara de red para la interfaz ethernet0/1)
SMTP: 211.1.8.150
POP3: 211.1.8.172
NOTA: Si el servidor DHCP ya está habilitado en la interfaz de la zona Trust y dispone de

un conjunto definido de direcciones IP (lo cual es el comportamiento
predeterminado para determinadas plataformas), debe eliminar primero el
conjunto de direcciones IP antes de poder cambiar la puerta de enlace
predeterminada y la máscara de red.
También configurará el módulo de servidor DHCP para que proporcione los

siguientes ajustes TCP/IP que no recibe del módulo de cliente DHCP:
Servidor WINS principal: 10.1.2.42
Servidor WINS secundario: 10.1.5.90
Finalmente, configurará el módulo de servidor DHCP de modo que asigne

direcciones IP del siguiente conjunto de direcciones IP a los hosts que actúen como
clientes DHCP en la zona Trust: 10.1.1.50 – 10.1.1.200.
WebUI
NOTA: Puede establecer esta función solamente mediante la CLI.
CLI
1. Cliente DHCP
set interface ethernet0/3 dhcp-client settings server 211.3.1.6
set interface ethernet0/3 dhcp-client settings update-dhcpserver
set interface ethernet0/3 dhcp-client settings autoconfig
set interface ethernet0/3 dhcp-client enable

2. Servidor DHCP
set interface ethernet0/1 dhcp server option gateway 10.1.1.1
set interface ethernet0/1 dhcp server option netmask 255.255.255.0
set interface ethernet0/1 dhcp server option wins1 10.1.2.42
set interface ethernet0/1 dhcp server option wins2 10.1.5.90
set interface ethernet0/1 dhcp server option pop3 211.1.8.172
set interface ethernet0/1 dhcp server option smtp 211.1.8.150
save
Configuración de DHCP en sistemas virtuales

DHCP: ScreenOS ahora admite completamente la retransmisión de DHCP para
Vsys. Puede configurar la retransmisión DHCP para un Vsys específico y
retransmitir todos los paquetes de múltiples servidores DHCP a un cliente.
Establecimiento de la retransmisión de un mensaje DHCP en sistemas virtuales

ScreenOS le permite configurar una retransmisión de mensajes de un protocolo de
configuración dinámica de host (DHCP) desde uno o múltiples servidores DHCP a
clientes dentro de un sistema virtual (vsys). Puede configurar la retransmisión de
mensajes de DHCP en una interfaz que esté disponible en un sistema virtual.
Si cuenta con dos servidores DHCP, servidor 1 y servidor 2, un dispositivo de

seguridad que se encuentra entre los servidores DHCP y un cliente, transmite
solicitudes DHCP individualmente a cada servidor DHCP a través de diferentes
interfaces de salida. A medida que se recibe cada respuesta de DHCP, el dispositivo
de seguridad las transmite al vsys raíz y después las redirecciona al cliente DHCP
correspondiente dentro de un vsys.
Figura 77: Servicios de retransmisión de DHCP dentro de un Vsys

Servidor DHCP 1
Dispositivo de seguridad que

proporciona la retransmisión de DHCP
Servidor DHCP 2
Cliente DHCP
Para configurar DHCP con vsys:
1. Crear un sistema virtual.
2. Habilite DHCP para dicho vsys.
Establecimiento de la retransmisión de un mensaje DHCP en sistemas virtuales 245

3. Configure una ruta estática para permitir que el servidor DHCP en el sistema
raíz obtenga acceso al vsys.
4. Establezca directivas de seguridad en el sistema virtual.
Protocolo punto a punto sobre Ethernet

El protocolo PPP a través de Ethernet (“PPP-over-Ethernet” o “PPPoE”) combina el
protocolo punto a punto (“Point-to-Point Protocol” o “PPP”), utilizado generalmente
para conexiones de acceso telefónico, con el protocolo Ethernet, que permite
conectar varios usuarios de un sitio a los mismos equipos de las instalaciones del
cliente. Muchos usuarios pueden compartir la misma conexión física, pero el
control de acceso, la facturación y el tipo de servicio se manejan
independientemente para cada usuario. Algunos dispositivos de seguridad admiten
un cliente PPPoE, permitiéndoles funcionar de modo compatible con DSL, Ethernet
Direct y redes de cable administradas por ISP, que utilizan el PPPoE para el acceso a
Internet de sus clientes.
En dispositivos que admiten PPPoE se puede configurar una instancia de cliente

PPPoE en cualquier interfaz o en todas ellas. Configurará una instancia PPPoE
específica con un nombre de usuario, una contraseña y otros parámetros y luego
unirá la instancia a una interfaz. Cuando hay dos interfaces de Ethernet (una
principal y una de respaldo) unidas a la zona Untrust, puede configurar una de ellas
o ambas para PPPoE.
Configuración de PPPoE
El ejemplo siguiente describe la manera de definir la interfaz no fiable de un
dispositivo de seguridad para conexiones PPPoE y la manera de iniciar el servicio
PPPoE.
En este ejemplo, el dispositivo de seguridad recibe una dirección IP asignada

dinámicamente para su interfaz de la zona Untrust (ethernet0/3) desde el ISP y el
dispositivo de seguridad también asigna direcciones IP dinámicamente a los tres
hosts de su zona Trust. En este caso, el dispositivo de seguridad actúa como cliente
PPPoE y como servidor DHCP. La interfaz de la zona Trust debe estar en modo NAT
o de rutas. En este ejemplo se encuentra en modo NAT.
Figura 78: Servidor
Untrust (ethernet0/3): modo DHCP Interfaz de Trust: 172.16.30.10/24
Módem DSL
ISP
DSLAM
Concent CA
rador Internet
Línea DSL
Principal
Servidor DNS
Rango de DHCP: Servidor DNS

172.16.30.2 - 172.16.30.5 Zona Trust Zona Untrust
secundario
246 Protocolo punto a punto sobre Ethernet

Antes de configurar el sitio de este ejemplo para el servicio PPPoE, debe disponer
de los siguientes medios:
Línea de abonado digital (DSL) y el módem correspondiente
Cuenta con un ISP
Nombre de usuario y contraseña (obtenida del ISP)
WebUI
1. Interfaces y PPPoE
Zone: Trust
Zone: Untrust
Obtain IP using PPPoE: (seleccione)
User Name/Password: nombre/contraseña
Network > Interfaces > Edit (para ethernet0/3): Para verificar su conexión
PPPoE, haga clic en Connect.
NOTA: Cuando se inicia una conexión PPPoE, su ISP proporciona automáticamente las
direcciones IP para la interfaz de la zona Untrust y para los servidores del sistema
de nombres de dominio (DNS). Cuando el dispositivo de seguridad recibe
direcciones DNS a través de PPPoE, los nuevos ajustes de DNS sobrescriben de
forma predeterminada los ajustes locales. Si no desea que los nuevos ajustes de
DNS reemplacen los ajustes locales, puede utilizar el comando CLI unset pppoe
dhcp-updateserver para desactivar este comportamiento.
Si utiliza una dirección IP estática para la interfaz de la zona Untrust, debe obtener
las direcciones IP de los servidores DNS e introducirlas manualmente en el
dispositivo de seguridad y en los hosts de la zona Trust.
Protocolo punto a punto sobre Ethernet 247

2. Servidor DHCP
Network > Interfaces > Edit (para ethernet0/1) > DHCP: Seleccione DHCP
Server y haga clic en Apply.
Network > Interfaces > Edit (para ethernet0/1) > DHCP: Introduzca los
Lease: 1 hour
Gateway: 0.0.0.0
Netmask: 0.0.0.0
DNS#1: 0.0.0.0
> Advanced: Introduzca los siguientes datos, luego haga clic en Return:
DNS#2: 0.0.0.0
Domain Name: (dejar en blanco)
Network > Interfaces > DHCP (para ethernet0/1) > New Address: Introduzca
3. Activación de PPPoE en el dispositivo de seguridad
1. Apague el módem DSL, el dispositivo de seguridad y las tres estaciones de
trabajo.
2. Encienda el módem DSL.
3. Encienda el dispositivo de seguridad.
El dispositivo de seguridad establecerá una conexión PPPoE con el ISP y

obtendrá de éste las direcciones IP para los servidores DNS.
4. Activación de DHCP en la red interna

Encienda las estaciones de trabajo.
Las estaciones de trabajo recibirán automáticamente las direcciones IP para los

servidores DNS. Obtendrán una dirección IP cuando intenten establecer una
conexión TCP/IP.
NOTA: Cuando utiliza DHCP para asignar direcciones IP a los hosts de la zona Trust, el
dispositivo de seguridad redirecciona automáticamente las direcciones IP de los
servidores DNS que recibe del ISP a los hosts.
Si las direcciones IP para los hosts no se asignan dinámicamente mediante DHCP,

deberá introducir manualmente las direcciones IP de los servidores DNS en cada
host.
Cada conexión TCP/IP que establece un host de la zona Trust hacia la zona
Untrust pasa automáticamente por el proceso de encapsulado PPPoE.

CLI
1. Interfaces y PPPoE
set pppoe interface ethernet0/3
set pppoe username cadena_nombre password cadena_contraseña
Para comprobar su conexión PPPoE:
exec pppoe connect

get pppoe
2. Servidor DHCP
save
3. Activación de PPPoE en el dispositivo de seguridad
1. Apague el módem DSL, el dispositivo de seguridad y las tres estaciones de
trabajo.
2. Encienda el módem DSL.
3. Encienda el dispositivo de seguridad.
4. Activación de DHCP en la red interna

Encienda las estaciones de trabajo.
Las estaciones de trabajo recibirán automáticamente las direcciones IP para los

servidores DNS. Obtendrán una dirección IP para sí mismas cuando intenten
establecer una conexión TCP/IP.
Cada conexión TCP/IP que establece un host de la zona Trust hacia la zona
Untrust pasa automáticamente por el proceso de encapsulado PPPoE.
Configuración de PPPoE en las interfaces principal y de respaldo de la zona Untrust

En el ejemplo siguiente configurará PPPoE para las interfaces principal
(ethernet0/3) y de respaldo (ethernet0/2) hacia la zona Untrust.
WebUI
1. Configuración de PPPoE para la interfaz ethernet0/2
Network > PPP > PPPoE Profile> New: Introduzca los siguientes datos y haga
clic en OK:
PPPoE instance: eth3-pppoe

Bound to interface: ethernet0/3 (seleccione)
Username: user1
Password: 123456
Authentication: Any (seleccione)
Access Concentrator: ac-11


Network > PPP > PPPoE Profile> New: Introduzca los siguientes datos y haga
clic en OK:
PPPoE instance: eth2-pppoe

Bound to interface: ethernet0/2 (seleccione)
Username: user2
Password: 654321
Authentication: Any (seleccione)
Access Concentrator: ac-22
CLI
set pppoe name eth3-pppoe username user1 password 123456
set pppoe name eth3-pppoe ac ac-11
set pppoe name eth3-pppoe authentication any
set pppoe name eth3-pppoe interface ethernet0/3
set pppoe name eth2-pppoe username user2 password 654321
set pppoe name eth2-pppoe ac ac-22
set pppoe name eth2-pppoe authentication any
set pppoe name eth2-pppoe interface ethernet0/2
save
Configuración de múltiples sesiones PPPoE a través de una sola interfaz

Algunos dispositivos de seguridad admiten la creación de múltiples subinterfaces
PPPoE (cada una con la misma dirección MAC) de una interfaz física dada. Esto
permite establecer una conexión de red privada con un ISP y conectarse a Internet
a través de un ISP diferente, utilizando la misma interfaz física. Puede establecer
estas conexiones utilizando un nombre de usuario o nombres de dominio
diferentes o conectarse simultáneamente a diferentes ISP.
El número máximo de sesiones PPPoE simultáneas en una interfaz física está

limitado solamente por el número de subinterfaces que permite el dispositivo. No
hay restricción en cuanto al número de interfaces físicas que pueden admitir
múltiples sesiones. Puede especificar los parámetros username, static-ip,
idle-timeout, auto-connect y otros por separado para cada instancia o sesión PPPoE.
Para admitir una sesión PPPoE, la subinterfaz no debe estar etiquetada. Una
interfaz sin etiqueta utiliza encap (no una etiqueta de VLAN) para identificar una
VLAN correspondiente a una subinterfaz. Encap enlaza la subinterfaz al
encapsulado PPPoE. Al hospedar múltiples subinterfaces, una sola interfaz física
puede hospedar múltiples instancias PPPoE. Puede configurar cada instancia de
modo que acceda al concentrador de accesos (AC) especificado, permitiendo que
entidades independientes tales como ISP administren sesiones PPPoE a través de
una sola interfaz. Para obtener más información sobre VLAN y etiquetas VLAN,
consulte el Volumen 10: Sistemas virtuales.

Figura 79: PPPoE con múltiples sesiones

Múltiples subinterfaces Interfaz física única (p. ej. ethernet7)
isp_1 e7 isp_1ac
Tres instancias PPPoE isp_2 e7.1 isp_2ac
Tres sesiones PPPoE
isp_3 e7.2 isp_3ac
Zona Trust Zona Untrust isp_1ac
isp_2ac
isp_3ac
ethernet7 Concentradores de accesos
En el ejemplo siguiente definirá tres instancias PPPoE, especificará un concentrador

de acceso (AC) para cada una y luego iniciará cada instancia.
Instancia isp_1, username usuario1@domain1, password espada, unida a la

interfaz ethernet7. El AC es isp_1ac.
Instancia isp_2, username usuario2@domain2, password emperador, unida a

la subinterfaz ethernet7.1. El AC es isp_2ac.
Instancia isp_3, username usuario3@dominio3, password trucha, unida a la

subinterfaz ethernet7.2. El AC es isp_3ac.
WebUI
1. Interfaz y subinterfaces
Network > Interfaces > Edit (para ethernet7):
Zone Name: Untrust
Network > Interfaces > New (Sub-IF):
Interface Name: ethernet7.1

Zone Name: Untrust
Network > Interfaces > New (Sub-IF):
Interface Name: ethernet7.2

Zone Name: Untrust

2. Instancias PPPoE y CA
Network > PPP > PPPoE Profile> New:
PPPoE Instance: isp_1

Enable: Enable
Bound to Interface: ethernet7
Username: usuario1@dominio1
Access Concentrator: isp_1ac

Enable: Enable
Bound to Interface: ethernet7.1

Enable: Enable
Bound to Interface: ethernet7.2
3. Iniciación del protocolo PPPoE
Network > PPP > PPPoE Profile > Connect (para isp_1)
CLI
1. Interfaz y subinterfaces
set interface ethernet7 zone untrust
set interface ethernet7.1 encap pppoe zone untrust
set interface ethernet7.2 encap pppoe zone untrust
2. Instancias PPPoE y CAs
set pppoe name isp_1 username usuario1@dominio1 password espada
set pppoe name isp_1 interface ethernet7
set pppoe name isp_1 ac isp_1ac
set pppoe name isp_2 username usuario2@dominio2 password emperador
set pppoe name isp_2 interface ethernet7.1
set pppoe name isp_3 username usuario3@dominio3 password trucha
set pppoe name isp_3 interface ethernet7.2
save

3. Iniciación del protocolo PPPoE

exec pppoe name isp_1 connect
PPPoE y alta disponibilidad

Dos dispositivos de seguridad que admiten PPPoE en modo activo/pasivo pueden
asumir el cambio en caso de error de una conexión PPPoE. En el momento de
iniciar la conexión, el dispositivo principal sincroniza su estado PPPoE con el
dispositivo de respaldo. Debido a que el dispositivo pasivo utiliza la misma
dirección IP que el dispositivo principal, no tiene que establecer una nueva
conexión PPPoE al convertirse en el principal. Por lo tanto, puede mantener la
comunicación con el concentrador de acceso después del fallo del principal. Esto es
necesario cuando la interfaz PPPoE trabaja con conexiones de VPN que deben
mantenerse con la misma IP de interfaz después del fallo. Para obtener más
información sobre configuraciones de HA, consulte el Volumen 11:
Alta disponibilidad.
Claves de licencia
La función de la clave de licencia permite ampliar las capacidades de su dispositivo
de seguridad de Juniper Networks sin tener que actualizarse a otro dispositivo o
imagen del sistema. Puede adquirir los siguientes tipos de claves:
Avanzada
Capacidad
Extendida
Virtualización
GTP
Vsys
IDP
Cada dispositivo de seguridad se suministra con un conjunto estándar de funciones

habilitadas y puede admitir la activación de funciones opcionales o aumentar la
capacidad de las existentes. Para obtener más información sobre qué características
pueden actualizarse en este momento, consulte la documentación comercial más
reciente de Juniper Networks.
El procedimiento para obtener y aplicar una clave de licencia es el siguiente:
1. Anote su código de autorización y número de serie del dispositivo.
Código de autorización: Una clave de acceso necesaria para generar y activar

la clave de licencia que usted o su empresa adquirieron para su dispositivo de
seguridad de Juniper Networks. Nota: El código de autorización se requiere para
generar su clave de licencia, no es la clave de licencia en sí.
Claves de licencia 253

Número de serie del dispositivo: Un código exclusivo de 16 caracteres que

Juniper Networks utiliza para identificar su dispositivo de seguridad en
particular al generar claves de licencia. Encontrará el número de serie del
dispositivo en la parte inferior o en la parte trasera del dispositivo. También
puede encontrar el número de serie en la sección de información del
dispositivo en GUI o al ejecutar un comando “get system” en la CLI.
2. Conéctese al sistema de administración de licencias de Juniper Networks (LMS)

en http://www.juniper.net/generate_license, seleccione el vínculo Firewall/IPSec
VPN and Intrusion Prevention, a continuación siga las instrucciones que
aparecen en la interfaz de usuario del sistema.
3. El sistema de administración de licencias de Juniper proporciona la clave de

licencia de dos maneras:
Se descarga la clave de licencia a su equipo.
Se recibe un correo electrónico que incluye su clave de licencia.
4. Instale la clave de licencia de una de las siguientes maneras:
WebUI
Configuration > Update > ScreenOS/Keys > SelectLicense Key Update
(funciones) > haga clic en Browse > seleccione el archivo que contiene la
clave de licencia, a continuación haga clic en Apply.
CLI
exec license-key núm_clave
Registro y activación de los servicios de suscripción

Antes de que su dispositivo de seguridad de Juniper Networks pueda recibir un
servicio de suscripción periódica de patrones de antivirus (AV), firmas de inspección
minuciosa (DI), antispam o filtrado de web, debe realizar lo siguiente:
Comprar una suscripción
Registrar la suscripción
Descargar la clave de suscripción
La descarga de la clave de la licencia de suscripción activa sus servicios en el

dispositivo durante el período de tiempo adquirido. Su proceso de activación del
servicio específico depende de los servicios que adquirió y el método utilizado al
adquirirlos.
254 Registro y activación de los servicios de suscripción

Servicio de prueba
Para permitir el uso de los servicios de AV, DI, antispam o filtrado de Web, el
dispositivo de seguridad proporciona un período de prueba. Durante este tiempo, el
dispositivo puede obtener servicios temporalmente. Para descargar las claves de
licencia de prueba correspondientes desde el servidor de autorización, utilice el
comando CLI para pruebas de actualización exec license-key.
Ningún dispositivo de seguridad de Juniper Networks se suministra con DI

habilitado. Para obtener el servicio DI de prueba, debe iniciar una sesión de
WebUI y hacer clic en Retrieve Subscriptions Now en Configuration > Update
> ScreenOS/Keys. Esta acción proporciona una clave DI única, válida para un
solo día.
Si su dispositivo cuenta con el servicio AV incluido en el momento de la

compra, entonces el dispositivo tendrá preinstalado un servicio de prueba. Este
servicio de prueba dura hasta 60 días.
Antispam.
Ningún dispositivo de seguridad de Juniper Networks se suministra con filtrado

de Web habilitado. Esta función no tiene un servicio de prueba.
PRECAUCIÓN: Para evitar la interrupción del servicio, debe registrar su dispositivo

de seguridad de Juniper Networks lo antes posible después de adquirir su
suscripción. El registro asegura la continuidad de la suscripción.
Actualización de las claves de suscripción

Si hay cualquier software con fecha de vencimiento instalado en el dispositivo de
seguridad, el dispositivo se conecta periódicamente al servidor de autorización para
descargar las claves de suscripción. El dispositivo se conecta al servidor de
autorización, sistema de administración de licencias, en los casos siguientes:
La clave vence en dos meses
La clave vence en un mes
La clave vence en dos semanas
La clave vence
30 días después del vencimiento de la clave
NOTA: Para eliminar una sola clave de licencia del archivo de claves, ejecute el comando
CLI exec license-key delete cadena_nombre.
Registro y activación de los servicios de suscripción 255

Adición de antivirus, filtrado de Web, antispam e inspección minuciosa a un nuevo

dispositivo o a uno existente
Después de adquirir suscripciones para AV, filtrado de Web, antispam o inspección
minuciosa (DI) para agregarlas a su dispositivo de seguridad de Juniper Networks
existente, realice los siguientes pasos para activar los servicios:
1. Después de solicitar la suscripción, deberá recibir un código de autorización,

por correo electrónico, desde Juniper Networks o su VAR autorizado. Este
código es un documento legible que contiene la información que necesitará
para registrar su suscripción.
2. Cerciórese de que el dispositivo esté registrado. Si aún no está registrado, vaya

al sitio siguiente:
http://tools.juniper.net/subreg
3. Registre el código de autorización de suscripción del dispositivo.
4. Confirme que su dispositivo puede conectarse a Internet.
5. Descargue la clave de suscripción en el dispositivo. Puede hacerlo de dos

maneras:
En WebUI, haga clic en Retrieve Subscriptions Now desde Configuration

> Update > ScreenOS/Keys.
Con la interfaz de línea de comandos (CLI), ejecute el comando siguiente:
exec license-key update
6. Debe restablecer el dispositivo después de cargar la clave.
Ahora puede configurar el dispositivo para que realice la descarga de los servicios
de firma de forma automática o manual. Para obtener instrucciones sobre la
configuración de estos servicios en su dispositivo de seguridad, consulte las
“Reensamblaje de fragmentos” en la página 4-58
“Análisis antivirus” en la página 4-62
“Filtrado de Web” en la página 4-100
Reloj del sistema

Es importante que su dispositivo de seguridad de Juniper Networks esté establecido
siempre en la hora correcta. Entre otras cosas, la hora de su dispositivo afecta a la
configuración de los túneles VPN y a la sincronización de programas. Primero, para
asegurarse que el dispositivo mantenga siempre la hora correcta, debe establecer el
reloj del sistema en la hora actual. A continuación, puede habilitar la opción del
horario de verano (DST) y puede configurar hasta tres servidores NTP (protocolo de
hora de la red) (uno principal y dos de respaldo) que el dispositivo utilizará para
actualizar periódicamente su reloj del sistema.
256 Reloj del sistema

Fecha y hora
Para poner el reloj en hora con la fecha y hora actuales, puede utilizar WebUI o CLI.
A través de WebUI, esta operación se efectúa sincronizando el reloj del sistema con
el reloj de su computadora:
1. Configuration > Date/Time: Haga clic en el botón Sync Clock with Client.
Aparecerá un mensaje preguntándole si tiene habilitada la opción de DST en el

reloj de su computadora.
2. Haga clic en Yes para sincronizar el reloj del sistema y ajustarlo según DST,
o bien, en No para sincronizarlo sin el ajuste de DST.
A través de CLI, puede ajustar el reloj introduciendo manualmente la fecha y la hora

con el siguiente comando:
set clock mm/dd/aaaa hh:mm:ss
Horario de verano
El horario de verano (DST) es un sistema que se utiliza en muchos países para
ajustar la hora local oficial durante los meses de verano a fin de ahorrar energía y
dejar más luz diurna para las actividades laborales y escolares.
El horario de verano se sigue de manera diferente en cada país. Por este motivo, el
sisteme permite seleccionar los ajustes apropiados de DST que se apliquen a su
país.
Puede establecer el ajuste de DST para recurrir a un programa laboral (por ejemplo,
el último domingo de marzo) o en una fecha específica. También puede establecer
que el ajuste de DST no sea recurrente de un año para otro, sino que se ajuste
solamente para un único año.
Huso horario
El huso horario se establece especificando el número de horas de adelanto o de
retraso de la hora local del dispositivo de seguridad con respecto a GMT (hora
media de Greenwich). Por ejemplo, si la zona horaria local del dispositivo es la hora
estándar del Pacífico, tendrá un retraso de 8 horas con respecto a GMT. Por lo tanto,
deberá poner el reloj en -8.
Para establecer el huso horario mediante WebUI:
Configuration > Date/Time > Set Time Zone_hours_minutes from GMT
Para establecer el huso horario mediante CLI:
device -> set clock timezone número (un número entre -12 y 12)
o bien
device -> set ntp timezone número (un número entre -12 y 12)
Reloj del sistema 257

Protocolo de hora de la red

Para asegurarse que el dispositivo de seguridad siempre tenga la hora correcta,
puede utilizar el protocolo de hora de red (NTP) para sincronizar el reloj del sistema
con el de un servidor NTP a través de Internet. Puede hacer esto manualmente o
configurar el dispositivo para que realice esta sincronización automáticamente a
intervalos determinados.
Configuración de múltiples servidores NTP

Puede configurar hasta tres servidores NTP en un dispositivo de seguridad de
Juniper Networks: un servidor principal y dos servidores de respaldo. Cuando
configura el dispositivo de seguridad para sincronizar el reloj del sistema
automáticamente, efectúa una consulta en cada servidor NTP configurado de
manera secuencial. El dispositivo siempre consulta primero al servidor NTP
principal. Si la consulta no obtiene respuesta, el dispositivo consulta seguidamente
al primer servidor NTP de respaldo y así sucesivamente, hasta obtener una
respuesta válida de alguno de los servidores NTP del dispositivo. Antes de finalizar
la actualización y registrar el fallo, el dispositivo realiza cuatro intentos en cada
servidor NTP.
La sincronización manual del reloj del sistema solamente se puede hacer mediante
CLI, pudiendo especificarse un servidor NTP determinado o ninguno. Si especifica
un servidor NTP, el dispositivo de seguridad solamente consultará a ese servidor. Si
no especifica ningún servidor NTP, el dispositivo consultará a cada servidor NTP
configurado en el dispositivo, de manera secuencial. Puede especificar un servidor
NTP utilizando su dirección IP o su nombre de dominio.
Configuración de un servidor NTP de respaldo

Puede especificar una interfaz individual en la dirección de origen para dirigir las
peticiones de NPT desde el dispositivo a través de un túnel VPN al servidor NTP
principal o al servidor de respaldo según sea necesario. Entre otros tipos de
interfaz, puede seleccionar una interfaz de bucle invertido para realizar esta
función.
El dispositivo de seguridad envía solicitudes de NTP desde una interfaz de origen y

opcionalmente utiliza una clave encriptada, compartida previamente al enviar
solicitudes de NTP al servidor de NTP. La clave proporciona autenticación.
En el ejemplo siguiente, puede configurar el servidor NTP principal y dos servidores

NTP de respaldo asignando una dirección IP a cada servidor. A continuación,
establecerá cada servidor para que envíe solicitudes NTP desde la interfaz Trust.
Después de eso, establecerá el identificador de clave y la clave compartida
previamente para cada servidor.

WebUI
Configuration > Date/Time: Introduzca los siguientes datos y haga clic
en Apply:
Primary Server IP/Name: 1.1.1.1

Primary server Key ID: 10
Source interface: Seleccione Trust de la lista.
Preshared Key: !2005abc
Backup Server1 IP/Name: 1.1.1.2
CLI
set ntp server 1.1.1.1
set ntp server backup1 1.1.1.2
set ntp server src-interface trust
set ntp server backup1 src-interface trust
set ntp server backup2 src-interface trust
set ntp server key-id 10 pre-share-key !2005abc
set ntp server backup1 key-id 10 pre-share-key !2005abc
set ntp server backup2 key-id 10 pre-share-key !2005abc
save
Desfase temporal máximo

Para la sincronización automática se puede especificar un valor máximo de desfase
(en segundos). El valor máximo de desfase horario representa la diferencia horaria
admisible entre el reloj del sistema del dispositivo de seguridad y la hora recibida
de un servidor NTP. El dispositivo solamente ajusta su reloj con la hora del servidor
NTP si la diferencia horaria entre su reloj y el servidor NTP se encuentra dentro del
valor máximo de desfase horario establecido. Por ejemplo, si el valor máximo de
desfase horario es de 3 segundos y la hora en el reloj del sistema del dispositivo
marca las 4:00:00 y el servidor NTP envía las 4:00:02 como la hora correcta, la
diferencia entre ambas es aceptable y el dispositivo puede actualizar su reloj. Si el
desfase horario es superior al valor establecido, el dispositivo no sincroniza su reloj
y procede a tratar de consultar al primer servidor NTP de respaldo configurado en el
dispositivo. Si el dispositivo no recibe una respuesta válida después de tratar de
consultar a todos los servidores NTP configurados, éste genera un mensaje de error
en el registro de eventos. El valor predeterminado de esta característica son
3 segundos y el rango de valores permitidos es de 0 (sin límite) a 3600 (una hora).
Al sincronizar manualmente el reloj del sistema, lo cual solamente es posible

mediante la CLI, el dispositivo de seguridad no comprueba el valor máximo de
desfase horario. En lugar de ello, si recibe una respuesta válida, el dispositivo
muestra un mensaje que le indica a qué servidor NTP se ha accedido, cuál es el
desfase horario y el tipo de método de autenticación que se ha utilizado. El mensaje
también pide que se confirme o se cancele la actualización del reloj del sistema.

Si el dispositivo de seguridad no recibe una respuesta, éste genera un mensaje de

tiempo de espera. Este mensaje aparece solamente después de que el dispositivo
ha intentado sin éxito alcanzar a todos los servidores NTP configurados en el
dispositivo.
NOTA: Al emitir consultas mediante la CLI, puede cancelar la solicitud actual presionando
Ctrl-C en el teclado.
Protocolos NTP y NSRP

El protocolo de redundancia de NetScreen (NSRP) contiene un mecanismo de
sincronización del reloj del sistema de los miembros de un clúster NSRP. Aunque la
unidad de resolución de sincronización es el segundo, NTP ofrece una resolución
inferior al segundo. Dado que diferentes miembros de un clúster pueden tener
horas distintas con variaciones de unos pocos segundos debido al retraso
ocasionado por el procesamiento, Juniper Networks recomienda desactivar la
sincronización horaria de NSRP cuando NTP esté habilitado en dos miembros del
clúster, para que ambos puedan actualizar su reloj del sistema desde un servidor
NTP. Para desactivar la función de sincronización de hora de NSRP, ingrese el
comando de CLI set ntp no-ha-sync.

servidor NTP
En el ejemplo siguiente configurará el dispositivo de seguridad para actualizar su
reloj a intervalos de cinco minutos desde los servidores NTP de las direcciones
IP 1.1.1.1, 1.1.1.2 y 1.1.1.3. También establecerá un valor máximo de desfase
horario de 2 segundos.
WebUI
Configuration > Date/Time: Introduzca los siguientes datos y haga clic
en Apply:
Automatically synchronize with an Internet Time Server (NTP): (seleccione)

Update system clock every minutes: 5
Maximum time adjustment seconds: 2
Primary Server IP/Name: 1.1.1.1
CLI
set clock ntp
set ntp server 1.1.1.1
set ntp interval 5
set ntp max-adjustment 2
save

Seguridad de los servidores NTP

Puede asegurar el tráfico NTP aplicando la suma de comprobación basada en MD5
para autenticar los paquetes NTP. No es necesario crear un túnel IPSec. Este tipo de
autenticación asegura la integridad del tráfico NTP. Esto no impide a los
interlocutores externos visualizar los datos, pero evita que cualquier usuario pueda
manipularlos.
Para habilitar la autenticación del tráfico NTP, debe asignar un identificador de clave
y una clave previamente compartida exclusivas a cada servidor NTP que configure
en un dispositivo de seguridad. El identificador de clave y la clave previamente
compartida sirven para generar una suma de comprobación con la que el
dispositivo de seguridad y el servidor NTP pueden autenticar los datos.
Tabla 38describe los dos tipos de autenticación para el tráfico NTP:
Tabla 38: Autentificación del tráfico de NTP
Tipo Descripción
Required Cuando lo selecciona, el dispositivo de seguridad debe incluir la información de
(necesario) autenticación (identificador de clave y suma de comprobación) en cada paquete
que envía a un servidor NTP y debe autenticar todos los paquetes NTP que recibe
de un servidor NTP. Para poder establecer la autenticación entre un dispositivo de
seguridad y un servidor NTP, los administradores del dispositivo de seguridad y del
servidor NTP deben intercambiar primero un identificador de clave y una clave
previamente compartida. Tienen que intercambiarlas manualmente, para lo que
disponen de varios métodos, por ejemplo, correo electrónico o teléfono.
Preferred Cuando lo selecciona, el dispositivo de seguridad primero debe funcionar como si
(preferido) estuviese en el modo Required, intentando autenticar todo el tráfico NTP. Si fallan
todos los intentos de autenticación, el dispositivo de seguridad entonces funciona
como si no se hubiese seleccionado ninguna autenticación. Envía paquetes a un
servidor NTP sin incluir identificador de clave ni suma de comprobación.
Básicamente, aunque existe cierta preferencia por la autenticación, si ésta falla, el
dispositivo de seguridad sigue permitiendo el tráfico NTP.


Índice
A grupos ...........................................................155 a 158
a una zona con NAT basada en interfaces ..................94 PAT ..................................................................143, 144
alarmas, umbrales .......................................................174 puerto fijo ...............................................................145
ALG rangos, modificación ............................................145
MS RPC ...................................................................130 Direcciones
para servicios personalizados ..............................169 definidas .................................................................168
RTSP .......................................................................132 en directivas ...........................................................168
Sun RPC ..................................................................129 entradas en la libreta de direcciones ........104 a 108
ancho de banda ...........................................................175 IP, identificaciones de host y de red .....................46
administrar ............................................................195 privadas ....................................................................46
garantizado ............................................175, 195, 201 públicas.....................................................................45
máximo ..................................................175, 195, 201 Direcciones IP
máximo, ilimitado.................................................196 Administrar ..............................................................95
prioridad identificaciones de host ..........................................46
de banda ...........................................................200 identificaciones de la red .......................................46
niveles ...............................................................200 interfaces, seguimiento a .......................................62
predeterminadas ..............................................200 privadas ....................................................................45
ARP..................................................................................82 públicas.....................................................................45
ARP, dirección IP de entrada ........................................84 puertos, definición para cada uno.......................104
asignación de tráfico ...................................................195 rangos de direcciones privadas .............................46
automática .............................................................196 secundarias ..............................................................49
prioridades del servicio ........................................200 secundarias, enrutamiento entre ..........................50
Autenticación secundarios ..............................................................49
Allow Any ...............................................................173 zonas de seguridad L3 ....................................45 a 46
directivas ................................................................172 direcciones IP secundarias ...........................................49
usuarios ..................................................................172 direcciones privadas ......................................................46
autenticación en tiempo de ejecución ......................172 direcciones públicas ......................................................45
direcciones, negación ..................................................189
C directivas...........................................................................3
claves de licencia .........................................................253 acciones ..................................................................168
CLI, set arp always-on-dest .....................................73, 76 administración .......................................................176
Conjuntos de direcciones IP administrar ancho de banda ................................195
véase Conjuntos de DIP alarmas ...................................................................174
aplicación, vínculo explícito de servicio a ..........169
D asignación de tráfico .............................................175
DHCP ..............................................................96, 100, 246 Autenticación .........................................................172
agente de retransmisión.......................................227 cambiar...................................................................191
cliente .....................................................................227 colocar al principio ........................................171, 193
Escenario PXE .......................................................239 contexto de una directiva .....................................187
HA ...........................................................................234 copia de seguridad de la sesión HA ....................174
servidor ..................................................................227 Deep Inspection (DI) .............................................171
DiffServ .........................................................176, 202, 216 denegar ...................................................................168
véase también DS Codepoint Marking desactivar ...............................................................191
DIP................................................................. 99, 142 a 146 direcciones .............................................................168
conjuntos ................................................................171 direcciones en ........................................................168
Índice IX-I
edición .................................................................... 191 DS Codepoint Marking ................................196, 202, 216

elementos requeridos ........................................... 162 DSL ........................................................................242, 247
eliminación ............................................................ 194
funciones de .......................................................... 161 E
global ...................................................... 164, 177, 186 enrutadores virtuales
grupos de DIP ........................................................ 156 véase VR
grupos de direcciones........................................... 168 etiquetas, VLANs ..............................................................3
grupos de servicios ............................................... 140
grupos de usuarios de acceso telefónico a F
VPN....................................................................... 168 filtrado de URL
habilitar .................................................................. 191 véase filtrado de web
ID ............................................................................ 167 filtrado de Web ............................................................174
interzonales ........................................... 163, 177, 180 flujo de paquetes ................................................... 10 a 12
intrazonales ........................................... 163, 177, 185
L2TP ........................................................................ 170 G
libro de servicios ................................................... 109 gestión de colas de prioridades .................................200
límite máximo ....................................................... 107 gráficos de historial .....................................................174
listas de conjuntos de directivas ......................... 164 Grupo de IP dinámico (DIP) ...............................145, 171
múltiples elementos por componente................ 188 grupos
NAT-dst................................................................... 171 Direcciones ............................................................105
NAT-src ................................................................... 171 servicios..................................................................140
negación de direcciones....................................... 189 grupos de direcciones .........................................105, 168
nombre ................................................................... 170 crear ........................................................................107
ocultación ............................................................... 192 edición ....................................................................108
orden ...................................................................... 193 entradas, eliminación ...........................................108
permitir .................................................................. 168 opciones .................................................................106
rechazo ................................................................... 168 grupos de servicios ............................................ 140 a 142
recuento ................................................................. 174 crear ........................................................................140
registro de tráfico .................................................. 174 eliminar ..................................................................142
reglas internas ....................................................... 166 modificar ................................................................141
reordenar ............................................................... 193 grupos de servicios (WebUI) .......................................140
secuencia de consulta ........................................... 165 grupos en puente
servicios ................................................................. 168 interfaz lógica ..........................................................34
servicios en .................................................... 109, 168 separar......................................................................44
sistema raíz ............................................................ 166
sistemas virtuales .................................................. 166 H
tareas programadas .............................................. 175 HA
tipos .............................................................. 163 a 164 DHCP ......................................................................234
túnel ........................................................................ 169 Interfaces de HA virtuales ......................................36
túneles L2TP .......................................................... 170 véase también NSRP
verificación ............................................................ 192 historial, gráficos .........................................................174
VPN ......................................................................... 170 huso horario .................................................................257
VPN bidireccionales .............................................. 170
zonas de seguridad ............................................... 168
directivas de acceso
I
iniciar sesión ................................................................174
véase directivas
Interfaces
directivas de L2TP ....................................................... 170
agregadas .................................................................35
DNS ............................................................................... 219 asociar a zonas ........................................................43
consultas ................................................................ 220
bucle invertido .........................................................57
consultas, dominios .............................................. 225 cambios de estado ..................................................60
direcciones, división ............................................. 226
conexiones, supervisión .........................................62
servidores............................................................... 247
DIP ..........................................................................142
servidores, encapsulamiento a ............................ 225 direccionamiento ....................................................45
tabla de estado ...................................................... 221 direcciones IP secundarias .....................................49
IX-II Índice
Índice
en línea lógicamente...............................................60 Véase también direcciones

en línes físicamente ................................................60 libro de servicios
físicas en zonas de seguridad ................................34 agregado .................................................................123
fuera de línea físicamente ......................................60 entradas, eliminación (CLI) ..................................124
fuera de línea lógicamente .....................................60 entradas, modificación de (CLI) ...........................124
HA virtual .................................................................36 personalizado (CLI)................................................123
MGT...........................................................................36 personalizados .......................................................109
modificar ..................................................................47 preconfigurado ......................................................109
NAT basada en directivas .......................................37 licencia, claves .............................................................253
predeterminadas .....................................................46
redundantes .............................................................35 M
Seguimiento de IP (véase seguimiento de IP) máscaras de red .....................................................46, 168
tablas de interfaces, visualización .........................41 MGT, interfaz ..................................................................36
túnel ..........................................................................37 MIP ..................................................................................11
visualizar tabla de interfaces .................................41 Modo de rutas
VLAN1.......................................................................80 ajustes de interfaz ...................................................99
VSI .............................................................................36 NAT-src .....................................................................99
zona de función .......................................................36 modo de rutas ......................................................98 a 101
zona de función de HA ...........................................36 modo NAT ...............................................................92 a 98
zonas de seguridad L3 ............................................45 ajustes de interfaz ...................................................95
zonas, separar de ....................................................44 tráfico a la zona Untrust ...................................79, 94
interfaces Modo transparente ................................................79 a 92
túnel .................................................................. 37 a 41 ARP/trace-route .......................................................83
interfaces agregadas ......................................................35 bloquear tráfico no ARP .........................................81
interfaces de bucle invertido ........................................57 bloquear tráfico no IP .............................................81
interfaces de ScreenOS inundación ...............................................................83
subinterfaces..............................................................3 opciones unicast ......................................................83
zonas de seguridad ...................................................3 rutas ..........................................................................82
interfaces de túnel .........................................................37 tráfico broadcast ......................................................81
definición .................................................................37 modos
NAT basada en directivas .......................................37 NAT, tráfico a la zona Untrust ...............................79
interfaces de zonas de función ....................................36 transparente .............................................................79
administración.........................................................36 MS RPC ALG, definido .................................................130
HA .............................................................................36
Interfaces HA virtuales ..................................................36 N
interfaces, supervisión .......................................... 67 a 72 NAT basada en directivas, interfaces de túnel ............37
bucles ........................................................................68 NAT-src, modo de rutas .................................................99
zonas de seguridad .................................................72 negación de direcciones .............................................189
Interfaz física NetInfo ..........................................................................228
interfaz lógica ..........................................................34 NSRP
interfaz inalámbrica copia de seguridad de la sesión HA ....................174
interfaz lógica ..........................................................34 DHCP ......................................................................234
IP de administración .....................................................95 grupos de DIP ..............................................155 a 158
ISP .................................................................................225 interfaces redundantes ...........................................35
sincronización NTP ...............................................260
L VSIs ...........................................................................36
libretas de direcciones NTP ......................................................................258 a 261
Direcciones desfase horario máximo.......................................259
adición ...............................................................104 múltiples servidores ..............................................258
eliminación .......................................................108 servidores ...............................................................258
modificar ...........................................................105 servidores seguros.................................................261
entradas..................................................................104 sincronización NSRP .............................................260
entradas de grupo, edición ..................................108 tipos de autenticación ...........................................261
grupos .....................................................................105
Índice IX-III
O zonas ................................................................ 25 a 32
opción de aplicación, en directivas ........................... 169 zonas de función .....................................................32
opciones “unicast” desconocidas ........................ 82 a 87 zonas de seguridad .............................................2, 27
ARP ................................................................... 84 a 87 zonas de seguridad predefinidas .............................2
inundación ....................................................... 83 a 84 zonas de túnel .........................................................28
trace-route ................................................................ 85 seguimiento de IP
interfaces, compartidas ..........................................63
P interfaces, compatibles ..........................................62
parámetros del sistema .............................................. 260 opción “dynamic” ...................................................63
PAT................................................................................. 143 pesos .........................................................................64
Proveedor de servicios de Internet (ISP) .................. 225 redireccionamiento de tráfico ....................... 62 a 78
PXE ................................................................................ 239 umbral de fallos del objeto ....................................64
vsys ...........................................................................63
Q seguimiento de IP, fallo
QoS (calidad del servicio) ........................................... 195 interfaz de entrada, en ................................... 75 a 78
interfaz de salida, en ...................................... 74 a 75
R umbral de IP marcado ............................................64
red, ancho de banda ................................................... 195 servicios ........................................................................109
reglas, derivadas de las directivas ............................. 166 definido ..................................................................168
reloj del sistema................................................. 256 a 261 en directivas ..........................................................168
fecha y hora ........................................................... 257 ICMP .......................................................................127
huso horario .......................................................... 257 lista desplegable ....................................................109
sincronización con cliente ................................... 257 umbral del tiempo de espera ...............................124
RFC servicios ICMP..............................................................127
0792, Protocolo de mensajes de control de códigos de mensaje ..............................................128
Internet ..........................................................128 tipos de mensaje ...................................................128
1349, Tipo de servicio en el Suite de protocolo de servicios personalizados .............................................122
Internet ..........................................................176 servicios personalizados, en raíz y vsys ....................123
1918, Asignación de direcciones para Internet servicios, personalizados ............................................122
privadas ...........................................................46 ALG .........................................................................169
2132, Opciones de DHCP y extensiones de en vsys....................................................................123
proveedores de BOOTP ....................................233 Servidor PXE ................................................................240
2326, Protocolo de secuencias en tiempo real Sistema de nombres de dominio
(RTSP) ....................................................132, 136 véase DNS
2474, Definición del campo de Servicios sistema, reloj
diferenciados (campo DS) en los encabezados de véase reloj del sistema
IPv4 e IPv6 .....................................................176 sistemas virtuales ............................................................8
RSH ALG ....................................................................... 128 subinterfaces ....................................................................3
RTSP ALG crear (sistema raíz) .................................................48
códigos de estado ................................................. 135 eliminar ....................................................................49
definido .................................................................. 132 Sun RPC ALG
métodos de petición ............................................. 133 definido ..................................................................129
servidor en dominio privado ............................... 136 supuestos de llamadas..........................................129
servidor en dominio público ................................ 138 suscripciones
registro y activación .................................... 254 a 256
servicio temporal ..................................................255
S
SCREEN, zona MGT ....................................................... 28
ScreenOS T
directivas .................................................................... 3 tareas programadas .............................................158, 175
flujo de paquetes ............................................. 10 a 12 trace-route ......................................................................85
sistemas virtuales ...................................................... 8 traducción de direcciones de puertos
vista general .............................................................. 1 véase PAT
zona de seguridad global ......................................... 2 tráfico
zona global ............................................................... 28 asignación ..............................................................195
IX-IV Índice
Índice
iniciar sesión ..........................................................174 Z

prioridad .................................................................175 zona VLAN ......................................................................80
recuento .................................................................174 zonas .......................................................................25 a 32
capa 2 .......................................................................81
U definición..................................................................30
usuarios de autenticación edición ......................................................................31
autenticación en tiempo de ejecución ................172 función ......................................................................32
autenticación previa a la directiva ......................173 función, interfaz MGT .............................................36
proceso de autenticación en tiempo de global ........................................................................28
ejecución ..............................................................172 seguridad global ........................................................2
WebAuth ................................................................173 túnel ..........................................................................28
VLAN ...................................................................32, 80
V zonas de seguridad ..........................................................2
VIP ...................................................................................11 determinación, zona de destino ............................12
VLAN1 determinación, zona de origen..............................10
interfaz ...............................................................80, 87 global ..........................................................................2
zonas.........................................................................81 predefinido .................................................................2
VLANs, etiquetas ..............................................................3 zonas de seguridad, interfaces .......................................3
VPN físicas ........................................................................34
a una zona con NAT basada en interfaces ...........94 zonas, ScreenOS ....................................................25 a 32
directivas ................................................................170 interfaces de seguridad.............................................3
zonas de túnel .........................................................28 predefinido .................................................................2
VR zonas, seguridad ........................................................2, 27
introducción ...............................................................4 determinación, zona de destino ............................12
reenviar tráfico entre ................................................4 determinación, zona de origen..............................10
global ..........................................................................2
W interfaces, físicas .....................................................34
WebAuth, proceso de autenticación previo a interfaces, supervisión ............................................72
directivas....................................................................173
Índice IX-V
IX-VI Índice
Volumen 3:
Administración

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Copyright Notice
without notice.
FCC Statement
Disclaimer
ii
Contenido
Convenciones de la interfaz de usuario web ............................................ vii
Asistencia y documentación técnica................................................................. x
Capítulo 1 Administración 1
Administración a través de la interfaz de usuario web ..................................... 2
Ayuda de la interfaz gráfica (WebUI) ......................................................... 2
Copia de los archivos de ayuda a una unidad local.............................. 3
Desvío de WebUI a la nueva ubicación de la ayuda............................. 3
Protocolo de transferencia de hipertextos ................................................. 4
Identificación de sesión ............................................................................. 4
Secure Sockets Layer ................................................................................. 5
Configuración de SSL .......................................................................... 7
Redireccionamiento de HTTP a SSL .................................................... 8
Administración a través de la interfaz de línea de comandos......................... 10
Telnet ...................................................................................................... 10
Conexiones Telnet seguras ...................................................................... 11
Secure Shell ............................................................................................. 11
Requisitos del cliente ........................................................................ 13
Configuración básica de SSH en el dispositivo................................... 13
Autenticación .................................................................................... 14
SSH y Vsys ........................................................................................ 16
Clave de host .................................................................................... 17
Ejemplo: SSHv1 con PKA para inicios de sesión de automatizados ... 17
Copia segura............................................................................................ 18
Consola serie ........................................................................................... 19
Consola remota ....................................................................................... 20
Consola remota con el puerto de módem V.92 ................................. 20
Consola remota con el puerto AUX ................................................... 21
Puerto de módem.................................................................................... 22
Administración a través de NetScreen-Security Manager................................ 23
Inicio de la conectividad entre el agente de NSM y el sistema MGT ......... 24
Habilitar, inhabilitar y desactivar el agente de NSM ................................. 25
Ajustar la dirección IP del servidor principal del sistema de
administración (Management System) .............................................. 26
Ajustar la generación de informes de alarmas y de estadísticas............... 26
Sincronización de la configuración .......................................................... 28
Ejemplo: Visualizar al estado de la configuración .............................. 28
Ejemplo: Consultar el hash de configuración..................................... 28
Contenido iii
Consultar la marca de hora de configuración........................................... 29

Control del tráfico administrativo................................................................... 29
Interfaces MGT y VLAN1.......................................................................... 30
Ejemplo: Administración a través de la interfaz MGT ........................ 30
Ejemplo: Administración a través de la interfaz VLAN1..................... 31
Ajuste de las opciones de la interfaz administrativa................................. 31
Ajuste de las direcciones IP de administración para múltiples
interfaces .......................................................................................... 33
Niveles de administración .............................................................................. 35
Administrador raíz................................................................................... 35
Administrador de lectura/escritura........................................................... 36
Administrador de sólo lectura.................................................................. 36
Administrador de sistema virtual............................................................. 36
Administrador de sólo lectura del sistema virtual .................................... 37
Definición de usuarios con permisos de administrador.................................. 37
Ejemplo: Agregar un administrador de sólo lectura ................................. 37
Ejemplo: Modificar un administrador ...................................................... 37
Ejemplo: Eliminar un administrador........................................................ 38
Ejemplo: Configurar las cuentas del administrador para las conexiones
de acceso telefónico.......................................................................... 38
Ejemplo: Borrar una sesión de administrador.......................................... 39
Tráfico administrativo seguro......................................................................... 40
Cambiar el número de puerto.................................................................. 41
Cambio de nombre y contraseña de inicio de sesión del administrador .. 41
un usuario administrador ........................................................... 42
Ejemplo: Cambiar su propia contraseña............................................ 43
raíz ............................................................................................. 43
Restablecimiento del dispositivo con los ajustes predeterminados de
fábrica............................................................................................... 44
Restricción del acceso administrativo ...................................................... 44
trabajo ........................................................................................ 45
Ejemplo: Restringir la administración a una subred .......................... 45
Restringir el administrador raíz a acceder desde la consola .............. 45
Túneles de VPN para tráfico administrativo ............................................. 46
Administración a través de un túnel VPN de clave manual basado en
rutas ........................................................................................... 47
Administración a través de un túnel VPN de clave manual basado en
directivas .................................................................................... 51
Directiva de contraseñas ................................................................................ 55
Establecimiento de una directiva de contraseñas .................................... 55
Eliminación de una directiva de contraseñas ........................................... 56
Visualización de una directiva de contraseñas ......................................... 56
Recuperación de una contraseña de administrador predeterminada
rechazada ......................................................................................... 56
Creación de un mensaje de bienvenida de inicio de sesión............................ 57
Capítulo 2 Supervisión de dispositivos de seguridad 59

Almacenamiento de la información del registro............................................. 59
Registro de eventos........................................................................................ 61
Ver el registro de eventos según nivel de gravedad y palabra clave ......... 62
Clasificación y filtrado del registro de eventos ......................................... 63
iv Contenido
Contenido
Descargar el registro de eventos.............................................................. 64

Ejemplo: Descargar el registro de eventos completo ......................... 64
Ejemplo: Descargar los eventos críticos del registro de eventos ........ 64
Registro de tráfico.......................................................................................... 65
Visualización del registro de tráfico ......................................................... 66
Ejemplo: Visualizar las entradas del registro de tráfico...................... 66
Clasificación y filtrado del registro de tráfico..................................... 67
Ejemplo: Clasificar el registro de tráfico por horas ............................ 67
Descarga del registro de tráfico ............................................................... 68
Eliminación del campo del motivo de cierre............................................ 68
Registro propio ..............................................................................................70
Visualización del registro propio .............................................................. 70
Clasificación y filtrado del registro propio ......................................... 71
Ejemplo: Filtrar el registro propio por horas...................................... 71
Descargar el registro propio..................................................................... 72
Descargar el registro de recuperación de posición ......................................... 72
Alarmas de tráfico.......................................................................................... 73
Ejemplo: Detección de intrusiones basada en directivas.......................... 74
Ejemplo: Notificación de sistema comprometido..................................... 74
Ejemplo: Enviar alertas de correo electrónico .......................................... 75
Syslog ............................................................................................................ 76
Ejemplo: Habilitar múltiples servidores Syslog......................................... 77
Activación de WebTrends para eventos de notificación ........................... 77
Protocolo simple de administración de redes................................................. 78
Vista general de implementación............................................................. 81
Definición de una comunidad SNMP de lectura/escritura......................... 82
Túneles VPN para tráfico autogenerado ......................................................... 83
Ejemplo: Tráfico autogenerado a través de túnel basado en rutas ........... 85
Ejemplo: Tráfico autogenerado a través de túnel basado en directivas .... 91
Visualizar contadores de pantalla ................................................................... 98
Índice ........................................................................................................................IX-I
Contenido v
vi Contenido
Los dispositivos de seguridad de Juniper Networks ofrecen distintas formas de

administrar los dispositivos tanto local como remotamente. El Volumen 3:
Administración contiene las siguientes secciones:
Capítulo 1, “Administración,” donde se explican los distintos medios

disponibles para gestionar un dispositivo de seguridad de forma local y remota.
En este capítulo también se explican los privilegios asociados a cada uno de los
cuatro niveles de administradores de red que se pueden definir.
Capítulo 2, “Supervisión de dispositivos de seguridad,” donde se explican los

diversos métodos de supervisión y se ofrecen instrucciones para interpretar los
resultados de dicha supervisión.

siguientes:
“Convenciones de interfaz de línea de comandos” en la página viii
“Convenciones de nomenclatura y conjuntos de caracteres” en la página viii
“Convenciones para las ilustraciones” en la página x


de una dirección:
Convenciones del documento vii

Address Name: dir_1

Zone: Untrust


En ejemplos:



viii Convenciones del documento




Convenciones del documento ix



zona de seguridad

Internet

Interfaz de túnel
Servidor
Túnel VPN
Enrutador
Concentrador




Asistencia y documentación técnica xi

xii Asistencia y documentación técnica

Capítulo 1
Administración
Este capítulo describe los métodos y herramientas de administración, los métodos

para asegurar el tráfico administrativo y los niveles de privilegios administrativos
que se pueden asignar a los usuarios con permisos de administrador. Este capítulo
consta de las siguientes secciones:
“Administración a través de la interfaz de usuario web” en la página 2
“Administración a través de la interfaz de línea de comandos” en la página 10
“Administración a través de NetScreen-Security Manager” en la página 23
“Control del tráfico administrativo” en la página 29
“Niveles de administración” en la página 35
“Definición de usuarios con permisos de administrador” en la página 37
“Tráfico administrativo seguro” en la página 40
“Directiva de contraseñas” en la página 55
“Creación de un mensaje de bienvenida de inicio de sesión” en la página 57
1
Administración a través de la interfaz de usuario web

Se puede utilizar la interfaz de usuario web (WebUI) para configurar y administrar el
software de los dispositivos de seguridad de Juniper Networks. La Figura 2 muestra
la ventana de WebUI. El cuadro de la izquierda contiene el menú de navegación y el
cuadro de la derecha visualiza la ventana de navegación.
Figura 2: WebUI
Para utilizar la WebUI, debe disponer de la siguiente aplicación y conexión:
Netscape Communicator (versión 4.7 o posterior) o Microsoft Internet Explorer

(versión 5.5 o posterior)
Conexión de red TCP/IP al dispositivo de seguridad
Ayuda de la interfaz gráfica (WebUI)

Puede ver los archivos de ayuda de WebUI en la dirección
http://help.juniper.net/help/english/versión_screenos
(por ejemplo, http://help.juniper.net/help/english/5.3).
También tiene la opción de guardar los archivos de ayuda en otra ubicación. Es

posible que desee guardarlos localmente y asignar la WebUI a la estación de trabajo
del administrador o a un servidor asegurado de la red local. Si no dispone de acceso
a Internet, almacenar los archivos de ayuda localmente proporciona una
accesibilidad a los mismos que de lo contrario no tendría.
2 Administración a través de la interfaz de usuario web

Capítulo 1: Administración
Copia de los archivos de ayuda a una unidad local

Los archivos de ayuda están disponibles en el CD de documentación. Puede
modificar WebUI para que busque los archivos de ayuda en el CD insertado en su
unidad de CD local. También puede copiar los archivos del CD a un servidor de la
red local o a otra unidad de su estación de trabajo y configurar WebUI para que abra
los archivos de ayuda desde esa ubicación.
NOTA: Si desea ejecutar los archivos de ayuda directamente desde el CD de

documentación, puede omitir este procedimiento. Continúe con “Desvío de
WebUI a la nueva ubicación de la ayuda” en esta página.
1. Cargue el CD de documentación en la unidad de CD de su estación de trabajo.
2. Navegue a la unidad de CD y copie el directorio denominado help.
3. Navegue a la ubicación en la que desea guardar el directorio Help y pegue el

directorio Help allí.
Desvío de WebUI a la nueva ubicación de la ayuda

Ahora es necesario configurar WebUI para que apunte a la nueva ubicación del
directorio de ayuda. Cambie la URL predeterminada a la nueva ruta de archivos,
donde ruta se refiere a la ruta específica del directorio “Help” de la estación de
trabajo del administrador.
1. Configuration > Admin > Management: En el campo Help Link Path,

reemplace la URL predeterminada:
http://help.juniper.net/help/english/versión_screenos
por
(para unidad local) file://ruta…/help
o bien
(para servidor local) http://nombre_servidor…/ruta/help
2. Haga clic en Apply.
Al hacer clic en el vínculo help de la esquina superior derecha de la interfaz

WebUI, el dispositivo ahora utiliza la nueva ruta especificada en el campo Help
Link Path para localizar el archivo de ayuda correspondiente.
Administración a través de la interfaz de usuario web 3

Protocolo de transferencia de hipertextos

Con un explorador estándar puede tener acceso, supervisar y controlar
remotamente las configuraciones de seguridad de su red por medio del protocolo
de transferencia de hipertexto (Hypertext Transfer Protocol) (HTTP).
Puede hacer que el tráfico administrativo de HTTP sea seguro encapsulándolo en

un túnel VPN (red privada virtual) o utilizando el protocolo Secure Sockets Layer
(SSL). También puede asegurar el tráfico administrativo separándolo totalmente del
tráfico de los usuarios de la red. Para ello, puede canalizar todo el tráfico
administrativo a través de la interfaz MGT (disponible en algunos dispositivos de
seguridad) o vincular una interfaz a la zona MGT y dedicarla exclusivamente al
tráfico administrativo.
NOTA: Para obtener más información, consulte “Secure Sockets Layer” en la página 5,
“Túneles de VPN para tráfico administrativo” en la página 46 e “Interfaces MGT y
VLAN1” en la página 30.
Identificación de sesión
El dispositivo de seguridad asigna a cada sesión administrativa de HTTP un
identificador de sesión único. En los dispositivos de seguridad que admiten
sistemas virtuales (vsys), el identificador es globalmente único en todos los
sistemas: raíz (root) y virtuales (vsys).
Cada identificador de sesión es un número de 39 bytes resultante de combinar

cinco números generados de forma pseudo-aleatoria. A diferencia de los esquemas
numéricos de incremento simples, la aleatoriedad en la generación del identificador
hace que éste sea casi imposible de predecir. Además, dicha aleatoriedad
combinada con la longitud del identificador hace que la duplicación accidental de
un mismo identificador para dos sesiones administrativas simultáneas resulte
extremadamente improbable.
A continuación se explican dos ventajas que el uso de identificadores de sesión

proporciona a los administradores:
La Figura 3 ilustra cómo el dispositivo de seguridad puede distinguir varias

sesiones simultáneas de múltiples administradores detrás de un dispositivo
NAT que asigne la misma dirección IP de origen a todos los paquetes salientes.
Figura 3: ID de sesión con un dispositivo NAT

Traduce todas las direcciones Dispositivo de seguridad
Dispositivo NAT IP de origen a 10.1.1.2
Dirección IP
de origen del
Admin-A: ORIG DEST ORIG DEST
10.2.2.5 2.2.2.5 1.1.1.1 DATOS 2.2.2.5 1.1.1.1 DATOS El dispositivo asigna
a cada sesión un
Dirección IP número único de
Dirección IP de la interfaz: identificación, que
de origen del ORIG DEST ORIG DEST 10.1.1.1/24 utiliza para distinguir
Admin-B: una sesión de otra.
10.2.2.6 10.2.2.5 10.1.1.1 DATOS 10.2.2.5 10.1.1.1 DATOS

La Figura 4 ilustra cómo el dispositivo de seguridad puede distinguir diferentes

sesiones administrativas de nivel raíz simultáneas procedentes de una misma
dirección IP de origen y dirigidas al sistema raíz, y desde allí a diversos
sistemas virtuales.
Figura 4: ID de sesión con dirección IP de origen

Admin raíz Dispositivo de seguridad
2.2.2.5 Sistema raíz
1.1.1.1
El dispositivo asigna a
ORIG DEST cada sesión un número
2.2.2.5 1.1.1.1 RAÍZ único de identificación,
DATOS que utiliza para poder
distinguir las sesiones
2.2.2.5 1.1.1.1 DATOS VSYS1 procedentes de un
mismo host y dirigidas a
2.2.2.5 1.1.1.1 DATOS VSYS2 diversos sistemas raíz y
virtuales.
Secure Sockets Layer

El nivel de sockets seguro (SSL) es un conjunto de protocolos que permiten
establecer una conexión segura entre un cliente web y un servidor web a través de
una red TCP/IP. SSL se compone del Protocolo de enlace de SSL (SSLHP, del inglés
“SSL Handshake Protocol”), que permite a los equipos servidor y cliente
autenticarse y negociar un método de encriptación, y del Protocolo de registro de
SSL (SSLRP, del inglés “SSL Record Protocol”), que proporciona servicios básicos de
seguridad a los protocolos de nivel superior, tales como HTTP. Estos dos protocolos
trabajan en las dos siguientes capas del modelo de interconexión de sistemas
abiertos (Open Systems Interconnection, OSI):
SSLHP en la capa de aplicación (capa 7)
SSLRP en la capa de presentación (capa 6)
Al ser independiente del protocolo de aplicación, SSL utiliza TCP para proporcionar
servicios seguros (consulte la Figura 5). SSL utiliza certificados para autenticar
primero el servidor o bien el cliente y el servidor, y luego para encriptar el tráfico
enviado durante la sesión. ScreeOS solamente admite autenticarse desde el
servidor (dispositivo de seguridad), no desde el cliente (administrador intentando
conectarse al dispositivo de seguridad a través de SSL).

Figura 5: Cliente a servidor SSL
Alicia (cliente SSL) establece contacto con el dispositivo de seguridad (servidor

SSL) para iniciar una sesión. Dispositivo
de seguridad
El dispositivo envía a Alicia un certificado y le propone utilizar una (Servidor SSL)
Alicia clave de cifrado secreta (3DES, DES, RC4 o RC4-40), un método de
Administrador NetScreen- compresión (PKZip o gzip) y un algoritmo hash (SHA-1 o MD5).
Security Manager
(Cliente SSL)
Alicia encripta un número aleatorio con la clave pública en el certificado y
lo devuelve con una lista de los elementos propuestos que ella aceptó.
(Mientras tanto, Alicia utiliza el número aleatorio y la clave de cifrado
acordada para crear una clave secreta).
El dispositivo utiliza su clave privada para desencriptar el número.

A continuación, utiliza ese número y la clave de cifrado secreta
acordada para crear una clave secreta.
El dispositivo de seguridad y Alicia utilizan su clave secreta compartida para encriptar el

tráfico que intercambian. También utilizan el método de compresión acordado para comprimir
datos y el algoritmo hash acordado para generar un hash de los datos y así proporcionar
integridad al mensaje.
Un dispositivo de seguridad de Juniper Networks puede redirigir tráfico

administrativo usando HTTP (puerto predeterminado 80) a SSL (puerto
predeterminado 443). El certificado predeterminado para SSL es el certificado
autofirmado generado automáticamente, aunque posteriormente puede utilizar
otro certificado si lo desea. Dado que SSL lleva integrada la administración de
claves/certificados PKI, puede seleccionar cualquiera de los certificados SSL que
aparecen en la lista de certificados. También puede utilizar el mismo certificado
para una VPN IPSec.
NOTA: Para obtener información sobre la redirección del tráfico HTTP administrativo a
SSL, consulte “Redireccionamiento de HTTP a SSL” en la página 8. Para obtener
información sobre certificados autofirmados, consulte “Certificados autofirmados”
en la página 5-38). Para más información sobre la obtención de certificados,
consulte “Certificados y CRL” en la página 5-24.
La implementación del protocolo SSL en ScreenOS proporciona las siguientes

posibilidades, compatibilidades e integración:
Autenticación del servidor SSL (no autenticación de servidor y cliente SSL); es

decir, el dispositivo de seguridad se autentica ante el administrador intentando
conectarse a través de SSL, pero el administrador no utiliza SSL para
autenticarse ante el dispositivo
Compatibilidad con SSL versión 3 (no con la versión 2)
Compatibilidad con Netscape Communicator 4.7x y versiones más recientes y

con Internet Explorer 5.x y versiones más recientes
Integración de la administración de claves de la infraestructura de claves

públicas (PKI) (consulte “Criptografía de claves públicas” en la página 19)

Los siguientes algoritmos de codificación para SSL:
RC4-40 con claves de 40 bits
RC4 con claves de 128 bits
DES: Data Encryption Standard con claves de 56 bits
3DES: Triple DES con claves de 168 bits
Los algoritmos de autenticación son los mismos para SSL que para VPN:
Message Digest versión 5 (MD5), claves de 128 bits
Secure Hash Algorithm versión 1 (SHA-1), claves de 160 bits
NOTA: Los algoritmos RC4 siempre van emparejados con MD5, mientras que DES y 3DES
van con SHA-1.
Configuración de SSL
Los pasos básicos para configurar SSL son los siguientes:
1. Utilice el certificado autofirmado que el dispositivo de seguridad genera

automáticamente durante su arranque inicial, o cree otro certificado
autofirmado, u obtenga un certificado firmado por una CA y cárguelo en el
NOTA: Compruebe el nivel de encriptación (cifrado) de su explorador y cuáles son los

tipos que admite. (Tanto el dispositivo de seguridad como su explorador deben
admitir los mismos tipos y niveles de encriptación que desee utilizar para SSL). En
Internet Explorer 5x, haga clic en Help, About Internet Explorer, y lea la sección
sobre capacidad de cifrado. Para obtener el paquete de seguridad avanzado, haga
clic en Update Information. En Netscape Communicator, haga clic en Help,
About Communicator, y compruebe la sección sobre RSA. Para modificar los
ajustes de configuración SSL, haga clic en Security Info, Navigator, Configure
SSL v3.
Para obtener más información, consulte “Certificados autofirmados” en la

página 5-38. Para obtener los detalles sobre cómo solicitar y cargar un certificado,
consulte “Certificados y CRL” en la página 5-24.
2. Habilite la administración de SSL.
NOTA: SSL está habilitado de forma predeterminada.

WebUI
Configuration > Admin > Management: Introduzca los siguientes datos y haga
clic en Apply:
SSL: (seleccione)
Port: Utilice el número de puerto predeterminado (443) o cámbielo por otro.
Certificate: Seleccione en la lista desplegable el certificado que desea utilizar.
Cipher: Seleccione en la lista desplegable el cifrado que desea utilizar.
NOTA: Si modifica el número de puerto SSL, los administradores deben especificar el

número de puerto no predeterminado al introducir la URL en su explorador.
CLI
set ssl port núm
set ssl cert núm_id
set ssl encrypt { { 3des | des } sha-1 | { rc4 | rc4-40 } | md5 }
set ssl enable
save
NOTA: Para averiguar el número de identificación de un certificado, utilice el comando

siguiente: get pki x509 list cert.
3. Configure la interfaz a través de la cual se administra el dispositivo de

seguridad para permitir la administración de SSL:
WebUI
Network > Interfaces > Edit (para la interfaz que desea administrar):
Seleccione la casilla de verificación del servicio de administración de SSL,
después haga clic en OK.
CLI
set interface interfaz manage ssl
save
4. Conéctese al dispositivo de seguridad a través del puerto SSL. Cuando

introduzca la dirección IP de administración del dispositivo de seguridad en el
campo URL de su explorador, cambie http por https y agregue la dirección IP
con dos puntos, seguidos del número de puerto HTTPS (SSL) si lo cambió del
predeterminado. Por ejemplo:
https://123.45.67.89:1443.
Redireccionamiento de HTTP a SSL

Un dispositivo de seguridad puede redirigir tráfico administrativo utilizando HTTP
(puerto predeterminado 80) a SSL (puerto predeterminado 443), como se muestra
en la Figura 6.

Durante el establecimiento de conexión SSL, el dispositivo de seguridad envía a

Alicia su certificado. Alicia encripta un número aleatorio con la clave pública que se
incluye en el certificado y lo devuelve al dispositivo, que utiliza su clave privada
para desencriptar el número. Ambos participantes utilizan el número aleatorio
compartido y una clave de cifrado secreta negociada (3DES, DES, RC4, o RC4-40)
para crear una clave secreta compartida, que utilizan para encriptar el tráfico entre
ellos. También utilizan el método de compresión acordado (PKZip or gzip) para
comprimir datos y el algoritmo hash acordado (SHA-1 or MD-5) para generar un
hash de los datos y así proporcionar integridad al mensaje.
Figura 6: Redirección de HTTP a SSL

Puerto de destino 80
HTTP-Get
Texto puro
Respuesta HTTP
Alicia
(Admin de Instrucciones para redireccionar
NetScreen) de HTTP a HTTPS
Conexión SSL
HTTP-Get Puerto de destino
Encriptado
Para habilitar el reenvío y utilizar el certificado autofirmado generado

automáticamente para SSL, lleve a cabo cualquiera de los siguientes
procedimientos:
WebUI
Configuration > Admin > Management: Introduzca los siguientes datos y haga
clic en Apply:
Redirect HTTP to HTTPS: (seleccione)

Certificate: Default – System Self-Signed Cert
CLI
set admin http redirect
save
NOTA: No tiene que introducir un comando CLI para aplicar el certificado autofirmado
generado automáticamente para su uso con SSL porque el dispositivo de
seguridad lo aplica a SSL de forma predeterminada. Si asignó previamente otro
certificado para uso con SSL y ahora desea utilizar el certificado predeterminado
en su lugar, debe eliminar el otro certificado con el comando unset ssl cert
núm_id, en el cual núm_id es el número de identificador del certificado asignado
previamente.
Aunque HTTP no proporciona la seguridad que da SSL, puede configurar el

dispositivo de seguridad de modo que no reenvíe tráfico HTTP. Para desactivar el
mecanismo de redireccionamiento de HTTP a SSL, anule la selección de la opción
Redirect HTTP to HTTPS en la WebUI o introduzca el comando CLI unset admin
http redirect.

Administración a través de la interfaz de línea de comandos

Los administradores avanzados pueden aumentar el grado de control utilizando la
interfaz de línea de comandos (CLI). Para configurar un dispositivo de seguridad
con la CLI, puede utilizar cualquier software que emule un terminal VT100. Con un
emulador de terminal, puede configurar el dispositivo de seguridad abriendo una
consola en cualquier sistema operativo Windows, UNIX o Macintosh. Para
administrar remotamente utilizando la CLI, utilice Telnet o Secure Shell (SSH). Si
dispone de una conexión directa a través del puerto de consola, puede utilizar
HyperTerminal.
NOTA: Para obtener un listado completo de los comandos CLI de ScreenOS, consulte el
Manual de referencia de CLI ScreenOS. Descripciones del comando IPv4.
Telnet
Telnet es un protocolo de inicio de sesión y de emulación de terminales que utiliza
una relación cliente/servidor para conectarse y configurar remotamente los
dispositivos de una red TCP/IP. El administrador ejecuta un programa cliente de
Telnet en la estación de trabajo de administración y crea una conexión con el
programa servidor de Telnet instalado en el dispositivo de seguridad. Después de
iniciar la sesión, el administrador puede enviar comandos de la CLI, que se
transmiten al programa de Telnet del dispositivo de seguridad, permitiendo
configurar eficazmente el dispositivo como si se estuviese trabajando a través de
una conexión directa. Para utilizar Telnet con el fin de administrar los dispositivos
de seguridad se requiere la siguiente aplicación y conexión:
Software Telnet en la estación de trabajo de administración
Una conexión Ethernet al dispositivo de seguridad
La Figura 7 ilustra el procedimiento de configuración para establecer una conexión

Telnet.
Figura 7: Establecimiento de una conexión Telnet
1. El cliente Telnet envía una petición de conexión

TCP al puerto 23 del dispositivo de seguridad (que
actúa como servidor Telnet).
2. El dispositivo solicita al cliente que inicie una sesión

con un nombre de usuario y una contraseña.
3. El cliente envía su nombre de usuario y contraseña, ya sea

en modo transparente o encriptados en un túnel VPN.
Para reducir al mínimo las posibilidades de que un usuario no autorizado pueda

iniciar una sesión en un dispositivo, puede limitar el número de intentos de
conexión que el dispositivo de seguridad admitirá antes de cerrar la sesión de
Telnet. Esta restricción también protege contra ciertos tipos de ataques, como los
ataques de diccionario automatizados.
10 Administración a través de la interfaz de línea de comandos

De forma predeterminada, el dispositivo de seguridad permite hasta tres intentos

fallidos de inicio de sesión antes de cerrar la sesión de Telnet. Para cambiar este
número, introduzca el comando siguiente:
set admin access attempts número
NOTA: Para establecer esta restricción debe utilizarse la CLI.
Conexiones Telnet seguras

El tráfico de datos Telnet se puede asegurar separándolo totalmente del tráfico de
los usuarios de la red. Dependiendo del modelo de su dispositivo de seguridad,
puede transmitir todo el tráfico administrativo a través de la interfaz MGT o dedicar
una interfaz específica, como la DMZ, enteramente al tráfico administrativo.
Además, para asegurarse de que los usuarios con permisos de administrador

utilicen una conexión segura al administrar un dispositivo de seguridad a través de
Telnet, puede requerir a tales usuarios que utilicen Telnet exclusivamente a través
de un túnel de red privada virtual (VPN). Después de establecer esta restricción, el
dispositivo denegará el acceso a cualquiera que intente ejecutar Telnet sin pasar a
través de un túnel VPN.
NOTA: Para obtener información sobre los túneles de VPN, consulte el Volumen 5:
Redes privadas virtuales.
Para obligar a Telnet a acceder a través de una VPN, introduzca el comando

siguiente:
set admin telnet access tunnel
Secure Shell
El servidor Secure Shell (SSH) integrado en un dispositivo de seguridad de Juniper
Networks proporciona a los administradores un medio para la administración
remota del dispositivo de manera segura utilizando las aplicaciones que reconocen
SSH. SSH permite abrir de forma segura un entorno de comandos remoto y ejecutar
comandos. SSH proporciona protección contra los ataques de simulación de IP o
DNS (“spoofing”) y contra la interceptación de contraseñas y datos.
Puede elegir entre ejecutar un servidor SSH versión 1 (SSHv1) o SSH versión 2
(SSHv2) en el dispositivo. SSHv2 se considera más seguro que SSHv1 y está siendo
desarrollado actualmente como estándar del IETF. Sin embargo, SSHv1 está
ampliamente difundido y se utiliza comúnmente. Observe que SSHv1 y SSHv2 no
son compatibles entre sí. Es decir, no se puede conectar un cliente SSHv1 a un
servidor SSHv2 en el dispositivo de seguridad, ni viceversa. La consola o aplicación
de terminal del cliente debe ejecutar la misma versión de SSH que el servidor. La
Figura 8 ilustra el flujo de tráfico SSH.
Administración a través de la interfaz de línea de comandos 11

Figura 8: Flujo de tráfico SSH

Tráfico administrativo encriptado ScreenOS
Cliente SSH Internet Servidor SSH
Estación de trabajo Dispositivo de seguridad

del administrador
Figura 9: ilustración del procedimiento básico de conexión de SSH.
Figura 9: Conexión de SSH
1. El cliente de SSH envía una petición de conexión TCP al puerto 22

del dispositivo de seguridad (que actúa como servidor de SSH).
2. El dispositivo y el cliente intercambian información

sobre la versión de SSH que cada uno admite. Claves
Host Key (Clave del host): Componente de clave

3. El dispositivo envía el componente público de sus claves de host y de pública de un par de claves públicas/privadas
servidor, su cookie y los algoritmos de encriptación y autenticación que que se utiliza para autenticar el dispositivo de seguridad o
admite. sistema virtual ante el cliente y encriptar la clave de la
sesión. (Cada vsys tiene su propia clave de host). La
4. El cliente crea una clave secreta para la sesión, la encripta clave de host está permanentemente asociada al
con el componente público de las claves de host y de servidor dispositivo o vsys.
y envía la clave de la sesión al dispositivo.
Server Key (Clave del servidor): El par de claves
públicas/privadas RSA temporal utilizado para encriptar la
clave de la sesión. (De forma predeterminada, el
dispositivo genera uno nuevo cada hora para cada vsys).
5. El dispositivo firma la clave de la sesión con su clave privada y envía
la clave de la sesión firmada al cliente. El cliente verifica la firma con la Session Key (Clave de la sesión): Clave secreta
clave de la sesión generada durante el intercambio de claves. De este temporal (DES o 3DES) que el cliente y el dispositivo
modo se completa la creación de un canal seguro. crean en conjunto durante el establecimiento de la
conexión para encriptar la comunicación (y que se
descarta al terminar la sesión).
PKA Key (Clave PKA): Par de claves pública/privada

RSA persistente que reside en el cliente de SSH. La clave
6. El dispositivo envía una señal al cliente de SSH para que pida al pública del cliente también debe estar cargada en el
usuario final la información de autenticación. dispositivo de seguridad antes de iniciar una conexión de
SSH; la clave PKA debe estar asociada al usuario con
permisos del usuario con permisos de administrador.
7. El cliente encripta un nombre de usuario y una contraseña o el Nota: Par de claves pública/privada = Conjunto de claves
componente público de su clave PKA y envía ambos para su encriptadas que operan de modo que cualquier elemento
autenticación. encriptado por una, sólo se pueda desencriptar con la
otra.
Un dispositivo de seguridad de Juniper Networks admite un máximo de cinco

sesiones SSH simultáneas.

Requisitos del cliente

De acuerdo con lo indicado en “Secure Shell” en la página 11, la aplicación del
equipo cliente debe ejecutar la misma versión de SSH que el servidor en el
dispositivo de seguridad. Los clientes SSHv2 deben configurarse para solicitar el
algoritmo de intercambio de claves Diffie-Hellman y el algoritmo de firma digital
DSA (“Digital Signature Algorithm”) para la autenticación del dispositivo mediante
clave pública. Los clientes SSHv1 deben configurarse para solicitar el algoritmo RSA
para la autenticación de dispositivos mediante clave pública.
Configuración básica de SSH en el dispositivo

A continuación se enumeran los pasos básicos para configurar SSH en un
dispositivo de seguridad de Juniper Networks:
1. Decida si utilizará autenticación mediante contraseña o mediante clave pública

(PKA) para acceder a SSH. Si decide utilizar PKA, las claves de PKA deben estar
asociadas a un administrador antes de establecer las conexiones de SSH.
Consulte “Autenticación” en la página 14 para obtener más información sobre
si utilizar contraseñas o PKA.
2. Decida qué versión de SSH necesita habilitar en el dispositivo de seguridad.

(Recuerde que la aplicación del equipo cliente y el servidor de SSH en el
dispositivo deben ejecutar la misma versión de SSH). Si habilitó SSH en el
dispositivo en una versión anterior de ScreenOS, al activar SSH ahora
comenzará a ejecutarse SSHv1. Para consultar qué versión de SSH está activa
pero no habilitada en el dispositivo, ingrese el comando CLI get ssh:
device> get ssh

SSH V1 is active
SSH is not enabled
SSH is not ready for connections
Maximum sessions: 8
Active sessions: 0
En la representación anterior, SSHv1 está activo y comienza a ejecutarse al

habilitar SSH. Si desea utilizar otra versión de SSH, asegúrese de que todas las
claves creadas con la versión anterior queden eliminadas. Por ejemplo, para
borrar las claves de SSHv1 y utilizar SSHv2, utilice los siguientes comandos CLI:
device> delete ssh device all
Aparecerán los siguientes mensajes:
SSH disabled for vsys: 1

PKA key deleted from device: 0
Host keys deleted from device: 1
Execute the ‘set ssh version v2’ command to activate SSH v2 for the device
Para utilizar SSHv2, utilice el siguiente comando CLI:
device-> set ssh version v2
NOTA: El hecho de establecer la versión de SSH no habilita SSH en el dispositivo.

3. Si no desea utilizar el puerto 22 (el puerto predeterminado) para las conexiones

de cliente de SSH, se puede especificar un número de puerto entre 1024 y
32767.
NOTA: También puede utilizar WebUI para cambiar el número de puerto y habilitar SSHv2
y SCP en la página Configuration > Admin > Management.
device-> set admin ssh port 1024
4. Habilite SSH para el sistema raíz o para el sistema virtual. Consulte “SSH y
Vsys” en la página 16 para obtener más información sobre cómo habilitar y
utilizar SSH en cada sistema virtual vsys.
Para habilitar SSH para el sistema raíz:
device-> set ssh enable
Si desea habilitar SSH para un vsys, primero debe entrar en dicho vsys y
habilitar SSH:
device-> set vsys v1

device(v1)-> set ssh enable
5. Habilite SSH en la interfaz a la que se conectará el cliente de SSH.
device-> set interface manage ssh
6. Distribuya la clave del host generada en el dispositivo de seguridad al cliente de

SSH. Para obtener más información, consulte “Clave de host” en la página 17.
Autenticación
Un administrador puede conectarse a un dispositivo de seguridad de
Juniper Networks mediante SSH usando uno de los dos métodos de autenticación:
Autenticación mediante contraseña: Este método lo utilizan los

administradores que necesitan configurar o supervisar un dispositivo de
seguridad. El cliente de SSH inicia una conexión de SSH al dispositivo. Si en la
interfaz que recibe la petición de conexión está habilitada la posibilidad de
gestión de SSH, el dispositivo envía una señal al cliente de SSH para que solicite
al usuario su nombre y contraseña. Cuando el cliente de SSH dispone de esta
información, la envía al dispositivo, que la compara con el nombre de usuario y
contraseña registrados en la cuenta del usuario administrador. Si coinciden, el
dispositivo autentica al usuario. Si no coinciden, el dispositivo rechaza la
petición de conexión.
Autenticación mediante clave pública (PKA, del inglés “Public Key

Authentication”): Este método ofrece mayor seguridad que el método de
autenticación mediante contraseña y permite ejecutar guiones automatizados.
En lugar del nombre y contraseña del usuario, el cliente de SSH envía un
nombre de usuario y el componente público de un par de claves
pública/privada. El dispositivo lo compara con hasta cuatro claves públicas que
se puedan asociar a un administrador. Si una de las claves coincide, el
dispositivo autentica al usuario. Si ninguna de las claves coincide, el dispositivo
rechaza la petición de conexión.

NOTA: Los algoritmos de autenticación admisibles son RSA para SSHv1 y DSA para
SSHv2.
Ambos métodos de autenticación requieren el establecimiento de una conexión

segura antes de que el cliente de SSH pueda conectarse. Una vez que un cliente de
SSH haya establecido una conexión de SSH con el dispositivo, debe autenticarse
con un nombre de usuario y una contraseña, o bien con un nombre de usuario y
una clave pública.
Tanto la autenticación mediante contraseña como mediante clave pública (PKA)

requieren crear una cuenta para el usuario administrador en el dispositivo y activar
la posibilidad de gestión de SSH en la interfaz por la que se pretende administrar el
dispositivo a través de una conexión de SSH. (Para obtener información sobre cómo
crear una cuenta de usuario con permisos de administrador, consulte “Definición
de usuarios con permisos de administrador” en la página 37.) El método de
autenticación mediante contraseña no requiere ninguna configuración adicional en
el cliente de SSH.
Por otra parte, los preparativos para PKA consisten en las siguientes tareas
preliminares:
1. En el cliente de SSH, genere una par de claves (una pública y una privada)
usando un programa de generación de claves. (El par de claves debe ser RSA
para SSHv1 o DSA para SSHv2. Para obtener más información, consulte la
documentación de la aplicación cliente de SSH).
NOTA: Si desea utilizar PKA para realizar inicios de sesión automatizados, también debe
cargar un agente en el equipo cliente de SSH para desencriptar el componente
privado del par de claves pública/privada PKA y mantener en memoria la versión
desencriptada de la clave privada.
2. Mueva la clave pública desde el directorio SSH local a un directorio en su

servidor TFTP y ejecute el programa TFTP.
NOTA: También se puede pegar el contenido archivos de clave pública directamente en el

comando CLI set ssh pka-rsa [ username cadena_nombre ] key cadena_clave (para
SSHv1) o set ssh pka-dsa [ user-name cadena_nombre ] key cadena_clave (para
SSHv2), pegándolo donde indique la variable cadena_clave, o en el campo Key de
la WebUI (Configuration > Admin > Administrators > SSH PKA). Sin embargo,
tanto CLI como WebUI tienen una restricción en cuanto al tamaño: el tamaño de la
clave pública no puede ser superior a 512 bits. Esta restricción no es aplicable
cuando la clave se carga a través de TFTP.
3. Inicie una sesión en el dispositivo para poder configurarlo con la CLI.

4. Para transferir la clave pública desde el servidor TFTP al dispositivo, introduzca

uno de los siguientes comandos CLI:
Para SSHv1:
exec ssh tftp pka-rsa [ username nombre ] file-name cadena_nombre ip-addr

dir_ip_tftp
Para SSHv2:
exec ssh tftp pka-dsa [ user-name name ] file-name cadena_nombre ip-addr

dir_ip_tftp
Las opciones username o user-name sólo están disponibles para el

administrador raíz, por lo que sólo este usuario puede asociar una clave RSA a
otro administrador. Cuando el administrador raíz o el administrador de
lectura/escritura ejecuta el comando sin incluir un nombre de usuario, el
dispositivo asocia la clave a su propia cuenta de administrador, es decir, al
administrador que ejecuta el comando.
NOTA: El dispositivo admite hasta cuatro claves públicas PKA por cada usuario con
permisos de administrador.
Cuando un administrador intenta iniciar una sesión a través de SSH en una interfaz
que tiene habilitada la gestión de SSH, el dispositivo NetScreen comprueba primero
si ese administrador tiene asociada una clave pública. En caso afirmativo, el
dispositivo autentica al administrador mediante PKA. Si no hay ninguna clave
pública asociada al administrador, el dispositivo pide un nombre de usuario y una
contraseña. (Puede utilizar el siguiente comando para obligar a un administrador a
utilizar únicamente el método PKA: set admin ssh password disable username
cadena_nombre.) Sin tener en cuenta el método de autenticación que desee
imponer al administrador, al definir inicialmente su cuenta deberá incluir de todos
modos una contraseña, aunque en el futuro ésta pase a ser irrelevante si asocia una
clave pública a ese usuario.
SSH y Vsys
Para los dispositivos de seguridad que admitan vsys, puede habilitar y configurar
SSH en cada vsys individualmente. Cada vsys tiene su propia clave de host (consulte
“Clave de host” en la página 17) y mantiene y administra una clave de PKA para el
administrador del sistema.
El número máximo de sesiones de SSH es una limitación inherente a cada

dispositivo y oscila entre 2 y 24, dependiendo de la plataforma. Cuando en un
dispositivo ya se ha registrado el número máximo de clientes de SSH, ningún otro
cliente de SSH puede iniciar sesión en el servidor de SSH. El sistema raíz y los vsys
comparten el mismo número de puerto de SSH. Esto significa que si se modifica el
puerto predeterminado de SSH (puerto 22), también cambia para todos los vsys.
NOTA: Cuando se implementa una gran cantidad de sistemas virtuales en un solo

dispositivo, tenga en cuenta que si varios o todos los administradores de sistemas
virtuales utilizan SSH, el almacenamiento reservado para los objetos PKI puede
llenarse.

Clave de host
La clave de host permite al dispositivo identificarse ante un cliente de SSH. En los
dispositivos que admiten sistemas virtuales (vsys), cada vsys tiene su propia clave
de host. Cuando se activa SSH por primera vez en un vsys (en dispositivos que
admiten vsys) o en un dispositivo, se genera una clave de host única para dicho
vsys o dispositivo. La clave de host se asocia con carácter permanente al vsys o
dispositivo y se vuelve a utilizar incluso después de inhabilitar y rehabilitar SSH.
La clave de host del dispositivo se debe distribuir al cliente de SSH mediante uno de
los dos métodos siguientes:
Manualmente: El administrador raíz o vsys envía la clave de host al usuario con

permisos de administrador del cliente por medio de correo electrónico,
teléfono, etc. El administrador receptor guarda la clave de host en el archivo
SSH apropiado del sistema cliente. (La aplicación cliente de SSH determina la
ubicación y el formato del archivo).
Automáticamente: Cuando el cliente de SSH se conecta al dispositivo, el

servidor de SSH envía al cliente el componente público de la clave de host sin
encriptar. El cliente de SSH comprueba en su base de datos local si la clave de
host recibida está asociada a la dirección del dispositivo. Si la clave de host es
desconocida (si la base de datos local de claves de host no contiene ninguna
asociación a la dirección del dispositivo), el usuario administrador puede
decidir si acepta la clave de host. De lo contrario, se termina la conexión.
(Consulte la documentación del cliente de SSH correspondiente para obtener
más información sobre la aceptación de claves de host desconocidas).
Para verificar si el cliente de SSH ha recibido la clave de host correcta, el usuario

administrador del sistema cliente puede generar el hash (resumen encriptado) SHA
de la clave de host recibida. El usuario administrador del cliente puede entonces
comparar este hash SHA con el hash SHA de la clave de host existente en el
dispositivo. En el dispositivo, el hash SHA de la clave de host se puede mostrar
ejecutando el comando CLI get ssh host-key.
Ejemplo: SSHv1 con PKA para inicios de sesión de automatizados

En este ejemplo, usted (como administrador raíz) configura la autenticación
mediante clave pública (PKA) de SSHv1 para un host remoto que ejecuta un guión
automatizado. El único propósito de que este host remoto acceda al dispositivo es
descargar el archivo de configuración cada noche. Dado que la autenticación está
automatizada, no se requiere intervención humana para que el cliente de SSH inicie
una sesión en el dispositivo.
Defina una cuenta de usuario con permisos de administrador denominada cfg, con
la contraseña cfg y privilegios de lectura/escritura. Habilite la posibilidad de gestión
de SSH en la interfaz “ethernet1”, asociada a la zona “Untrust”.
Usted utilizó previamente un programa de generación de claves en su cliente de

SSH para generar un par de claves pública/privada RSA, movió el archivo de clave
pública, que tiene el nombre de archivo “idnt_cfg.pub” a un directorio en su
servidor TFTP e implementó el programa TFTP. La dirección IP del servidor TFTP es
10.1.1.5.

WebUI
Configuration > Admin > Administrators > New: Introduzca los siguientes
Name: cfg
New Password: cfg
Confirm Password: cfg
Privileges: Read-Write (seleccione)
SSH Password Authentication: (seleccione)
Network > Interfaces > Edit (para ethernet1): Seleccione SSH en Service
Options y después haga clic en OK.
NOTA: Únicamente es posible cargar un archivo de claves públicas para SSH desde un
servidor TFTP por medio del comando exec ssh.
CLI
set admin user cfg password cfg privilege all
set interface ethernet1 manage ssh
exec ssh tftp pka-rsa username cfg file-name idnt_cfg.pub ip-addr 10.1.1.5
save
Copia segura
La copia segura (SCP, Secure Copy) es un método de transferencia de archivos entre
un cliente remoto y el dispositivo de seguridad utilizando el protocolo SSH. (El
protocolo SSH proporciona la autenticación, la encriptación y la integridad de datos
a la conexión SCP). El dispositivo actúa como servidor de SCP para aceptar
conexiones de clientes de SCP en hosts remotos.
SCP requiere que el cliente remoto se haya autenticado antes de poder comenzar la
transferencia de archivos. La autenticación de SCP sigue exactamente el mismo
proceso utilizado para autenticar clientes de SSH. El cliente de SCP se puede
autenticar con una contraseña o una clave de PKA. Una vez autenticado el cliente
de SCP, pueden transferirse uno o más archivos hacia o desde el dispositivo. La
aplicación cliente de SCP determina el método exacto para especificar los nombres
de archivo de origen y de destino; consulte la documentación de la aplicación
cliente de SCP.
De forma predeterminada, SCP está inhabilitado en el dispositivo. Para habilitar

SCP es necesario habilitar también SSH.
WebUI
Configuration > Admin > Management: Seleccione los siguientes datos y haga
clic en Apply:
Enable SSH: (seleccione)

Enable SCP: (seleccione)
CLI
set ssh enable
set scp enable
save

Lo que sigue es un ejemplo de un comando del cliente de SCP para copiar el archivo
de configuración desde la memoria flash de un dispositivo NetScreen (el nombre
del administrador es “juniper” y la dirección IP es 10.1.1.1) al archivo
“ns_sys_config_backup” del sistema cliente:
scp juniper@10.1.1.1:ns_sys_config ns_sys_config_backup
También puede también copiar una imagen ScreenOS a y desde un dispositivo.

Para guardar una imagen denominada “ns.5.1.0r1” en un dispositivo de un cliente
SCP, introduzca el siguiente comando del cliente SCP, en el que el nombre de
usuario es “juniper” y la dirección IP del dispositivo es 10.1.1.1:
scp ns.5.1.0r1 juniper@10.1.1.1:image
Luego introduzca el comando reset para reiniciar el dispositivo para cargar y

ejecutar la nueva imagen ScreenOS.
Para copiar una imagen ScreenOS desde un dispositivo a un cliente SCP y para
nombrar la imagen guardada “current_image_backup”, introduzca el siguiente
comando del cliente SCP:
scp juniper@10.1.1.1:image current_image_backup
Consulte la documentación de la aplicación cliente de SCP para obtener

información sobre cómo especificar el nombre del administrador, la dirección IP del
dispositivo y los archivos de origen y de destino.
Consola serie
Puede administrar un dispositivo de seguridad por medio de una conexión serie
directa entre la estación de trabajo del administrador y el dispositivo a través del
puerto de consola. Aunque no siempre es posible establecer una conexión
directa, éste es el método más seguro para administrar el dispositivo,
siempre que el entorno donde se encuentre el dispositivo también sea
seguro.
NOTA: Para impedir que usuarios no autorizados puedan iniciar sesiones remotamente
como administrador raíz, puede obligar a éste a iniciar sus sesiones en el
dispositivo exclusivamente a través de la consola. Para obtener más información
sobre esta restricción, consulte “Restringir el administrador raíz a acceder desde la
consola” en la página 45.
Dependiendo del modelo de su dispositivo de seguridad de Juniper Networks, para

establecer una conexión serie necesitará uno de los siguientes cables:
Un cable serie directo con un conector hembra DB-9 y un conector macho

DB-25
Un cable serie directo con un conector hembra DB-9 y un conector macho DB-9
Un cable serie con un conector hembra DB-9 y un conector macho MiniDIN-8
Un adaptador con un conector hembra DB-9 a RJ-45 y un cable Ethernet directo

RJ-45 a RJ-45

También necesitará el software HyperTerminal (u otro emulador del terminal

VT100) en la estación de trabajo de administración, con los ajustes de puerto de
Hyperterminal configurados como se indica a continuación:
Comunicaciones serie a 9600 bps
8 bits
Sin paridad
1 bit de parada
Sin control de flujo
NOTA: Para obtener más detalles acerca del uso de HyperTerminal, consulte el Manual de
referencia CLI ScreenOS: Descripciones del comando IPv4 o la documentación para
su dispositivo.
Consola remota
Puede obtener acceso de manera remota a la interfaz de consola en un dispositivo
de seguridad para acceso telefónico a la misma. Existen dos maneras de acceso
telefónico en la consola:
Consola remota con el puerto de módem V.92
Consola remota con el puerto AUX
Consola remota con el puerto de módem V.92

Puede administrar remotamente los dispositivos de seguridad que cuentan con
puertos de módem v.92 mediante acceso telefónico al puerto y a la interfaz de
consola. Para utilizar la consola remota, conecte el puerto de módem v.92 en el
dispositivo a una línea telefónica y obtenga acceso telefónico al dispositivo
utilizando una computadora remota con un módem. Utilice un programa de
terminal como HyperTerminal para establecer la sesión de la consola.
A fin de utilizar la conexión de consola remota, primero debe permitir la

administración remota con el siguiente comando CLI:
set interface serialx/0 modem aux enable

save

La Figura 10 muestra cómo conectar el dispositivo para la administración de

consola remota.
Figura 10: Conexión de administración de consola remota

Estación de trabajo de
administración con
módem
Sistema telefónico
público
Puerto v.92 en el
dispositivo de seguridad

8 bits
Sin paridad
1 bit de parada
NOTA: Para obtener más detalles acerca del uso de HyperTerminal, consulte el Manual de
referencia CLI ScreenOS: Descripciones del comando IPv4 o la documentación para
su dispositivo.
Consola remota con el puerto AUX

Puede administrar remotamente los dispositivos de seguridad que cuentan con
puertos AUX mediante acceso telefónico a un módem conectado al puerto y a la
interfaz de consola. Para utilizar la consola remota, conecte el puerto de módem
AUX en el dispositivo a una línea telefónica con un módem externo y obtenga
acceso telefónico al dispositivo utilizando una computadora remota con un módem.
Utilice un programa de terminal como HyperTerminal para establecer la sesión de
la consola.

La Figura 10 muestra cómo conectar el dispositivo para la administración de

consola remota.
Figura 11: Conexión de administración de consola remota

Estación de trabajo de
administración con
módem
Sistema telefónico
público
Módem
externo v.92 Puerto AUX en el

8 bits
Sin paridad
1 bit de parada
NOTA: Para obtener más detalles acerca del uso de HyperTerminal, consulte el mnaual
ScreenOS CLI Reference Guide: IPv4 Command Descriptions o la documentación de
su dispositivo.
Puerto de módem
El dispositivo de seguridad también se puede administrar conectando la estación de
trabajo del administrador al puerto de módem del dispositivo. El puerto de módem
funciona de forma similar al puerto de consola, salvo que no se pueden definir sus
parámetros ni utilizar esta conexión para transferir una imagen.
Para impedir que usuarios no autorizados puedan administrar el dispositivo a través

de una conexión directa a la consola o al puerto de módem, puede inhabilitar
ambos puertos mediante los siguientes comandos:
set console disable

set console aux disable

Administración a través de NetScreen-Security Manager

NetScreen-Security Manager es una aplicación de software de administración a
nivel corporativo de Juniper Networks que se encarga de la configuración y
supervisión de los dispositivos de seguridad de Juniper Networks a través de un
entorno de red de área local (LAN) o red de área extensa (WAN). La interfaz de
usuario (UI) de NetScreen-Security Manager permite a los administradores de red
implementar, configurar y administrar múltiples dispositivos desde puestos de
trabajo centrales.
NetScreen-Security Manager utiliza tres componentes para habilitar la

comunicación remota con dispositivos de seguridad.
La Interfaz de usuario (UI) NetScreen-Security Manager es una aplicación de

software basada en java que se utiliza para obtener acceso y configurar datos
en su red junto con el sistema de administración de NetScreen-Security
Manager. Desde la UI, se puede visualizar, configurar y administrar su red.
El sistema Management System es un conjunto de servicios que reside en un

host externo. Estos servicios procesan, supervisan y almacenan la información
de administración de dispositivos intercambiada entre un dispositivo y la UI de
NetScreen-Security Manager. El sistema de administración consta de dos
componentes:
El servidor de GUI recibe y responde las peticiones y los comandos desde la

UI. Administra los recursos del sistema y los datos de configuración
requeridos para administrar su red. También incluye un almacenamiento
de información de datos locales sobre sus dispositivos de seguridad
administradores y configuraciones administradas.
El servidor del dispositivo actúa como un punto de recopilación de todos los

datos generados por cada uno de los dispositivos de su red. Almacena estos
datos, principalmente los registros de tráfico, en el almacenamiento de
datos locales.
El agente NSM es un servicio que reside en cada dispositivo de seguridad

administrado. El agente NSM recibe parámetros de configuración
procedentes del sistema de administración externo y los reenvía a
ScreenOS. El agente de NSM también supervisa cada dispositivo y
transmite informes al sistema de administración (Management System). El
agente de NSM puede descargar paquetes de firmas, certificados y
derechos entre el dispositivo de seguridad y NetScreen-Security Manager.
Administración a través de NetScreen-Security Manager 23

La Figura 12 muestra cómo se comunica el agente de NSM con la UI de

NetScreen-Security Manager.
Figura 12: Dispositivo de seguridad con el agente de NSM habilitado

Sistema de administración
Interfaz de
NetScreen-Security
Servidor principal Manager
El servidor principal
contiene un servidor
de dispositivos y el
servidor de GUI.
Agente de NSM:
El dispositivo de seguridad utiliza su
agente incorporado para comunicarse Servidores de dispositivos y GUI: El administrador
con el servidor de dispositivos. El servidor de dispositivos envía cambios de NetScreen-Security
configuración al dispositivo de seguridad y recibe Manager opera el sistema
informes operativos y estadísticos del mismo. de administración a través
del cliente.
El servidor de GUI procesa los cambios de
configuración que recibe de uno o más clientes
del Administrador de seguridad NetScreen.
Para obtener más información sobre éstos y otros componentes de

NetScreen-Security Manager, consulte el Manual del administrador de
Inicio de la conectividad entre el agente de NSM y el sistema MGT

Para que NetScreen-Security Manager pueda acceder y administrar el dispositivo de
seguridad, primero es necesario iniciar las comunicaciones entre el agente de NSM
(que reside en el dispositivo) y el sistema de administración Management System
(que reside en un host externo). La inicialización puede requerir hasta dos usuarios
en dos sitios diferentes, dependiendo de la disponibilidad actual del dispositivo de
seguridad. Estos usuarios pueden incluir al administrador de NetScreen-Security
Manager, que utiliza la UI de NetScreen-Security Manager en un equipo cliente, y al
usuario local, que ejecuta comandos CLI en un dispositivo a través de una sesión de
consola. Entre los casos posibles de inicialización se incluyen los siguientes:
Caso 1: Un dispositivo ya tiene una dirección IP conocida y está accesible a

través de su infraestructura de red.
En este caso, el administrador de NetScreen-Security Manager agrega el

dispositivo usando la UI de NetScreen-Security Manager del cliente host. (No se
precisa un usuario local). El dispositivo se conecta automáticamente al sistema
de administración Management System, quedando listo para enviar
información de configuración a la base de datos NetScreen-Security Manager
que reside allí.
Caso 2: La dirección IP es inalcanzable.
En este caso, ambos usuarios realizan tareas de inicialización. El administrador

agrega el dispositivo a través de la UI de NetScreen-Security Manager. El
administrador también determina qué comandos CLI necesita el usuario local y
se los entrega para que éste los ejecute a través de la consola. Entonces, el
dispositivo se conecta automáticamente al sistema de administración
Management System, quedando listo para enviar información de configuración
a la base de datos NetScreen-Security Manager.
24 Administración a través de NetScreen-Security Manager

Caso 3: El dispositivo es una nueva aplicación y contiene los ajustes

predeterminados de fábrica.
En este caso, ambos usuarios realizan tareas de inicialización. El usuario local

puede utilizar un guión de configuración encriptado denominado Configlet, que
genera el administrador de NetScreen-Security Manager. El proceso es el
siguiente:
1. El administrador selecciona la plataforma del dispositivo y la versión de

ScreenOS utilizando el asistente para agregar dispositivos Add Device
Wizard de la UI de NetScreen-Security Manager.
2. El administrador edita el dispositivo e introduce la configuración deseada.
3. El administrador activa el dispositivo.
4. El administrador genera y entrega el archivo Configlet (o los comandos CLI

necesarios, como en el caso 2) al usuario local.
5. El usuario local ejecuta Configlet (o los comandos CLI).
Para obtener más información, consulte la información sobre agregar dispositivos

en el Manual del administrador de NetScreen-Security Manager.
Habilitar, inhabilitar y desactivar el agente de NSM

Para que el dispositivo de seguridad pueda comunicarse con Management System,
es necesario activar el agente de NetScreen-Security Manager (NSM) que reside en
el dispositivo.
Si desea eliminar los ajustes de NetScreen-Security Manager, utilice el comando

unset nsmgmt all. Este comando ajusta el agente de NSM con sus valores
predeterminados iniciales, de modo que actúa como si nunca se hubiera conectado
con NetScreen-Security Manager. Utilice el comando unset nsmgmt all cuando
desee reconfigurar los ajustes de NetScreen-Security Manager.
Para habilitar el agente de NSM en el dispositivo de seguridad, lleve a cabo

cualquiera de los siguientes procedimientos:
WebUI
Configuration > Admin > NSM: Seleccione Enable Communication with
NetScreen-Security Manager (NSM) y después haga clic en Apply.
CLI
set nsmgt enable
save
Para deshabilitar el agente de NSM en el dispositivo, lleve a cabo cualquiera de los

WebUI
Configuration > Admin > NSM: Desactive Enable Communication with
NetScreen-Security Manager (NSM) y después haga clic en Apply.

CLI
unset nsmgt enable
save
Ajustar la dirección IP del servidor principal del sistema de administración (Management

System)
La dirección IP por la cual el agente NSM identifica los servidores externos de
Management System es un parámetro configurable.
En el siguiente ejemplo se establece la dirección IP del servidor principal en

1.1.1.100.
WebUI
Configuration > Admin > NSM: Introduzca los siguientes datos y haga clic
en Apply:
Primary IP Address/Name: 1.1.1.100
CLI
set nsmgmt server primary 1.1.1.100
save
Ajustar la generación de informes de alarmas y de estadísticas

El agente de NSM supervisa los eventos del dispositivo y transmite informes al
sistema de administración (Management System). Esto permite al administrador de
NetScreen-Security Manager ver los eventos de la UI de NetScreen-Security
Manager.
Los eventos registrados por el agente NSM se dividen en las siguientes categorías:
Alarmas, que comunican anomalías o ataques potencialmente peligrosos en el

tráfico, incluyendo los ataques detectados por “Deep Inspection” (inspección
minuciosa).
Eventos del registro, que informan sobre cambios en una configuración del
dispositivo y cambios de escasa relevancia que se producen en el mismo.
Distribución de protocolos, eventos que comunican los mensajes generados por

los siguientes protocolos:
Encabezado de autenticación (AH)
Carga de seguridad encapsulada (ESP)
Encapsulado genérico de enrutamiento (GRE)
Protocolo de mensajes de control de Internet (ICMP)
Primera ruta más corta abierta (OSPF)

Protocolo de control de la transmisión (TCP)
Protocolo de datagramas de usuario (UDP)
Estadísticas, mensajes que comunican la siguiente información estadística.
Attack statistics (Estadísticas de ataques)
Ethernet statistics (Estadísticas de Ethernet)
Traffic flow statistics (Estadísticas del flujo de tráfico)
Policy statistics (Estadísticas de directivas)
En el ejemplo siguiente se activa la transmisión de todos los mensajes de alarma y

de estadísticas a Management System.
WebUI
Configuration > Admin > NSM: Introduzca los siguientes datos y haga clic
en Apply:
Attack Statistics: (seleccione)

Policy Statistics: (seleccione)
Attack Alarms: (seleccione)
Traffic Alarms: (seleccione)
Flow Statistics: (seleccione)
Ethernet Statistics: (seleccione)
Deep Inspection Alarms: (seleccione)
Event Alarms: (seleccione)
CLI
set nsmgmt report statistics attack enable
set nsmgmt report statistics policy enable
set nsmgmt report alarm attack enable
set nsmgmt report alarm traffic enable
set nsmgmt report statistics flow enable
set nsmgmt report statistics ethernet enable
set nsmgmt report alarm idp enable
set nsmgmt report alarm other enable
save

Sincronización de la configuración
Si la configuración de ScreenOS sufre modificaciones desde la última vez que se
sincronizó con NetScreen-Security Manager, el dispositivo de seguridad notifica al
administrador del NetScreen-Security Manager el cambio. Por ejemplo, el
dispositivo envía un mensaje cuando un administrador de dispositivo utiliza la
consola, telnet, SSH, o WebUI para modificar la configuración de un dispositivo de
seguridad. Si se modifica la configuración con una aplicación que no sea
NetScreen-Security Manager, ésta deja de estar sincronizada. El archivo de
configuración NetScreen-Security Manager debe estar sincronizado con el archivo
de configuración del dispositivo de seguridad para que NetScreen-Security Manager
pueda trabajar correctamente. La sincronización se logra cuando se importa el
archivo de configuración a NetScreen-Security Manager. Para obtener información
acerca de los dispositivos de importación, consulte la Guía del administrador de
El ejemplo siguiente muestra el comando que se emplea para visualizar el estado de

la configuración.
Ejemplo: Visualizar al estado de la configuración

En el ejemplo siguiente, visualizará el estado de la sincronización de la
configuración de un dispositivo de seguridad.
WebUI
NOTA: Debe utilizarla interfaz CLI para consultar el estado de la configuración actual.
CLI
get config nsmgmt-dirty
NOTA: Si las aplicaciones que no pertenecen a NetScreen-Security Manager no han

modificado el archivo de configuración, el comando devuelve un espacio en
blanco y en caso contrario, devuelve la palabra “yes”.
Ejemplo: Consultar el hash de configuración

NetScreen-Security Manager utiliza el hash de configuración para verificar la
sincronización de la configuración de un dispositivo de seguridad. En el ejemplo
siguiente, consultará el hash de configuración actual de un sistema virtual
específico.
WebUI
NOTA: Debe utilizarla interfaz CLI para consultar el hash de la configuración actual.
CLI
device-> enter vsys vsys1
device(vsys1)-> get config hash
a26a16cd6b8ef40dc79d5b2ec9e1ab4f
device(vsys1)->
device(vsys1)-> exit

Consultar la marca de hora de configuración

Un dispositivo de seguridad ofrece dos marcas de hora de configuración
(running-config y saved-config). La marca de hora running-config es la que indica
cuándo se ejecutó por última vez el comando set o unset de cada sistema virtual. La
marca de hora saved-config indica cuándo se guardó por última vez la configuración
del dispositivo.
En el siguiente ejemplo, el dispositivo de seguridad consultará las marcas de hora

de las configuraciones que se ejecutaron y se guardaron por última vez del sistema
virtual vsys1:
WebUI
NOTA: Debe utilizar el comando de CLI para consultar las marcas de hora de
configuración que se ejecutaron y se guardaron.
CLI
get config timestamp vsys vsys1
get config saved timestamp
NOTA: Si omite vsys vsys_name en el comando, el dispositivo de seguridad consulta la

marca de hora de configuración del sistema raíz. Si la marca de hora está no
disponible, se mostrará el mensaje “unknown”.
Control del tráfico administrativo

ScreenOS proporciona las siguientes opciones para configurar y administrar el
dispositivo de seguridad:
WebUI: Al seleccionar esta opción se permite a la interfaz recibir tráfico HTTP

de administración a través de la interfaz de usuario web (WebUI).
Telnet: Un programa de emulación de terminales para redes TCP/IP como

Internet; Telnet es una forma muy común de controlar remotamente los
dispositivos de red. Seleccionando esta opción se habilita la posibilidad de
gestión de Telnet.
SSH: El dispositivo de seguridad se puede administrar desde una conexión

Ethernet o a través de un módem de acceso telefónico utilizando Secure
Command Shell (SSH). Se requiere un cliente de SSH compatible con la
versión 1.5 del protocolo SSH. Existen clientes para Windows 95 y posterior,
Windows NT, Linux y UNIX. El dispositivo de seguridad se comunica con el
cliente de SSH a través de su servidor SSH integrado, que proporciona servicios
de configuración y administración de dispositivos. Seleccionando esta opción
se habilita la posibilidad de gestión de SSH.
SNMP: El dispositivo de seguridad admite tanto SNMPv1 como SNMPv2c,

y todos los grupos relevantes de Management Information Base II (MIB II),
según lo definido en RFC-1213. Seleccionando esta opción se habilita la
posibilidad de gestión de SNMP.
Control del tráfico administrativo 29

SSL: Seleccionando esta opción se permite a la interfaz recibir tráfico HTTPS

para la administración segura del dispositivo de seguridad a través de la WebUI.
NetScreen-Security Manager: Seleccionando esta opción se permite a la

interfaz recibir tráfico de NetScreen-Security Manager.
Ping: Si se selecciona esta opción se permite al dispositivo de seguridad

responder a una petición de eco ICMP, o “ping”, que determina si una
determinada dirección IP se encuentra accesible en la red.
Ident-Reset: Servicios como Mail y FTP envían peticiones de identificación. Si

no obtienen ningún acuse de recibo, envían la petición de nuevo. Mientras la
petición se está procesando, los usuarios no pueden acceder. Al activar la
opción Ident-reset, el dispositivo de seguridad envía un aviso de
restablecimiento de TCP en respuesta a una petición de identificación IDENT al
puerto 113 y restablece el acceso bloqueado previamente por una petición de
identificación no atendida.
Para utilizar estas opciones, deben habilitarse en una o más interfaces,

dependiendo de las necesidades administrativas y de seguridad.
Interfaces MGT y VLAN1

Algunos dispositivos de seguridad de Juniper Networks tienen una interfaz física,
Management (MGT), dedicada exclusivamente al tráfico de administración. Puede
utilizar esta interfaz para el tráfico administrativo cuando las interfaces se
encuentren en modo NAT, de ruta, o modo transparente.
En el modo transparente, puede configurar todos los dispositivos de seguridad para

permitir la administración a través de la interfaz lógica, VLAN1. Para permitir que el
tráfico administrativo alcance la interfaz VLAN1, deben activarse las opciones de
administración deseadas tanto en VLAN1 como en las zonas de capa 2 (V1-Trust,
V1-Untrust, V1-DMZ, zona capa 2 definida por el usuario) por las que pasa el tráfico
administrativo para alcanzar VLAN1.
Para mantener el nivel más alto de seguridad, Juniper Networks recomienda limitar
el tráfico administrativo exclusivamente a las interfaces VLAN1 o MGT y el tráfico
de usuarios a las interfaces de la zona de seguridad. Al separar el tráfico
administrativo del tráfico de los usuarios de la red se aumenta significativamente la
seguridad administrativa y se asegura un ancho de banda constante para la
administración.
Ejemplo: Administración a través de la interfaz MGT

En este ejemplo, se establece la dirección IP de la interfaz MGT en 10.1.1.2/24 y se
habilita la interfaz MGT para recibir tráfico administrativo web y SSH.
WebUI
Network > Interfaces > Edit (para mgt): Introduzca los siguientes datos y haga
clic en OK:
Management Services: WebUI, SSH: (seleccione)
30 Control del tráfico administrativo

CLI
set interface mgt ip 10.1.1.2/24
set interface mgt manage web
set interface mgt manage ssh
save
Ejemplo: Administración a través de la interfaz VLAN1

En este ejemplo, se establece la dirección IP de la interfaz VLAN1 en 10.1.1.1/24 y
se habilita la interfaz VLAN1 para recibir tráfico administrativo Telnet y web a través
de la zona V1-Trust.
WebUI
Network > Interfaces > Edit (para VLAN1): Introduzca los siguientes datos y
haga clic en OK:
Management Services: WebUI, Telnet: (seleccione)
Network > Zones > Edit (para V1-Trust): Introduzca los siguientes datos y haga
clic en OK:
Management Services: WebUI, Telnet: (seleccione)
CLI
save
Ajuste de las opciones de la interfaz administrativa

En los dispositivos de seguridad equipados con interfaces físicas múltiples para el
tráfico de red, pero con ninguna interfaz física MGT, se puede dedicar una interfaz
física exclusivamente para la administración, separando totalmente el tráfico
administrativo del tráfico de los usuarios de la red. Por ejemplo, se puede tener
acceso administrativo local al dispositivo a través de una interfaz enlazada a la zona
fiable Trust y realizar la administración remota a través de una interfaz enlazada a
la zona sin confianza Untrust.
En este ejemplo se enlaza ethernet1 a la zona fiable Trust y ethernet3 a la zona sin
confianza Untrust. Se asigna a ethernet1 la dirección IP 10.1.1.1/24 y la dirección IP
de administración 10.1.1.2. (Recuerde que la dirección IP de administración debe
encontrarse en la misma subred que la dirección IP de la interfaz de la zona de
seguridad). También permitirá a ethernet1 recibir tráfico web y Telnet.
A continuación, asigne a ethernet3 la dirección IP 1.1.1.1/24 y bloquee todo el
tráfico administrativo hacia dicha interfaz.

WebUI
Network > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos y
haga clic en Apply:
Zone Name: Trust

Manage IP: 10.1.1.2
Management Services:
WebUI: (seleccione)
SNMP: (anule la selección)
Telnet: (seleccione)
SSL: (anule la selección)
SSH: (anule la selección)
Interface Mode: NAT

Network > Interfaces > Edit (para ethernet3):
Zone Name: Untrust

WebUI: (anule la selección)
SNMP: (anule la selección)
Telnet: (anule la selección)
SSL: (anule la selección)
SSH: (anule la selección)
CLI
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 manage-ip 10.1.1.2
set interface ethernet1 manage web
unset interface ethernet1 manage snmp
set interface ethernet1 manage telnet
unset interface ethernet1 manage ssl
unset interface ethernet1 manage ssh
set interface ethernet1 nat
save
NOTA: Cuando se asocia una interfaz a cualquier zona de seguridad que no sean las
zonas Trust y V1-Trust, todas las opciones de administración se inhabilitan de
forma predeterminada. Por lo tanto, en este ejemplo, no tiene que inhabilitar las
opciones de administración en ethernet3.

Ajuste de las direcciones IP de administración para múltiples interfaces

Cualquier interfaz o subinterfaz física, redundante o agregada que se enlace a una
zona de seguridad puede tener al menos dos direcciones IP:
Una dirección IP de interfaz, para la conexión a una red.
Una dirección IP lógica de administración para recibir el tráfico administrativo.
Cuando un dispositivo de seguridad actúa como unidad de respaldo en un grupo

redundante para la obtención de “HA” (“High Availability” o alta disponibilidad), se
puede acceder a la unidad y configurarla a través de su dirección (o direcciones) IP
de administración.
NOTA: La dirección IP de administración se diferencia de la dirección de VLAN1 en los

dos aspectos siguientes:
Cuando el dispositivo de seguridad se encuentra en modo transparente, la

dirección IP de VLAN1 puede ser el punto final de un túnel VPN, pero la dirección
IP de administración no.
Aunque se pueden definir múltiples direcciones IP de administración (una por

cada interfaz de red), sólo se puede definir una dirección IP de VLAN1 para todo el
sistema.
Si selecciona la opción Manageable en la página de configuración de la interfaz en

WebUI, puede administrar el dispositivo de seguridad a través de la dirección IP de
la interfaz o a través de la dirección IP de administración asociada a esa interfaz.
En la Figura 13 en la página 34 se ilustra este ejemplo, en el cual se enlaza

ethernet2 a la zona DMZ y ethernet3 a la zona Untrust. Se trata de establecer las
opciones de administración en cada interfaz para proporcionar acceso a los
diversos tipos de tráfico administrativo. Usted permite el acceso HTTP y Telnet a
través de ethernet2 a un grupo de administradores locales en la zona DMZ, y el
acceso SNMP a través de ethernet3 para la supervisión central de un dispositivo
desde un sitio remoto. Tanto ethernet2 como ethernet3 tienen una dirección IP de
administración a la que se dirige el tráfico administrativo. También puede
establecer una ruta que dirija el tráfico SNMP autogenerado fuera de ethernet3 al
enrutador externo en 1.1.1.250.

Figura 13: Ajuste de las direcciones IP de administración para múltiples interfaces

Zona Untrust ethernet3
IP: 1.1.1.1/24
IP de administración:
1.1.1.2 Estación de
Internet
administración
SNMP
Enrutador 1.1.1.250
Administradores locales
Zona DMZ
ethernet2
IP: 1.2.2.1/24
IP de administración: 1.2.2.2
LAN
Zona Trust
WebUI
Network > Interfaces > Edit (ethernet2): Introduzca los siguientes datos y
haga clic en OK:
Zone Name: DMZ

Manage IP: 1.2.2.2
WebUI: (seleccione)
Telnet: (seleccione)
haga clic en OK:
Zone Name: Untrust

Manage IP: 1.1.1.2
SNMP: (seleccione)

CLI
set interface ethernet2 zone dmz
set interface ethernet2 manage web
set interface ethernet2 manage telnet
set interface ethernet3 manage snmp
save
Niveles de administración
Los dispositivos de seguridad de Juniper Networks admiten múltiples usuarios
administrativos. Cualquier cambio en la configuración realizado por un
administrador queda registrado por el dispositivo de seguridad con la siguiente
información:
El nombre del administrador que efectuó el cambio
La dirección IP desde la que se realizó el cambio
La fecha y hora en la que se realizó la modificación
Existen varios niveles de usuarios administrativos. La disponibilidad de algunos de

estos niveles depende del modelo de dispositivo de seguridad de Juniper Networks.
En las secciones siguientes se enumeran todos los niveles de administrador y los
privilegios de cada uno. Un administrador únicamente dispone de estos privilegios
después de haber iniciado correctamente una sesión indicando un nombre de
usuario y una contraseña válidos.
Administrador raíz
El administrador raíz tiene privilegios administrativos completos. Hay solamente un
administrador raíz por cada dispositivo de seguridad. El administrador raíz tiene los
siguientes privilegios:
Administra el sistema raíz del dispositivo de seguridad
Agrega, elimina y administra a los demás administradores
Establece y administra los sistemas virtuales, y les asigna interfaces físicas y

lógicas
Crea, elimina y administra enrutadores virtuales (VRs)
Agrega, elimina y administra zonas de seguridad
Asigna interfaces a zonas de seguridad
Realiza la recuperación de activos
Cambia el dispositivo al modo FIPS
Niveles de administración 35
Restablece los ajustes predeterminados del dispositivo
Actualiza el firmware
Carga los archivos de configuración
Borra todas las sesiones activas de un administrador determinado o de todos

los administradores activos
Administrador de lectura/escritura
El administrador de lectura/escritura tiene los mismos privilegios que el
administrador raíz, pero no puede crear, modificar ni eliminar otros usuarios con
permisos de administrador. El administrador de lectura/escritura tiene los
privilegios siguientes:
Crea sistemas virtuales y asigna a cada uno un administrador del sistema

virtual
Supervisa cualquier sistema virtual
Realiza un seguimiento estadístico (un privilegio que no se puede delegar en un

administrador del sistema virtual)
Administrador de sólo lectura

El administrador de sólo lectura solamente tiene privilegios de visualización con
WebUI y puede ejecutar exclusivamente los comandos CLI get y ping. El
administrador de sólo lectura tiene los privilegios siguientes:
Privilegios de sólo lectura en el sistema raíz, con los cuatro comandos

siguientes: enter, exit, get y ping
Privilegios de sólo lectura en sistemas virtuales
Administrador de sistema virtual

Algunos dispositivos de seguridad pueden trabajar con sistemas virtuales. Cada
sistema virtual (vsys) es un dominio de seguridad único que puede ser administrado
por administradores del sistema virtual con privilegios aplicables solamente a dicho
vsys. Los administradores de sistemas virtuales administran independientemente
los sistemas virtuales a través de la CLI o WebUI. En cada vsys, el administrador del
sistema virtual tiene los privilegios siguientes:
Crea y edita auth, IKE, L2TP, XAuth y usuarios de clave manual
Crea y edita servicios
Crea y edita directivas
Crea y edita direcciones
Crea y edita VPN
Modifica la contraseña de inicio de sesión del administrador del sistema virtual
36 Niveles de administración
Crea y administra zonas de seguridad
Agrega y elimina administradores de sólo lectura del sistema virtual
Administrador de sólo lectura del sistema virtual

Un administrador de sólo lectura del sistema virtual dispone del mismo conjunto de
privilegios que un administrador de sólo lectura, pero solamente dentro de un
sistema virtual determinado. Un administrador de sólo lectura del sistema virtual
tiene privilegios de visualización en su vsys particular a través de WebUI y sólo
puede ejecutar los comandos CLI enter, exit, get y ping en su propio vsys.
NOTA: Para obtener más información sobre sistemas virtuales, consulte “Sistemas
virtuales” en la página 10-1.
Definición de usuarios con permisos de administrador

El administrador raíz es el único que puede crear, modificar y eliminar usuarios con
permisos de administrador. En el ejemplo siguiente, quien vaya a ejecutar el
procedimiento debe ser administrador raíz.
Ejemplo: Agregar un administrador de sólo lectura

En este ejemplo, usted, como administrador raíz, agregará un administrador de
sólo lectura llamado Roger con la contraseña 2bd21wG7.
WebUI
Configuration > Admin > Administrators > New: Introduzca los siguientes
Name: Roger
New Password: 2bd21wG7
Confirm New Password: 2bd21wG7
Privileges: Read-Only (seleccione)
NOTA: La contraseña puede tener una longitud de hasta 31 caracteres; el sistema

distingue entre mayúsculas y minúsculas.
CLI
set admin user Roger password 2bd21wG7 privilege read-only
save
Ejemplo: Modificar un administrador

En este ejemplo, usted, como administrador raíz, cambia los privilegios de Roger
de sólo lectura a lectura/escritura.
WebUI
Configuration > Admin > Administrators > Edit (para Roger): Introduzca los
Definición de usuarios con permisos de administrador 37

Name: Roger
New Password: 2bd21wG7
Confirm New Password: 2bd21wG7
Privileges: Read-Write (seleccione)
CLI
unset admin user Roger
set admin user Roger password 2bd21wG7 privilege all
save
Ejemplo: Eliminar un administrador

En este ejemplo, usted, como administrador raíz, elimina el usuario con permisos
de administrador Roger.
WebUI
Configuration > Admin > Administrators: Haga clic en Remove para Roger en
la columna Configure.
CLI
unset admin user Roger
save
Ejemplo: Configurar las cuentas del administrador para las conexiones de acceso
telefónico
Algunos dispositivos admiten una conexión de módem para las situaciones de
recuperación de desastres de conexión telefónica. Puede configurar cuentas
fiduciarias para la interfaz, para el módem o tanto para la interfaz como para el
módem. Esta sección describe los dos tipos de cuentas fiduciarias:
Interfaz fiduciaria
Una interfaz fiduciaria únicamente tiene acceso a la WebUI y tiene acceso

restringido a la asignación de métodos de señalización y direcciones IP para la
interfaz Untrust principal.
Para dispositivos con interfaces ADSL, una interfaz fiduciaria tiene control
sobre las siguientes características:
Características de la capa 1: VPI/VCI, modo de multiplexado, RFC1483

enlazado o enrutado
Métodos de señalización de capa 2 (PPPoE r PPPoA y sus parámetros)
Los métodos de asignación de dirección IP (definidas estáticamente por el

administrador o adquiridas dinámicamente desde el circuito a través de
PPPoE o PPPoA).
Unicamente para los dispositivos con interfaces ethernet, una interfaz

fiduciaria puede controlar cómo se asigna la dirección IP de la interfaz
(definidas estadísticamente por el administrador o adquiridas dinámicamente
desde el circuito por medio del DHCP o PPPoE).
38 Definición de usuarios con permisos de administrador

Módem fiduciario
Un módem fiduciario únicamente tiene acceso a la WebUI y tiene acceso

restringido a los ajustes del módem y al ISP para la interfaz de serie. Un
módem fiduciario puede crear, modificar y eliminar las definiciones del
módem para satisfacer sus necesidades específicas y puede crear, modificar y
eliminar los ajustes para ISP1 y ISP2. Un módem fiduciario puede visualizar las
configuraciones para ISP3 e ISP4, así como también puede examinar la
conectividad de cualquier número telefónico y ISP definido.
Puede visualizar todas las cuentas del administrador al introducir el comando get
admin user o puede visualizar únicamente las cuentas fiduciarias al introducir el
comando get admin user trustee.
En el ejemplo siguiente configurará una cuenta fiduciaria de módem de

lectura/escritura para Richard Brockie. El nombre de usuario será rbrockie y su
contraseña será !23fb.
WebUI
Configuration > Admin > Administrators
CLI
set admin user rbrockie password !23fb privilege all
set admin user rbrockie trustee modem
Ejemplo: Borrar una sesión de administrador

En este ejemplo, usted, como administrador raíz, termina todas las sesiones activas
del usuario administrador Roger. Al ejecutar el comando siguiente, el dispositivo de
seguridad cierra todas las sesiones y cierra automáticamente la sesión de Roger en
el sistema.
WebUI
NOTA: Debe utilizar la interfaz CLI para eliminar las sesiones de administración.
CLI
clear admin name Roger
save
Definición de usuarios con permisos de administrador 39

Tráfico administrativo seguro

Para asegurar el dispositivo de seguridad durante la configuración, realice los pasos
siguientes:
1. En la WebUI, cambie el puerto de administración.
Consulte “Cambiar el número de puerto” en la página 41.
2. Cambie el nombre de usuario y la contraseña de acceso administrativo.
Consulte “Cambio de nombre y contraseña de inicio de sesión del

administrador” en la página 41.
3. Defina las direcciones IP que tendrán los usuarios administradores en el equipo

cliente de administración.
Consulte “Restricción del acceso administrativo” en la página 44.
4. Desactive cualquier opción innecesaria de servicios de administración de la

interfaz.
Consulte “Control del tráfico administrativo” en la página 29.
5. Desactive las opciones “ping” e “ident-reset” en las interfaces, ya que ambas

responden a las peticiones iniciadas por interlocutores desconocidos y pueden
revelar información sobre su red:
WebUI
Network > Interfaces > Edit (para la interfaz que desee editar): Introduzca las
siguientes opciones de servicio, después haga clic en OK:
Ping: Seleccionando esta opción se permite al dispositivo de seguridad

responder a una petición de eco ICMP o “ping”, que determina si una
dirección IP específica se encuentra desde el equipo.
Ident-Reset: Si un servicio, como el correo electrónico o FTP, envía una

solicitud de identificación y no recibe confirmación, volverá a enviar la
solicitud. Mientras dicha solicitud se encuentre en curso, el acceso de
usuario estará inhabilitado. Si la casilla de verificación Ident-Reset está
habilitada, el dispositivo de seguridad restaurará automáticamente el
acceso de usuario.
CLI
unset interface interfaz manage ping
unset interface interfaz manage ident-reset
40 Tráfico administrativo seguro

Cambiar el número de puerto

Cambiar el número de puerto utilizado por el dispositivo de seguridad para
escuchar el tráfico administrativo de HTTP aumenta la seguridad. El ajuste
predeterminado es el puerto 80, que es el puerto estándar para el tráfico HTTP.
Cuando haya cambiado el número de puerto, deberá introducir el nuevo número en
el campo URL de su explorador cuando intente comunicarse con el dispositivo de
seguridad. (En el ejemplo siguiente, el administrador debe escribir
http://188.30.12.2:15522).
En este ejemplo, la dirección IP de la interfaz asociada a la zona Trust es

10.1.1.1/24. Para administrar el dispositivo de seguridad a través de la WebUI en
esta interfaz, debe utilizar HTTP. Para aumentar la seguridad de la conexión HTTP,
cambie el número de puerto HTTP de 80 (el predeterminado) a 15522.
WebUI
Configuration > Admin > Management: En el campo HTTP Port, introduzca
15522 y después haga clic en Apply.
CLI
set admin port 15522
save
Cambio de nombre y contraseña de inicio de sesión del administrador

De forma predeterminada, el nombre de inicio de sesión preajustado en fábrica
para los dispositivos de seguridad es netscreen. La contraseña inicial también es
netscreen. Dado que ambos han sido ampliamente divulgados, Juniper Networks
recomienda cambiar inmediatamente el nombre de inicio de sesión y la
contraseña. Tanto el nombre de inicio de sesión como la contraseña distinguen
entre mayúsculas y minúsculas. Pueden contener cualquier carácter que pueda
introducirse mediante el teclado, exceptuando el signo de interrogación ? y las
comillas “. Anote el nombre de inicio de sesión y la contraseña definitivos en un
lugar seguro.
ADVERTENCIA: Asegúrese de memorizar su nueva contraseña. Si la olvida, deberá

restablecer los ajustes de fábrica del dispositivo de seguridad y perderá todos sus
ajustes de configuración. Para obtener más información, consulte
“Restablecimiento del dispositivo con los ajustes predeterminados de fábrica” en
la página 44.
Los usuarios administradores del dispositivo de seguridad se pueden autenticar

usando las bases de datos internas o un servidor de autenticación externo. Cuando
el usuario administrador inicia una sesión en el dispositivo de seguridad, éste
comprueba en primer lugar las bases de datos internas locales para autenticarlo. Si
las bases de datos no contienen ninguna entrada y hay conectado un servidor de
autenticación externo, comprueba si éste contiene en su base de datos una entrada
coincidente. Una vez que el usuario administrador se ha conectado con éxito a un
servidor de autenticación externo, el dispositivo de seguridad conserva localmente
su estado de inicio de sesión.
Tráfico administrativo seguro 41

NOTA: Para la autenticación de usuarios administradores, Juniper Networks es

compatible con servidores RADIUS, SecurID y LDAP. (Para obtener más
información, consulte “Usuarios con permisos de administrador” en la
página 9-2). Aunque la cuenta del administrador raíz debe almacenarse en la base
de datos local, se pueden almacenar usuarios administradores de lectura/escritura
de nivel raíz y de sólo lectura de nivel raíz en un servidor de autenticación
externo. Para almacenar usuarios administradores de nivel raíz y de nivel vsys en
un servidor de autenticación externo y consultar sus privilegios, en el servidor, que
debe ser RADIUS, deberá cargarse el archivo netscreen.dct.
Para obtener más información sobre los niveles de usuarios administradores,

consulte “Niveles de administración” en la página 35. Para obtener más
información sobre el uso de servidores de autenticación externos, consulte
“Servidores de autenticación externos” en la página 9-17.
Cuando el administrador raíz cambia cualquier atributo del perfil de un usuario

administrador (nombre de usuario, contraseña o privilegios), cualquier sesión
administrativa que el administrador tenga abierta en ese momento terminará
automáticamente. Si el administrador raíz cambia cualquiera de estos atributos
para sí mismo o si un administrador de lectura/escritura de nivel raíz o de
lectura/escritura de nivel vsys cambia su propia contraseña, todas las sesiones que
el usuario en cuestión tenga abiertas en ese momento se cerrarán, salvo la sesión
desde la que realizó el cambio.
NOTA: El comportamiento de una sesión HTTP o HTTPS en la que se utiliza WebUI es

diferente. Dado que HTTP no admite conexiones persistentes, cualquier cambio
que realice en su propio perfil de usuario cerrará automáticamente todas las
sesiones que tenga abiertas en ese momento.

un usuario administrador
En este ejemplo, usted, como administrador raíz, cambiará el nombre de inicio de
sesión del administrador de lectura/escritura “John” a “Smith” y su contraseña de
“xL7s62a1” a “3MAb99j2”.
NOTA: En lugar de utilizar palabras reales como contraseñas, que resultan fáciles de
acertar o descubrir mediante un ataque de diccionario, puede utilizar una cadena
aparentemente aleatoria de números y letras. Para crear tal cadena que pueda
recordar fácilmente, componga una oración y utilice la primera letra de cada
palabra. Por ejemplo, la frase “Carlos cumplirá 6 años el 21 de noviembre”
resultará en la contraseña “Cc6ae21dn”.
Para obtener más información, consulte “Niveles de administración” en la

página 35.

WebUI
Configuration > Admin > Administrators > Edit (para John): Introduzca los
Name: Smith
New Password: 3MAb99j2
Confirm New Password: 3MAb99j2
CLI
unset admin user John
set admin user Smith password 3MAb99j2 privilege all
save
Ejemplo: Cambiar su propia contraseña

Los usuarios administradores con privilegios de lectura/escritura pueden cambiar su
propia contraseña de administrador, pero no su nombre de inicio de sesión. En este
ejemplo, un administrador con privilegios de lectura/escritura y el nombre de inicio
de sesión “Smith” cambia su contraseña de “3MAb99j2” a “ru494Vq5”.
WebUI
Configuration > Admin > Administrators > Edit (para la primera entrada):
Name: Smith
New Password: ru494Vq5
Confirm New Password: ru494Vq5
CLI
set admin password ru494Vq5
save

raíz
En algunas empresas, una persona suele realizar la configuración inicial del
dispositivo como administrador raíz, pero luego otra persona asume ese papel para,
en adelante, administrar el dispositivo. Para evitar que el siguiente administrador
raíz utilice contraseñas cortas mucho más fáciles de desencriptar, el administrador
raíz inicial puede establecer un requisito de longitud mínima de la contraseña del
administrador raíz, eligiendo cualquier número entre 1 y 31.
Puede establecer la longitud mínima de la contraseña si es el administrador raíz y

su propia contraseña cumple el requisito de longitud mínima que está intentando
establecer. De lo contrario, el dispositivo de seguridad muestra un mensaje del
error.
Para especificar una longitud mínima para la contraseña del administrador raíz,
escriba el siguiente comando CLI:
set admin password restrict length número

Restablecimiento del dispositivo con los ajustes predeterminados de fábrica

Si se pierde la contraseña de administrador, puede utilizar el procedimiento
siguiente para restablecer los ajustes predeterminados del dispositivo de seguridad.
Las configuraciones se perderán, pero podrá acceder de nuevo al dispositivo. Para
realizar esta operación, es necesario que realice una conexión de consola, la cual se
describe detalladamente en el Manual de referencia de la CLI ScreenOS: Descripciones
del comando IPv4 y la documentación para su dispositivo.
NOTA: De forma predeterminada, la función de restablecimiento del dispositivo está

habilitada. Puede desactivarla con el comando unset admin device-reset.
Asimismo, cuando el dispositivo de seguridad se encuentra en modo FIPS, la
función de restablecimiento se desactiva automáticamente.
1. En la pantalla de inicio de sesión, introduzca el número de serie del dispositivo.
2. Cuando se le solicite la contraseña, introduzca de nuevo el número de serie.
Aparecerá el siguiente mensaje:
!!!! Lost Password Reset !!!! You have initiated a command to reset the device
to factory defaults, clearing all current configuration, keys and settings. Would
you like to continue? y/n
3. Presione la tecla y.
Aparecerá el siguiente mensaje:
!! Reconfirm Lost Password Reset !! If you continue, the entire configuration of

the device will be erased. In addition, a permanent counter will be
incremented to signify that this device has been reset. This is your last chance
to cancel this command. If you proceed, the device will return to factory
default configuration, which is: System IP: 192.168.1.1; username:
netscreen; password: netscreen. Would you like to continue? y/n
4. Presione la tecla y para restablecer el dispositivo. Ahora podrá iniciar la sesión

utilizando netscreen como el nombre de usuario y contraseña
predeterminados.
Restricción del acceso administrativo

Los dispositivos de seguridad se pueden administrar desde una o varias direcciones
de una subred. De forma predeterminada, cualquier host conectado a la interfaz
fiable puede administrar un dispositivo de seguridad. Para restringir esta posibilidad
en estaciones de trabajo específicas, es necesario configurar direcciones IP de
clientes de administración.


trabajo
En este ejemplo, el administrador en la estación de trabajo con la dirección
IP 172.16.40.42 es el único autorizado para administrar el dispositivo de seguridad.
WebUI
Configuration > Admin > Permitted IPs: Introduzca los siguientes datos y haga
clic en Add:
CLI
set admin manager-ip 172.16.40.42/32
save
Ejemplo: Restringir la administración a una subred

En este ejemplo, se designa al grupo de administradores con las estaciones de
trabajo de la subred 172.16.40.0/24 para administrar un dispositivo de seguridad.
WebUI
Configuration > Admin > Permitted IPs: Introduzca los siguientes datos y haga
clic en Add:
CLI
set admin manager-ip 172.16.40.0 255.255.255.0
save
Restringir el administrador raíz a acceder desde la consola

También puede obligar a que el administrador raíz inicie su sesión en el dispositivo
de seguridad exclusivamente a través de la consola. Esta restricción requiere que el
administrador raíz tenga acceso físico al dispositivo al que necesita conectarse,
impidiéndose de este modo que usuarios no autorizados puedan iniciar sesiones
remotamente como administrador raíz. Una vez establecida esta restricción, el
dispositivo denegará el acceso a cualquier persona que intente iniciar una sesión
como administrador raíz por otros medios, como WebUI, Telnet o SSH, incluso
aunque en la interfaz de ingreso estén habilitadas las opciones de administración
correspondientes a esos medios.
Para restringir el acceso del administrador raíz exclusivamente a través de la

consola, ejecute el comando siguiente:
set admin root access console

Túneles de VPN para tráfico administrativo

Puede utilizar túneles de red privada virtual (VPN) para hacer segura la
administración remota de un dispositivo de seguridad desde una dirección IP fija o
asignada dinámicamente. Usando un túnel VPN puede proteger cualquier tipo de
tráfico, tal como NetScreen-Security Manager, HTTP, Telnet o SSH. (Para obtener
información sobre cómo crear un túnel VPN para hacer seguro el tráfico
autogenerado, como los informes de NetScreen-Security Manager, los informes
syslog o las capturas SNMP, consulte “Túneles VPN para tráfico autogenerado” en la
página 83).
Los dispositivos de seguridad de Juniper Networks admiten dos tipos de

configuraciones de túneles de VPN:
VPN basadas en rutas: El dispositivo de seguridad utiliza entradas de la tabla

de rutas para dirigir el tráfico a las interfaces de túnel, asociadas a los túneles
de VPN.
VPN basadas en directivas: El dispositivo de seguridad utiliza los nombres de

los túneles de VPN indicados expresamente en las directivas para dirigir el
tráfico a través de dichos túneles.
Por cada tipo de configuración de túnel VPN existen los siguientes tipos de túnel
VPN:
Clave manual: El usuario establece manualmente los tres elementos que

definen una asociación de seguridad (SA) en ambos extremos del túnel: un
índice de parámetros de seguridad (SPI), una clave de encriptación y una clave
de autenticación. Para modificar cualquier elemento de la SA, debe introducirse
manualmente en ambos extremos del túnel.
AutoKey IKE con clave previamente compartida: Una o dos claves secretas
previamente compartidas (una para la autenticación y otra para la encriptación)
funcionan como valores de inicialización. El protocolo IKE genera con ellas un
juego de claves simétricas en ambos extremos del túnel; es decir, se utiliza la
misma clave para encriptar y desencriptar. Estas claves se regeneran
automáticamente a intervalos predeterminados.
AutoKey IKE con certificados: Utilizando la infraestructura de claves públicas

(PKI), los participantes en ambos extremos del túnel utilizan un certificado
digital (para la autenticación) y un par de claves pública/privada RSA (para la
encriptación). La encriptación es asimétrica; es decir, una de las claves del par
se utiliza para encriptar y la otra para desencriptar.
NOTA: Para obtener una descripción completa de los túneles VPN, consulte el Volumen 5:
Redes privadas virtuales. Para obtener más información sobre NetScreen-Remote,
consulte el NetScreen-Remote VPN Client Administrator Guide (Manual del
administrador de Cliente VPN de NetScreen-Remote).

Si utiliza una configuración de VPN basada en directivas, debe crear una entrada en
la libreta de direcciones con la dirección IP de una interfaz de cualquier zona, salvo
la que está asociada a la interfaz de salida. Puede entonces utilizarla como dirección
de origen en las directivas que se refieren al túnel VPN. Esta dirección también sirve
como dirección de entidad final para el interlocutor IPSec remoto. Si está utilizando
una configuración VPN basada en rutas, esta entrada en la libreta de direcciones es
innecesaria.

en rutas
En la Figura 14 se ilustra un ejemplo en el que se configura un túnel VPN de clave
manual basado en rutas para proporcionar confidencialidad al tráfico
administrativo. El túnel se extiende desde el cliente VPN de NetScreen-Remote que
se ejecuta en una estación de trabajo de administrador en la dirección 10.1.1.56
hasta ethernet1 (10.1.1.1/24). Tanto la estación de trabajo del administrador como
ethernet1 se encuentran en la zona Trust. El túnel se denomina “tunnel-adm”.
Creará una interfaz de túnel sin numerar, denomínela “tunnel 1” y asóciela a la
zona Trust y al túnel VPN “tunnel-adm”.
El dispositivo de seguridad utiliza la dirección IP interna configurada en el cliente

NetScreen-Remote (10.10.10.1) como dirección de destino para apuntar más allá de
la dirección 10.1.1.56 de la puerta de enlace del interlocutor. Defina una ruta hacia
10.10.10.1/32 a través de “tunnel 1”. No se requiere ninguna directiva por las dos
razones siguientes:
El túnel VPN protege por sí mismo el tráfico administrativo que termina en el

dispositivo de seguridad, en lugar de pasar por el dispositivo a otra zona de
seguridad.
Se trata de una VPN basada en rutas, lo que significa que la consulta de rutas
(no la consulta de directivas) vincula la dirección de destino a la interfaz del
túnel, que está asociada al túnel VPN correspondiente.
NOTA: Compare este ejemplo con “Administración a través de un túnel VPN de clave
manual basado en directivas” en la página 51.
NetScreen-Remote utiliza la dirección IP de ethernet3 (1.1.1.1) como dirección de

destino para apuntar más allá de la puerta de enlace remota en 10.1.1.1. La
configuración de NetScreen-Remote especifica el tipo de identificador del
interlocutor remoto como “IP address” y el protocolo como “All”.

Figura 14: Administración a través de un túnel VPN de clave manual basado en rutas
NetScreen-Remote ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24

LAN Internet
VPN de clave manual
Túnel “tunnel-adm”
Admin tunnel.1
10.1.1.56 no numerado
(dirección IP estática)
10.10.10.1/32
(dirección IP interna)
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

clic en OK:
Tunnel Interface Name: Tunnel.1

Zone (VR): Trust (trust-vr)
Unnumbered: (seleccione)
Interface: ethernet1(trust-vr)
NOTA: La interfaz de túnel no numerada toma prestada la dirección IP de la interfaz de la

zona de seguridad especificada.

2. VPN
VPNs > Manual Key > New: Introduzca los siguientes datos y haga clic en OK:
VPN Tunnel Name: tunnel-adm

Gateway IP: 10.1.1.56
Security Index (HEX Number): 5555 (Local) 5555 (Remote)
Outgoing Interface: ethernet1
ESP-CBC: (seleccione)
Encryption Algorithm: DES-CBC
Generate Key by Password: netscreen1
Authentication Algorithm: MD5
Bind to Tunnel Interface: (seleccione), Tunnel.1
NOTA: Dado que NetScreen-Remote transforma las contraseñas en claves de forma

diferente a otros productos de Juniper Networks, después de configurar el túnel
realice el siguiente procedimiento: (1) Regrese al cuadro de diálogo Manual Key
Configuration (haga clic en Edit en la columna Configure de “tunnel-adm”);
(2) copie las claves hexadecimales generadas y (3) utilice estas claves al configurar
el extremo NetScreen-Remote del túnel.
3. Ruta

Interface: Tunnel.1
CLI
1. Interfaces
set interface tunnel.1 ip unnumbered interface ethernet1
NOTA: La interfaz de túnel no numerada toma prestada la dirección IP de la interfaz de la

zona de seguridad especificada.
2. VPN
set vpn tunnel-adm manual 5555 5555 gateway 10.1.1.56 outgoing ethernet1 esp
des password netscreen1 auth md5 password netscreen2
set vpn tunnel-adm bind interface tunnel.1


realice el siguiente procedimiento: (1) Introduzca get vpn admin-tun; (2) copie las
claves hexadecimales generadas por “netscreen1” y “netscreen2”; (3) utilice estas
claves hexadecimales al configurar el extremo NetScreen-Remote del túnel.
3. Ruta
set vrouter trust-vr route 10.10.10.1/32 interface tunnel.1
save
Editor de directivas de seguridad “NetScreen-Remote Security Policy Editor”

1. Haga clic en Options > Global Policy Settings y seleccione la casilla de
verificación Allow to Specify Internal Network Address.
2. Haga clic en Options > Secure > Specified Connections.
3. Haga clic en Add a new connection y escriba Admin junto al icono de nueva
conexión que aparece.
4. Configure las opciones de conexión:
Connection Security: Secure

Remote Party Identity and Addressing:
ID Type: IP Address, 1.1.1.1
Protocol: All
Connect using Secure Gateway Tunnel: (seleccione)
5. Haga clic en el signo MÁS, que se ubica a la izquierda del icono de UNIX para
ampliar la directiva de la conexión.
6. Haga clic en My Identity en la lista desplegable Select Certificate, seleccione

None y en Internal Network IP Address escriba 10.10.10.1.
7. Haga clic en Security Policy y seleccione Use Manual Keys.
8. Haga clic en el signo MÁS situado a la izquierda del icono “Security Policy” y
luego haga clic en el signo MÁS a la izquierda de “Key Exchange (Phase 2)” para
ampliar más aún la directiva.
9. Haga clic en Proposal 1, a continuación seleccione los siguientes protocolos

IPSec:
Encapsulation Protocol (ESP): (seleccione)

Encrypt Alg: DES
Hash Alg: MD5
Encapsulation: Tunnel
10. Haga clic en Inbound Keys y escriba 5555 en el campo “Security Parameters
Index”.

11. Haga clic en Enter Key, escriba lo siguiente y después haga clic en OK:
Choose key format: Binary

ESP Encryption Key: dccbee96c7e546bc
ESP Authentication Key: dccbe9e6c7e546bcb0b667794ab7290c
NOTA: Éstas son las dos claves generadas que copió después de configurar el dispositivo
de seguridad.
12. Haga clic en Outbound Keys y escriba 5555 en el campo “Security Parameters
Index”.

14. Haga clic en Save.

en directivas
En la Figura 15 se ilustra un ejemplo en el que se configura un túnel VPN de clave
manual basado en directivas para el tráfico administrativo. El túnel se extiende
desde el cliente VPN de NetScreen-Remote que se ejecuta en una estación de
trabajo de administrador en la dirección 10.1.1.56 hasta ethernet1 (10.1.1.1/24).
Tanto la estación de trabajo del administrador como ethernet1 se encuentran en la
zona Trust. El túnel se llamará “tunnel-adm” y se asociará a la zona Trust.
El dispositivo de seguridad utiliza la dirección IP interna configurada en

NetScreen-Remote (10.10.10.1) como dirección de destino para apuntar más allá de
la dirección 10.1.1.56 de la puerta de enlace del interlocutor. También se definirá
una entrada en la libreta de direcciones de la zona Trust especificando
10.10.10.1/32 y otra entrada en la libreta de la zona Untrust especificando la
dirección IP de ethernet3. Aunque la dirección de la interfaz ethernet3 es
1.1.1.1/24, la dirección que se creará tendrá una máscara de red de 32 bits:
1.1.1.1/32. Esta dirección y la dirección interna de la estación de trabajo del
administrador se utilizarán en la directiva que se creará con relación al túnel
“tunnel-adm”. La directiva es necesaria porque se trata de una VPN basada en
directivas, lo que quiere decir que la determinación de directivas (no la consulta de
rutas) vincula la dirección de destino a la interfaz del túnel VPN correspondiente.
También se debe definir una ruta hacia 10.10.10.1/32 a través de ethernet1.
NOTA: Compare este ejemplo con “Administración a través de un túnel VPN de clave
manual basado en rutas” en la página 47.
NetScreen-Remote utiliza la dirección IP 1.1.1.1 como la dirección de destino para

apuntar más allá de la puerta de enlace remota en 10.1.1.1. La configuración del
túnel de NetScreen-Remote especifica el tipo de identificador del interlocutor
remoto como dirección IP y el protocolo como “All”.

Figura 15: Administración a través de un túnel VPN de clave manual basado en directivas

10.1.1.1/24 1.1.1.1/24
Admin
10.1.1.56 LAN
(dirección IP Internet
estática) VPN de clave manual
Túnel “tunnel-adm”
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Direcciones
Policy > Policy Elements > Addresses > Lists > New: Introduzca los
Address Name: Untrust-IF

Zone: Untrust
Address Name: admin

Zone: Trust

3. VPN
VPN Tunnel Name: tunnel-adm

Gateway IP: 10.1.1.56
Security Index (HEX Number): 5555 (Local) 5555 (Remote)
Encryption Algorithm: DES-CBC
Authentication Algorithm: MD5

realice el siguiente procedimiento: (1) Regrese al cuadro de diálogo Manual Key
Configuration (haga clic en Edit en la columna Configure de “tunnel-adm”);
(2) copie las claves hexadecimales generadas y (3) utilice estas claves al configurar
el extremo NetScreen-Remote del túnel.
4. Ruta

Interface: ethernet1
5. Directivas
Policies > (From: Trust, To: Untrust) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), admin
Address Book Entry: (seleccione), Untrust-IF
Service: Any
Action: Tunnel
Tunnel:
VPN: tunnel-adm
CLI
1. Interfaces
2. Direcciones
set address trust admin 10.10.10.1/32
set address untrust Untrust-IF 1.1.1.1/32

3. VPN
set vpn tunnel-adm manual 5555 5555 gateway 10.1.1.56 outgoing ethernet1 esp
des password netscreen1 auth md5 password netscreen2

realice el siguiente procedimiento: (1) Introduzca get vpn admin-tun; (2) copie las
claves hexadecimales generadas por “netscreen1” y “netscreen2”; (3) utilice estas
claves hexadecimales al configurar el extremo NetScreen-Remote del túnel.
4. Ruta
set vrouter trust-vr route 10.10.10.1/32 interface ethernet1
5. Directivas
set policy top from trust to untrust admin Untrust-IF any tunnel vpn tunnel-adm
set policy top from untrust to trust Untrust-IF admin any tunnel vpn tunnel-adm
save
Editor de directivas de seguridad “NetScreen-Remote Security Policy Editor”

2. Haga clic en Add a new connection y escriba Admin junto al icono de nueva
conexión que aparece.

Protocol: All
4. Haga clic en el signo MÁS, que hay situado a la izquierda del icono de UNIX
para ampliar la directiva de la conexión.
5. Haga clic en My Identity y en la lista desplegable Select Certificate, elija None.
6. Haga clic en Security Policy y seleccione Use Manual Keys.
7. Haga clic en el símbolo MÁS situado a la izquierda del icono “Security Policy” y
luego en el símbolo MÁS a la izquierda de “Key Exchange (Phase 2)” para
ampliar más aún la directiva.
8. Haga clic en Proposal 1 y seleccione los siguientes protocolos IPSec:

Encrypt Alg: DES
Hash Alg: MD5
9. Haga clic en Inbound Keys y escriba 5555 en el campo “Security Parameters

Index”.

10. Haga clic en Enter Key, escriba lo siguiente y haga clic en OK:

NOTA: Éstas son las dos claves generadas que copió después de configurar el dispositivo
de seguridad.
11. Haga clic en Outbound Keys y escriba 5555 en el campo “Security Parameters
Index”.

13. Haga clic en Save.
Directiva de contraseñas
La función de directiva de contraseñas le permite implementar una longitud
mínima y un esquema de complejidad para las contraseñas del administrador
(admin) y usuario autenticado (auth). La función de directiva está diseñada para
utilizarse en una base de datos local y por lo tanto es útil en ambientes en los que el
directorio Windows o RADIUS no está disponible para proporcionar el
cumplimiento de la directiva de contraseñas centralizadas.
Establecimiento de una directiva de contraseñas

Puede crear una directiva de contraseñas para requerir que las contraseñas de
administrador y autenticada cumplan con una o ambas de las siguientes
características:
Longitud mínima
Complejidad
El rango para la longitud mínima de contraseña es de 1 a 32 caracteres. Utilice el

siguiente comando para crear una directiva de contraseñas que requiera una
longitud mínima de 8 caracteres para contraseñas de administrador:
set password-policy user-type admin minimum-length 8
La complejidad de la contraseña significa que las contraseñas deben incluir por lo

menos dos letras mayúsculas, dos letras minúsculas y dos caracteres alfanuméricos
y dos no alfanuméricos, por ejemplo: AAbb12@#. Para requerir que las contraseñas
contengan complejidad, debe establecer la complejidad en 1. Para desactivar el
requisito de complejidad, establezca la complejidad en 0. Utilice el siguiente
comando para crear una directiva de contraseñas que requiera que las contraseñas
autenticadas contengan complejidad:
set password-policy user-type auth complexity 1
Directiva de contraseñas 55
En el siguiente ejemplo, se crea una directiva de contraseñas para las cuentas

autenticadas y de administrador que exija complejidad y una longitud mínima de
8 caracteres:
CLI
set password-policy user-type admin minimum-length 8
set password-policy user-type admin complexity 1
set password-policy user-type auth minimum-length 8
set password-policy user-type auth complexity 1
save
NOTA: Puede configurar una directiva de contraseñas únicamente desde la interfaz de

línea de comandos (CLI).
Eliminación de una directiva de contraseñas

Utilice el comando unset password-policy para borrar una directiva de
contraseñas. Cuando elimina una directiva de contraseñas, el requisito de
contraseña para la cuenta regresa a los ajustes predeterminados. En el siguiente
ejemplo, eliminará el requisito de longitud mínima para las contraseñas de
autenticación.
CLI
unset password-policy user-type auth minimum-length
Visualización de una directiva de contraseñas

Utilice el comando get password-policy para visualizar la directiva de contraseñas
de los usuarios con permisos de administrador y de autenticación.
Recuperación de una contraseña de administrador predeterminada rechazada

Al eliminar (unset) la cuenta del administrador raíz en un dispositivo en el cual tiene
configurada una directiva de contraseñas, es posible que necesite establecer una
nueva contraseña de administrador antes de cerrar la sesión del sistema. Esto se
debe a que ScreenOS regresa a la contraseña predeterminada (netscreen) una vez
que usted borra la cuenta del administrador raíz. Si cuenta con una directiva de
contraseñas que requiere complejidad o una longitud mínima mayor de
9 caracteres, su próximo intento por iniciar sesión fallará. Si sucede esto, utilice el
procedimiento de recuperación de equipos para obtener acceso al dispositivo.
Consulte el manual del usuario para obtener una plataforma con los detalles.
En el siguiente ejemplo, borrará la cuenta de administrador denominada

admin2005, luego visualizará la directiva de contraseñas actual. Como se muestra,
la directiva especifica que las contraseñas deben tener una longitud mínima de
8 caracteres y utilizar la complejidad (un mínimo de dos letras mayúsculas, dos
letras minúsculas, dos caracteres alfanuméricos y dos no alfanuméricos). Luego
creará una nueva cuenta de administrador denominada admin2006 y establecerá
una contraseña de manera que cumpla con los requisitos de longitud mínima y
complejidad de la directiva de contraseñas.
56 Directiva de contraseñas
CLI
unset admin admin2005
get password-policy
user-type: admin
password minimum length: 8
password complexity scheme: 1
user-type: auth
password minimum length: 8
password complexity scheme: 1
set admin admin2006 password AAbb12@#

save
NOTA: Puede configurar una cuenta de administrador únicamente desde la interfaz de

línea de comandos (CLI).
Creación de un mensaje de bienvenida de inicio de sesión

Se ha aumentado el tamaño del mensaje de bienvenida de inicio de sesión a un
máximo de 4 Kbytes. Esto proporciona espacio para las declaraciones de términos
del uso, que se presentan antes de que los administradores y usuarios autenticados
inicien una sesión en el dispositivo de seguridad y en recursos protegidos detrás del
dispositivo. El mensaje de bienvenida de inicio de sesión es un archivo de texto
ASCII que se puede crear y almacenar en el dispositivo de seguridad, el archivo
tiene que llamarse usrterms.txt. El mensaje de bienvenida se activa reiniciando el
dispositivo. Si el archivo del mensaje de bienvenida tiene más de 4 Kbytes, el
dispositivo de seguridad no lo aceptará y continuará utilizando los mensajes de
bienvenida existentes que se han introducido a través de CLI y la WebUI.
Cuando se activa el mensaje de bienvenida de inicio de sesión, el dispositivo raíz y

todos los sistemas virtuales (vsys) lo utilizan en forma global. No es posible
diferenciar o personalizar entre sistemas virtuales (vsys). El mensaje de bienvenida
de inicio de sesión sustituye a todos los mensajes de bienvenida de acceso
administrativo y los mensajes de bienvenida de autenticación del cortafuegos que
fueron definidos de forma individual. Después de introducir el nombre de usuario y
la contraseña, el usuario debe hacer clic en el botón Login. Si el usuario presiona la
tecla Enter no obtendrá acceso al dispositivo.
Utilice el programa de SCP para copiar de forma segura el archivo del mensaje de
bienvenida en el dispositivo de seguridad. Con el siguiente comando, un
administrador con nombre de usuario netscreen puede copiar el archivo del
mensaje de bienvenida mi_mensaje_bienvenida.txt a un dispositivo de seguridad a
una dirección IP 1.1.1.2. El archivo del mensaje de bienvenida debe guardarse en el
dispositivo de seguridad como usrterms.txt.
linux:~#scp mi_mensaje_bienvenida.txt netscreen@1.1.1.2:usrterms.txt
Debe reiniciar el dispositivo para activar el nuevo mensaje de bienvenida. Para

modificar el archivo del mensaje de bienvenida, puede crear un nuevo archivo y
sobrescribir el existente con el nuevo.
Creación de un mensaje de bienvenida de inicio de sesión 57

Para eliminar el mensaje de bienvenida, ejecute el siguiente comando en el

device-> delete file usrterms.txt
Esto inhabilita la función del mensaje de bienvenida después de que reinicie el

dispositivo.
58 Creación de un mensaje de bienvenida de inicio de sesión

Capítulo 2
Supervisión de dispositivos de
seguridad
Este capítulo trata de los siguientes temas relacionados con la supervisión de

dispositivos de seguridad Juniper Networks:
“Almacenamiento de la información del registro” en esta página
“Registro de eventos” en la página 61
“Registro de tráfico” en la página 65
“Registro propio” en la página 70
“Descargar el registro de recuperación de posición” en la página 72
“Alarmas de tráfico” en la página 73
“Syslog” en la página 76
“Protocolo simple de administración de redes” en la página 78
“Túneles VPN para tráfico autogenerado” en la página 83
“Visualizar contadores de pantalla” en la página 98
Almacenamiento de la información del registro

Todos los dispositivos de seguridad Juniper Networks permiten almacenar datos del
registro de eventos y de tráfico en soportes internos (memoria flash) y externos (en
una serie de ubicaciones). Aunque resulta muy cómodo almacenar la información
del registro internamente, la cantidad de memoria del dispositivo disponible es
limitada. Cuando el espacio de almacenamiento interno se llena totalmente, el
dispositivo de seguridad comienza a sobrescribir las entradas más antiguas del
registro con las más recientes. Si este mecanismo FIFO (“first-in-first-out”, es decir,
las entradas más antiguas son las primeras que se sobrescriben) entra en acción
antes de que usted haya guardado la información registrada, puede perder datos.
Para minimizar tal pérdida de datos, puede almacenar los registros de eventos y
tráfico externamente en un servidor syslog o WebTrends, o bien en la base de datos
NetScreen-Global PRO. El dispositivo de seguridad envía las nuevas entradas del
registro de eventos y tráfico a una ubicación de almacenamiento externo cada
segundo.
Almacenamiento de la información del registro 59

La siguiente lista proporciona los posibles destinos de los datos registrados:
Consola: Un destino muy útil para que todas las entradas del registro estén
disponibles cuando se están resolviendo problemas en un dispositivo de
seguridad a través de la consola. Opcionalmente, puede elegir que aquí
solamente aparezcan mensajes de alarma (crítico, alerta, emergencia) para
alertarle inmediatamente si se desencadena alguna alarma mientras usted está
utilizando la consola.
Interno: Permite que almacene un número limitado de entradas de registro.
Correo electrónico: Un método para enviar registros de eventos y tráfico a

administradores remotos.
SNMP: Además de la transmisión de capturas SNMP, un dispositivo de

seguridad también puede enviar mensajes de alarma (crítico, alerta,
emergencia) desde su registro de eventos a una comunidad SNMP.
Syslog: Todas las entradas del registro de eventos y tráfico que un dispositivo
de seguridad puede almacenar internamente, también puede enviarlas a un
servidor syslog. Dado que los servidores syslog tienen una capacidad de
almacenamiento mucho mayor que las memorias flash internas de un
dispositivo de seguridad, el envío de datos a un servidor syslog puede
minimizar la pérdida de datos que podría producirse cuando el número de
entradas del registro supera la capacidad máxima de almacenamiento interno.
Syslog almacena eventos de los niveles de alerta y emergencia en la utilidad de
seguridad que usted especifique, y los demás eventos (incluyendo los datos de
tráfico) en otro equipo que también se puede especificar.
WebTrends: Permite visualizar los datos del registro de los niveles crítico, alerta
y emergencia en un formato más gráfico que syslog, que es una herramienta de
visualización en modo texto.
CompactFlash (PCMCIA): Le permite almacenar datos en una tarjeta

CompactFlash.
USB: Le permite almacenar datos en una unidad de memoria USB. Cuando

establece un USB como el destino de registro, el sistema envía mensajes de
registro a un archivo en la unidad de memoria USB. El archivo de registro se
denomina nombrehost fecha.evt_log, donde nombrehost es el nombre del host
del sistema en el momento de arranque y fecha es la fecha en la cual se inició el
dispositivo por última vez. El registro a USB está desactivado como valor
predeterminado, utilice el comando de CLI set log usb enable para activar lo.
Utilice el comando set log... destination... para establecer los niveles de gravedad
para todos los destinos de registro. El siguiente ejemplo registra todos los mensajes
del módulo del sistema de nivel crítico o más alto a la unidad de memoria USB:
set log module system level critical destination usb
60 Almacenamiento de la información del registro

Capítulo 2: Supervisión de dispositivos de seguridad
Registro de eventos
ScreenOS proporciona un registro de eventos para la supervisión de los eventos del
sistema, tales como cambios de configuración efectuados por administradores y
mensajes y alarmas autogenerados en relación con el comportamiento operativo y
los ataques recibidos. El dispositivo de seguridad categoriza los eventos del sistema
según los siguientes niveles de gravedad:
Emergency (emergencia): mensajes sobre ataques de tipo SYN, Tear Drop y

Ping of Death. Para obtener más información sobre estos tipos de ataques,
consulte el Volumen 4: Detección ataques y mecanismos de defensa.
Alert (alerta): mensajes sobre condiciones que requieren una atención

inmediata, como ataques al cortafuegos y vencimiento de claves de licencia.
Critical (crítico): mensajes sobre condiciones que probablemente afectan a la

funcionalidad del dispositivo, como cambios de estado de alta disponibilidad
(HA).
Error: mensajes sobre condiciones de error que probablemente afectan a la

funcionalidad del dispositivo, como un fallo en el análisis antivirus o un error
de comunicación con servidores SSH.
Warning (advertencia): mensajes sobre condiciones que podrían afectar a la

funcionalidad del dispositivo, como un fallo de conexión con servidores de
correo electrónico o errores de autenticación, vencimientos de temporizaciones
y éxitos.
Notification (notificación): mensajes sobre eventos normales, incluyendo

cambios de configuración iniciados por un administrador.
Information (información): mensajes que ofrecen información general sobre

operaciones del sistema.
Debugging (depuración): mensajes que ofrecen información detallada utilizada

con fines de depuración.
El registro de eventos muestra la fecha y hora, el nivel y la descripción de cada

evento del sistema. Puede ver los eventos del sistema correspondientes a cada
categoría almacenada en la memoria flash del dispositivo de seguridad a través de
WebUI o CLI. También puede abrir o guardar el archivo en la ubicación que
especifique, y luego utilizar un editor de textos ASCII (como Bloc de notas o
WordPad) para ver el archivo. Alternativamente, puede enviarlos a un
almacenamiento externo (consulte “Almacenamiento de la información del
registro” en la página 59).
NOTA: Para obtener información detallada sobre los mensajes que aparecen en el registro
de eventos, consulte el manual ScreenOS Message Log Reference Guide.
Registro de eventos 61
Ver el registro de eventos según nivel de gravedad y palabra clave

Puede ver el registro de eventos almacenado en el dispositivo mediante CLI o
WebUI. Las entradas del registro se pueden mostrar según el nivel de gravedad y
buscar por palabras clave, tanto en WebUI como en CLI.
Para mostrar el registro de eventos por niveles de gravedad, ejecute cualquiera de

los siguientes procedimientos:
WebUI
Reports > System Log > Event: Seleccione un nivel de gravedad en la lista
desplegable Log Level.
CLI
get event level { emergency | alert | critical | error | warning | notification |
information | debugging }
Para buscar en el registro de eventos por palabras clave, ejecute cualquiera de los
WebUI
Reports > System Log > Event: Escriba una palabra o una frase de hasta
15 caracteres en el campo de búsqueda y haga clic en Search.
CLI
get event include word_string
En este ejemplo visualizará entradas del registro de eventos con un nivel de

gravedad “warning” y buscará la palabra clave “AV”.
WebUI
Reports > System Log > Event:
Log Level: Warning (seleccione)
Search: Escriba AV, luego haga clic en Search.
CLI
get event level warning include av
Nivel de
Fecha Hora módulo Nivel Tipo Descripción
2003-05-16 15:56:20 advertencia 00547 AV se eliminó scanman.
del sistema
2003-05-16 09:45:52 advertencia 00547 AV se eliminó test1.
del sistema
Total de entradas con coincidencia = 2
62 Registro de eventos
Clasificación y filtrado del registro de eventos

También puede utilizar la interfaz de línea de comandos (CLI) para clasificar o filtrar
el registro de eventos basándose en los criterios siguientes:
Dirección IP de origen o de destino: Sólo ciertos eventos contienen una

dirección IP de origen o de destino, como la autenticación, ataques terrestres
(land attacks) o los ataques de inundación por “ping”. Cuando se clasifican los
registros de eventos por dirección IP de origen o de destino, el dispositivo
clasifica y muestra solamente los registros de eventos que contienen
direcciones IP de origen o de destino. Ignora todos los registros de eventos que
no contengan dirección IP de origen o de destino. Los mensajes de registro de
autenticación incluyen la dirección IP del usuario.
Cuando se filtra el registro de eventos especificando una dirección IP de origen

o de destino, o bien un rango de direcciones, el dispositivo muestra las
entradas del registro correspondientes a la dirección IP de origen o de destino,
o bien al rango de direcciones que se haya especificado.
Fecha: El registro de eventos se puede clasificar por fecha solamente, o bien

por fecha y hora. Cuando se clasifican las entradas del registro por fecha y
hora, el dispositivo enumera las entradas del registro en orden descendente de
fecha y hora.
También se pueden filtrar las entradas del registro de eventos especificando

una fecha de comienzo, una fecha de final, o bien un intervalo de fechas.
Cuando se especifica una fecha de comienzo, el dispositivo muestra las
entradas del registro que tengan marcas de fecha/hora posteriores a la fecha de
comienzo. Si se especifica una fecha de final, el dispositivo muestra las
entradas del registro que tengan marcas de fecha/hora anteriores a la misma.
Hora: Al clasificar registros por hora, el dispositivo muestra las entradas del
registro en orden descendente según su hora, sin importar la fecha. Si se
especifica una hora de comienzo, el dispositivo muestra las entradas del
registro cuyas marcas de hora sean posteriores a la hora de comienzo
especificada, sin importar la fecha. Si se especifica una hora de final, el
dispositivo muestra las entradas del registro cuyas marcas de hora sean
anteriores a la hora de final especificada, sin importar la fecha. Si se especifica
una hora de comienzo y otra de final, el dispositivo muestra las entradas del
registro cuyas marcas de hora se encuentren dentro del periodo de tiempo
especificado.
Número de identificación del tipo de mensaje: Se pueden mostrar las

entradas del registro de eventos correspondientes a un determinado número de
identificación del tipo de mensaje, o bien las entradas cuyos números de
identificación del tipo de mensaje coincidan con un rango especificado. El
dispositivo muestra las entradas del registro con los números de identificación
de los tipos de mensaje especificados, clasificados por fecha y hora en orden
descendente.
En este ejemplo podrá ver las entradas del registro de eventos que contienen
direcciones IP de origen en el rango 10.100.0.0 a 10.200.0.0. Las entradas del
registro también están clasificadas por direcciones IP de origen.
Registro de eventos 63
WebUI
NOTA: Debe utilizar la CLI para clasificar el registro de eventos según las entradas de
direcciones.
CLI
get event sort-by src-ip 10.100.0.0-10.200.0.0
Descargar el registro de eventos

También puede abrir o guardar el registro de eventos en la ubicación que
especifique, y luego utilizar un editor de textos ASCII (como Bloc de notas o
WordPad) para ver el archivo. Alternativamente, puede enviar las entradas del
registro a un almacenamiento externo (consulte “Almacenamiento de la
información del registro” en la página 59). También puede descargar el registro de
eventos completo a través de WebUI. Mediante la CLI se puede descargar el registro
de eventos por niveles de gravedad.
Ejemplo: Descargar el registro de eventos completo

En este ejemplo, descargará el registro de eventos al directorio. Usando la WebUI,
descárguelo en C:\netscreen\logs. Con CLI, puede descargarlo al directorio raíz de un
servidor TFTP en la dirección IP 10.1.1.5. Nombrará el archivo “evnt07-02.txt”.
WebUI
1. Reports > System Log > Event: Haga clic en Save.
El cuadro de diálogo “File Download” le pedirá que abra el archivo (con un

editor ASCII) o que lo guarde en el disco.
2. Seleccione la opción Save, luego haga clic en OK.
El cuadro de diálogo “File Download” le pedirá que elija un directorio.
3. Especifique C:\netscreen\logs, denomine el archivo evnt07-02.txt, luego haga

clic en Save.
CLI
get event > tftp 10.1.1.5 evnt07-02.txt
Ejemplo: Descargar los eventos críticos del registro de eventos

En este ejemplo descargará los eventos críticos existentes en el registro de eventos
al directorio raíz de un servidor TFTP con la dirección IP 10.1.1.5. Denominará el
archivo crt_evnt07-02.txt.
WebUI
NOTA: Debe utilizar la CLI para descargar entradas según el nivel de gravedad.
CLI
get event level critical > tftp 10.1.1.5 crt_evnt07-02.txt
64 Registro de eventos
Registro de tráfico
El dispositivo de seguridad Juniper Networks puede supervisar y registrar el tráfico
que autoriza o deniega basándose en las directivas previamente configuradas.
Puede habilitar la opción de registro para cada directiva que configure. Al habilitar
la opción de registro para una directiva de autorización de tráfico, el dispositivo
registra el tráfico autorizado por esa directiva. Al habilitar la opción de registro para
una directiva de denegación de tráfico, el dispositivo registra el tráfico que intenta
pasar a través del dispositivo pero que resulta anulado por esa directiva.
En un registro de tráfico se anotan los siguientes elementos de cada sesión:
Fecha y hora de inicio de la conexión
Duración
Dirección de origen y número de puerto
Dirección de origen traducida y número de puerto
Dirección de destino y número de puerto
La duración de la sesión
El servicio utilizado en la sesión
Para registrar todo el tráfico recibido por un dispositivo de seguridad, debe

habilitarse la opción de registro para todas las directivas. Para registrar tráfico
específico, habilite el registro solamente para las directivas que afecten a ese tipo
de tráfico. Para habilitar la opción de registro de una directiva, ejecute cualquiera de
los siguientes procedimientos:
WebUI
Policies > (From: zona_orig, To: zona_dest) New : Seleccione Logging y haga
clic en OK.
CLI
set policy from zona_orig to zona_dest dir_orig dir_dest servicio acción log
Además de registrar el tráfico de una directiva, el dispositivo también puede

mantener una cuenta en bytes de todo el tráfico de la red al que se aplicó la
directiva. Cuando se habilita la opción de recuento, el dispositivo incluye la
siguiente información al mostrar entradas del registro de tráfico
Bytes transmitidos de un origen a un destino
Bytes transmitidos de un destino a un origen
Puede habilitar el recuento de una directiva desde WebUI y desde CLI.
WebUI
Policies > (From: zona_orig, To: zona_dest) New > Advanced: Seleccione
Counting, haga clic en Return y luego haga clic en OK.
Registro de tráfico 65
CLI
set policy from zona_orig to zona_dest dir_orig dir_dest servicio acción log count
Visualización del registro de tráfico

Las entradas del registro de tráfico almacenadas en la memoria flash del dispositivo
de seguridad se pueden ver por medio del uso de la CLI o de WebUI:
WebUI
Policies > Logging (para la directiva con ID número)
o bien
Reports > Policies > (para la directiva con ID número)
CLI
get log traffic policy número
Ejemplo: Visualizar las entradas del registro de tráfico

En este ejemplo se visualizan los detalles del registro de tráfico de una directiva con
la identificación número 3, para la que previamente se ha habilitado el registro:
WebUI
Directivas: Haga clic en el icono de registro para la directiva con el número de
identificación 3.
Aparece la información siguiente:
Date/Time: 2003-01-09 21:33:43
Duration: 1800 seg.
Source IP Address/Port: 1.1.1.1:1046
Destination IP Address/Port: 10.1.1.5:80
Service: HTTP
Reason for Close: Age out
Translated Source IP Address/Port: 1.1.1.1:1046
Translated Destination IP Address/Port: 10.1.1.5:80
Policy ID number: 3
CLI
get log traffic policy 3
66 Registro de tráfico
Clasificación y filtrado del registro de tráfico

De forma similar al registro de eventos, cuando se utiliza la CLI para ver el registro
de tráfico se pueden clasificar o filtrar las entradas del registro según los criterios
siguientes:
Dirección IP de origen o de destino: El registro de tráfico se puede clasificar

por direcciones IP de origen o de destino. También se puede filtrar el registro de
tráfico especificando una dirección IP de origen o de destino, o bien un rango
de direcciones.
Fecha: El registro de tráfico se puede clasificar por fechas solamente, o bien por
fecha y hora. El dispositivo muestra las entradas del registro en orden
descendente por fecha y hora.
También se pueden filtrar las entradas del registro de eventos especificando

una fecha de comienzo, una fecha de final, o bien un intervalo de fechas.
Cuando se especifica una fecha de comienzo, el dispositivo muestra las
entradas del registro que tengan marcas de fecha/hora posteriores a la fecha de
comienzo. Si se especifica una fecha de final, el dispositivo muestra las
entradas del registro que tengan marcas de fecha/hora anteriores a la misma.
Hora: Al clasificar el registro de tráfico por hora, el dispositivo muestra las

entradas del registro en orden descendente según su hora, sin importar la
fecha. Si se especifica una hora de comienzo, el dispositivo muestra las
entradas del registro cuyas marcas de hora sean posteriores a la hora de
comienzo especificada, sin importar la fecha. Si se especifica una hora de final,
el dispositivo muestra las entradas del registro cuyas marcas de hora sean
especificado.
Ejemplo: Clasificar el registro de tráfico por horas

En este ejemplo se visualizan los registros de tráfico clasificados por hora con una
marca horaria posterior a las 1:00 horas.
WebUI
NOTA: La posibilidad de clasificar el registro de tráfico por tiempo está disponible

únicamente con la CLI.
CLI
get log traffic sort-by time start-time 01:00:00
Descarga del registro de tráfico

También puede abrir o guardar el registro en la ubicación que especifique, y luego
utilizar un editor de textos ASCII (como Bloc de notas o WordPad) para ver el
archivo.
Alternativamente, puede enviar las entradas del registro de tráfico a un

almacenamiento externo (consulte “Almacenamiento de la información del
registro” en la página 59). El dispositivo de seguridad crea una entrada en el
registro de tráfico cuando se termina una sesión. Cuando se habilita el dispositivo
de seguridad para enviar entradas del registro de tráfico a una ubicación de
almacenamiento externo, envía las nuevas entradas cada segundo. Dado que el
dispositivo de seguridad genera una entrada en el registro de tráfico cada vez que
se cierra una sesión, envía las entradas del registro de tráfico de todas las sesiones
cerradas durante el último segundo. También se pueden incluir entradas del registro
de tráfico con las entradas del registro de eventos enviadas por correo electrónico a
un administrador.
En este ejemplo se descarga el registro de tráfico correspondiente a una directiva

con la identificación número 12. Con WebUI se descarga al directorio local
“C:\netscreen\logs”. Con CLI, se descarga al directorio raíz de un servidor TFTP en la
dirección IP 10.10.20.200. El archivo se denomina “traf_log11-21-02.txt”.
WebUI
1. Reports > Policies > Logging (para la directiva con ID 12): Haga clic en Save.

3. Especifique “C:\netscreen\logs”, nombre el archivo “traf_log11-21-02.txt”, luego

haga clic en Save.
CLI
get log traffic policy 12 > tftp 10.10.20.200 traf_log11-21-02.txt
Eliminación del campo del motivo de cierre

De forma predeterminada ScreenOS registra y muestra el motivo del cierre de la
sesión de manera que pueda diferenciar los mensajes de creación de sesión de los
mensajes de cierre de sesión. Si no desea ver el motivo, puede configurar
explícitamente el dispositivo de manera que no muestre el campo.
68 Registro de tráfico
La Tabla 1 enumera los motivos del cierre de la sesión identificados por ScreenOS.
Cualquier sesión que no se puede identificar se etiqueta como OTHER (otra).
Tabla 1: Códigos de motivo para el cierre de sesión
Motivo registrado Significado

TCP FIN Conexión TCP desmantelada debido al paquete FIN.
TCP RST Conexión TCP desmantelada debido al paquete RST.
RESP Las sesiones especiales, como PING y DNS, se cierran al recibir la
respuesta.
ICMP Error de ICMP recibido.
AGE OUT La conexión expiró normalmente.
ALG La ALG forzó el cierre de la sesión, ya sea debido a un error o a otro
motivo específico para dicho ALG.
NSRP Se recibió el mensaje de cierre de la sesión NSRP.
AUTH Fallo de autenticación.
IDP Cerrada por IDP.
SYN PROXY FAIL Fallo de Proxy de SYN.
SYN PROXY LIMIT Se ha alcanzado el límite del sistema para sesiones del proxy de SYN.
TENT2NORM CONV Fallo en el intento de realizar una conversión normal de sesión.
PARENT CLOSED Sesión principal cerrada.
CLI Cerrado por comando del usuario.
OTHER Motivo del cierre no identificado.
Ejemplo de registro de tráfico con motivo de cierre enumerado:
ns-> get log traffic

PID 1, from Trust to Untrust, src Any, dst Any, service ANY, action Permit
Total traffic entries matched under this policy = 2300
================================================================================
Date Time Duration Source IP Port Destination IP Port Service
Reason Xlated Src IP Port Xlated Dst IP Port ID
================================================================================
2001-10-25 07:08:51 0:00:59 10.251.10.25 137 172.240.16.10 137 NETBIOS (NS)
Close - AGE OUT 172.24.76.127 8946 172.24.16.10 137
2001-10-25 07:08:51 0:00:59 10.251.10.25 137 172.24.244.10 137 NETBIOS (NS)
Close - AGE OUT 172.24.76.127 8947 172.24.244.10 137
2001-10-25 07:07:53 0:00:01 10.251.10.25 1028 172.24.16.10 53 DNS
Close - RESP 172.24.76.127 8945 172.24.16.10 53
2001-10-25 07:06:29 0:01:00 10.251.10.25 138 172.24.244.10 138 NETBIOS (DGM)
Close - AGE OUT 172.24.76.127 8933 172.24.244.10 138
2001-10-25 07:06:11 0:03:16 10.251.10.25 2699 172.24.60.32 1357 TCP PORT 1357
Close - TCP FIN 172.24.76.127 8921 172.24.60.32 1357
Ejemplo de registro de tráfico sin motivo de cierre enumerado:
ns-> get log traffic

PID 1, from Trust to Untrust, src Any, dst Any, service HTTP, action Permit
Total traffic entries matched under this policy = 1538
================================================================================
Date Time Duration Source IP Port Destination IP Port Service
Xlated Src IP Port Xlated Dst IP Port ID
================================================================================
2002-07-19 15:53:11 0:01:33 10.251.10.25 2712 207.17.137.108 80 HTTP

10.251.10.25 2712 207.17.137.108 80
2002-07-19 15:51:33 0:00:12 10.251.10.25 2711 66.163.175.128 80 HTTP
10.251.10.25 2711 66.163.175.128 80
2002-07-19 15:41:33 0:00:12 10.251.10.25 2688 66.163.175.128 80 HTTP
10.251.10.25 2688 66.163.175.128 80
2002-07-19 15:31:39 0:00:18 10.251.10.25 2678 66.163.175.128 80 HTTP
10.251.10.25 2678 66.163.175.128 80
En el siguiente ejemplo, puede configurar el dispositivo para que no muestre el

motivo del cierre de las sesiones debido a que interfiere con un que desea ejecutar
en el registro de tráfico. Debe utilizar la interfaz de línea de comandos para cambiar
el estilo de salida del registro.
WebUI
No disponible.
CLI
set log traffic detail 0
save
Registro propio
ScreenOS proporciona un registro propio para supervisar y registrar todos los
paquetes llegados al dispositivo de seguridad. Por ejemplo, al desactivar algunas
opciones de administración en una interfaz, como WebUI, SNMP y el comando
ping, y se envía tráfico HTTP, SNMP o ICMP a esa interfaz, en el registro propio se
generan entradas por cada paquete descartado.
Para activar el registro propio, proceda de una de las siguientes maneras:
WebUI
Configuration > Report Settings > Log Settings: Active la casilla de verificación
Log Packets Terminated to Self y haga clic en Apply.
CLI
set firewall log-self
Cuando se activa el registro propio, el dispositivo de seguridad registra las entradas

en dos lugares: el registro propio y el registro de tráfico. De forma similar al registro
de tráfico, el registro propio muestra a la fecha y hora, la dirección o puerto de
origen, la dirección o puerto de destino, la duración y el servicio de cada paquete
descartado que terminó en el dispositivo de seguridad. Normalmente, las entradas
del registro propio tienen una zona de origen de cero y una zona de destino de
“registro propio”.
Visualización del registro propio

El registro propio, que se guarda en la memoria flash del dispositivo de seguridad,
se puede visualizar a través de CLI o de WebUI.
WebUI
Reports > System Log > Self
70 Registro propio
CLI
get log self
Clasificación y filtrado del registro propio

De forma similar a los registros de eventos y tráfico, cuando se utiliza la CLI para
ver el registro propio, se pueden clasificar o filtrar las entradas del registro según los
siguientes criterios:
Dirección IP de origen o de destino: El registro propio se puede clasificar por

direcciones IP de origen o de destino. También se puede filtrar el registro
propio especificando una dirección IP de origen o de destino, o bien un rango
de direcciones.
Fecha: El registro propio se puede clasificar por fecha solamente, o bien por
fecha y hora. El dispositivo muestra las entradas del registro en orden
descendente por fecha y hora.
También se pueden filtrar las entradas del registro propio especificando una
fecha de comienzo, una fecha de final, o bien un intervalo de fechas. Cuando se
especifica una fecha de comienzo, el dispositivo muestra las entradas del
registro que tengan marcas de fecha/hora posteriores a la fecha de comienzo. Si
se especifica una fecha de final, el dispositivo muestra las entradas del registro
que tengan marcas de fecha/hora anteriores a la misma.
Hora: Al clasificar el registro propio por hora, el dispositivo de seguridad

muestra las entradas del registro en orden descendente según su hora, sin
importar la fecha. Si se especifica una hora de comienzo, el dispositivo muestra
las entradas del registro cuyas marcas de hora sean posteriores a la hora de
comienzo especificada, sin importar la fecha. Si se especifica una hora de final,
el dispositivo muestra las entradas del registro cuyas marcas de hora sean
especificado.
Ejemplo: Filtrar el registro propio por horas

En este ejemplo se filtran las entradas del registro propio por horas finales. El
dispositivo de seguridad muestra las entradas del registro cuyas marcas de
fecha/hora son anteriores a la hora de final especificada:
WebUI
NOTA: La posibilidad de filtrar el registro propio según las horas está disponible
únicamente con la CLI.
Registro propio 71
CLI
get log self end-time 16:32:57
Fecha Hora Duración IP de origen Puerto IP de destino Puerto Servicio

2003-08-21 16:32:57 0:00:00 10.100.25.1 0 224.0.0.5 0 OSPF
2003-08-21 16:32:47 0:00:00 10.100.25.1 0 224.0.0.5 0 OSPF
Total de entradas con coincidencia = 2
Descargar el registro propio

El registro también se puede guardar como archivo de texto en la ubicación
especificada, y después utilizar un editor de textos ASCII (como Bloc de notas o
WordPad) para visualizarlo.
En este ejemplo se descarga un registro propio al directorio local

“C:\netscreen\logs” (WebUI) o al directorio raíz de un servidor TFTP con la dirección
IP 10.1.1.5 (CLI). Denomine el archivo “self_log07-03-02.txt”.
WebUI
1. Reports > System Log > Self: Haga clic en Save.

3. Especifique “C:\netscreen\logs”, nombre el archivo “self_log07-03-02.txt” y

haga clic en Save.
CLI
get log self > tftp 10.1.1.5 self_log07-03-02.txt
Descargar el registro de recuperación de posición

Un dispositivo de seguridad Juniper Networks proporciona un registro de
recuperación de posición para mostrar información sobre cada vez que se
restablecen los ajustes predeterminados del dispositivo mediante el procedimiento
de recuperación de posición (consulte “Restablecimiento del dispositivo con los
ajustes predeterminados de fábrica” en la página 44). Además de ver el registro de
recuperación de posiciones con WebUI o CLI, también se puede abrir o guardar el
archivo en la ubicación que se especifique. Para ver el archivo, utilice un editor de
textos ASCII (como Bloc de notas).
En este ejemplo se descarga el registro de recuperación de activos al directorio local

“C:\netscreen\logs” (WebUI) o al directorio raíz de un servidor TFTP con la dirección
IP 10.1.1.5 (CLI). El archivo se denominará “sys_rst.txt”.
72 Descargar el registro de recuperación de posición

WebUI
1. Reports > System Log > Asset Recovery: Haga clic en Save.

3. Especifique “C:\netscreen\logs”, nombre el archivo “sys_rst.txt” y haga clic en

Save.
CLI
get log asset-recovery > tftp 10.1.1.5 sys_rst.txt
Alarmas de tráfico
El dispositivo de seguridad permite la generación de alarmas de tráfico cuando éste
supera los umbrales definidos mediante directivas. El dispositivo de seguridad se
puede configurar para alertar mediante uno o varios de los métodos siguientes
cuando genere una alarma de tráfico:
Consola
Interno (registro de eventos)
Correo electrónico
SNMP
Syslog
WebTrends
NetScreen-Global PRO
Se establecen umbrales de alarma para detectar las actividades anómalas. Para

saber qué constituye una actividad anómala, primero debe establecer una línea de
base de actividad normal. Para crear tal línea de base para el tráfico de red, es
necesario observar los patrones de tráfico a lo largo de un periodo de tiempo.
Entonces, cuando haya determinado qué cantidad de tráfico considera normal,
puede establecer umbrales de alarma por encima de esa cantidad. El tráfico que
supera ese umbral dispara una alarma para llamar su atención hacia esta
desviación de la línea de base. Entonces, usted puede evaluar la situación para
determinar qué causó la desviación y si necesita iniciar acciones como respuesta.
Las alarmas de tráfico también se pueden utilizar para proporcionar un sistema de

detección de intrusiones basado en directivas y notificar que el sistema está en
situación de riesgo. A continuación se indican ejemplos de utilización de las
alarmas de tráfico con estos fines.
Alarmas de tráfico 73
Ejemplo: Detección de intrusiones basada en directivas

En este ejemplo hay un servidor web con la dirección IP 211.20.1.5 (y el nombre
“web1”) en la zona DMZ. Suponga que desea detectar cualquier intento de acceso a
este servidor web a través de Telnet desde la zona Untrust. Para conseguirlo, debe
crear una directiva que deniegue el tráfico de Telnet desde cualquier dirección de la
zona Untrust dirigido al servidor web denominado “web1” de la zona DMZ, así
como establecer un umbral de alarma de tráfico en 64 bytes. Debido a que el
tamaño más pequeño de un paquete IP son 64 bytes, incluso un paquete de Telnet
que intente acceder al servidor web desde la zona Untrust generará una alarma.
WebUI
Address Name: web1

Zone: DMZ
Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), web1
Service: Telnet
Action: Deny
Counting: (seleccione)
Alarm Threshold: 64 Bytes/Sec, 0 Kbytes/Min
CLI
set address dmz web1 211.20.1.5/32
set policy from untrust to dmz any web1 telnet deny count alarm 64 0
save
Ejemplo: Notificación de sistema comprometido

En este ejemplo se utilizan alarmas de tráfico para generar notificaciones cuando el
sistema está comprometido. Hay un servidor FTP con la dirección IP 211.20.1.10
(y nombre “ftp1”) en la zona DMZ. Se desea permitir el tráfico FTP-get para
alcanzar ese servidor. Pero no se desea que desde el servidor FTP se origine tráfico
de ninguna clase. La presencia de tal tráfico indicaría que el sistema está
comprometido, quizás a causa de un virus similar al NIMDA. Se definirá una
dirección para el servidor FTP en la zona “Global”, de modo que se puedan crear
dos directivas globales.
74 Alarmas de tráfico
WebUI
Address Name: ftp1

Zone: Global
Policies > (From: Global, To: Global) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), ftp1
Service: FTP-Get
Action: Permit
Policies > (From: Global, To: Global) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Service: ANY
Action: Deny
Counting: (seleccione)
Alarm Threshold: 64 Bytes/Sec, 0 Kbytes/Min
CLI
set address global ftp1 211.20.1.10/32
set policy global any ftp1 ftp-get permit
set policy global ftp1 any deny count alarm 64 0
save
Ejemplo: Enviar alertas de correo electrónico

En este ejemplo se configura la notificación mediante alertas de correo electrónico
cuando se produce una alarma. El servidor de correo está en 172.16.10.254, la
primera dirección de correo electrónico a la que se debe notificar es
jharker@juniper.net y la segunda dirección es driggs@juniper.net. El dispositivo de
seguridad incluye registros de tráfico con los registros de eventos enviados a través
de correo electrónico.
Alarmas de tráfico 75
WebUI
Configuration > Report Settings > Email: Introduzca los siguientes datos y
haga clic en Apply:
Enable E-Mail Notification for Alarms: (seleccione)

Include Traffic Log: (seleccione)
SMTP Server Name: 172.16.10.254
E-Mail Address 1: jharker@juniper.net
E-Mail Address 2: driggs@juniper.net
NOTA: Si tiene DNS habilitado, también puede utilizar un nombre de host para referirse al
servidor de correo, como por ejemplo mail.juniper.net.
CLI
set admin mail alert
set admin mail mail-addr1 jharker@juniper.net
set admin mail mail-addr2 driggs@juniper.net
set admin mail server-name 172.16.10.254
set admin mail traffic-log
save
Syslog
Un dispositivo de seguridad puede generar mensajes syslog para eventos del
sistema según niveles de gravedad predefinidos (consulte la lista de niveles de
gravedad en “Registro de eventos” en la página 61) y, opcionalmente, para el tráfico
que las directivas permiten pasar a través del cortafuegos. Envía estos mensajes
hasta a cuatro hosts syslog determinados que se estén ejecutando en sistemas
UNIX/Linux. Por cada host syslog se puede especificar lo siguiente:
Si el dispositivo de seguridad debe incluir entradas del registro de tráfico,

entradas del registro de eventos, o ambos tipos de entradas.
Si se debe enviar tráfico al servidor syslog a través de un túnel VPN y, en tal

caso, qué interfaz utilizar como interfaz de origen (consulte algunos ejemplos
en “Ejemplo: Tráfico autogenerado a través de túnel basado en rutas” en la
página 85 y “Ejemplo: Tráfico autogenerado a través de túnel basado en
directivas” en la página 91).
El puerto al que el dispositivo de seguridad debe enviar los mensajes syslog.
La utilidad de seguridad, que clasifica y envía los mensajes de niveles de

emergencia y alerta al host Syslog, y el equipo habitual, que clasifica y envía el
resto de mensajes correspondientes a eventos no relacionados con la
seguridad.
De forma predeterminada, el dispositivo de seguridad envía los mensajes a los host

syslog a través de UDP (puerto 514). Para aumentar la fiabilidad en la entrega de
mensajes, puede cambiar el protocolo de transporte de cada host syslog a TCP.
Puede utilizar mensajes de syslog para crear alertas de correo electrónico para el
administrador del sistema o para mostrar mensajes en la consola del host
designado siguiendo las convenciones syslog de UNIX.
76 Syslog
NOTA: En plataformas UNIX/Linux, modifique el archivo /etc/rc.d/init.d/syslog de modo

que syslog recupere la información del origen remoto (syslog -r).
Ejemplo: Habilitar múltiples servidores Syslog

En este ejemplo se configura el dispositivo de seguridad para enviar registros de
eventos y de tráfico a través de TCP a tres servidores syslog en las direcciones IP o
números de puerto siguientes: 1.1.1.1/1514, 2.2.2.1/2514 y 3.3.3.1/3514. Tanto los
niveles de seguridad como de utilidad se establecerán como “Local0”.
WebUI
Configuration > Report Settings > Syslog: Introduzca los siguientes datos y
haga clic en Apply:
Enable syslog messages: Seleccione esta opción para enviar registros a los
servidores syslog especificados.
No.: Seleccione 1, 2 y 3 para indicar que está agregando 3 servidores syslog.
IP/Hostname: 1.1.1.1, 2.2.2.1, 3.3.3.1
Port: 1514, 2514, 3514
Security Facility: Local0, Local0, Local0
Facility: Local0, Local0, Local0
Event Log: (seleccione)
Traffic Log: (seleccione)
TCP: (seleccione)
CLI
set syslog config 1.1.1.1 port 1514
set syslog config 1.1.1.1 facilities local0 local0
set syslog config 1.1.1.1 transport tcp
set syslog enable
save
Activación de WebTrends para eventos de notificación

NetIQ ofrece un producto denominado WebTrends Firewall Suite que permite crear
informes personalizados basados en los registros generados por un dispositivo de
seguridad. WebTrends analiza los archivos de registro y muestra la información
necesaria en formato gráfico. Puede crear informes sobre todos los eventos y
niveles de gravedad, o centrarse en un área determinada, como los ataques a
cortafuegos. (Para obtener más información sobre WebTrends, consulte la
documentación del producto WebTrends.)
También se pueden enviar mensajes de WebTrends a través de un túnel VPN. En

WebUI, utilice la opción Use Trust Zone Interface as Source IP for VPN. En la CLI,
utilice el comando set webtrends vpn.
Syslog 77
En el ejemplo siguiente, enviaremos mensajes de notificación al host WebTrends

(172.10.16.25).
WebUI
1. Ajustes de WebTrends
Configuration > Report Settings > WebTrends: Introduzca los siguientes datos
Enable WebTrends Messages: (seleccione)

WebTrends Host Name/Port: 172.10.16.25/514
2. Niveles de gravedad
Configuration > Report Settings > Log Settings: Introduzca los siguientes datos
WebTrends Notification: (seleccione)
NOTA: Cuando se habilitan syslog y WebTrends en un dispositivo de seguridad que se

está ejecutando en modo transparente, debe configurarse una ruta estática.
Consulte “Enrutamiento estático” en la página 7 -1.
CLI
3. Ajustes de WebTrends
set webtrends host-name 172.10.16.25
set webtrends port 514
set webtrends enable
4. Niveles de gravedad
set log module system level notification destination webtrends
save
Protocolo simple de administración de redes

El agente del protocolo simple de administración de redes (SNMP) del dispositivo de
seguridad Juniper Networks proporciona a los administradores de red un método de
visualización de datos estadísticos sobre la red y los dispositivos que contiene, así
como para recibir las notificaciones de eventos del sistema que desee.
Los dispositivos de seguridad Juniper Networks son compatibles con el protocolo

SNMPv1, descrito en la RFC-1157, A Simple Network Management Protocol, y con el
protocolo SNMPv2c, descrito en las RFC siguientes:
RFC-1901, Introduction to Community-based SNMPv2
RFC-1905, Protocol Operations for Version 2 of the Simple Network Management

Protocol (SNMPv2)
RFC-1906, Transport Mappings for Version 2 of the Simple Network Management

Protocol (SNMPv2)
78 Protocolo simple de administración de redes

Los dispositivos de seguridad también son compatibles con todos los grupos de
Management Information Base II (MIB II) relevantes definidos en la RFC-1213,
Management Information Base for Network Management of TCP/IP-based internets:
MIB-II. Los dispositivos también disponen de archivos MIB corporativos privados,
que se pueden cargar en un explorador MIB SNMP.
NOTA: Puede verificar los recuentos de la utilización de la CPU, la utilización de la

memoria y la utilización de sesiones por medio del explorador MIB del SNMP,
tanto en los módulos de seguridad de protección de detección de intrusión (IDP)
como en ScreenOS.
El agente SNMP de Juniper Networks genera las siguientes capturas,

o notificaciones, cuando se producen las condiciones o eventos especificados:
Captura de inicio en frío: El dispositivo de seguridad genera una captura de

inicio en frío una vez que se encuentra operativo después de encenderlo.
Captura por fallo de autenticación de SNMP: El agente SNMP del dispositivo

de seguridad desencadena la captura por fallo de autenticación cuando alguien
intenta conectarse al mismo utilizando una cadena de comunidad SNMP
incorrecta o cuando la dirección IP del host que intenta conectarse no está
definida en una comunidad SNMP. (De forma predeterminada, esta opción está
habilitada).
Capturas por alarmas del sistema: Las situaciones de error en el dispositivo de

seguridad y en el cortafuegos desencadenan alarmas del sistema. Para
identificar las alarmas relacionadas con el hardware, la seguridad y el software,
se han definido tres capturas corporativas. (Para obtener más información
sobre los ajustes de cortafuegos y alarmas, consulte “Fragmentos ICMP” en la
página 4 -243 y “Alarmas de tráfico” en la página 73).
Capturas por alarmas del tráfico: Las alarmas de tráfico se desencadenan

cuando el tráfico excede los umbrales de alarma establecidos en las directivas.
(Para obtener más información sobre la configuración de directivas, consulte
“Directivas” en la página 2 -161).
Protocolo simple de administración de redes 79

“Tipos de alarma de captura” en la página 80 muestra los posibles tipos de alarmas

y los correspondientes números de captura:
Tabla 2: Tipos de alarma de captura
Captura de ID
corporativa Descripción
100 Problemas de hardware
200 Problemas cortafuegos
300 Problemas de software
400 Problemas de tráfico
500 Problemas de VPN
600 Problemas de NSRP
800 Problemas de DRP
900 Problemas de
conmutación por error de
interfaces
1000 Ataques al cortafuegos
NOTA: El administrador de la red debe disponer de una aplicación de administración de

SNMP, como HP OpenView o SunNet Manager para examinar los datos MIB II
SNMP y recibir capturas procedentes de la interfaz fiable o sin confianza. Hay
aplicaciones shareware y freeware para la administración de SNMP disponibles en
Internet.
Los dispositivos de seguridad no se suministran con una configuración

predeterminada para el administrador de SNMP. Si desea configurar su dispositivo
de seguridad para SNMP, primero debe crear comunidades, definir sus host
asociados y asignar permisos (de lectura/escritura o de sólo lectura).
Al crear una comunidad SNMP, se puede especificar si la comunidad es compatible

con SNMPv1, SNMPv2c o con ambas versiones de SNMP, según los requisitos de las
estaciones de administración de SNMP. (Para garantizar la compatibilidad con
versiones anteriores de ScreenOS que solamente funcionan con SNMPv1, de forma
predeterminada los dispositivos de seguridad son compatibles con SNMPv1). Si una
comunidad SNMP admite ambas versiones de SNMP, debe especificarse una
versión para las capturas por cada miembro de la comunidad.
Por razones de seguridad, un miembro de la comunidad SNMP con privilegios de

lectura/escritura solamente puede modificar las siguientes variables en un
sysContact: datos de contacto del administrador del dispositivo de seguridad

por si el administrador de SNMP necesita ponerse en contacto con él. Puede ser
el nombre, la dirección de correo electrónico, el número de teléfono del
administrador de seguridad, o bien la ubicación de su puesto de trabajo en una
oficina, o una combinación de todos estos datos.
sysLocation: la ubicación física del dispositivo de seguridad. Puede ser desde el

nombre de un país, ciudad, edificio, hasta su ubicación exacta en un bastidor
en un centro de operaciones de red (NOC).

sysName: el nombre que los administradores de SNMP utilizan para el

dispositivo de seguridad. Por convención, éste es un nombre de dominio
totalmente clasificado (FQDN), pero puede ser algo más.
snmpEnableAuthenTraps: habilita o inhabilita el agente SNMP en el dispositivo

de seguridad para generar una captura tan pronto como alguien intenta entrar
en contacto con el agente SNMP utilizando un nombre de comunidad SNMP
incorrecto.
ipDefaultTTL: el valor predeterminado que se inserta en el campo

“time-to-live” (TTL) del encabezado IP de los datagramas originados en el
dispositivo de seguridad cuando el protocolo de la capa de transporte no
proporciona un valor de TTL.
ipForwarding: indica si el dispositivo de seguridad reenvía tráfico o no,

a excepción del destinado al dispositivo de seguridad propiamente dicho. De
forma predeterminada, el dispositivo de seguridad indica que éste no reenvía
tráfico.
Vista general de implementación

Juniper Networks ha implementado SNMP en su dispositivo de las siguientes
maneras:
Los administradores SNMP están agrupados en comunidades SNMP. Un

dispositivo puede admitir hasta tres comunidades, con un máximo de ocho
miembros por comunidad.
Un miembro de la comunidad puede ser un host individual o una subred de

hosts, dependiendo de la máscara de red que se haya utilizado al definir el
miembro. De forma predeterminada, el dispositivo de seguridad asigna a un
miembro de la comunidad SNMP una máscara de red de 32 bits
(255.255.255.255), que lo define como un host individual.
Si un miembro de la comunidad SNMP se define como subred, cualquier

dispositivo en esa subred puede consultar el dispositivo de seguridad para
obtener la información MIB del SNMP. Sin embargo, el dispositivo de seguridad
no puede enviar una captura de SNMP a una subred, sino sólo a un host
individual.
Cada comunidad tiene permiso de sólo lectura o de lectura/escritura sobre los

datos MIB II.
Cada comunidad puede trabajar con SNMPv1, SNMPv2c o con ambos. Si una
comunidad SNMP admite ambas versiones de SNMP, debe especificarse una
versión para las capturas por cada miembro de la comunidad.
Se puede permitir o denegar a cada comunidad la recepción de capturas.
Se puede acceder a los datos MIB II y a las capturas a través de cualquier

interfaz física.
Protocolo simple de administración de redes 81

Cada alarma del sistema (un evento del sistema clasificado con un nivel de
gravedad crítico, de alerta o de emergencia) genera una sola captura
corporativa SNMP a cada uno de los host de cada comunidad configurados para
recibir capturas.
El dispositivo de seguridad envía capturas de inicio en frío (“Cold Start”), de

enlace activo (“Link Up”) y de enlace inactivo (“Link Down”) a todos los hosts
de las comunidades configuradas para recibir capturas.
Al especificar la activación de capturas para una comunidad, también se tiene

la opción de permitir alarmas de tráfico.
Puede enviar mensajes SNMP a través de un túnel VPN basado en rutas o

basado en directivas. Para obtener más información, consulte “Túneles VPN
para tráfico autogenerado” en la página 83.
Definición de una comunidad SNMP de lectura/escritura

En este ejemplo creará una comunidad SNMP llamada MAge11. Le asignará
privilegios de lectura/escritura y habilitará a sus miembros para recibir datos MIB II
y capturas. Tiene los dos miembros siguientes: 1.1.1.5/32 y 1.1.1.6/32. Cada uno
de estos miembros tiene una aplicación de administración de SNMP y ambos
ejecutan versiones de SNMP diferentes: SNMPv1 y SNMPv2c. El nombre de
comunidad funciona como una contraseña y es necesario protegerlo.
Proporcionará datos de contacto del administrador local del dispositivo de

seguridad por si algún miembro de la comunidad SNMP necesita entrar en contacto
con él (nombre): al_baker@mage.com. También proporcionará la ubicación del
dispositivo de seguridad—ubicación: 3-15-2. Estos números indican que el
dispositivo se encuentra en el tercer piso, en la decimoquinta fila y en la segunda
posición de esa fila.
También habilitará el agente SNMP para generar capturas siempre que alguien
intente establecer una conexión SNMP ilegítima con el dispositivo de seguridad. Las
capturas por fallo de autenticación son un ajuste global aplicable a todas las
comunidades SNMP y están inhabilitadas de forma predeterminada.
Finalmente, habilitará la posibilidad de gestión de SNMP en ethernet1, una interfaz

que previamente habrá asociado a la zona Trust. Se trata de la interfaz a través de la
cual la aplicación de administración de SNMP se comunica con el agente SNMP del
WebUI
Configuration > Report Settings > SNMP: Introduzca los siguientes ajustes y
haga clic en Apply:
System Contact: al_baker@mage.com

Location: 3-15-2
Enable Authentication Fail Trap: (seleccione)

Configuration > Report Settings > SNMP > New Community: Introduzca los
siguientes ajustes y haga clic en OK:
Community Name: MAge11

Permissions:
Write: (seleccione)
Trap: (seleccione)
Including Traffic Alarms: (anule la selección)
Version: ANY (seleccione)
Hosts IP Address/Netmask and Trap Version:
1.1.1.5/32 v1
1.1.1.6/32 v2c
Network > Interfaces > Edit (para ethernet1): Introduzca los siguientes ajustes
y haga clic en OK:
Service Options:
Management Services: SNMP
CLI
set snmp contact al_baker@mage.com
set snmp location 3-15-2
set snmp auth-trap enable
set snmp community MAge11 read-write trap-on version any
set snmp host Mage 1.1.1.5/32 trap v1
set snmp host Mage 1.1.1.6/32 trap v2
save
Túneles VPN para tráfico autogenerado

Puede utilizar túneles de red privada virtual (VPN) para hacer segura la supervisión
remota de un dispositivo de seguridad desde una dirección IP fija. Utilizando un
túnel VPN se puede proteger el tráfico dirigido a un dispositivo de seguridad o
generado por éste. Los tipos de tráfico iniciados desde un dispositivo de seguridad
pueden ser informes de NetScreen-Global PRO, entradas del registro de eventos
enviadas a syslog y a servidores WebTrends, y capturas SNMP MIB.
Los dispositivos de seguridad de Juniper Networks admiten dos tipos de

configuraciones de túneles de VPN:
VPN basadas en rutas: El dispositivo de seguridad utiliza entradas de la tabla

de rutas para dirigir el tráfico a las interfaces de túnel, asociadas a los túneles
de VPN.
Para enviar tráfico tal como entradas del registro de eventos, informes de
NetScreen-Global PRO o capturas SNMP generadas por el dispositivo de
seguridad a través de un túnel VPN basado en rutas, se debe introducir
manualmente la ruta de destino apropiada. La ruta debe apuntar a la interfaz
de túnel asociada al túnel VPN por el que usted desea que el dispositivo de
seguridad dirija el tráfico. No se requieren directivas.
VPN basadas en directivas: El dispositivo de seguridad utiliza los nombres de

los túneles de VPN indicados expresamente en las directivas para dirigir el
tráfico a través de dichos túneles.
Túneles VPN para tráfico autogenerado 83

Para enviar tráfico autogenerado a través de un túnel VPN basado en directivas,

debe incluir las direcciones de origen y de destino en la directiva. Como
dirección de origen, utilice la dirección IP de una interfaz del dispositivo de
seguridad. Como dirección de destino, utilice la dirección IP del servidor de
almacenamiento o la estación de trabajo del miembro de la comunidad SNMP,
si se encuentra detrás de un dispositivo de seguridad remoto. Si el miembro
remoto de la comunidad SNMP utiliza el cliente VPN NetScreen-Remote para
establecer las conexiones VPN al dispositivo de seguridad local, utilice una
dirección IP interna definida en NetScreen-Remote como dirección de destino.
Si la puerta de enlace remota o la entidad final tiene asignada una dirección IP

dinámica, el dispositivo de seguridad no podrá iniciar la formación de un túnel
VPN, ya que estas direcciones no se pueden predeterminar y, por lo tanto, no se
podrán definir rutas para ellas. En tales casos, el host remoto debe iniciar la
conexión VPN. Una vez establecido un túnel VPN basado en directivas o en rutas,
ambos extremos del túnel pueden iniciar el tráfico, siempre que las directivas lo
permitan. Además, en el caso de una VPN basada en rutas, debe haber una ruta a la
entidad de uno de los extremos a través de una interfaz Tunnel asociada al túnel
VPN, ya sea porque se ha introducido manualmente o porque el dispositivo de
seguridad local recibió la ruta mediante el intercambio de mensajes de
enrutamiento dinámico cuando se estableció el túnel. (Para más información sobre
los protocolos de enrutamiento dinámico, consulte el Volumen 7: Enrutamiento).
También puede utilizar la supervisión de VPN con la opción Rekey o pulsos IKE para
asegurarse de que una vez establecido un túnel, permanecerá activo
independientemente de la actividad de VPN. (Para más información sobre estas
opciones, consulte “Supervisión de VPN” en la página 5 -250 y “Mecanismos de
supervisión” en la página 5 -303).
Por cada tipo de configuración de túnel VPN es posible utilizar los siguientes tipos
de túnel VPN:
Clave manual: El usuario establece manualmente los tres elementos que

definen una asociación de seguridad (SA) en ambos extremos del túnel: un
índice de parámetros de seguridad (SPI), una clave de encriptación y una clave
de autenticación. Para modificar cualquier elemento de la SA, debe introducirse
manualmente en ambos extremos del túnel.
AutoKey IKE con clave compartida: Una o dos claves secretas previamente
compartidas (una para la autenticación y otra para la encriptación) funcionan
como valores de inicialización. El protocolo IKE genera con ellas un juego de
claves simétricas en ambos extremos del túnel; es decir, se utiliza la misma
clave para encriptar y desencriptar. Estas claves se regeneran automáticamente
a intervalos predeterminados.
AutoKey IKE con certificados: Utilizando la infraestructura de claves públicas

(PKI), los participantes situados en ambos extremos del túnel utilizan un
certificado digital (para la autenticación) y un par de claves pública/privada RSA
(para la encriptación). La encriptación es asimétrica; es decir, una de las claves
del par se utiliza para encriptar y la otra para desencriptar.
NOTA: Para obtener una descripción completa de los túneles VPN, consulte el Volume 5:
Virtual Private Networks. Para obtener más información sobre NetScreen-Remote,
consulte el manual NetScreen-Remote VPN Client Administrator Guide.
84 Túneles VPN para tráfico autogenerado

Ejemplo: Tráfico autogenerado a través de túnel basado en rutas

La Figura 16 muestra un ejemplo en el cual configurará un dispositivo de seguridad
local (dispositivo A) para enviar capturas SNMPv1 MIB e informes syslog a través de
un túnel VPN AutoKey IKE basado en rutas a un miembro de una comunidad SNMP
ubicado tras un dispositivo de seguridad remoto (Dispositivo B). El túnel utiliza una
clave compartida (Ci5y0a1aAG) para la autenticación del origen de los datos y el
nivel de seguridad predefinido como “Compatible” para las propuestas de las fases
1 y 2. Como administrador local del dispositivo A, deberá crear la interfaz tunnel.1
y asociarla a vpn1. Además, junto con el administrador del dispositivo B, definirá
las siguientes ID de proxy que se muestran en la Tabla 3:
Tabla 3: ID de proxy para el túnel basado en rutas
Dispositivo A Dispositivo B
IP local 10.1.1.1/32 IP local 10.2.2.2/32
IP remota 10.2.2.2/32 IP remota 10.1.1.1/32
Servicio Any Servicio Any
En este ejemplo se enlaza ethernet1 a la zona Trust y ethernet3 a la zona Untrust.

La dirección IP predeterminada para la puerta de enlace es 1.1.1.250. Todas las
zonas se encuentran en el dominio de enrutamiento trust-vr.
Figura 16: Tráfico a través de túnel basado en rutas
Zona Untrust
Ubicación local
Zona Trust
ethernet1 Administrador de
10.1.1.1/24 tunnel.1, sin numerar SNMP y servidor
NAT ethernet3, 1.1.1.1/24 Syslog 10.2.2.2
puerta de enlace, 1.1.1.250
Dispositivo A Internet
LAN LAN
10.1.1.0/24 10.2.2.0/24
TÚNEL: VPN1 Dispositivo B

ethernet1
ethernet3, 2.2.2.2/24 10.2.2.1/24
NAT
tunnel.1, sin numerar
Ubicación remota
Zona Untrust Zona Trust
El administrador remoto del Dispositivo B utiliza ajustes similares para definir aquel
extremo del túnel de VPN AutoKey IKE, de forma que la clave compartida, las
propuestas y las ID de proxy coinciden.
También puede configurar una comunidad SNMP llamada “remote_admin” con

permisos de lectura/escritura y permitir que reciba capturas. Definirá el host en
10.2.2.2/32 como miembro de la comunidad.

NOTA: En este ejemplo se parte de la base de que el administrador remoto ya ha

configurado el servidor syslog y una aplicación de administración de SNMP
compatible con SNMPv1. Cuando el administrador remoto configura el túnel VPN
en su dispositivo de seguridad, utiliza 1.1.1.1 como puerta de enlace remota y
10.1.1.1 como dirección de destino.
WebUI (dispositivo A)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT (seleccione)
Cuando el administrador remoto configure la administración SNMP, deberá

introducir 10.1.1.1 en el campo Remote SNMP Agent. Ésta será la dirección a la
que la administración de SNMP enviará las consultas.
haga clic en OK:
Zone Name: Untrust

Service Options:
clic en OK:

2. Syslog y SNMP
haga clic en Apply:

No.: Seleccione 1 para indicar que va a agregar un servidor syslog.
Port: 514
Security Facility: auth/sec
Facility: Local0

Community Name: remote_admin

Permissions:
Write: (seleccione)
Trap: (seleccione)
Version: V1
Hosts IP Address/Netmask:
10.2.2.2/32 V1
Trap Version:
V1
3. VPN
VPN Name: vpn1

Remote Gateway: Create a Simple Gateway: (seleccione)
Gateway Name: to_admin
Type: Static IP, Address/Hostname: 2.2.2.2
Preshared Key: Ci5y0a1aAG
Outgoing interface: ethernet3
> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en

Return para regresar a la página de configuración básica de AutoKey IKE:
Bind to: Tunnel Interface: (seleccione), tunnel.1

Proxy-ID: (seleccione)
Local IP/Netmask: 10.1.1.1/32
Remote IP/Netmask: 10.2.2.2/32
Service: ANY
4. Rutas

Interface: tunnel.1

Gateway IP Address: (seleccione) 1.1.1.250

CLI (dispositivo A)
1. Interfaces
NOTA: Cuando el administrador remoto configure la administración SNMP, deberá

De forma predeterminada, cualquier interfaz que se asocie a la zona Trust estará

2. VPN
set ike gateway to_admin address 2.2.2.2 outgoing-interface ethernet3 preshare
Ci5y0a1aAG sec-level compatible
set vpn vpn1 gateway to_admin sec-level compatible
set vpn vpn1 proxy-id local-ip 10.1.1.1/32 remote-ip 10.2.2.2/32 any
3. Syslog y SNMP
set syslog config 10.2.2.2 auth/sec local0
set syslog enable
set snmp community remote_admin read-write trap-on version v1
set snmp host remote_admin 10.2.2.2/32
4. Rutas
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
save
WebUI (dispositivo B)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT

haga clic en OK:
Zone Name: Untrust

clic en OK:

2. Direcciones
Address Name: addr1

IP Address/Domain Name: IP/Netmask: 10.2.2.2/32
Zone: Trust
Address Name: ns-a

IP Address/Domain Name: IP/Netmask: 10.1.1.1/32
Zone: Untrust
Directiva > Elementos de directiva > Servicios > Grupos > New: Introduzca
el siguiente nombre de grupo, mueva los siguientes servicios y haga clic en OK:
Group Name: s-grp1
Seleccione Syslog y utilice el botón << para mover el servicio de la

Seleccione SNMP y utilice el botón << para mover el servicio de la

4. VPN
VPN Name: vpn1


> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en Return
para regresar a la página de configuración básica de AutoKey IKE:

Service: Any
5. Rutas

Interface: tunnel.1

6. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), addr1
Address Book Entry: (seleccione), ns-a
Service: s-grp1
Action: Permit
Policies > (From: Untrust, To: Trust) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Service: s-grp1
Action: Permit

CLI (dispositivo B)
1. Interfaces
2. Direcciones
set address trust addr1 10.2.2.2/32
set address untrust ns-a 10.1.1.1/32
set group service s-grp1
set group service s-grp1 add syslog
set group service s-grp1 add snmp
4. VPN
5. Rutas
6. Directivas
set policy top from trust to untrust addr1 ns-a s-grp1 permit
set policy top from untrust to trust ns-a addr1 s-grp1 permit
save
Ejemplo: Tráfico autogenerado a través de túnel basado en directivas

En este ejemplo (que se muestra en la Figura 17), configurará un dispositivo de
seguridad local (dispositivo A) para enviar capturas SNMPv2c MIB e informes syslog
a través de un túnel (vpn1) VPN AutoKey IKE basado en directivas a un miembro de
una comunidad SNMP ubicado tras un dispositivo de seguridad remoto (dispositivo
B). El túnel utiliza una clave previamente compartida (Ci5y0a1aAG) para la
autenticación del origen de los datos y el nivel de seguridad predefinido como
“Compatible” para las propuestas de las fases 1 y 2.
NOTA: En este ejemplo se parte de la base de que el administrador remoto ya ha

configurado el servidor syslog y una aplicación de administración de SNMP
compatible con SNMPv2c. Cuando el administrador remoto configura el túnel VPN
en su dispositivo de seguridad, utiliza 1.1.1.1 como puerta de enlace remota y
10.1.1.1 como dirección de destino.

Tanto usted como el administrador remoto asocian ethernet1 a la zona Trust y

ethernet3 a la zona Untrust de los dispositivos A y B. La dirección IP
predeterminada de la pasarela de enlace para el dispositivo A es 1.1.1.250. La
dirección IP predeterminada de la puerta de enlace para el dispositivo B es
2.2.2.250. Todas las zonas se encuentran en el dominio de enrutamiento trust-vr.
Figura 17: Tráfico a través de túnel basado en directivas
Ubicación local Zona Untrust

Zona Trust
Administrador de
ethernet1 SNMP y servidor
10.1.1.1/24 ethernet3, 1.1.1.1/24 Syslog 10.2.2.2
NAT
Dispositivo A Internet
LAN LAN
10.1.1.0/24 10.2.2.0/24
TÚNEL: VPN1 Dispositivo B

ethernet1
ethernet3, 2.2.2.2/24 10.2.2.1/24
NAT
Zona Untrust Ubicación remota Zona Trust
También puede configurar una comunidad SNMP llamada “remote_admin” con

permisos de lectura/escritura y permitir que reciba capturas. Definirá el host en
10.2.2.2/32 como miembro de la comunidad.
Las directivas de entrada y salida del dispositivo A coinciden con las del
dispositivo B. Las direcciones y servicios utilizados en las directivas son:
10.1.1.1/32, la dirección de la interfaz de zona Trust en el dispositivo A
10.2.2.2/32, la dirección del host para el miembro de la comunidad SNMP y el

servidor syslog
Grupo de servicios llamado “s-grp1”, que contiene los servicios SNMP y syslog

A partir de las directrices que usted y el administrador hayan creado para el

dispositivo B, los dos dispositivos NetScreen derivarán las siguientes ID de proxy
para vpn1:
Tabla 4: ID de proxy para el túnel basado en directivas
IP local 10.1.1.1/32 IP local 10.2.2.2/32
IP remota 10.2.2.2/32 IP remota 10.1.1.1/32
Servicio Any Servicio Any
NOTA: El dispositivo de seguridad trata cada grupo de servicios como “any” en las ID de
proxy.
WebUI (dispositivo A)
1. Interfaces, zonas de seguridad
haga clic en OK:
Zone Name: Trust

NOTA: Cuando el administrador remoto configure la administración SNMP, deberá

De forma predeterminada, cualquier interfaz que se asocie a la zona Trust estará

haga clic en OK:
Zone Name: Untrust

Service Options:
2. Direcciones
Address Name: trust_int

IP/Netmask: 10.1.1.1/32
Zone: Trust

Address Name: remote_admin

IP/Netmask: 10.2.2.2/32
Zone: Untrust
Directiva > Elementos de directiva > Servicios > Grupos > New: Introduzca
el siguiente nombre de grupo, mueva los siguientes servicios y haga clic en OK:
Group Name: s-grp1


4. VPN
VPN Name: vpn1

5. Syslog y SNMP
haga clic en Apply:

Source Interface: ethernet1
No.: Seleccione 1 para indicar que va a agregar un servidor syslog.
Port: 514
Security Facility: auth/sec
Facility: Local0

Community Name: remote_admin

Permissions:
Write: (seleccione)
Trap: (seleccione)
Version: V2C
Hosts IP Address/Netmask:
10.2.2.2/32 V2C
Trap Version:
V2C
Source interface:
ethernet1 (seleccione)
Configuration > Report Settings > SNMP: Introduzca los siguientes datos y
haga clic en Apply:
Enable Authentication Fail Trap: (seleccione)

6. Ruta

7. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), trust_int
Address Book Entry: (seleccione), remote_admin
Service: s-grp1
Action: Tunnel
Tunnel VPN: vpn1
CLI (dispositivo A)

2. Direcciones
set address trust trust_int 10.1.1.1/32
set address untrust remote_admin 10.2.2.2/32
4. VPN
5. Syslog y SNMP
set syslog config 10.2.2.2 auth/sec local0
set syslog src-interface ethernet1
set syslog enable
set snmp community remote_admin read-write trap-on version v2c
set snmp host remote_admin 10.2.2.2/32 src-interface ethernet1
6. Ruta
7. Directivas
set policy top from trust to untrust trust_int remote_admin s-grp1 tunnel vpn vpn1
set policy top from untrust to trust remote_admin trust_int s-grp1 tunnel vpn vpn1
save
WebUI (dispositivo B)
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Direcciones
Address Name: addr1

IP/Netmask: 10.2.2.2/32
Zone: Trust

Address Name: ns-a

IP/Netmask: 10.1.1.1/32
Zone: Untrust
Policy > Policy Elements > Services > Group: Introduzca el siguiente nombre
de grupo, mueva los siguientes servicios y haga clic en OK:
Group Name: s-grp1


4. VPN
VPN Name: vpn1

Type: Static IP, IP Address: 1.1.1.1
Outgoing interface: ethernet3
5. Ruta
Network > Routing > Routing Table > trust-vr New: Introduzca los siguientes

6. Directivas
haga clic en OK:
Source Address:
Service: s-grp1
Action: Tunnel
Tunnel VPN: vpn1

CLI (dispositivo B)
2. Direcciones
set address trust addr1 10.2.2.2/32
set address untrust ns-a 10.1.1.1/32
4. VPN
Ci5y0a1sec-level compatible
5. Ruta
6. Directivas
set policy top from trust to untrust addr1 ns-a s-grp1 tunnel vpn vpn1
set policy top from untrust to trust ns-a addr1 s-grp1 tunnel vpn vpn1
save
Visualizar contadores de pantalla

Los dispositivos de seguridad Juniper Networks disponen de contadores de pantalla,
hardware y flujos para supervisar el tráfico. Estos contadores ofrecen información
de proceso sobre las zonas e interfaces especificadas y permiten verificar la
configuración de cualquier directiva deseada.
La Tabla 5 muestra los contadores de pantalla para supervisar el comportamiento

general del cortafuegos y visualizar la cantidad de tráfico afectada por las directivas
especificadas.
Tabla 5: Contadores de pantalla
Contador Descripción
Bad IP Option Protection Número de tramas desechadas debido a las opciones IP mal formadas o
incompletas
Dst IP-based session limiting Número de sesiones descartadas después de alcanzar el umbral de sesión
FIN bit with no ACK bit Número de paquetes detectados y descartados con una combinación de flags no
permitida
Fragmented packet protection Número de fragmentos de paquetes de IP bloqueados
HTTP Component Blocked Número de paquetes bloqueados con componentes de HTTP
HTTP Component Blocking for ActiveX Número de componentes de ActiveX bloqueados
controls
98 Visualizar contadores de pantalla

HTTP Component Blocking for .exe files Número de paquetes HTTP bloqueados con archivos .exe
HTTP Component Blocking for Java Número de componentes Java bloqueados
applets
HTTP Component Blocking for .zip files Número de paquetes HTTP bloqueados con archivos .zip
ICMP Flood Protection Número de paquetes ICMP bloqueados como parte de una inundación ICMP
ICMP Fragment Número de tramas ICMP con el flag More Fragments ajustado o con un offset
indicado en el campo de offset
IP Spoofing Attack Protection Número de direcciones IP bloqueadas como parte de un ataque de simulación
de IP
IP Sweep Protection Número de paquetes de ataque de limpieza de IP detectados y bloqueados
Land Attack Protection Número de paquetes bloqueados como parte de una sospecha de ataque terrestre
Large ICMP Packet Número de tramas ICMP detectadas con una longitud de IP superior a 1024
Limit Session Número de paquetes no entregados por haberse alcanzado el límite de sesión
Loose Src Route IP Option Número de paquetes de IP detectados con la opción Loose Source Route
habilitada
Malicious URL Protection Número de direcciones URL bloqueadas por existir la sospecha de que son
maliciosas
Ping-of-Death Protection Número de paquetes ICMP sospechosos y rechazados por su tamaño excesivo o
irregular
Port Scan Protection Número de análisis de puerto detectados y bloqueados
Record Route IP Option Número de tramas detectadas con la opción Record Route habilitada
Security IP Option Número de tramas descartadas con la opción IP Security ajustada
Src IP-based session limiting Número de sesiones descartadas después de alcanzar el umbral de sesión
Source Route IP Option Filter Número de rutas de origen IP filtradas
Stream IP Option Número de paquetes descartados con el identificador IP Stream ajustado
Strict Src Route IP Option Número de paquetes detectados con la opción Strict Source Route habilitada
SYN-ACK-ACK-Proxy DoS Número de paquetes bloqueados debido a la opción SYN-ACK-ACK-proxy DoS
SCREEN
SYN and FIN bits set Número de paquetes detectados con una combinación de flags no permitida
SYN Flood Protection Número de paquetes SYN detectados cuando se sospecha de una inundación SYN
SYN Fragment Detection Número de fragmentos de paquete descartados como parte de una sospecha de
ataque de fragmentos SYN
Timestamp IP Option Número de paquetes IP descartados con la opción Internet Timestamp ajustada
TCP Packet without Flag Número de paquetes no permitidos descartados sin campo de flags o con el
campo mal formado
Teardrop Attack Protection Número de paquetes bloqueados como parte de un ataque Teardrop
UDP Flood Protection Número de paquetes UDP descartados cuando se sospecha de una inundación
UDP
Unknown Protocol Protection Número de paquetes bloqueados como parte de un protocolo desconocido
WinNuke Attack Protection Número de paquetes detectados como parte de una sospecha de ataque WinNuke
Visualizar contadores de pantalla 99

La Tabla 6 en la página 100 muestra los contadores de hardware para supervisar el

funcionamiento del hardware y los paquetes con errores:
Tabla 6: Contadores de hardware
drop vlan Número de paquetes descartados por falta de etiquetas VLAN, una subinterfaz no definida o porque
no se habilitó el truncamiento de VLAN mientras el dispositivo de seguridad estaba en modo
transparente
early frame Número de contadores utilizados en una administración de descriptores de búfer de controlador
Ethernet
in align err Número de paquetes entrantes con un error de alineación en la secuencia de bits
in bytes Número de bytes recibidos
in coll err Número de paquetes de colisión entrantes
in crc err Número de paquetes entrantes con un error de comprobación de redundancia cíclica (CRC)
in dma err Número de paquetes entrantes con un error de acceso directo de memoria (DMA)
in misc err Número de paquetes entrantes con errores de otro tipo
in no buffer Número de paquetes no recibidos porque los búferes no están disponibles
in overrun Número de paquetes transmitidos por exceso (desbordamiento de búfer)
in packets Número de paquetes recibidos
in short frame Número de paquetes entrantes con una trama Ethernet menor de 64 bytes (incluyendo la suma de
comprobación de trama)
in underrun Número de paquetes transmitidos por defecto
late frame Número de contadores utilizados en una administración de descriptores de búfer de controlador
Ethernet
out bs pak Número de paquetes retenido en almacenamiento en segundo plano mientras se busca una dirección
MAC desconocida
Cuando el dispositivo de seguridad reenvía un paquete, primero comprueba si la dirección MAC de
destino se encuentra en la tabla ARP. Si no encuentra la dirección MAC de destino en la tabla ARP, el
dispositivo de seguridad envía una petición ARP a la red. Si el dispositivo de seguridad recibe otro
paquete con la misma dirección MAC de destino antes de recibir una respuesta a la primera petición
ARP, aumenta el contador out bs pak en uno.
out bytes Número de bytes enviados
out coll err Número de paquetes de colisión salientes
out cs lost Número de paquetes salientes descartados porque el protocolo Carrier Sense Multiple Access/Collision
Detect (CSMA/CD) perdió la señal
out defer Número de paquetes salientes aplazados
out discard Número de paquetes salientes descartados
out heartbeat Número de paquetes de pulso salientes
out misc err Número de paquetes salientes con errores de otro tipo
out no buffer Número de paquetes no enviados porque los búferes no están disponibles
out packets Número de paquetes enviados
re xmt limit Número de paquetes descartados al exceder el límite de retransmisión mientras una interfaz estaba
funcionando en semidúplex

La Tabla 7 en la página 101 muestra los contadores de flujo para la supervisión del
número de paquetes inspeccionados a nivel de flujo.
Tabla 7: Contadores de flujo
address spoof Número de paquetes sospechosos de ataque de simulación de dirección recibidos
auth deny Número de veces que se ha rechazado la autenticación de usuario
auth fail Número de veces que ha fallado la autenticación de usuario
big bkstr Número de paquetes que son demasiado grandes para el búfer en el almacenamiento en segundo
plano ARP mientras se espera la resolución de la dirección MAC a IP
connections Número de sesiones establecidas desde el último arranque
encrypt fail Número de paquetes Point-to-Point Tunneling Protocol (PPTP) con errores
*icmp broadcast Número de difusiones ICMP recibidas
icmp flood Número de paquetes ICMP contabilizados justo por debajo del umbral de inundación ICMP
illegal pak Número de paquetes descartados porque no cumplen las normas de protocolo
in arp req Número de paquetes de petición ARP entrantes
in arp resp Número de paquetes de petición ARP salientes
in bytes Número de bytes recibidos
in icmp Número de paquetes de Internet Control Message Protocol (ICMP) recibidos
in other Número de paquetes entrantes con un tipo Ethernet distinto
in packets Número de paquetes recibidos
in self Número de paquetes dirigidos a la dirección IP de administración
*in un auth Número de paquetes TCP, UDP e ICMP entrantes no autorizados
*in unk prot Número de paquetes entrantes que utilizan un protocolo Ethernet desconocido
in vlan Número de paquetes vlan entrantes
in vpn Número de paquetes IPSec recibidos
invalid zone Número de paquetes destinados a una zona de seguridad no válida
ip sweep Número de paquetes recibidos y descartados más allá del umbral de limpieza de IP especificado
land attack Número de paquetes sospechosos de ataque terrestre recibidos
loopback drop Número de paquetes descartados porque no se pueden someter a un bucle de retroceso a través de un
dispositivo de seguridad. Un ejemplo de sesión de bucle de retroceso sería cuando un host en la zona
Trust envía datos a una dirección MIP o VIP asignada a un servidor que también se encuentra en la
zona Trust. El dispositivo de seguridad crea una sesión de bucle de retroceso que dirige este tráfico
desde el host al servidor MIP o VIP.
mac relearn Número de veces que la tabla de aprendizaje de direcciones MAC tuvo que volver a memorizar la
interfaz asociada a una dirección MAC porque la ubicación de dicha dirección cambió
mac tbl full Número de veces que la tabla de aprendizaje de direcciones MAC se llenó completamente
mal url Número de paquetes bloqueados destinados a una dirección URL que se considera maliciosa
*misc prot Número de paquetes que utilizan un protocolo distinto de TCP, UDP o ICMP
mp fail Número de veces que se produjo un problema al enviar un mensaje PCI entre el módulo procesador
master y el módulo procesador
no conn Número de paquetes descartados porque las conexiones Network Address Translation (NAT) no
estaban disponibles
no dip Número de paquetes descartados porque las direcciones Dynamic IP (DIP) no estaban disponibles

no frag netpak Número de veces que el espacio disponible en el búfer netpak ha caído por debajo del 70%
*no frag sess Número de veces que las sesiones fragmentadas han superado la mitad del número máximo de
sesiones NAT
no g-parent Número de paquetes descartados debido a que no se encontró la conexión principal
no gate Número de paquetes descartados porque no había puerta de enlace disponible
no gate sess Número de sesiones terminadas porque no había puertas de enlace para ellas en el cortafuegos
no map Número de paquetes descartados debido a que no había una asignación a la zona fiable
no nat vector Número de paquetes descartados porque la conexión Network Address Translation (NAT) no estaba
disponible para la puerta
*no nsp tunnel Número de paquetes descartados enviados a una interfaz de túnel sin túnel de VPN asociado
no route Número de paquetes que no se pueden enrutar recibidos
no sa Número de paquetes descartados porque no hay definidas Asociaciones de seguridad (SA)
no sa policy Número de paquetes descartados debido a que no había ninguna directiva asociada con una SA
*no xmit vpnf Número de paquetes VPN descartados debido a la fragmentación
null zone Número de paquetes descartados enviados erróneamente a una interfaz asociada a la zona Null
nvec err Número de paquetes descartados debido a un error de vector NAT
out bytes Número de bytes enviados
out packets Número de paquetes enviados
out vlan Número de paquetes de vlan salientes
ping of death Número de paquetes recibidos sospechosos de ataque tipo Ping of Death
policy deny Número de paquetes rechazados por una directiva definida
port scan Número de paquetes contabilizados como intentos de análisis de puertos
proc sess Número de veces que las sesiones totales en un módulo procesador excedieron el umbral máximo
sa inactive Número de paquetes descartados por una SA inactiva
sa policy deny Número de paquetes rechazados por una directiva de SA
sessn thresh El umbral para el número máximo de sesiones
*slow mac Número de tramas con direcciones MAC eran lentas de resolver
src route Número de paquetes descartados debido a la opción filter source route
syn frag Número de paquetes SYN descartados por causa de la fragmentación
tcp out of seq Número de segmentos TCP recibidos cuyo número de secuencia se encuentra fuera de un rango
aceptable
tcp proxy Número de paquetes descartados por haber utilizado un proxy TCP, como la opción de SYN flood
protection o autenticación de usuario
teardrop Número de paquetes bloqueados como parte de un posible ataque Teardrop
tiny frag Número de paquetes pequeños fragmentados recibidos
trmn drop Número de paquetes descartados por la administración de tráfico
trmng queue Número de paquetes que esperan en cola
udp flood Número de paquetes UDP contabilizados hacia el umbral de inundación UDP
url block Número de peticiones HTTP que han sido bloqueadas
winnuke Número de paquetes WinNuke recibidos

wrong intf Número de mensajes de creación de sesión enviados desde un módulo procesador al módulo
procesador master
wrong slot Número de paquetes enviados erróneamente a un modulo de procesador incorrecto
NOTA: Para más información sobre el protocolo CSMA/CD (Carrier Sense Multiple
Access/Collision Detect), consulte la norma IEEE 802.3 disponible en
http://standards.ieee.org.
En este ejemplo veremos los contadores de pantalla del dispositivo para la zona
Trust.
WebUI
Reports > Counters > Zone Screen: Seleccione Trust en la lista desplegable
Zone.
CLI
get counter screen zone trust


Índice
A D
administración DIP .................................................................................101
CLI .............................................................................10 Direcciones IP
restringir ...................................................................45 IP administrativa .....................................................33
WebUI .........................................................................2 Servidores de NetScreen-Security Manager .........26
administrador raíz, inicio de sesión ............................45 direcciones IP de cliente de administración ...............44
Agente de NSM ........................................................23, 24 directiva de SA .............................................................102
comunicar eventos ..................................................26 dispositivos, restablecer a los ajustes
habilitar ....................................................................25 predeterminados de fábrica ......................................44
ajustes de configuración, requisitos del explorador ....2 distribución del protocolo, comunicar a
ajustes predeterminados de fábrica, restablecer .......44 NetScreen-Security Manager .....................................26
alarmas
alerta de correo electrónico ...................................73 E
comunicar a NetScreen-Security Manager ...........26 email alert notification ..................................................78
tráfico ............................................................... 73 a 76 error de vector NAT .....................................................102
umbrales ..................................................................73 Estadísticas, comunicar a NSM ....................................27
alarmas de tráfico .................................................. 73 a 76
almacenamiento en segundo plano ..........................100 F
almacenamiento flash interno .....................................60 filtrar ruta de origen ....................................................102
Archivos de ayuda ...........................................................2
asociaciones de seguridad (SA) ..................................102 H
HTTP, ID de sesión ..........................................................4
C
cables serie .....................................................................19 I
capturas SNMP ID de sesión ......................................................................4
100, problemas de hardware ................................80 Ident-Reset......................................................................30
200, problemas de cortafuegos .............................80 iniciar sesión ..........................................................59 a 73
300, problemas de software ..................................80 CompactFlash (PCMCIA).........................................60
400, problemas de tráfico ......................................80 consola......................................................................60
500, problemas de VPN .........................................80 correo electrónico ...................................................60
alarma de tráfico .....................................................79 interno ......................................................................60
alarma del sistema ..................................................79 NetScreen-Security Manager ..................................26
permitir o denegar ..................................................81 registro de eventos ..................................................61
tipos ..........................................................................80 registro de recuperación de activos ......................72
claves manuales, VPN .............................................46, 84 registro propio .........................................................70
CLI ...................................................................................10 SNMP ..................................................................60, 78
CompactFlash ................................................................60 syslog ..................................................................60, 76
comunidad SNMP USB............................................................................60
privada......................................................................82 WebTrends .........................................................60, 77
pública ......................................................................82 in-short, error ...............................................................100
conexión principal .......................................................102 Interfaces
consola ............................................................................60 gestionables .............................................................33
contraseñas opciones de administración ...................................29
administrador raíz ...................................................43 interfaz de línea de comandos
olvidadas ..................................................................41 véase CLI
Índice IX-I
interfaz de usuario VLAN1.......................................................................30

véase WebUI WebUI .......................................................................29
Interfaz MGT, opciones de administración ................. 30 Opciones de administración de SSL ............................30
IP de administración ..................................................... 33 Opciones de administración de Telnet .......................29
IP de servidor SMTP ...................................................... 76 Opciones de administración del comando ping ........30
IP dinámico
véase DIP P
paquetes .......................................................................102
M ataque de simulación de dirección .....................101
Management Information Base II colisión ...................................................................100
véase MIB II descartados ....................................................101, 102
mensajes entrantes ................................................................100
alerta ......................................................................... 61 fragmentados.........................................................102
críticos ...................................................................... 61 IPSec .......................................................................101
depurar ..................................................................... 61 land attack .............................................................101
emergencia .............................................................. 61 no enrutables .........................................................102
error .......................................................................... 61 Protocolo de encapsulamiento de punto a punto
información ............................................................. 61 (PPTP) ...................................................................101
notificación .............................................................. 61 Protocolo de mensajes de control de Internet
WebTrends .............................................................. 78 (ICMP) .............................................................99, 101
métodos de administración que no se pueden recibir......................................100
CLI ............................................................................. 10 rechazados .............................................................102
consola ..................................................................... 19 recibidos .................................................100, 101, 102
SSL .............................................................................. 5 Traducción de direcciones de red (NAT) ............101
Telnet........................................................................ 10 transmitidos por defecto (underrun) ..................100
WebUI ........................................................................ 2 PCMCIA ...........................................................................60
MIB II ........................................................................ 29, 79 PKI keys ............................................................................6
Modo transparente, opciones de administración ...... 30 Protocolo de encapsulamiento de punto a punto
(PPTP) ........................................................................101
N Protocolo de transferencia de hipertexto (HTTP),
NetScreen-Security Manager ID de sesión ...................................................................4
administración del sistema ........................ 23, 24, 26 puertos de módem ..................................................20, 22
Agente de NSM .................................................. 23, 26 puertos, módem ......................................................20, 22
comunicar eventos ........................................... 26, 27
configuración de la conectividad inicial ............... 24 R
definición ................................................................. 23 RADIUS ...........................................................................42
habilitación del agente de NSM ............................. 25 redes privadas virtuales
iniciar sesión ............................................................ 26 véase VPNs
interfaz de usuario .................................................. 23 registro de eventos ........................................................61
opciones de administración................................... 30 registro de recuperación de activos .............................72
notificación de alerta por correo electrónico ............. 76 registro propio................................................................70
requisitos del explorador ................................................2
O requisitos del explorador web ........................................2
opciones de administración ruta de origen ...............................................................102
gestionables ............................................................. 33
interfaces ................................................................. 29 S
MGT, interfaz ........................................................... 30 SA inactiva ....................................................................102
modo transparente ................................................. 30 SCP
NetScreen-Security Manager ................................. 30 ejemplo de comando del cliente ...........................19
ping ........................................................................... 30 habilitar ....................................................................18
SNMP ........................................................................ 29 secuencia de bits .........................................................100
SSH ........................................................................... 29 Secure Copy
SSL ............................................................................ 30 Veáse SCP
Telnet........................................................................ 29
IX-II Índice
Índice
Secure Shell T
Consulte SSH TCP proxy .....................................................................102
Secure Sockets Layer Telnet ...............................................................................10
véase SSL Telnet, inicio de sesión mediante ................................11
serie, cables ....................................................................19 Traducción de direcciones de red (NAT) ....................101
sistemas virtuales tráfico administrativo ....................................................30
administradores ......................................................36
administradores de sólo lectura ............................36 U
SNMP ........................................................................29, 78 USB ..................................................................................60
captura de inicio en frío .........................................79 usuarios, múltiples administrativos .............................35
configuración ...........................................................82
encriptación .......................................................82, 83 V
opciones de administración ...................................29 VLAN1, opciones de administración ...........................30
SSH .......................................................................... 11 a 16 VPN
autenticación mediante contraseña ......................14 AutoKey IKE .......................................................46, 84
autenticación mediante PKA .................................14 clave manual ............................................................84
cargar claves públicas, CLI .....................................15 claves manuales ......................................................46
cargar claves públicas, TFTP ............................15, 18 para tráfico administrativo .....................................83
cargar claves públicas, WebUI ...............................15 VPN AutoKey IKE .....................................................46, 84
forzar la autenticación mediante PKA
exclusivamente .....................................................16 W
inicios de sesión automatizados ............................17 WebTrends ................................................................60, 77
opciones de administración ...................................29 encriptación .......................................................77, 83
PKA ...........................................................................15 mensajes ..................................................................78
prioridad del método de autenticación ................16 WebUI................................................................................2
procedimiento de conexión ...................................12 Archivos de ayuda .....................................................2
SSL .....................................................................................5 opciones de administración ...................................29
SSL Handshake Protocol
véase SSLHP
SSLHP................................................................................5
syslog ..............................................................................60
encriptación .............................................................83
host ...........................................................................76
mensajes ..................................................................76
nombre de host .....................................77, 78, 86, 94
puerto ...........................................................77, 86, 94
servicio de seguridad ..................................77, 86, 94
utilidad ..........................................................77, 86, 94
Índice IX-III
IX-IV Índice
Volumen 4:
Detección ataques y mecanismos de defensa

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Copyright Notice
without notice.
FCC Statement
Disclaimer
ii
Contenido
Convenciones de interfaz de línea de comandos ...................................... xi
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
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
Contenido iii
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
(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
iv Contenido
Contenido
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
usuario .....................................................................................163
Objetos de ataque de la firma de la secuencia de TCP ...........................165
usuario .....................................................................................166
Contenido v
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
pasivo .............................................................................................181
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
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
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
vi Contenido
Contenido
Establecimiento de las opciones de registro ....................................203

Establecimiento de las opciones de tiempo de espera.....................203
Configuración de las normas de exclusión ...................................................205
Adición de la base de normas de exclusión ...........................................206
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
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
Servicios .........................................................................................213
Establecimiento del funcionamiento......................................................213
Establecimiento de acciones..................................................................213
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 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
Configuración de grupos estáticos...................................................230
Configuración de grupos dinámicos ................................................232
Ejemplo: Creación de un grupo dinámico........................................233
Contenido vii
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
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
viii Contenido
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.
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.
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.
ix
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.

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


de una dirección:
Address Name: dir_1

Zone: Untrust



En ejemplos:




Convenciones del documento xi






zona de seguridad

Internet

Interfaz de túnel
Servidor
Túnel VPN
Enrutador
Concentrador
Convenciones del documento xiii




xiv Asistencia y documentación técnica

Capítulo 1
Protección de una red
Puede haber numerosos motivos para entrar a una red protegida. La siguiente lista
contiene algunos objetivos comunes:
Obtener el siguiente tipo de información sobre la red protegida:
Topología
Direcciones IP de los hosts activos
Números de los puertos activos de los hosts activos
Sistema operativo de los hosts activos
Colapsar un host de una red protegida con tráfico fantasma para inducir una
denegación de servicio (DoS)
Colapsar una red protegida con tráfico fantasma para inducir un DoS en toda la
red
Colapsar un cortafuegos con tráfico fantasma e inducir un DoS para la red a la

que protege
Provocar daños y robar datos de un host en una red protegida
Conseguir acceso a un host en una red protegida para obtener información
Lograr el control de un host para aprovechar otras vulnerabilidades
Apoderarse de un cortafuegos para controlar el acceso a la red a la que protege
ScreenOS ofrece herramientas de detección y defensa que permiten descubrir y

frustrar los esfuerzos de los hackers por alcanzar los objetivos mencionados
anteriormente cuando intentan atacar una red protegida con un dispositivo de
seguridad Juniper Networks.
1
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.
2 Etapas de un ataque
Capítulo 1: Protección de una red
Juniper Networks ofrece diversos métodos de detección y mecanismos de defensa a

nivel de directivas y de zona para combatir los ataques a vulnerabilidades en todas
sus etapas de ejecución:
Opciones SCREEN a nivel de zona
Las directivas del cortafuegos en los niveles de directivas interzonales,

intrazonales y (superzonales representan aquí las directivas globales, donde no
se hace referencia a las zonas de seguridad)
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.
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
Mecanismos de detección y defensa 3

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
4 Mecanismos de detección y defensa

Capítulo 1: Protección de una red
Protocolos desconocidos
Fragmentos de paquetes IP
Fragmentos SYN
Los ajustes de protección de red de ScreenOS operan en dos niveles: zona de

seguridad y directivas. El dispositivo de seguridad de Juniper Networks ofrece
defensas contra ataques DoS y medidas de bloqueo de reconocimiento a nivel de
zona de seguridad. En el área de supervisión y filtrado de contenidos, el dispositivo
de seguridad aplica un reensamblaje de fragmentos a nivel de zona y un análisis
antivirus (AV) y un filtrado de localizadores de recursos uniformes (URL) a nivel de
directivas. El dispositivo aplica IDP a nivel de directivas, excepto para la detección y
el bloqueo de componentes HTTP, que se realiza a nivel de zona. Los ajustes del
cortafuegos a nivel de zona son opciones SCREEN. Una opción de protección de red
establecida en una directiva es un componente de dicha directiva.
Supervisión de vulnerabilidades
Aunque normalmente se utiliza el dispositivo de seguridad para bloquear ataques a
vulnerabilidades, puede haber ocasiones en las que se desee obtener información
sobre ellos. Es posible que desee estudiar específicamente una vulnerabilidad
concreta para descubrir su intención, su nivel de sofisticación o incluso su origen (si
el hacker es descuidado o poco sofisticado).
Si desea obtener información sobre un ataque, puede dejar que actúe, supervisarlo,
analizarlo, investigarlo y reaccionar tal como se haya esbozado en un plan de
respuesta ante incidentes preparado con anterioridad. Puede configurar el
dispositivo de seguridad para que le notifique la existencia de un ataque, pero que,
en lugar de tomar medidas, permita que el ataque se filtre. En tal caso, podrá
estudiar qué ha ocurrido e intentar comprender el método, la estrategia y los
objetivos del hacker. Cuanto mejor comprenda las amenazas que acechan la red,
mejor podrá fortificar sus defensas. Aunque un hacker astuto puede ocultar su
ubicación e identidad, se puede averiguar suficiente información como para
determinar dónde se originó el ataque. Puede que también sea capaz de estimar las
habilidades del hacker. Este tipo de información le permitirá calcular su respuesta.
Ejemplo: Supervisión de ataques desde la zona 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.
Supervisión de vulnerabilidades 5
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
6 Supervisión de vulnerabilidades
Capítulo 2
Bloqueo de reconocimiento
Los hackers pueden planificar mejor sus ataques si antes conocen el diseño de la
red objetivo del ataque (qué direcciones IP tienen los hosts activos), los posibles
puntos de entrada (qué números de puertos están activos en los hosts activos) así
como la constitución de sus víctimas (qué sistema operativo se está ejecutando en
los hosts activos). Para obtener esta información es necesario realizar un
reconocimiento. Juniper Networks ofrece varias opciones SCREEN para frustrar los
intentos de reconocimiento de los hackers e impedir que obtengan información
valiosa sobre la red y los recursos de red protegidos.
“Barrido de direcciones IP” en la página 8
“Barrida de puertos” en la página 9
“Reconocimiento de red mediante opciones IP” en la página 10
“Sondeos del sistema operativo” en la página 12
“indicadores SYN y FIN activados” en la página 13
“Indicador FIN sin indicador ACK” en la página 14
“Encabezado TCP sin indicadores activados” en la página 15
“Técnicas de evasión” en la página 15
“Análisis FIN” en la página 16
“Indicadores no SYN” en la página 16
“Simulación de IP” en la página 20
“Opciones IP de ruta de origen” en la página 26
7
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

Origen: 2.2.2.5
(Probablemente una dirección
simulada o un agente zombie) ethernet3 ethernet2
1.1.1.1/24 1.2.2.1/24
Untrust
DMZ
Paquetes ICMP
Dir. Dir. El dispositivo de seguridad realiza una
11 paquetes ICMP origen destino entrada en su tabla de sesiones para
en 0,005 segundos los 10 primeros paquetes ICMP
2.2.2.5 1.2.2.5 procedentes de 2.2.2.5 y realiza una
2.2.2.5 1.2.2.160 consulta de rutas y una consulta de
2.2.2.5 1.2.2.84 directivas para ellos. Si ninguna
Nota: Después de recibir 10 2.2.2.5 1.2.2.211 directiva permite estos paquetes, el
paquetes ICMP, el dispositivo de 2.2.2.5 1.2.2.10 dispositivo los marca como no válidos y
seguridad lo registra como un 2.2.2.5 1.2.2.20 los elimina de la tabla de sesiones en el
barrido de direcciones IP y rechaza 2.2.2.5 1.2.2.21 siguiente “barrido de basura”, que se
Rechazado 2.2.2.5 1.2.2.240 realiza cada dos segundos. A partir del
el paquete decimoprimero.
2.2.2.5 1.2.2.17 décimo paquete, el dispositivo rechaza
2.2.2.5 1.2.2.123 todo el tráfico ICMP procedente de
2.2.2.5 1.2.2.6 2.2.2.5.
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)
8 Barrido de direcciones IP
Capítulo 2: Bloqueo de reconocimiento
NOTA: El valor se mide en microsegundos. El ajuste predeterminado es

5000 microsegundos.
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

Origen: 2.2.2.5
(Probablemente una dirección
simulada o un agente zombie) ethernet3 ethernet2
1.1.1.1/24 1.2.2.1/24
Untrust DMZ
Destino: 1.2.2.5
Paquetes IP con segmentos TCP

SYN El dispositivo de seguridad realiza
11 segmentos SYN Dir una entrada en su tabla de
en 0,005 segundos orig:puerto Dir dest:puert sesiones para los 10 primeros
intentos de conexión de 2.2.2.5 a
2.2.2.5:17820 1.2.2.5:21 1.2.2.5 y realiza una consulta de
2.2.2.5:42288 1.2.2.160:23 rutas así como una consulta de
Nota: A partir del décimo paquete IP 2.2.2.5:22814 1.2.2.84:53 directivas para ellos. Si ninguna
con segmentos TCP SYN destinado a 2.2.2.5:15401 1.2.2.211:80 directiva permite estos intentos de
diversos puertos de la misma 2.2.2.5:13373 1.2.2.10:111 conexión, el dispositivo los marca
dirección IP de destino, el dispositivo 2.2.2.5:33811 1.2.2.20:113 como no válidos y los elimina de la
de seguridad lo registra como una 2.2.2.5:17821 1.2.2.21:123 tabla de sesiones en el siguiente
barrida de puertos y rechaza todos 2.2.2.5:19003 1.2.2.240:129 “barrido de basura”, que se realiza
los paquetes procedentes de la Rechazado 2.2.2.5:26450 1.2.2.17:137 cada dos segundos. A partir del
dirección de origen. 2.2.2.5:38087 1.2.2.123:138 décimo intento, el dispositivo
2.2.2.5:24111 1.2.2.6:139 rechaza todos los intentos de
conexión procedentes de 2.2.2.5.
Barrida de puertos 9
Para bloquear la barrida de puertos originados en una zona de seguridad en

concreto, utilice una de las siguientes soluciones:
WebUI
Port Scan Protection: (seleccione)

Threshold: (introduzca un valor que active la protección contra la
barrida de puertos)
NOTA: El valor se mide en microsegundos. El ajuste predeterminado es

5000 microsegundos.
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
Encabezado IP Longitud de Tipo de servicio

Versión encabezado Longitud total del paquete (en bytes)
Identificación 0 D M Desplazamiento del fragmento
Tiempo de vida (TTL) Protocolo Suma de comprobación del encabezado
Opciones
Carga de datos
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
Tipo Clase Número Longitud Uso intencionado Uso pernicioso

1
Fin de 0 0 0 Indica el fin de una o más opciones IP. Ninguno.
opciones
Sin opciones 0 1 0 Indica que no hay opciones IP en el Ninguno.
encabezado.
10 Reconocimiento de red mediante opciones IP

Tipo Clase Número Longitud Uso intencionado Uso pernicioso

Seguridad 0 2 11 bits Ofrece un medio para que los hosts envíen Desconocido. Sin embargo, ya que
seguridad, parámetros TCC (grupo de se trata de una opción obsoleta, su
usuarios cerrado) y códigos de restricción presencia en un encabezado IP
de uso compatibles con los requisitos del resulta sospechosa.
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).
Ruta de 0 3 Variable Especifica una lista de rutas parcial que Evasión. El hacker puede utilizar
origen debe tomar un paquete en su trayecto las rutas especificadas para ocultar
abierta desde el punto de origen al de destino. El el verdadero origen de un paquete
paquete debe avanzar en el orden de o para obtener acceso a una red
direcciones especificado, pero se le protegida. (Consulte “Opciones IP
permite atravesar otros enrutadores de ruta de origen” en la página 26).
intermedios.
Grabación de 0 7 Variable Registra las direcciones IP de los Reconocimiento. Si el host de
ruta dispositivos de red del itinerario que destino es un equipo
recorre el paquete IP. El equipo de destino comprometido bajo el control del
puede extraer y procesar la información hacker, éste puede obtener
de ruta. (Debido a la limitación de espacio información sobre la topología y el
de 40 bytes tanto para la opción como esquema de direccionamiento de la
para el espacio de almacenamiento, sólo red atravesada por el paquete.
se puede registrar un máximo de
9 direcciones IP).
Identificación 0 8 4 bits (Obsoleta) Ofrecía un medio para que el Desconocido. Sin embargo, ya que
de secuencia identificador de secuencia SATNET de se trata de una opción obsoleta, su
16 bits se transportara por redes presencia en un encabezado IP
incompatibles con el concepto de resulta sospechosa.
secuencia.
Ruta de 0 9 Variable Especifica la lista de la ruta completa que Evasión. Un hacker puede utilizar
origen debe tomar un paquete en su trayecto las rutas especificadas para ocultar
estricta desde el punto de origen al de destino. La el verdadero origen de un paquete
última dirección de la lista sustituye a la o para obtener acceso a una red
dirección del campo de destino. protegida. (Consulte “Opciones IP
de ruta de origen” en la página 26).
Marca de 22 4 Registra la hora (en formato de horario Reconocimiento. Si el host de
hora universal3) en la que cada dispositivo de destino es un equipo
red recibe el paquete durante su trayecto comprometido bajo el control del
desde el punto de origen al de destino. Los hacker, éste puede obtener
dispositivos de red se identifican por su información sobre la topología y el
número IP. esquema de direccionamiento de la
Esta opción desarrolla una lista de red atravesada por el paquete.
direcciones IP de los enrutadores del
itinerario del paquete y la duración de
transmisión entre cada uno de ellos.
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.
Reconocimiento de red mediante opciones IP 11

Las siguientes opciones SCREEN detectan las opciones IP que un hacker puede
utilizar para el reconocimiento o cualquier otra finalidad desconocida, pero
sospechosa:
Grabación de ruta: El dispositivo de seguridad detecta paquetes en los cuales

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

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

IP es 2 (security) y registra el evento en la lista de contadores SCREEN para la
interfaz de entrada.
Identificador de secuencia: El dispositivo de seguridad detecta paquetes en los

cuales la opción IP es 8 (Stream ID) y registra el evento en la lista de contadores
SCREEN para la interfaz de entrada.
Para detectar paquetes con las opciones IP anteriores establecidas, utilice uno de los
siguientes métodos (la zona de seguridad especificada es la zona en la que se
originó el paquete):
WebUI
IP Record Route Option Detection: (seleccione)

IP Timestamp Option Detection: (seleccione)
IP Security Option Detection: (seleccione)
IP Stream Option Detection: (seleccione)
CLI
set zone zona screen ip-record-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.
12 Sondeos del sistema operativo

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

Encabezado
TCP Número de puerto de origen de 16 bits Número de puerto de destino de 16 bits
Número de secuencia de 32 bits
Número de reconocimiento de 32 bits
Tamaño de Reservado U A P R S F
encabezado C S S Y I Tamaño de ventana de 16 bits
R K H T N N
Suma de comprobación de TCP 16 bits Puntero urgente 16 bits
Opciones (si las hay)
Datos (si los hay)
Los indicadores SYN y FIN están activados.
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
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
Sondeos del sistema operativo 13

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).
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.
Figura 6: Encabezado TCP con indicador FIN activado
Encabezado Número de puerto de origen de 16 bits Número de puerto de destino de 16 bits

TCP
Tamaño de U A P R S FF
encabezado Reservado
C S S Y II Tamaño de ventana de 16 bits
4 bits R K H T N NN
Datos (si los hay)
Sólo está activado el indicador FIN.
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
14 Sondeos del sistema operativo

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

Encabezado TCP Número de puerto de origen de 16 bits Número de puerto de destino de 16 bits
encabezado C S S Y I Tamaño de ventana de 16 bits
4 bits R K H T N N
Datos (si los hay)
No hay ningún indicador 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
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.
Técnicas de evasión 15
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.)
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).
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.
16 Técnicas de evasión
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).
Figura 8: Comprobación de indicador SYN

Con la comprobación de indicador SYN habilitada Con la comprobación de indicador SYN inhabilitada
El paquete llega a la El paquete llega a

interfaz de entrada
En En
sesión sesión
Consulta de Actualización Consulta de Actualización
de sesión REDIRECCIONAMIENTO de sesión
sesiones sesiones
REDIRECCIONAMIENTO
No en No en
sesión sesión
Permis Sí Creación Permis Creación

Consulta de Comprobación Consulta de
directivas de indicador de sesión REDIRECCIONAMIENTO directivas de sesión
SYN REDIRECCIONAMIENTO
Rechazado No Rechazado
DESCARTAR DESCARTAR DESCARTAR
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
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.
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.
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.
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.
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.
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.
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

1. Un paquete IP llega a ethernet3.
Su dirección IP de origen es 10.1.1.6.
2. Como la protección contra simulación de IP está
habilitada en la zona Untrust, el dispositivo
Paquete IP con IP de origen 10.1.1.6 comprueba si 10.1.1.6 es una dirección IP de origen
Zona Untrust válida para los paquetes que llegan a ethernet3.
ethernet3
1.1.1.1/24
X Tabla de rutas
3. Si al consultar la tabla de rutas ID IP-Prefijo Interfaz Puerta de enlace P
observa que 10.1.1.6 no es una
dirección IP de origen válida para 1 10.1.10/24 eth 1 0.0.0.0 C
un paquete que llega a ethernet3, el
dispositivo rechazará el paquete. ethernet1
Zona Trust 10.1.1.1/24
Subred: 10.1.1.0/24
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
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

1. Un paquete IP llega de la zona 2. Debido a que la protección contra simulación de IP
V1-Untrust. Su dirección IP de origen es está habilitada en la zona Untrust V1, el dispositivo
1.2.2.5. Zona V1-Untrust comprueba si 1.2.2.5 es una dirección IP de origen
Paquete IP con IP de origen 1.2.2.5 válida para el paquete que llega de la zona Untrust V1.
ethernet3
0.0.0.0/0
Nombre de zona de dirección: V1-DMZ

3. Si al consultar la libreta de
direcciones observa que Nombre Dirección Máscara de red
1.2.2.5 no es una dirección IP
Subred: 1.2.2.0/24 1.2.2.5
de origen válida para un serv A 255.255.255.255
paquete procedente de la zona C
V1-Untrust, el dispositivo serv A ethernet2
rechazará el paquete. 0.0.0.0/0
Zona V1-DMZ
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.
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:
Destino Interfaz de salida Siguiente puerta de enlace

10.1.2.0/24 ethernet1 10.1.1.250
1.2.3.0/24 ethernet2 1.2.2.250
0.0.0.0/0 ethernet3 1.1.1.250
Si habilita la opción SCREEN para protección contra 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

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

Enrutador ethernet1 ethernet3 Enrutador
10.1.1.250 10.1.1.1/24 1.1.1.1/24 1.1.1.250
ethernet2
1.2.2.1/24
10.1.2.0/24 10.1.1.0/24 1.1.1.0/24 0.0.0.0/0

1.2.2.0/24
1.2.3.0/24
Zona
DMZ
Enrutador
1.2.2.250
WebUI
1. Interfaces
Network > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos,
luego haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: DMZ

haga clic en OK:
Zone Name: Untrust

2. Rutas
Network > Routing > Routing Entries > trust-vr New: Introduzca los



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
2. Rutas
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.
WebUI
1. Direcciones
Address Name: servA

Zone: V1-DMZ
Address Name: servB

Zone: V1-DMZ
Address Name: servC

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

El enrutamiento de origen 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

Opciones IP de ruta de Cuatro
origen para diagnóstico enrutadores
1 3
A Itinerario del paquete B
La transmisión de A a B mediante los
enrutadores 1 y 3 se realiza con éxito el
2 4 50% de las ocasiones.
1 3
A B
Mediante el enrutamiento de origen IP, A envía
tráfico a través de los enrutadores 2 y 3. La
2 4 transmisión de A a B se realiza con éxito el
50% de las ocasiones.
1 3
A B Mediante el enrutamiento de origen IP, A envía
tráfico a través de los enrutadores 1 y 4. La
transmisión de A a B se realiza con éxito el 100%
2 4 de las ocasiones. Por lo tanto, podemos suponer
que el problema reside en el enrutador 3.
Aunque la aplicación de las opciones IP de ruta de origen era 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.
Figura 13: Opción IP de ruta de origen abierta para un engaño

Cuatro ethernet3 ethernet1 Servidor HTTP
enrutadores 1.1.1.1/24 10.1.1.1/24 10.1.1.5
1 3
Itinerario del paquete
2.2.2.0/24 10.1.1.0/24
2 4
Sin comprobación de Dirección IP asignada: 1.1.1.5 - 10.1.1.5

simulación de IP Directiva: set policy from untrust to trust
Sin control de acceso 2.2.2.0/24 MIP(1.1.1.5) HTTP permit
Hacker
Información del paquete
Dirección de origen real: 6.6.6.5 Entre las opciones SCREEN para la zona Untrust se
Dirección de origen simulada: 2.2.2.5 incluye “Deny IP Source Route Option”.
Dirección de destino: 1.1.1.5 El dispositivo de seguridad descarta el paquete.
IP de ruta de origen abierta: 6.6.6.250, 2.2.2.250
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).
Para bloquear paquetes con la opción IP de ruta de origen abierta o estricta

establecida, utilice uno de los siguientes métodos (la zona de seguridad especificada
es la zona en la que se originó el paquete):
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione IP
Source Route Option Filter y haga clic en Apply.
CLI
set zone zona screen ip-filter-src
Para detectar y registrar (pero no bloquear) paquetes con la opción IP de ruta de

origen abierta o estricta establecida, utilice uno de los siguientes métodos (la zona
de seguridad especificada es la zona en la que se originó el paquete):
WebUI
IP Loose Source Route Option Detection: (seleccione)

IP Strict Source Route Option Detection: (seleccione)
CLI
set zone zona screen ip-loose-src-route
set zone zona screen ip-strict-src-route
Capítulo 3
Defensas contra los ataques de
denegación de servicio
La intención de un ataque de denegación de servicio (DoS) es sobrecargar a la

víctima potencial con tal cantidad de tráfico fantasma que se sature intentando
procesar el tráfico fantasma y no consiga procesar el tráfico legítimo. El objetivo
puede ser el cortafuegos de Juniper Networks, los recursos de red cuyos accesos
controla el cortafuegos o la plataforma de hardware específica o el sistema
operativo (OS) de un host determinado.
Si un ataque DoS se genera desde múltiples direcciones de origen, se conoce como

ataque distribuido de denegación de servicio (Distributed Denial-of-Service o
DDoS). Normalmente, la dirección de origen de un ataque DoS es simulada
(“spoofed”). Las direcciones de origen de un ataque DDoS pueden ser simuladas,
o bien, pueden ser las direcciones reales de hosts previamente comprometidos por
el hacker y que éste utiliza ahora como “agentes zombie” para ejecutar el ataque.
El dispositivo de seguridad puede defenderse a sí mismo y defender a los recursos

que protege de los ataques DoS y DDoS. Las siguientes secciones describen las
diversas opciones de defensa disponibles:
“Ataques DoS contra el cortafuegos” en la página 30
“Inundaciones de la tabla de sesiones” en la página 30
“Inundaciones de SYN-ACK-ACK a través de un servidor proxy” en la

página 35
“Ataques DoS contra la red” en la página 37
“Inundaciones SYN” en la página 37
“Cookie SYN” en la página 47
“Inundaciones ICMP” en la página 49
“Inundaciones UDP” en la página 51
“Ataque terrestre” en la página 52
29
“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.
30 Ataques DoS contra el cortafuegos

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
Limitación de sesiones según

su origen: contención del tráfico Zona Untrust
del virus/gusano Nimda
Un servidor Web se infecta con el híbrido Cuando el número de sesiones

del virus/gusano Nimda, lo que provoca que concurrentes del servidor infectado
el servidor genere cantidades excesivas de
tráfico. Zona … alcanza el límite máximo, el dispositivo
de seguridad comienza a bloquear
DMZ Servidor todos los intentos de conexión
infectado subsiguientes de ese servidor.
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
Limitación de sesiones según su origen: Limitación de sesiones según su destino:

Ataque de denegación de servicio Ataque de denegación de servicio distribuido
Hacker Hacker
IP de origen de
host inexistente: Agentes
6.6.6.6 zombie
Zona Untrust Zona
Untrust
Zona DMZ Zona DMZ
Servidor web Servidor web
Cuando el número de sesiones concurrentes que proceden de Cuando el número de sesiones concurrentes al servidor web
6.6.6.6 sobrepasa el límite máximo, el dispositivo de sobrepasa el límite máximo, el dispositivo de seguridad
seguridad bloquea cualquier conexión subsiguiente de esa bloquea cualquier intento de conexión subsiguiente a esa
dirección IP. dirección IP.
Ataques DoS contra el cortafuegos 31

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:

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.

WebUI
Screening > Screen (Zone: Untrust): Introduzca los siguientes datos y haga clic
en OK:
Destination IP Based Session Limit: (seleccione)

CLI
set zone untrust screen limit-session destination-ip-based 4000
set zone untrust screen limit-session destination-ip-based
save
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:

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
Min 30 25 20 15 10 5 0
Tiempo de espera predeterminado de las sesiones TCP:
30 min (1800 seg)
Expiración dinámica = 10 (predeterminado - 100 seg): Seg 1800 1500 1200 900 600 300 0
28:20 min (1700 seg)
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
Min 5 4 3 2 1 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) Seg 300 240 180 120 60 0
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
100%
Cuando el número de sesiones supera la capacidad del
80%, se activa el mecanismo de expiración dinámica.
80% Umbral superior
(caducado - 40 seg)
70% Umbral inferior
Las sesiones expiran dinámicamente hasta
que la cantidad cae por debajo del 70%. En
Sesiones ese momento, el mecanismo de expiración
dinámica se detiene.
0%

WebUI
NOTA: Para configurar los ajustes de expiración dinámica debe utilizar la interfaz de línea
de comandos (“CLI”).
CLI
set flow aging low-watermark 70
set flow aging high-watermark 80
set flow aging early-ageout 4
save
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.

Figura 19: Inundaciones de SYN-ACK-ACK a través de un servidor proxy
Cliente Telnet o FTP

(usuario de autenticación) Servidor Telnet
Zona Untrust Zona Trust o FTP
SYN
SYN/ACK Tabla de sesiones de ScreenOS:

Otros recursos disponibles.
ACK
Name: ?
Password: ?
SYN
SYN/ACK
ACK La tabla de sesiones se
está llenando.
Name: ?
Password: ?
.
.
.
SYN La tabla de sesiones está llena.
Para evitar tal ataque, puede habilitar la opción SCREEN de protección de

SYN-ACK-ACK a través de proxy. Cuando el número de conexiones procedentes de
una misma dirección IP alcanza el umbral de SYN-ACK-ACK del proxy, el dispositivo
de seguridad rechaza las peticiones de conexión subsiguientes provenientes de esa
dirección IP. De forma predeterminada, el umbral es de 512 conexiones de una
determinada dirección IP. Puede cambiar este umbral (a cualquier número entre 1 y
250.000) para que se adapte mejor a los requisitos de su entorno de red.
Para habilitar la protección contra inundaciones de SYN-ACK-ACK a través de un

servidor proxy, ejecute cualquiera de los siguientes procedimientos, donde la zona
especificada es aquélla en la que se origina el ataque:
WebUI
SYN-ACK-ACK Proxy Protection: (seleccione)

Threshold: (introduzca un valor para activar la protección contra
inundaciones de SYN-ACK-ACK del proxy)
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.
CLI
set zone zona screen syn-ack-ack-proxy threshold número
set zone zona screen syn-ack-ack-proxy

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

El host en 2.2.2.5 envía segmentos SYN Si una directiva permite el tráfico entrante, el dispositivo de seguridad
Dirección en paquetes IP con direcciones de origen permite los segmentos SYN. La víctima responde enviando segmentos
IP real, simuladas. SYN/ACK a la dirección IP simulada de origen, quedando a la espera
2.2.2.5 de respuesta hasta que los intentos sobrepasan el tiempo de espera.
Direcciones IP
inexistentes o
inalcanzables
3.3.3.5
SYN
LAN
SYN/ACK protegida
4.4.4.20
SYN
SYN/ACK
5.5.5.10
SYN El búfer de memoria
de la víctima
SYN/ACK empieza a llenarse.
6.6.6.3
SYN
SYN/ACK
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.
Ataques DoS contra la red 37

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

Dirección IP real El host con la dirección 2.2.2.5 continúa enviando segmentos
2.2.2.5 SYN en paquetes IP con direcciones de origen simuladas.
Direcciones IP
inalcanzables
o inexistentes
7.7.7.11 SYN LAN
protegida
SYN/ACK
8.8.8.8 SYN
SYN/ACK
El búfer de memoria de la
9.9.9.22 víctima deja de llenarse.
— Umbral de ataque SYN —
2.2.2.4
SYN
Cuando el número de segmentos
SYN/ACK SYN procedentes de una misma
dirección de origen o dirigidos a
3.3.3.25 SYN la misma dirección de destino La cola de conexiones a
alcanza un umbral especificado, través de un servidor
SYN/ACK el dispositivo de seguridad proxy del dispositivo de
comienza a interceptar las seguridad comienza a
. peticiones de conexión y a llenarse.
. procesar los segmentos
. SYN/ACK mediante el 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.
38 Ataques DoS contra la red

Figura 22: Rechazo de nuevos segmentos SYN
Dirección IP real El host con la dirección 2.2.2.5 continúa enviando segmentos SYN
2.2.2.5 en paquetes IP con la dirección de origen simulada 3.3.3.5.
LAN
Direcciones IP protegida
inexistentes o
inalcanzables
3.3.3.5 — Umbral de ataque SYN —
SYN
El dispositivo de seguridad El búfer de memoria de
SYN/ACK intercepta los segmentos SYN y la víctima recupera su
procesa a través de un servidor estado normal.
proxy las respuestas SYN/ACK
SYN hasta que la cola de conexiones a
través del servidor proxy se llena. La cola de conexiones a
SYN/ACK través del servidor proxy
del dispositivo de
seguridad está llena.
— Umbral de alarma —
. El dispositivo de seguridad introduce

. una alarma en el registro de eventos.
.
— Limite máximo de la cola de conexiones a través de un servidor proxy —
El dispositivo de seguridad
rechaza nuevos segmentos SYN
de todas las direcciones de la
SYN misma zona de seguridad.
Segmento SYN de otra dirección de

la misma zona de seguridad.
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.
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.
Para habilitar la opción SCREEN de protección contra inundaciones SYN y definir

sus parámetros, ejecute cualquiera de los siguientes procedimientos, donde la zona
especificada es aquélla en la que pueden originarse inundaciones:
WebUI
SYN Flood Protection: (seleccione para habilitar)

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)
NOTA: Para obtener más detalles acerca de cada uno de estos parámetros, consulte las
descripciones en la siguiente sección de CLI.
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

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

Cuando se establece un umbral de origen SYN y un umbral de destino, se

activan tanto el mecanismo básico de protección contra inundaciones SYN
como el mecanismo de seguimiento de inundaciones SYN según sus destinos.
Cuando se da seguimiento a inundaciones SYN por su dirección de destino, se

utilizan otros parámetros de detección distintos a los del seguimiento de
inundaciones SYN por dirección y número de puerto de destino. Observe el
caso siguiente, donde el dispositivo de seguridad tiene directivas que permiten
realizar peticiones FTP (puerto 21) y peticiones HTTP (puerto 80) al mismo
servidor. Si el umbral de ataque contra inundaciones SYN es de 1000 paquetes
por segundo (pps) y un hacker envía 999 paquetes FTP y 999 paquetes HTTP
por segundo, ninguno de ambos conjuntos de paquetes (conjunto que
comparte la misma dirección y número de puerto de destino) activa el
mecanismo de procesamiento de SYN a través de un servidor proxy. El
mecanismo básico de ataque contra inundaciones SYN realiza el seguimiento
de direcciones y números de puerto de destino y ninguno de los conjuntos
supera el umbral de ataque de 1000 paquetes por segundo. Sin embargo, si el
umbral de destino es de 1000 pps, el dispositivo trata los paquetes FTP y HTTP
con la misma dirección de destino que los miembros de un solo conjunto y
rechaza el 1001º paquete (FTP o HTTP) dirigido a ese destino.
Timeout: El tiempo máximo antes de que una conexión incompleta sea

descartada de la cola. El valor predeterminado es de 20 segundos, pero se
puede establecer entre 0 y 50 segundos. Intente reducir el valor del tiempo de
espera hasta que comience a ver conexiones descartadas en condiciones
normales de tráfico. Veinte segundos representan un tiempo de espera muy
conservador para una respuesta ACK a un establecimiento de conexión en tres
pasos.
set zone zona screen syn-flood timeout número
Queue size: El número de peticiones de conexión a través de un servidor proxy

que se pueden retener en la cola de conexiones a través de un servidor proxy
antes de que el dispositivo de seguridad comience a rechazar nuevas peticiones
de conexión. Cuanto mayor sea el tamaño de la cola, más tarda el dispositivo
en analizar la cola para encontrar una respuesta ACK válida a una petición de
conexión a través de un servidor proxy. Esto puede retardar ligeramente el
establecimiento inicial de la conexión; sin embargo, como el tiempo que debe
transcurrir antes de poder comenzar la transferencia de datos es normalmente
muy superior al de cualquier retraso menor en la configuración inicial de la
conexión, los usuarios no percibirán una diferencia notable.
set zone zona screen syn-flood queue-size número

Drop Unknown MAC: Cuando un dispositivo de seguridad detecta un ataque

SYN, procesa a través de un servidor proxy todas las peticiones de conexión
TCP. Sin embargo, un dispositivo en modo transparente no puede procesar a
través de un servidor proxy una petición de conexión TCP si la dirección MAC
de destino no está en su tabla de aprendizaje de MAC. De forma
predeterminada, un dispositivo en modo transparente que ha detectado un
ataque SYN entrega paquetes SYN que contienen direcciones MAC
desconocidas. Puede utilizar esta opción para ordenar al dispositivo que
descarte los paquetes SYN que contienen direcciones MAC de destino
desconocidas en lugar de permitirles el paso.
set zone zona screen syn-flood drop-unknown-mac
Ejemplo: Protección contra inundaciones 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.
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.
Figura 23: Protección contra inundaciones SYN a nivel de dispositivo
ethernet3 ethernet2 Servidores Web

1.1.1.1/24 1.2.2.1/24
Zona Untrust 1.2.2.10
1.2.2.20
Zona DMZ
Internet
HTTP 1.2.2.30
Inundación SYN
1.2.2.40
Cortafuegos
Para configurar los parámetros de protección contra inundaciones SYN con los
valores apropiados para su red, primero debe establecer una línea de base de los
flujos de tráfico tí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: 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.
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
Parámetro Valor Motivo para cada valor

Attack 625 paquetes Esto supera en un 25% a la cantidad de picos promedio de nuevas peticiones de conexión por
Threshold por segundo segundo por servidor, algo inusual para este entorno de red. Cuando el número de paquetes
(Umbral de (pps) SYN por segundo de cualquiera de los cuatro servidores web supera este número, el dispositivo
ataque) 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 250 pps 250 pps es 1/4 del tamaño de la cola (1000 peticiones de conexión incompletas y procesadas a
Threshold través de un servidor proxy1). Cuando el dispositivo procesa a través de un servidor proxy 251
(Umbral de nuevas peticiones de conexión en un segundo, se genera una entrada de alarma en el registro
alarma) 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 25 pps Cuando se establece un umbral de origen, el dispositivo rastrea la dirección IP de origen de los
Threshold paquetes SYN, sin importar la dirección y el número de puerto de destino. (Observe que este
(Umbral de seguimiento según los orígenes es independiente del seguimiento de paquetes SYN en base a la
origen) 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 0 pps Cuando se establece un umbral de destino, el dispositivo ejecuta un seguimiento separado
Threshold solamente de la dirección IP de destino, sin importar el número de puerto de destino. Debido a
(Umbral de que los cuatro servidores web reciben solamente tráfico HTTP (puerto de destino 80), no les
destino) 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).

Parámetro Valor Motivo para cada valor

Timeout 20 segundos Dado que el tamaño de la cola es relativamente pequeño (1000 peticiones de conexión
(Tiempo de procesadas a través de un servidor proxy), el valor predeterminado de 20 segundos es un
espera) tiempo razonable para mantener las peticiones de conexión incompletas en cola para esta
configuración.
Queue Size 1000 1000 peticiones de conexión incompletas y procesadas a través de un servidor proxy es dos
(Tamaño de conexiones veces el promedio de picos de nuevas peticiones de conexión (500 pps). El dispositivo procesa
la cola) incompletas y a través de un servidor proxy hasta 1000 peticiones por segundo antes de descartar nuevas
procesadas a peticiones. Procesar a través de un servidor proxy el doble del promedio de picos de nuevas
través de un peticiones de conexión proporciona un “colchón” suficiente como para que puedan pasar las
servidor proxy 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.
WebUI
1. Interfaces
haga clic en OK:
Zone Name: DMZ

haga clic en OK:
Zone Name: Untrust

2. Direcciones
Address Name: ws1

Zone: DMZ
Address Name: ws2

Zone: DMZ

Address Name: ws3

Zone: DMZ
Address Name: ws4

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




3. Directiva
haga clic en OK:
Source 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

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.
CLI
1. Interfaces
2. Direcciones
set address dmz ws1 1.2.2.10/32
set group address dmz web_servers add ws1
3. Directiva
set policy from untrust to dmz any web_servers HTTP permit
4. Screen
set zone untrust screen syn-flood attack-threshold 625
set zone untrust screen syn-flood alarm-threshold 250
set zone untrust screen syn-flood source-threshold 25
set zone untrust screen syn-flood timeout 20
set zone untrust screen syn-flood queue-size 1000
set zone untrust screen syn-flood
save
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.
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.

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

Host TCP Servidor TCP
SYN
1
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
2 SYN/ACK
Envío de ACK
3 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
4 SYN
1. Aceptar conexión
2. Envar SYN/ACK
55 SYN/ACK
Envío de ACK a ambos extremos
7 ACK 6 ACK
Conectado
8 Data/ACK
Data/ACK
9

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.

Figura 25: Inundaciones ICMP
El hacker envía peticiones de eco ICMP El dispositivo de seguridad deja pasar

con direcciones de origen simuladas. las peticiones de eco sólo si alguna
directiva lo permite.
Petición de eco LAN

protegida
Peticiones de eco Respuesta de eco
ICMP procedentes
de diversas Petición de eco
direcciones IP
simuladas Respuesta de eco
Petición de eco
Respuesta de eco
.
.
.
— Límite máximo de peticiones de eco ICMP por segundo —
Petición de eco Una vez alcanzado el umbral de ICMP,

el dispositivo de seguridad rechaza las
peticiones de eco ICMP subsiguientes
que provienen de todas las
Petición de eco direcciones de la misma zona de
seguridad durante el resto del
segundo actual y también durante el
Petición de eco ICMP legítima de una segundo siguiente.
dirección en la misma zona de seguridad
Para habilitar la protección contra inundaciones ICMP, ejecute cualquiera de los

siguientes procedimientos, donde la zona especificada es aquélla en la que pueden
originarse inundaciones:
WebUI
ICMP Flood Protection: (seleccione)

Threshold: (introduzca el valor a partir del cual debe activarse la
protección contra inundaciones ICMP)
NOTA: La unidad de este valor se expresa en paquetes ICMP por segundo. El valor
predeterminado es de 1000 paquetes por segundo.
CLI
set zone zona screen icmp-flood threshold número
set zone zona screen icmp-flood

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

El hacker envía datagramas UDP en paquetes El dispositivo de seguridad deja pasar los
IP con direcciones de origen simuladas. datagramas UDP sólo si alguna directiva lo permite.
LAN protegida
Datagrama UDP
Servidor DNS
Datagramas UDP Los datagramas IP: 1.2.2.5
dentro de los apuntan a un servidor
paquetes IP Puerto: 53 (UDP)
DNS en 1.2.2.5:53.
procedentes de Datagrama UDP
varias direcciones
IP simuladas
Datagrama UDP
— Límite máximo de datagramas UDP por segundo —
Datagrama UDP Una vez alcanzado el umbral de

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

siguientes procedimientos, donde la zona especificada es aquélla en la que puede
originarse una inundación:
WebUI
UDP Flood Protection: (seleccione)

Threshold: (introduzca el valor a partir del cual debe activarse la
protección contra inundaciones UDP)
NOTA: La unidad de este valor se expresa en paquetes UDP por segundo. El valor
predeterminado es de 1000 paquetes por segundo.

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
Hacker Tanto la dirección de origen como la de Víctima

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

están consumidos, lo
cual impide las
operaciones normales.
Cuando se habilita la opción SCREEN para bloquear ataques terrestres, el

dispositivo 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

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.
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.
Figura 28: Ping of Death

20 bytes 8 bytes 65.510 bytes
Paquete
Encabezado
original no Encabezado IP Datos ICMP
ICMP
fragmentado
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.
Ataques de DoS específicos de cada sistema operativo 53

Para habilitar la protección contra ataques “Ping of Death”, ejecute cualquiera de los
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

El dispositivo de seguridad comprueba si existen discrepancias
Encabezado IP en el campo de desplazamiento del fragmento.
Longitu
Versión Tipo de servicio Longitud total del paquete (en bytes)
d del
Desplazamiento del
Identificación x D M fragmento
20
Tiempo de vida (TTL) Protocolo Suma de comprobación del encabezado bytes
Carga de datos
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.
54 Ataques de DoS específicos de cada sistema operativo

Figura 30: Discrepancia entre fragmentos
20 bytes 800 bytes

Paquete Encabezado IP Datos
fragmentado nº 1
Desplazamiento = 0
Longitud = 820
Más fragmentos = 1
El segundo fragmento pretende
20 bytes 600 bytes comenzar 20 bytes antes (en 800) del
Paquete final del primer fragmento (en 820). El
Encabezado IP Datos desplazamiento del fragmento nº 2 no
fragmentado nº 2
concuerda con la longitud del paquete
Desplazamiento = 800 del fragmento nº 1. Esta discrepancia
Longitud = 620 puede hacer que algunos sistemas se
queden colgados al intentar el
Más fragmentos = 0
reensamblaje.
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

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.
Ataques de DoS específicos de cada sistema operativo 55

Figura 31: Indicadores de un ataque WinNuke

El puerto de destino es el 139.
Encabezado TCP
Número del puerto de origen Puerto de destino: 139
Número de secuencia
Número de reconocimiento
Longitud del U A P R S F
Reservado R C S S Y I Tamaño de la ventana
encabezado
G K H T N N
Suma de comprobación de TCP Indicador “Urgente”
Datos (si los hay)
El indicador URG está establecido.
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

origina el ataque:
WebUI
WinNuke Attack Protection, después haga clic en Apply.
CLI
set zone zona screen winnuke
56 Ataques de DoS específicos de cada sistema operativo

Capítulo 4
Supervisión y filtrado de contenidos
Juniper Networks proporciona amplia protección y control de la actividad de red

por medio de funciones de ScreenOS y de la combinación de ScreenOS con
productos Websense, SurfControl y Kaspersky Lab.
En este capítulo se describe cómo se ha de configurar el dispositivo para

reensamblar paquetes y segmentos, supervisar el tráfico HTTP en busca de URL
maliciosas e interactuar con otros dispositivos para realizar el análisis antivirus y el
filtrado de URL. El capítulo se divide en las siguientes secciones:
“Reensamblaje de fragmentos” en la página 58
“Protección contra URL maliciosas” en la página 58
“Puerta de enlace en la capa de aplicación” en la página 59
“Análisis antivirus” en la página 62
“Análisis AV externo” en la página 62
“Análisis AV interno” en la página 64
“Análisis AV basado en directivas” en la página 71
“Análisis de protocolos de aplicación” en la página 72
“Actualización de los archivos de patrones AV para el analizador

incorporado” en la página 81
“Ajustes globales del analizador de AV” en la página 84
“Perfiles de AV” en la página 88
“Filtrado anti spam” en la página 95
“Filtrado de Web” en la página 100
“Filtrado de Web integrado” en la página 101
“Redireccionamiento del filtrado de Web” en la página 110
57
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
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.
58 Reensamblaje de fragmentos
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.
NOTA: Para una directiva de rechazo, el servicio FTP-Put, Ftp-Get y FTP se comporta de la
misma manera bloqueando todos los paquetes.
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.
Reensamblaje de fragmentos 59
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
60 Reensamblaje de fragmentos
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
ID: perl
Pattern: scripts/perl.exe
Length: 14
ID: cmf
Pattern: cgi-bin/phf
Length: 11
ID: dll
Pattern: 210.1.1.5/msadcs.dll
Length: 18
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
Reensamblaje de fragmentos 61
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
62 Análisis antivirus
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
Dispositivo de seguridad Servidores

de Juniper Networks Zona Trust HTTP/SMTP
Zona Untrust remotos
Servidor FTP
remoto Servidores ICAP que
ejecutan Symantec
PW R A LA R M TEM P S TAT U S HA
FA N M OD1 M OD2 M OD3 F LA S H

ISG 2000
scan engine 5.0
Cliente ICAP
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.
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.
Análisis antivirus 63
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.
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.
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)
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
NOTA: Se debe utilizar la CLI para modificar el nivel de seguridad de análisis

predeterminado.
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
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:
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) SOCKS 4, SOCKS 5,
HTTP
MSN Messenger 1863 SOCKS 4, SOCKS 5,
HTTP
1. Además del puerto 5050, asegúrese de que esté permitido el tráfico

en los puertos 443 (HTTPS) y 80 (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.
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 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)
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.
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.
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 Se descarta. Se redirecciona un mensaje de notificación
(está desactivado el de descarte por error de análisis al destino
permiso para error de del mensaje original.
análisis)
El análisis de AV termina Se redirecciona a su El mensaje llega a su destino.
sin virus o errores en el destino.
análisis
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:
Transferencia de
archivos/distribución
Si el tamaño del archivo es… 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á No se realiza análisis AV Descarta el archivo y redirecciona el
activado el descarte de mensaje de notificación de descarte
max_content_size) al destino del mensaje original.
> AV max_content_size (está No se realiza análisis AV Se redirecciona el archivo a su
desactivado el descarte de destino.
max_content_size)
NOTA: Esta versión de ScreenOS no es compatible con el tráfico P2P de mensajería

instantánea a través del cortafuegos.
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.
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.
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 “Análisis del tráfico de HTTP” en la página 74
(HTTP)
Protocolo de acceso de correo de Internet “Análisis del tráfico de IMAP y POP3” en la
(IMAP) página 76
Protocolo de oficina de correo, versión 3 “Análisis del tráfico de IMAP y POP3” en la
(POP3) página 76
Protocolo de transferencia de correo sencillo “Análisis del tráfico de SMTP” en la página 78
(SMTP)
Protocolo de adaptación de contenido de “Desvío del tráfico a los servidores de análisis AV
Internet ( ICAP) ICAP” en la página 80
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.
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
Un cliente establece una conexión con un

5 Si no se encuentran virus, los datos
se reenvían a su destino original.
servidor e inicia una sesión.
El administrador de análisis supervisa todas las
Zona Untrust
2 peticiones enviadas por el cliente y extrae los
datos específicos del protocolo. Zona Trust
Servidor Cliente FTP

FTP remoto local
3 El perfil de AV determina si la petición
se debe enviar para el análisis de antivirus.
Si se encuentra un virus, el mensaje
Si los datos se configuran para ser 6 se registrará y se enviará un correo
4 analizados, entonces se envían al motor de electrónico basado en el ajuste del
perfil de AV.
detección de virus para el análisis.
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.
NOTA: Es necesario evaluar el riesgo y determinar la mejor solución entre seguridad y

rendimiento.
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
Cada una de las aplicaciones anteriores puede configurarse para uno o varios de los
siguientes:
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.
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:
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 está establecida la descarta los datos del canal de datos y envía un mensaje de “file
contenido opción drop too large” (archivo demasiado grande) al cliente FTP a través del
canal de control
exceden el tamaño máximo de no está establecida la pasa los datos sin examinar al cliente FTP a través del canal de
contenido opción drop datos
no se pueden analizar con éxito no está establecida la descarta los datos del canal de datos y envía un mensaje “scan
opción fail mode error” (error de análisis) al cliente FTP a través del canal de
(drop) control
no se pueden analizar con éxito la opción fail mode pasa los datos al cliente FTP a través del canal de datos
está establecida en
permit (traffic
permit)

exceden los mensajes simultáneos está establecida la descarta los datos del canal de datos y envía un mensaje
máximos opción drop “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 no está establecida la pasa los datos al cliente FTP a través del canal de datos
máximos opción drop
Figura 34: Análisis de antivirus para el tráfico de FTP
Canal de control
Servidor FTP Cliente FTP

remoto local
Analizador AV interno
Canal de datos
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.
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.


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

exceden el tamaño máximo de está establecida la descarta los datos y envía un mensaje “file too large” (archivo
contenido opción drop demasiado grande) al cliente HTTP
exceden el tamaño máximo de no está establecida la pasa los datos al cliente HTTP
contenido opción drop
no se pueden analizar con éxito no está establecida la descarta los datos y envía un mensaje “scan error” (error de
opción fail mode análisis) al cliente HTTP
(drop)
no se pueden analizar con éxito está establecida la pasa los datos al cliente HTTP
opción traffic
permito
(fail mode tiene el
valor permit)
exceden los mensajes simultáneos está establecida la descarta los datos del canal de datos y envía un mensaje
máximos opción drop “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 no está establecida la pasa los datos al cliente HTTP a través del canal de datos
máximos opción drop
Figura 35: Análisis de antivirus para el tráfico de HTTP
Servidor Web Cliente HTTP

remoto local
Analizador AV interno
4. Un servidor web responde a una petición de HTTP. 1. Un cliente HTTP envía una petición de HTTP a un servidor web.
5. El dispositivo de seguridad intercepta la respuesta de HTTP y pasa 2. El dispositivo de seguridad intercepta la petición y transmite los
los datos a su motor interno de detección AV, que los examina en datos al analizador AV interno, que los examina en busca de virus.
busca de virus.
3. Una vez finalizado el análisis, el dispositivo sigue uno de estos
6. Una vez finalizado el análisis, el dispositivo sigue uno de estos pasos*:
pasos*:
• Si no hay virus, reenvía la petición al servidor web.
• Si no hay virus, reenvía la respuesta al cliente de HTTP.
• Si se descubre la presencia de un virus, descarta la petición y
• 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.
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.
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/
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:

no están pasa el mensaje al cliente de IMAP o POP3.
contaminados
contienen un virus está establecida la cambia el tipo de contenido a “text/plain,” reemplaza el cuerpo del mensaje con
opción email la siguiente notificación, la envía al cliente de IMAP o POP3 y notifica al
notification remitente:
VIRUS WARNING.
Contaminated File: nombre del archivo contaminado
Virus Name: nombre del virus

exceden el tamaño está establecida la cambia el tipo de contenido a text/plain, reemplaza el cuerpo del mensaje con la
máximo de opción drop siguiente notificación, la envía al cliente de IMAP o POP3:
contenido Content was not scanned for viruses because cadena_motivo (número de código),
o bien and it was dropped.
no se pueden no está establecida El campo cadena_motivo puede ser uno de los siguientes:
analizar con éxito la opción fail mode El archivo es demasiado grande.
o bien (drop) Se encontró un error o un problema.
exceden los Se excedió el tamaño de contenido máximo.
mensajes está establecida la
simultáneos Se excedió el número máximo de mensajes
opción email
máximos notification notifica al remitente/destinatario sobre los virus detectados o los errores en el
análisis.
exceden el tamaño no está establecida pasa el mensaje original al cliente de IMAP o POP3 con la línea de asunto original
máximo de la opción drop modificada como se muestra a continuación:
contenido cadena_asunto_original (No virus check because cadena_motivo, número de
o bien código)
no se pueden notifica al remitente/destinatario sobre los virus detectados o los errores en el
analizar con éxito análisis.
traffic permit está
o bien establecido (fail
exceden los mode tiene el valor
mensajes permit)
simultáneos
máximos
drop no está
establecido
está establecida la
opción email
notification
Figura 36: Análisis de antivirus para el tráfico de IMAP y POP3
Zona DMZ
Servidor de correo
local
Internet
Analizador AV interno Cliente IMAP o POP3
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.
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.

no están pasa el mensaje al destinatario de SMTP.
contaminados
contienen un virus está establecida la cambia el tipo de contenido a “text/plain,” reemplaza el cuerpo del mensaje con la
opción email siguiente notificación, la envía al destinatario de SMTP y notifica al remitente:
notification VIRUS WARNING.
Contaminated File: nombre del archivo
Virus Name: nombre_virus

exceden el tamaño está establecida la cambia el tipo de contenido a “text/plain,” reemplaza el cuerpo del mensaje con la
máximo de opción drop siguiente notificación, la envía al destinatario de SMTP:
contenido Content was not scanned for viruses because cadena_motivo (número de código),
o bien no está establecida and it was dropped.
no se pueden la opción fail mode El campo cadena_motivo puede ser uno de los siguientes:
analizar con éxito (drop) El archivo es demasiado grande.
o bien Se encontró un error o un problema.
exceden los está establecida la Se excedió el tamaño de contenido máximo.
mensajes opción drop
simultáneos Se excedió el número máximo de mensajes
máximos notifica al remitente/destinatario sobre los virus detectados o los errores en el
está establecida la análisis.
opción email
notification
exceden el nivel está desactivada la pasa el mensaje original al cliente de SMTP con la línea de asunto original
máximo de opción drop modificada como se muestra a continuación:
contenido cadena_asunto_original (No virus check because cadena_motivo, número de código)
o bien traffic permit está notifica al remitente/destinatario sobre los virus detectados o los errores en el
no se pueden establecido (fail análisis.
analizar con éxito mode está
o bien permitido)
exceden los
mensajes no está activada la
simultáneos opción drop
máximos está establecida la
opción email
notification
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.
Figura 37: Análisis de antivirus para el tráfico de SMTP
Zona DMZ
Internet
Servidor de correo remoto Analizador AV interno Cliente SMTP
1. Un servidor de correo remoto redirecciona un mensaje de correo A. Un cliente SMTP envía un mensaje de correo electrónico a un
electrónico por SMTP al servidor de correo local. servidor de correo local.
2. El dispositivo de seguridad intercepta el mensaje de correo B. El dispositivo de seguridad intercepta el mensaje de correo
electrónico y pasa los datos al analizador AV interno, que los electrónico y pasa los datos al analizador AV interno, que los
analiza en busca de virus. analiza en busca de virus.
3. Una vez finalizado el análisis, el dispositivo sigue uno de estos C. Una vez finalizado el análisis, el dispositivo sigue uno de estos
pasos*: pasos*:
• Si no hay virus, reenvía el mensaje al servidor local. • Si no hay virus, reenvía el mensaje al servidor local.
• Si se descubre la presencia de un virus, envía un mensaje • Si se descubre la presencia de un virus, envía un mensaje
informando de la infección al servidor remoto. informando de la infección al cliente.
* 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.
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:
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.
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:
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
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.
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.
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

Dispositivo de seguridad Servidor de
Petición de transferencia de archivo actualizaciones
Internet
URL de Juniper-Kaspersky = http://update.juniper-updates.net/av/5gt
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.
NOTA: ScreenOS contiene un certificado CA para autenticar la comunicación con el

servidor de archivos de actualización 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.
Figura 39: Actualización de archivos de firmas, paso 2
Servidor de
Dispositivo de seguridad Solicitud del archivo de firmas archivos de firmas
Internet
Archivo de firmas de virus Transferencia del archivo de firmas de virus Archivo de firmas de virus
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.
NOTA: Cuando caduque la suscripción, el servidor de actualizaciones no permitirá

actualizar el archivo de firmas de virus.
Ejemplo: Actualización automática

En este ejemplo, configuraremos el dispositivo 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
WebUI
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.
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).

(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.
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.
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: 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.
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
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.
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.
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.
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.
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.
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
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
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.
NOTA: Para cambiar el valor de tiempo de espera, debe utilizar la CLI.
CLI
(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
(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
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.
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.
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)
NOTA: Para cambiar el valor de tiempo de espera, debe utilizar CLI.
CLI
(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
save
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
(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).
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.
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
(av:jnpr-profile)-> unset av http skipmime
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.

Protocols to be scanned:
Email Notify > Select Virus Sender
Email Notify > Select Scan-error Sender
Email Notify > Select Scan-error Recipient
CLI
(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
save
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.
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.
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
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
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
(av:jnpr-profile)-> set http decompress-layer 3
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.
Filtrado anti spam 95

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.
NOTA: Esta versión admite antispam únicamente para el protocolo SMTP.
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.
96 Filtrado anti spam

Si lo prefiere, puede configurar listas blancas y negras locales. En este caso, de

forma predeterminada el sistema revisa primero la base de datos local de las listas
negras/blancas. Si no encuentra el nombre del host, el cortafuegos continúa la
consulta del servidor SBL que se encuentra en Internet.
Configuración bá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

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

device(anti-spam:ns-profile)-> set whitelist www.fiddwicket.com
98 Filtrado anti spam

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.
2. Especifique que los mensajes de correo electrónico que parecen ser spam
incluyan la cadena “Esto es spam” en el encabezado del mensaje.

device(anti-spam:ns-profile)-> set default action tag header “Esto es spam”
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:
2. Active el uso del servicio anti spam predeterminado.

device(anti-spam:ns-profile)-> set sbl default-server-enable
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

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.
NOTA: El filtrado de Web integrado requiere que se instale una clave de licencia en el
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.
NOTA: Utilice el filtrado de Web integrado para administrar el tráfico HTTPS. El filtrado de
Web desviado no admite el tráfico HTTPS.
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.
100 Filtrado de Web

2. Iniciar el modo de filtrado de Web.
Ejecutar el comando set url protocol { sc-cpa | scfp | websense } coloca a la

CLI en el contexto de filtrado de Web. Una vez que se ha iniciado el contexto de
filtrado de Web, todas las ejecuciones de comandos posteriores se aplican a ese
modo de filtrado de Web.
La Tabla 3 muestra los comandos para entrar y salir de los tres diferentes modos de
filtrado de Web.
Tabla 3: Entrada y salida de los modos de filtrado de Web
Filtrado de Web Reenviar a Reenviar a

integrado servidor SurfControl servidor Websense
1. Seleccionar set url protocol type sc-cpa set url protocol type scfp set url protocol type websense
el protocolo
2. Iniciar el set url protocol sc-cpa set url protocol scfp set url protocol websense
contexto de (url:sc-cpa)-> : (url:scfp)-> : (url:websense)-> :
filtrado de
Web
3. Salir del (url:sc-cpa)-> :exit (url:scfp)-> :exit (url:websense)-> :exit
modo 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 101

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).
102 Filtrado de Web

El servidor CPA de SurfControl actualiza periódicamente su lista de categorías. Ya

que el servidor de CPA no notifica a sus clientes cuando se actualiza la lista, el
dispositivo de seguridad debe revisar periódicamente el servidor de CPA. De forma
predeterminada, el dispositivo consulta el servidor de CPA para conocer las
actualizaciones de categoría cada dos semanas. Se puede cambiar este valor
predeterminado para que se ajuste al entorno de sus conexiones en red. También
puede actualizar manualmente la lista de categorías al introducir el contexto de
filtrado de Web y ejecutar el comando exec cate-list-update. Para actualizar
manualmente la lista de categoría, realice lo siguiente:
device-> set url protocol sc-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(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
Filtrado de Web 103

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(url:sc-cpa)-> set enable
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(url:sc-cpa)-> get category pre
104 Filtrado de Web

La lista de categorías de URL que se muestra es similar a la que se figura en la

Tabla 4.
Tabla 4: Lista parcial de categorías URL de SurfControl
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
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.
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.
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
Category Name: Competidores

URL: www.juegos1.com
URL: www.juegos2.com
Filtrado de Web 105

CLI
device(url:sc-cpa)-> set category ompetidores url www.juegos1.com
device(url:sc-cpa)-> set category competidores url www.juegos2.com
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(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
106 Filtrado de Web

Category Action
Advertisements block
Arts & Entertainment permit
Chat permit
Computing & Internet permit
.
.
.
Violence block
Weapons block
Web-based Email permit
other permit
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.
NOTA: Debe utilizar WebUI para clonar ns-profile.
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
Profile Name: mi-perfil

Subscribers Identified by:
Category Name: Competidores (seleccione)
Action: Block (seleccione)
Configure: Add (seleccione)
Filtrado de Web 107

NOTA: Para configurar la acción predeterminada utilizando CLI, especifique la acción

para la otra categoría.
CLI
device(url:sc-cpa)-> set profile mi-perfil other permit
device(url:sc-cpa)-> set profile mi-perfil competidores block
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
Petición de HTML
¿En la N ¿En la N ¿Categoría definida N ¿Categoría definida N Acción predeterminada -

lista negra? lista blanca? por el usuario? por el usuario? Bloquear/Permitir
S S S S
Bloquear URL Permitir URL Bloquear/Permitir según se defina Bloquear/Permitir según se defina
108 Filtrado de Web

Si el dispositivo determina que la URL está en una categoría permitida y si el

análisis AV está habilitado para esa directiva, entonces el dispositivo analiza el
contenido en busca de virus. Si el dispositivo determina que la URL está en una
categoría bloqueada, termina la conexión TCP, envía un mensaje de alerta al
usuario y no realiza el análisis AV.
Ejemplo: Filtrado de Web 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
Category Name: Competidores

URL: www.comp1.com
URL: www.comp2.com
3. Perfil de filtrado de Web
Security > Web Filtering > Profile > Custom Profile > New: Introduzca los
Profile Name: mi-perfil

Category Name: Competidores (seleccione)

Action: Block (seleccione)
Configure: Add (seleccione)
Filtrado de Web 109

4. Directiva
haga clic en OK:
Source Address:
Service: HTTP
Web Filtering: (seleccione), mi-perfil
Action: Permit
CLI
1. Filtrado de Web
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
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.
NOTA: Para obtener información adicional sobre Websense, visite www.websense.com.

Para obtener información adicional sobre SurfControl, visite
www.surfcontrol.com.
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.
110 Filtrado de Web

Figura 41: Una URL bloqueada de la zona Trust a la zona Untrust

set policy from trust to untrust Servidor de filtrado de
any any http permit web-filter Web (en la zona Trust)
Cliente HTTP Petición de Respuesta de filtrado

filtro de Web Servidor HTTP
de Web: “block”

Establecimiento de
comunicación TCP SYN
de 3 fases SYN/ACK
ACK
Petición
HTTP-Get 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 Web. El servidor de
filtrado de Web responde con un mensaje de “bloqueo”.
Mensaje de URL
bloqueada BLCK URL
TCP RST RST RST
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.
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

set policy from trust to untrust Servidor de filtrado de Web
any http permit url-filter (en la zona Trust)
Petición de Respuesta de filtrado Servidor HTTP

Cliente HTTP de URL: “permit”
filtrado de URL

Establecimiento
de comunicación SYN
TCP de 3 fases SYN/ACK
ACK
Petición HTTP GET
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).
Reenvío de la HTTP GET
petición HTTP GET
Respuesta de HTTP
Filtrado de Web 111

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.
112 Filtrado de Web

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.
Filtrado de Web 113

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(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”.
114 Filtrado de Web

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.
NOTA: Si selecciona Juniper Networks, algunas de las funciones que ofrece Websense,
como el desvío, quedarán suprimidas.
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(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
Filtrado de Web 115

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.
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
Zone Name: Trust

Interface Mode: NAT
Network > Interfaces > List >Edit (para ethernet3): Introduzca los siguientes
Zone Name: Untrust

116 Filtrado de Web

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


4. Directiva
Source Address:
Service: HTTP
Action: Permit
Web Filtering: (seleccione)
Filtrado de Web 117

CLI
1. Interfaces
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
4. Directiva
set policy from trust to untrust any any http permit url-filter
save
118 Filtrado de Web

Capítulo 5
Deep Inspection
Puede habilitar Deep Inspection (DI) en directivas para examinar el tráfico

permitido y realizar las acciones correspondientes si el módulo DI en ScreenOS
detecta signos de ataque o anomalías en el protocolo. En las siguientes secciones de
este capítulo se presentan los elementos de DI que aparecen en las directivas y se
explica la manera de configurarlos:
“Vista general” en la página 120
“Servidor de la base de datos de objetos de ataque” en la página 124
“Objetos de ataque y grupos” en la página 132
“Protocolos admitidos” en la página 133
“Firmas completas” en la página 137
“Firmas de secuencias TCP” en la página 138
“Anomalías en el protocolo” en la página 138
“Grupos de objetos de ataque” en la página 139
“Desactivación de objetos de ataque” en la página 142
“Acciones de ataque” en la página 143
“Acciones de ataques de fuerza bruta” en la página 151
“Registro de ataques” en la página 154
“Asignación de servicios personalizados a aplicaciones” en la página 156
“Objetos de ataque y grupos personalizados” en la página 160
“Objetos de ataque de firma completa que define el usuario” en la

página 160
“Objetos de ataque de la firma de la secuencia de TCP” en la página 165
“Parámetros configurables de anomalías en protocolos” en la página 167
“Negación” en la página 168
119
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.
120 Vista general

Capítulo 5: Deep Inspection
Figura 43: Inspección activa del cortafuegos
Inspección activa del ¿Cumple un paquete inicial de una

cortafuegos ¿Cumple? No sesión con los requisitos L3 y L4 de
una directiva?
Descartar el
paquete O bien...
Sí
¿Cumple con las expectativas en la
tabla de sesiones el estado de un
paquete en una sesión existente?
¿Se permite? No ¿Permite o rechaza la directiva

este paquete?
Descartar el
paquete
Sí
Firma completa, anomalías en protocolos y

(en algunos el dispositivo de seguridad) ¿DI? ¿Se detectó
Inspección de secuencia de TCP Sí un ataque? Sí
Realizar acción de
respuesta al ataque
No No
Reenviar el paquete
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.
NOTA: Si la acción especificada es encapsular, ésta implica un permiso (tráfico

permitido). Observe que si habilita DI en una directiva cuya acción sea encapsular,
el dispositivo de seguridad ejecuta las operaciones de DI especificadas antes de la
encriptación de un paquete saliente y tras la desencriptación de un paquete
entrante.
Vista general 121

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

Primero: Inspección del cortafuegos (Capas de red): Después: Deep Inspection (Capas de red y aplicación):
IP ORIG, IP DEST, PTO ORIG, PTO DEST IP ORIG, IP DEST, PTO ORIG, PTO DEST
y servicio (Protocolo) Servicio (Protocolo) y datos transportados
Cortafuegos Deep Inspection
IP ORIG IP DEST PTO ORIG PTO DEST PROTO IP ORIG IP DEST PTO ORIG PTO DEST PROTO
Datos de carga Datos de carga
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).
122 Vista general

El comando set policy se puede separar conceptualmente en dos partes: la sección

central y el componente DI:
La sección central contiene las zonas de origen y de destino, las direcciones de

origen y de destino, uno o más servicios y una acción.
El componente DI ordena al dispositivo de seguridad examinar el tráfico

permitido por medio de la sección central de la directiva para saber si hay
patrones que coincidan con los objetos de ataque que se encuentran en uno o
más de los grupos de objetos de ataque. Si el dispositivo de seguridad detecta
un objeto de ataque, ejecuta posteriormente la acción definida por el grupo
correspondiente.
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.)
El siguiente comando set policy contiene un componente de DI:
Figura 45: El componente de DI en el comando Set Policy

Sección central de una directiva Componente de Deep Inspection
set policy id 1 from untrust to dmz any websrvl http permit attack HIGH:HTTP action close
Zona de Dirección de Servicio Grupo de

origen origen ataque Acción si el dispositivo
de seguridad detecta
Zona de Dirección de Acción si el tráfico cumple un ataque
destino destino con los criterios de los
componentes de L3 y L4
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(policy:1)->
Vista general 123

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.
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(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-> 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.
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.
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.
124 Servidor de la base de datos de objetos de ataque

Tabla 5: Paquetes de firmas predefinidas
Paquete de firmas Descripción Cobertura de la amenaza

Básico1 Un conjunto seleccionado de firmas para Incluye un gusano de muestra, firmas de cliente a
protección de gusanos y clientes/servidores servidor y de servidor a cliente para los protocolos y
optimizada para sucursales y oficinas remotas servicios orientados a Internet, como HTTP, DNS,
así como para pequeñas y medianas empresas. FTP, SMTP, POP3, IMAP, NetBIOS/SMB, MS-RPC, P2P
e IM (AIM, YMSG, MSN e IRC).
Protección del Para pequeñas y medianas empresas y Principalmente se centra en proteger la granja de
servidor sucursales y oficinas remotas de empresas servidores. Esto incluye un conjunto integral de
importantes que necesitan el cumplimiento y protocolos orientados a servidores, como HTTP, DNS,
defensa de perímetro para infraestructuras del FTP, SMTP, IMAP, MS-SQL y LDAP. También se
servidor, como IIS, Exchange y Oracle. incluyen las firmas de gusanos cuyo objetivo son los
servidores.
Protección del Para pequeñas y medianas empresas, además de Se centra principalmente en evitar que los usuarios
cliente sucursales y oficinas remotas de empresas reciban malware, caballos de Troya, etc., mientras
importantes que necesitan el cumplimiento y navegan por Internet. Esto incluye un conjunto
defensa de perímetro para los host (equipos de integral de protocolos orientados a los clientes, como
escritorio, portátiles, etc.). 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 Para sucursales y oficinas remotas de empresas Incluye firmas de secuencias y se centra
gusanos importantes, así como pequeñas y medianas principalmente en proporcionar protección completa
empresas para proporcionar la defensa más contra gusanos. Detecta ataques de gusanos de
completa contra ataques de gusanos. 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.
La Tabla 6 enumera los paquetes de firmas predefinidas con las URL

correspondientes.
Tabla 6: URL para paquetes de firmas predefinidas
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
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
Servidor de la base de datos de objetos de ataque 125

“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
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.
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: Después de descargar el paquete de firmas por primera vez, se debe restablecer el
dispositivo de seguridad. A partir de entonces, después de cada descarga, no es
necesario restablecer el dispositivo.

Actualización 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
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

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

objetos de ataque objetos de ataque .com/restricted/sigupdates
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.

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
Dispositivo de seguridad local Servidor de la base de

datos de objetos de ataque
1. Comprobación automática
de la actualización
S M T W T F S
Internet
Base de datos de 2. Actualización inmediata de la Base de datos de https://services.juniper

objetos de ataque base de datos objetos de ataque .com/restricted/sigupdates
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
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.
CLI
set attack db sigpack server
set attack db mode update
set attack db schedule weekly monday 04:00
save

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
Dispositivo de seguridad local Servidor de la base de datos

1. Comprobación automática de
la actualización
S M T W T F S
Internet
https://services.juniper
.com/restricted/sigupdates
Base de datos de 2. Actualización inmediata de la Base de datos de
objetos de ataque base de datos objetos de ataque
WebUI
1. Comprobación programada de la base de datos
haga clic en OK:
Signature Pack: Client

Update Mode: Automatic Notification
Schedule:
Daily
Time (hh:mm): 07:00

2. Actualización inmediata de la base de datos

Cuando reciba un aviso de que la base de datos de ataques del servidor está
más actualizada que la del dispositivo 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).
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.
En este ejemplo (consulte la Figura 49), guardará manualmente el paquete de

firmas más reciente en el directorio local “C:\netscreen\attacks-db” (si desea utilizar
WebUI para cargar la base de datos) o en C:\Archivos de Programa\TFTP Server
(si prefiere utilizar CLI). A continuación cargará la base de datos en el dispositivo de
seguridad de su directorio local.
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.
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

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

Servidor de la base de datos
Dispositivo de seguridad local 1. Descarga manual de la base de datos
Internet
2. Actualización
manual de la URL = https://services.netscreen.com/
Base de datos de base de datos Base de datos de /restricted/sigupdates/5.4/ns200/attacks
objetos de ataque objetos de ataque .bin?sn=0043012001000213
Admin: 10.1.1.5
C:\netscreen\attacks-db C:\Archivos de
programa\TFTP Server
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:\netscreen\attacks-db”

(para cargar a través de WebUI) o en el directorio “C:\Archivos de
programa\TFTP Server” del servidor TFTP (cuando desee utilizar CLI para
cargarlo).
2. Actualización del paquete de firmas

WebUI
haga clic en OK:
Deep Inspection Signature Update:

Load File: Introduzca C:\netscreen\attacks-db\attacks.bin
O bien
Haga clic en Browse y navegue hacia ese directorio, seleccione attacks.bin

y después haga clic en Open.

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

set policy from untrust to dmz any Attack Group: HIGH:HTTP:SIGS
websrv1 http permit attack
HIGH:HTTP:SIGS action close /scripts/\.\.%c1%9c\.\./.* .*%255(c|C).* .*\[.asp::$data\].*
PUT \[/users/.*\.asp\].* /phorum/plugin/replace/pluring.php?*p
/\[scripts/iisadmin/ism\.dll\?http/dir\]. *revlog/.*
Host remoto Dispositivo de seguridad websrv1

1.1.1.3:25611 Untrust: ethernet3 1.1.1.1/24; DMZ: ethernet2 1.2.2.1/24 1.2.2.5:80
Zona Untrust Zona DMZ
SYN
SYN/ACK
ACK
IP ORIG Coincide
IP DEST PTO ORIG PTO DEST PROTO
1.1.1.3 1.2.2.5 25611 80 HTTP
Carga: … revlog/.
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.
RST RST
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
132 Objetos de ataque y grupos

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
Anomalía
Firmas en el
Protocolo completas protocolo Definición
DNS Sí Sí Sistema de nombres de dominio (DNS) es un sistema de base de datos para
traducir nombres de dominios a direcciones IP, como
www.juniper.net = 207.17.137.68.
FTP Sí Sí El protocolo de transferencia de archivos (FTP) es un protocolo para intercambiar
archivos entre equipos a través de una red.
HTTP Sí Sí El protocolo de transferencia de hipertexto (HTTP) es un protocolo que se utiliza
principalmente para transferir información de servidores web a clientes web.
IMAP Sí Sí El protocolo de acceso de correo electrónico de Internet (IMAP) es un protocolo
que proporciona servicios de recuperación y almacenamiento de correos
electrónicos entrantes con la opción de que los usuarios puedan descargar sus
correos electrónicos o dejarlos en el servidor IMAP.
NetBIOS Sí Sí NetBIOS (Sistema básico de entrada/salida de red) es una interfaz de aplicación
que le permite a las aplicaciones de las estaciones de trabajo de los usuarios
obtener acceso a los servicios de red proporcionados por los transportes de red
como NetBEUI, SPX/IPX y TCP/IP.
POP3 Sí Sí El protocolo de oficina de correo, versión 3 (POP3) es un protocolo que
proporciona servicios de recuperación y almacenamiento de correo electrónico
entrante.
SMTP Sí Sí Protocolo simple de transferencia de correo electrónico (SMTP) es un protocolo
que se utiliza para la transferencia de correo electrónico entre servidores de
correo electrónico.
Chargen Sí Sí Protocolo generador de caracteres
Objetos de ataque y grupos 133

Anomalía
Firmas en el
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.

Anomalía
Firmas en el
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.
Tabla 8: Aplicaciones de mensajería inmediata
Anomalía
Firmas en el
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.
Tabla 9: Aplicaciones de redes Punto a punto (P2P)

Anomalía
Firmas en el
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 Sí No DC (Direct Connect) es una aplicación de reparto de archivos de P2P. Una red de
(Direct connect) 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.

Anomalía
Firmas en el
eDonkey Sí No eDonkey es una aplicación de reparto de archivos de P2P descentralizada que
utiliza el protocolo de transferencia de archivos de múltiples fuentes (MFTP). La
red Donkey admite dos clases de aplicaciones: clientes y servidores. Los clientes
se conectan a la red y comparten archivos. Los servidores actúan como
concentradores de reunión para los clientes.
Gnutella Sí Sí Gnutella es una aplicación y protocolo P2P para compartir archivos que no
incluye ningún servidor centralizado. Algunas otras aplicaciones que utilizan el
protocolo Gnutella son: BearShare, Limewire, Morpheus y ToadNode.
KaZaa Sí No KaZaa es una aplicación P2P descentralizada para compartir archivos que utiliza
el protocolo FastTrack. KaZaa se utiliza principalmente para compartir archivos
MP3.
MLdonkey Sí No MLdonkey es una aplicación de cliente de P2P que se puede ejecutar en múltiples
plataformas y puede obtener acceso a múltiples redes de P2P, como BitTorrent,
DC, eDonkey, FastTrack (KaZaa, entre otros), así como Gnutella y Gnutella2.
Skype Sí No Skype es un servicio telefónico gratis de Internet P2P que permite a los usuarios
hablar entre ellos a través de una red TCP/IP como Internet.
SMB Sí Sí SMB (bloque de mensaje del servidor) es un protocolo que se utiliza para
compartir recursos como archivos e impresoras entre equipos. SMB funciona en
control del protocolo NetBIOS.
WinMX Sí No WinMX es una aplicación P2P para compartir archivos que permite que un
cliente se conecte a varios servidores a la vez.
NOTA: Varias de las aplicaciones de P2P enumeradas, utilizan sus propios protocolos
patentados.
Tabla 10: Puertas de enlace en la capa de aplicación (ALG)
Anomalía
Firmas en el
MSRPC Sí Sí MSRPC (llamada del procedimiento remoto de Microsoft) es un mecanismo que
se utiliza para llevar a cabo procesos en equipos remotos.
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

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

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.
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.
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).
NOTA: Las firmas de secuencias TCP sólo se pueden definir en sistemas de gama alta.
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
anomalías del protocolo predefinidas, consulte “Protocolos admitidos” en la
página 133.
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.

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
Nivel de gravedad de Nivel de gravedad de entrada

objetos de ataque – Se corresponde con – de registro de eventos
Critical Critical
High Error
Medium Warning
Low Notification
Info Information
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.

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
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.
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.
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.
WebUI
haga clic en OK:
Source Address:
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

> 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
Log: (seleccione)
Severity: Default
Group: INFO:HTTP:SIGS
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
save
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.
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: La desactivación de los objetos de ataque no mejora el rendimiento total.

Para deshabilitar un objeto de ataque, ejecute cualquiera de los siguientes

procedimientos:
WebUI
Objects > Attacks > Predefined Desactive la casilla de verificación en la
columna Configure para el objeto de ataque que desee desactivar.
CLI
set attack disable nombre_ataque_objeto
Para volver a habilitar un objeto de ataque que se deshabilitó previamente, ejecute

uno de los siguientes procedimientos:
WebUI
Objects > Attacks > Predefined Seleccione la casilla de verificación en la
columna Configure para el objeto de ataque que desee habilitar.
CLI
unset attack disable nombre_ataque_objeto
Acciones de ataque
Cuando el dispositivo de seguridad detecta un ataque, ejecuta la acción que se
especificó para el grupo de ataque que contiene el objeto que coincide con el
ataque. Las siete acciones son las siguientes, organizadas de la más a la menos
severa:
Close (interrumpe la conexión y envía RST al cliente y al servidor)
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.
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.
Acciones de ataque 143

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.
144 Acciones de ataque

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.
CRITICAL:FTP:SIGS
Acción para todos los grupos de objetos de ataque: Close
Decide interrumpir la conexión y enviar una notificación RST de TCP tanto a los
clientes como a los servidores protegidos para que ambos puedan terminar sus
sesiones y borrar sus recursos independientemente del nivel de gravedad del
ataque.
Directiva con ID 3: Permitir el tráfico de FTP-GET, HTTP, HTTPS, PING desde

cualquier dirección de la zona Trust a cualquier dirección de la zona Untrust.

CRITICAL:FTP:SIGS
Acción para todos los grupos de objetos de ataque: Close Client
Optará por interrumpir la conexión y enviar una notificación RST de TCP a los
clientes protegidos para que ambos puedan terminar sus sesiones y borrar sus
recursos. En este caso, usted prevé un ataque procedente de un servidor HTTP
o FTP no fiable.
Aunque las directivas permiten HTTP, HTTPS, Ping, FTP-Get o FTP, el dispositivo de
seguridad activa DI únicamente para el tráfico de HTTP y FTP. Todas las zonas se
encuentran en el dominio de enrutamiento trust-vr.
Figura 51: Acciones de ataque DI
Zona Untrust
DI (Untrust -> DMZ)
HTTP:Crit, High, Med;
FTP:Crit
ethernet3 Action:Close-server
1.1.1.1/24
Zona DMZ
DI (Trust -> Untrust)

HTTP: Crit, High,
Med; FTP: Crit; ethernet2 websrv1 websrv2
Action: Close-client 1.2.2.1/24 1.2.2.5/24 1.2.2.6/24
ethernet1 DI (Trust -> DMZ)

10.1.1.1/24 HTTP:Crit, High,
Med; FTP:Crit;
Zona Trust Action:Close
WebUI
1. Interfaces
Zone Name: Trust


Interface Mode: NAT

Service Options:
Management Services: (seleccione todos)
Other services: Ping
haga clic en OK:
Zone Name: Untrust

haga clic en OK:
Zone Name: DMZ

2. Direcciones
Address Name: websrv1

Zone: DMZ
Address Name: websrv2

Zone: DMZ
3. Ruta

4. ID de directiva 1
haga clic en OK:
Source 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
Action: Permit
Group: CRITICAL:HTTP:ANOM
Action: Close Server
Log: (seleccione)
Group: CRITICAL:HTTP:SIGS
Log: (seleccione)
Group: HIGH:HTTP:ANOM
Log: (seleccione)
Log: (seleccione)
Group: MEDIUM:HTTP:ANOM
Log: (seleccione)
Group: MEDIUM:HTTP:SIGS
Log: (seleccione)
Group: CRITICAL:FTP:SIGS
Log: (seleccione)
Policies > (From: Trust, To: DMZ) New: Introduzca los siguientes datos y haga
clic en OK:
Source Address:
Address Book Entry: (seleccione), websrv1
> Haga clic en Multiple, seleccione websrv2 y después haga clic en OK

para regresar a la página de configuración básica de directivas.
Service: HTTP
Action: Permit

Action: Close
Log: (seleccione)
Action: Close
Log: (seleccione)
Action: Close
Log: (seleccione)
Action: Close
Log: (seleccione)
Action: Close
Log: (seleccione)
Action: Close
Log: (seleccione)
Action: Close
Log: (seleccione)
haga clic en OK:
Source Address:
Service: HTTP
Action: Permit
Log: (seleccione)
Log: (seleccione)
Log: (seleccione)
Log: (seleccione)

Log: (seleccione)
Log: (seleccione)
Log: (seleccione)
CLI
1. Interfaces
set interface ethernet1 manage
2. Direcciones
set address dmz websrv1 1.2.2.5/32
set address dmz websrv2 1.2.2.6/32
3. Ruta
set policy id 1 from untrust to dmz any websrv1 http permit attack
CRITICAL:HTTP:ANOM action close-server
set policy id 1
device(policy:1)-> set service ftp-get
device(policy:1)-> set service ping
device(policy:1)-> set attack HIGH:HTTP:ANOM 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

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 service ftp
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
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 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
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.

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
Nombre de los ataques de fuerza bruta Parámetro

Intento de inicio de sesión de fuerza bruta de failed_logins
HTTP
Intento de búsqueda bruta de HTTP brute_search
IMAP
LDAP
Inundación de petición MS-RPC No se puede configurar, 32 intentos
IsSystemActive
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 failed_login
POP3
Intento de autenticación de fuerza bruta de failed_auth
RADIUS
Crear/borrar directorios de fuerza bruta de No se puede configurar, 200 intentos
SMB
SMB
FTP
Telnet
VNC
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.

Tabla 13: Opciones de destino
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)
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

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
154 Registro de ataques

La directiva se aplica al tráfico de IMAP proveniente de todos los hosts en la zona

Trust hacia el servidor de correo electrónico llamado “mail1” en la zona DMZ. Si
alguno de los objetos de ataque IMAP predefinidos en los cinco grupos anteriores
coincide con un ataque, el dispositivo de seguridad cierra la conexión. Sin embargo,
dicha acción únicamente crea entradas de registro para detectar ataques que
coincidan con los objetos de ataque que se encuentran en los dos primeros grupos.
WebUI
1. Dirección
Address Name: mail1

Zone: DMZ
2. Directiva
clic en OK:
Source Address:
Address Book Entry: (seleccione), mail1
Service: IMAP
Action: Permit
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
Group: INFO:IMAP:ANOM
Action: Close
CLI
1. Dirección
set address dmz mail1 1.2.2.10/32
Registro de ataques 155

2. Directiva
device-> set policy id 1 from trust to dmz any mail1 imap permit attack
HIGH:IMAP:ANOM action close
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-> 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

El cortafuegos permite tráfico
custom-ftp en el puerto 2121.
custom-ftp (puerto 2121)

Internet
FTP (puerto 21) ftp-srv1
Sin embargo, el módulo DI comprueba si hay ataques CRITICAL:FTP en el puerto 21, que no están en uso.
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
156 Asignación de servicios personalizados a aplicaciones

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
El cortafuegos permite tráfico custom-ftp en el puerto 2121.
custom-ftp (puerto 2121)

Internet
El módulo DI comprueba si hay ataques
CRITICAL:FTP:SIGS en el puerto 2121.
ftp-srv1
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:
Acción para todos los grupos de objetos de ataque: Close Server
WebUI
1. Servicio personalizado
Service Name: HTTP1

Source Port Low: 0
Asignación de servicios personalizados a aplicaciones 157

2. Dirección
Address Name: servidor1

Zone: DMZ
3. Directiva
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), servidor1
Service: HTTP1
Application: HTTP
Action: Permit
Log: (seleccione)
Log: (seleccione)
Log: (seleccione)
Log: (seleccione)
Log: (seleccione)
Log: (seleccione)
CLI
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
158 Asignación de servicios personalizados a aplicaciones

3. Directiva
device-> set policy id 1 from untrust to dmz any servidor1 HTTP1 permit attack
CRITICAL:HTTP:ANOM action close-server
device(policy:1)-> set attack HIGH:HTTP:ANOM 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-> 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.
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.
WebUI
Service Name: HTTP2

Source Port Low: 0
Asignación de servicios personalizados a aplicaciones 159

2. Directiva
haga clic en OK:
Source Address:
Service: HTTP2
Application: HTTP
Action: Permit
Action: Close
Log: (seleccione)
Action: Close
Log: (seleccione)
CLI
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(policy:1)-> set attack MEDIUM:HTTP:SIGS action close
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:”).
160 Objetos de ataque y grupos personalizados

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.
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.
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
Finalidad Metacaracteres Ejemplo Significado

Coincidencia binaria directa \Onúmero_octal \0162 Coincidir exactamente con
(octal)1 Coincide con: este número octal: 162
162
Coincidencia binaria directa \Xnúmero_hexadecimal\X \X01 A5 00 00\X Coincidir exactamente con
(hexadecimal)2 Coincide con: estos cuatro números
01 A5 00 00 hexadecimales:
01 A5 00 00
Coincidencias sin distinguir \[caracteres\] \[cat\] Buscar los caracteres
mayúsculas de minúsculas Coincide con: contenidos en cat sin importar
Cat, cAt, caT
si están en letras mayúsculas
o minúsculas
CAt, CaT, CAT
cat, cAt
Coincidencia con cualquier . c.t Busca c, cualquier carácter, t

carácter Coincide con:
cat, cbt, cct, … czt
cAt, cBt, cCt, … cZt
c1t, c2t, c3t, … c9t
Objetos de ataque y grupos personalizados 161

Finalidad Metacaracteres Ejemplo Significado

Buscar el carácter anterior * a*b+c Buscar cero, una o más
cero o más veces, en lugar de Coincide con: ocurrencias de a, seguidas por
sólo una vez. bc
una o más ocurrencias de b y
seguidas por una ocurrencia
bbc de c.
abc
aaabbbbc
Buscar una o más + a+b+c Buscar una o más ocurrencias

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

cero veces o una vez. Coincide con: droppacket
drop-packet
droppacket
Expresiones de grupos ()
El carácter anterior o el | (drop | packet) Buscar drop o packet.
siguiente. Generalmente se Coincide con:
utiliza con ( ) drop
packet
Rango de caracteres [comienzo-final] [c-f]a(d | t) Buscar todo lo que comience

Coincide con: con c, d, e o f, tenga la letra
cad, cat
central a y la última letra d o t
dad, dat
ead, eat
fad, fat
Negación del carácter [^carácter] [^0-9A-Z] Buscar letras minúsculas

siguiente. Coincide con:
a, b, c, d, e, … z
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.


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
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”
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
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
clic en OK:
Attack Name: cs:url-index

Attack Context: HTTP URL Parsed
Attack Severity: High
Attack Pattern: .*index.html.*

4. Objeto de ataque 4: spammer

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
haga clic en OK:
Source Address:
Service: HTTP
> Haga clic en Multiple, seleccione FTP y después haga clic en OK para
regresar a la página de configuración básica de directivas.
Action: Permit
Group: CS:DMZ DI
Log: (seleccione)

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
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
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.
NOTA: Las firmas de secuencias de TCP sólo se pueden definir en sistemas de la serie
NetScreen-5000.
Dado que no hay objetos de ataque de firma de la secuencia 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

Figura 54: Ejemplo de un objeto de ataque de firma de secuencia de TCP
set attack "CS:A1" stream ".*satori.*" severity critical
Nombre Tipo Definición Nivel de gravedad

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
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
haga clic en OK:
Source Address:
Service: ANY
Action: Permit

Group: CS:Gr1
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.
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.
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.
Valor
Parámetro del protocolo predeterminado Nuevo
SMB: Número máximo de fallos de inicio de sesión por 4 fallos 8 fallos
minuto
Gnutella: Número máximo de saltos de plazo de vida (TTL) 8 saltos 10 saltos

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:
Valor
Parámetro del protocolo predeterminado Nuevo
AOL Instant Messenger (AIM): Máxima longitud del nombre 10.000 bytes 5.000 bytes
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.
AOL Instant Messenger: Máxima longitud de una trama FLAP 10.000 bytes 5.000 bytes
(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.
WebUI
NOTA: Debe utilizar la CLI para modificar los parámetros de anomalías de protocolos.
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.
168 Negación
En el ejemplo se utilizan los siguientes ajustes:
El nombre de usuario y contraseña correcta son admin1 y pass1.
El servidor FTP se encuentra en 1.2.2.5 de la zona DMZ. Su nombre de

dirección es ftp1.
Se aplica DI en el tráfico de FTP para el servidor desde todos los hosts en las
zonas Untrust y Trust.
Todas las zonas de seguridad se encuentran en el dominio de enrutamiento

trust-vr.
Creará los dos objetos de ataque siguientes:
Objeto de ataque No. 1:
Name: CS:FTP1_USR_OK
Negation: enabled
Context: ftp-username
Pattern: admin1
Severity: high
Objeto de ataque No. 2:
Name: CS:FTP1_PASS_OK
Negation: enabled
Context: ftp-password
Pattern: pass1
Severity: high
Posteriormente se colocaran los dos objetos en un grupo de objetos de ataque

llamado CS:FTP1_LOGIN y que se refieren a ese grupo de objetos de ataque en dos
directivas que permiten el tráfico de FTP desde las zonas Trust y Untrust hacia ftp1
en la zona DMZ.
Negación 169
Figura 55: Negación de objeto de ataque
Nota: Por simplicidad, el enrutador externo en la zona

Untrust no se muestra. Su dirección es 1.1.1.250.
Untrust
Intento de inicio de Internet Intento de inicio de sesión:

sesión: Nombre de usuario: admin1
Nombre de usuario: Contraseña: pass1
123456
Contraseña: 123456 ethernet2
ethernet3 1.2.2.1/24
1.1.1.1/24 DMZ
Servidor
FTP “ftp1”
1.2.2.5
LAN
ethernet1
10.1.1.1/24
Intento de inicio de Intento de inicio de sesión:

sesión: Nombre de usuario: admin1
Nombre de usuario: LAN Contraseña: pass1
anon
Contraseña: logos
Trust
WebUI
1. Interfaces
Zone Name: Trust

Seleccione los siguientes datos y haga clic en OK:
haga clic en OK:
Zone Name: DMZ

haga clic en OK:
Zone Name: Untrust

170 Negación
2. Dirección
Address Name: ftp1

Zone: DMZ
3. Objeto de ataque 1: CS:FTP1_USR_OK
clic en OK:
Attack Name: CS:FTP1_USR_OK

Attack Context: ftp-username
Attack Pattern: admin1
Pattern Negation: (seleccione)
4. Objeto de ataque 2: CS:FTP1_PASS_OK
clic en OK:
Attack Name: CS:FTP1_PASS_OK

Attack Context: ftp-password
Attack Pattern: pass1
Pattern Negation: (seleccione)
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

Negación 171
7. Directivas
haga clic en OK:
Source Address:
Service: FTP
Action: Permit
Group: CS:FTP1_LOGIN
Action: Drop
Log: (seleccione)
clic en OK:
Source Address:
Service: FTP
Action: Permit
Group: CS:FTP1_LOGIN
Action: Drop
Log: (seleccione)
CLI
1. Interfaces
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
172 Negación
4. Ruta
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).
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.
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.
Bloqueo granular de los componentes de HTTP 173

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
174 Bloqueo granular de los componentes de HTTP

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.
“Dispositivos de seguridad con capacidad para IDP” en la página 176
“Flujo de tráfico en un dispositivo con capacidad de IDP” en la página 176
“Configuración de la detección y prevención de intrusiones” en la página 177
“Configuración de directivas de seguridad” en la página 185
“Uso de las bases de normas de IDP” en la página 187
“Habilitación de IDP en las normas de cortafuegos” en la página 189
“Configuración de las normas de IDP” en la página 191
“Configuración de las normas de exclusión” en la página 205
“Configuración de las normas de puerta de atrás” en la página 210
“Configuración de los objetos de ataque de IDP” en la página 215
“Configuración del dispositivo como un dispositivo IDP independiente” en la

página 235
“Administración de IDP” en la página 238
175
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
NOTA: La instalación de la clave de licencia IDP desactiva la función de Deep Inspection

(DI) de ScreenOS.
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.
176 Dispositivos de seguridad con capacidad para IDP

Capítulo 6: Detección y prevención de intrusiones
Figura 56: Flujo de tráfico en el dispositivo de seguridad
Flujo de tráfico
Sin IDP Se crea la sesión y el

1. Consulta de paquete sale del dispositivo
rutas 2. Consulta IDP en línea
de directivas
IDP en línea a
Módulo de demanda
administración El paquete se envía al
módulo de seguridad que
está menos cargado para la
inspección de IDP
PW R A LA R M TEM P S TAT U S HA
Módulo de seguridad
FA N M OD1 M OD2 M OD3 F LA S H
ISG 2000
Juniper Networks
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
Configuración de la detección y prevención de intrusiones 177

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.
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
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
Juniper Networks
Internet
PW R A LA R M T E MP S TAT U S H A
FA N M O D1 M O D2 M O D3 F LA S H
ISG 2000
FTP-Srv1
178 Configuración de la 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 (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.

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”.
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.
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 Módulo de seguridad 1
2 1 1 8
4 0 1 0
6 0 1 0

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.
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.
10. Actualice regularmente la base de datos de objetos de ataque en el servidor

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
Dispositivos de
Dispositivo A seguridad
Zona Untrust
PW R
FA N
A LA RM
M OD1
TEM P
M OD2
S TAT U S
M OD3
HA
FLA SH
ISG 2000
Zona Trust
Internet Dispositivo B
PW R
FA N
A LA RM
M OD1
TEM P
M OD2
S TA T U S
M OD3
HA
FLA SH
ISG 2000
FTP-Srv1
Cambio en caso de fallo activo, pasivo

Dispositivo A (maestro)
ID VSD 0
Dispositivo B (respaldo)

Configure el dispositivo como se muestra en la Figura 58, después realice lo

siguiente:
1. Configure el dispositivo A y el dispositivo B para IDP de la manera que se

describe en el “Ejemplo 1: Configuración básica de IDP” en la página 178.
2. Para garantizar un flujo de tráfico continuo, puede cablear y configurar dos

dispositivos de seguridad en un clúster redundante de tal forma que el
dispositivo A actúe como un dispositivo principal y el dispositivo B actúe como
su respaldo.
Cablee e1/x en el dispositivo A a e1/x en el dispositivo B. De la misma manera,

cablee las interfaces e2/x. Para obtener más información sobre cómo cablear
los dos dispositivos entre sí, cómo configurar las direcciones IP administradas
para administrar un dispositivo de respaldo o eliminar posibles puntos de fallo
al configurar conmutadores redundantes en cada lado del par de HA, consulte
el Volumen 11: Alta disponibilidad.
3. Configure las interfaces de HA.
Especifique las zonas con las interfaces de HA. Enlace e1/x y e2/x a la zona HA.
Establezca direcciones de IP para las interfaces de la zona Trust en ambos
dispositivos.
4. Configure un clúster de protocolo de redundancia de NetScreen (NSRP).
Asigne cada dispositivo al ID 0 del clúster de NSRP. Cuando los dispositivos se

convierten en miembros del clúster NSRP, las direcciones IP de sus interfaces
físicas se convierten automáticamente en las direcciones IP de las interfaces de
seguridad virtuales (VSI) de la ID 0 del grupo de dispositivos de seguridad
virtual (VSD). Cada miembro de VSD tiene una prioridad predeterminada de
100. El dispositivo que tenga la mayor ID de unidad se convierte en el
dispositivo principal del grupo VSD. Para obtener más información acerca de
VSD, consulte el Volumen 11: Alta disponibilidad.
Por ejemplo, introduzca la siguiente información en cada uno de los

dispositivos para configurar un clúster NSRP.
a. Agregue el dispositivo a un clúster NSRP y a un grupo VSD.
set nsrp cluster id 0
b. Habilite la sincronización de objetos en tiempo de ejecución (RTO).
set nsrp rto sync all
c. Seleccione los puertos que desea que los dispositivos supervisen.
Si el dispositivo detecta una pérdida de conexión de red en uno de los

puertos supervisados, desencadena un cambio en caso de fallo en el
dispositivo.

set nsrp rto-mirror 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.
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.
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.

Figura 59: Configuración de IDP para cambio en caso de fallo activo, activo
Dispositivos de
Dispositivo A seguridad
Zona Untrust
Zona Trust
PW R A LA RM TEM P STATU S HA
FA N M OD1 M OD2 M OD3 FLA SH

ISG 2000
Internet Dispositivo B
PW R
FA N
A LA RM
M OD1
TEM P
M OD2
STATU S
M OD3
HA
FLA SH
ISG 2000
FTP-Srv1
Cambio en caso de fallo activo/activo
ID VSD 0
Dispositivo B (respaldo)
Dispositivo A (respaldo)
ID VSD 1
Configure el dispositivo como se muestra en la Figura 59, después realice lo

siguiente:
NOTA: Recomendamos que instale el mismo número de módulos de seguridad en ambos

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

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.
NOTA: La sincronización se mantiene solamente para las sesiones de cortafuegos. El

cambio en caso de fallo activo no ocurre en las sesiones de IDP.
Configuración de directivas de seguridad

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.
Configuración de directivas de seguridad 185

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.
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.
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
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.
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
186 Configuración de directivas de seguridad

Uso de las bases de normas de IDP

Después de que una norma de cortafuegos (intrazonal o global) permite el paso del
tráfico de la red, puede dirigir el dispositivo para que inspeccione más el tráfico en
busca de ataques conocidos. NetScreen-Security Manager admite las siguientes
bases de normas de IDP:
IDP: Esta base de normas protege su red de ataques al utilizar objetos de ataque
para detectar ataques conocidos y desconocidos. Juniper Networks proporciona
objetos de ataque predefinidos, los cuales puede utilizar en las normas de IDP.
También puede configurar sus propios objetos de ataque personalizados. Para
obtener más información, consulte “Configuración de los objetos de ataque de
IDP” en la página 215.
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.
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: Si importa el dispositivo a NetScreen-Security Manager, la configuración del

dispositivo importado no incluye las bases de normas IDP, exclusión o puerta de
atrás.
Uso de las bases de normas de IDP 187

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.
NOTA: Debe crear cada objeto en la base de datos de objetos de direcciones. No hay
objetos de direcciones predeterminados.
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
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.)
188 Uso de las bases de normas de IDP

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.
NOTA: La acción del cortafuegos debe ser permit. No puede habilitar IDP para el tráfico
que el dispositivo deniega o rechaza.
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.
Habilitación de IDP en las normas de cortafuegos 189

Figura 60: Cuadro de diálogo DI Profile/Enable IDP
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.
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.
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.
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.
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.
Especificará el modo de IDP como parte de la directiva de seguridad del dispositivo.
190 Habilitación de IDP en las normas de cortafuegos

Configuración de las normas de IDP

La base de normas de IDP protege su red de ataques utilizando objetos de ataque
para identificar una actividad maliciosa y después ejecutar las acciones
correspondientes para impedir los ataques. Tenga cuidado de evitar la
configuración de un gran número de normas de IDP, ya que esto podría ocasionar
problemas de rendimiento.
Al crear una norma de IDP, debe especificar lo siguiente:
El tipo de tráfico de red en el que desea que IDP supervise los ataques,
utilizando las siguientes características:
From Zone/To Zone: Todo el tráfico fluye de una zona origen a una de
destino. Puede seleccionar cualquier zona para el origen o destino; sin
embargo, la zona debe ser válida para los dispositivos de seguridad que
seleccionó en la columna Install On de la norma. También puede utilizar las
excepciones de zona para especificar zonas to y from para cada
dispositivo.
Source IP: La dirección IP de origen desde la cual se origina el tráfico de la

red. Puede establecer ésta en “any” para supervisar el tráfico de la red que
se origina de cualquier dirección IP. También puede especificar “negate”
para especificar todos los orígenes, excepto las direcciones especificadas.
Destination IP: La dirección IP de destino hacia la cual se envía el tráfico

de la red. Puede establecer ésta en “any” para supervisar el tráfico de la red
enviado hacia cualquier dirección IP. También puede especificar “negate”
para especificar todos los destinos, excepto las direcciones especificadas.
Service: Los protocolos de capa de aplicación que admitidos por las

direcciones IP de destino.
Terminate Match: De manera predeterminada, las normas en la base de

normas son no definitivas, lo que significa que IDP examina todas las
normas en la base de normas y ejecuta todas las coincidencias. Puede
especificar que una norma sea definitiva; si IDP encuentra una coincidencia
de origen, destino y servicio especificados en una norma definitiva, no
examina ninguna norma subsiguiente en esa conexión. Observe que no es
necesario que el tráfico coincida con los ataques especificados en la norma
definitiva. Las normas definitivas aparecen cerca de la parte superior de la
base de normas, antes de otras normas que podrían coincidir con el mismo
tráfico. Tenga precaución al especificar las normas definitivas.
Consulte la Figura 70 en la página 199 y tenga en cuenta que si marca

Terminate Match, las normas que aparecen bajo Terminate Match Rule
(normas solapadas) no se evaluarán.
Si no marca Terminate Match, se producirá comparación/registro de

múltiples eventos, lo que resultará en un ataque mediante la creación de
múltiples entradas en los registros y en la realización de múltiples acciones.
Configuración de las normas de IDP 191

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
192 Configuración de las normas de IDP

Aparece la ficha de la base de normas de IDP. Consulte la Figura 62.
Figura 62: Base de normas de IDP agregada
3. Para configurar una norma de IDP, haga clic en el icono Add que se encuentra
en el lado izquierdo de la ventana Security Policy.
Aparece una norma de IDP predeterminada. Puede modificar esta norma

según sea necesario. Consulte la Figura 63.
Figura 63: Norma de IDP agregada
Tráfico 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.

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

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

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

Figura 68: Agregue objetos de servicios no estándar
Agregue este objeto de servicio a su norma, después agregue varios objetos de

ataque HTTP, que tienen un servicio predeterminado de TCP/80. IDP utiliza el
servicio especificado, HTTP-8080 en lugar del servicio predeterminado y busca
coincidencias con los ataques HTTP en el tráfico TCP en el puerto 8080.
Figura 69: Establecimiento de servicio no estándar
Puede crear sus propios objetos de servicio para utilizar en normas, como por
ejemplo objetos de servicio para protocolos que utilizan puertos no estándar. Sin
embargo, no puede comparar objetos de ataque con los protocolos que éstos no
utilizan.

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

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.

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

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

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).
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.
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
Nivel de Notificación
gravedad Descripción Acción recomendada recomendada
Critical Los ataques intentan evadir un IPS, que una máquina se quede Drop Packet Logging
colgada u obtener privilegios a nivel del sistema. Drop Connection Alert
Major Los ataques intentan que el servicio se caiga, realizar un rechazo de Drop Packet Logging
servicio, instalar o utilizar un caballo de Troya, u obtener acceso a Drop Connection Alert
nivel de usuario a un host.
Minor Los ataques intentan obtener información esencial mediante la Ninguna Logging
navegación de directorios o filtraciones de información.
Warning Los ataques intentan obtener información no esencial o analizar la Ninguna Logging
red. También puede ser tráfico de ataques obsoletos (pero
probablemente inofensivos).
Info Los ataques son tráfico normal, inofensivo que contiene fallos de Ninguno Ninguno
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.
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.

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.

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.
NOTA: Para mejorar el rendimiento de IDP, registre solamente los paquetes recibidos
después del ataque.
Si múltiples normas con la captura de paquetes habilitada coinciden con el mismo

ataque, IDP captura el número máximo de paquetes especificado. Por ejemplo,
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: Las capturas de paquetes están restringidas a 256 paquetes antes y después de un
ataque.
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.
NOTA: Si elimina la base de normas de IDP, la base de normas de exclusión también se

elimina.
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.
Configuración de las normas de exclusión 205

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

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.
206 Configuración de las normas de exclusión

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.

norma de exclusión.

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.


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:
208 Configuración de las normas de exclusión

Figura 75: Exclusión de un objeto de ataque
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.
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.

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.
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.
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”.
210 Configuración de las normas de puerta de atrás

Los servicios que ofrece el origen o destino, así como los servicios interactivos
que los hackers pueden instalar y utilizar.
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.
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.
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.
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:

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.
Configuración de las normas de puerta de atrás 211

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.

norma de puerta de atrás.

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.

representar componentes en su red. Hosts, redes, servidores, etc. Normalmente, un
servidor u otro dispositivo de su red es la IP de destino para los ataques entrantes y
algunas veces puede ser la IP de origen para ataques interactivos. Puede especificar
“any” para supervisar el tráfico de la red que se origina desde cualquier dirección IP.
También puede negar los objetos de dirección enumerados en la columna Source o
Destination para especificar todos los orígenes o destinos excepto los objetos de
dirección excluidos.

Puede crear objetos de dirección antes de crear una norma de puerta de atrás
(consulte el manual NetScreen-Security Manager Administrator's Guide) o mientras
crea o edita una norma de puerta de atrás. Para seleccionar o configurar un objeto
de dirección, haga clic con el botón secundario en la columna Source o Destination
de una norma y seleccione Select Address. En el cuadro de diálogo Select Source
Addresses puede seleccionar un objeto de dirección que ya está creado o hacer clic
en el icono Add para crear un nuevo host, red u objeto de grupo.
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 IDP cierra la conexión interactiva y envía un paquete RST al cliente y al servidor. Si IDP está funcionando
Server en el modo de programa rastreador, IDP envía un paquete RST al cliente y al servidor, pero no cierra la
conexión.
Close client IDP cierra la conexión interactiva al cliente, pero no al servidor.
Close Server IDP cierra la conexión interactiva al servidor, pero no al cliente.
Configuración de las normas de puerta de atrás 213

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.

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.
NOTA: Las capturas de paquetes están restringidas a 256 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.
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.
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: Solamente los dispositivos de seguridad con capacidades para IDP admiten IDP.
Configuración de los objetos de ataque de IDP 215

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.
216 Configuración de los objetos de ataque de IDP

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.

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.

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:

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.

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.

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.

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

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/ Servicio de nombres NetBios 1001, 1002
NBDS
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 2865, 2866, 2867, 2868,
de acceso telefónico 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 821
(SMTP)
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

Direction define qué sentido sigue la conexión del ataque:
Client to Server detecta el ataque solamente en el tráfico del cliente al

servidor.
Server to Client detecta el ataque solamente en el tráfico del servidor

al cliente.
Any detecta el ataque en cualquier dirección.
Flow define el flujo de la conexión del ataque: Control, auxiliar o ambos.
5. Configure la información de coincidencia de encabezado para el ataque de

firma. La configuración de coincidencia de encabezado le permite especificar
que IDP busque solamente una coincidencia de patrón en un paquete con
cierta información de encabezado para los siguientes protocolos:
Protocolo de Internet (IP)
Type-of-service. Especifique un operando (none, =, !, >, <) y un

valor decimal.
Total length. Especifique un operando (none, =, !, >, <) y un valor

decimal.
ID Especifique un operando (none, =, !, >, <) y un valor decimal.
Time-to-live. Especifique un operando (none, =, !, >, <) y un valor

decimal.
Protocol. Especifique un operando (none, =, !, >, <) y un valor

decimal.
Source. Especifique la dirección IP del dispositivo de ataque.
Destination. Especifique la dirección IP del objetivo de ataque.
Reserved Bit. Especifica que IDP busque una coincidencia de patrón

independientemente de que esté o no esté establecido un indicador de
IP (none), solamente si el indicador está establecido (set) o solamente
si el indicador no está establecido (unset).
More Fragments. Especifica que IDP busque una coincidencia de

patrón independientemente de que esté o no esté establecido un
indicador de IP (none), solamente si el indicador está establecido (set)
o solamente si el indicador no está establecido (unset).
Don’t Fragment. Especifica que IDP busque una coincidencia de

patrón independientemente de que esté o no esté establecido un
indicador de IP (none), solamente si el indicador está establecido (set)
o solamente si el indicador no está establecido (unset).

Protocolo de control de la transmisión (TCP)
Source Port. El número de puerto del dispositivo de ataque.
Destination Port. El número de puerto del objetivo de ataque.
Sequence Number. El número de secuencia del paquete. Este número

identifica la ubicación de los datos en relación con la secuencia de
datos completa.
ACK Number. El número ACK del paquete. Este número identifica el

siguiente número de secuencia, el indicador ACK debe estar
establecido para activar este campo.
Header Length. El número de bytes en el encabezado de TCP.
Window Size. El número de bytes en el tamaño de la ventana de TCP.
Urgent Pointer. Indica que los datos en el paquete son urgentes; el

indicador URG debe estar establecido para activar este campo.
Data Length. El número de bytes en la carga de datos. Para los

paquetes SYN, ACK y FIN, este campo debe estar vacío.
También puede especificar las siguientes opciones de indicador TCP como

none, set o unset:
URG. Cuando está establecido, el indicador urgente indica que los

datos del paquete son urgentes.
ACK. Cuando está establecido, el indicador de acuse de recibo,

acusa recibo de un paquete.
PSH. Cuando está establecido el indicador de envío indica que el

receptor debe enviar todos los datos en la secuencia actual a la
aplicación de destino (identificada por el número de puerto) sin
esperar los paquetes restantes de la secuencia.
RST. Cuando está establecido, el indicador de restablecimiento,

restablece la conexión TCP, descartando todos los paquetes de una
secuencia existente.
FIN. Cuando está establecido, el indicador final indica que la

transferencia del paquete está completa y la conexión se puede
cerrar.
Protocolo de datagramas de usuario (UDP)
Source Port. El número de puerto del dispositivo de ataque.

Especifique un operando (none, =, !, >, <) y un valor decimal.
Destination Port. El número de puerto del objetivo de ataque.

Especifique un operando (none, =, !, >, <) y un valor decimal.

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

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

Si selecciona Peer, IDP detecta ataques entre las direcciones IP de
especificado.

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.

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

Si selecciona Peer, IDP detecta ataques entre las direcciones IP de
especificado.


3. Realice los siguientes pasos para configurar los miembros de ataque

compuesto:
Scope especifica si la coincidencia debe ocurrir en una única sesión o se

puede realizar a través de múltiples transacciones dentro de una sesión:
Seleccione Session para permitir múltiples coincidencias para el objeto

dentro de la misma sesión.
Seleccione Transaction para comparar el objeto a través de múltiples

transacciones que ocurren dentro de la misma sesión.
Seleccione Reset si el ataque compuesto debe coincidir más de una vez

dentro de una única sesión o transacción. Si selecciona Reset, se pueden
realizar múltiples coincidencias dentro de una única sesión o transacción.
Seleccione Ordered Match para crear un objeto de ataque compuesto que

debe coincidir con cada firma de miembro o anomalía de protocolo en el
orden que especifique. Si no especifica una coincidencia ordenada, el
objeto de ataque compuesto aún debe coincidir con todos los miembros,
pero los ataques o anomalías de protocolo pueden aparecer en orden
aleatorio.
Ahora puede agregar objetos de ataque de anomalía de protocolo o firma al ataque

compuesto, según se describe en las siguientes secciones.
Adición de una firma al objeto de ataque compuesto

1. Para agregar un patrón de ataque al objeto de ataque compuesto, haga clic en el
icono Add y seleccione Signature. Aparece el cuadro de diálogo New Member.
2. Haga doble clic en el miembro de firma creado del objeto de ataque

compuesto. Configure los ajustes del patrón de ataque:
DFA Pattern. Especifique el patrón con el que IDP debe buscar una
coincidencia. Debe construir el patrón de ataque de la misma manera que
lo haría al crear un nuevo objeto de ataque de firma.
Para excluir el patrón específico de la coincidencia, seleccione la casilla de

verificación Negate.
Context. Especifique el contexto en el que IDP debe buscar el patrón. El

contexto muestra solamente contextos que son apropiados al servicio
especificado. Si seleccionó un enlace de servicio de any, está restringido al
paquete de contextos de servicio y primer paquete.
Direction. Especifique si IDP debe buscar una coincidencia con el patrón

en el tráfico que fluye en cualquier sentido, del cliente al servidor o del
servidor al cliente.
Examine el tráfico antes de determinar la dirección. Juniper Networks

recomienda el sentido del cliente al servidor para obtener un mejor
rendimiento. El rendimiento del dispositivo se afectado si selecciona
servidor a cliente y el riesgo de objetos de ataque es menor con la opción
cliente a servidor.

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

Grupos dinámicos predefinidos
Un grupo estático personalizado puede incluir los mismos miembros que un grupo
estático predefinido, más los siguientes miembros:
Objetos de ataque personalizados
Grupos dinámicos personalizados
Otros grupos estáticos personalizados
Los grupos estáticos se utilizan para lo siguiente:
Definir un conjunto específico de ataques a los que sabe que su red es

vulnerable
Agrupar los objetos de ataque personalizados
Definir un conjunto específico de objetos de ataque de información que utiliza

para mantenerse enterado de lo que sucede en su red
Los grupos estáticos requieren más mantenimiento que los grupos dinámicos
debido a que debe agregar o eliminar manualmente los objetos de ataque en el
grupo estático para poder cambiar los miembros. Sin embargo, puede incluir un
grupo dinámico dentro de un grupo estático para actualizar automáticamente
algunos objetos de ataque. Por ejemplo, el sistema operativo del grupo de objetos
de ataque predefinido es un grupo estático que contiene cuatro grupos estáticos
predefinidos: BSD, Linux, Solaris y Windows. El grupo BSD contiene el grupo
dinámico predefinido BSD-Services-Critical en el que puede agregar objetos de
ataque durante una actualización de la base de datos de ataques.
Para crear un grupo estático personalizado:

2. Haga clic en la ficha Custom Attack Groups.
3. Haga clic en el icono Add y seleccione Add Static Group. Aparece el cuadro de
diálogo New Static Group.
4. Introduzca un nombre y una descripción del grupo estático. Seleccione un color

para el icono del grupo.
5. Para agregar un ataque o grupo al grupo estático, seleccione el ataque o grupo

de la lista Attacks/Group y haga clic en Add.
6. Haga clic en OK.

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:

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

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

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

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.
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.
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.
Configuración del dispositivo como un dispositivo IDP independiente 235

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

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
236 Configuración del dispositivo como un dispositivo IDP independiente

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.
Configuración del dispositivo como un dispositivo IDP independiente 237

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ó.
238 Administración de IDP

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.
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.
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.
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.
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.)
Administración de IDP 239

Puede actualizar el motor IDP en un dispositivo administrado desde una

actualización de la base de datos de ataques en el servidor GUI. Debido a que
las actualizaciones de la base de datos de ataques están disponibles más a
menudo que las publicaciones de firmware, una actualización de la base de
datos de ataques podría incluir una versión más reciente del motor IDP que la
que está disponible en la publicación de firmware más reciente. Por ejemplo,
una actualización de la base de datos de ataque podría contener objetos de
ataque IDP actualizados que solamente se pueden utilizar con una versión
actualizada del motor IDP.
Realice los siguientes pasos para ver la versión del motor IDP que se ejecuta
actualmente en el dispositivo.
1. Seleccione Tools > View/Update NSM Attack Database. Aparece el asistente

del administrador de actualizaciones de ataques.
El resumen de actualización de ataques que se muestra en la Figura 86, incluye

información de la versión actual descargada en el servidor GUI y la última
versión disponible de Juniper Networks.
Figura 86: Resumen de actualización de ataques
3. Haga clic en Finish para continuar descargando la actualización de la base de

datos de ataques más reciente o haga clic en Cancel para salir del
administrador de actualización de ataques.

Para actualizar el motor IDP en el dispositivo:
1. Seleccione Devices > IDP Detector Engine > IDP Detector Engine. Aparece
el cuadro de diálogo Change Device Sigpack
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.
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.
NOTA: La actualización del motor IDP en un dispositivo no requiere que reinicie el

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

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.
Administración de IDP 241

Las entradas de registro de alarma IDP aparecerán en el visualizador de registros

con las siguientes columnas de información.
Source and Destination Address
Action
Protocol
Category (Anomaly, Custom, or Signature)
Subcategory
Severity
Device

Capítulo 7
Atributos de los paquetes sospechosos
Según lo mostrado en los demás capítulos de este volumen, un hacker puede

manipular los paquetes para que realicen tareas de reconocimiento o ataques de
denegación de servicio (“Denial of Service” o “DoS”). A veces resulta difícil
determinar la intención de un paquete manipulado, pero el mismo hecho de que
esté manipulado induce a sospechar que se está incluyendo con algún fin insidioso.
Todas las opciones SCREEN presentadas en este capítulo bloquean los paquetes
sospechosos que pueden contener amenazas ocultas:
“Fragmentos ICMP” en esta página
“Paquetes ICMP grandes” en la página 244
“Opciones IP incorrectas” en la página 245
“Protocolos desconocidos” en la página 246
“Fragmentos de paquetes IP” en la página 247
“Fragmentos SYN” en la página 248
Fragmentos ICMP
El protocolo de mensajes de control de Internet (“Internet Control Message
Protocol” o “ICMP”) ofrece posibilidades de comunicación de errores y de
comprobación de redes. Dado que los paquetes ICMP contienen mensajes muy
cortos, no existe ningún motivo legítimo para que los paquetes ICMP resulten
fragmentados. Cuando un paquete ICMP es tan grande que necesita fragmentarse,
hay algún problema. Si habilita la opción SCREEN “ICMP Fragment Protection”, el
dispositivo de seguridad bloquea cualquier paquete ICMP que tenga el indicador de
más fragmentos (“More Fragments”) activado o que contenga algún valor de
desplazamiento en el campo de desplazamiento.
Fragmentos ICMP 243

Figura 87: Bloquear fragmentos de ICMP

Si el tipo de protocolo y el indicador de más o hay un valor distinto de cero en
es 1 para ICMP... fragmentos está activado... el campo desplazamiento del fragmento...
Encabezado IP Longitud del Longitud total del paquete (en bytes)

Versión Tipo de servicio
encabezado
Identificación 0 D M Desplazamiento del
fragmento
Tiempo de vida (TTL) Protocolo (ICMP = 1) Suma de comprobación del encabezado
Opciones
Encabezado ICMP Tipo Código Suma de comprobación

(Carga del
paquete IP) Identificador Número de secuencia
Datos
…el dispositivo de seguridad bloquea el paquete.
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.
244 Paquetes ICMP grandes

Capítulo 7: Atributos de los paquetes sospechosos
Figura 88: Bloquear paquetes ICMP grandes

Cuando el tipo de protocolo es 1 para ICMP… y este valor es >1024…
Encabezado IP Longitud del Longitud total del paquete (en bytes)

Versión Tipo de servicio
encabezado
Tiempo de vida (TTL) Protocolo (ICMP = 1) Suma de comprobación del encabezado
Opciones
Encabezado Tipo Código Suma de comprobación

ICMP
(Carga del Identificador Número de secuencia
paquete IP)
Datos
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.
Opciones IP incorrectas 245

Figura 89: Opciones IP formateadas incorrectamente
Encabezado IP Longitud del Tipo de servicio Longitud total del paquete (en bytes)
Versión
encabezado
Opciones
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.
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.
246 Protocolos desconocidos

Figura 90: Protocolos desconocidos

Si el número de ID del protocolo es 137 o superior,
el dispositivo de seguridad bloquea el paquete.
Encabezado IP Longitud del

Versión Tipo de servicio Longitud total del paquete (en bytes)
encabezado
Opciones
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.
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
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.
Fragmentos de paquetes IP 247

Figura 91: Fragmentos de paquetes IP

Si el indicador de más o hay un valor distinto de cero en
fragmentos está activado... el campo desplazamiento del fragmento...
Longitud del
Encabezado IP Versión Tipo de servicio Longitud total del paquete (en bytes)
encabezado
Desplazamiento
Identificación 0 D M del fragmento
Opciones
Carga de datos
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.
248 Fragmentos SYN

Para descartar los paquetes IP que contengan fragmentos SYN, utilice uno de los
siguientes métodos, donde la zona de seguridad especificada es la zona en la que se
originan los paquetes:
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione SYN
Fragment Protection, luego haga clic en Apply.
CLI
set zone zona screen syn-frag
Figura 92: Fragmentos SYN

Si el indicador de más o hay un valor distinto de cero en
fragmentos está activado... el campo desplazamiento del fragmento...
Encabezado IP Versión Longitud del Tipo de servicio Longitud total del paquete (en bytes)
encabezado
Identificación 0 D M Desplazamientodel
fragmento
Encabezado ICMP Número de puerto de origen de 16 bits Número de puerto de destino de 16 bits

encabezado R C S S Y I Tamaño de ventana de 16 bits
(6 bits)
de 4 bits G K H T N N
Datos (si los hay)
…y el indicador SYN está activado… ...el dispositivo descarta el paquete.
Fragmentos SYN 249

250 Fragmentos SYN

Apéndice A
Contextos para las firmas definidas por
el usuario
El contexto define la ubicación dentro del paquete donde el módulo Deep

Inspection (DI) busca una firma que coincida con el patrón del objeto de ataque.
Cuando define un objeto de ataque de firma activa, puede especificar cualquiera de
los contextos en las siguientes listas. Después de definir un objeto de ataque, deberá
colocarlo en un grupo de objetos de ataque definido por el usuario para poderlo
utilizar en directivas.
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.
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
Protocolo Contexto Descripción (Establece el contexto como…)

AIM aim-chat-room-desc La descripción de una sala de chat en una sesión de America Online Instant
Messenger (AIM) o ICQ (I Seek You).
aim-chat-room-name El nombre de una sala de chat en una sesión AIM o ICQ.
aim-get-file El nombre de un archivo que un usuario transfiere de un interlocutor.
aim-nick-name El apodo (nickname) de un usuario de AIM o ICQ.
aim-put-file El nombre de un archivo que un usuario transfiere a un interlocutor.
aim-screen-name El nombre de la pantalla de un usuario de AIM o ICQ.
DNS dns-cname El CNAME (nombre canónico) en una respuesta o petición del Sistema de nombres
del dominio (DNS), según se define en la norma RFC 1035, Nombres de dominio:
Implementación y especificación).
FTP ftp-command Uno de los comandos de FTP especificado en RFC 959, Protocolo de transferencia de
archivos (FTP).
ftp-password Una contraseña de inicio de sesión de FTP.
ftp-pathname Un nombre de archivo o directorio en cualquier comando de FTP.
A-I

ftp-username El nombre que un usuario introduce cuando inicia una sesión en un servidor de FTP.
Gnutella gnutella-http- El nombre de un archivo que un cliente de Gnutella intenta recuperar.
get-filename
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- Una variable de interfaz de puerta de enlace común decodificada (CGI) en URL de
variable-parsed 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 msn-display-name El nombre de visualización de un usuario en una sesión de mensajería instantánea de
Messenger 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
A-II
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
pop3-mime- El nombre del archivo de contenido de un documento adjunto de extensiones de
content-filename 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- El nombre del archivo de contenido de un documento adjunto de extensiones de
content-filename 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! ymsg-alias El nombre de identificación alterno asociado con el nombre de usuario principal de
Messenger un usuario de mensajes instantáneos de Yahoo!
ymsg-chatroom- El texto en mensajes intercambiados en una sala de chat de mensajería instantánea
message de Yahoo!
ymsg-chatroom- El nombre de un sala de chat de mensajería instantánea de Yahoo!
name
ymsg-nickname El apodo de un usuario de mensajería instantánea de Yahoo!
ymsg-p2p-get- La ubicación de un archivo en la máquina de un interlocutor de mensajería
filename-url instantánea de Yahoo! desde la cual se puede descargar.
ymsg-p2p-put- La ubicación de un archivo en la máquina de un interlocutor de mensajería
filename-url instantánea de Yahoo! al cual se puede descargar.
A-III
A-IV
Índice
A asignación de grandes cantidades de paquetes
acciones de ataque ............................................ 143 a 151 simultáneos de la tabla de sesiones .........................19
close ........................................................................143 ataques
close client .............................................................144 asignación de grandes cantidades de paquetes
close server ............................................................143 simultáneos de la tabla de sesiones....................19
drop ........................................................................144 direcciones MAC desconocidas .............................43
drop packet ............................................................144 DOS ...................................................................29 a 56
ignore......................................................................144 etapas .........................................................................2
none ........................................................................144 Fragmentos de paquetes IP .................................247
Actualización del motor IDP .......................................239 Fragmentos SYN ....................................................248
Actualizaciones de la base de datos de ataques ICMP
descargar ................................................................239 fragmentos ........................................................243
introducción ...........................................................238 inundaciones ......................................................49
Administración en base a funciones inundación de la tabla de sesiones .......................30
Bases de normas de IDP ......................................188 Inundaciones SYN ...........................................37 a 43
Configuración de un administrador sólo de Inundaciones UDP ...................................................51
IDP ........................................................................237 objetivos comunes ....................................................1
agentes zombie ........................................................29, 31 opciones de detección y defensa ......................2 a 5
AIM ................................................................................135 paquetes ICMP grandes ........................................244
ALG ..................................................................................59 Ping of Death ...........................................................53
análisis antivirus .................................................... 62 a 88 protocolos desconocidos ......................................246
descompresión ........................................................92 Teardrop ...................................................................54
extensiones de archivo ...........................................93 terrestres ..................................................................52
FTP ............................................................................73 WinNuke ...................................................................55
goteo HTTP ..............................................................87
HTTP .........................................................................74 B
HTTP “keep-alive” ...................................................86 barrida de puertos ...........................................................9
IMAP .........................................................................76 barrido de direcciones ....................................................8
MIME.........................................................................75 base de datos de objetos de ataque.................124 a 132
modo de fallo ...........................................................85 actualización automática ..............................127, 128
POP3 .........................................................................76 actualización inmediata ........................................127
recursos de AV por cliente .....................................84 actualización manual ............................................130
SMTP .........................................................................78 cambiar la URL predeterminada .........................130
suscripción ...............................................................81 notificación automática y actualización
análisis FIN .....................................................................16 manual .................................................................129
anomalías en el protocolo ..........................................138 Base de normas de exclusión
ALG .........................................................................136 Adición a una directiva de seguridad ..................206
Aplicaciones de mensajería inmediata ...............135 introducción ...........................................................205
Aplicaciones P2P ...................................................135 Base de normas de puerta de atrás
configuración de parámetros ...............................167 Adición a una directiva de seguridad ..................211
protocolos admitidos .................................. 133 a 137 introducción ...........................................................210
protocolos básicos de red.....................................133 Bases de normas de IDP
applets Java, bloquear .................................................174 Adición a una directiva de seguridad ..................192
archivos exe, bloquear ................................................174 Administración en base a funciones ...................188
archivos zip, bloquear .................................................174 introducción ...........................................................191
Índice IX-I
tipos ........................................................................ 187 plantillas .................................................................189

Bloque de mensajes del servidor Discard ..........................................................................134
Consulte SMB DNS ...............................................................................133
Bobinadora LPR ........................................................... 134 DoS
asignación de grandes cantidades de paquetes
C simultáneos de la tabla de sesiones ...................19
Chargen ........................................................................ 133 ataque específico del sistema operativo....... 53 a 56
claves de licencia cortafuegos ...................................................... 30 a 36
actualización del patrón de ataques ................... 122 inundación de la tabla de sesiones .......................30
modo avanzado ..................................................... 122 red ..................................................................... 37 a 52
comprobación de SYN .................................... 16, 16 a 19 DoS, ataques .......................................................... 29 a 56
agujero de reconocimiento .................................... 18 drop-no-rpf-route ...........................................................20
asignación de grandes cantidades de paquetes
simultáneos de la tabla de sesiones ................... 19 E
enrutamiento asimétrico ........................................ 18 Echo ..............................................................................134
interrupción de sesión ............................................ 18 Entradas de registros
controles ActiveX, bloqueo ......................................... 173 Habilitación en las normas IDP ...........................241
Cookies SYN ................................................................... 47 establecimientos de conexión en tres pasos ..............37
estado................................................................................3
D firmas .....................................................................137
DDoS ............................................................................... 29 inspección ..................................................................3
Deep Inspection (DI) ......................................... 140 a 165 evasión .................................................................... 15 a 27
acciones de ataque ..................................... 143 a 151 expiración dinámica .............................................. 33 a 35
anomalías en el protocolo .................................... 138 exploits
base de datos de objetos de ataque .......... 124 a 132 véase ataques
cambio de gravedad ............................................. 140 expresiones regulares........................................ 161 a 162
claves de licencia .................................................. 122 extensiones de archivo, análisis de AV .......................93
contexto ...................................................................... I
desactivar objetos de ataque ............................... 142 F
expresiones regulares ................................. 161 a 162 filtrado de contenido ........................................... 57 a 118
firmas completas .................................................. 137 filtrado de paquetes dinámico .......................................3
firmas de secuencias ............................................ 138 filtrado de Web
firmas personalizadas................................. 161 a 165 aplicar perfiles a directivas ..................................108
grupos de objetos de ataque ................................ 139 caché.......................................................................103
introducción........................................................... 120 categorías de URL .................................................104
negación de objetos de ataque ............................ 168 enrutamiento .........................................................116
objetos de ataque .................................................. 122 estado del servidor ................................................116
objetos de ataque personalizados ....................... 160 integrado ................................................................101
paquetes de firmas ............................................... 124 mensaje de URL bloqueada .................................115
registro de grupos de objetos de ataque ............ 154 nombre del servidor SurfControl ........................113
servicios personalizados ............................ 156 a 160 nombre del servidor Websense ..........................113
volver a habilitar objetos de ataque .................... 143 perfiles ....................................................................106
Denegación de servicio puerto del servidor SurfControl ...........................113
véase DoS puerto del servidor Websense .............................113
descompresión, análisis antivirus ............................... 92 redirigir ...................................................................110
Detección y prevención de intrusión, definida ........ 175 servidores CPA de SurfControl ............................101
DHCP ............................................................................ 134 servidores de SurfControl.....................................102
directivas servidores por vsys ...............................................112
contexto ................................................................. 124 SurfControl SCFP ...................................................113
sección central ................................................ 18, 123 tiempo de espera de comunicaciones ................114
Directivas de seguridad .............................................. 185 tipo de mensaje de URL bloqueada ....................115
Base de normas..................................................... 186 FIN sin indicador ACK ...................................................14
Ejecución de bases de normas ............................ 189 Finger ............................................................................134
normas ................................................................... 186 firmas
IX-II Índice
Índice
estado .....................................................................137 umbral ......................................................................38

firmas de secuencias ...................................................138 umbral de alarma ....................................................41
Fragmentos SYN ..........................................................248 umbral de ataque ....................................................40
fuerza bruta umbral de destino ...................................................41
acciones de ataque................................................151 umbral de origen .....................................................41
IP
G fragmentos de paquetes .......................................247
Gopher ..........................................................................134 IRC .................................................................................135
grupos de objetos de ataque ......................................139
cambio de gravedad .............................................140 L
inicio sesión ...........................................................154 Land Attack, ataques terrestres ....................................52
niveles de gravedad ..............................................139 LDAP ..............................................................................134
que se aplican en directivas .................................132 límites de sesiones ................................................30 a 33
URL de ayuda ........................................................136 según su destino ................................................31, 32
grupos VSD ...................................................................185 según su origen..................................................30, 32
Llamada de procedimiento remoto de Microsoft
H Consulte MS-RPC
HTTP
“keep-alive”..............................................................86 M
bloqueo de componentes ........................... 173 a 174 Mensajería inmediata ..................................................135
goteo .........................................................................87 AIM ..........................................................................135
tiempo de espera de la sesión ...............................34 IRC...........................................................................135
Mensajero Yahoo! ..................................................135
I MSN Messenger .....................................................135
ICMP ..............................................................................134 Yahoo! Messenger .................................................135
fragmentos .............................................................243 Mensajería inmediata de America Online
paquetes grandes ..................................................244 Consulte AIM
IDENT............................................................................134 Mensajero Yahoo! ........................................................135
IDP Microsoft Network Instant Messenger
configuración básica .............................................178 Consulte MSN Instant Messenger
Configuración de un dispositivo para IDP MIME, análisis antivirus ................................................75
independiente .....................................................235 modo de fallo .................................................................85
Configuración del modo en línea o tap en Modo en línea ..............................................................190
línea ......................................................................190 Modo tap en línea ........................................................190
Habilitación en una norma de cortafuegos ........189 Modo transparente
indicadores SYN y FIN activados .................................13 descartar las direcciones MAC desconocidas.......43
inicio sesión Modos de IDP ...............................................................190
grupos de objetos de ataque ................................154 Motor IDP
inspecciones .....................................................................3 actualizar ................................................................239
inundación de la tabla de sesiones..............................30 MS RPC .........................................................................136
inundaciones MSN Messenger ...........................................................135
ICMP .........................................................................49
SYN ............................................................. 37 a 43, 47 N
tabla de sesiones .....................................................30 negación, Deep Inspection (DI)..................................168
UDP ...........................................................................51 NetBIOS ........................................................................136
inundaciones de SYN-ACK-ACK a través de un servidor NFS ................................................................................134
proxy ............................................................................35 NNTP .............................................................................134
Inundaciones ICMP .......................................................49 normas de exclusión .........................................205 a 210
Inundaciones SYN ................................................. 37 a 43 configuración .........................................................207
ataques .....................................................................37 Configuración de las columnas de
Cookies SYN.............................................................47 coincidencia .........................................................207
descartar las direcciones MAC desconocidas ......43 Configuración de los ataques ...............................208
tamaño de la cola ....................................................42 Configuración de objetivos ...................................209
tiempo de espera ....................................................42 Configuración de zonas ........................................207
Índice IX-III
Configuración del origen y destino ..................... 208 personalizados .......................................................219

Configuración desde el visualizador de volver a habilitar ...................................................143
registros ............................................................... 209 Objetos de ataque IDP ................................................188
Normas de IDP ............................................................ 191 objetos de ataques de fuerza bruta ...........................152
configuración ......................................................... 193 opción de marca de tiempo de IP .........................11, 12
Configuración de acciones ................................... 199 opción de seguridad IP ...........................................11, 12
Configuración de la gravedad del ataque ........... 205 opción IP de grabación de ruta ..............................11, 12
Configuración de la notificación ......................... 204 opción IP de ID de secuencia .................................11, 12
Configuración de las acciones de IP ................... 202 opción IP de ruta de origen abierta ............... 11, 26 a 27
Configuración de las columnas de opción IP de ruta de origen estricta .............. 11, 26 a 27
coincidencia ........................................................ 193 Opciones IP ............................................................ 10 a 12
Configuración de los ataques .............................. 200 atributos ........................................................... 10 a 11
Configuración de los servicios ............................. 195 formateadas incorrectamente .............................245
Configuración de normas definitivas .................. 198 grabación de ruta ..............................................11, 12
Configuración de objetivos .................................. 205 ID de secuencia .................................................11, 12
Configuración de objetos de ataque de IDP ...... 188 marca de hora ...................................................11, 12
configuración de objetos de dirección................ 188 ruta de origen ..........................................................26
Configuración de objetos de servicio .................. 188 ruta de origen abierta ............................... 11, 26 a 27
Configuración del origen y destino ..................... 194 ruta de origen estricta .............................. 11, 26 a 27
Introducción de comentarios .............. 205, 209, 215 seguridad ............................................................11, 12
normas de puerta de atrás ............................... 210 a 215
Configuración de acciones ................................... 213 P
Configuración de la gravedad .............................. 215 P2P ................................................................................135
Configuración de las columnas de BitTorrent ...............................................................135
coincidencia ........................................................ 212 DC ...........................................................................135
Configuración de los servicios ............................. 213 eDonkey .................................................................136
Configuración de objetivos .................................. 215 FastTrack ................................................................136
Configuración de zonas ........................................ 212 Gnutella ..................................................................136
Configuración del funcionamiento ..................... 213 KaZaa ......................................................................136
Configuración del origen y destino ..................... 212 MLdonkey ..............................................................136
NSRP Skype ......................................................................136
grupos VSD ............................................................ 185 SMB .........................................................................136
NTP ............................................................................... 134 WinMX....................................................................136
paquetes de firmas, DI ................................................124
O Ping of Death .................................................................53
objetos plantillas
objetos de ataque .................................................. 215 directiva de seguridad ..........................................189
Objetos de ataque, anomalías de protocolo ...... 216 Portmapper ..................................................................134
Objetos de ataque, creación personalizada ....... 219 protección contra ataques
Objetos de ataque, firma ..................................... 216 nivel de directivas .....................................................5
objetos AV nivel de zona de seguridad ......................................5
tiempo de espera .................................................... 91 protección contra URL maliciosas ....................... 58 a 61
objetos de ataque ...................................... 122, 132 a 138 protocolos desconocidos ............................................246
anomalía del protocolo......................................... 216 Puerta de enlace en la capa de aplicación
anomalías en el protocolo ............................ 138, 167 Véase ALG
desactivar ............................................................... 142 Punto a punto
firma ....................................................................... 216 Consulte P2P
firmas completas .................................................. 137
firmas de secuencias ............................................ 138 R
firmas de secuencias de TCP ............................... 165 RADIUS .........................................................................134
fuerza bruta ................................................... 151, 152 reconocimiento ........................................................ 7 a 27
IDP .......................................................................... 188 análisis FIN...............................................................16
introducción........................................................... 215 barrida de puertos .....................................................9
negación ................................................................. 168 barrido de direcciones ..............................................8
IX-IV Índice
Índice
indicadores SYN y FIN activados ..........................13 SMB

Opciones IP ..............................................................10 NetBIOS ..................................................................136
paquete TCP sin indicadores .................................15 SNMPTRAP ...................................................................135
reensamblaje de fragmentos ................................ 58 a 61 sondeo
rexec ..............................................................................134 puertos abiertos .........................................................9
RFC red ...............................................................................8
1038, Opción de seguridad IP revisada................ 11 sistemas operativos ...........................................12, 15
791, Internet Protocol......................................... 11 SSH ................................................................................135
791, protocolo de Internet................................... 10 SSL .................................................................................135
793, Protocolo de control de transmisión............. 14 SurfControl ...........................................................101, 110
rlogin .............................................................................134 SYN, cookies...................................................................47
rsh..................................................................................134 syslog.............................................................................135
RTSP ..............................................................................134
T
S TCP
SCREEN firmas de secuencias .............................................165
Ataques terrestres ...................................................52 paquete sin indicadores..........................................15
Ataques WinNuke ...................................................55 tiempos de espera de sesiones ..............................34
barrida de puertos .....................................................9 Teardrop, ataques ..........................................................54
barrido de direcciones ..............................................8 Telnet .............................................................................135
descartar las direcciones MAC desconocidas ......43 TFTP ..............................................................................135
FIN sin ACK ..............................................................16 tiempo de espera de la sesión
FIN sin indicador ACK, descartar ..........................14 HTTP .........................................................................34
fragmentos de paquetes IP, bloquear .................247 tiempos de espera de sesiones
fragmentos SYN, detectar ....................................248 TCP ............................................................................34
ICMP UDP ...........................................................................34
fragmentos, bloquear ......................................243
indicadores SYN y FIN activados ..........................13 U
inundaciones de SYN-ACK-ACK a través de un UDP
servidor proxy .......................................................35 tiempos de espera de sesiones ..............................34
Inundaciones ICMP .................................................49 umbral
Inundaciones SYN ........................................... 37 a 43 umbral inferior ........................................................33
Inundaciones UDP ..................................................51 umbral superior .......................................................33
opción IP de ruta de origen abierta, detectar ......27 umbral inferior ...............................................................33
opción IP de ruta de origen estricta, detectar .....27 umbral superior .............................................................33
opción IP de ruta de origen, rechazar ..................27
Opciones IP ..............................................................10 V
opciones IP incorrectas, descartar ......................245 Visualizador de registros
paquete TCP sin indicadores, detectar .................15 Creación de una norma de exclusión .................209
paquetes ICMP grandes, bloquear ......................244 VNC ...............................................................................135
Ping of Death ...........................................................53
protocolos desconocidos, descartar ....................246 W
Simulación de IP ............................................. 20 a 25 web, filtrado........................................................110 a 118
Teardrop ...................................................................54 Whois ............................................................................135
zonas VLAN y MGT ...................................................3 WinNuke, ataques ..........................................................55
servicios
personalizados .......................................................156 Y
Simulación de IP Yahoo! Messenger ........................................................135
Capa 2.................................................................21, 24
Capa 3.................................................................20, 22
drop-no-rpf-route .....................................................20
Z
zombie, agentes .......................................................29, 31
simulación de IP .................................................... 20 a 25
Sistema con capacidad para IDP ...............................176
sistemas operativos, sondeos de host para ........ 12 a 15
Índice IX-V
IX-VI Índice
Volumen 5:

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Copyright Notice
without notice.
FCC Statement
Disclaimer
ii
Contenido
Capítulo 1 Seguridad del protocolo de Internet 1

Introducción a las redes privadas virtuales....................................................... 2
Conceptos de IPSec.......................................................................................... 3
Modos ....................................................................................................... 4
Modo de transporte............................................................................. 4
Modo de túnel ..................................................................................... 4
Protocolos ................................................................................................. 6
Encabezado de autenticación .............................................................. 6
Carga de seguridad encapsulada ......................................................... 6
Administración de claves........................................................................... 7
Clave manual ...................................................................................... 7
AutoKey IKE........................................................................................ 7
Asociaciones de seguridad......................................................................... 8
Negociación de túnel........................................................................................ 9
Fase 1........................................................................................................ 9
Modo principal y modo dinámico ..................................................... 10
Intercambio Diffie-Hellman............................................................... 11
Fase 2...................................................................................................... 11
Confidencialidad directa perfecta ...................................................... 12
Protección contra reprocesamiento de paquetes............................... 12
Paquetes IKE e IPSec ..................................................................................... 12
Paquetes IKE ........................................................................................... 13
Paquetes IPSec ........................................................................................ 16
Capítulo 2 Criptografía de claves públicas 19

Introducción a la criptografía de claves públicas ............................................ 20
Firma de un certificado ........................................................................... 20
Verificación de una firma digital .............................................................. 20
Infraestructura de claves públicas .................................................................. 22
Certificados y CRL.......................................................................................... 24
Petición manual de un certificado ........................................................... 26
Carga de certificados y listas de revocación de certificados ..................... 28
Configuración de ajustes de CRL.............................................................. 29
Obtención automática de un certificado local .......................................... 31
Contenido iii
Renovación automática de certificado ..................................................... 34

Generación de pares de claves.................................................................35
Protocolo de estado de certificado en línea (OCSP) ........................................ 35
Especificación de un método de comprobación de revocación de
certificados ....................................................................................... 36
Visualización de los atributos de comprobación de estado ...................... 37
Especificación de una URL del servidor de respuesta del protocolo de
estado de certificado en línea............................................................ 37
Eliminación de atributos de comprobación de estado.............................. 37
Certificados autofirmados .............................................................................. 38
Validación de certificados ........................................................................ 39
Creación manual de certificados autofirmados ........................................ 40
Establecimiento de un certificado autofirmado y definido por el
administrador ................................................................................... 41
Autogeneración de certificados................................................................ 45
Eliminar certificados autofirmados .......................................................... 46
Capítulo 3 Directrices para las redes privadas virtuales 49

Opciones criptográficas.................................................................................. 50
Opciones criptográficas punto a punto ....................................................50
Opciones VPN de acceso telefónico ......................................................... 57
Túneles basados en directivas y en rutas ....................................................... 64
Flujo de paquetes: VPN punto a punto ........................................................... 66
Directrices para la configuración de túneles ................................................... 72
Consideraciones sobre seguridad en redes privadas virtuales basadas en
rutas ........................................................................................................ 74
Ruta Null.................................................................................................. 74
Línea de acceso telefónico o arrendada ................................................... 76
Conmutación por error de la VPN hacia la línea arrendada o la ruta
Null ................................................................................................... 77
Interfaz Tunnel ficticia ............................................................................. 79
Enrutador virtual para interfaces Tunnel.................................................. 80
Reenrutamiento a otro túnel.................................................................... 80
Capítulo 4 Redes privadas virtuales de punto a punto 81

Configuraciones VPN punto a punto............................................................... 82
VPN punto a punto basada en rutas, AutoKey IKE ................................... 88
VPN punto a punto basada en directivas, AutoKeyIKE............................. 97
VPN punto a punto basada en rutas, interlocutor dinámico ...................103
VPN punto a punto basada en directivas, interlocutor dinámico............112
VPN punto a punto basada en rutas, clave manual ................................120
VPN punto a punto basada en directivas, clave manual.........................127
Puertas de enlace IKE dinámicas con FQDN ................................................132
Alias ......................................................................................................133
Ajuste del interlocutor AutoKey IKE con FQDN......................................134
Sitios VPN con direcciones superpuestas......................................................142
VPN en modo transparente..........................................................................154
Capítulo 5 Redes privadas virtuales de acceso telefónico 163

Acceso telefónico .........................................................................................164
VPN de acceso telefónico basada en directivas, AutoKey IKE ................165
VPN de acceso telefónico basada en rutas, interlocutor dinámico .........170
iv Contenido
Contenido
VPN de acceso telefónico basada en directivas, interlocutor dinámico ..177

Directivas bidireccionales para usuarios de VPN de acceso telefónico ...184
Identificación IKE de grupo ..........................................................................188
Identificación IKE de grupo con certificados ..........................................189
Tipos de identificación IKE ASN1-DN Wildcard y Container ..................191
Creación de una identificación IKE de grupo (certificados) ....................194
Configuración de una ID IKE de grupo con claves previamente
compartidas ....................................................................................198
Identificación IKE compartida ......................................................................204
Capítulo 6 Protocolo de encapsulamiento de la capa 2 211

Introducción al L2TP ....................................................................................211
Encapsulado y desencapsulado de paquetes ................................................214
Encapsulado ..........................................................................................215
Desencapsulado.....................................................................................216
Ajuste de los parámetros L2TP .....................................................................217
L2TP y L2TP sobre IPSec..............................................................................219
Configuración de L2TP ..........................................................................219
Configuración de L2TP sobre IPSec .......................................................224
L2TP sobre IPSec bidireccional ..............................................................232
Capítulo 7 Funciones avanzadas de redes privadas virtuales 239

NAT-Traversal ..............................................................................................240
Sondeos de NAT ....................................................................................241
Atravesar un dispositivo NAT.................................................................243
Suma de comprobación de UDP ............................................................245
Paquetes de mantenimiento de conexión..............................................246
Simetría iniciador/respondedor .............................................................246
Habilitación de NAT-Traversal ...............................................................248
Uso de identificaciones de IKE con NAT-Traversal .................................249
Supervisión de VPN......................................................................................250
Opciones de reencriptación y optimización ...........................................251
Interfaz de origen y dirección de destino...............................................252
Consideraciones sobre directivas...........................................................253
Configuración de la función de supervisión de VPN...............................254
Objetos y capturas SNMP para la supervisión de VPN............................262
Múltiples túneles por interfaz de túnel .........................................................263
Asignación de rutas a túneles ................................................................264
Direcciones de interlocutores remotos...................................................266
Entradas de tabla manuales y automáticas ............................................267
Entradas manuales en la tabla ........................................................267
Entradas automáticas en la tabla.....................................................267
Ajuste de VPN en una interfaz de túnel para subredes
superpuestas ............................................................................269
tabla NHTB ...............................................................................288
Uso de OSPF para entradas automáticas en la tabla de rutas ..........300
Puertas de enlace VPN redundantes.............................................................301
Grupos VPN ...........................................................................................302
Mecanismos de supervisión...................................................................303
Pulsos de IKE ..................................................................................304
Detección de interlocutor muerto....................................................304
Procedimiento de recuperación IKE ................................................306
Contenido v
Comprobación de indicador TCP SYN....................................................307

Creación de puertas de enlace VPN redundantes ............................308
Creación de VPN adosadas...........................................................................314
Creación de VPN radiales .............................................................................321
Capítulo 8 Redes privadas virtuales de AutoConnect 331

Vista general ................................................................................................331
Cómo funciona ............................................................................................332
Mensajes NHRP .....................................................................................332
Iniciación del túnel AC-VPN ...................................................................333
Configuración de AC-VPN ......................................................................334
Traducción de direcciones de red....................................................335
Configuración en el concentrador ...................................................335
Configuración en cada red radial.....................................................335
Ejemplo .................................................................................................336
Índice ........................................................................................................................IX-I
vi Contenido
El Volumen 5: Redes privadas virtuales describe los conceptos de la red privada

virtual (VPN) y las funciones específicas de la VPN de ScreenOS.
Este volumen contiene los siguientes capítulos:
Capítulo 1, “Seguridad del protocolo de Internet,” que presenta los elementos

de Seguridad del protocolo de Internet (IPSec) y explica cómo se relacionan con
el encapsulamiento de VPN.
Capítulo 2, “Criptografía de claves públicas,” donde se ofrece una introducción

a la criptología de claves públicas y al uso de certificados y listas de revocación
de certificados (CLR) en el marco de la infraestructura de claves públicas (PKI).
Capítulo 3, “Directrices para las redes privadas virtuales,” que explica el

encapsulamiento de VPN.
Capítulo 4, “Redes privadas virtuales de punto a punto,” que explica cómo

configurar un túnel VPN punto a punto entre dos dispositivos de seguridad de
Juniper Networks.
Capítulo 5, “Redes privadas virtuales de acceso telefónico,” donde se explica

cómo configurar una VPN de acceso telefónico.
Capítulo 6, “Protocolo de encapsulamiento de la capa 2,” que describe el

protocolo de encapsulamiento de capa 2 (L2TP) y proporciona ejemplos de
configuraciones para L2TP y L2TP sobre IPSec.
Capítulo 7, “Funciones avanzadas de redes privadas virtuales,” que explica los

temas relacionados con las Traducción de direcciones de red de origen (NAT),
supervisión VPN y VPN que utilizan múltiples túneles.
Capítulo 8, “Redes privadas virtuales de AutoConnect,” que describe cómo

ScreenOS utiliza los mensajes del protocolo de resolución de siguiente salto
(NHRP) para habilitar los dispositivos de seguridad para configurar las VPN de
AutoConnect según sea necesario. El capítulo proporciona un ejemplo de un
escenario típico en el cual se puede utilizar AC-VPN.
vii

siguientes:
“Convenciones de la interfaz de usuario web” en la página viii
“Convenciones de interfaz de línea de comandos” en la página viii
“Convenciones de nomenclatura y conjuntos de caracteres” en la página ix


de una dirección:
Address Name: dir_1

Zone: Untrust


En ejemplos:










zona de seguridad

Internet

Interfaz de túnel
Servidor
Túnel VPN
Enrutador
Concentrador






Capítulo 1
Seguridad del protocolo de Internet
En este capítulo se presentan los elementos de la seguridad del protocolo de

internet (IPsec) y se describe cómo se relacionan con el encapsulamiento de red
privada virtual (VPN). Este capítulo incluye las siguientes secciones:
“Introducción a las redes privadas virtuales” en la página 2
“Conceptos de IPSec” en la página 3
“Modos” en la página 4
“Protocolos” en la página 6
“Administración de claves” en la página 7
“Asociaciones de seguridad” en la página 8
“Negociación de túnel” en la página 9
“Fase 1” en la página 9
“Fase 2” en la página 11
“Paquetes IKE e IPSec” en la página 12
“Paquetes IKE” en la página 13
“Paquetes IPSec” en la página 16
1
Introducción a las redes privadas virtuales

Una red privada virtual (VPN) representa un medio de comunicación segura entre
equipos remotos de una red de área extensa (WAN) pública, como Internet.
Una conexión VPN puede enlazar dos redes de área local (LAN) entre sí, o un
usuario de acceso telefónico remoto y una LAN. El tráfico que circula entre estos
dos puntos atraviesa determinados recursos compartidos, como enrutadores,
conmutadores y otros equipos de red que conforman la WAN pública. Para
garantizar la seguridad de las comunicaciones VPN a través de la WAN, los dos
participantes crean un túnel de seguridad IP (IPSec).
NOTA: El término túnel no denota ni transporte ni modo de túnel (consulte “Modos” en la

página 4). Se refiere a la conexión IPSec.
Un túnel IPSec está formado por un par de asociaciones de seguridad (SA)

unidireccionales (una a cada extremo del túnel) que especifican el índice de
parámetros de seguridad (SPI), la dirección IP de destino y el protocolo de
seguridad (encabezado de autenticación o carga de seguridad encapsulada)
empleado.
Para obtener más información sobre SPI, consulte “Asociaciones de seguridad” en

la página 8. Para obtener más información sobre los protocolos de seguridad IPSec,
consulte “Protocolos” en la página 6.
A través de la SA, un túnel IPSec puede proporcionar las siguientes funciones de

seguridad:
Privacidad (por encriptación)
Integridad de contenido (por autenticación de datos)
Autenticación de remitente y (si se usan certificados) prevención de rechazo

(por autenticación de origen de datos)
Las funciones de seguridad empleadas dependen de las necesidades particulares. Si

sólo necesita autenticar el origen del paquete IP y la integridad de contenido, puede
autenticar el paquete sin aplicar ningún tipo de encriptación. Por otro lado, si sólo le
preocupa preservar la privacidad, puede encriptar el paquete sin aplicar ningún
mecanismo de autenticación. También puede encriptar y autenticar el paquete. La
mayoría de los diseñadores de seguridad de red se decantan por la encriptación, la
autenticación y la protección contra reprocesamiento de paquetes para el tráfico
VPN.
ScreenOS admite la tecnología IPSec para la creación de túneles VPN con dos tipos
de mecanismos de elaboración de claves:
Clave manual
AutoKey IKE con un certificado o una clave previamente compartida
2 Introducción a las redes privadas virtuales

Capítulo 1: Seguridad del protocolo de Internet
Conceptos de IPSec
La seguridad IP (IPSec) es un conjunto de protocolos relacionados utilizados para
garantizar la seguridad de las comunicaciones en la capa de paquetes IP mediante
encriptación. La IPSec se compone de dos modos y dos protocolos principales:
Modos de túnel y de transporte
Protocolo de encabezado de autenticación (AH) para la autenticación y

protocolo de carga de seguridad encapsulada (ESP) para la encriptación (y la
autenticación)
IPSec también ofrece métodos para la negociación manual y automática de

asociaciones de seguridad (SA) y distribución de claves; todos los atributos
necesarios para ello están reunidos en un dominio de interpretación (DOI).
Consulte las normas RFC 2407 y RFC 2408.
Figura 2: Arquitectura IPSec
Modo de transporte Modo de túnel
Nota: ScreenOS
no admite el modo de
transporte
transporte con AH.
Protocolo AH Protocolo ESP
Algoritmo de autenticación Algoritmo de encriptación

(MD5, SHA-1) (DES, 3DES)
Dominio de interpretación
(DOI)
Administración de claves y SA
(manual y automática)
NOTA: El dominio de interpretación (DOI) IPSec es un documento que contiene

definiciones para todos los parámetros de seguridad requeridos para la
negociación satisfactoria de un túnel VPN (fundamentalmente, todos los atributos
necesarios para las negociaciones IKE y SA).
Conceptos de IPSec 3
Modos
La seguridad IPSec funciona en uno de dos modos: transporte o túnel Cuando
ambos extremos del túnel son hosts, se puede utilizar tanto el modo de transporte
como el modo de túnel. Cuando al menos uno de los puntos finales de un túnel es
una puerta de enlace de seguridad (como un enrutador o un cortafuegos), hay que
utilizar el modo de túnel. Los dispositivos de seguridad de Juniper Networks
funcionan siempre en modo de túnel cuando se trata de túneles IPSec y en modo
de transporte cuando se trata de túneles L2TP sobre IPSec.
Modo de transporte
El paquete IP original no está encapsulado en otro paquete IP, como se muestra en
la Figura 3. El paquete completo se puede autenticar (con AH), la carga se puede
encriptar (con ESP), y el encabezado original continúa en texto sin formato tal
como se envía por la WAN.
Figura 3: Modos de transporte

Paquetes IP
Modo de transporte, AH
Original AH Carga de datos
Autenticado
Modo de transporte,
ESP Original ESP Carga de datos
Encriptado
Autenticado
Modo de túnel
El paquete IP original completo (carga y encabezado) está encapsulado dentro de
otra carga IP y tiene adjunto un nuevo encabezado, como se muestra en la Figura 4.
El paquete original completo se puede encriptar, autenticar o ambas cosas. Con AH,
se autentican el AH y los nuevos encabezados. Con ESP, se autentica el encabezado
ESP.
Figura 4: Modos de túnel

Paquetes IP
El paquete original está encapsulado.
Modo de túnel, AH Nuevo Encabezado AH Encabezado
encabezado original Carga de datos
Autenticado
Modo de túnel, ESP Nuevo Encabezado

Encabezado ESP Carga de datos
encabezado original
Encriptado
Autenticado
4 Conceptos de IPSec
En una VPN punto a punto, las direcciones de origen y destino utilizadas en el

encabezado nuevo son las direcciones IP de la interfaz de salida (en modo de ruta o
NAT) o la dirección IP VLAN1 (en modo transparente); las direcciones de origen y
destino de los paquetes encapsulados son las direcciones de los puntos finales
definitivos de la conexión.
Figura 5: VPN punto a punto en modo de túnel
Puerta de enlace de túnel Puerta de enlace de túnel
Internet
LAN LAN
Túnel
1 2
B
A
A B Carga de datos 1 2 A B Carga de datos A B Carga de datos
En una VPN de acceso telefónico no existe ninguna puerta de enlace de túnel en el

extremo del túnel correspondiente al cliente de acceso telefónico VPN; el túnel se
prolonga directamente hasta el propio cliente. En este caso, en los paquetes
enviados desde el cliente de acceso telefónico, tanto el encabezado nuevo como el
encabezado encapsulado original tendrán la misma dirección IP: la del equipo del
cliente.
NOTA: Algunos clientes VPN, como NetScreen-Remote, permiten definir una dirección IP
interna virtual. En estos casos, la dirección IP interna virtual es la dirección IP de
origen en el encabezado del paquete original del tráfico originado por el cliente,
y la dirección IP que el ISP asigna dinámicamente al cliente de acceso telefónico
es la dirección IP de origen en el encabezado externo.
Figura 6: VPN de acceso telefónico en modo de túnel

Dispositivo B
Puerta de enlace de túnel
Internet
Cliente VPN de acceso telefónico
LAN
Túnel
A=1
2 B
A B Carga de datos 1 2 A B Carga de datos A B Carga de datos
Protocolos
IPSec utiliza dos protocolos para garantizar la seguridad de las comunicaciones en
la capa IP:
Encabezado de autenticación (AH): protocolo de seguridad que sirve para

autenticar el origen de un paquete IP y verificar la integridad de su contenido
Carga de seguridad encapsulada (ESP): protocolo de seguridad que sirve para

encriptar el paquete IP completo (y autenticar su contenido)
Encabezado de autenticación
El protocolo de encabezado de autenticación (AH) ofrece un medio para verificar la
autenticidad/integridad del contenido y el origen de un paquete. Puede autenticar el
paquete por la suma de comprobación calculada a través de un código de
autenticación de mensajes basado en hash (HMAC) mediante una clave secreta y
funciones MD5 o SHA-1 hash.
Message Digest versión 5 (MD5): Un algoritmo que produce un hash de

128 bits (también se denomina una firma digital o resumen del mensaje) a partir
de un mensaje de longitud arbitraria y una clave de 16 bytes. El hash resultante
se utiliza, como si fuese la huella dactilar de la entrada, para verificar la
autenticidad y la integridad del contenido y el origen.
Secure Hash Algorithm-1 (SHA-1): Un algoritmo que produce un hash de

160 bits a partir de un mensaje de longitud arbitraria y una clave de 20 bytes.
Normalmente, se considera más seguro que MD5 debido al mayor tamaño del
hash que produce. Como el procesamiento computacional se realiza en ASIC, el
coste de rendimiento es insignificante.
NOTA: Para obtener más información sobre los algoritmos MD5 y SHA-1, consulte las
siguientes normas RFC: (MD5) 1321, 2403; (SHA-1) 2404. Para obtener
información sobre HMAC, consulte la norma RFC 2104.
Carga de seguridad encapsulada

El protocolo de carga de seguridad encapsulada (ESP) proporciona un medio para
garantizar la privacidad (encriptación), la autenticación de origen y la integridad de
contenidos (autenticación). El protocolo ESP en modo de túnel encapsula el paquete
IP completo (encabezado y carga) y adjunta un nuevo encabezado IP al paquete que
ya se encriptó. Este nuevo encabezado IP contiene la dirección de destino necesaria
para enrutar los datos protegidos a través de la red.
Con ESP, es posible encriptar y autenticar, sólo encriptar o sólo autenticar. Para la
encriptación se puede seleccionar uno de los siguientes algoritmos de encriptación:
Norma de encriptación de datos (DES): Un algoritmo de bloque criptográfico

con una clave de 56 bits.
Triple DES (3DES): Una versión más potente de DES en la que el algoritmo
original DES se aplica en tres rondas utilizando una clave de 168 bits. DES
ofrece un ahorro de rendimiento significativo, pero no se considera aceptable
para numerosas transferencias de material delicado o clasificado.
Norma de encriptación avanzada (AES): norma de encriptación que, cuando

sea adoptada por las infraestructuras de Internet de todo el mundo, ofrecerá
una mayor interoperabilidad con otros dispositivos de seguridad de red.
ScreenOS admite AES con claves de 128, 192 y 256 bits.
Para la autenticación, puede utilizar algoritmos MD5 o SHA-1.
NOTA: Aunque es posible seleccionar NULL para la autenticación, se ha demostrado que

IPSec puede ser vulnerable a ataques bajo tales circunstancias. Por lo tanto, no es
recomendable seleccionar NULL para la autenticación.
Administración de claves
La distribución y la administración de claves son fundamentales para el uso
satisfactorio de las redes VPN. IPSec admite los métodos de distribución de claves
manual y automático.
Clave manual
Con las claves manuales, los administradores de ambos extremos de un túnel
configuran todos los parámetros de seguridad. Ésta es una técnica viable para redes
pequeñas y estáticas, donde la distribución, el mantenimiento y el seguimiento de
las claves no resulta difícil. Sin embargo, la distribución segura de configuraciones
de clave manual a través de largas distancias genera problemas de seguridad.
Excepto en el caso de que las claves se transmitan “cara a cara”, no es posible estar
completamente seguro de que las claves no hayan quedado comprometidas
durante la transferencia. Además, a la hora de modificar la clave nos enfrentamos a
los mismos problemas que a la hora de distribuirla inicialmente.
AutoKey IKE
Cuando es necesario crear y administrar numerosos túneles, se requiere un método
en el que no haya que configurar cada elemento de forma manual. IPSec admite la
generación y negociación automatizada de claves y asociaciones de seguridad
mediante el protocolo de intercambio de claves de Internet (IKE). ScreenOS
denomina estas negociaciones de túnel automatizadas “AutoKey IKE” y admite
AutoKey IKE con claves previamente compartidas y AutoKey IKE con certificados.
AutoKey IKE con claves previamente compartidas

Si AutoKey IKE utiliza claves previamente compartidas para autenticar a sus
participantes en una sesión IKE, cada parte debe configurar e intercambiar de
forma segura la clave compartida por adelantado. En este sentido, el problema de
distribución segura de claves es idéntico al que presentan las claves manuales. Sin
embargo, al contrario de lo que ocurre con las claves manuales, una AutoKey, una
vez distribuida, puede modificar sus claves automáticamente a intervalos
predeterminados mediante el protocolo IKE. Con frecuencia, la modificación de
claves aumenta la seguridad de forma considerable. Además, la automatización de
esta tarea reduce significativamente las responsabilidades de administración de
claves. Sin embargo, la modificación de claves eleva el nivel máximo de tráfico; por
lo tanto, si se realiza a menudo, puede disminuir la eficacia de la transmisión de
datos.
NOTA: Una clave previamente compartida es una clave que se utiliza tanto para la
encriptación como para la desencriptación y que ambos participantes deben
poseer antes de iniciar la comunicación.
AutoKey IKE con certificados

Cuando se utilizan certificados para autenticar a los participantes durante una
negociación AutoKey IKE, cada parte genera un par de claves públicas/privadas
(consulte “Criptografía de claves públicas” en la página 19) y adquiere un
certificado (consulte “Certificados y CRL” en la página 24). Si la autoridad de
certificación (CA) es fiable para ambas partes, los participantes podrán recuperar la
clave pública del interlocutor y verificar la firma del interlocutor. No es necesario
realizar un seguimiento de las claves y SA; IKE lo hace automáticamente.
NOTA: Para obtener ejemplos de ambos túneles (clave manual y AutoKey IKE), consulte
“Redes privadas virtuales de punto a punto” en la página 81.
Asociaciones de seguridad
Una asociación de seguridad (SA) es un acuerdo unidireccional entre los
participantes VPN por lo que respecta a los métodos y parámetros empleados para
garantizar la seguridad de un canal de comunicaciones. Una comunicación
bidireccional completa requiere al menos dos SA, una para cada dirección.
Una SA agrupa los siguientes componentes para garantizar la seguridad de las

comunicaciones:
Claves y algoritmos de seguridad
Modo de protocolo (transporte o túnel)
Método de administración de claves (clave manual o AutoKey IKE)
Periodo de vigencia de SA
Para el tráfico VPN saliente, la directiva invoca la SA asociada al túnel VPN. Para el
tráfico entrante, el dispositivo de seguridad consulta la SA mediante los siguientes
tres elementos:
IP de destino
Protocolo de seguridad (AH o ESP)
Valor del índice de parámetros de seguridad (SPI)
Negociación de túnel
Para un túnel IPSec de clave manual, como todos los parámetros de la SA se han
definido previamente, no es necesario negociar cuál SA utilizar. Básicamente, el
túnel ya se ha establecido. Cuando el tráfico coincide con una directiva que utilice
ese túnel de clave manual o cuando una ruta utiliza el túnel, el dispositivo de
seguridad simplemente encripta y autentica los datos, como se haya determinado y
los envía a la puerta de enlace de destino.
Para establecer un túnel IPSec AutoKey IKE se requieren dos fases de negociación:
En la fase 1, los participantes establecen un canal seguro en el que negociar las

SA IPSec.
En la fase 2, los participantes negocian las SA IPSec para encriptar y autenticar

los sucesivos intercambios de datos de usuario.
Fase 1
La fase 1 de una negociación de túnel AutoKey IKE consiste en el intercambio de
propuestas sobre cómo autenticar y garantizar la seguridad del canal. El
intercambio se puede realizar en uno de estos dos modos: inámico o principal. En
cualquiera de los dos modos, los participantes intercambian propuestas de servicios
de seguridad aceptables, como por ejemplo:
Algoritmos de encriptación (DES y 3DES) y de autenticación (MD5 y SHA-1).

Para obtener más información sobre estos algoritmos, consulte “Protocolos” en
la página 6.
Un grupo Diffie-Hellman (consulte “Intercambio Diffie-Hellman” en la

página 11).
Una clave previamente compartida o certificados RSA/DSA (consulte “AutoKey

IKE” en la página 7).
Una negociación de fase 1 correcta concluye cuando ambos extremos del túnel se
ponen de acuerdo para aceptar al menos un conjunto de los parámetros de
seguridad de fase 1 propuestos y comienzan a procesarlos. Los dispositivos de
seguridad de Juniper Networks admiten hasta cuatro propuestas para negociaciones
de fase 1 y permiten definir el grado de restricción del rango aceptable de
parámetros de seguridad para la negociación de claves.
Las propuestas predefinidas de fase 1 que ofrece ScreenOS son las siguientes:
Estándar: pre-g2-aes128-sha y pre-g2-3des-sha
Compatibles: pre-g2-3des-sha, pre-g2-3des-md5, pre-g2-des-sha y

pre-g2-des-md5
Básicas: pre-g1-des-sha y pre-g1-des-md5
También es posible definir propuestas de fase 1 personalizadas.
Negociación de túnel 9
Modo principal y modo dinámico

La fase 1 se puede desarrollar en modo principal o en modo dinámico. Estos dos
modos se describen a continuación.
Modo principal: el iniciador y el destinatario envían tres intercambios en dos

direcciones (seis mensajes en total) para lograr los siguientes servicios:
Primer intercambio (mensajes 1 y 2): proponer y aceptar los algoritmos de

encriptación y autenticación.
Segundo intercambio (mensajes 3 y 4): Ejecutar un intercambio Diffie-Hellman;

el iniciador y el destinatario ofrecen un número pseudoaleatorio cada uno.
Tercer intercambio (mensajes 5 y 6): enviar y verificar las identidades.
La información transmitida en el tercer intercambio de mensajes está protegida por

el algoritmo de encriptación establecido en los dos primeros intercambios. Es decir,
las identidades de los participantes no se transmiten de modo transparente.
Modo dinámico: El iniciador y el destinatario logran los mismos objetivos, pero en

sólo dos intercambios con un total de tres mensajes:
Primer mensaje: el iniciador propone la SA, inicia el intercambio Diffie-Hellman

y envía un número pseudoaleatorio y su identidad IKE.
Segundo mensaje: El destinatario acepta la SA, autentica al iniciador y envía un

número pseudoalatorio, su identidad IKE y si se utilizan certificados, el
certificado de destinatario.
Tercer mensaje: el iniciador autentica al destinatario, confirma el intercambio y,

si se utilizan certificados, envía el certificado de iniciador.
Puesto que las identidades de los participantes se intercambian en modo

transparente (en los dos primeros mensajes), el modo dinámico no ofrece
protección de identidad.
NOTA: Cuando un usuario VPN de acceso telefónico negocia un túnel AutoKey IKE con
una clave previamente compartida, se debe utilizar el modo dinámico. Recuerde
también que un usuario VPN de acceso telefónico puede utilizar una dirección de
correo electrónico, un nombre de dominio completo (FQDN) o una dirección IP
como su ID IKE. Un interlocutor dinámico puede utilizar una dirección de correo
electrónico o un FQDN, pero no una dirección IP.
10 Negociación de túnel
Intercambio Diffie-Hellman
Un intercambio Diffie-Hellman (DH) permite a los participantes elaborar un valor
secreto compartido. El punto fuerte de esta técnica es que permite a los
participantes crear el valor secreto a través de un medio no seguro sin tener que
transmitir este valor por la línea. Hay cinco grupos Diffie-Hellman; ScreenOS
admite los grupos 1, 2 y 5. El tamaño del módulo primario utilizado en el cálculo de
cada grupo varía del siguiente modo:
Grupo DH 1: módulo de 768 bits
NOTA: Las ventajes de la seguridad que ofrece el grupo DH 1 se han depreciado y no se

recomienda su uso.
Cuanto mayor es un módulo, más segura se considera la clave generada; no

obstante, cuanto mayor es un módulo, más tarda el proceso de generación de
claves. Como el módulo de cada grupo DH tiene un tamaño distinto, los
participantes tienen que ponerse de acuerdo para utilizar el mismo grupo.
NOTA: Si configura múltiples propuestas (hasta cuatro) para negociaciones de fase 1,

utilice el mismo grupo Diffie-Hellman para todas ellas. La misma directriz se aplica
a la creación de múltiples propuestas para negociaciones de fase 2.
Fase 2
Una vez que los participantes han establecido un canal seguro y autenticado,
continúan con la fase 2, en la que negocian las SA para garantizar la seguridad de
los datos que se van a transmitir a través del túnel IPSec.
Al igual que ocurre en la fase 1, los participantes intercambian propuestas para

determinar los parámetros de seguridad que se van a emplear en la SA. Una
propuesta de fase 2 incluye también un protocolo de seguridad (encabezado de
autenticación, AH, o carga de seguridad encapsulada, ESP) y algoritmos de
encriptación y autenticación seleccionados. La propuesta también puede especificar
un grupo Diffie-Hellman si se desea una confidencialidad directa perfecta (PFS).
Independientemente del modo utilizado en la fase 1, la fase 2 funciona siempre en

modo rápido e implica el intercambio de tres mensajes.
Los dispositivos de seguridad de Juniper Networks admiten hasta cuatro propuestas

para negociaciones de fase 2 y permiten definir el grado de restricción del rango
aceptable de parámetros de túnel. ScreenOS también ofrece una función de
protección contra reprocesamiento de paquetes. El uso de esta función no requiere
negociación porque los paquetes se envían siempre con números de secuencia.
Sólo existe la opción de comprobar o no los números de secuencia. (Para más
información sobre la protección contra reprocesamiento de paquetes, consulte
“Protección contra reprocesamiento de paquetes” en la página 12).
Negociación de túnel 11
Las propuestas predefinidas de fase 2 que ofrece ScreenOS son las siguientes:
Estándar: g2-esp-3des-sha y g2-esp-aes128-sha
Compatibles: nopfs-esp-3des-sha, nopfs-esp-3des-md5, nopfs-esp-des-sha y

nopfs-esp-des-md5
Básicas: nopfs-esp-des-sha y nopfs-esp-des-md5
También es posible definir propuestas de fase 2 personalizadas.
En la fase 2, los interlocutores también intercambian ID de proxy. Una ID de proxy

es una tupla de tres partes compuesta por dirección IP local/dirección IP
remota/servicio. La ID de proxy para ambos interlocutores debe coincidir, es decir,
el servicio especificado en la ID de proxy para ambos interlocutores debe ser
idéntico, y la dirección IP local indicada para un interlocutor debe ser igual que la
dirección IP remota indicada para el otro interlocutor.
Confidencialidad directa perfecta

La confidencialidad directa perfecta (PFS) es un método para derivar claves de
fase 2 independientes y no relacionadas con las claves anteriores. De forma
alternativa, la propuesta de fase 1 crea la clave (SKEYID_d) a partir de la que se
derivan todas las claves de fase 2. La clave SKEYID_d puede generar claves de
fase 2 con un mínimo de procesamiento de CPU. Lamentablemente, si un
interlocutor no autorizado obtiene acceso a la clave SKEYID_d, todas las claves de
encriptación quedarán comprometidas.
PFS afronta este riesgo de seguridad forzando un nuevo intercambio de claves

Diffie-Hellman para cada túnel de fase 2. Por lo tanto, utilizar PFS es más seguro,
aunque el procedimiento de reencriptación de la fase 2 puede prolongarse
ligeramente si la función PFS está habilitada.
Protección contra reprocesamiento de paquetes

Se produce un ataque de reproducción cuando alguien intercepta una serie de
paquetes y los utiliza posteriormente para inundar el sistema, provocando un
rechazo de servicio (DoS), o para obtener acceso a la red fiable. La función de
protección contra reprocesamiento de paquetes permite que los dispositivos de
seguridad comprueben cada paquete IPSec para verificar si se ha recibido
previamente. Si llegan paquetes fuera de un rango de secuencia especificado, el
dispositivo de seguridad los rechaza.
Paquetes IKE e IPSec

Un túnel VPN IPSec consta de dos elementos importantes:
Configuración del túnel: En primer lugar, los interlocutores establecen las

asociaciones de seguridad (SA), que definen los parámetros para asegurar el
tráfico entre ellos. Los administradores de cada extremo pueden definir las SA
manualmente, o bien dinámicamente durante las negociaciones IKE de fase 1 y
fase 2. La fase 1 se puede desarrollar en modo principal o en modo dinámico.
La fase 2 ocurre siempre en modo rápido.
12 Paquetes IKE e IPSec

Seguridad aplicada: IPSec protege el tráfico enviado entre los dos puntos
terminales del túnel usando los parámetros de seguridad definidos en las SA
que los interlocutores acordaron durante la configuración del túnel. IPSec
puede aplicarse en uno de dos modos: transporte o túnel. Ambos modos
admiten los dos protocolos IPSec: carga de seguridad encapsulada (ESP) y
encabezado de autenticación (AH).
Para obtener una explicación del procesamiento de paquetes que se produce

durante las etapas IKE e IPSec de un túnel VPN, consulte “Paquetes IKE” en la
página 13 y “Paquetes IPSec” en la página 16. Dichas secciones muestran los
encabezados de los paquetes para IKE e IPSec, respectivamente.
Paquetes IKE
Cuando un paquete de texto sin formato que requiere encapsulamiento llega al
dispositivo de seguridad y no existe ninguna SA activa de fase 2 para ese túnel, el
dispositivo de seguridad inicia las negociaciones IKE (y descarta el paquete). Las
direcciones de origen y de destino en el encabezado del paquete IP son las de las
puertas de enlace IKE local y remota, respectivamente. La carga de datos del
paquete IP icnluye un segmento UDP que encapsula una asociación de seguridad
de Internet y protocolo de gestión de claves (ISAKMP), o paquete IKE. El formato de
los paquetes IKE es igual para la fase 1 y la fase 2.
NOTA: Cuando se descarta el paquete IP inicial, el host de origen lo reenvía. Típicamente,

para cuando el segundo paquete alcanza el dispositivo de seguridad, las
negociaciones IKE se han completado y el dispositivo de seguridad lo protege
(como también protege todos los paquetes subsiguientes de esa sesión) con IPSec
antes de reenviarlo.
Paquetes IKE e IPSec 13

Figura 7: Paquete IKE para las fases 1 y 2
Encabezado Encabezado Encabezado Carga de

IP UDP ISAKMP datos
Nota: ISAKMP es el formato de paquetes utilizado por IKE.

Encabezado IP
Versión Longitud del

Tipo de servicio Tamaño total del paquete (en bytes)
encabezado
Tiempo de vida (TTL) Protocolo (17 para UDP) Suma de comprobación del encabezado
Dirección de origen (puerta de enlace del interlocutor local)
Dirección de destino (puerta de enlace del interlocutor remoto)
Opciones (si las hay) Relleno
Carga de datos IP
Encabezado UDP
Puerto de origen (500 para IKE) Puerto de destino (500 para IKE)
Longitud Suma de comprobación
Carga de datos UDP
Encabezado ISAKMP (para IKE)
Cookie del iniciador
Cookie del respondedor

(0000 para el primer paquete)
Carga de datos siguiente Ver may Ver men Tipo del intercambio Indicadores
ID del mensaje
Longitud del mensaje
Carga de datos ISAKMP
El campo de carga de datos siguiente contiene un número que indica uno de los
siguientes tipos de carga de datos:
0002—Carga de datos de la negociación SA: incluye una definición para la SA

de fase 1 o fase 2.
0004—Carga de datos de la propuesta: puede ser una propuesta de fase 1 o

fase 2.
0008—Carga de datos de transformación: La carga de datos de transformación

es encapsulada en una carga de datos propuesta que se encapsula en una carga
de datos SA.
0010—Carga de datos de intercambio de datos (KE): contiene la información

necesaria para realizar un intercambio de claves, como un valor público
Diffie-Hellman.

0020—Carga de datos de identificación (IDx).
En la fase 1, IDii indica la identificación del iniciador, mientras IDir indica

la del respondedor.
En la fase 2, IDui indica el iniciador del usuario, mientras IDur indica el

respondedor.
Las identificaciones son tipos de ID IKE, como FQDN, U-FQDN, dirección

IP y ASN.1_DN.
0040—Carga de datos de certificados (CERT).
0080—Carga de datos de petición de certificado (CERT_REQ).
0100—Carga de datos de Hash (HASH): contiene el resultado resumido de una

determinada función de transformación hash.
0200—Carga de datos de firma (SIG): contiene una firma digital.
0400—Carga de datos Nonce (Nx): contiene información pseudoaleatoria

necesaria para el intercambio.
0800—Carga de datos de notificación.
1000—Carga de datos de eliminación ISAKMP.
2000—Carga de datos de ID del vendedor (VID): puede incluirse en cualquier

parte de las negociaciones de la fase 1. ScreenOS la utiliza para marcar la
compatibilidad con NAT-T.
Cada carga de datos ISAKMP comienza con el mismo encabezado genérico, como
se muestra en la Figura 8.
Figura 8: Encabezado genérico de la carga de datos ISAKMP
Siguiente encabezado Reservado Longitud de la carga de datos (en bytes)
Carga de datos
Puede haber múltiples cargas de datos ISAKMP encadenadas, indicándose cada tipo
de carga de datos subsiguiente en el valor del campo del siguiente encabezado. Un
valor de 0000 indica la última carga de datos ISAKMP. Consulte la Figura 9 en la
página 16 para obtener un ejemplo.

Figura 9: Encabezado ISAKMP con cargas de datos genéricas ISAKMP
SPI del iniciador
SPI del respondedor (0000 para el primer paquete)

Carga de datos siguiente Encabezado
Maj Ver Min Ver Tipo del intercambio Indicadores de ISAKMP
(0002 para SA)
ID del mensaje
Longitud total del mensaje

Encabezado siguiente Reservado Longitud de la carga de datos SA
(0004 para propuesta) Carga de datos
SA
Carga de datos SA
Encabezado siguiente
(0008 para transformación) Reservado Longitud de la carga de datos de la propuesta
Carga de
datos
Carga de datos propuesta propuesta
Encabezado siguiente Reservado Longitud de la carga de datos de transformación
(0000 para fin) Carga de datos
de
Carga de datos de transformación transformación
Paquetes IPSec
Una vez completadas las negociaciones IKE y después de que las dos puertas de
enlace IKE hayan establecido las asociaciones de seguridad de fase 1 y fase 2 (SA),
el dispositivo NetScreen aplica la protección IPSec a los paquetes IP de texto sin
formato subsiguientes que los hosts situados detrás de una puerta de enlace IKE
envían a los hosts que se encuentran detrás de la otra puerta de enlace (asumiendo
que las directivas permitan el tráfico). Si la SA de fase 2 especifica el protocolo de
seguridad encapsulada (ESP) en modo de túnel, el paquete se parecerá al que
aparece debajo. El dispositivo de seguridad agrega dos encabezados adicionales al
paquete original enviado por el host.
NOTA: Para obtener más información sobre ESP, consulte “Carga de seguridad
encapsulada” en la página 6. Para obtener información sobre el modo de túnel,
consulte “Modo de túnel” en la página 4.
Figura 10: Paquete IPSec — datos de seguridad encapsulada (ESP) en el modo de túnel
Paquete IPSec
enviado por la puerta Paquete original
de enlace IKE enviado por el host iniciador
Encabezado Encabezado Encabezado Encabezado
IP2 ESP IP1 TCP Carga de datos
La puerta de enlace local agrega

estos encabezados al paquete.
Como muestra la Figura 10, el paquete que el host iniciador construye incluye la
carga de datos, el encabezado TCP y el encabezado IP interno (IP1).

El encabezado IP externo (IP2) que agrega el dispositivo de seguridad contiene la

dirección IP de la puerta de enlace remota como dirección IP de destino y la
dirección IP del dispositivo de seguridad local como dirección IP de origen. El
dispositivo de seguridad también agrega un encabezado ESP entre los encabezados
IP externo e interno. El encabezado ESP contiene información que permite al
interlocutor remoto procesar correctamente el paquete al recibirlo. Se ilustra en la
Figura 11: Encabezado IP externo (IP2) y encabezado ESP

Encabezado IP externo (IP2)
Longitud de
Versión encabezado Tipo de servicio Tamaño total del paquete (en bytes)
Tiempo de vida (TTL) Protocolo (50 para ESP) Suma de comprobación del encabezado
Dirección de origen (puerta de enlace del interlocutor local)
Dirección de destino (puerta de enlace del interlocutor remoto)
Carga de datos
Encabezado ESP
Índice de parámetros de seguridad (“Security Parameters Index” o SPI) del interlocutor remoto *
Número correlativo*
Vector de inicialización* (IV) – Primeros 8 octetos del campo de datos Autenticado

Carga de datos** (variable)
Encriptado
Relleno** (0-255 bytes) Longitud de relleno** Encabezado siguiente
(4 para IP)**
Datos de autenticación (variables)
* = secciones autenticadas del paquete

** = secciones encriptadas del paquete
El campo de encabezado siguiente indica el tipo de datos contenidos en el campo

de carga de datos. En el modo de túnel, este valor es 4, indicando IP-en-IP. Si se
aplica ESP en el modo de transporte, este valor indica un protocolo de capa de
transporte, como 6 para TCP o 17 para UDP.

Figura 12: Encabezado IP interno (IP1) y encabezado TCP

Encabezado IP interno (IP1)
Versión Longitud de Tipo de servicio Tamaño total del paquete (en bytes)
encabezado
Tiempo de vida (TTL) Protocolo (6 para TCP) Suma de comprobación del encabezado
Dirección de origen (host iniciador)
Dirección de destino (host receptor)
Carga de datos
Encabezado TCP
Puerto de origen Puerto de destino
Número de secuencia
Número de reconocimiento
Longitud de U A P R S F
encabezado Reservado R C S S Y I Tamaño de la ventana
G K H T N N
Suma de comprobación Indicador “Urgente”

Padding
Datos

Capítulo 2
Criptografía de claves públicas
En este capítulo se ofrece una introducción a la criptografía de claves públicas y al

uso de certificados y listas de revocación de certificados (CRL, o “Certificate
Revocation Lists”) en el marco de las infraestructuras de claves públicas (PKI,
o “Public Key Infraestructure”). Este capítulo incluye los siguientes temas:
“Introducción a la criptografía de claves públicas” en la página 20
“Firma de un certificado” en la página 20
“Verificación de una firma digital” en la página 20
“Infraestructura de claves públicas” en la página 22
“Certificados y CRL” en la página 24
“Carga de certificados y listas de revocación de certificados” en la

página 28
“Configuración de ajustes de CRL” en la página 29
“Obtención automática de un certificado local” en la página 31
“Renovación automática de certificado” en la página 34
“Protocolo de estado de certificado en línea (OCSP)” en la página 35
“Generación de pares de claves” en la página 35
“Especificación de un método de comprobación de revocación de

certificados” en la página 36
“Especificación de una URL del servidor de respuesta del protocolo de

estado de certificado en línea” en la página 37
“Certificados autofirmados” en la página 38
“Eliminación de atributos de comprobación de estado” en la página 37
“Creación manual de certificados autofirmados” en la página 40
19
“Establecimiento de un certificado autofirmado y definido por el

administrador” en la página 41
“Eliminar certificados autofirmados” en la página 46
Introducción a la criptografía de claves públicas

En la criptografía de claves públicas se utiliza el par formado por una clave pública y
otra privada para encriptar y desencriptar datos. Los datos encriptados con una
clave pública, que su propietario pone a disposición de otros usuarios, sólo pueden
ser desencriptados con la clave privada correspondiente, que el propietario
mantendrá protegida y en secreto. Por ejemplo, si Alicia quiere enviar a Juan un
mensaje encriptado, utilizará la clave pública de él para encriptarlo y,
a continuación, se lo enviará. Cuando reciba el mensaje, Juan podrá desencriptarlo
con su clave privada.
El método inverso también resulta de gran utilidad; esto es, encriptar los datos con
una clave privada y que se puedan desencriptar con la clave pública
correspondiente. Este método se conoce como firma digital. Si, por ejemplo, Alicia
desea que se sepa que ella es la autora de un mensaje, lo encripta con su clave
privada y lo envía de forma pública a Juan. A continuación, Juan sólo puede
desencriptar los datos utilizando la clave pública de Alicia, lo que significa que lo ha
enviado ella.
Los conjuntos de claves privada y pública también desempeñan un importante

papel en el uso de certificados digitales. El procedimiento para firmar un certificado
(por parte de una autoridad de certificación) y, después, verificar la firma (por parte
del receptor) se desarrolla tal y como se indica en las siguientes subsecciones:
Firma de un certificado
1. La autoridad de certificación (CA) que emite el certificado lo somete a una
operación matemática en la que se utiliza un algoritmo “hash” (MD5 o SHA-1)
para generar una codificación.
2. A continuación, la CA “firma” el certificado encriptando la codificación con su

clave privada. El resultado es una firma digital.
3. La CA envía el certificado firmado digitalmente a la persona que lo solicitó.
Verificación de una firma digital

1. Cuando el destinatario recibe el certificado, también genera otra codificación
aplicando el mismo algoritmo hash (MD5 o SHA-1) en el archivo de certificado.
2. El destinatario utiliza la clave pública de la CA para desencriptar la firma digital.
3. El destinatario compara la codificación desencriptada con la que se acaba de

generar. Si las dos coinciden, el destinatario puede confirmar la integridad de la
firma de la CA y, por extensión, la integridad del certificado que lo acompaña.
20 Introducción a la criptografía de claves públicas

Capítulo 2: Criptografía de claves públicas
Figura 13: Verificación de firma digital
Emisor (CA)
1. La CA genera la codificación A a partir del certificado utilizando Codif. A

el algoritmo hash MD5 o SHA-1. Cert.
Algoritmo hash
2. Con su clave privada, la CA encripta la codificación A. El (MD5 o SHA-1)
resultado es la codificación B, la firma digital.
3. La CA envía el certificado firmado digitalmente a la persona que

lo solicitó. Codif. B
Clave privada de la CA
Receptor
1. Genera la codificación A a partir del certificado utilizando MD5 o Codif. A Cert.

SHA-1.
Comparación Algoritmo hash
2. Utilizando la clave pública de la CA, desencripta la codificación B. (MD5 o SHA-1)
3. Compara la codificación A con la B. Si coinciden, el receptor sabrá
que el certificado no está manipulado.
Codif. B
Clave privada de la CA
El procedimiento de firma digital de los mensajes enviados por dos participantes en

una sesión IKE funciona de forma muy parecida, con las siguientes diferencias:
En lugar de generar una codificación a partir del certificado de la CA, el emisor

lo genera a partir de los datos del paquete IP.
En lugar de utilizar el par de claves pública/privada de la CA, los participantes

utilizan el par de claves pública/privada del emisor.
Introducción a la criptografía de claves públicas 21

Infraestructura de claves públicas

La infraestructura de claves públicas (PKI) hace referencia a la estructura jerárquica
de confianza necesaria para la correcta implementación de la criptografía de claves
públicas. Para verificar la fiabilidad de un certificado, es necesario poder identificar
una ruta de CA fiables, desde la CA que emite el certificado localmente hasta la
autoridad raíz de un dominio de CA.
Figura 14: Jerarquía de PKI en Trust — Dominio de CA
La CA de nivel raíz valida las CA subordinadas.
Las CA subordinadas
validan certificados locales
y a otras CA.
Los certificados locales

contienen la clave pública
del usuario.
22 Infraestructura de claves públicas

Si los certificados se utilizan exclusivamente dentro de una organización, dicha

organización puede tener su propio dominio de CA dentro del cual una CA de la
empresa emite y valida certificados entre sus empleados. Si después esa
organización desea que sus empleados puedan intercambiar sus certificados con
otro dominio de CA (por ejemplo, con empleados de otra organización que tiene su
propio dominio de CA), las dos CA pueden desarrollar una certificación cruzada; es
decir, pueden llegar a un acuerdo para confiar mutuamente en la autoridad de cada
una de ellas. En este caso, la estructura de la PKI no se extiende en vertical, sino en
horizontal.
Figura 15: Certificación cruzada
Dominio CA: A Dominio CA: B
Certificación cruzada
Los usuarios del dominio A pueden utilizar sus certificados y pares de

claves con los usuarios del dominio B porque ambas CA disponen de
certificación cruzada entre sí.
Por motivos prácticos y de comodidad, la PKI debe administrarse e implementarse

de forma transparente. Para conseguirlo, ScreenOS hace lo siguiente:
1. Genera un par de claves pública/privada cuando se crea una petición de

certificado.
2. Proporciona esa clave pública como parte de la petición de certificado en un

archivo de texto que se transmite a una autoridad de certificación (CA) para la
inscripción del certificado (archivo PKCS 10).
3. Permite cargar el certificado local, el certificado de CA y la lista de revocación

de certificados (SubinterfaceCRL) en la unidad.
NOTA: La autoridad de certificación normalmente proporciona una CRL. Aunque puede

cargar una CRL en el dispositivo de seguridad, no podrá verla una vez cargada.
También puede especificar un intervalo de tiempo para actualizar la CRL

automáticamente. Para obtener más información sobre las CRL, consulte
“Certificados y CRL” en la página 24.
4. Permite enviar certificados cuando se establece un túnel IPSec.
Infraestructura de claves públicas 23

5. Admite la validación ascendente de rutas de certificados a través de ocho

niveles de autoridades CA en la jerarquía PKI.
6. Es compatible con la norma de criptografía PKCS 7, lo que significa que el

dispositivo de seguridad puede aceptar certificados X.509 y CRL empaquetadas
según la norma PKCS 7. La compatibilidad con PKCS 7 permite enviar
múltiples certificados X.509 dentro de una única petición PKI. Ahora es posible
configurar PKI para validar a la vez todos los certificados enviados por la CA
emisora.
NOTA: ScreenOS admite un tamaño de archivo PKCS nº. 7 de hasta 7 kB.
7. Admite recuperación de CRL en línea a través de LDAP o HTTP.
Certificados y CRL
Un certificado digital es un método electrónico para verificar la identidad de un
usuario utilizando la palabra de una tercera parte en la que se confía, conocida
como autoridad de certificación (CA). El servidor de CA que se utilice puede ser
propiedad de una CA, que también se encargue de su manejo, o de su propia
organización, en cuyo caso usted será su propia CA. Si utiliza una CA independiente,
debe ponerse en contacto con ella para obtener las direcciones de los servidores de
CA y CRL (y conseguir certificados y listas de revocación de certificados) o la
información que dichos servidores necesitan cuando envían peticiones de
certificados personales. Si es su propia CA, podrá hacerlo usted mismo.
NOTA: ScreenOS admite las siguientes CA: Baltimore, Entrust, Microsoft, Netscape, RSA
Keon y Verisign.
ScreenOS dispone de un certificado de CA para las descargas de autenticación

desde el servidor de archivos de firmas de virus y el servidor de la base de datos
de objetos de ataque Deep Inspection (DI). Para obtener más información sobre el
servidor de archivos de firmas de virus, consulte “Análisis antivirus” en la
página 4-62. Para obtener más información sobre el servidor de la base de datos
de objetos de ataque DI, consulte “Servidor de la base de datos de objetos de
ataque” en la página 4-124.
Para utilizar un certificado digital y así autenticar su identidad al establecer una

conexión VPN segura, siga estos pasos:
Genere una clave en el dispositivo de seguridad, envíela a una CA para obtener

un certificado personal (que también se conoce como un certificado local) y
cargue el certificado en el dispositivo de seguridad.
Consiga un certificado de la CA que emitió el certificado personal (básicamente

para verificar la identidad de la CA que lo verifica a usted) y cargue el
certificado de la CA en el dispositivo de seguridad. Esta tarea puede realizarla
manual o automáticamente, utilizando el protocolo de inscripción de
certificado sencillo (SCEP, Simple Certificate Enrollment Protocol).
24 Certificados y CRL
Si el certificado no contiene la extensión de punto de distribución de

certificados (CDP) y no recibe automáticamente la CRL a través de LDAP o
HTTP, puede obtenerla manualmente y cargarla en el dispositivo de seguridad.
Durante el proceso de negociación, puede haber muchos casos en los que sea
necesario revocar un certificado. Es posible que quiera revocar un certificado si
sospecha que es peligroso o si su propietario ha dejado la empresa. Las
revocaciones y validaciones de certificados se pueden administrar localmente
(aunque esta solución es limitada) o con referencia a la CRL de una CA, a la que se
puede acceder en línea de forma automática en intervalos diarios, semanales o
mensuales o según el intervalo predefinido por la CA.
Para conseguir un certificado firmado digitalmente siguiendo el método manual,

debe seguir estos pasos:
1. Generar un par de claves pública/privada
2. Llenar la petición de certificado
3. Enviar la petición a la CA que desee
4. Una vez recibido el certificado firmado, cargarlo en el dispositivo de seguridad

junto con el certificado de CA
Ahora dispondrá de los siguientes elementos con los siguientes objetivos:
Un certificado local para el dispositivo de seguridad para autenticar su

identidad en cada conexión de túnel
Un certificado de CA (clave pública de la CA), para verificar el certificado del

otro interlocutor
Si la lista de revocación de certificados (CRL) está incluida en el certificado de

CA, una CRL para identificar certificados no válidos
NOTA: La CRL puede acompañar al certificado de CA y se puede almacenar en la base de

datos de ScreenOS Alternativamente, el certificado de CA puede contener la URL
de la CRL (ya sea LDAP o HTTP) si ésta se encuentra almacenada en la base de
datos de la CA. Si es incapaz de obtener la CRL por cualquiera de los métodos,
puede introducir manualmente la URL de la CRL en el dispositivo de seguridad, tal
y como se explica en “Configuración de ajustes de CRL” en la página 29.
Cuando reciba estos archivos (los archivos de certificado suelen tener extensión la
.cer y los archivos de CRL, la extensión .crl), cárguelos en el dispositivo de
seguridad siguiendo el procedimiento descrito en “Petición manual de un
certificado” en la página 26.
NOTA: Si piensa utilizar el correo electrónico para enviar un archivo PKCS 10 y obtener
los certificados, debe configurar adecuadamente los ajustes de ScreenOS para
poder enviar mensajes de correo electrónico al administrador del sistema. Deberá
establecer los servidores DNS principal y secundario, y especificar los ajustes de
dirección del servidor SMTP y del servidor de correo.
Certificados y CRL 25
Petición manual de un certificado

Cuando se solicita un certificado, el dispositivo de seguridad genera un par de
claves. La clave pública se incorpora en la propia petición y, posteriormente, en el
certificado local firmado digitalmente que recibirá de la CA.
En el siguiente ejemplo, el administrador de seguridad realiza una petición de

certificado para Michael Zhang en el departamento de desarrollo de
Juniper Networks in Sunnyvale, California. Este certificado se utilizará en un
dispositivo de seguridad con la dirección IP 10.10.5.44. El administrador ordena al
dispositivo de seguridad que envíe la petición por correo electrónico al
administrador de seguridad, que tiene la dirección admin@juniper.net.
A continuación, el administrador de seguridad copia la petición y la pega en el
campo de texto de petición de certificado en el punto de inscripción de certificados
de la CA. Una vez finalizado el proceso de inscripción, la CA normalmente devuelve
el certificado por correo electrónico al administrador de seguridad.
NOTA: Una cadena de identidad certificada especial, llamada dominio-componente, está

disponible únicamente a través de la CLI. Los dispositivos pueden utilizar este
valor en certificados para que IPSec se conecte a puertas de enlace VPN. Por
ejemplo, el dispositivo puede utilizarlo como una ID IKE de grupo, aceptando las
identidades IKE tipo ASN1_DN que contienen “DC=Ingenieros, DC=NuevaYork”.
Antes de generar una petición de certificado, compruebe que ha ajustado el reloj

del sistema y que ha asignado un nombre de host y un nombre de dominio al
dispositivo de seguridad. Si el dispositivo de seguridad se encuentra en un clúster
NSRP, sustituya el nombre de host por un nombre de clúster. Para obtener más
información, consulte “Creación de un clúster de NSRP” en la página 11-29.)
WebUI
1. Generación del certificado
Objects > Certificates > New: Introduzca los siguientes datos y haga clic
en Generate:
Name: Michael Zhang

Phone: 408-730-6000
Unit/Department: Development
Organization: Juniper Networks
County/Locality: Sunnyvale
State: CA
Country: US
E-mail: mzhang@juniper.net
IP Address: 10.10.5.44
Write to file: (seleccione)
RSA: (seleccione)
Create new key pair of 1024 length: (seleccione)
El dispositivo de seguridad genera un archivo PKCS nº. 10 y solicita que envíe

el archivo por correo electrónico, lo guarde en disco o lo inscriba
automáticamente a través del protocolo SCEP (Simple Certificate Enrollment
Protocol).
Seleccione la opción E-mail to, escriba admin@juniper.net y después haga

clic en OK.
NOTA: Determinadas CA no admiten direcciones de correo electrónico en los

certificados. Si no incluye una dirección de correo electrónico en la petición de
certificado local, no podrá utilizarla como identificación de IKE local al configurar
el dispositivo de seguridad como interlocutor dinámico. En su lugar, podrá utilizar
un nombre de dominio completo (si se encuentra en el certificado local) o dejar el
campo vacío. Predeterminadamente el dispositivo de seguridad envía su
nombrehost.nombredominio. Si no especifica la identificación local para un
interlocutor dinámico, introduzca el nombrehost.nombredominio del interlocutor
en el dispositivo que se encuentra en el otro extremo del túnel IPSec en el campo
de identificación del interlocutor.
El valor 1024 indica la longitud en bits del par de claves. Si va a utilizar el

certificado para SSL (consulte “Secure Sockets Layer” en la página 3-5), asegúrese
de que utiliza una longitud de bits que también sea compatible con su explorador.
Si utiliza la dirección de correo electrónico, se supone que ya ha configurado la

dirección IP para el servidor SMTP: set admin mail server-name { dir_ip |
nombre_dom }.
2. Petición de certificado
El administrador de seguridad abre el archivo y copia su contenido, procurando
copiar el texto completo pero no los espacios en blanco situados delante o
detrás del texto (comenzando por “-----BEGIN CERTIFICATE REQUEST-----” y
finalizando en “-----END CERTIFICATE REQUEST-----”).
A continuación, el administrador de seguridad sigue las direcciones de la

petición de certificado en el sitio web de la CA, pegando el archivo PKCS no. 10
en el campo apropiado.
3. Recuperación del certificado

Cuando el administrador de seguridad recibe el certificado de la CA por correo
electrónico, se lo reenvía a usted. Cópielo en un archivo de texto y guárdelo en
su estación de trabajo (para después cargarlo en el dispositivo de seguridad a
través de la interfaz WebUI) o en un servidor TFTP (para cargarlo a través de
CLI).
CLI
1. Generación del certificado
set pki x509 dn country-name US
set pki x509 dn email mzhang@juniper.net
set pki x509 dn ip 10.10.5.44
set pki x509 dn local-name “Santa Clara”
set pki x509 dn name “Michael Zhang”
set pki x509 dn org-name “Juniper Networks”
set pki x509 dn org-unit-name Development
set pki x509 phone 408-730-6000
set pki x509 dn state-name CA
set pki x509 default send-to admin@juniper.net
exec pki rsa new-key 1024
NOTA: Si utiliza la dirección de correo electrónico, se supone que ya ha configurado la

dirección IP para el servidor SMTP: set admin mail server-name { dir_ip |
nombre_dom }.
La petición de certificado se envía por correo electrónico a admin@juniper.net.
2. Petición de certificado
El administrador de seguridad abre el archivo y copia su contenido, procurando
copiar el texto completo pero no los espacios en blanco situados delante o
detrás del texto (comenzando por “-----BEGIN CERTIFICATE REQUEST-----” y
finalizando en “-----END CERTIFICATE REQUEST-----”).
A continuación, el administrador de seguridad sigue las direcciones de la

petición de certificado en el sitio web de la CA, pegando el archivo PKCS nº. 10
en el campo apropiado.
3. Recuperación del certificado

Cuando el administrador de seguridad recibe el certificado de la CA por correo
electrónico, se lo reenvía a usted. Cópielo en un archivo de texto y guárdelo en
su estación de trabajo (para después cargarlo en el dispositivo de seguridad a
través de la interfaz WebUI) o en un servidor TFTP (para cargarlo a través de
CLI).
Carga de certificados y listas de revocación de certificados

La CA le devuelve los siguientes tres archivos para que los cargue en el dispositivo
de seguridad:
Un certificado de CA, que contiene la clave pública de la CA
Un certificado local, que identifica su equipo local (su clave pública)
Una CRL, que enumera los certificados revocados por la CA
Para el ejemplo con la WebUI, habrá descargado los archivos a un directorio

llamado C:\certs\ns en la estación de trabajo del administrador. Para el ejemplo con
CLI, habrá descargado el directorio raíz TFTP a un servidor TFTP con la dirección
IP 198.168.1.5.
NOTA: Los dispositivos de seguridad de Juniper Networks configurados con ScreenOS 2.5
o versiones posteriores (incluyendo los sistemas virtuales) permiten cargar
certificados locales desde distintas CA.
En este ejemplo se muestra cómo se deben cargar dos archivos distintos, llamados
auth.cer (certificado de CA) y local.cer (su clave pública), junto con el archivo de
CRL llamado distrust.crl.
WebUI
1. Objects > Certificates: Seleccione Load Cert y después haga clic en Browse.
2. Acceda al directorio C:\certs, seleccione auth.cer y después haga clic en Open.
La ruta del directorio y el nombre de archivo (C:\certs\ns\auth.cer) aparecerán

en el campo File Browse.
3. Haga clic en Load.
Se cargará el archivo local.cer.
4. Objects > Certificates: Seleccione Load Cert y después haga clic en Browse.
5. Acceda al directorio C:\certs, seleccione local.cer y después haga clic en Open.
La ruta del directorio y el nombre de archivo (C:\certs\ns\local.cer) aparecerán

en el campo File Browse.
El archivo del certificado local.cer se carga.
7. Objects > Certificates: Seleccione Load CRL y después haga clic en Browse.
8. Acceda al directorio C:\certs, seleccione distrust.cer y después haga clic

en Open.
Se cargará el archivo de CRL distrust.crl.
CLI
exec pki x509 tftp 198.168.1.5 cert-name auth.cer
exec pki x509 tftp 198.168.1.5 cert-name local.cer
exec pki x509 tftp 198.168.1.5 crl-name distrust.crl
Configuración de ajustes de CRL

En la fase 1 de las negociaciones, los participantes consultan la lista CRL para
comprobar si los certificados recibidos durante un intercambio IKE siguen siendo
válidos. Si una CRL no está cargada en la base de datos de ScreenOS, el dispositivo
de seguridad intentará recuperarla mediante la ubicación de LDAP o HTTP CRL
definida en el propio certificado. Si no hay ninguna dirección URL definida en el
certificado, el dispositivo de seguridad utiliza la URL del servidor definido para ese
certificado de CA. Si el certificado de CA no está cargado en el dispositivo (por
ejemplo, una CA intermedia de la cadena del certificado recibida durante el
intercambio de IKE), no puede resolver la URL del servidor de CRL para esa CA. En
este caso, puede especificar la URL del servidor de CRL en la sección de Ajustes de
validación del certificado predeterminado de la UI de web (consulte la siguiente
página). Una URL del servidor de CRL que se introduzca aquí sólo se utilizará
cuando el certificado de CA no está presente en el dispositivo. No hay una URL
predeterminada.
NOTA: La extensión del punto de distribución de la CRL (.cdp) en un certificado X509

puede ser una URL HTTP o una URL LDAP.
Con ScreenOS 2.5 y versiones posteriores, al cargar la CRL puede desactivar la

comprobación de firmas digitales. Sin embargo, si desactiva la comprobación del
certificado de CRL pondrá en peligro la seguridad de su dispositivo.
En este ejemplo, primero configurará el servidor de CA Entrust para comprobar la

CRL diariamente mediante una conexión al servidor LDAP ubicado en 2.2.2.121 y
la localización del archivo de CRL. A continuación configurará los ajustes
predeterminados de validación de certificados para su uso en el servidor LDAP
ubicado en 10.1.1.200, comprobando también diariamente la CRL.
NOTA: El número de índice (IDX) para el certificado de Entrust CA es 1. Para poder ver
una lista de los números IDX de todos los certificados de CA cargados en un
dispositivo de seguridad, utilice el siguiente comando CLI: get pki x509 list
ca-cert.
WebUI
Objects > Certificates (Show: CA) > Server Settings (para NetScreen):
X509 Cert_Path Validation Level: Full

CRL Settings:
URL Address: ldap:///CN=Entrust,CN=en2001,CN=PublicKeyServices,
CN=Services,CN=Configuration,DC=EN2001,DC=com?CertificateRevocati
onList?base?objectclass=CRLDistributionPoint
LDAP Server: 2.2.2.121
Refresh Frequency: Daily
Objects > Certificates > Default Cert Validation Settings: Introduzca los
X509 Certificate Path Validation Level: Full

Certificate Revocation Settings:
Check Method: CRL
URL Address:
ldap:///CN=NetScreen,CN=safecert,CN=PublicKeyServices,
CN=Services,CN=Configuration,DC=SAFECERT,DC=com?CertificateRevoc
ationList?base?objectclass=CRLDistributionPoint
LDAP Server: 10.1.1.200
CLI
set pki authority 1 cert-path full
set pki authority 1 cert-status crl url “ldap:///CN=Entrust,CN=en2001,
CN=PublicKeyServices,CN=Services,CN=Configuration,DC=EN2000,DC=com?
CertificateRevocationList?base?objectclass=CRLDistributionPoint”
set pki authority 1 cert-status crl server-name 2.2.2.121
set pki authority 1 cert-status crl refresh daily
set pki authority default cert-path full
set pki authority default cert-status crl url “ldap:///CN=NetScreen,
CN=safecert,CN=PublicKeyServices,CN=Services,CN=Configuration,DC=SAFE
CERT,
DC=com?CertificateRevocationList?base?objectclass=CRLDistributionPoint”
set pki authority default cert-status crl server-name 10.1.1.200
set pki authority default cert-status crl refresh daily
save
Obtención automática de un certificado local

Para utilizar un certificado digital y así autenticar su identidad al establecer una
conexión VPN segura, siga estos pasos:
Consiga el certificado de una autoridad de certificación (CA) de la cual desee

obtener un certificado personal y cárguelo en el dispositivo de seguridad.
Obtenga un certificado local (también llamado certificado personal) de la CA

cuyo certificado de CA ya ha cargado y, a continuación, cargue el certificado
local en el dispositivo de seguridad. Esto lo puede hacer manual o
automáticamente, utilizando el protocolo SCEP (Simple Certificate Enrollment
Protocol).
Como durante el método manual para solicitar certificados locales se le va a pedir

que copie información de un certificado a otro, puede llegar a ser un proceso largo.
Para evitarlo, puede utilizar el método automático.
Antes de utilizar el protocolo SCEP, debe llevar a cabo estas tareas:
Configurar y habilitar DNS. (Consulte “Compatibilidad con DNS (sistema de

nombres de dominio)” en la página 2-219.)
Ajustar el reloj del sistema. (Consulte “Reloj del sistema” en la página 2-256.)
Asignar un nombre de host y un nombre de dominio al dispositivo de

seguridad. Si el dispositivo de seguridad se encuentra en un clúster NSRP,
sustituya el nombre de host por un nombre de clúster. Para obtener más
información, consulte “Creación de un clúster de NSRP” en la página 11-29.)
En este ejemplo seguirá el método automático para solicitar un certificado local. Se

utiliza SCEP con la CA Verisign. Establecerá los siguientes ajustes de CA:
Validación de la ruta de certificado completa
RA CGI: http://ipsec.verisign.com/cgi-bin/pkiclient.exe
NOTA: La interfaz de puerta de enlace común (CGI, o “Common Gateway Interface”) es

un método estándar que utilizan los servidores web para enviar una petición de
usuario a un programa de aplicación y recibir a cambio datos. La interfaz CGI
forma parte del protocolo de transferencia de hipertexto (HTTP, o “Hypertext
Transfer Protocol”). Debe especificar una ruta RA CGI aunque la autoridad de
registro (RA) no exista. Si la RA no existe, utilice el valor especificado para la CA
CGI.
CA CGI: http://ipsec.verisign.com/cgi-bin/pkiclient.exe
Confirmación automática de la integridad de los certificados de CA
CA ID, que identifica un servidor SCEP, donde el servidor SCEP de Verisign

utilizará un nombre de dominio, como juniper.net, o un dominio establecido
por Verisign para su empresa
Contraseña de desafío
Sondeo automático de certificado cada 30 minutos (de forma predeterminada

no se realiza ningún sondeo)
A continuación generará un par de claves RSA, especificando una longitud de

1024 bits, e iniciará la operación SCEP para solicitar un certificado local de la CA
Verisign con los ajustes de CA anteriormente mencionados.
Si utiliza la interfaz WebUI, hará referencia a los certificados de CA por su nombre.

Si utiliza CLI, hará referencia a los certificados de CA por su número de índice (IDX).
En este ejemplo, el número IDX de la CA Verisign es “1”. Para consultar los números
IDX para los certificados de CA, utilice el siguiente comando: get pki x509 list
ca-cert. Aparecerá un número IDX y un número de ID para cada certificado.
Apunte el número IDX y utilícelo para hacer referencia al certificado de CA en los
comandos.
WebUI
1. Ajustes del servidor de CA
Objects > Certificates > Show CA > Server Settings (para Verisign): Introduzca
X509 certificate path validation level: Full

SCEP Settings:
RA CGI: http://ipsec.verisign.com/cgi-bin/pkiclient.exe
CA CGI: http://ipsec.verisign.com/cgi-bin/pkiclient.exe
> Advanced: Introduzca los siguientes ajustes avanzados, después haga

clic en Return para regresar a la página de configuración básica CA Server
Settings:
Polling Interval: 30
Certificate Authentication: Auto
Certificate Renew: 14
2. Petición de certificado local

en Generate:
Name: Michael Zhang

Phone: 408-730-6000
Unit/Department: Development
Organization: Juniper Networks
County/Locality: Sunnyvale
State: CA
Country: US
Email: mzhang@juniper.net
Key Pair Information
RSA: (seleccione)
Create new key pair of 1024 length.
NOTA: El valor 1024 indica la longitud en bits del par de claves. Si va a utilizar el
certificado para SSL, asegúrese de que utiliza una longitud de bits que también sea
compatible con su explorador.
Ejecute el comando CLI get pki x509 pkcs para que el dispositivo de seguridad
genere un archivo PKCS nº. 10 y, a continuación, siga uno de estos pasos:
Enviar el archivo PKCS nº. 10 de petición de certificado a una dirección de

correo electrónico
Guardarlo en disco
Inscribirlo automáticamente enviando el archivo a una CA que admita el

protocolo (SCEP)
3. Inscripción automática
Seleccione la opción Automatically enroll to, luego la opción Existing CA
server settings y finalmente seleccione Verisign en la lista desplegable.
Póngase en contacto con Verisign para informarles sobre su petición de

certificado. Verisign debe autorizar la petición de certificado antes de que usted
pueda descargarlo.
CLI
1. Ajustes del servidor de CA
set pki authority 1 cert-path full
set pki authority 1 scep ca-cgi “http://ipsec.verisign.com/cgi-bin
/pkiclient.exe”
set pki authority 1 scep ra-cgi “http://ipsec.verisign.com/cgi-bin
/pkiclient.exe”
set pki authority 1 scep polling-int 30
set pki authority 1 scep renew-start 14
NOTA: La interfaz de puerta de enlace común (CGI, o “Common Gateway Interface”) es

un método estándar que utilizan los servidores web para enviar una petición de
usuario a un programa de aplicación y recibir a cambio datos. La interfaz CGI
forma parte del protocolo de transferencia de hipertexto (HTTP, o “Hypertext
Transfer Protocol”).
Debe especificar una ruta RA CGI aunque la autoridad de registro (RA) no exista. Si
la RA no existe, utilice el valor especificado para la CA CGI.
2. Petición de certificado local

set pki x509 dn country-name US
set pki x509 dn email mzhang@juniper.net
set pki x509 dn ip 10.10.5.44
set pki x509 dn local-name “Santa Clara”
set pki x509 dn name “Michael Zhang”
set pki x509 dn org-name “Juniper Networks”
set pki x509 dn org-unit-name Development
set pki x509 phone 408-730-6000
set pki x509 dn state-name CA
exec pki rsa new 1024
3. Inscripción automática
exec pki x509 scep 1
Si ésta es la primera petición de certificado que envía a esta CA, aparecerá un

mensaje presentando un valor de marca de identidad para el certificado de CA.
Debe ponerse en contacto con la CA para confirmar que se trata del certificado de
CA correcto.
Póngase en contacto con Verisign para informarles sobre su petición de certificado.

Verisign debe autorizar la petición de certificado antes de que usted pueda
descargarlo.
Renovación automática de certificado

Puede habilitar el dispositivo de seguridad para que renueve automáticamente los
certificados adquiridos a través del protocolo SCEP (Certificate Enrollment
Protocol). Esta función evita tener que acordarse de renovar los certificados en el
dispositivo de seguridad antes de que venzan y, por el mismo token, mantiene la
validez de los certificados en todo momento.
De forma predeterminada, esta función está inhabilitada. Puede configurar el

dispositivo de seguridad para que envíe automáticamente una petición para
renovar un certificado antes de que venza. Puede establecer el momento en que
desee que el dispositivo de seguridad envíe la petición de renovación del certificado
en días y minutos antes de la fecha de vencimiento. Si establece momentos
distintos para cada certificado, evitará que el dispositivo de seguridad tenga que
renovar todos los certificados al mismo tiempo.
Para evitar problemas con esta función, el dispositivo de seguridad debe ser capaz
de acceder al servidor SCEP y el certificado debe estar presente en el propio
dispositivo de seguridad durante el proceso de renovación. También debe
asegurarse de que la CA que emite el certificado pueda hacer lo siguiente:
Admitir la aprobación automática de peticiones de certificado.
Devolver el mismo nombre de dominio (DN). En otras palabras, la CA no debe

modificar el nombre del sujeto ni la extensión SubjectAltName en el nuevo
certificado.
Puede activar y desactivar la función de renovación automática de certificados

SCEP para todos los certificados SCEP o de forma individual.
Generación de pares de claves

Los dispositivos de seguridad guardan en memoria las claves generadas
previamente. El número de claves generadas previamente depende del modelo de
dispositivo. Durante el funcionamiento normal, el dispositivo de seguridad es capaz
de disponer de claves suficientes para renovar certificados, puesto que cada vez que
utiliza una clave genera otra nueva. El proceso de generación de claves
normalmente se ejecuta en segundo plano, ya que el dispositivo tiene tiempo para
generar una nueva clave antes de que se necesite utilizar otra. En caso de que el
dispositivo de seguridad renueve un gran número de certificados al mismo tiempo
y tenga que utilizar claves rápidamente, podría llegar a quedarse sin claves
generadas previamente y tener que generarlas inmediatamente con cada nueva
petición. Si esto es así, la generación de claves podría afectar al funcionamiento del
dispositivo de seguridad, especialmente en entornos de alta disponibilidad (HA),
donde el rendimiento del dispositivo de seguridad podría ralentizarse durante
algunos minutos.
El número de pares de claves generadas previamente en un dispositivo de

seguridad depende del modelo. Para más información, consulte la hoja de
especificaciones de su producto de seguridad de Juniper Networks.
Protocolo de estado de certificado en línea (OCSP)

Cuando un dispositivo de seguridad realiza una operación en la que se utiliza un
certificado, suele ser importante verificar su validez. Los certificados pueden
quedar invalidados por vencimiento o por revocación. La forma habitual de
comprobar el estado de los certificados es utilizar las listas de revocación de
certificados (CRL). El protocolo de estado de certificado en línea (OCSP) es otra
forma de comprobar el estado de los certificados. Este protocolo ofrece información
adicional sobre los certificados y realiza comprobaciones de estado periódicas.
Cuando un dispositivo de seguridad utiliza el protocolo OCSP, se le considera el

cliente OCSP (o solicitante). Dicho cliente envía una petición de verificación a un
servidor llamado servidor de respuesta OCSP. ScreenOS es compatible con RSA Keon
y Verisign como servidores de respuesta OCSP. La petición del cliente incluye la
identidad del certificado que se debe comprobar. Antes de que el dispositivo de
seguridad pueda realizar operaciones OCSP, debe configurarlo para que reconozca
la ubicación del servidor de respuesta OCSP.
Protocolo de estado de certificado en línea (OCSP) 35

NOTA: También hemos evaluado satisfactoriamente con el servidor de respuesta OCSP

Valicert durante un examen exhaustivo realizado hace tiempo.
Una vez recibida la petición, el servidor de respuesta OCSP confirma que la

información de estado del certificado está disponible y, a continuación, devuelve el
estado actual al dispositivo de seguridad. La respuesta del servidor OCSP contiene
el estado de revocación del certificado, el nombre del servidor de respuesta y el
periodo de validez de la respuesta. A menos que la respuesta sea un mensaje de
error, el servidor de respuesta firmará la respuesta utilizando su clave privada. El
dispositivo de seguridad verifica la validez de la firma del servidor de respuesta
utilizando su certificado. Este certificado del servidor de respuesta puede estar
incorporado en la respuesta OCSP o almacenado localmente y especificado en la
configuración de OCSP. Si el certificado está almacenado localmente, utilice el
siguiente comando para especificar el certificado almacenado localmente:
set pki authority núm_id1 cert-status ocsp cert-verify id núm_id2
núm_id1 identifica el certificado de CA que emitió el certificado que se va a

verificar; núm_id2 identifica el certificado almacenado localmente que el
dispositivo utiliza para verificar la firma en la respuesta OCSP.
Si el certificado del servidor de respuesta no está incorporado en la respuesta OCSP

o almacenado localmente, el dispositivo de seguridad verifica la firma utilizando el
certificado de la CA que emitió el certificado en cuestión.
Puede utilizar comandos CLI para configurar un dispositivo de seguridad para OCSP.
La mayoría de estos comandos utilizan un número de identificación para asociar la
URL de referencia de la revocación con el certificado de CA. Puede obtener este
número ID con el siguiente comando CLI:
get pki x509 list ca-cert
NOTA: El dispositivo de seguridad asigna de forma dinámica el número ID del certificado

de CA cuando se elabora la lista de certificados de CA. Este número puede
cambiar si se modifica el almacenamiento de certificados.
Especificación de un método de comprobación de revocación de certificados

Para especificar el método de comprobación de revocaciones (CRL, OCSP o
ninguno) para un certificado de una determinada CA, utilice la siguiente sintaxis en
CLI:
set pki authority núm_id cert-status revocation-check { CRL | OCSP | none }
donde núm_id será el número de identificación del certificado.
El siguiente ejemplo especifica la comprobación de revocaciones con OCSP:
set pki authority 3 cert-status revocation-check ocsp
El número de ID 3 identifica el certificado de la CA
36 Protocolo de estado de certificado en línea (OCSP)

Visualización de los atributos de comprobación de estado

Para visualizar los atributos de comprobación de estado de una CA determinada,
utilice la siguiente sintaxis en CLI:
get pki authority núm_id cert-status
donde núm_id será el número de identificación del certificado emitido por la

CA.
Para visualizar los atributos de comprobación de estado para la CA que emitió el

certificado 7:
get pki authority 7 cert-status
Especificación de una URL del servidor de respuesta del protocolo de estado de

certificado en línea
Para especificar la cadena de URL de un servidor de respuesta OCSP para un
certificado en particular, utilice la siguiente sintaxis en CLI:
set pki authority núm_id cert-status ocsp url cadena_url
Para especificar la cadena de URL de un servidor de respuesta OCSP

(http:\\192.168.10.10) para la CA con certificado 5, utilice la siguiente sintaxis en
CLI:
set pki authority 5 cert-status ocsp url http:\\192.168.10.10
Para eliminar la URL (http:\\192.168.2.1) de un servidor de CRL para el

certificado 5:
unset pki authority 5 cert-status ocsp url http:\\192.168.2.1
Eliminación de atributos de comprobación de estado

Para eliminar todos los atributos de comprobación de estado de una CA emisora de
un determinado certificado, utilice la siguiente sintaxis:
unset pki authority núm_id cert-status
Para eliminar todos los atributos de revocación relativos al certificado 1:
unset pki authority 1 cert-status
Protocolo de estado de certificado en línea (OCSP) 37

Certificados autofirmados
Un certificado autofirmado es un certificado firmado y emitido por la misma
entidad; es decir, el emisor y el sujeto del certificado coinciden. Por ejemplo, los
certificados CA de todas las autoridades de certificación raíz (CA) son autofirmados.
Los dispositivos de seguridad generan automáticamente un certificado autofirmado

al encenderse, si no hay ningún certificado ya configurado para Secure Sockets
Layer (SSL), como es el caso cuando se enciende por primera vez. El dispositivo de
seguridad que crea un certificado autogenerado y autofirmado es el único
dispositivo que lo utiliza. El dispositivo nunca exporta este certificado fuera de sí
mismo. Aunque el dispositivo de seguridad se encuentra en un clúster del protocolo
de redundancia de NetScreen (“NetScreen Redundancy Protocol” o NSRP), no
incluye el certificado autofirmado y autogenerado con otros tipos de certificados al
sincronizar objetos PKI con otros miembros del clúster. (Los miembros del NSRP
intercambian certificados autofirmados generados manualmente. Para obtener
información sobre la generación manual de certificados autofirmados, consulte
“Creación manual de certificados autofirmados” en la página 40).
Aunque no se pueden exportar certificados autofirmados y autogenerados, puede

copiar su nombre de sujeto y huella. A continuación, puede entregarlo a un
administrador remoto que más adelante podrá utilizar el nombre del sujeto y la
huella digital para verificar el certificado autofirmado recibido durante las
negociaciones SSL. Comprobar el nombre del sujeto y la huella digital es una
precaución importante contra los ataques por interposición de intrusos
(“man-in-the-middle attacks”), en los que alguien intercepta un intento de conexión
SSL y finge ser el dispositivo de seguridad de destino, respondiendo con su propio
certificado autofirmado. (Para obtener más información sobre la verificación de
certificados autofirmados, consulte “Validación de certificados” en la página 39).
Puede utilizar un certificado autofirmado al establecer una conexión Secure Sockets

Layer (SSL) con el dispositivo de seguridad. Si administra el dispositivo a través de
WebUI, SSL puede proporcionar autenticación y encriptación para asegurar su
tráfico administrativo. Puede incluso configurar un dispositivo de seguridad para
redirigir un intento de conexión administrativo utilizando HTTP (puerto
predeterminado 80) hacia SSL (puerto predeterminado 443).
NOTA: Para obtener más información sobre SSL, incluyendo el mecanismo de redirección
HTTP a SSL, consulte “Secure Sockets Layer” en la página 3-5.
De forma predeterminada, el dispositivo de seguridad pone a disposición el

certificado autofirmado y autogenerado para las negociaciones SSL. Es el certificado
SSL predeterminado. Si más adelante instala un certificado firmado por una CA o
configura el dispositivo de seguridad para que genere otro certificado autofirmado,
puede utilizar uno de estos otros certificados para SSL. Si elimina el certificado
autofirmado y autogenerado y no asigna otro certificado para su uso en SSL, el
dispositivo de seguridad genera automáticamente otro certificado autofirmado la
próxima vez que el dispositivo se reinicie.
38 Certificados autofirmados
NOTA: Para averiguar cómo crear otro certificado autofirmado, consulte “Creación
manual de certificados autofirmados” en la página 40. Para averiguar cómo
eliminar un certificado autofirmado y autogenerado, consulte “Eliminar
certificados autofirmados” en la página 46.
Validación de certificados
Durante el establecimiento de conexión SSL, el dispositivo de seguridad se
autentica enviando un certificado al cliente SSL. Cuando el dispositivo de seguridad
envía un certificado autofirmado, el cliente SSL no puede validarlo comprobando la
firma de la CA emisora porque no la publicó ninguna CA. Cuando el dispositivo de
seguridad presenta un certificado autofirmado para establecer una sesión SSL, el
explorador del equipo del administrador intenta validarlo con un certificado CA en
su almacén de CA (autoridades de certificación). Si no puede encontrar esa
autoridad, el explorador visualiza un mensaje como el que se muestra en la
Figura 16, pidiendo al administrador que acepte o rechace el certificado.
Figura 16: Alertas de seguridad para certificados autofirmados
Si esta es la primera vez que se conecta al dispositivo de seguridad después de su

arranque inicial, el reloj del sistema puede no estar en hora. Por lo tanto, el período
de validez indicado en el certificado también puede ser inexacto. Aunque ponga en
hora el reloj del sistema y regenere un certificado autofirmado, el explorador nunca
podrá encontrar una CA que lo autentique, por lo que el administrador debe estar
preparado para obtener uno de los mensajes antedichos cada vez que el dispositivo
de seguridad utilice un certificado autofirmado para una conexión SSL.
Sin poder recurrir a la validación del certificado por parte de una CA imparcial e
independiente, el administrador que inicie una sesión a través de SSL podría
preguntarse si el certificado autofirmado recibido realmente procede del dispositivo
de seguridad al que está intentando conectarse. (Después de todo, el certificado
podría ser un impostor que esté utilizando un ataque por interposición de intrusos
(man-in-the-middle attack) para intentar enmascararse como dispositivo de
seguridad). El administrador puede validar el certificado recibido utilizando el
nombre del sujeto y la huella digital del certificado autofirmado. Puede entregar el
nombre del sujeto y la huella digital al administrador para que pueda validar el
certificado autofirmado cuando el dispositivo de seguridad lo suministre más
adelante para autenticarse.
Certificados autofirmados 39
Para consultar el nombre del sujeto y la huella digital de un certificado autofirmado

y autogenerado, utilice el comando siguiente:
device-> get pki x509 cert system

...
CN=0043022002000186,CN=system generated,CN=self-signed,
...
finger print (md5) <e801eae4 56699fbc 324e38f2 4cfa5d47>
finger print (sha) <0113f5ec 6bd6d32b 4ef6ead9 f809eead 3a71435b>
NOTA: WebUI no permite visualizar los detalles de un certificado autofirmado y

autogenerado.
Después de ver el nombre del sujeto y la huella digital, puede copiarlos y

entregarlos (con el método seguro y “fuera de banda” que usted elija) al
administrador que posteriormente se conectará al dispositivo de seguridad a través
de SSL. Cuando el cliente SSL del administrador reciba el certificado desde el
dispositivo de seguridad durante el establecimiento de conexión SSL, podrá
comparar el nombre del sujeto y la huella digital del certificado recibido con los
recibidos anteriormente “fuera de banda”. Si coinciden, sabrá que el certificado es
auténtico. Dada la ausencia de una autoridad CA de confianza para autenticar el
certificado, sin nombre de sujeto y huella digital que comparar, el administrador
remoto no puede saber con certeza si el certificado es genuino.
Creación manual de certificados autofirmados

El dispositivo de seguridad genera automáticamente un certificado autofirmado la
primera vez que se enciende, con el fin de admitir SSL durante la conexión inicial.
Sin embargo, puede que desee generar un certificado autofirmado distinto del que
genera automáticamente el dispositivo de seguridad. Éstas son algunas razones
posibles para reemplazar el certificado autofirmado y autogenerado por un
certificado autofirmado y definido por el administrador:
El certificado autofirmado y autogenerado utiliza un tamaño de clave fijo de

1024 bits. Dependiendo de sus necesidades, puede necesitar claves con un
tamaño mayor o menor, que puede controlar al generar su propia clave
autofirmada.
Puede que desee utilizar un certificado con un nombre de sujeto distinto del
creado automáticamente.
Puede necesitar varios certificados autofirmados. En los dispositivos de

seguridad que admiten sistemas virtuales, el sistema raíz puede compartir el
certificado autofirmado y autogenerado con todos los sistemas virtuales. Sin
embargo, los administradores de vsys pueden preferir generar sus propios
certificados autofirmados y, a continuación, exigir a sus administradores que
comprueben el nombre del sujeto y la huella digital de estos certificados
específicos en lugar de los atributos de un certificado compartido.
NOTA: A diferencia de un certificado autofirmado y autogenerado, que nunca sale del

dispositivo en el cual se crea, un certificado autofirmado y generado
manualmente se incluye con otros certificados cuando un dispositivo de seguridad
de un clúster NSRP sincroniza objetos PKI con otros miembros del clúster.
Aunque puede configurar varios componentes de un certificado autofirmado (como

los campos de nombres distinguidos (“distinguished name” o DN), el nombre
alternativo del sujeto y el tamaño de la clave), los siguientes elementos de nombres
comunes (“common name” o CN) siempre aparecen al final del DN:
“CN = núm_serie_disp, CN = NetScreen self-signed”
Aunque el principal uso previsto de un certificado autofirmado es permitir que un

dispositivo de seguridad pueda establecer inmediatamente conexiones Secure
Sockets Layer (SSL), este certificado se puede utilizar igual que cualquier otro
certificado firmado por una CA. Las aplicaciones de un certificado autofirmado
pueden ser las siguientes:
Establecer una conexión Secure Sockets Layer (SSL) para proteger el tráfico
administrativo hacia un dispositivo de seguridad
Asegurar el tráfico entre NetScreen-Security Manager (NSM) y un dispositivo de

seguridad
Autenticar interlocutores IKE al establecer túneles VPN
NOTA: Para la versión actual de ScreenOS, solamente admitimos certificados

autofirmados para su uso con SSL.
Establecimiento de un certificado autofirmado y definido por el administrador

En este ejemplo, definirá los siguientes componentes de un certificado autofirmado
para su uso con SSL:
Distinguished Name/Subject Name:
Name: 4ssl
Organization: jnpr
FQDN: www.juniper.net
Key type and length: RSA, 1024 bits
Después de definirlo, generará el certificado y lo visualizará. A continuación, podrá

copiar el nombre del sujeto y la huella digital (también denominados “thumbprint”)
para su distribución a otros administradores que inicien una sesión a través de SSL
para administrar el dispositivo de seguridad.
Cuando un administrador intente iniciar una sesión con SSL, el dispositivo de

seguridad le enviará este certificado. Cuando lo reciba, podrá abrirlo y comparar el
nombre del sujeto y la huella digital que aparecen en el certificado con la
información que recibió previamente. Si coinciden, sabrá que el certificado es
auténtico.
WebUI
1. Definir los atributos del certificado
en Generate:
Certificate Subject Information:

Name: 4ssl
Organization: jnpr
FQDN: www.juniper.net
Key Pair Information:
RSA: (seleccione)
Create new key pair of 1024 length.
2. Generar el certificado autofirmado
Cuando el dispositivo de seguridad ha completado la generación de la clave,
compone una petición de certificado. Haga clic en Generate Self-Signed Cert.
3. Ver el certificado autofirmado

Objects > Certificates > Show Local: Haga clic en Detail para ver el certificado
recién creado.
La página de detalles de certificados aparece, como se muestra en la Figura 17.
Figura 17: Detalles del certificado:
Puede copiar el nombre del sujeto y la huella digital desde esta página y
comunicarlos a otros administradores que pretendan utilizar SSL al administrar el
dispositivo de seguridad. Cuando inicien una conexión SSL, podrán utilizar esta
información para asegurarse de que el certificado que reciben procede, de hecho,
del dispositivo de seguridad.
CLI
1. Definir los atributos del certificado
set pki x509 dn name 4ssl
set pki x509 dn org-name jnpr
set pki x509 cert-fqdn www.juniper.net
save
2. Generar el certificado autofirmado

Para generar un par de claves pública/privada que el dispositivo de seguridad
de Juniper Networks utilizará en sus peticiones de certificados, ejecute el
comando siguiente:
exec pki rsa new-key 1024
Después de que el dispositivo de seguridad genere un par de claves, compondrá la

petición de certificado siguiente:
-----BEGIN CERTIFICATE REQUEST-----

MIIB0jCCATsCAQAwZTENMAsGA1UEChMESk5QUjEZMBcGA1UEAxMQMDA0MzAyMj
Aw
MjAwMDE4NjEQMA4GA1UEAxMHcnNhLWtleTEYMBYGA1UEAxMPd3d3Lmp1bmlwZ
XIu
bmV0MQ0wCwYDVQQDEwQ1c3NsMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQK
BgQDP
aAtelkL4HxQmO1w1jv9NMmrWnzdVYnGrKrXnw2MaB3xEgouWrlymEkZetA2ouKeA
D24SL0h1YvJ7Sd9PvkhwHOnvP1zkOCWA84TgvxBzcAyeBnS1UpSwcC0admX0Da6
T
80EUuGrmUWodddRFUc8o5d2VGTUOM7WgcFDZRSGQGwIDAQABoC0wKwYJKoZIh
vcN
AQkOMR4wHDAaBgNVHREEEzARgg93d3cuanVuaXBlci5uZXQwDQYJKoZIhvcNAQEF
BQADgYEAgvDXI4H905y/2+k4omo9Y4XQrgq44Rj3jqXAYYMgQBd0Q8HoyL5NE3+i
QUkiYjMTWO2wIWzEr4u/tdAISEVTu03achZa3zIkUtn8sD/VYKhFlyPCBVvMiaHd
FzIHUgBuMrr+awowJDG6wARhR75w7pORXy7+aAmvIjew8YRre9s=
-----END CERTIFICATE REQUEST-----
Para conocer el número de identificación del par de claves, utilice el comando

siguiente:
get pki x509 list key-pair
Getting OTHER PKI OBJECT ...

IDX ID num X509 Certificate Subject Distinguish Name
========================================================
0000 176095259
CN=4ssl,CN=www.juniper.net,CN=rsa-key,CN=0043022002000186,
O=jnpr,
========================================================
Para generar el certificado autofirmado, ejecute el comando siguiente, haciendo

referencia al número de identificación del par de claves que vio en el resultado del
comando anterior:
exec pki x509 self-signed-cert key-pair 176095259
3. Ver el certificado autofirmado

Para ver el certificado autofirmado recién creado, ejecute el comando siguiente:
get pki x509 list local-cert
Getting LOCAL CERT ...

IDX ID num X509 Certificate Subject Distinguish Name
========================================================
0000 176095261 LOCAL CERT friendly name <29>
LOCAL CERT friendly name <29>
CN=self-signed,CN=4ssl,CN=www.juniper.net,CN=rsa-key,CN=004302200200
0186,
O=jnpr,
Expire on 10-19-2009 17:20, Issued By:
0186,
O=jnpr,
========================================================
Para ver el certificado más detalladamente, ejecute el comando siguiente usando el

número de identificación del certificado:
get pki x509 cert 176095261

-0001 176095261 LOCAL CERT friendly name <29>
000186,
O=jnpr,
Expire on 10-19-2009 17:20, Issued By:
0186,
O=jnpr,
Serial Number: <9d1c03365a5caa172ace4f82bb5ec9da>
subject alt name extension:
email(1): (empty)
fqdn(2): (www.juniper.net)
ipaddr(7): (empty)
no renew
finger print (md5) <be9e0280 02bdd9d1 175caf23 6345198e>
finger print (sha) <87e0eee0 c06f9bac 9098bd02 0e631c1b 26e37e0e>
subject name hash: <d82be8ae 4e71a576 2e3f06fc a98319a3 5c8c6c27>
use count: <1>
flag <00000000>
Puede copiar el nombre del sujeto subject name y la huella digital fingerprint
desde esta página y comunicarlos a otros administradores que pretendan utilizar
SSL para administrar el dispositivo de seguridad. Cuando inicien una conexión SSL,
podrán utilizar esta información para asegurarse de que el certificado que reciben
procede, de hecho, del dispositivo de seguridad.
Autogeneración de certificados
La primera vez que se encienda el dispositivo de seguridad, generará
automáticamente un certificado autofirmado. El principal propósito de este
certificado es reconocer inmediatamente SSL después del arranque inicial de un
dispositivo de seguridad. Para ver este certificado, utilice el comando CLI siguiente:
get pki x509 cert system

Expire on 08- 3-2014 16:19, Issued By:
Serial Number: <c927f2044ee0cf8dc931cdb1fc363119>
finger print (md5) <fd591375 83798574 88b3e698 62890b5d>
finger print (sha) <40a1bda8 dcd628fe e9deaee1 92a2783c 817e26d9>
subject name hash: <0324d38d 52f814fe 647aba3a 86eda7d4 a7834581>
De forma predeterminada, el dispositivo de seguridad genera automáticamente un

certificado autofirmado durante el proceso de arranque si se cumplen las
condiciones siguientes:
En el dispositivo no existe ningún certificado autofirmado generado

automáticamente.
No se ha asignado ningún certificado para su uso con SSL.
Puede utilizar el comando siguiente para consultar si ya hay configurado un

certificado para SSL:
get ssl
web SSL enable.
web SSL port number(443).
web SSL cert: Default - System Self-Signed Cert.
web SSL cipher(RC4_MD5).
En el resultado anterior, puede ver que SSL está utilizando el certificado

autofirmado y generado automáticamente (“System”).
La Figura 18 muestra la ruta de decisiones que el dispositivo de seguridad toma al

encenderse para la generación de certificados.
Figura 18: Ruta de decisiones para la autogeneración de certificados

Empieza
Proceso de
arranque
¿Existe un
cert generado
automáticamente y Sí
autofirmado?
Sí
No generar
automáticamente
¿Existe Cert un certificado
para Sí
autofirmado.
SSL?
No
Generar automáticamente un
certificado autofirmado.
Si elimina el certificado autofirmado y generado automáticamente, asigne otro

certificado para su uso con SSL y restablezca el dispositivo; el dispositivo de
seguridad no generará otro certificado autofirmado durante el proceso de arranque.
Si a continuación cambia la configuración de SSL para que no se asigne ningún
certificado y luego restablece el dispositivo, el dispositivo de seguridad generará
automáticamente un nuevo certificado autofirmado durante el siguiente proceso de
arranque.
Eliminar certificados autofirmados

Puede eliminar un certificado autofirmado generado de forma automática o
manual, igual que se puede con cualquier tipo de certificado. Puede que disponga
de un certificado firmado por una CA que prefiera utilizar para SSL en lugar de un
certificado autofirmado. Sea cual sea el motivo para eliminar el certificado
autofirmado y autogenerado, utilice el comando CLI siguiente:
delete pki object-id system
Para eliminar un certificado autofirmado y configurado por el administrador, utilice

el comando siguiente, donde núm_id es el número de identificación del certificado
que desea eliminar:
delete pki object-id núm_id
Si elimina el certificado autofirmado y autogenerado y más adelante desea que el

dispositivo de seguridad genere otro, haga lo siguiente:
No asigne ningún otro certificado para SSL (puede utilizar el comando

siguiente: unset ssl cert).
Restablezca el dispositivo de seguridad.
El dispositivo de seguridad puede redirigir el tráfico HTTP (puerto predeterminado

80) enviado al dispositivo mismo hacia SSL (puerto predeterminado 443). Por lo
tanto, para asegurarse de que un certificado esté disponible para SSL, durante el
proceso de arranque el dispositivo de seguridad siempre comprueba si existe un
certificado autofirmado y autogenerado o si se ha asignado a SSL otro certificado. Si
no hay ningún certificado autofirmado y autogenerado y no se asigna ningún otro
certificado para su uso con SSL, el dispositivo de seguridad genera
automáticamente un certificado autofirmado.
NOTA: Sólo CLI permite eliminar certificados autofirmados generados automáticamente.
Para averiguar el número de identificación de un certificado, utilice el comando

siguiente: get pki x509 list local-cert.
Para obtener información sobre la redirección del tráfico HTTP a SSL, consulte
“Redireccionamiento de HTTP a SSL” en la página 3-8.
Capítulo 3
Directrices para las redes privadas
virtuales
ScreenOS ofrece una variedad de opciones criptográficas para configurar un túnel

de red privada virtual (VPN). Incluso para configurar un túnel simple es necesario
elegir entre varias opciones. Los objetivos de la primera mitad de este capítulo son
primero resumir todas las opciones disponibles para una VPN punto a punto básica
y una VPN de acceso telefónico básica, y después ofrecer uno o más motivos para
elegir una opción u otra.
La segunda mitad del capítulo examina las diferencias que existen entre los túneles
VPN basados en rutas y los túneles VPN basados en directivas. También revisa el
flujo de paquetes de un túnel VPN AutoKey IKE punto a punto basado en directivas
y basado en rutas para ver las etapas de procesamiento de entrada y salida por las
que pasa un paquete. El capítulo concluye con algunos consejos de configuración
VPN que hay que tener en cuenta a la hora de configurar un túnel.
“Opciones criptográficas” en la página 50
“Opciones criptográficas punto a punto” en la página 50
“Opciones VPN de acceso telefónico” en la página 57
“Túneles basados en directivas y en rutas” en la página 64
“Flujo de paquetes: VPN punto a punto” en la página 66
“Directrices para la configuración de túneles” en la página 72
“Consideraciones sobre seguridad en redes privadas virtuales basadas en rutas”

en la página 74
“Ruta Null” en la página 74
“Línea de acceso telefónico o arrendada” en la página 76
“Conmutación por error de la VPN hacia la línea arrendada o la ruta Null”

en la página 77
“Interfaz Tunnel ficticia” en la página 79
49
“Enrutador virtual para interfaces Tunnel” en la página 80
“Reenrutamiento a otro túnel” en la página 80
Opciones criptográficas
Durante la configuración de una VPN es necesario tomar numerosas decisiones
sobre la criptografía que se desea utilizar. Surgirán preguntas sobre cuál es el grupo
Diffie-Hellman adecuado, qué algoritmo de encriptación ofrece el mejor equilibrio
entre seguridad y rendimiento, etc. En esta sección se presentan todas las opciones
criptográficas requeridas para configurar un túnel VPN punto a punto básico y un
túnel VPN de acceso telefónico básico. También se indican una o más ventajas de
cada opción para ayudarle a tomar una decisión.
La primera decisión que hay que tomar es si se va a optar por un túnel VPN punto a
punto (entre dos dispositivos de seguridad) o por un túnel VPN de acceso telefónico
(desde el cliente VPN NetScreen-Remote hasta el dispositivo de seguridad). Aunque
esta decisión depende de la configuración de red, las diferencias entre estos dos
tipos de túneles afectan a algunas opciones criptográficas. Por lo tanto, las opciones
se presentan en dos figuras distintas:
“Opciones criptográficas punto a punto”, descritas en la Figura 19, “Opciones

criptográficas para un túnel VPN punto a punto,” en la página 51.
“Opciones VPN de acceso telefónico”, descritas en la Figura 20, “Opciones

criptográficas para un túnel VPN de acceso telefónico,” en la página 58.
Cuando haya decidido qué tipo de túnel desea configurar (de acceso telefónico o
punto a punto), consulte la Figura 19 o la Figura 20 para obtener las indicaciones
oportunas. En cada figura se presentan las decisiones criptográficas que deberá
tomar durante la configuración del túnel. A continuación, se señalan los motivos
que justifican la elección de cada opción de la figura.
NOTA: En el Capítulo 4, “Redes privadas virtuales de punto a punto,” y en el Capítulo 5,

“Redes privadas virtuales de acceso telefónico.”, se incluyen ejemplos de
configuración de ambos tipos de túneles.
Opciones criptográficas punto a punto

Durante la configuración de un túnel VPN punto a punto básico, deberá seleccionar
entre las opciones criptográficas que se muestran en la Figura 19. A continuación
de la figura, se indican las ventajas de cada opción.
NOTA: La Figura 19 en la página 51 muestra las opciones que se recomiendan en negrita.

Para obtener información sobre las distintas opciones IPSec, consulte “Seguridad
del protocolo de Internet” en la página 1.
50 Opciones criptográficas
Capítulo 3: Directrices para las redes privadas virtuales
Figura 19: Opciones criptográficas para un túnel VPN punto a punto

1. Método de administración de claves: Clave manual o AutoKey IKE
AutoKey IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o bien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clave manual
2. Modo:
Dinámico o principal
3. Tipo de autenticación: 6. Grupo Diffie-Hellman 13. Protocolo IPSec:

Certificados o clave previamente Grupo: 1, 2 ó 5 ESP. . . . . . . . o bien. . . . . . . . AH
compartida
14. Modo:
4. Tipo de certificado: Túnel o transporte
RSA o DSA 7. Encriptación IKE y
algoritmos de autenticación:
5. Longitud de bits: AES, DES o 3DES 15. Opciones ESP:
512 ó 768 y Encriptación, autenticación y encriptación o
ó 1024 ó 2048 MD5 o SHA-1
16. Algoritmos de encriptación: 17. Algoritmos de
AES, DES ó 3DES autenticación:
8. ID IKE local: 9. ID IKE remota: MD5 o SHA-1
10. Contra reprocesamiento
Dirección IP o U-FQDN Dirección IP o U-FQDN de paquetes:
o FQDN o ASN1-DN o FQDN o ASN1-DN
11. Confidencialidad directa perfecta:
Sí o No
12. Grupo Diffie-Hellman IPSec:

1, 2 o 5
Fase 1--puerta de enlace IKE Fase 2--túnel VPN
1. Método de administración de claves: Clave manual o AutoKey IKE

AutoKey IKE
Recomendado.
Ofrece una renovación de claves automática, con lo que aumenta la seguridad.
Clave manual
Resulta útil para depurar problemas IKE.
Elimina los retardos de negociación IKE a la hora de establecer un túnel.
2. Modo: Dinámico o principal

Dinámico
Es necesario cuando la dirección IP de uno de los interlocutores IPSec está asignada
de forma dinámica y si se utiliza una clave previamente compartida
Principal
Recomendado.
Ofrece protección de identidad.
Se puede utilizar cuando el usuario de acceso telefónico posee una dirección IP

estática o si se utilizan certificados para la autenticación.
Opciones criptográficas 51
3. Tipo de autenticación: clave previamente compartida o certificados

Certificados
Recomendado
Ofrece mayor seguridad que las claves previamente compartidas porque es

posible validar los certificados a través de una autoridad de certificación (CA).
(Para obtener más información, consulte “Criptografía de claves públicas” en la
página 19).

Es más fácil de manejar y más rápida de configurar, porque no requiere una
infraestructura de claves públicas (PKI).
4. Tipo de certificado: RSA o DSA

Depende de la CA de la que se obtengan los certificados. Ningún tipo de certificado
presenta ventajas en comparación con el otro.
5. Longitud de bits: 512, 768, 1024 ó 2048

512
Su gasto de procesamiento es el más bajo.
768
Ofrece más seguridad que la opción de 512 bits.
Su gasto de procesamiento es inferior al de las opciones de 1024 y 2048 bits.
1024
Recomendado
Ofrece más seguridad que las opciones de 512 y 768 bits.
Su gasto de procesamiento es inferior al de la opción de 2048 bits.
2048
Ofrece la máxima seguridad.
6. Grupo Diffie-Hellman IKE: 1, 2 ó 5

Grupo de Diffie-Hellman 1
Su gasto de procesamiento es inferior al de los grupos Diffie-Hellman 2 y 5
Aceleración de procesamiento proporcionada por el hardware de seguridad de

Juniper Networks
Recomendado
Su gasto de procesamiento es inferior al del grupo Diffie-Hellman 5
Ofrece más seguridad que el grupo Diffie-Hellman 1

Juniper Networks
Ofrece la máxima seguridad
7. Algoritmos de autenticación y encriptación IKE: AES, DES o 3DES y MD5 o SHA-1

AES
Recomendado
Tiene un mayor nivel de encriptación que DES y 3DES si las longitudes de clave
son iguales

Juniper Networks
Algoritmo de encriptación aprobado para las normas federales para

procesamiento de la información (FIPS, o “Federal Information Processing
Standards”) y los criterios comunes de EAL4
DES
Su gasto de procesamiento es inferior al de 3DES y AES.
Resulta útil cuando el interlocutor remoto no admite AES.
3DES
Ofrece más seguridad criptográfica que DES.

Juniper Networks
MD5
Su gasto de procesamiento es inferior al de SHA-1.
SHA-1
Recomendado
Ofrece más seguridad criptográfica que MD5.
Es el único algoritmo de autenticación que admiten las normas FIPS.
8. ID IKE local: dirección IP (valor predeterminado), o bien U-FQDN, FQDN o ASN1-DN

Dirección IP
Recomendado.
Sólo se puede utilizar si el dispositivo de seguridad local tiene una dirección IP

estática.
Es la ID IKE predeterminada cuando se utiliza una clave previamente

compartida para la autenticación.
Se puede utilizar con un certificado si la dirección IP aparece en el campo

SubjectAltName.
U-FQDN
Nombre de dominio completo de usuario (U-FQDN, una dirección de correo
electrónico): se puede utilizar con una clave previamente compartida o un
certificado si el U-FQDN aparece en el campo SubjectAltName.
FQDN
Nombre de dominio completo (FQDN): se puede utilizar con una clave
previamente compartida o un certificado si el FQDN aparece en el campo
SubjectAltName.
Resulta útil para puertas de enlace VPN que tengan direcciones IP dinámicas.
Es la ID IKE predeterminada cuando se utilizan certificados RSA o DSA para la

autenticación.
ASN1-DN
Sólo se puede utilizar con certificados.
Resulta útil si la CA no admite el campo SubjectAltName en los certificados que

emite.
9. ID IKE remota: dirección IP (valor predeterminado), o bien U-FQDN, FQDN o ASN1-DN

Dirección IP
Recomendado.
No requiere la introducción de una ID IKE remota para un interlocutor con

dirección IP estática cuando se utilizan claves previamente compartidas para la
autenticación y el interlocutor es un dispositivo de seguridad.
Se puede utilizar para un dispositivo con dirección IP estática.
Se puede utilizar con una clave previamente compartida o un certificado si la

dirección IP aparece en el campo SubjectAltName.
U-FQDN
certificado si el U-FQDN aparece en el campo SubjectAltName.
FQDN
SubjectAltName.
No requiere la introducción de una ID IKE remota cuando se utilizan

certificados para la autenticación y el interlocutor es un dispositivo de
seguridad.
ASN1-DN

emite.
10. Comprobación contra reprocesamiento de paquetes: Sí o no

Sí
Recomendado
Permite al destinatario comprobar los números de secuencia de los

encabezados de paquetes para prevenir ataques de denegación de servicio
(DoS) provocados cuando un atacante reenvía paquetes IPSec interceptados.
No
Desactivar esta opción tal vez sea la solución a problemas de compatibilidad con
interlocutores de terceros.
11. Confidencialidad directa perfecta: Sí o no

Sí
Recomendado
Confidencialidad directa perfecta (PFS): ofrece una mayor seguridad porque los
interlocutores realizan un segundo intercambio Diffie-Hellman para generar la
clave utilizada para la encriptación/desencriptación IPSec.
No
Agiliza la configuración del túnel.
Reduce el procesamiento durante las negociaciones IPSec de fase 2.
12. Grupo Diffie-Hellman IPSec: 1, 2 ó 5

Su gasto de procesamiento es inferior al de los grupos Diffie-Hellman 2 y 5.

Juniper Networks.
Recomendado

Juniper Networks
Ofrece la máxima seguridad.
13. Protocolo IPSec: ESP o AH

ESP
Recomendado
Carga de seguridad encapsulada (ESP): puede ofrecer confidencialidad

mediante encriptación y encapsulado del paquete IP original e integridad
mediante autenticación
Puede proporcionar sólo encriptación o sólo autenticación
AH
Encabezado de autenticación (AH): ofrece autenticación del paquete IP completo,
incluyendo el encabezado IPSec y el encabezado IP externo
14. Modo: túnel o transporte

Túnel
Recomendado
Oculta el encabezado IP original, con lo que aumenta la privacidad
Transporte
Es necesario para el soporte del túnel L2TP sobre IPSec
15. Opciones ESP: sólo encriptación, sólo autenticación o encriptación y autenticación

Encriptación
Ofrece un rendimiento más rápido y su gasto de procesamiento es inferior al de
la opción de encriptación y autenticación
Resulta útil cuando se requiere confidencialidad, pero no autenticación
Encriptación y autenticación
Recomendado
Resulta útil si se desea obtener confidencialidad y autenticación
Autenticación
Resulta útil cuando se requiere autenticación, pero no confidencialidad. Por
ejemplo, cuando la información no es secreta, pero es importante determinar que
procede realmente de la persona que dice enviarlo y que nadie ha manipulado el
contenido durante la transmisión.
16. Algoritmos de encriptación: AES, DES o 3DES

AES
Recomendado
son iguales

Juniper Networks
Algoritmo de encriptación aprobado para normas FIPS y criterios comunes

EAL4
DES
Su gasto de procesamiento es inferior al de 3DES y AES
Resulta útil cuando el interlocutor remoto no admite AES
3DES
Ofrece más seguridad criptográfica que DES

Juniper Networks
17. Algoritmos de autenticación: MD5 o SHA-1

MD5
Su gasto de procesamiento es inferior al de SHA-1
SHA-1
Recomendado
Ofrece más seguridad criptográfica que MD5
Si se utilizan las opciones recomendadas de la lista anterior, una configuración VPN

punto a punto genérica entre dos dispositivos de seguridad con direcciones IP
estáticas estaría formada por los siguientes componentes:
AutoKey IKE Confidencialidad directa perfecta (PFS) = sí
Modo principal Grupo Diffie-Hellman 2 para fase 2
Certificados de 1024 bits (RSA o DSA) Carga de seguridad encapsulada (ESP)
Grupo Diffie-Hellman 2 para fase 1 Modo de túnel
Encriptación = AES Encriptación y autenticación
Autenticación = SHA-1 Encriptación = AES
ID IKE = dirección IP (valor Autenticación = SHA-1

predeterminado)
Protección contra reprocesamiento de
paquetes = sí
Opciones VPN de acceso telefónico

Durante la configuración de un túnel VPN de acceso telefónico básico, deberá
seleccionar entre las opciones criptográficas que se muestran en la Figura 20.
A continuación de la figura, se indican las ventajas de cada opción.
NOTA: La Figura 20 muestra las opciones que se recomiendan en negrita. Para obtener
información sobre las distintas opciones IPSec, consulte el “Seguridad del
protocolo de Internet” en la página 1.
Figura 20: Opciones criptográficas para un túnel VPN de acceso telefónico

Método de administración de claves = AutoKey IKE
1. Modo:
Dinámico o principal
2. Tipo de autenticación: 5. IKE Diffie-Hellman 12. Protocolo IPSec:

Certificados o clave previamente Grupo: 1, 2 ó 5 ESP. . . . . . . . o bien. . . . . . . . AH
compartida
13. Modo:
3. Tipo de certificado: Túnel o transporte
RSA o DSA 6. Encriptación IKE y
algoritmos de autenticación: 14. Opciones ESP:
4. Longitud de bits: AES, DES o 3DES Encriptación, encriptación y
512 ó 768 y autorización o autorización
ó 1024 ó 2048 MD5 o SHA-1
15. Algoritmos de encriptación: 16. Algoritmos de autenticación:
AES, DES ó 3DES MD5 o SHA-1
7. ID IKE local: 8. ID IKE remota:
Dirección IP (valor predeterminado) o Dirección IP (valor predeterminado) o 9. Comprobación contra
U-FQDN, FQDN o ASN1-DN U-FQDN, FQDN o ASN1-DN reprocesamiento: Sí o No
10. Confidencialidad directa perfecta:

Sí o No
11. Grupo Diffie-Hellman IPSec:

1, 2 o 5
Fase 1--puerta de enlace IKE Fase 2--túnel VPN
1. Modo: Dinámico o principal

Dinámico
Recomendado
Es necesario cuando la dirección IP de uno de los interlocutores IPSec está

asignada de forma dinámica y si se utiliza una clave previamente compartida
Se puede utilizar con certificados o claves previamente compartidas para la

autenticación
Principal
Ofrece protección de identidad
2. Tipo de autenticación: clave previamente compartida o certificados

Certificados
Recomendado
Ofrece mayor seguridad que las claves previamente compartidas porque es

posible validar los certificados a través de una autoridad de certificación (CA).
(Para obtener más información, consulte “Criptografía de claves públicas” en la
página 19)

Es más fácil de manejar y más rápida de configurar, porque no requiere una
infraestructura de claves públicas (PKI)
3. Tipo de certificado: RSA o DSA

Depende de la CA de la que se obtengan los certificados. Ningún tipo de certificado
presenta ventajas en comparación con el otro.
4. Longitud de bits: 512, 768, 1024 ó 2048

512
Su gasto de procesamiento es el más bajo.
768
Ofrece más seguridad que la opción de 512 bits.
Su gasto de procesamiento es inferior al de las opciones de 1024 y 2048 bits.
1024
Recomendado
Ofrece más seguridad que las opciones de 512 y 768 bits
Su gasto de procesamiento es inferior al de la opción de 2048 bits
2048
5. Grupo Diffie-Hellman IKE: 1, 2 ó 5


Juniper Networks
Recomendado

Juniper Networks
6. Algoritmos de autenticación y encriptación IKE: AES, DES o 3DES y MD5 o SHA-1?

AES
Recomendado
son iguales

Juniper Networks

EAL4
DES
Su gasto de procesamiento es inferior al de 3DES y AES
Resulta útil cuando el interlocutor remoto no admite AES
3DES

Juniper Networks
MD5
SHA-1
Recomendado
7. ID IKE local: dirección IP (valor predeterminado), o bien U-FQDN, FQDN o ASN1-DN

Dirección IP (valor predeterminado)
No requiere la introducción de una ID IKE para un dispositivo con dirección IP
estática.

U-FQDN
Recomendado

certificado si el U-FQDN aparece en el campo SubjectAltName
FQDN
SubjectAltName.
ASN1-DN

emite.
8. ID IKE remota: dirección IP (valor predeterminado), o bien U-FQDN, FQDN o ASN1-DN

Dirección IP (valor predeterminado)
No requiere la introducción de una ID IKE para un dispositivo con dirección IP
estática.

U-FQDN
Recomendado

certificado si el U-FQDN aparece en el campo SubjectAltName
FQDN
SubjectAltName.
ASN1-DN

emite.
9. Comprobación contra reprocesamiento de paquetes: Sí o no?

Sí
Recomendado
Permite al destinatario comprobar los números de secuencia de los

encabezados de paquetes para prevenir ataques de denegación de servicio
(DoS) provocados cuando un atacante reenvía paquetes IPSec interceptados
No
Desactivar esta opción tal vez sea la solución a problemas de compatibilidad con
interlocutores de terceros
10. Confidencialidad directa perfecta: Sí o no?

Sí
Recomendado
Confidencialidad directa perfecta (PFS): ofrece una mayor seguridad porque los
interlocutores realizan un segundo intercambio Diffie-Hellman para generar la
clave utilizada para la encriptación/desencriptación IPSec
No
Agiliza la configuración del túnel.
Reduce el procesamiento durante las negociaciones IPSec de fase 2.
11. Grupo Diffie-Hellman IPSec: 1, 2 ó 5


Juniper Networks
Recomendado.
Su gasto de procesamiento es inferior al del grupo Diffie-Hellman 5.
Ofrece más seguridad que el grupo Diffie-Hellman 1.

Juniper Networks.
12. Protocolo IPSec: ESP o AH

ESP
Recomendado
Carga de seguridad encapsulada (ESP): puede ofrecer confidencialidad

mediante encriptación y encapsulado del paquete IP original e integridad
mediante autenticación
Puede proporcionar sólo encriptación o sólo autenticación
AH
Encabezado de autenticación (AH): ofrece autenticación del paquete IP completo,
incluyendo el encabezado IPSec y el encabezado IP externo
13. Modo: túnel o transporte

Túnel
Recomendado
Oculta el encabezado IP original, con lo que aumenta la privacidad
Transporte
Es necesario para el soporte del túnel L2TP sobre IPSec
14. Opciones ESP: sólo encriptación, sólo autenticación o encriptación y autenticación

Encriptación
Ofrece un rendimiento más rápido y su gasto de procesamiento es inferior al de
la opción de encriptación y autenticación.
Resulta útil cuando se requiere confidencialidad, pero no autenticación.
Encriptación y autenticación
Recomendado
Resulta útil si se desea obtener confidencialidad y autenticación
Autenticación
Resulta útil cuando se requiere autenticación, pero no confidencialidad. Por
ejemplo, cuando la información no es secreta, pero es importante determinar que
procede realmente de la persona que dice enviarlo y que nadie ha manipulado el
contenido durante la transmisión.
15. Algoritmos de encriptación: AES, DES o 3DES

AES
Recomendado
son iguales

Juniper Networks

EAL4
DES
Su gasto de procesamiento es inferior al de 3DES y AES.
Resulta útil cuando el interlocutor remoto no admite AES.
3DES

Juniper Networks
16. Algoritmos de autenticación: MD5 o SHA-1

MD5
SHA-1
Recomendado
Si se utilizan las opciones recomendadas de la lista anterior, una configuración VPN

de acceso telefónico genérica entre dos dispositivos de seguridad con direcciones IP
estáticas estaría formada por los siguientes componentes:
Modo dinámico Confidencialidad directa perfecta (PFS) = sí
Certificados de 1024 bits (RSA o DSA) Grupo Diffie-Hellman 2 para fase 2
Grupo Diffie-Hellman 2 para fase 1 Carga de seguridad encapsulada (ESP)
Encriptación = AES Modo de túnel
Autenticación = SHA-1 Encriptación y autenticación
ID IKE = U-FQDN (dirección de correo Encriptación = AES

electrónico)
Protección contra reprocesamiento de Autenticación = SHA-1
paquetes = sí
Túneles basados en directivas y en rutas

La configuración de un dispositivo de seguridad para el soporte VPN es
particularmente flexible. Es posible crear túneles VPN basados en directivas y
basados en rutas. Además, en cada tipo de túnel se puede utilizar clave manual o
AutoKey IKE para administrar las claves utilizadas para la encriptación y la
autenticación.
En el caso de los túneles VPN basados en directivas, un túnel se gestiona como un

objeto (o un bloque de construcción) que, junto con el origen, el destino, el servicio
y la acción, comprende una directiva que permite el tráfico VPN. (En realidad, la
acción de directiva VPN es tunnel, pero la acción permit está implícita si no se
especifica). En una configuración VPN basada en directivas, una directiva hace
referencia de forma específica a un túnel VPN por su nombre.
En las VPN basadas en rutas, la directiva no hace referencia de forma específica al

túnel VPN. En su lugar, la directiva hace referencia a una dirección de destino.
Cuando el dispositivo de seguridad realice una consulta de ruta para averiguar la
interfaz a través de la que debe enviar el tráfico para alcanzar esa dirección,
encontrará una ruta a través de una interfaz Tunnel, que estará asociada a un túnel
VPN específico.
NOTA: Normalmente, una interfaz Tunnel está asociada a un solo túnel. No obstante,
también es posible asociar una interfaz Tunnel a varios túneles. Para obtener más
información, consulte “Múltiples túneles por interfaz de túnel” en la página 263.
Por lo tanto, con un túnel VPN basado en directivas, un túnel se puede considerar
como un elemento en la construcción de una directiva. Con un túnel VPN basado
en rutas, un túnel se puede considerar como un medio para entregar tráfico, y la
directiva se puede considerar como un método para permitir o denegar la entrega
de dicho tráfico.
64 Túneles basados en directivas y en rutas

El número de túneles VPN basados en directivas que se puede crear está limitado
por el número de directivas que admita el dispositivo. El número de túneles VPN
basados en rutas que se puede crear está limitado por el número de entradas de
ruta o por el número de interfaces Tunnel que admita el dispositivo (el que sea más
pequeño).
La configuración de un túnel VPN basado en rutas es una elección acertada si desea

conservar los recursos de túnel y ajustar restricciones granulares para el tráfico
VPN. Aunque puede crear numerosas directivas que hagan referencia al mismo
túnel VPN, cada directiva crea una asociación de seguridad (SA) IPSec individual
con el interlocutor remoto; cada una de estas asociaciones cuenta como un túnel
VPN independiente. Con un planteamiento basado en rutas para las VPN, la
regulación del tráfico no está ligada a los medios de entrega. Es posible configurar
docenas de directivas para regular el tráfico que circula a través de un único túnel
VPN entre dos puntos, si sólo hay una SA IPSec operativa. Además, la configuración
de una VPN basada en rutas permite crear directivas que hagan referencia a un
destino alcanzado a través de un túnel VPN donde la acción sea deny, en contraste
con la configuración de una VPN basada en directivas, donde, como hemos
indicado antes, la acción debe ser tunnel con la acción implícita permit.
Otra ventaja de las VPN basadas en rutas es el intercambio de información de

enrutamiento dinámico a través de túneles VPN. Es posible habilitar una instancia
de un protocolo de enrutamiento dinámico, como BGP (Border Gateway Protocol),
en una interfaz Tunnel asociada a un túnel VPN. La instancia de enrutamiento local
intercambia información de enrutamiento a través del túnel con un vecino
habilitado en una interfaz Tunnel asociada al otro extremo.
Si un túnel no conecta grandes redes en las que se ejecuten protocolos de

enrutamiento dinámico y no es necesario conservar túneles o definir diversas
directivas para filtrar el tráfico a través del túnel, tiene sentido configurar un túnel
basado en directivas. Además, como no existe ninguna red más allá de un cliente
VPN de acceso telefónico, los túneles VPN basados en directivas pueden ser una
buena elección para configuraciones VPN de acceso telefónico.
Dicho esto, si el cliente de acceso telefónico admite una dirección IP interna virtual
(como NetScreen-Remote), existen argumentos convincentes para utilizar una
configuración VPN basada en rutas. Un túnel VPN de acceso telefónico basado en
rutas presenta las siguientes ventajas:
Se puede asociar su interfaz túnel a cualquier zona para requerir o no la

aplicación de directivas.
Se pueden definir rutas para forzar el tráfico a través del túnel, al contrario de lo
que ocurre con una configuración VPN basada en directivas.
Un túnel VPN basado en rutas simplifica la adición de un radio a una

configuración radial (consulte “Creación de VPN radiales” en la página 321).
Puede ajustar la ID de proxy para que acepte cualquier dirección IP del cliente
VPN de acceso telefónico configurando la dirección del cliente remoto como
255.255.255.255/32.
Puede definir una o más direcciones IP asignadas (MIP) en la interfaz del túnel.
Túneles basados en directivas y en rutas 65

NOTA: Para obtener un ejemplo de una configuración VPN basada en rutas para un
cliente de acceso telefónico, consulte “VPN de acceso telefónico basada en rutas,
interlocutor dinámico” en la página 170.
Flujo de paquetes: VPN punto a punto

Para comprender mejor cómo interactúan los diversos componentes que
intervienen en la creación de un túnel IPSec, en esta sección se describe el proceso
de un flujo de paquetes a través de un túnel (tanto cuando un dispositivo de
seguridad envía tráfico VPN saliente como cuando recibe tráfico VPN entrante). Se
explica el proceso de una VPN basada en rutas y a continuación se incluye un anexo
en el que se indican los dos puntos del flujo que difieren en el caso de una VPN
basada en directivas.
Una empresa con sede en Tokio acaba de abrir una sucursal en París y necesita
conectar los dos puntos mediante un túnel IPSec. El túnel tiene las siguientes
características: AutoKey IKE, protocolo ESP, AES para encriptación, SHA-1 para
autenticación con clave previamente compartida y comprobación contra
reprocesamiento de paquetes habilitada. Los dispositivos de seguridad que
protegen cada punto se encuentran en modo NAT y todas las zonas se ubican en el
dominio de enrutamiento trust-vr. Las direcciones se muestran en la Figura 21 en la
página 66.
Figura 21: Túnel VPN punto a punto
Zona Trust Oficina Zona Untrust

de Tokio
tunnel.1, 10.1.2.1/24
Interfaz de salida: ethernet3, 1.1.1.1/24
ethernet1
10.1.1.1/24 Enrutador externo: 1.1.1.250
10.1.1.5
Internet París
Tokio
LAN VPN1 LAN
10.2.2.5
Enrutador externo: 2.2.2.250
ethernet1
Interfaz de salida: ethernet3, 2.2.2.2/24 10.2.2.1/24
tunnel.2, 10.2.1.1/24
Oficina
Zona Untrust de París Zona Trust
La ruta de un paquete procedente de 10.1.1.5/32 en la LAN de Tokio y destinado a

10.2.2.5/32 en la LAN de París a través de un túnel IPSec se desarrolla tal como se
describe en las subsecciones siguientes.
Tokio (iniciador)
1. El host en 10.1.1.5 envía un paquete para 10.2.2.5 a 10.1.1.1, que es la
dirección IP ethernet1 y es la puerta de enlace predeterminada configurada en
los ajustes TCP/IP del host.
66 Flujo de paquetes: VPN punto a punto

2. El paquete llega a ethernet1, que está asociado a la zona Trust.
3. Si hay habilitadas opciones SCREEN como la detección de suplantación de IP

para la zona Trust, el dispositivo de seguridad activa el módulo SCREEN en este
momento. La comprobación de SCREEN puede producir uno de los tres
resultados siguientes:

eventos.

para ethernet1 y continúa con el paso siguiente.
Si el mecanismo SCREEN no detecta ningún comportamiento anómalo, el

dispositivo de seguridad procede al paso siguiente.
Si no ha habilitado ninguna opción de SCREEN para la zona Trust, el dispositivo

de seguridad procede inmediatamente al paso siguiente.

paquete coincide con una sesión existente.
Si el paquete no coincide con una sesión existente, el dispositivo de seguridad

ejecuta los pasos restantes con procesamiento del primer paquete.

ejecuta el procesamiento rápido, utilizando la información disponible en la
rápido omite las consultas de rutas y directivas porque la información generada
por los pasos omitidos ya se obtuvo durante el procesamiento del primer
paquete de la sesión.
5. El módulo de asignación de direcciones comprueba si una dirección IP

asignada (MIP) utiliza la dirección IP de destino 10.2.2.5. Como 10.2.2.5 no se
utiliza en una configuración MIP, el dispositivo de seguridad continúa con el
paso siguiente. (Para obtener información sobre el procesamiento de paquetes
cuando existe traducción de direcciones de destino [NAT-dst], MIP o VIP,
consulte “Flujo de paquetes para NAT-Dst” en la página 8 -29).
6. Para determinar la zona de destino, el módulo de rutas realiza una consulta de

rutas para 10.2.2.5. (El módulo de rutas utiliza la interfaz de entrada para
determinar qué enrutador virtual debe utilizar para la consulta de rutas).
Encuentra una entrada de ruta que dirige el tráfico a 10.2.2.5 a través de la
interfaz tunnel.1 asociada a un túnel VPN llamado “vpn1”. La interfaz Tunnel se
encuentra en la zona Untrust. Determinando las interfaces de entrada y salida,
el dispositivo de seguridad determina las zonas de origen y de destino y puede
realizar una consulta de directivas.
Flujo de paquetes: VPN punto a punto 67

7. El motor de directivas realiza una consulta de directivas entre las zonas Trust y
Untrust (según lo determinado por las correspondientes interfaces de entrada y
de salida). La acción especificada en la directiva que coincide con la dirección
de origen y la zona, la dirección de destino y la zona, y el servicio es permitir.
8. El módulo IPSec comprueba si existe una asociación de seguridad (SA) de fase

2 activa con el interlocutor remoto. Mediante la comprobación de SA de fase 2
se pueden obtener los siguientes resultados:
Si el módulo IPSec descubre una SA de fase 2 activa con el interlocutor,

continúa con el paso 10.
Si el módulo IPSec no descubre una SA de fase 2 activa con el interlocutor,

descarta el paquete y activa el módulo IKE.
9. El módulo IKE comprueba si existe una SA de fase 1 activa con el interlocutor

remoto. Mediante la comprobación de SA de fase 1 se pueden obtener los
siguientes resultados:
Si el módulo IKE descubre una SA de fase 1 activa con el interlocutor, utiliza

esta SA para negociar una SA de fase 2.
Si el módulo IKE no descubre una SA de fase 1 activa con el interlocutor,

inicia negociaciones de fase 1 en modo principal y, luego, negociaciones de
fase 2.
10. El módulo IPSec coloca un encabezado ESP y un encabezado IP externo en el

paquete. Utilizando la dirección especificada como interfaz de salida, indica
1.1.1.1 como dirección IP de origen en el encabezado externo. Utilizando la
dirección especificada para la puerta de enlace remota, indica 2.2.2.2 como la
dirección IP de destino en el encabezado externo. A continuación, encripta el
paquete desde la carga hasta el campo del siguiente encabezado en el
encabezado IP original. Luego, autentica el paquete desde el finalizador ESP
hasta el encabezado ESP.
11. El dispositivo de seguridad envía el paquete encriptado y autenticado dirigido a

2.2.2.2 a través de la interfaz de salida (ethernet3) al enrutador externo en
1.1.1.250.
París (destinatario)
1. El paquete llega a 2.2.2.2, que es la dirección IP de ethernet3, una interfaz
asociada a la zona Untrust.
2. Mediante el SPI, la dirección IP de destino y el protocolo IPSec incluidos en el

encabezado de paquete externo, el módulo IPSec intenta localizar una SA de
fase 2 activa con el interlocutor iniciador junto con las claves para autenticar y
desencriptar el paquete. Mediante la comprobación de SA de fase 2 se puede
obtener uno de los tres siguientes resultados:
Si el módulo IPSec descubre una SA de fase 2 activa con el interlocutor,

continúa con el paso 4.

Si el módulo IPSec no descubre una SA de fase 2 activa con el interlocutor

pero puede comparar una SA de fase 2 inactiva utilizando la dirección IP de
origen pero no el SPI, descarta el paquete, realiza una entrada en el registro
de eventos y envía una notificación al interlocutor iniciador para avisar de
que ha recibido un SPI incorrecto.
Si el módulo IPSec no descubre una SA de fase 2 activa con el interlocutor,

descarta el paquete y activa el módulo IKE.
3. El módulo IKE comprueba si existe una SA de fase 1 activa con el interlocutor

remoto. Mediante la comprobación de SA de fase 1 se pueden obtener los
siguientes resultados:
Si el módulo IKE descubre una SA de fase 1 activa con el interlocutor, utiliza

esta SA para negociar una SA de fase 2.
Si el módulo IKE no descubre una SA de fase 1 activa con el interlocutor,

inicia negociaciones de fase 1 en modo principal y, luego, negociaciones de
fase 2.
4. El módulo IPSec realiza una comprobación contra reprocesamiento de

paquetes. Mediante esta comprobación se puede obtener uno de los dos
resultados siguientes:
Si el paquete no pasa la comprobación contra reprocesamiento de

paquetes (porque se detecte un número de secuencia que el dispositivo de
seguridad ya haya recibido), el dispositivo de seguridad descarta el
paquete.
Si el paquete pasa la comprobación contra reprocesamiento de paquetes, el

dispositivo de seguridad continúa con el siguiente paso.
5. El módulo IPSec intenta autenticar el paquete. Mediante la comprobación de

autenticación se puede obtener uno de los dos resultados siguientes:
Si el paquete no pasa la comprobación de autenticación, el dispositivo de

seguridad descarta el paquete.
Si el paquete pasa la comprobación de autenticación, el dispositivo de

seguridad continúa con el siguiente paso.
6. Mediante la SA de fase 2 y las claves, el módulo IPSec desencripta el paquete,

descubriendo la dirección de origen original (10.1.1.5) y el destino final
(10.2.2.5). Averigua que el paquete ha llegado a través de vpn1, que está
asociada a tunnel.1. A partir de este momento, el dispositivo de seguridad
gestiona el paquete teniendo en cuenta que su interfaz de entrada es tunnel.1
en lugar de ethernet3. También ajusta la ventana deslizante contra
reprocesamiento de paquetes.

7. Si hay habilitadas opciones de SCREEN para la zona Untrust, el dispositivo de

seguridad activa el módulo SCREEN en este momento. La comprobación de
SCREEN puede producir uno de los tres resultados siguientes:

eventos.

para ethernet3 y continúa con el paso siguiente.
Si el mecanismo SCREEN no detecta ningún comportamiento anómalo, el

dispositivo de seguridad procede al paso siguiente.

paquete coincide con una sesión existente. A continuación, aplica el
procesamiento del primer paquete o el procesamiento rápido.

ejecuta el procesamiento rápido, utilizando la información disponible en la
rápido omite todos los pasos salvo los dos últimos (encriptar el paquete y
reenviarlo) porque la información generada por los pasos omitidos ya se obtuvo
durante el procesamiento del primer paquete de la sesión.
9. El módulo de asignación de direcciones comprueba si una dirección IP

asignada (MIP) o virtual (VIP) utiliza la dirección IP de destino 10.2.2.5. Como
10.2.2.5 no se utiliza en ninguna configuración MIP o VIP, el dispositivo de
seguridad continúa con el paso siguiente.
10. El módulo de rutas utiliza primero la interfaz de entrada para determinar el

enrutador virtual que debe utilizar para la consulta de rutas; en este caso,
trust-vr. A continuación, realiza una consulta de rutas para 10.2.2.5 en trust-vr y
descubre que el acceso se ha llevado a cabo a través de ethernet1.
Determinando la interfaz de entrada (tunnel.1) y la de salida (ethernet1), el
dispositivo de seguridad puede determinar las zonas de origen y destino. La
interfaz tunnel.1 está asociada a la zona Untrust y ethernet1 a la zona Trust. El
dispositivo de seguridad puede realizar ahora una consulta de directivas.
11. El motor de directivas comprueba su lista de directivas desde la zona Untrust

hasta la zona Trust y encuentra una directiva que permite el acceso.
12. El dispositivo de seguridad reenvía el paquete a través de ethernet1 a su

destino en 10.2.2.5.
Anexo: VPN basadas en directivas

El flujo de paquetes para una configuración VPN basada en directivas difiere en dos
puntos del de la configuración VPN basada en rutas: la consulta de rutas y la
consulta de directivas.

Tokio (iniciador)
Las primeras etapas del flujo de paquetes saliente son las mismas para las
configuraciones VPN basadas en rutas y las basadas en directivas hasta que se
producen las consultas de rutas y de directivas:
Consulta de rutas: para determinar la zona de destino, el módulo de rutas

realiza una consulta de rutas para 10.2.2.5. Si no encuentra ninguna entrada
para esa dirección específica, el módulo de rutas, resuelve una ruta a través de
ethernet3, que está asociada a la zona Untrust. Determinando las interfaces de
entrada y salida, el dispositivo de seguridad determina las zonas de origen y de
destino y puede realizar una consulta de directivas.
Consulta de directivas: el motor de directivas realiza una consulta de directivas

en las zonas Trust y Untrust. La consulta compara la dirección de origen y la
zona, la dirección de destino y la zona, y el servicio, y encuentra una directiva
que hace referencia a un túnel VPN llamado vpn1.
El dispositivo de seguridad reenvía el paquete a través de ethernet1 a su destino en

10.2.2.5.
París (destinatario)
La mayoría de las etapas del flujo de paquetes entrante en el extremo del
destinatario son idénticas tanto para las configuraciones VPN basadas en directivas
como para las basadas en rutas, excepto que el túnel no está asociado a una interfaz
Tunnel, sino a una zona de túnel. El dispositivo de seguridad averigua que el
paquete ha llegado a través de vpn1, que está asociada a la zona de túnel
Untrust-Tun, cuya zona portadora es la zona Untrust. Al contrario de lo que ocurre
en las VPN basadas en rutas, el dispositivo de seguridad considera que ethernet3 es
la interfaz de entrada del paquete desencriptado (y no tunnel.1).
El flujo cambia cuando concluye la desencriptación del paquete. En este punto, las
consultas de rutas y directivas difieren:
Consulta de rutas: el módulo de rutas realiza una consulta de rutas para

10.2.2.5 y descubre que el acceso se ha producido a través de ethernet1, que
está asociada a la zona Trust. Averiguando que la zona Untrust es la zona de
origen (porque vpn1 está asociada a la zona de túnel Untrust-Tun, cuya zona
portadora es la zona Untrust) y determinando la zona de destino a partir de la
interfaz de salida (ethernet1 está asociada a la zona Trust), el dispositivo de
seguridad puede buscar ahora una directiva desde la zona Untrust hasta la zona
Trust que haga referencia a vpn1.
Consulta de directivas: el motor de directivas comprueba su lista de directivas

desde la zona Untrust hasta la zona Trust y encuentra una directiva que hace
referencia a un túnel VPN llamado vpn1 y que permite el acceso a 10.2.2.5.
Entonces, el dispositivo de seguridad reenvía el paquete a su destino.

Directrices para la configuración de túneles

Esta sección presenta algunas directrices para la configuración de los túneles VPN.
Al configurar un túnel VPN IPSec, es posible que desee considerar lo siguiente:
ScreenOS admite un máximo de cuatro propuestas para las negociaciones de

fase 1 y un máximo de cuatro propuestas para las negociaciones de fase 2. Un
interlocutor tiene que estar configurado para aceptar al menos una propuesta
de fase 1 y una propuesta de fase 2 realizadas por el otro interlocutor. Para
obtener información sobre las negociaciones IKE de fase 1 y fase 2, consulte
“Negociación de túnel” en la página 9.
Si desea utilizar certificados para la autenticación y hay más de un certificado

local cargado en el dispositivo de seguridad, deberá especificar qué certificado
desea que utilice cada configuración de túnel VPN. Para obtener más
información sobre los certificados, consulte “Criptografía de claves públicas” en
la página 19.
Para una VPN básica basada en directivas:
Utilice direcciones definidas por el usuario en la directiva, no la dirección

predefinida “Any”.
Las direcciones y el servicio especificados en las directivas configuradas en

los dos extremos de la VPN deben coincidir.
Utilice directivas simétricas para el tráfico VPN bidireccional.
La ID de proxy para ambos interlocutores debe coincidir, es decir, el servicio

especificado en la ID de proxy para ambos interlocutores debe ser idéntico y la
dirección IP local indicada para un interlocutor debe ser igual que la dirección
IP remota indicada para el otro interlocutor.
NOTA: La ID de proxy es una tupla de tres partes compuesta por dirección IP

local-dirección IP remota-servicio.
Para una configuración VPN basada en rutas, la ID de proxy es configurable

por el usuario.
Para una configuración VPN basada en directivas, el dispositivo de

seguridad (de forma predeterminada) deriva la ID de proxy a partir de la
dirección de origen, la dirección de destino y el servicio especificados en la
directiva que hace referencia al túnel VPN en la lista de directivas. También
es posible definir una ID de proxy para una VPN basada en directivas que
reemplace la ID de proxy derivada.
El método más simple para garantizar que las ID de proxy coinciden es utilizar
0.0.0.0/0 para la dirección local, 0.0.0.0/0 para la dirección remota y “any” para el
servicio. En lugar de utilizar la ID de proxy para el control de acceso, se utilizan
directivas para controlar el tráfico procedente de y destinado a la VPN. Para obtener
ejemplos de configuraciones VPN con ID de proxy configurables por el usuario,
consulte los ejemplos de VPN basadas en rutas del “Redes privadas virtuales de
punto a punto” en la página 81.
72 Directrices para la configuración de túneles

NOTA: Si la dirección remota es la dirección interna virtual de un cliente VPN de acceso

telefónico, utilice 255.255.255.255/32 para la dirección IP remota/máscara de red
en la ID de proxy.
Siempre que coincidan los ajustes de ID de proxy de los interlocutores, es

irrelevante si un interlocutor define una VPN basada en rutas y el otro, una VPN
basada en directivas. Si el interlocutor 1 utiliza una configuración VPN basada
en directivas, y el interlocutor utiliza una configuración VPN basada en rutas, el
interlocutor 2 deberá definir una ID de proxy que coincida con la ID de proxy
derivada de la directiva del interlocutor 1. Si el interlocutor 1 realiza la
traducción de direcciones de red de origen (NAT-src) mediante un conjunto de
DIP, utilice la dirección y la máscara de red para el conjunto de DIP como
dirección remota en la ID de proxy del interlocutor 2. Por ejemplo:
Si el conjunto de DIP es: Utilice esto en la ID de proxy:

1.1.1.8 – 1.1.1.8 1.1.1.8/32
1.1.1.20 – 1.1.1.50 1.1.1.20/26
1.1.1.100 – 1.1.1.200 1.1.1.100/25
1.1.1.0 – 1.1.1.255 1.1.1.0/24
Para obtener más información sobre las ID de proxy cuando se utilizan con NAT-src
y NAT-dst, consulte “Sitios VPN con direcciones superpuestas” en la página 142.
NOTA: El interlocutor 1 también puede definir una ID de proxy que coincida con la ID de
proxy del interlocutor 2. La ID de proxy definida por el usuario del interlocutor 1
reemplaza la ID de proxy que el dispositivo de seguridad deriva de los
componentes de la directiva.
Como las ID de proxy admiten un único servicio o todos los servicios, el

servicio de una ID de proxy derivada a partir de una VPN basada en directivas
que haga referencia a un grupo de servicios se considera como “any”.
Cuando ambos interlocutores tienen direcciones IP estáticas, pueden utilizar la

ID IKE predeterminada, es decir, su dirección IP. Cuando un usuario de acceso
telefónico o interlocutor tiene una dirección IP asignada de forma dinámica,
dicho usuario o interlocutor debe utilizar otro tipo de ID IKE. Un nombre
completo (FQDN) es una buena elección para un interlocutor dinámico, y un
U-FQDN (dirección de correo electrónico) es una buena elección para un
usuario de acceso telefónico. Se pueden utilizar los dos tipos de ID IKE FQDN y
U-FQDN con claves previamente compartidas y certificados (si el FQDN o
U-FQDN aparece en el campo SubjectAltName del certificado). Si utiliza
certificados, el interlocutor dinámico o el usuario de acceso telefónico también
podrá utilizar todo o parte del ASN1-DN como ID IKE.
Directrices para la configuración de túneles 73

Consideraciones sobre seguridad en redes privadas virtuales basadas en rutas

Aunque los cambios de rutas no afectan a las VPN basadas en directivas, las VPN
basadas en rutas son otra cuestión. El dispositivo de seguridad puede enrutar
paquetes a través del túnel de una VPN basada en rutas combinando rutas estáticas
con protocolos de enrutamiento dinámico. Mientras no ocurra ningún cambio de
ruta, el dispositivo de seguridad encripta y reenvía constantemente los paquetes
destinados a las interfaces Tunnel asociadas a los túneles de la VPN basada en rutas.
Sin embargo, cuando se utiliza el seguimiento de VPN con una configuración de

túnel VPN basado en rutas, el estado del túnel puede cambiar de en línea (up) a
fuera de línea (down). Cuando esto ocurre, todas las entradas de la tabla de rutas
que hacen referencia a la interfaz Tunnel asociada a ese túnel cambian a inactivas.
A continuación, si el dispositivo de seguridad examina las rutas para buscar tráfico
que originalmente debería estar encriptado y enviarse a través de un túnel asociado
a esa interfaz Tunnel, no tendrá en cuenta la ruta relativa a la interfaz Tunnel y
buscará la siguiente ruta con mayor coincidencia. La ruta que encuentre podría ser
la ruta predeterminada. Con esta ruta, el dispositivo de seguridad enviaría fuera el
tráfico desencriptado (es decir, en texto sin formato o sin formato) a través de una
interfaz sin túnel a la WAN pública.
Para evitar reenrutar el tráfico previsto originalmente para un túnel VPN a la WAN
pública como texto sin formato, puede configurar el dispositivo de seguridad para
que desvíe dicho tráfico a otro túnel, reenrutarlo a una línea arrendada o
simplemente descartarlo, utilizando una de las siguientes soluciones:
“Ruta Null” en la página 74 (descarta el tráfico cuando la ruta a la interfaz

Tunnel se desactiva)
“Línea de acceso telefónico o arrendada” en la página 76 (reencamina el tráfico

a otra ruta segura cuando la ruta a la interfaz Tunnel se desactiva)
“Interfaz Tunnel ficticia” en la página 79 (descarta el tráfico cuando la ruta a la

interfaz Tunnel se desactiva)
“Enrutador virtual para interfaces Tunnel” en la página 80 (descarta el tráfico

cuando la ruta a la interfaz Tunnel se desactiva)
“Reenrutamiento a otro túnel” en la página 80 (reencamina el tráfico a un túnel

VPN alternativo cuando la ruta a la interfaz Tunnel se desactiva)
Ruta Null
Si el estado de un túnel VPN cambia a “fuera de línea”, el dispositivo de seguridad
cambia cualquier ruta que haga referencia a esa interfaz Tunnel a “fuera de línea”. Si
la ruta a la interfaz Tunnel deja de estar disponible y la opción siguiente es la ruta
predeterminada (por ejemplo), a continuación el dispositivo de seguridad utiliza la
ruta predeterminada para reenviar el tráfico previsto originalmente para el túnel
VPN. Para evitar enviar tráfico en texto sin formato hacia la WAN pública cuando se
produce un cambio de ruta, puede utilizar una ruta Null. Una ruta Null apunta a la
misma dirección de destino que la ruta a través de la interfaz Tunnel, pero dirige el
tráfico hacia la interfaz Null. La interfaz Null es una interfaz lógica que descarta el
tráfico enviado hacia ella. Asigne a la ruta Null una métrica más elevada (más
alejada de cero) que la ruta que utiliza la interfaz Tunnel para que la ruta Null tenga
una prioridad inferior.
74 Consideraciones sobre seguridad en redes privadas virtuales basadas en rutas

NOTA: Las versiones anteriores a ScreenOS 5.1.0 no admiten interfaces Null. No

obstante, puede utilizar una interfaz Tunnel ficticia para lograr el mismo objetivo.
Para obtener información, consulte “Interfaz Tunnel ficticia” en la página 79.
Por ejemplo, si crea una ruta estática a través de tunnel.1 hacia una LAN remota
con la dirección IP 10.2.2.0/24, su métrica recibirá automáticamente el valor
predeterminado 1:

get route
…
Dest-Routes for <trust-vr> (4 entries)

* 3 0.0.0.0/0 eth3 1.1.1.250 S 20 1 Root
* 2 1.1.1.0/24 eth3 0.0.0.0 C 0 0 Root
* 1 10.1.1.0/24 eth1 0.0.0.0 C 0 0 Root
* 4 10.2.2.0/24 tun.1 0.0.0.0 S 20 1 Root
En la tabla de enrutamiento anterior, un asterisco (*) indica que una ruta está
activa, S indica una ruta estática y “C” indica una ruta conectada.
En la tabla de enrutamiento anterior, el dispositivo de seguridad tiene dos rutas

para alcanzar cualquier dirección en la subred 10.2.2.0/24. La primera opción es la
ruta nº 4 porque coincide en mayor medida con esa dirección. La segunda opción
es la ruta predeterminada (0.0.0.0/0).
Si a continuación agrega otra ruta a 10.2.2.0/24 a través de la interfaz Null y le

asigna un valor mayor que 1, esa ruta se convierte en la segunda opción de
enrutamiento hacia cualquier dirección de la subred 10.2.2.0/24. Si la ruta hacia
10.2.2.0/24 a través de tunnel.1 se desactiva, el dispositivo de seguridad utiliza la
ruta hacia la interfaz Null. El dispositivo de seguridad reenvía el tráfico destinado a
10.2.2.0/24 hacia esa interfaz y luego lo descarta.
set vrouter trust-vr route 10.2.2.0/24 interface null metric 10

get route
…
Dest-Routes for <trust-vr> (5 entries)

* 3 0.0.0.0/0 eth3 1.1.1.250 S 20 1 Root
* 2 1.1.1.0/24 eth3 0.0.0.0 C 0 0 Root
* 1 10.1.1.0/24 eth1 0.0.0.0 C 0 0 Root
4 10.2.2.0/24 tun.1 0.0.0.0 S 20 1 Root
* 5 10.2.2.0/24 null 0.0.0.0 S 20 10 Root
Consideraciones sobre seguridad en redes privadas virtuales basadas en rutas 75

En la tabla de enrutamiento anterior, la ruta hacia 10.2.2.0/24 a través de tunnel.1

está inactiva (indicado por la ausencia de un asterisco en la columna izquierda). Por
lo tanto, el dispositivo de seguridad busca la siguiente ruta con la mayor
coincidencia con la dirección de destino y encuentra la ruta número 5. (La siguiente
opción después de la ruta nº 5 es la ruta predeterminada con la identificación
número 3). A continuación, el dispositivo de seguridad reenvía el tráfico para
10.2.2.0/24 a la interfaz Null, que descarta el tráfico. Consecuentemente, si la ruta
que utiliza tunnel.1 se desactiva, el dispositivo de seguridad descarta el tráfico para
10.2.2.0/24 en lugar de utilizar la ruta número 3 para reenviarlo hacia fuera a través
de ethernet3 como texto sin formato al enrutador en 1.1.1.250.
Línea de acceso telefónico o arrendada

Si no desea que el tráfico dirigido a un interlocutor remoto se descarte cuando el
túnel hacia ese interlocutor se desactive, puede agregar una ruta alternativa hacia
ese interlocutor a través de una línea de acceso telefónico o arrendada. Esta ruta
alternativa utilizará la misma dirección IP de destino que la ruta a través del túnel
VPN, pero tendrá otra interfaz de salida y una métrica menos prioritaria. Si la ruta a
través del túnel VPN llegase a desactivarse, el dispositivo de seguridad reenrutaría el
tráfico dirigido al interlocutor remoto a través de la línea de acceso telefónico o
arrendada.
Cuando utilice una línea de acceso telefónico o arrendada como ruta de siguiente
opción, todavía existe la posibilidad de que las rutas de primera y de segunda
opción puedan desactivarse simultáneamente. En ese caso, el dispositivo de
seguridad recurre a la tercera opción, que puede ser la ruta predeterminada. En
previsión de tal situación, puede convertir a la ruta de acceso telefónico o
arrendada en la segunda opción y a la ruta Null en la tercera opción (consulte “Ruta
Null” en la página 74). La Figura 22 muestra cómo estas opciones de tratamiento de
un fallo de enrutamiento pueden funcionar en conjunto.
Figura 22: Alternativas del fallo de enrutamiento para el tráfico de VPN
Primera opción: Un túnel VPN

hacia el interlocutor remoto. Dispositivo de
seguridad
ethernet1 10.1.1.1/24 local
Zona Trust ethernet3 1.1.1.1/24 Zona Untrust
LAN Interlocutor remoto
local tunnel.1 Internet de la VPN
LAN remota
Túnel VPN
Segunda opción: Una ruta estática sobre
una línea de acceso telefónico o arrendada ethernet4
hacia el interlocutor de la VPN. Su métrica 1.2.2.1/24
es mayor que la de la ruta que utiliza el Línea de acceso
túnel VPN. Esta opción de enrutamiento Interfaz telefónico o arrendada
reenvía el tráfico como texto sin formato a Null
través de la línea protegida al interlocutor.
Descartar
Tercera opción: Una ruta Null con una métrica superior tráfico
que la de la línea de acceso telefónico o arrendada. Esta
opción descarta el tráfico.

Conmutación por error de la VPN hacia la línea arrendada o la ruta Null

En este ejemplo, deseamos que el tráfico procedente de la sucursal detrás del
dispositivo-A alcance la red corporativa situada detrás del dispositivo-B a través de
una conexión VPN segura. Si el túnel falla, el tráfico deberá fluir a través de una
línea arrendada hacia la oficina corporativa. Si tanto el túnel VPN como la línea
arrendada fallan, el dispositivo-A deberá descartar el tráfico en lugar de enviarlo
fuera hacia Internet como texto sin formato.
Creará tres rutas en el dispositivo-A para alcanzar a 10.2.2.0/24 y asignará a cada

una su propia métrica:
Ruta preferida: utilizar tunnel.1, asociado a vpn1 (métrica = 1)
Ruta secundaria: utilizar ethernet4 y la puerta de enlace en 1.2.2.5 para

utilizar la línea arrendada (métrica = 2)
Ruta terciaria: utilice la interfaz Null para descartar tráfico (métrica = 10)
Al crear la ruta preferida, utilizará la métrica predeterminada de una ruta estática,

que es 1. Asignará una métrica de 2 a la ruta secundaria; es decir, el la ruta de
respaldo a través de la línea arrendada (mostrada en la Figura 23 en la página 77).
La métrica es inferior que la de la ruta preferida a través del túnel VPN. El
dispositivo de seguridad no utiliza la ruta secundaria a menos que la ruta preferida
a través del túnel VPN falle.
Finalmente, agregará una ruta NULL con una métrica de 10. Si la ruta preferida falla
y a continuación también falla la ruta secundaria, el dispositivo de seguridad
descartará todos los paquetes. Todas las zonas de seguridad se encuentran en el
dominio de enrutamiento trust-vr.
NOTA: Este ejemplo muestra únicamente la configuración para cuatro rutas (tres para la
conmutación por error más la ruta predeterminada) en el dispositivo-A.
Figura 23: Fallo de enrutamiento hacia una línea arrendada y después a la ruta Null
El tráfico fluye desde la sucursal a la

oficina corporativa.
Preferencias de rutas:
1. tunnel.1 -> vpn1
2. ethernet4 -> línea arrendada
3. interfaz null -> descartar ethernet3 Puerta de enlace ethernet3
1.1.1.1/24 1.1.1.250 2.2.2.2/24
tunnel.1 tunnel.1
Dispositivo A Internet Dispositivo B

LAN LAN
10.1.1.0/24 10.2.2.0/24
vpn1
Línea arrendada (ruta de respaldo)

Ruta NULL
Puerta de enlace: 1.2.2.5/24
ethernet4 ethernet4
1.2.2.1/24 2.3.3.2/24

WebUI (dispositivo-A)

Metric: 1

Interface: tunnel.1
Metric: 1

Metric: 2

Interface: Null
Metric: 10
CLI (dispositivo-A)
set vrouter trust-vr route 10.2.2.0/24 interface ethernet4 gateway 1.2.2.5 metric
2
save

Puede verificar la presencia de las nuevas rutas ejecutando el comando get route.
device-C-> get route
IPv4 Dest-Routes for <untrust-vr> (0 entries)

--------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2
IPv4 Dest-Routes for <trust-vr> (7 entries)

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
* 8 0.0.0.0/0 eth1/1 10.100.37.1 S 20 1 Root
* 7 1.1.1.1/32 eth1/2 0.0.0.0 H 0 0 Root
* 3 192.168.1.1/32 mgt 0.0.0.0 H 0 0 Root
* 2 192.168.1.0/24 mgt 0.0.0.0 C 0 0 Root
* 4 10.100.37.0/24 eth1/1 0.0.0.0 C 0 0 Root
* 5 10.100.37.170/32 eth1/1 0.0.0.0 H 0 0 Root
* 6 1.1.1.0/24 eth1/2 0.0.0.0 C 0 0 Root
La entrada de la tabla de rutas con la identificación 5 dirige el tráfico destinado a

10.2.2.0/24 hacia tunnel.1 y luego a través del túnel VPN. Es la ruta preferida para
que el tráfico alcance la red 10.2.2.0. Si ese túnel falla, la siguiente mejor ruta es la
correspondiente a la entrada 6 sobre una línea arrendada a través de una puerta de
enlace en 1.2.2.5. Si la conexión de la entrada de ruta 6 falla, la entrada de ruta 7 se
convierte en la siguiente mejor ruta y el dispositivo de seguridad dirige el tráfico
destinado a 10.2.2.0/24 hacia la interfaz Null, que después lo descarta.
Interfaz Tunnel ficticia

Cuando se produce un error, en lugar de conmutar el tráfico de un túnel VPN a una
interfaz Null (donde se descarta), se puede utilizar una interfaz Tunnel inoperativa
para lograr el mismo objetivo.
NOTA: Las versiones anteriores a ScreenOS 5.1.0 no admiten interfaces Null (consulte
“Ruta Null” en la página 74). Sin embargo, puede utilizar una interfaz Tunnel
ficticia para lograr el mismo objetivo.
Para configurar una interfaz Tunnel ficticia, haga lo siguiente:
1. Cree una segunda interfaz Tunnel, pero no la asocie a un túnel VPN. En su lugar,
asóciela a una zona Tunnel que se encuentre en el mismo dominio de
enrutamiento virtual que la primera interfaz Tunnel.
NOTA: Si una interfaz Tunnel está asociada a una zona de túnel, su estado siempre será
activo.

2. Defina una segunda ruta hacia el mismo destino utilizando esta segunda
interfaz Tunnel y asígnele una métrica más alta (más alejada de cero) que la de
la ruta preferida.
Cuando el estado de la interfaz Tunnel en funcionamiento pase de en línea a

fuera de línea y la entrada de la tabla de rutas relativa a esa interfaz quede
inactiva, las consultas de rutas encontrarán esta segunda ruta a la interfaz
Tunnel no operativa. El dispositivo de seguridad reenviará el tráfico a la
segunda interfaz Tunnel y como no está asociada a un túnel VPN, el dispositivo
descartará el tráfico.
Enrutador virtual para interfaces Tunnel

Para evitar que, al desactivarse la ruta programada a través de un túnel VPN, el
tráfico que originalmente debía atravesar el túnel se conmute en caso de error hacia
la ruta predeterminada, puede crear un dominio de enrutamiento virtual especial
exclusivamente para el tráfico VPN. Para configurarlo, proceda de la siguiente
manera:
1. Cree un enrutador virtual independiente para utilizarlo con todas las rutas que
apunten a interfaces Tunnel y déle, por ejemplo, el nombre “VR-VPN”.
2. Cree una zona de seguridad (llamada, por ejemplo, “zona VPN”) y asóciela a
VR-VPN.
3. Asocie todas las interfaces Tunnel a la zona VPN e introduzca todas las
direcciones de ubicaciones remotas a las que desee acceder a través de túneles
VPN en esta zona.
4. Configure rutas estáticas en todos los demás enrutadores virtuales a VR-VPN

para el tráfico que desee que esté encriptado y se envíe a través de los túneles.
En caso necesario, defina rutas estáticas para el tráfico desencriptado desde
VR-VPN a otros enrutadores virtuales. Estas rutas son necesarias para permitir
que el tráfico VPN entrante pase por el túnel si se inicia desde la ubicación
remota.
Si el estado de una interfaz Tunnel pasa de en línea a fuera de línea, el

dispositivo de seguridad aún lo reenviará a VR-VPN, donde debido a que ahora
el estado de la ruta a esa interfaz está inactivo y no hay otras rutas adecuadas,
el dispositivo de seguridad descartará el tráfico.
Reenrutamiento a otro túnel

Puede configurar dos o más túneles VPN hacia el mismo interlocutor remoto. Si uno
de los túneles queda fuera de línea, el dispositivo de seguridad puede reenrutar el
tráfico a través de otro túnel VPN. Para obtener información y ejemplos sobre la
configuración de túneles VPN redundantes, consulte:
“Cambio en caso de fallo del túnel de activo a respaldo” en la página 11-51
“Configuración de túneles activos dobles” en la página 11-71
“Configuración de los pesos de cambio en caso de fallo del túnel” en la

página 11-78

Capítulo 4
Redes privadas virtuales de punto a
punto
En este capítulo se explica cómo configurar un túnel de red privada virtual (VPN)
punto a punto entre dos dispositivos de seguridad de Juniper Networks. Aquí se
examinan los túneles VPN basados en rutas y basados en directivas, se presentan
los diversos elementos que hay que tener en cuenta al configurar un túnel y se
ofrecen varios ejemplos.
“Configuraciones VPN punto a punto” en la página 82
“VPN punto a punto basada en rutas, AutoKey IKE” en la página 88
“VPN punto a punto basada en directivas, AutoKeyIKE” en la página 97
“VPN punto a punto basada en rutas, interlocutor dinámico” en la

página 103
“VPN punto a punto basada en directivas, interlocutor dinámico” en la

página 112
“VPN punto a punto basada en rutas, clave manual” en la página 120
“VPN punto a punto basada en directivas, clave manual” en la página 127
“Puertas de enlace IKE dinámicas con FQDN” en la página 132
“Alias” en la página 133
“Ajuste del interlocutor AutoKey IKE con FQDN” en la página 134
“Sitios VPN con direcciones superpuestas” en la página 142
“VPN en modo transparente” en la página 154
81
Configuraciones VPN punto a punto

Existe un túnel VPN IPSec entre dos puertas de enlace y cada puerta de enlace
necesita una dirección IP. Si ambas puertas de enlace tienen direcciones IP
estáticas, se pueden configurar los siguientes tipos de túneles:
Túnel VPN punto a punto AutoKey IKE (con clave previamente compartida o
certificados)
Túnel VPN punto a punto con clave manual
Si una puerta de enlace tiene una dirección estática, y la otra tiene una dirección
asignada de forma dinámica, se puede configurar el siguiente tipo de túnel:
Túnel VPN punto a punto de interlocutor dinámico AutoKey IKE (con clave
previamente compartida o certificados)
Tal como se utiliza aquí, una VPN punto a punto estática implica la existencia de un
túnel IPSec para conectar dos puntos, cada uno de ellos con un dispositivo de
seguridad operativo como puerta de enlace segura. La interfaz o subinterfaz física
utilizada como interfaz de salida en ambos dispositivos tiene una dirección IP fija,
y los hosts internos también tienen direcciones IP estáticas. Si el dispositivo de
seguridad se encuentra en modo transparente, utiliza la dirección VLAN1 como
dirección IP para la interfaz de salida. Con una VPN punto a punto estática, los
hosts situados en cualquier extremo del túnel pueden iniciar la configuración del
túnel VPN porque la dirección IP de la puerta de enlace remota se mantiene
constante y, por tanto, accesible.
Si la interfaz de salida de uno de los dispositivos de seguridad tiene una dirección IP

asignada dinámicamente, dicho dispositivo se considera un interlocutor dinámico y
la VPN se configura de forma distinta. Con una VPN punto a punto de interlocutor
dinámico, sólo los hosts ubicados detrás del interlocutor dinámico pueden iniciar la
configuración del túnel VPN, ya que sólo su puerta de enlace remota tiene una
dirección IP fija y, por tanto, es accesible desde su puerta de enlace local. Sin
embargo, una vez que se ha establecido un túnel entre un interlocutor dinámico y
un interlocutor estático, los hosts ubicados detrás de cualquier puerta de enlace
pueden iniciar tráfico VPN si los hosts de destino tienen direcciones IP fijas.
NOTA: Para obtener más información sobre las opciones de VPN disponibles, consulte
“Seguridad del protocolo de Internet” en la página 1. Si desea obtener ayuda para
elegir entre las distintas opciones, consulte “Directrices para las redes privadas
virtuales” en la página 49.
La configuración de un túnel VPN punto a punto requiere la coordinación de la

configuración del túnel con la configuración de otros ajustes (interfaces,
direcciones, rutas y directivas). Los tres ejemplos de configuración VPN incluidos en
esta sección se enmarcan en el siguiente contexto: una oficina de Tokio desea
comunicarse de forma segura con una oficina de París a través de un túnel VPN
IPSec.
82 Configuraciones VPN punto a punto

Capítulo 4: Redes privadas virtuales de punto a punto
Figura 24: Configuración de túneles VPN punto a punto
Oficin Zona Untrust

Zona Trust
de Tokio

ethernet1
10.1.1.1/24 ethernet3, 1.1.1.1/24
NAT
enrutador externo, 1.1.1.250
Dispositivo de
seguridad
de Tokio Internet
LAN LAN
10.1.1.0/24 10.2.2.0/24
Tunnel:vpn1 Dispositivo de
seguridad
de París
enrutador externo, 2.2.2.250
ethernet1
ethernet3, 2.2.2.2/24 10.2.2.1/24
Zona Untrust Oficina Zona Trust

de París
Los administradores de ambas oficinas configuran los siguientes ajustes:
Interfaces: Zonas de seguridad y túnel
Direcciones
VPN (una de las opciones siguientes)
AutoKey IKE
Interlocutor dinámico
Clave manual
Rutas
Directivas
Configuraciones VPN punto a punto 83

Figura 25: Configuración de túneles punto a punto: Interfaces

de Tokio

ethernet1
10.1.1.1/24 Eth3, 1.1.1.1/24
NAT
Dispositivo de
seguridad
de Tokio
Internet
Dispositivo de
seguridad
de París ethernet1
Eth3, 2.2.2.2/24 10.2.2.1/24
NAT
Zona Untrust Oficina Zona Trust

de París
1. Interfaces: Zonas de seguridad y túnel

El administrador de la oficina de Tokio configura las interfaces de zona de seguridad
y túnel con los ajustes que aparecen en la mitad superior de la Figura 25.
Asimismo, el administrador de la oficina de París configura los ajustes que aparecen
en la mitad inferior de la figura.
Ethernet3 va a ser la interfaz de salida para el tráfico VPN y la puerta de enlace

remota para el tráfico VPN enviado desde el otro extremo del túnel.
Ethernet1 se encuentra en modo NAT, por lo que cada administrador puede asignar
direcciones IP a todos los hosts internos, incluso si el tráfico pasa de la zona Trust a
la zona Untrust, el dispositivo de seguridad traduce la dirección IP de origen de los
encabezados de los paquetes a la dirección de la interfaz de la zona Untrust,
ethernet3 (1.1.1.1 para Tokio y 2.2.2.2 para París).
Para una VPN basada en rutas, cada administrador asocia la interfaz de túnel
tunnel.1 al túnel VPN vpn1. Definiendo una ruta al espacio de direcciones de la LAN
de la oficina remota, el dispositivo de seguridad puede dirigir todo el tráfico
asociado a dicha LAN a la interfaz tunnel.1, y por tanto, a través del túnel al que
está asociada tunnel.1.
Como no se requieren servicios NAT basados en directivas, una configuración VPN

basada en rutas no requiere que tunnel.1 tenga una dirección IP/máscara de red,
y una configuración VPN basada en directivas ni siquiera requiere una interfaz de
túnel.

Figura 26: Configuración de túneles punto a punto: Direcciones

de Tokio
ethernet1 ethernet3, 1.1.1.1/24
10.1.1.1/24 Dispositivo de
Trust_LAN NAT seguridad
Trust, 10.1.1.0/24 de Tokio París
Tokio Internet LAN Untrust, 10.2.2.0/24
LAN
Untrust 10.1.1.0/24 Dispositivo de Trust_LAN
seguridad Trust 10.2.2.0/24
de París
ethernet3, 2.2.2.2/24 ethernet1
tunnel.1, sin numerar 10.2.2.1/24
NAT
Oficina
Zona Untrust de París Zona Trust
2. Direcciones
Los administradores definen direcciones para su posterior uso en directivas de
entrada y salida. El administrador de la oficina de Tokio define las direcciones que
aparecen en la mitad superior de la Figura 26. Asimismo, el administrador de la
oficina de París configura las direcciones que aparecen en la mitad inferior de la
figura.
Para VPN basadas en directivas, el dispositivo de seguridad deriva las ID de proxy a

partir de las directivas. Como las ID de proxy utilizadas por los dispositivos de
seguridad situados a ambos extremos del túnel VPN deben coincidir exactamente,
no es posible utilizar la dirección predefinida “ANY”, cuya dirección IP es 0.0.0.0/0,
en un extremo del túnel si se utiliza una dirección más específica en el otro
extremo. Por ejemplo:
Si la ID de proxy de Tokio es como aparece a continuación:
From: 0.0.0.0/0
To: 10.2.2.0/24
Service: ANY
Y si la ID de proxy de París es como aparece a continuación:
To: 10.1.1.0/24
From: 10.2.2.0/24
Service: ANY
Entonces las ID de proxy no coincidirán y las negociaciones IKE fracasarán.
NOTA: A partir de ScreenOS 5.0.0, también es posible definir ID de proxy para túneles
VPN de los que se incluyen referencias en configuraciones VPN basadas en
directivas.
Para las VPN basadas en rutas, es posible utilizar “0.0.0.0/0–0.0.0.0/0–any” para

definir las direcciones IP local y remota y el tipo de servicio para una ID de proxy.
Y luego se pueden utilizar directivas más restrictivas para filtrar el tráfico VPN
entrante y saliente por dirección de origen, dirección de destino y tipo de servicio.

Figura 27: Configuración de túneles punto a punto: Túnel VPN

de Tokio
Tunnel.1, sin numerar
ethernet1 ethernet3, 1.1.1.1/24
10.1.1.1/24 Dispositivo de
Trust_LAN NAT seguridad Trust_LAN
Trust, 10.1.1.0/24 de Tokio Trust 10.2.2.0/24
Internet
LAN LAN
Tokio París
Túnel: vpn1 Dispositivo de Untrust, 10.2.2.0/24
Untrust 10.1.1.0/24
seguridad
de París
ethernet3, 2.2.2.2/24 ethernet1
10.2.2.1/24
tunnel.1, sin numerar NAT
Oficina
de París
3. VPN
Es posible configurar una de las tres VPN siguientes:
AutoKey IKE
El método AutoKey IKE utiliza una clave previamente compartida o un

certificado para renovar (es decir, modificar) las claves de encriptación y
autenticación automáticamente en intervalos definidos por el usuario
(conocidos como periodos de vigencia de clave). En esencia, actualizar estas
claves con frecuencia refuerza la seguridad, aunque unos periodos de vigencia
de clave excesivamente breves pueden reducir el rendimiento general.
Interlocutor dinámico
Un interlocutor dinámico es una puerta de enlace remota que tiene una

dirección IP asignada de forma dinámica. Como es posible que la dirección IP
del interlocutor remoto sea diferente cada vez que comienzan las
negociaciones IKE, los hosts situados detrás del interlocutor deben iniciar el
tráfico VPN. Asimismo (si se utiliza una clave previamente compartida para la
autenticación), el interlocutor debe enviar una ID IKE durante el primer
mensaje de las negociaciones de fase 1 en modo dinámico para identificarse.
Clave manual
El método de clave manual requiere la configuración y actualización manual de

las claves de encriptación y autenticación. Este método es una opción viable
para un pequeño conjunto de túneles VPN.

Figura 28: Configuración de túneles punto a punto: Rutas
trust-vr Oficina
Dest 10.2.2.0/24 Zona Trust Zona Untrust
Utilizar tunnel. 1 de Tokio
tunnel.1, sin numerar Trust_LAN
Dest 10.2.2.0/24 ethernet1 ethernet3, 1.1.1.1/24 Trust, 10.2.2.0/24
Utilizar NULL 10.1.1.1/24 París
Metric: 50 Interfaz Null Enrutador externo, 1.1.1.250 Untrust,
NAT
10.2.2.0/24
Dest 0.0.0.0/0 Internet trust-vr
LAN LAN
Utilizar eth3 Tunnel:vpn1 Dest 10.1.1.0/24
Puerta de enlace: Utilizar tunnel. 1
1.1.1.250
Trust_LAN enrutador externo, 2.2.2.250 Interfaz Null
Dest 10.1.1.0/24
Trust, 10.1.1.0/24 ethernet3, 2.2.2.2/24 ethernet1 Utilizar NULL
10.2.2.1/24 Metric: 50
Tokio tunnel.1, sin numerar NAT
Untrust, 10.1.1.0/24 Oficina de Dest 0.0.0.0/0
Zona Untrust París Zona Trust Utilizar eth3
Puerta de enlace:
2.2.2.250
4. Rutas
Los administradores de cada extremo del túnel deben configurar al menos las rutas
siguientes:
Una ruta para el tráfico destinado a una dirección de la LAN remota a través de
tunnel.1.
Una ruta predeterminada para el resto del tráfico, incluyendo el tráfico de túnel
VPN externo, para el acceso a Internet a través de ethernet3 y el enrutador
externo situado más allá (1.1.1.250 para la oficina de Tokio y 2.2.2.250 para la
de París). El enrutador externo es la puerta de enlace predeterminada hacia la
que el dispositivo de seguridad reenvía todo el tráfico para el que no disponga
de una ruta específica en su tabla de enrutamiento.
NOTA: Si el dispositivo de seguridad de la oficina de Tokio recibe su dirección IP externa

de forma dinámica de su ISP (es decir, si desde el punto de vista de la oficina de
París, el dispositivo de seguridad de la oficina de Tokio es un interlocutor
dinámico), el ISP proporciona automáticamente al dispositivo de Tokio su
dirección IP de puerta de enlace predeterminada.
Una ruta Null, de modo que si en algún momento el estado cambia de tunnel.1
a “fuera de línea” y cualquier ruta que haga referencia a tunnel.1 se desactiva,
el dispositivo de seguridad no utilice la ruta predeterminada para reenviar el
tráfico destinado a la LAN remota fuera de ethernet3 sin encriptar. Una ruta
Null utiliza la LAN remota como dirección de destino, pero envía tráfico a la
interfaz Null, una interfaz lógica que descarta todo el tráfico que recibe. Asigne
a la ruta Null una métrica superior (más alejada de cero) que la ruta a la LAN
remota que utiliza tunnel.1, haciendo la ruta Null menos preferente que la ruta
que hace referencia a la interfaz de tunnel.1.

Figura 29: Configuración de túneles punto a punto: Directivas

trust-vr trust-vr
Dest 10.2.2.0/24 Oficina Dest 10.1.1.0/24
Utilizar tunnel. 1 Zona Trust Zona Untrust
de Tokio Utilizar tunnel. 1
Dest 0.0.0.0/0 tunnel.1, sin numerar Dest 0.0.0.0/0

Utilizar eth1 ethernet1 ethernet3, 1.1.1.1/24 Utilizar eth3
puerta de enlace: 10.1.1.1/24 Interfaz Null puerta de enlace:
1.1.1.250 NAT Enrutador externo, 1.1.1.250 2.2.2.250
Internet Trust_LAN
Trust_LAN LAN LAN
Trust, 10.1.1.0/24 Trust, 10.2.2.0/24
Tunnel:vpn1
Tokio enrutador externo, 2.2.2.250 Interfaz Null París

ethernet1 Untrust,
Untrust,
10.1.1.0/24 ethernet3, 2.2.2.2/24 10.2.2.1/24 10.2.2.0/24
tunnel.1, sin numerar NAT
Trust -> Untrust
Trust -> Untrust Oficina Trust_LAN ->
Trust_LAN ->París Zona Untrust de París Zona Trust París
ANY, Permit ANY), Permit
Untrust -> Trust Untrust -> Trust

París -> Trust_LAN París->
ANY, Permit Trust_LAN
ANY, Permit
5. Directivas
Los administradores de cada extremo del túnel definen directivas para permitir el
tráfico entre las dos oficinas:
Una directiva que permita cualquier tipo de tráfico desde “Trust_LAN” en la

zona Trust hasta “París” o “Tokio” en la zona Untrust
Una directiva que permita cualquier tipo de tráfico desde “París” o “Tokio” en la
zona Untrust hasta “Trust_LAN” en la zona Trust
Como la ruta preferente al punto remoto indica tunnel.1, que está asociada al túnel
VPN vpn1, no es necesario que la directiva haga referencia al túnel VPN.
VPN punto a punto basada en rutas, AutoKey IKE

En este ejemplo, un túnel AutoKey IKE que utiliza un secreto previamente
compartido o un par de certificados (uno por cada extremo del túnel) proporciona
la conexión segura entre las oficinas de Tokio y París. Para los niveles de seguridad
de las fases 1 y 2, debe especificar una propuesta de fase 1 (pre-g2-3des-sha para el
método de clave previamente compartida o rsa-g2-3des-sha para certificados) y
seleccionar el conjunto de propuestas predefinido “Compatible” para la fase 2.
Todas las zonas se encuentran en trust-vr.

Figura 30: VPN punto a punto basada en rutas, AutoKey IKE
Topología de las zonas Topología de las zonas

configuradas en el dispositivo configuradas en el dispositivo
de seguridad de Tokio de seguridad de París
Tokio París Tokio París
Zona Zona Zona Zona

Trust Untrust Untrust Trust
Interfaz de salida Interfaz de salida

Zona Untrust Zona Untrust
eth3, 1.1.1.1/24 eth3, 2.2.2.2/24
Puerta de enlace Puerta de enlace
Tokio 1.1.1.250 2.2.2.250 París
eth1, 10.1.1.1/24 eth1, 10.2.2.1/24
Internet
Túnel VPN
Interfaz de túnel Interfaz de túnel

Tunnel.1 Tunnel.1
La configuración de un túnel AutoKey IKE basado en rutas mediante un secreto

previamente compartido o certificados implica los siguientes pasos:
1. Asignar direcciones IP a las interfaces físicas asociadas a las zonas de seguridad

y a la interfaz de túnel.
2. Configurar el túnel VPN, designar su interfaz de salida en la zona Untrust,

asociarla a la interfaz de túnel y configurar su ID de proxy.
3. Introducir las direcciones IP de los puntos finales local y remoto en las libretas
de direcciones para las zonas Trust y Untrust.
4. Introducir una ruta predeterminada al enrutador externo en trust-vr, una ruta al

destino a través de la interfaz de túnel y otra ruta Null al destino. Asigne una
métrica más alta (más alejada de cero) a la ruta Null para que se convierta en la
siguiente opción de ruta al destino. A continuación, si el estado de la interfaz de
túnel cambia a “fuera de línea” y la ruta que hace referencia a esa interfaz
también se desactiva, el dispositivo de seguridad utiliza la ruta Null, que
descarta todo tráfico enviado hacia él, en lugar de la ruta predeterminada, que
reenvía tráfico no encriptado.
5. Definir directivas para la circulación del tráfico VPN entre ambos sitios.
En los ejemplos siguientes, la clave previamente compartida es h1p8A24nG5. Se

asume que ambos participantes tienen certificados RSA y utilizan Entrust como
autoridad de certificación (CA). (Para más información sobre cómo obtener y cargar
certificados, consulte “Certificados y CRL” en la página 24).

WebUI (Tokio)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

clic en OK:

Interface: ethernet3 (trust-vr)
2. Direcciones
Address Name: Trust_LAN

Zone: Trust
Policy > Policy Elements> > Addresses > List > New: Introduzca los
Address Name: Paris_Office

Zone: Untrust
3. VPN
y haga clic en OK:
Gateway Name: To_Paris



Preshared Key: h1p8A24nG5

en Return para regresar a la página de configuración básica de puerta de
enlace:

Phase 1 Proposal (para nivel de seguridad personalizado):
pre-g2-3des-sha
(o bien)
Certificados

enlace:

rsa-g2-3des-sha
Preferred certificate (opcional)
Peer CA: Entrust
Peer Type: X509-SIG
VPN > AutoKey IKE > New: Introduzca los siguientes datos y haga clic en OK:
VPN Name: Tokyo_Paris

Remote Gateway:
Predefined: (seleccione), To_Paris

IKE:

Bind to: Tunnel Interface, tunnel.1
Service: ANY
4. Rutas



Interface: Tunnel.1

Interface: Null
Metric: 10
5. Directivas
haga clic en OK:
Name: To_Paris
Source Address: Trust_LAN
Destination Address: Paris_Office
Service: ANY
Action: Permit
Policies > (From: Untrust, To: Trust) > New: Introduzca los siguientes datos y
haga clic en OK:
Name: From_Paris
Source Address: Paris_Office
Destination Address: Trust_LAN
Service: ANY
Action: Permit
WebUI (París)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust


clic en OK:

2. Direcciones

Zone: Trust
Address Name: Tokyo_Office

Zone: Untrust
3. VPN
y haga clic en OK:
Gateway Name: To_Tokyo


enlace:

pre-g2-3des-sha
(o bien)

Certificados

enlace:

rsa-g2-3des-sha
Peer CA: Entrust
Peer Type: X509-SIG
Name: Paris_Tokyo
Remote Gateway:
Predefined: (seleccione), To_Tokyo

IKE:

Service: ANY
4. Rutas


Interface: Tunnel.1

Interface: Null
Metric: 10

5. Directivas
haga clic en OK:
Name: To_Tokyo
Source Address:
Address Book Entry: (seleccione), Trust_LAN
Address Book Entry: (seleccione), Tokyo_Office
Service: ANY
Action: Permit
haga clic en OK:
Name: From_Tokyo
Source Address:
Service: ANY
Action: Permit
CLI (Tokio)
1. Interfaces
2. Direcciones
set address trust Trust_LAN 10.1.1.0/24
set address untrust Paris_Office 10.2.2.0/24
3. VPN
set ike gateway To_Paris address 2.2.2.2 main outgoing-interface ethernet3
preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn Tokyo_Paris gateway To_Paris sec-level compatible
set vpn Tokyo_Paris bind interface tunnel.1
set vpn Tokyo_Paris proxy-id local-ip 10.1.1.0/24 remote-ip 10.2.2.0/24 any
(o bien)

Certificado
set ike gateway To_Paris address 2.2.2.2 main outgoing-interface ethernet3
set ike gateway To_Paris cert peer-ca 1
set ike gateway To_Paris cert peer-cert-type x509-sig
set vpn Tokyo_Paris gateway To_Paris sec-level compatible
NOTA: El número 1 es el número de ID de la CA. Para consultar los números ID de CA,

utilice el siguiente comando: get ike ca.
4. Rutas
5. Directivas
set policy top name “To Paris” from trust to untrust Trust_LAN Paris_Office any
permit
set policy top name “From Paris” from untrust to trust Paris_Office Trust_LAN any
permit
save
CLI (París)
1. Interfaces
2. Direcciones
set address untrust Tokyo_Office 10.1.1.0/24
3. VPN
set ike gateway To_Tokyo address 1.1.1.1 main outgoing-interface ethernet3
set vpn Paris_Tokyo gateway To_Tokyo sec-level compatible
set vpn Paris_Tokyo bind interface tunnel.1
set vpn Paris_Tokyo proxy-id local-ip 10.2.2.0/24 remote-ip 10.1.1.0/24 any
(o bien)
Certificado
set ike gateway To_Tokyo address 1.1.1.1 main outgoing-interface ethernet3
set ike gateway To_Tokyo cert peer-ca 1
set ike gateway To_Tokyo cert peer-cert-type x509-sig
set vpn Paris_Tokyo gateway To_Tokyo sec-level compatible

4. Rutas
5. Directivas
set policy top name “To Tokyo” from trust to untrust Trust_LAN Tokyo_Office any
permit
set policy top name “From Tokyo” from untrust to trust Tokyo_Office Trust_LAN any
permit
save
VPN punto a punto basada en directivas, AutoKeyIKE

En este ejemplo, un túnel AutoKey IKE que utiliza un secreto previamente
la conexión segura entre las oficinas de Tokio y París. Para los niveles de seguridad
de las fases 1 y 2, debe especificar una propuesta de fase 1 (pre-g2-3des-sha para el
método de clave previamente compartida o rsa-g2-3des-sha para certificados) y
seleccionar el conjunto de propuestas predefinido “Compatible” para la fase 2.
Todas las zonas se encuentran en trust-vr.
Figura 31: VPN punto a punto basada en directivas, AutoKey IKE

Zona Zona Zona Zona Zona Zona

Trust Untrust-Tun Untrust Untrust Untrust-Tun Untrust

eth3, 1.1.1.1/24 eth3, 2.2.2.2/24
Tokio 1.1.1.250 2.2.2.250 París
eth1, 10.1.1.1/24 eth1, 10.2.2.1/24
Internet
Túnel VPN
La configuración de un túnel AutoKey IKE utilizando AutoKey IKE mediante un

secreto previamente compartido o certificados implica los siguientes pasos:
1. Definir las direcciones IP de la interfaz de zona de seguridad.
2. Realizar entradas en la libreta de direcciones para las entidades finales local y

remota.
3. Definir la puerta de enlace remota y el modo de intercambio de claves,

y especificar un secreto previamente compartido o un certificado.
4. Crear la VPN Autokey IKE.

5. Configurar una ruta predeterminada que conduzca al enrutador externo.
6. Configurar directivas.

certificados, consulte “Certificados y CRL” en la página 24).
WebUI (Tokio)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Direcciones

Zone: Trust

Zone: Untrust
3. VPN
y haga clic en OK:




para regresar a la página de configuración básica de puerta de enlace:

pre-g2-3des-sha
(o bien)
Certificados


rsa-g2-3des-sha
Peer CA: Entrust
Peer Type: X509-SIG

Remote Gateway: Predefined: (seleccione), To_Paris
4. Ruta

5. Directivas
haga clic en OK:
Name: To/From Paris

Source Address:
Address Book Entry: (seleccione), Paris_Office
Service: ANY
Action: Zona
Tunnel VPN: Tokyo_Paris

WebUI (París)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Direcciones

Zone: Trust

Zone: Untrust
3. VPN
y haga clic en OK:




enlace:

pre-g2-3des-sha
(o bien)
Certificados

enlace:

rsa-g2-3des-sha
Peer CA: Entrust
Peer Type: X509-SIG
VPN Name: Paris_Tokyo

Remote Gateway: Predefined: (seleccione), To_Tokyo
4. Ruta


5. Diresctivas
haga clic en OK:
Name: To/From Tokyo

Source Address:
Service: ANY
Action: Zona
Tunnel VPN: Paris_Tokyo
CLI (Tokio)
1. Interfaces
2. Direcciones
set address untrust paris_office 10.2.2.0/24
3. VPN
set ike gateway to_paris address 2.2.2.2 main outgoing-interface ethernet3
set vpn tokyo_paris gateway to_paris sec-level compatible
(o bien)
Certificados
set ike gateway to_paris address 2.2.2.2 main outgoing-interface ethernet3
set ike gateway to_paris cert peer-ca 1
set ike gateway to_paris cert peer-cert-type x509-sig

4. Ruta
5. Directivas
set policy top name “To/From Paris” from trust to untrust Trust_LAN paris_office
any tunnel vpn tokyo_paris
set policy top name “To/From Paris” from untrust to trust paris_office Trust_LAN
save

CLI (París)
1. Interfaces
2. Direcciones
set address untrust tokyo_office 10.1.1.0/24
3. VPN
set ike gateway to_tokyo address 1.1.1.1 main outgoing-interface ethernet3
set vpn paris_tokyo gateway to_tokyo sec-level compatible
(o bien)
Certificados
set ike gateway to_tokyo cert peer-ca 1
set ike gateway to_tokyo cert peer-cert-type x509-sig
set vpn paris_tokyo gateway to_tokyo tunnel proposal nopfs-esp-3des-sha
4. Ruta
5. Directivas
set policy top name “To/From Tokyo” from trust to untrust Trust_LAN tokyo_office
any tunnel vpn paris_tokyo
set policy top name “To/From Tokyo” from untrust to trust tokyo_office Trust_LAN
save
VPN punto a punto basada en rutas, interlocutor dinámico

En este ejemplo, un túnel VPN AutoKey IKE que utiliza una clave previamente
compartida o un par de certificados (uno por cada extremo del túnel) proporciona
la conexión segura entre los dispositivos de seguridad para proteger las oficinas de
Tokio y París. La interfaz de la zona Untrust para el dispositivo de seguridad de París
cuenta con una dirección IP estática. El ISP de la oficina de Tokio asigna la dirección
IP para la interfaz de zona Untrust de forma dinámica a través del protocolo DHCP.
Como sólo el dispositivo de seguridad de París tiene una dirección fija para su zona
Untrust, el tráfico VPN se debe originar desde los hosts de la oficina de Tokio. Una
vez establecido un túnel, el tráfico que atraviese el túnel se puede originar desde
cualquier extremo de dicho túnel. Todas las zonas de túnel y de seguridad se
encuentran en trust-vr.

Figura 32: VPN punto a punto basada en rutas, interlocutor dinámico

Zona Zona
Zona Zona Trust
Untrust Untrust
Trust
Tokio eth3 y puerta de enlace eth3, 2.2.2.2/24 París
Zona Trust asignadas dinámicamente Puerta de enlace Zona Trust
eth1, 10.1.1.1/24 por el ISP 2.2.2.250 eth1, 10.2.2.1/24
Internet
Túnel VPN

Tunnel.1 Tunnel.1
Servidor DHCP
2.1.1.5
La clave previamente compartida es h1p8A24nG5. Se parte de la base de que

ambos participantes ya tienen certificados RSA emitidos por la autoridad de
certificación (CA) Verisign y que la dirección de correo electrónico pmason@abc.com
aparece en el certificado local del dispositivo A. (Para obtener más información
sobre la adquisición y la carga de certificados, consulte “Certificados y CRL” en la
página 24). Para los niveles de seguridad de las fases 1 y 2, debe especificar una
propuesta de fase 1 (pre-g2-3des-sha para el método de clave previamente
compartida o rsa-g2-3des-sha para certificados) y seleccionar el conjunto de
propuestas “Compatible” para la fase 2.
Indique tres rutas en los dispositivos de seguridad en cada extremo del túnel VPN:
Una ruta predeterminada que conduzca al enrutador externo en trust-vr
Una ruta al destino a través de la interfaz de túnel
Una ruta Null al destino. Asigne una métrica más alta (más alejada de cero) a la
ruta Null para que se convierta en la siguiente opción de ruta al destino.
A continuación, si el estado de la interfaz de túnel cambia a “fuera de línea” y la
ruta que hace referencia a esa interfaz también se desactiva, el dispositivo de
seguridad utiliza la ruta Null, que descarta todo tráfico enviado hacia él, en
lugar de la ruta predeterminada, que reenvía tráfico no encriptado.
Finalmente, configure directivas para permitir tráfico bidireccional entre los dos
sitios.
WebUI (Tokio)
1. Interfaces
haga clic en Apply:
Zone Name: Trust


Interface Mode: NAT
haga clic en Apply:
Zone Name: Untrust
Obtain IP using DHCP: (seleccione)

clic en OK:

2. Direcciones

Zone: Trust

Zone: Untrust
3. VPN
y haga clic en OK:

Local ID: pmason@abc.com


enlace:

pre-g2-3des-sha
Mode (Initiator): Aggressive
(o bien)
Certificados
NOTA: El U-FQDN “pmason@abc.com” debe aparecer en el campo SubjectAltName del

certificado.

enlace:

rsa-g2-3des-sha
Preferred Certificate (opcional):
Peer CA: Verisign
Peer Type: X509-SIG

Remote Gateway:

IKE:

Service: ANY
4. Rutas


NOTA: El ISP proporciona la dirección IP de la puerta de enlace de forma dinámica a

través del protocolo DHCP.

Interface: Tunnel.1

Interface: Null
Metric: 10
5. Directivas
haga clic en OK:
Source Address:
Service: Any
Action: Permit
haga clic en OK:
Source Address:
Service: Any
Action: Permit
WebUI (París)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT

haga clic en OK:
Zone Name: Untrust

IP Address: 2.2.2.2/24
clic en OK:

2. Direcciones

Zone: Trust

Zone: Untrust
3. VPN
y haga clic en OK:

Dynamic IP Address: (seleccione), Peer ID: pmason@abc.com

enlace:

pre-g2-3des-sha
(o bien)

Certificados

enlace:

rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
VPN Name: Paris_Tokyo

Remote Gateway:

IKE:

Service: ANY
4. Rutas

Gateway IP Address: (seleccione), 2.2.2.250

Interface: Tunnel.1

Interface: Null
Metric: 10

5. Directivas
haga clic en OK:
Source Address:
Service: Any
Action: Permit
haga clic en OK:
Source Address:
Service: Any
Action: Permit
CLI (Tokio)
1. Interfaces
set interface ethernet3 dhcp client
set interface ethernet3 dhcp client settings server 1.1.1.5
2. Direcciones
3. VPN
set ike gateway To_Paris address 2.2.2.2 aggressive local-id pmason@abc.com
outgoing-interface ethernet3 preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn Tokyo_Paris gateway To_Paris tunnel sec-level compatible
(o bien)
Certificados
set ike gateway To_Paris address 2.2.2.2 aggressive local-id pmason@abc.com
outgoing-interface ethernet3 proposal rsa-g2-3des-sha
set ike gateway To_Paris cert peer-ca 1
set ike gateway To_Paris cert peer-cert-type x509-sig
set vpn Tokyo_Paris gateway To_Paris tunnel sec-level compatible


certificado.
El número 1 es el número de ID de la CA. Para consultar los números ID de CA,

4. Rutas

través del protocolo DHCP, por lo tanto, no se puede especificar aquí.
5. Directivas
set policy top from trust to untrust Trust_LAN Paris_Office any permit
set policy top from untrust to trust Paris_Office Trust_LAN any permit
save
CLI (París)
1. Interfaces
2. Direcciones
3. VPN
set ike gateway To_Tokyo dynamic pmason@abc.com aggressive outgoing-interface
ethernet3 preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn Paris_Tokyo gateway To_Tokyo tunnel sec-level compatible
(o bien)
Certificados
set ike gateway To_Tokyo dynamic pmason@abc.com aggressive outgoing-interface
ethernet3 proposal rsa-g2-3des-sha
set ike gateway To_Tokyo cert peer-ca 1
set ike gateway To_Tokyo cert peer-cert-type x509-sig
set vpn Paris_Tokyo gateway To_Tokyo tunnel sec-level compatible


4. Rutas
5. Directivas
set policy top from trust to untrust Trust_LAN Tokyo_Office any permit
set policy top from untrust to trust Tokyo_Office Trust_LAN any permit
save
VPN punto a punto basada en directivas, interlocutor dinámico

En este ejemplo, un túnel VPN conecta de forma segura a los usuarios de la zona
Trust situados detrás del dispositivo A con el servidor de correo de la zona
corporativa DMZ protegida por el dispositivo B. La interfaz de zona Untrust para el
dispositivo B tiene una dirección IP estática. El ISP del dispositivo A asigna la
dirección IP para su interfaz de zona Untrust de forma dinámica a través del
protocolo DHCP. Puesto que sólo el dispositivo B tiene una dirección fija para su
zona Untrust, el tráfico VPN se debe originar desde los hosts situados detrás del
dispositivo A. Una vez que el dispositivo A haya establecido el túnel, el tráfico que
atraviese el túnel se puede originar desde cualquiera de sus extremos. Todas las
zonas se encuentran en el dominio de enrutamiento trust-vr.
Figura 33: VPN punto a punto basada en directivas, interlocutor dinámico

configuradas en dispositivo-A configuradas en el dispositivo
en la sucursal. B en la sede central
A B A B
Zona Zona Zona Zona

Trust Untrust Untrust DMZ

Zona Untrust Zona Untrust Oficina
Sucursal eth3 y puerta de enlace eth3, 2.2.2.2/24 corporativa
Zona Trust asignados dinámicamente Gateway 2.2.2.250 Zona DMZ
eth1, 10.1.1.1/24 por el ISP eth2, 3.3.3.3/24
Servidor de
Internet correo
electrónico
Dispositivo A Túnel VPN Dispositivo B 3.3.3.5
Petición Petición
SMTP o POP3 Servidor IDENT
DHCP
ID Usuario de 2.1.1.5
autenticación
Nombre de usuario: pmason
Contraseña: Nd4syst4
Nota: Antes de realizar una conexión SMTP o POP3 con el
servidor de correo corporativo, Phil debe iniciar primero una
Phil conexión HTTP, FTP o Telnet para que el dispositivo A
pueda autenticarle.

En este ejemplo, el usuario de autenticación local Phil (nombre de usuario: pmason;

contraseña: Nd4syst4) desea recoger su correo electrónico del servidor de correo
electrónico del sitio corporativo. Cuando intenta hacerlo, pasa por dos
autenticaciones: primero, el dispositivo A le autentica de forma local antes de
permitir que el tráfico originado por él atraviese el túnel; después, el programa de
servidor de correo le autentica de nuevo enviando una petición IDENT a través del
túnel.
NOTA: Como Phil es un usuario de autenticación, antes de que pueda realizar una
petición SMTP o POP3, debe iniciar primero una conexión HTTP, FTP o Telnet
para que el dispositivo A pueda responder con un mensaje de petición de inicio de
sesión/usuario de cortafuegos para autenticarle. Una vez que el dispositivo A le
haya autenticado, tendrá permiso para establecer contacto con el servidor de
correo corporativo a través del túnel VPN.
El servidor de correo puede enviar la petición IDENT a través del túnel sólo si los
administradores de los dispositivos A y B agregan un servicio personalizado para
ello (TCP, puerto 113) y configuran directivas que permitan el tráfico a través del
túnel hacia la subred 10.10.10.0/24.
La clave previamente compartida es h1p8A24nG5. Se parte de la base de que

ambos participantes ya tienen certificados RSA emitidos por la autoridad de
certificación (CA) Verisign y que la dirección de correo electrónico pmason@abc.com
aparece en el certificado local del dispositivo A. (Para obtener más información
sobre la adquisición y la carga de certificados, consulte “Certificados y CRL” en la
página 24). Para los niveles de seguridad de la fase 1 y fase 2, debe especificar una
propuestas “Compatible” para la fase 2.
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust



2. Usuario
Objects > Users > Local > New: Introduzca los siguientes datos y haga clic
en OK:
User Name: pmason

Status: Enable
Authentication User: (seleccione)
User Password: Nd4syst4
Confirm Password: Nd4syst4
3. Direcciones
Address Name: Trusted_network

Zone: Trust
Address Name: Mail_Server

Zone: Untrust
4. Servicios
Service Name: Ident

Service Timeout:
Use protocol default: (seleccione)
Source Port: Low 0, High 65535
Destination Port: Low 113, High 113
Policy > Policy Elements > Services > Group > New: Introduzca los
siguientes datos, mueva los siguientes servicios; finalmente, haga clic en OK:
Group Name: Remote_Mail

Group Members << Available Members:
HTTP
FTP
Telnet
Ident
MAIL
POP3

5. VPN
y haga clic en OK:
Gateway Name: To_Mail


enlace:

pre-g2-3des-sha
(o bien)
Certificados

enlace:

rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
Name: branch_corp
Remote Gateway Tunnel: To_Mail
6. Ruta



7. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (select), Trusted_network
Service: Remote_Mail
Action: Tunnel
VPN Tunnel: branch_corp

en Return para regresar a la página de configuración básica de directivasy:
Authentication: (seleccione)
Auth Server: Cliente FTP
User: (seleccione), Local Auth User - pmason
WebUI (dispositivo-B)
1. Interfaces
haga clic en OK:
Zone Name: DMZ

haga clic en OK:
Zone Name: Untrust

2. Direcciones

Zone: DMZ

Address Name: branch office

Zone: Untrust
3. Servicios
Service Name: Ident

Service Timeout:

Ident
MAIL
POP3
4. VPN
y haga clic en OK:
Gateway Name: To_branch

Dynamic IP Address: (seleccione), Peer ID: pmason@abc.com

enlace:

pre-g2-3des-sha
(o bien)

Certificados

enlace:

rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
VPN Name: corp_branch

Remote Gateway:
Predefined: (seleccione), To_branch
5. Ruta

6. Directivas
Policies > (From: DMZ, To: Untrust) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: (select), branch_office
Action: Tunnel
VPN Tunnel: corp_branch
CLI (dispositivo-A)
1. Interfaces
set interface ethernet3 dhcp client
set interface ethernet3 dhcp client settings server 1.1.1.5
2. Usuario
set user pmason password Nd4syst4

3. Direcciones
set address trust “trusted network” 10.1.1.0/24
set address untrust “mail server” 3.3.3.5/32
4. Servicios
set service ident protocol tcp src-port 0-65535 dst-port 113-113
set group service remote_mail
set group service remote_mail add http
set group service remote_mail add ftp
set group service remote_mail add telnet
set group service remote_mail add ident
set group service remote_mail add mail
set group service remote_mail add pop3
5. VPN
set ike gateway to_mail address 2.2.2.2 aggressive local-id pmason@abc.com
set vpn branch_corp gateway to_mail sec-level compatible
(o bien)
Certificados
set ike gateway to_mail address 2.2.2.2 aggressive local-id pmason@abc.com
set ike gateway to_mail cert peer-ca 1
set ike gateway to_mail cert peer-cert-type x509-sig
set vpn branch_corp gateway to_mail sec-level compatible

certificado.

6. Ruta

7. Directivas
set policy top from trust to untrust “trusted network” “mail server” remote_mail
tunnel vpn branch_corp auth server Local user pmason
set policy top from untrust to trust “mail server” “trusted network” remote_mail
tunnel vpn branch_corp
save
CLI (dispositivo-B)
1. Interfaces

2. Direcciones
set address dmz “mail server” 3.3.3.5/32
set address untrust “branch office” 10.1.1.0/24
3. Servicios
4. VPN
set ike gateway to_branch dynamic pmason@abc.com aggressive
set vpn corp_branch gateway to_branch tunnel sec-level compatible
(o bien)
Certificados
set ike gateway to_branch dynamic pmason@abc.com aggressive
set ike gateway to_branch cert peer-ca 1
set ike gateway to_branch cert peer-cert-type x509-sig
set vpn corp_branch gateway to_branch sec-level compatible

5. Ruta
6. Directivas
set policy top from dmz to untrust “mail server” “branch office” remote_mail
tunnel vpn corp_branch
set policy top from untrust to dmz “branch office” “mail server” remote_mail
tunnel vpn corp_branch
save
VPN punto a punto basada en rutas, clave manual

En este ejemplo, un túnel con clave manual ofrece un canal de comunicación
segura entre las oficinas de Tokio y París. Las zonas Trust de cada punto se
encuentran en modo NAT. Las direcciones son las siguientes:
Tokio:
Interfaz de zona Trust (ethernet1): 10.1.1.1/24
Interfaz de zona Untrust (ethernet3): 1.1.1.1/24
París:
Interfaz de zona Trust (ethernet1): 10.2.2.1/24
Interfaz de zona Untrust (ethernet3): 2.2.2.2/24

Las zonas de seguridad Trust y Untrust se encuentran en el dominio de

enrutamiento trust-vr. La interfaz de zona Untrust (ethernet3) actúa como interfaz
de salida para el túnel VPN.
Figura 34: VPN punto a punto basada en rutas, clave manual

de seguridad de Tokio. de seguridad de París.
Zona Zona Zona Zona

eth3, 1.1.1.1/24 eth3, 2.2.2.2/24
Tokio 1.1.1.250 2.2.2.250 París
eth1, 10.1.1.1/24 eth1, 10.2.2.1/24
Internet
Túnel VPN

Tunnel.1 Tunnel.1
Para configurar el túnel, lleve a cabo los siguientes pasos en los dispositivos de
seguridad situados a ambos extremos del túnel:

2. Configurar el túnel VPN, designar su interfaz de salida en la zona Untrust y

asociarla a la interfaz de túnel.


WebUI (Tokio)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

clic en OK:

2. Direcciones

Zone: Trust

Zone: Untrust
3. VPN
VPN Tunnel Name: Tokyo_Paris

Gateway IP: 2.2.2.2
Security Index: 3020 (Local), 3030 (Remote)
Encryption Algorithm: 3DES-CBC
Generate Key by Password: asdlk24234
Authentication Algorithm: SHA-1
Generate Key by Password: PNas134a

> Advanced: Introduzca los siguientes ajustes avanzados; luego haga clic
en Return para regresar a la página de configuración básica del túnel de clave
manual:

4. Rutas


Interface: tunnel.1

Interface: Null
Metric: 10
5. Directivas
haga clic en OK:
Name: To_Paris
Source Address:
Service: ANY
Action: Permit
haga clic en OK:
Name: From_Paris
Source Address:
Service: ANY
Action: Permit

WebUI (París)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

clic en OK:

2. Direcciones

Zone: Trust

Zone: Untrust
3. VPN
VPN Tunnel Name: Paris_Tokyo

Gateway IP: 1.1.1.1

en Return para regresar a la página de configuración básica del túnel de
clave manual:

4. Rutas


Interface: tunnel.1

Interface: Null
Metric: 10
5. Directivas
haga clic en OK:
Name: To_Tokyo
Source Address:
Service: ANY
Action: Permit
haga clic en OK:
Name: From_Tokyo
Source Address:
Service: ANY
Action: Permit

CLI (Tokio)
1. Interfaces
2. Direcciones
3. VPN
set vpn Tokyo_Paris manual 3020 3030 gateway 2.2.2.2 outgoing-interface
ethernet3 esp 3des password asdlk24234 auth sha-1 password PNas134a
4. Rutas
5. Directivas
set policy top name “To Paris” from trust to untrust Trust_LAN Paris_Office any
permit
set policy top name “From Paris” from untrust to trust Paris_Office Trust_LAN any
permit
save
CLI (París)
1. Interfaces
2. Direcciones
3. VPN
set vpn Paris_Tokyo manual 3030 3020 gateway 1.1.1.1 outgoing-interface
4. Rutas

5. Directivas
set policy top name “To Tokyo” from trust to untrust Trust_LAN Tokyo_Office any
permit
set policy top name “From Tokyo” from untrust to trust Tokyo_Office Trust_LAN any
permit
save
VPN punto a punto basada en directivas, clave manual

En este ejemplo, un túnel con clave manual ofrece un canal de comunicación
segura entre las oficinas de Tokio y París utilizando ESP con encriptación 3DES y
autenticación SHA-1. Las zonas Trust de cada punto se encuentran en modo NAT.
Las direcciones son las siguientes:
Tokio:
Interfaz Trust (ethernet1): 10.1.1.1/24
Interfaz Untrust (ethernet3): 1.1.1.1/24
París:
Interfaz Trust (ethernet1): 10.2.2.1/24
Interfaz Untrust (ethernet3): 2.2.2.2/24
Las zonas de seguridad Trust y Untrust y la zona de túnel Untrust-Tun se encuentran

en el dominio de enrutamiento trust-vr. La interfaz de zona Untrust (ethernet3)
actúa como interfaz de salida para el túnel VPN.
Figura 35: VPN punto a punto basada en directivas, clave manual

de seguridad de Tokio. de seguridad de París.
Zona Zona Zona Zona Zona Zona

Trust Untrust-Tun Untrust Untrust Untrust-Tun Trust

ethernet3, 1.1.1.1/24 ethernet3, 2.2.2.2/24
Tokio 2.2.2.250 París
1.1.1.250
Internet
Túnel VPN
Para configurar el túnel, lleve a cabo los siguientes pasos en los dispositivos de
seguridad situados a ambos extremos del túnel:
1. Asignar direcciones IP a las interfaces físicas asociadas a las zonas de

seguridad.

2. Configurar el túnel VPN y designar su interfaz de salida en la zona Untrust.
4. Introducir una ruta predeterminada que conduzca al enrutador externo.
5. Configurar directivas para que el tráfico VPN circule de forma bidireccional por
el túnel.
WebUI (Tokio)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Direcciones

Zone: Trust

Zone: Untrust

3. VPN
VPN Tunnel Name: Tokyo_Paris

Gateway IP: 2.2.2.2
clave manual:
Bind to: Tunnel Zone, Untrust-Tun

4. Ruta

5. Directivas
haga clic en OK:
Name: To/From Paris

Source Address:
Service: ANY
Action: Zona
Tunnel VPN: Tokyo_Paris
WebUI (París)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT

Network > Interfaces > Edit (para ethernet3): Introduzca los siguientes
Zone Name: Untrust
2. Direcciones

Zone: Trust

Zone: Untrust
3. VPN
VPN Tunnel Name: Paris_Tokyo

Gateway IP: 1.1.1.1
Security Index (HEX Number): 3030 (Local), 3020 (Remote)
clave manual:

4. Ruta


5. Directivas
haga clic en OK:
Name: To/From Tokyo

Source Address:
Service: ANY
Action: Zona
Tunnel VPN: Paris_Tokyo
CLI (Tokio)
1. Interfaces
2. Direcciones
3. VPN
set vpn tokyo_paris manual 3020 3030 gateway 2.2.2.2 outgoing-interface
set vpn tokyo_paris bind zone untrust-tun
4. Ruta
5. Directivas
set policy top name “To/From Paris” from trust to untrust Trust_LAN paris_office
set policy top name “To/From Paris” from untrust to trust paris_office Trust_LAN
save
CLI (París)
1. Interfaces
2. Direcciones

3. VPN
set vpn paris_tokyo manual 3030 3020 gateway 1.1.1.1 outgoing-interface
set vpn paris_tokyo bind zone untrust-tun
4. Ruta
5. Directivas
set policy top name “To/From Tokyo” from trust to untrust Trust_LAN tokyo_office
set policy top name “To/From Tokyo” from untrust to trust tokyo_office Trust_LAN
save
Puertas de enlace IKE dinámicas con FQDN

Para un interlocutor IKE que obtenga su dirección IP de forma dinámica, es posible
especificar su nombre de dominio completo (FQDN) en la configuración local para
la puerta de enlace remota. Por ejemplo, un proveedor de servicios de Internet (ISP)
podría asignar direcciones IP a sus clientes a través del protocolo DHCP. El ISP toma
direcciones de un amplio conjunto de direcciones y las asigna cuando los clientes se
conectan en línea. Aunque el interlocutor IKE posee un FQDN que no varía, tiene
una dirección IP que cambia de forma impredecible. El interlocutor IKE dispone de
tres métodos para mantener una asignación DNS (Domain Name System) entre su
FQDN y su dirección IP asignada de forma dinámica (un proceso denominado DNS
dinámico).
Si el interlocutor IKE remoto es un dispositivo de seguridad, el administrador

puede avisar manualmente al servidor DNS para que actualice su asignación
entre FQDN y dirección IP cada vez que el dispositivo de seguridad reciba una
dirección IP nueva de su ISP.
Si el interlocutor IKE remoto es cualquier otro tipo de dispositivo terminal VPN

en el que se esté ejecutando software DNS dinámico, dicho software puede
notificar al servidor DNS sus cambios de dirección para que el servidor
actualice su tabla de asignación entre FQDN y dirección IP.
Si el interlocutor IKE remoto es un dispositivo de seguridad o cualquier otro tipo

de dispositivo terminal VPN, un host ubicado detrás de él puede ejecutar un
programa de actualización automática entre FQDN y dirección IP que avise al
servidor DNS de los cambios de dirección.
132 Puertas de enlace IKE dinámicas con FQDN

Figura 36: Interlocutor IKE con dirección IP dinámica
Dispositivo de seguridad local Interlocutor IKE
Internet
www.jnpr.net
Túnel VPN
1.1.1.202 = www.jnpr.net
1. El servidor DHCP toma la dirección 1.1.1.202 de su conjunto de Conjunto de direcciones IP

direcciones IP y la asigna al interlocutor IKE.
2. El interlocutor IKE notifica al servidor DNS la nueva dirección

para que éste pueda actualizar su tabla de asignación entre
FQDN y dirección IP.
1.1.1.10 – Servidor DHCP Servidor DNS
1.1.7.9
Sin necesidad de conocer la dirección IP actual de un interlocutor IKE remoto, es

posible configurar un túnel VPN AutoKey IKE que conecte con dicho interlocutor
utilizando su FQDN en lugar de una dirección IP.
Alias
También es posible utilizar un alias para el FQDN del interlocutor IKE remoto si el
servidor DNS al que consulta el dispositivo de seguridad local devuelve sólo una
dirección IP. Si el servidor DNS devuelve varias direcciones IP, el dispositivo local
utilizará la primera que reciba. Como no existe ninguna garantía sobre el orden de
aparición de las direcciones en la respuesta del servidor DNS, es posible que el
dispositivo de seguridad local utilice la dirección IP incorrecta y, por tanto, las
negociaciones IKE podrían fracasar.
Figura 37: Respuestas múltiples de DNS que derivan en el éxito o el fracaso de la negociación IKE
Dispositivo de seguridad local El dispositivo de seguridad local desea Interlocutor IKE remoto
establecer un túnel VPN IKE con su
interlocutor remoto. Utiliza www.jnpr.net
como dirección de puerta de enlace remota.
Consulta DNS: www.jnpr.net = IP ?

Dispositivo de seguridad local Servidor DNS
Respuesta DNS:
El dispositivo utiliza
esta dirección IP. www.jnpr.net = 1.1.1.202
www.jnpr.net = 1.1.1.114
www.jnpr.net = 1.1.1.20
Dispositivo de seguridad local Si el interlocutor IKE remoto se encuentra en 1.1.1.202, Interlocutor IKE remoto
las negociaciones IKE se desarrollan con éxito.
Si el interlocutor IKE remoto

Dispositivo de seguridad local se encuentra en 1.1.1.114 Interlocutor IKE remoto
o bien
1.1.1.20, las negociaciones
IKE fracasan.
Puertas de enlace IKE dinámicas con FQDN 133

Ajuste del interlocutor AutoKey IKE con FQDN

En este ejemplo, un túnel VPN AutoKey IKE que utiliza un secreto previamente
una conexión segura entre dos oficinas de Tokio y París. La oficina de París tiene
una dirección IP asignada de forma dinámica, por lo que la oficina de Tokio utiliza
el FQDN del interlocutor remoto (www.nspar.com) como dirección de la puerta de
enlace remota en su configuración de túnel VPN.
La configuración que aparece en la Figura 38 corresponde a un túnel VPN basado

en rutas. Para los niveles de seguridad de las fases 1 y 2, debe especificar una
propuestas predefinido “Compatible” para la fase 2. Todas las zonas se encuentran
en trust-vr.
Figura 38: Interlocutor AutoKey IKE con FQDN

Zona Zona Zona Zona

Interfaz de salida
Interfaz de salida Zona Untrust
Zona Untrust ethernet3, IP y puerta de
ethernet3, 1.1.1.1/24 enlace a través del
Puerta de enlace protocolo DHCP
Tokio www.nspar.com París
Zona Trust 1.1.1.250 Zona Trust
Internet
Túnel VPN
Interfaz Tunnel: tunnel.1 Interfaz Tunnel: tunnel.1

Puerta de enlace remota: www.nspar.com Puerta de enlace remota: 1.1.1.1
La configuración de un túnel AutoKey IKE basado en rutas mediante un secreto

previamente compartido o certificados implica los siguientes pasos:

2. Definir la puerta de enlace remota y el modo de intercambio de claves,

y especificar un secreto previamente compartido o un certificado.
3. Configurar el túnel VPN, designar su interfaz de salida en la zona Untrust,

asociarla a la interfaz de túnel y configurar su ID de proxy.


6. Definir directivas para la circulación del tráfico entre ambos sitios.

certificados, consulte “Criptografía de claves públicas” en la página 19).
WebUI (Tokio)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

IP Address/Netmask: 1.1.1.1
clic en OK:

2. Direcciones

Zone: Trust


Zone: Untrust
3. VPN
y haga clic en OK:

Static IP Address: (seleccione), IP Address/Hostname: www.nspar.com

enlace:

pre-g2-3des-sha
(o bien)
Certificados

enlace:

rsa-g2-3des-sha
Peer CA: Entrust
Peer Type: X509-SIG

Remote Gateway:


IKE:

Service: ANY
4. Rutas



Interface: tunnel.1

Interface: Null
Metric: 10
5. Directivas
haga clic en OK:
Name: To_Paris
Destination Address: Paris_Office
Service: ANY
Action: Permit

Policies > Policy (From: Untrust, To: Trust) > New Policy: Introduzca los
Name: From_Paris
Source Address: Paris_Office
Service: ANY
Action: Permit
WebUI (París)
1. Nombre de host y nombre de dominio
Network > DNS: Introduzca los siguientes datos y haga clic en Apply:
Host Name: www

Domain Name: nspar.com
2. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

clic en OK:

3. Direcciones

Zone: Trust


Zone: Untrust
4. VPN
y haga clic en OK:


enlace:

pre-g2-3des-sha
(o bien)
Certificados

enlace:

rsa-g2-3des-sha
Peer CA: Entrust
Peer Type: X509-SIG
Name: Paris_Tokyo
Remote Gateway:


IKE:

Service: ANY
5. Rutas


Interface: tunnel.1

Interface: Null
Metric: 10
6. Directivas
haga clic en OK:
Name: To_Tokyo
Destination Address: Tokyo_Office
Service: ANY
Action: Permit
haga clic en OK:
Name: From_Tokyo
Source Address: Tokyo_Office
Service: ANY
Action: Permit

CLI (Tokio)
1. Interfaces
2. Direcciones
3. VPN
set ike gateway to_paris address www.nspar.com main outgoing-interface
set vpn tokyo_paris bind interface tunnel.1
set vpn tokyo_paris proxy-id local-ip 10.1.1.0/24 remote-ip 10.2.2.0/24 any
(o bien)
Certificado
set ike gateway to_paris address www.nspar.com main outgoing-interface
set ike gateway to_paris cert peer-ca 1
set ike gateway to_paris cert peer-cert-type x509-sig
set vpn tokyo_paris bind interface tunnel.1
set vpn tokyo_paris proxy-id local-ip 10.1.1.0/24 remote-ip 10.2.2.0/24 any

4. Rutas
5. Directivas
set policy top name “To Paris” from trust to untrust Trust_LAN paris_office any
permit
set policy top name “From Paris” from untrust to trust paris_office Trust_LAN any
permit
save
CLI (París)
1. Nombre de host y nombre de dominio
set hostname www
set domain nspar.com

2. Interfaces
set interface ethernet3 ip dhcp-client enable
3. Direcciones
4. VPN
set vpn paris_tokyo bind interface tunnel.1
set vpn paris_tokyo proxy-id local-ip 10.2.2.0/24 remote-ip 10.1.1.0/24 any
(o bien)
Certificado
set ike gateway to_tokyo cert peer-ca 1
set ike gateway to_tokyo cert peer-cert-type x509-sig
set vpn paris_tokyo bind interface tunnel.1
set vpn paris_tokyo proxy-id local-ip 10.2.2.0/24 remote-ip 10.1.1.0/24 any
5. Rutas
6. Directivas
set policy top name “To Tokyo” from trust to untrust Trust_LAN tokyo_office any
permit
set policy top name “From Tokyo” from untrust to trust tokyo_office Trust_LAN any
permit
save
Sitios VPN con direcciones superpuestas

Como el rango de direcciones IP privadas es relativamente pequeño, es bastante
probable que las direcciones de las redes protegidas de dos interlocutores VPN se
superpongan. Para el tráfico VPN bidireccional entre dos entidades finales con
direcciones superpuestas, los dispositivos de seguridad de los dos extremos del
túnel deben aplicar una traducción de direcciones de red de origen y de destino
(NAT-src y NAT-dst) al tráfico VPN que circule entre ellos.
NOTA: Un espacio de direcciones superpuesto se produce cuando los rangos de

direcciones IP de dos redes coinciden parcial o totalmente.
142 Sitios VPN con direcciones superpuestas

Para NAT-src, las interfaces situadas a ambos extremos del túnel deben poseer
direcciones IP en subredes exclusivas entre sí, con un conjunto de direcciones IP
dinámicas (DIP) en cada una de dichas subredes. Las directivas que regulan el
tráfico VPN saliente pueden aplicar NAT-src mediante direcciones de conjunto DIP
para traducir las direcciones de origen originales y convertirlas en direcciones de un
espacio de direcciones neutro.
NOTA: El rango de direcciones en un conjunto de DIP debe estar en la misma subred que
la interfaz de túnel, pero no es necesario que el conjunto incluya la dirección IP de
la interfaz o cualquier otra dirección MIP o VIP que pueda encontrarse en dicha
subred. Para las interfaces de la zona de seguridad, es posible definir una
dirección IP extendida y un conjunto de DIP auxiliar en una subred distinta de la
de la dirección IP de la interfaz. Para obtener más información, consulte “Uso de
DIP en una subred distinta” en la página 2-146.
Hay dos posibilidades para aplicar NAT-dst al tráfico VPN entrante:
NAT-dst basada en directivas: una directiva puede aplicar NAT-dst para traducir
el tráfico VPN entrante y convertirlo en una dirección que se encuentre en la
misma subred que la interfaz de túnel (pero no en el mismo rango que el
conjunto de DIP local utilizado para el tráfico VPN saliente) o en una dirección
de otra subred a la que el dispositivo de seguridad tenga una entrada en su
tabla de rutas. (Para encontrar información acerca de los aspectos que rodean a
la configuracióin de NAT-dst, consulte “Enrutamiento para NAT-Dst” en la
página 8-32.)
Dirección IP asignada (MIP): una directiva puede hacer referencia a una MIP
como dirección de destino. La MIP utiliza una dirección que se encuentra en la
misma subred que la interfaz de túnel (pero no en el mismo rango que el
conjunto de DIP local utilizado para el tráfico VPN de salida). (Para encontrar
información acerca de las MIP, consulte “Direcciones IP asignadas” en la
página 8-63.)
El tráfico VPN entre dos puntos con direcciones superpuestas requiere la traducción
de direcciones en ambos sentidos. Como la dirección de origen del tráfico saliente
no puede ser la misma que la dirección de destino del tráfico entrante (la dirección
NAT-dst o MIP no puede estar en el conjunto de DIP), las direcciones de las que se
incluyen referencias en las directivas de entrada y salida no pueden ser simétricas.
Si desea que el dispositivo de seguridad realice una traducción de direcciones de

origen y destino para el tráfico VPN direccional que atraviese el mismo túnel,
dispone de las dos opciones siguientes:
Puede definir una ID de proxy para una configuración VPN basada en

directivas. Si hace referencia de forma específica a un túnel VPN en una
directiva, el dispositivo de seguridad deriva una ID de proxy a partir de los
componentes de la directiva que haga referencia a dicho túnel. El dispositivo de
seguridad deriva la ID de proxy al crear la directiva por primera vez, y a partir
de entonces, cada vez que el dispositivo se reinicia. Sin embargo, si define
manualmente una ID de proxy para un túnel VPN al que se haga referencia en
una directiva, el dispositivo de seguridad aplicará la ID de proxy definida por el
usuario y no la ID de proxy derivada a partir de la directiva.
Sitios VPN con direcciones superpuestas 143

NOTA: Una ID de proxy es un tipo de acuerdo entre interlocutores IKE para permitir el
tráfico a través de un túnel si el tráfico cumple una tupla especificada de dirección
local, dirección remota y servicio.
Puede utilizar una configuración de túnel VPN basada en rutas, que debe tener
una ID de proxy definida por el usuario. Con una configuración de túnel VPN
basada en rutas, no se hace referencia de forma específica a un túnel VPN en
una directiva. En su lugar, la directiva controla (permite o deniega) el acceso a
un destino en particular. La ruta que conduce a dicho destino apunta a una
interfaz de túnel que, a su vez, está asociada a un túnel VPN. Como el túnel
VPN no está asociado directamente a ninguna directiva a partir de la que se
pueda derivar una ID de proxy de la dirección de origen, la dirección de destino
y el servicio, habrá que definir una ID de proxy de forma manual. (Recuerde
que una configuración VPN basada en rutas también permite crear múltiples
directivas que hagan uso de un único túnel VPN; es decir, una SA de fase 2
sencilla).
Examine las direcciones de la Figura 39, en la que se ejemplifica un túnel VPN entre
dos puntos con espacios de direcciones superpuestas.
Figura 39: Superposición de direcciones en ubicaciones de interlocutores
Dispositivo A Túnel VPN Dispositivo B

Espacio de Espacio de
direcciones direcciones
interno tunnel.1 tunnel.2 interno
10.1.1.0/24 10.10.1.1/24 10.20.2.1/24 10.1.1.0/24
Direcciones en directivas
10.10.1.2 – 10.10.1.2 DIP MIP 10.20.2.5 (a 10.1.1.5)

10.10.1.5 (a 10.1.1.5) MIP DIP 10.20.2.2 – 10.20.2.2
Si los dispositivos de seguridad de la Figura 39 derivan las ID de proxy a partir de

las directivas, como ocurre en las configuraciones VPN basadas en directivas, las
directivas de entrada y salida dan como resultado las siguientes ID de proxy:
Local Remota Servicio Local Remota Servicio
Salida 10.10.1.2/32 10.20.2.5/32 Any Entrada 10.20.2.5/32 10.10.1.2/32 Any
Entrada 10.10.1.5/32 10.20.2.2/32 Any Salida 10.20.2.2/32 10.10.1.5/32 Any
Como se muestra en la tabla, existen dos ID de proxy: una para el tráfico VPN
entrante y otra para el saliente. Cuando el dispositivo A envía tráfico por primera
vez desde 10.10.1.2/32 hasta 10.20.2.5/32, los dos interlocutores realizan
negociaciones IKE y generan asociaciones de seguridad (SA) de fase 1 y fase 2. La
SA de fase 2 da como resultado la ID de proxy de salida anterior para el dispositivo
A y la ID de proxy de entrada para el dispositivo B.

Si el dispositivo B envía tráfico al dispositivo A, la consulta de directivas para el

tráfico de 10.20.2.2/32 a 10.10.1.5/32 indica que no hay ninguna SA de fase 2
activa para tal ID de proxy. Por lo tanto, los dos interlocutores utilizan la SA de fase
1 existente (asumiendo que su periodo de vigencia no haya caducado) para
negociar una SA de fase 2 distinta. Las ID de proxy resultantes se indican en la tabla
anterior como ID de proxy de entrada para el dispositivo A e ID de proxy de salida
para el dispositivo B. Hay dos SA de fase 2 (dos túneles VPN) porque las direcciones
son asimétricas y requieren ID de proxy distintas.
Para crear un solo túnel para tráfico VPN bidireccional, puede definir las siguientes
ID de proxy con direcciones cuyo alcance incluya las direcciones de origen y
destino traducidas en cada extremo del túnel:
Local Remota Servicio Local Remota Servicio
10.10.1.0/24 10.20.2.0/24 Any 10.20.2.0/24 10.10.1.0/24 Any
o bien
0.0.0.0/0 0.0.0.0/0 Any 0.0.0.0/0 0.0.0.0/0 Any
Las ID de proxy anteriores comprenden las direcciones que aparecen tanto en el

tráfico VPN entrante como en el saliente que circule entre ambos puntos. La
dirección 10.10.1.0/24 incluye el conjunto de DIP 10.10.1.2 – 10.10.1.2 y la
dirección MIP 10.10.1.5. Asimismo, la dirección 10.20.2.0/24 incluye el conjunto de
DIP 10.20.2.2 – 10.20.2.2 y la dirección MIP 10.20.2.5. Las ID de proxy anteriores
son simétricas, es decir, la dirección local del dispositivo A es la dirección remota
del dispositivo B y viceversa. Si el dispositivo A envía tráfico al dispositivo B, la SA
de fase 2 y la ID de proxy también se aplican al tráfico enviado desde el dispositivo
B al dispositivo A. Por lo tanto, sólo se requiere una única SA de fase 2 (es decir, un
único túnel VPN) para el tráfico bidireccional entre los dos puntos.
NOTA: La dirección 0.0.0.0/0 incluye todas las direcciones IP y, por tanto, las direcciones
del conjunto de DIP y MIP.
Para crear un túnel VPN para el tráfico bidireccional entre dos puntos con espacios
de direcciones superpuestas cuando las direcciones para NAT-src y NAT-dst
configuradas en el mismo dispositivo se encuentran en subredes distintas, la ID de
proxy para el túnel debe ser (IP local) 0.0.0.0/0 – (IP remota) 0.0.0.0/0 – tipo de
servicio. Si desea utilizar direcciones más restrictivas en la ID de proxy, las
direcciones para NAT-src y NAT-dst deberán encontrarse en la misma subred.
En este ejemplo vamos a configurar un túnel VPN entre el “dispositivo A” situado en

el sitio corporativo y el “dispositivo B” situado en la sucursal de la empresa. El
espacio de direcciones para las entidades finales VPN se superpone; ambas utilizan
direcciones en la subred 10.1.1.0/24. Para superar este conflicto, utilizaremos
NAT-src para traducir la dirección de origen del tráfico VPN saliente y NAT-dst para
traducir la dirección de destino del tráfico VPN entrante. Las directivas permiten
que todas las direcciones de la LAN corporativa accedan a un servidor FTP de la
sucursal, y que todas las direcciones de la sucursal accedan a un servidor FTP de la
sede central.

NOTA: Para obtener más información sobre la traducción de direcciones de red de origen
y destino (NAT-src y NAT-dst), consulte el Volumen 8: Traducción de direcciones.
Las configuraciones de ambos extremos del túnel utilizan los siguientes parámetros:
AutoKey IKE, clave previamente compartida (“netscreen1”) y el nivel de seguridad
predefinido como “Compatible” para propuestas de fase 1 y fase 2. (Para ver los
detalles sobre estas propuestas, consulte “Negociación de túnel” en la página 9).
La interfaz de salida del dispositivo-A en el sitio corporativo es ethernet3, que tiene

la dirección IP 1.1.1.1/24 y está asociada a la zona Untrust. El dispositivo-B, en la
sucursal, utiliza esta dirección como puerta de enlace IKE remota.
La interfaz de salida del dispositivo-B en la sucursal es ethernet3, que tiene la

dirección IP 2.2.2.2/24 y está asociada a la zona Untrust. El dispositivo-A, en el sitio
corporativo, utiliza esta dirección como puerta de enlace IKE remota.
La interfaz de zona Trust de ambos dispositivos de seguridad es ethernet1 y tiene la

dirección IP 10.1.1.1/24. Todas las zonas de ambos dispositivos de seguridad se
Figura 40: Interfaz de túnel con NAT-Src y NAT-Dst

configuradas en el configuradas en el
dispositivo-A en la sucursal. dispositivo-B en la sucursal 1.
A B B A
Zona Trust Zona Untrust Zona Untrust Zona Trust
Puerta de enlace servidorB

Puerta de 10.1.1.5
enlace 2.2.2.250
Red A Internet Red B
10.1.1.0/24 Dispositivo A Dispositivo B 10.1.1.0/24
servidorA
Tunnel.1 10.10.1.1/24 Tunnel.1 10.20.1.1/24
10.1.1.5
DIP 5 10.10.1.2 – 10.10.1.2 DIP 6 10.20.1.2 – 10.20.1.2

NAT-Dst 10.10.1.5 –> 10.1.1.5 NAT-Dst 10.20.1.5 –> 10.1.1.5
Los usuarios de la red A pueden acceder al servidor B. Los usuarios de la red B

pueden acceder al servidor A.
Todo el tráfico circula a través del túnel VPN entre los dos puntos.
Red A Dispositivo A Dispositivo B servidorB
server A Túnel VPN Red B

“vpn1”

1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

clic en OK:

2. DIP
ID: 5
IP Address Range: (seleccione), 10.10.1.2 ~ 10.10.1.2
3. Direcciones
Address Name: corp

Zone: Trust
Address Name: virtualA

Zone: Trust

Address Name: branch1

Zone: Untrust
Address Name: servidorB

Zone: Untrust
4. VPN
VPN Name: vpn1

Gateway Name: branch1
Type: Static IP: (seleccione), Address/Hostname: 2.2.2.2
Preshared Key: netscreen1
NOTA: La interfaz de salida no necesita estar en la misma zona a la que está asociada la
interfaz del túnel, aunque en este caso se encuentran en la misma zona.

IKE:

Service: ANY
5. Rutas


Interface: tunnel.1


Interface: Null
Metric: 10
6. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), corp
Address Book Entry: (seleccione), servidorB
Service: FTP
Action: Permit

NAT:
DIP On: 5 (10.10.1.2–10.10.1.2)/X-late
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), branch1
Address Book Entry: (seleccione), virtualA
Service: FTP
Action: Permit

NAT:
Destination Translation: (seleccione)
Translate to IP: (seleccione), 10.1.1.5
Map to Port: (anule la selección)
1. Interfaces
haga clic en Apply:
Zone Name: Trust


Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

clic en OK:

2. DIP
ID: 6
3. Direcciones
Address Name: branch1

Zone: Trust
Address Name: virtualB

Zone: Trust
Address Name: corp

Zone: Untrust

Address Name: servidorA

Zone: Untrust
4. VPN
VPN Name: vpn1

Gateway Name: corp

IKE:

Service: ANY
5. Rutas


Interface: tunnel.1


Interface: Null
Metric: 10
6. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), servidorA
Service: FTP
Action: Permit

NAT:
DIP on: 6 (10.20.1.2–10.20.1.2)/X-late
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), virtualB
Service: FTP
Action: Permit

NAT:
Translate to IP: 10.1.1.5
Map to Port: (anule la selección)
CLI (dispositivo-A)
1. Interfaces

2. DIP
3. Direcciones
set address trust corp 10.1.1.0/24
set address trust virtualA 10.10.1.5/32
set address untrust branch1 10.20.1.2/32
set address untrust servidorB 10.20.1.5/32
4. VPN
set ike gateway branch1 address 2.2.2.2 outgoing-interface ethernet3 preshare
netscreen1 sec-level compatible
set vpn vpn1 gateway branch1 sec-level compatible
5. Rutas
6. Directivas
set policy top from trust to untrust corp servidorB ftp nat src dip-id 5 permit
set policy top from untrust to trust branch1 virtualA ftp nat dst ip 10.1.1.5 permit
save
CLI (dispositivo-B)
1. Interfaces
2. DIP
3. Direcciones
set address trust branch1 10.1.1.0/24
set address trust virtualB 10.20.1.5/32
set address untrust corp 10.10.1.2/32
set address untrust servidorA 10.10.1.5/32
4. VPN
set ike gateway corp address 1.1.1.1 outgoing-interface ethernet3 preshare
set vpn vpn1 gateway corp sec-level compatible

5. Rutas
6. Directivas
set policy top from trust to untrust branch1 servidorA ftp nat src dip-id 6 permit
set policy top from untrust to trust corp virtualB ftp nat dst ip 10.1.1.5 permit
save
VPN en modo transparente

Si las interfaces de los dispositivos de seguridad se encuentran en modo
transparente (es decir, si no tienen direcciones IP y operan en la capa 2 del modelo
OSI), puede utilizar la dirección IP VLAN1 como punto terminal de la VPN. En lugar
de una interfaz de salida, tal como se utiliza cuando las interfaces se encuentran en
modo NAT o de rutas (es decir, cuando tienen direcciones IP y operan en la capa 3),
un túnel VPN hace referencia a una zona de salida. De forma predeterminada, un
túnel utiliza la zona V1-Untrust como su zona de salida. Si tiene múltiples interfaces
asociadas a la misma zona de salida, el túnel VPN puede utilizar cualquiera de ellas.
NOTA: El modelo OSI es un modelo estándar en el sector de redes de una arquitectura de

protocolos de red. El modelo OSI está compuesto por siete capas: la capa 2 es la
capa de enlace de datos y la capa 3 es la capa de red.
En el momento de esta publicación, un dispositivo de seguridad cuyas interfaces

se encuentren en modo transparente sólo admite VPN basadas en directivas. Para
obtener más información acerca del modo transparente, consulte “Modo
transparente” en la página 2-79.
No es necesario que las interfaces de ambos dispositivos de seguridad se

encuentren en modo transparente. Las interfaces del dispositivo situado a un
extremo del túnel pueden encontrarse en modo transparente, y las del otro
dispositivo pueden encontrarse en modo NAT o de rutas.
En este ejemplo, vamos a configurar un túnel VPN AutoKey IKE basado en

directivas entre dos dispositivos de seguridad cuyas interfaces operan en modo
transparente.
NOTA: No es necesario que las interfaces de ambos dispositivos de seguridad se

encuentren en modo transparente. Las interfaces del dispositivo situado a un
extremo del túnel pueden encontrarse en modo transparente, y las del otro
dispositivo pueden encontrarse en modo NAT o de rutas.
154 VPN en modo transparente

Los elementos clave para la configuración de los dispositivos de seguridad situados

a ambos extremos del túnel son éstos:
Elementos de
configuración Dispositivo A Dispositivo B
Zona V1-Trust Interfaz: ethernet1, 0.0.0.0/0 Interfaz: ethernet1, 0.0.0.0/0
(habilitar administración para el (habilitar administración para el
administrador local) administrador local)
Zona V1-Untrust Interfaz: ethernet3, 0.0.0.0/0 Interfaz: ethernet3, 0.0.0.0/0
Interfaz VLAN1 Dirección IP: 1.1.1.1/24 Dirección IP: 2.2.2.2/24
IP de administración: 1.1.1.21 IP de administración: 2.2.2.3
Direcciones lan_local: 1.1.1.0/24 en V1-Untrust lan_local: 2.2.2.0/24 en V1-Trust
lan_interlocutor: 2.2.2.0/24 en V1-Untrust lan_interlocutor: 1.1.1.0/24 en V1-Untrust
Puerta de enlace IKE gw1, 2.2.2.2, clave precompartida gw1, 1.1.1.1, clave precompartida
h1p8A24nG5, h1p8A24nG5, seguridad: compatible
seguridad: compatible
Túnel VPN seguridad: compatible seguridad: compatible
Directivas lan_local -> lan_interlocutor, cualquier lan_local -> lan_interlocutor, cualquier
servicio, vpn1 servicio, vpn1
lan_interlocutor -> lan_local, cualquier lan_interlocutor -> lan_local, cualquier
servicio, vpn1 servicio, vpn1
Enrutador externo Dirección IP: 1.1.1.250 Dirección IP: 2.2.2.250
Ruta 0.0.0.0/0, usar interfaz VLAN1 0.0.0.0/0, usar interfaz VLAN1
a puerta de enlace 1.1.1.250 a puerta de enlace 2.2.2.250
1.Puede separar el tráfico VPN del administrativo utilizando la dirección IP de administración para recibir el tráfico
administrativo y la dirección VLAN1 para terminar el tráfico VPN.
La configuración de un túnel AutoKey IKE basado en directivas para un dispositivo

de seguridad cuyas interfaces se encuentren en modo transparente implica los
siguientes pasos:
1. Eliminar las direcciones IP de las interfaces físicas y asociarlas a las zonas de

seguridad de capa 2.
2. Asignar una dirección IP y una dirección IP de administración a la interfaz

VLAN1.
de direcciones para las zonas V1-Trust y V1-Untrust.
4. Configurar el túnel VPN y designar su zona de salida como zona V1-Untrust.
5. Introducir una ruta predeterminada que conduzca al enrutador externo en

trust-vr.
VPN en modo transparente 155

1. Interfaces
NOTA: El desplazamiento de la dirección IP VLAN1 a una subred distinta hace que el

dispositivo de seguridad elimine todas las rutas relacionadas con la interfaz
VLAN1 anterior. A la hora de configurar un dispositivo de seguridad a través de la
WebUI, la estación de trabajo debe acceder a la primera dirección VLAN1 y
encontrarse en la misma subred que la dirección nueva. Después de cambiar la
dirección VLAN1, deberá modificar la dirección IP de su estación de trabajo para
que se encuentre en la misma subred que la nueva dirección VLAN1. Es posible
que también tenga que reubicar su estación de trabajo en una subred físicamente
adyacente al dispositivo de seguridad.
Manage IP: 1.1.1.2
Management Services: WebUI, Telnet, Ping
NOTA: Se deben habilitar las opciones de administración para WebUI, Telnet y Ping tanto
en la zona V1-Trust como en la interfaz VLAN1 para que un administrador local de
la zona V1-Trust pueda acceder a la dirección IP de administración de VLAN1. Si la
administración a través de la WebUI aún no está habilitada en las interfaces de
zona V1-Trust y VLAN1, no será posible acceder al dispositivo de seguridad a
través de la WebUI para realizar estos ajustes. En su lugar, deberá habilitar la
administración mediante WebUI en estas interfaces a través de una conexión de
consola.
haga clic en Apply:

Zone Name: V1-Trust

haga clic en OK:

2. Direcciones
Address Name: lan_local

Zone: V1-Trust

Address Name: lan_interlocutor

Zone: V1-Untrust
3. VPN
y haga clic en OK:
Gateway Name: gw1

Outgoing Zone: V1-Untrust
VPN Name: vpn1

Remote Gateway:
Predefined: (seleccione), gw1
4. Ruta

Interface: VLAN1 (VLAN)
5. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), lan_local
Address Book Entry: (seleccione), lan_interlocutor
Service: ANY
Action: Zona
Tunnel VPN: vpn1

1. Interfaces
NOTA: El desplazamiento de la dirección IP VLAN1 a una subred distinta hace que el

dispositivo de seguridad elimine todas las rutas relacionadas con la interfaz
VLAN1 anterior. A la hora de configurar un dispositivo de seguridad a través de la
WebUI, la estación de trabajo debe acceder a la primera dirección VLAN1 y
encontrarse en la misma subred que la dirección nueva. Después de cambiar la
dirección VLAN1, deberá modificar la dirección IP de su estación de trabajo para
que se encuentre en la misma subred que la nueva dirección VLAN1. Es posible
que también tenga que reubicar su estación de trabajo en una subred físicamente
adyacente al dispositivo de seguridad.
Manage IP: 2.2.2.3
Management Services: WebUI, Telnet, Ping
NOTA: Si la administración a través de la WebUI aún no está habilitada en las interfaces

de zona V1-Trust y VLAN1, no será posible acceder al dispositivo de seguridad a
través de la WebUI para realizar estos ajustes. En su lugar, deberá habilitar la
administración mediante WebUI en estas interfaces a través de una conexión de
consola.
haga clic en Apply:

Zone Name: V1-Trust

haga clic en OK:

2. Direcciones
Address Name: lan_local

Zone: V1-Trust

Address Name: lan_interlocutor

Zone: V1-Untrust
3. VPN
y haga clic en OK:
Gateway Name: gw1

Outgoing Zone: V1-Untrust
VPN Name: vpn1

Remote Gateway:
Predefined: (seleccione), gw1
4. Ruta

Interface: VLAN1 (VLAN)
5. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), lan_local
Address Book Entry: (seleccione), lan_interlocutor
Service: ANY
Action: Zona
Tunnel VPN: vpn1

CLI (dispositivo-A)
1. Interfaces y zonas
unset interface ethernet1 ip
unset interface ethernet1 zone
set interface ethernet1 zone v1-trust
set interface ethernet3 zone v1-untrust
set interface vlan1 manage-ip 1.1.1.2
NOTA: Se deben habilitar las opciones de administración para WebUI, Telnet y Ping tanto
en la zona V1-Trust como en la interfaz VLAN1 para que un administrador local de
la zona V1-Trust pueda acceder a la dirección IP de administración de VLAN1.
2. Direcciones
set address v1-trust lan_local 1.1.1.0/24
set address v1-untrust lan_interlocutor 2.2.2.0/24
3. VPN
set ike gateway gw1 address 2.2.2.2 main outgoing-interface v1-untrust preshare
h1p8A24nG5 sec-level compatible
set vpn vpn1 gateway gw1 sec-level compatible
4. Rutas
set vrouter trust-vr route 0.0.0.0/0 interface vlan1 gateway 1.1.1.250
5. Directivas
set policy top from v1-trust to v1-untrust lan_local lan_interlocutor any tunnel vpn
vpn1
set policy top from v1-untrust to v1-trust lan_interlocutor lan_local any tunnel vpn
vpn1
save
CLI (dispositivo-B)
1. Interfaces y zonas
set interface ethernet1 zone v1-trust
set zone v1-trust manage
set interface ethernet3 zone v1-untrust
set interface vlan1 manage-ip 2.2.2.3
set interface vlan1 manage

2. Direcciones
set address v1-trust lan_local 2.2.2.0/24
set address v1-untrust lan_interlocutor 1.1.1.0/24
3. VPN
set ike gateway gw1 address 1.1.1.1 main outgoing-interface v1-untrust preshare
h1p8A24nG5 sec-level compatible
4. Rutas
set vrouter trust-vr route 0.0.0.0/0 interface vlan1 gateway 2.2.2.250
5. Directivas
set policy top from v1-trust to v1-untrust lan_local lan_interlocutor any tunnel vpn
vpn1
set policy top from v1-untrust to v1-trust lan_interlocutor lan_local any tunnel vpn
vpn1
save


Capítulo 5
Redes privadas virtuales de acceso
telefónico
Los dispositivos de seguridad de Juniper Networks pueden admitir conexiones de

red privada virtual (VPN) de acceso telefónico. Puede configurar un dispositivo de
seguridad con una dirección IP estática para asegurar un túnel IPSec a un cliente
NetScreen-Remote o a otro dispositivo de seguridad con una dirección IP dinámica.
“Acceso telefónico” en la página 164
“VPN de acceso telefónico basada en directivas, AutoKey IKE” en la

página 165
“VPN de acceso telefónico basada en rutas, interlocutor dinámico” en la

página 170
“VPN de acceso telefónico basada en directivas, interlocutor dinámico” en

la página 177
“Directivas bidireccionales para usuarios de VPN de acceso telefónico” en

la página 184
“Identificación IKE de grupo” en la página 188
“Identificación IKE de grupo con certificados” en la página 189
“Tipos de identificación IKE ASN1-DN Wildcard y Container” en la

página 191
“Creación de una identificación IKE de grupo (certificados)” en la

página 194
“Configuración de una ID IKE de grupo con claves previamente

compartidas” en la página 198
“Identificación IKE compartida” en la página 204
163
Acceso telefónico
Es posible configurar túneles para usuarios de VPN de acceso telefónico de forma
individual o reuniendo varios usuarios en un grupo VPN de acceso telefónico, en
cuyo caso sólo tendrá que configurar un túnel. También es posible crear un usuario
de identificación IKE de grupo, lo que permite definir un usuario cuya identificación
IKE se utilizará como parte de todas las ID IKE de los usuarios IKE de acceso
telefónico. Esto permite ahorrar bastante tiempo cuando hay grandes grupos de
usuarios de acceso telefónico, puesto que no tendrá que configurar a cada usuario
IKE individualmente.
NOTA: Para obtener más información sobre la creación de grupos de usuarios IKE,
consulte “Usuarios y grupos de usuarios IKE” en la página 9-69. Para obtener más
información sobre la función de identificación IKE de grupo, consulte
“Identificación IKE de grupo” en la página 188.
Si el cliente de acceso telefónico admite una dirección IP interna virtual, como hace
el dispositivo NetScreen-Remote, también puede crear un túnel AutoKey IKE de
VPN de acceso telefónico para interlocutor dinámico (con clave o certificados
previamente compartidos). Puede configurar una puerta de enlace segura
Juniper Networks con una dirección IP estática para asegurar un túnel IPSec a un
cliente NetScreen-Remote o a otro dispositivo de seguridad con una dirección IP
dinámica.
NOTA: Para obtener más información sobre las opciones de VPN disponibles, consulte
“Seguridad del protocolo de Internet” en la página 1. Si desea obtener ayuda para
elegir entre las distintas opciones, consulte “Directrices para las redes privadas
virtuales” en la página 49.
Puede configurar túneles VPN basados en directivas para usuarios de acceso

telefónico a VPN. En el caso de un cliente dinámico de acceso telefónico, puede
configurar una VPN basada en directivas o basada en rutas. Dado que el cliente
dinámico de acceso telefónico puede admitir una dirección IP interna virtual, al
igual que el dispositivo NetScreen, puede configurar una entrada de la tabla de
enrutamiento a esa dirección interna virtual a través de una interfaz de túnel
designada. De esta forma podrá configurar un túnel VPN basado en rutas entre el
dispositivo de seguridad y el cliente.
NOTA: Un cliente dinámico de acceso telefónico es un cliente de acceso telefónico que

admite una dirección IP interna virtual.
Un interlocutor dinámico de acceso telefónico es prácticamente idéntico a un

interlocutor dinámico punto a punto, excepto por el hecho de que la dirección IP
interna del cliente de acceso telefónico es una dirección virtual.
164 Acceso telefónico

Capítulo 5: Redes privadas virtuales de acceso telefónico
VPN de acceso telefónico basada en directivas, AutoKey IKE

En este ejemplo, un túnel AutoKey IKE que utiliza una clave previamente
compartida o un par de certificados (uno por cada extremo del túnel) proporciona
el canal de comunicación segura entre el usuario IKE Wendy y el servidor UNIX. El
túnel, una vez más, utiliza ESP con encriptación 3DES y autenticación SHA-1.
NOTA: La clave previamente compartida es h1p8A24nG5. Se parte de la base de que

ambos participantes ya disponen de certificados. Para obtener más información
sobre los certificados, consulte “Certificados y CRL” en la página 24.
Para configurar el túnel AutoKey IKE utilizando AutoKey IKE con una clave
previamente compartida o con certificados, es necesario realizar la siguiente
configuración en la empresa:
1. Configurar interfaces para las zonas Trust y Untrust, que se encuentran en el

2. Introducir la dirección del servidor UNIX en la libreta de direcciones de la zona

Trust.
3. Definir a Wendy como usuario IKE.
4. Configurar la puerta de enlace remota y la VPN AutoKey IKE.
5. Configurar una ruta predeterminada.
6. Crear una directiva de la zona Untrust a la zona Trust que permita que el
usuario de acceso telefónico acceda a UNIX.
Figura 41: VPN de acceso telefónico basada en directivas, AutoKey IKE

Interfaz de salida Oficina corporativa
Usuario remoto Wendy Zona Untrust Zona Trust
NetScreen-Remote ethernet3, 1.1.1.1/24 ethernet1, 10.1.1.1/24
Puerta de enlace 1.1.1.250
Zona Untrust Servidor UNIX

10.1.1.5
Internet
LAN
Túnel VPN
Zona Zona
Untrust Trust
La clave previamente compartida es h1p8A24nG5. En este ejemplo se asume que

ambos participantes ya tienen certificados RSA emitidos por Verisign y que el
certificado local en NetScreen-Remote contiene el U-FQDN wparker@email.com.
(Para información sobre cómo obtener y cargar certificados, consulte “Certificados
y CRL” en la página 24.) Para los niveles de seguridad de las fases 1 y 2, debe
especificar la propuesta de fase 1 (pre-g2-3des-sha para el método de clave
previamente compartida o rsa-g2-3des-sha para certificados) y seleccionar el
conjunto de propuestas predefinido “Compatible” para la fase 2.
Acceso telefónico 165

WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Dirección
Address Name: UNIX

Zone: Trust
3. Usuario
en OK:
User Name: Wendy

Status: Enable (seleccione)
IKE User: (seleccione)
Simple Identity: (seleccione)
IKE Identity: wparker@email.com
4. VPN
y haga clic en OK:
Gateway Name: Wendy_NSR

Dialup User: (seleccione), User: Wendy

Certificados

enlace:

rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
VPN Name: Wendy_UNIX

Remote Gateway:
Predefined: (seleccione), Wendy_NSR
(o bien)
PRECAUCIÓN: El modo dinámico es poco seguro. Por razones de limitación de

protocolo, el modo principal IKE junto con la clave previamente compartida (PSK)
no se puede utilizarse en los usuarios VPN de acceso telefónico. Además, se
recomienda nunca utilizar el modo dinámico debido a que dicho modo tiene
problemas de seguridad inherentes. Por consecuencia, se recomienda firmemente
configurar a los usuarios VPN de acceso telefónico con los certificados PKI y en
modo principal.


enlace:

pre-g2-3des-sha
5. Ruta


6. Directiva
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Dial-Up VPN
Address Book Entry: (seleccione), UNIX
Service: ANY
Action: Tunnel
Tunnel VPN: Wendy_UNIX
Modify matching bidirectional VPN policy: (anule la selección)
CLI
1. Interfaces
2. Dirección
set address trust unix 10.1.1.5/32
3. Usuario
set user wendy ike-id u-fqdn wparker@email.com
4. VPN
Certificados
set ike gateway wendy_nsr dialup wendy aggressive outgoing-interface ethernet3
set ike gateway wendy_nsr cert peer-ca 1
set ike gateway wendy_nsr cert peer-cert-type x509-sig
set vpn wendy_unix gateway wendy_nsr sec-level compatible

utilice el siguiente comando: get pki x509 list ca-cert.
(o bien)
PRECAUCIÓN: El modo dinámico es poco seguro. Por razones de limitación de

protocolo, el modo principal IKE junto con la clave previamente compartida (PSK)
no se puede utilizarse en los usuarios VPN de acceso telefónico. Además, se
recomienda nunca utilizar el modo dinámico debido a que dicho modo tiene
problemas inherentes de poca seguridad. Por consecuencia, se recomienda
firmemente configurar a los usuarios VPN de acceso telefónico con los certificados
PKI y en modo principal.
set ike gateway wendy_nsr dialup wendy aggressive outgoing-interface ethernet3

set vpn wendy_unix gateway wendy_nsr sec-level compatible

5. Ruta
6. Directiva
set policy top from untrust to trust “Dial-Up VPN” unix any tunnel vpn wendy_unix
save
Editor de directivas de seguridad

2. Haga clic en Add a new connection y escriba UNIX junto al icono de nueva
conexión que aparecerá en pantalla.

Protocol: All
5. Haga clic en My Identity: Siga uno de estos dos pasos:
Haga clic en Pre-shared Key > Enter Key: Escriba h1p8A24nG5, después
haga clic en OK.
ID Type: (seleccione E-mail Address) y escriba wparker@email.com.
(o bien)
Seleccione un certificado de la lista desplegable para seleccionar el

certificado.
ID Type: (seleccione E-mail Address)
NOTA: La dirección de correo electrónico del certificado aparecerá automáticamente en

el campo del identificador.
6. Haga clic en el icono Security Policy, después seleccione Aggressive Mode y

desactive Enable Perfect Forward Secrecy (PFS).
7. Haga clic en el símbolo MÁS situado a la izquierda del icono Security Policy y
después en el símbolo MÁS situado a la izquierda de Authentication (Phase 1) y
de Key Exchange (Phase 2) para ampliar aún más la directiva.

8. Haga clic en Authentication (Phase 1) > Proposal 1: Seleccione el siguiente

método y algoritmos de autenticación:
Authentication Method: Pre-Shared Key
(o bien)
Authentication Method: RSA Signatures

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Key Group: Diffie-Hellman Group 2
9. Haga clic en Key Exchange (Phase 2) > Proposal 1: Seleccione los siguientes
protocolos IPSec:

Hash Alg: SHA-1
10. Haga clic en Key Exchange (Phase 2) > Create New Proposal: Seleccione los
siguientes protocolos IPSec:

Hash Alg: MD5

Encrypt Alg: DES
Hash Alg: SHA-1

Encrypt Alg: DES
Hash Alg: MD5
13. Haga clic en File > Save Changes.
VPN de acceso telefónico basada en rutas, interlocutor dinámico

En este ejemplo, un túnel VPN conecta de forma segura al usuario situado tras el
dispositivo NetScreen-Remote a la interfaz de la zona Untrust del dispositivo de
seguridad que protege el servidor de correo en la zona DMZ. La interfaz de la zona
Untrust tiene una dirección IP estática. El cliente NetScreen-Remote tiene una
dirección IP externa asignada dinámicamente y una dirección IP interna estática
(virtual). El administrador del dispositivo de seguridad debe conocer la dirección IP
interna del interlocutor por dos motivos:
Puede utilizarla en directivas.

Puede crear una ruta asociando la dirección con una interfaz de túnel unida a
un túnel VPN apropiado.
Cuando el cliente NetScreen-Remote establece el túnel, el tráfico que lo atraviesa

puede originarse desde el otro extremo. Todas las zonas del dispositivo de
seguridad se encuentran en el dominio de enrutamiento Trust-vr.
Figura 42: VPN de acceso telefónico basada en rutas, interlocutor dinámico
Usuario remoto: Phil Interfaz de salida Oficina corporativa

1.1.1.1/24 1.2.2.1/24 Servidor de
Zona DMZ correo
Zona Untrust Puerta de enlace
Petición 1.2.2.5
SMTP 1.1.1.250
Internet
Túnel VPN Petición

IDENT
Dirección IP externa Interfaz de túnel

Dirección IP interna
dinámica Tunnel.1
10.10.10.1
En este ejemplo, Phil desea acceder a su correo electrónico desde el servidor de

correo del sitio de la empresa. Cuando intenta hacerlo, es autenticado por el
programa del servidor de correo, que le envía una petición IDENT a través del túnel.
NOTA: El servidor de correo puede enviar la petición IDENT a través del túnel sólo si el
administrador de seguridad agrega un servicio personalizado para ello (TCP,
puerto 113) y establece una directiva de salida que permita el tráfico a través del
túnel hacia 10.10.10.1.
La clave previamente compartida es h1p8A24nG5. Partiremos de la base de que

certificado local en NetScreen-Remote contiene el U-FQDN pm@juniper.net. (Para
encontrar información sobre cómo obtener y cargar certificados, consulte
“Certificados y CRL” en la página 24.) Para los niveles de seguridad de las fases 1
y 2, debe especificar una propuesta de fase 1 (pre-g2-3des-sha para el método de
clave previamente compartida o rsa-g2-3des-sha para certificados) y seleccionar el
conjunto de propuestas “Compatible” para la fase 2.
Introduzca las tres rutas siguientes en el dispositivo de seguridad:
Una ruta predeterminada que conduzca al enrutador externo en trust-vr
Una ruta al destino a través de la interfaz de túnel
Una ruta Null al destino. Asigne una métrica más alta (más alejada de cero) a la
ruta Null para que se convierta en la siguiente opción de ruta al destino.
A continuación, si el estado de la interfaz de túnel cambia a “fuera de línea” y la
ruta que hace referencia a esa interfaz también se desactiva, el dispositivo de
seguridad utiliza la ruta Null, que descarta todo tráfico enviado hacia él, en
lugar de la ruta predeterminada, que reenvía tráfico no encriptado.
Finalmente, creará directivas que permitan el flujo del tráfico fluya en ambas
direcciones entre Phil y el servidor de correo.

WebUI
1. Interfaces
haga clic en OK:
Zone Name: DMZ

haga clic en OK:
Zone Name: Untrust

clic en OK:

2. Direcciones

Zone: DMZ
Address Name: Phil

Zone: Untrust
3. Servicios
Service Name: Ident

Service Timeout:


Ident
MAIL
POP3
4. VPN
y haga clic en OK:
Gateway Name: To_Phil

Dynamic IP Address: (seleccione), Peer ID: pm@juniper.net

enlace:

pre-g2-3des-sha
(o bien)
Certificados

enlace:

rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
VPN Name: corp_Phil

Remote Gateway:
Predefined: (seleccione), To_Phil


IKE:

Service: Any
5. Rutas


Interface: tunnel.1

Interface: Null
Metric: 10
6. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Phil
Action: Permit
haga clic en OK:
Source Address:
Action: Permit

CLI
1. Interfaces
2. Direcciones
set address dmz “Mail Server” 1.2.2.5/32
set address untrust phil 10.10.10.1/32
3. Servicios
4. VPN
set ike gateway to_phil dynamic pm@juniper.net aggressive outgoing-interface
set vpn corp_phil gateway to_phil sec-level compatible
set vpn corp_phil bind interface tunnel.1
set vpn corp_phil proxy-id local-ip 1.2.2.5/32 remote-ip 10.10.10.1/32 any
(o bien)
Certificados
set ike gateway to_phil cert peer-ca 1
set ike gateway to_phil cert peer-cert-type x509-sig
set vpn corp_phil bind interface tunnel.1
set vpn corp_phil proxy-id local-ip 1.2.2.5/32 remote-ip 10.10.10.1/32 any

5. Rutas
6. Directivas
set policy top from dmz to untrust “Mail Server” phil remote_mail permit
set policy top from untrust to dmz phil “Mail Server” remote_mail permit
save
NetScreen-Remote
1. Haga clic en Options > Global Policy Settings y seleccione la casilla de
verificación Allow to Specify Internal Network Address.

2. Options > Secure > Specified Connections.
3. Haga clic en el botón Add a new connection y escriba Mail junto al icono de la
nueva conexión que aparecerá en pantalla.

Protocol: All

7. Haga clic en My Identity y elija una de estas dos opciones:
Haga clic en Pre-shared Key > Enter Key: Escriba h1p8A24nG5, después haga
clic en OK.
ID Type: E-mail Address; pm@juniper.net

Internal Network IP Address: 10.10.10.1
(o bien)
Seleccione el certificado que contiene la dirección de correo electrónico

“pm@juniper.net” en la lista desplegable “Select Certificate”.


(o bien)

Hash Alg: SHA-1

protocolos IPSec:

Hash Alg: SHA-1

Hash Alg: MD5

Encrypt Alg: DES
Hash Alg: SHA-1

Encrypt Alg: DES
Hash Alg: MD5
VPN de acceso telefónico basada en directivas, interlocutor dinámico

En este ejemplo, un túnel VPN conecta de forma segura al usuario situado tras el
dispositivo NetScreen-Remote a la interfaz de la zona Untrust del dispositivo de
seguridad que protege el servidor de correo en la zona DMZ. La interfaz de la zona
Untrust tiene una dirección IP estática. El cliente NetScreen-Remote tiene una
dirección IP externa asignada dinámicamente y una dirección IP interna estática
(virtual). El administrador del dispositivo de seguridad debe conocer la dirección IP
interna del cliente, de forma que pueda agregarla a la libreta de direcciones de la
zona Untrust para su uso en directivas de tráfico de túnel desde ese origen. Cuando
el cliente NetScreen-Remote establece el túnel, el tráfico que lo atraviesa puede
originarse desde el otro extremo.

Figura 43: VPN de acceso telefónico basada en directivas, interlocutor dinámico

Usuario remoto Phil Interfaz de salida
NetScreen-Remote Zona Untrust Oficina corporativa
ethernet3, 1.1.1.1/24 Zona DMZ
Puerta de enlace 1.1.1.250 ethernet2, 1.2.2.1/24 Servidor de correo
Petición electrónico
SMTP 1.2.2.5
Internet
Petición
Túnel VPN IDENT
Dirección IP interna Dirección IP externa Zona Untrust Zona DMZ

10.10.10.1 dinámica
En este ejemplo, Phil desea acceder a su correo electrónico desde el servidor de

correo del sitio de la empresa. Cuando intenta hacerlo, es autenticado por el
programa del servidor de correo, que le envía una petición IDENT a través del túnel.
NOTA: El servidor de correo puede enviar la petición IDENT a través del túnel sólo si el
administrador de seguridad agrega un servicio personalizado para ello (TCP,
puerto 113) y establece una directiva de salida que permita el tráfico a través del
túnel hacia 10.10.10.1.
La clave previamente compartida es h1p8A24nG5. En este ejemplo se asume que

certificado local en NetScreen-Remote contiene el U-FQDN pm@juniper.net. (Para
más información sobre cómo obtener y cargar certificados, consulte “Certificados y
CRL” en la página 24.) Para los niveles de seguridad de las fases 1 y 2, debe
especificar una propuesta de fase 1 (pre-g2-3des-sha para el método de clave
previamente compartida o rsa-g2-3des-sha para certificados) y seleccionar el
conjunto de propuestas “Compatible” para la fase 2.
WebUI
1. Interfaces
haga clic en OK:
Zone Name: DMZ

haga clic en OK:
Zone Name: Untrust


2. Direcciones

Zone: DMZ
Address Name: Phil

Zone: Untrust
3. Servicios
Service Name: Ident

Service Timeout:

Ident
MAIL
POP3
4. VPN
y haga clic en OK:
Gateway Name: To_Phil

Dynamic IP Address: (seleccione), Peer ID: pm@juniper.net



enlace:

pre-g2-3des-sha
(o bien)
Certificados

enlace:

rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
VPN Name: corp_Phil

Remote Gateway:
Predefined: (seleccione), To_Phil
5. Ruta


6. Directivas
haga clic en OK:
Source Address:
Action: Tunnel
VPN Tunnel: corp_Phil
CLI
1. Interfaces
2. Direcciones
set address dmz “mail server” 1.2.2.5/32
set address untrust phil 10.10.10.1/32
3. Servicios
4. VPN
(o bien)
Certificados
set ike gateway to_phil cert peer-ca 1
set ike gateway to_phil cert peer-cert-type x509-sig

5. Ruta

6. Directivas
set policy top from untrust to dmz phil “mail server” remote_mail tunnel vpn
corp_phil
set policy top from dmz to untrust “mail server” phil remote_mail tunnel vpn
corp_phil
save
NetScreen-Remote
1. Haga clic en Options > Global Policy Settings y seleccione Allow to Specify
Internal Network Address.
2. Options > Secure > Specified Connections.
3. Haga clic en Add a new connection y escriba Mail junto al icono de nueva

Protocol: All

7. Click My Identity and do either of the following:
Click Pre-shared Key > Enter Key: Escriba h1p8A24nG5, después haga clic
en OK.

(o bien)
Select the certificate that contains the email address “pmason@email.com”

from the Select Certificate dropdown list.



(o bien)

Hash Alg: SHA-1
protocolos IPSec:

Hash Alg: SHA-1

Hash Alg: MD5

Encrypt Alg: DES
Hash Alg: SHA-1

Encrypt Alg: DES
Hash Alg: MD5

Directivas bidireccionales para usuarios de VPN de acceso telefónico

Es posible crear directivas bidireccionales para VPN de acceso telefónico. Esta
configuración presenta unas funciones similares a la configuración VPN para
interlocutores dinámicos. Sin embargo, con una configuración de VPN para
interlocutores dinámicos, el administrador del dispositivo de seguridad debe
conocer el espacio de direcciones IP interno del usuario de acceso telefónico, de
forma que pueda utilizarlo como dirección de destino cuando configure una
directiva de salida (consulte “VPN de acceso telefónico basada en directivas,
interlocutor dinámico” en la página 177). Con una configuración de usuario de VPN
de acceso telefónico, el administrador en el sitio LAN no necesita conocer el
espacio de direcciones interno del usuario de acceso telefónico. El dispositivo de
seguridad que protege la red LAN utiliza la dirección predefinida “Dial-Up VPN”
como dirección de origen en la directiva de entrada y la de destino en la directiva
de salida.
La posibilidad de crear directivas bidireccionales para un túnel VPN permite que el

tráfico se origine en un extremo de la LAN de la conexión VPN cuando ya se ha
establecido la conexión (el equipo remoto debe iniciar en primer lugar la creación
del túnel). Observe que, a diferencia de un túnel VPN de acceso telefónico de
interlocutor dinámico, esta función hace necesario que los servicios de las
directivas de entrada y salida sean idénticos.
NOTA: ScreenOS no admite grupos de servicios ni de direcciones en las directivas

bidireccionales que hacen referencia a una configuración de VPN de acceso
telefónico.
El espacio de direcciones interno de dos o más usuarios de una VPN de acceso

telefónico conectados simultáneamente podría hacer que se superpusieran. Por
ejemplo, los usuarios de acceso telefónico A y B podrían tener un espacio de
direcciones IP interno 10.2.2.0/24. Si esto sucede, el dispositivo de seguridad envía
todo el tráfico de VPN saliente al usuario A y al usuario B a través de la VPN de la
que se incluye una referencia en la primera directiva que encuentre en la lista de
directivas. Si la directiva de salida relativa a la VPN del usuario A aparece primero
en la lista de directivas, el dispositivo de seguridad envía al usuario A todo el tráfico
VPN saliente para los usuarios A y B.
De forma similar, la dirección interna de un usuario de acceso telefónico podría

superponerse con una dirección de cualquier otra directiva, independientemente de
si esa otra directiva hace referencia a un túnel VPN. Si esto sucede, el dispositivo de
seguridad aplica la primera directiva que coincida con los atributos básicos de
tráfico relativos a la dirección de origen, dirección de destino, número de puerto de
origen, número de puerto de destino o servicio. Para evitar que una directiva
bidireccional para una VPN de acceso telefónico con una dirección derivada
dinámicamente anule otra directiva con una dirección estática, Juniper Networks
recomienda colocar la directiva bidireccional de VPN de acceso telefónico en una
posición más baja en la lista de directivas.
En este ejemplo configuraremos directivas bidireccionales para un túnel VPN de

acceso telefónico AutoKey IKE llamado VPN_dial para el usuario IKE dialup-j con la
identificación IKE jf@ns.com. Para las negociaciones de la fase 1, utilice la
propuesta pre-g2-3des-sha, con la clave previamente compartida Jf11d7uU.
Seleccione el conjunto predefinidos de propuestas “Compatible” para las
negociaciones de la fase 2.

El usuario IKE inicia una conexión VPN al dispositivo de seguridad desde la zona
Untrust para acceder a los servidores corporativos de la zona Trust. Una vez el
usuario IKE establece la conexión VPN, el tráfico se puede iniciar desde cualquiera
de los dos extremos del túnel.
La interfaz de la zona Trust es ethernet1, tiene la dirección IP 10.1.1.1/24 y se

encuentra en modo NAT. La interfaz de la zona Untrust es ethernet3 y tiene la
dirección IP 1.1.1.1/24. La ruta predeterminada apunta al enrutador externo
situado en 1.1.1.250.
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Objetos
Address Name: trust_net

Zone: Trust
Policy > Policy Elements > Users > Local > New: Introduzca los siguientes
User Name: dialup-j

Status: Enable
Simple Identity: (seleccione); jf@ns.com
3. VPN
y haga clic en OK:
Gateway Name: dialup1

Dialup User: (seleccione); dialup-j
Preshared Key: Jf11d7uU


enlace:

pre-g2-3des-sha
VPN Name: VPN_dial

Remote Gateway:
Create a Simple Gateway: (seleccione)
Type:
Dialup User: (seleccione); dialup-j
Preshared Key: Jf11d7uU
4. Ruta

5. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), trust_net
Service: ANY
Action: Tunnel
VPN Tunnel: VPN_dial
CLI
1. Interfaces
2. Objetos
set address trust trust_net 10.1.1.0/24
set user dialup-j ike-id u-fqdn jf@ns.com

3. VPN
set ike gateway dialup1 dialup dialup-j aggressive outgoing-interface ethernet3
preshare Jf11d7uU proposal pre-g2-3des-sha
set vpn VPN_dial gateway dialup1 sec-level compatible
4. Ruta
5. Directivas
set policy from untrust to trust “Dial-Up VPN” trust_net any tunnel vpn VPN_dial
set policy from trust to untrust trust_net “Dial-Up VPN” any tunnel vpn VPN_dial
save

2. Haga clic en Add a new connection y escriba Corp junto al icono de nueva

Remote Party Identity and Addressing
ID Type: IP Subnet
Subred: 10.1.1.0
Mask: 255.255.255.0
Protocol: All
5. Haga clic en My Identity: Siga uno de estos dos pasos:
Click Pre-shared Key > Enter Key: Escriba Jf11d7uU y después haga clic
en OK.
ID Type: (seleccione E-mail Address) y escriba jf@ns.com.



(o bien)

Hash Alg: SHA-1
protocolos IPSec:

Hash Alg: SHA-1

Hash Alg: MD5

Encrypt Alg: DES
Hash Alg: SHA-1

Encrypt Alg: DES
Hash Alg: MD5
Identificación IKE de grupo

Algunas organizaciones pueden tener muchos usuarios de acceso telefónico VPN.
Por ejemplo, un departamento de ventas puede tener cientos de usuarios, muchos
de los cuales necesitarán comunicación segura por acceso telefónico cuando se
encuentran fuera de las oficinas. Con tantos usuarios, no resulta práctico crear una
definición de usuario, una configuración de VPN y una directiva para cada uno.
188 Identificación IKE de grupo

Para evitar este problema, el método de identificación IKE de grupo permite que
una sola definición esté disponible para múltiples usuarios. La definición de usuario
para una identificación IKE de grupo se aplica a todos los usuarios que tengan
certificados con valores específicos en el nombre completo (DN) o a todos los
usuarios cuya identificación IKE completa y clave previamente compartida en su
cliente VPN coincida con una identificación IKE parcial y una clave previamente
compartida del dispositivo de seguridad.
NOTA: Cuando un usuario IKE de acceso telefónico se conecta al dispositivo de

seguridad, éste primero extrae y utiliza la identificación IKE completa para buscar
sus registros de puerta de enlace de interlocutor por si el usuario no pertenece a
un grupo de usuarios de identificación IKE de grupo. Si la búsqueda con la
identificación IKE completa no ofrece ningún resultado, el dispositivo de
seguridad realizará una nueva búsqueda de parte de la identificación IKE,
buscando coincidencias entre la identificación IKE entrante incorporada y un
usuario ya configurado de la identificación IKE de grupo.
Debe agregar un único usuario de identificación IKE de grupo a un grupo de

usuarios IKE de una VPN de acceso telefónico y especificar el número máximo de
conexiones simultáneas que admitirá el grupo. El número máximo de sesiones
simultáneas no podrá exceder el número máximo de asociaciones de seguridad
admitidas en la fase 1 o el número máximo de túneles VPN admitidos en la
plataforma.
Identificación IKE de grupo con certificados

La identificación IKE de grupo con certificados es una técnica para llevar a cabo la
autenticación IKE para un grupo de usuarios IKE de acceso telefónico sin tener que
configurar un perfil de usuario independiente para cada uno de ellos. En lugar de
hacer eso, el dispositivo de seguridad utiliza un único perfil de usuario de
identificación IKE de grupo con una identificación IKE parcial. El usuario IKE de
acceso telefónico podrá establecer correctamente un túnel VPN a un dispositivo de
seguridad si la configuración de VPN en su cliente VPN especifica un certificado que
contenga elementos de nombre completo con coincidan con los configurados como
definición de la identificación IKE parcial en el perfil de usuario de identificación
IKE de grupo en el dispositivo de seguridad.
Identificación IKE de grupo 189

Figura 44: Identificación IKE de grupo con certificados
Grupo de usuarios de acceso telefónico

ID IKE de grupo con claves
Usuarios IKE de previamente compartidas
acceso telefónico (nombre completo)
Certificado
DN:
cn=alice
ou=eng Usuario de identificación
---------- IKE de grupo
---------- Tipo de ID IKE ASN1-DN
ID IKE parcial: ou=eng
Certificado
DN:
cn=bob Para autenticar el usuario, el dispositivo
ou=eng compara un elemento específico del nombre
---------- completo (dn) asociado al grupo de usuarios de
---------- acceso telefónico con el elemento
correspondiente del certificado y del dn
Certificado utilizados en la carga de datos de la
DN: identificación IKE que acompaña al paquete
cn=carol inicial de la fase 1.
ou=sales
----------
---------- Nota: Como el DN en el certificado de Carol
no incluye ou=eng, el dispositivo rechaza la
petición de conexión.
Puede configurar una identificación IKE de grupo con certificados tal y como se
indica a continuación:
En el dispositivo de seguridad:
1. Cree un nuevo usuario de identificación IKE de grupo con una identidad IKE
parcial (como ou=sales,o=netscreen) y especifique cuántos usuarios de acceso
telefónico podrán utilizar el perfil de la identificación IKE de grupo para
conectarse.
2. Asigne el nuevo usuario de ID IKE de grupo al grupo de usuarios de acceso

telefónico y asigne un nombre al grupo.
NOTA: Sólo puede asignar un usuario de ID IKE de grupo a un grupo de usuarios IKE.
3. En la configuración de la VPN de acceso telefónico AutoKey IKE, especifique el

nombre del grupo de usuarios de acceso telefónico, indique que las
negociaciones de la fase 1 serán del modo dinámico y que para la
autenticación se utilizarán certificados (RSA o DSA, según el tipo de certificado
cargado en los clientes VPN de acceso telefónico).
4. Cree una directiva que permita el tráfico de entrada a través de la VPN de

acceso telefónico especificada.
En el cliente VPN:
1. Obtenga y cargue un certificado cuyo nombre completo contenga la misma
información definida en la identificación IKE parcial del dispositivo de
seguridad.

2. Configure un túnel VPN al dispositivo de seguridad utilizando el modo dinámico

para las negociaciones de la fase 1, especifique el certificado cargado
anteriormente y seleccione Distinguished Name para el tipo de identificación
IKE local.
A partir de ese momento, cada usuario IKE de acceso telefónico que disponga de
un certificado con elementos de nombre completo que coincidan con la
identificación IKE parcial definida en el perfil de usuario de la ID IKE de grupo
podrá establecer correctamente un túnel al dispositivo de seguridad. Por ejemplo, si
el usuario de ID IKE de grupo tiene la ID IKE OU=sales,O=netscreen, el dispositivo
de seguridad aceptará las negociaciones de fase 1 de cualquier usuario que tenga
un certificado con esos elementos en su nombre completo. El número máximo de
usuarios IKE de acceso telefónico que se podrán conectar al dispositivo de
seguridad dependerá del número máximo de sesiones simultáneas que especifique
en el perfil de usuario de identificación IKE de grupo.
Tipos de identificación IKE ASN1-DN Wildcard y Container

Cuando se define la ID IKE para un usuario IKE de grupo, se utiliza el nombre
completo según la norma ASN-1 (ASN1-DN) como tipo de identificación IKE de la
configuración de identidad. Esta notación constituye una cadena de valores
ordenados (a menudo pero no siempre= desde lo más general a lo más específico.
Consulte la Figura 45 para obtener un ejemplo.
Figura 45: Nombre distinguido ASN1

ASN1-DN: C=us,ST=ca,L=sunnyvale,O=juniper,OU=sales,CN=jozef
C=us Leyenda:
General
C = País
ST=ca
ST = Estado
L=sunnyvale L = Localidad
O = Organización
O=juniper OU = Unidad organizativa
CN = Nombre común
OU=sales
CN=jozef
Específico
Cuando se configura el usuario de la identificación IKE de grupo, debe especificar la

ID ASN1-DN del interlocutor como uno de estos dos tipos:
Wildcard: ScreenOS autentica la ID de un usuario IKE de acceso telefónico si

los valores de los campos identificativos del ASN1-DN de dicho usuario
coinciden con los de los campos identificativos del ASN1-DN del usuario IKE de
grupo. El tipo de ID Wildcard sólo admite un valor por cada campo
identificativo (por ejemplo, “ou=eng” o bien “ou=sw” pero no
“ou=eng,ou=sw”). Así, el orden que sigan los campos identificativos en las
dos cadenas ASN1-DN no es importante.

Container: ScreenOS autentica la ID de un usuario IKE de acceso telefónico si

los valores de los campos identificativos del ASN1-DN de dicho usuario
coinciden exactamente con los de los campos identificativos del ASN1-DN del
usuario IKE de grupo. El tipo de ID Container admite múltiples entradas por
cada campo identificativo (por ejemplo, “ou=eng,ou=sw,ou=screenos”). El
orden de los valores en los campos identificativos de las dos cadenas ASN1-DN
debe ser idéntico.
Cuando configure una ID de ASN1-DN para un usuario IKE remoto, deberá

especificar el tipo como “wildcard” o “container”, y definir la ID ASN1-DN que
espere recibir en el certificado del interlocutor (por ejemplo,
“c=us,st=ca,cn=kgreen”). Si configura una ID ASN1-DN para una ID IKE local,
utilice la siguiente palabra clave: [DistinguishedName]. Incluya los corchetes y
escríbalo exactamente como se indica.
ID IKE de ASN1-DN de tipo Wildcard

Un ASN1-DN de tipo Wildcard hace necesario que los valores de la ID IKE del
nombre completo del interlocutor remoto coincidan con los valores de la ID IKE
parcial del ASN1-DN del usuario IKE de grupo. El orden que sigan estos valores en la
cadena del ASN1-DN es irrelevante. Por ejemplo, si la ID del usuario IKE de acceso
telefónico y la ID del usuario IKE de grupo son las siguientes:
ID IKE de ASN1-DN completo del usuario IKE de acceso telefónico:

CN=kristine,OU=finance,O=juniper,ST=ca,C=us
ID IKE parcial del ASN1-DN del usuario IKE de grupo: C=us,O=juniper
una ID IKE de tipo Wildcard del ASN1-DN compara las dos ID IKE, aunque el orden
de los valores en las dos ID difiera.
Figura 46: Autenticación exitosa de ASN1-DN Wildcard

usuario de acceso telefónico IKE Wildcard del usuario IKE de grupo
ID IKE ASN1-DN ID IKE ASN1-DN
El ASN1-DN del usuario IKE de
acceso telefónico contiene los valores E= E=
especificados en el ASN1-DN del
usuario IKE de grupo. El orden de los
valores es irrelevante. CN=kristine C=us
Autenticación
satisfactoria
OU=finance ST=
O=juniper L=
L= O=juniper
ST=ca OU=
C=us CN=

ID IKE de ASN1-DN de tipo Container

Una ID de tipo Container del ASN1-DN permite que la ID del usuario IKE de grupo
tenga múltiples entradas en cada campo identificativo. ScreenOS autentica un
usuario IKE de acceso telefónico si la ID de usuario de acceso telefónico contiene
valores que coinciden al cien por cien con los valores de la ID del usuario IKE de
grupo. Al contrario de lo que sucede con el tipo Wildcard, el orden de los campos
del ASN1-DN también debe coincidir en las ID del usuario IKE de acceso telefónico
y del usuario IKE de grupo. Si hay varios valores, su orden en los campos
correspondientes también deberá ser igual.
Figura 47: Éxito y fallo de la autenticación utilizando las ID de tipo Container del ASN1-DN
ID IKE de ASN1-DN del usuario ID IKE Container del ASN1-DN
IKE de acceso telefónico del usuario IKE de grupo
E= E=
El primer ASN1-DN de usuario
IKE de acceso telefónico
contiene valores exactamente
iguales a los de ASN1-DN C=us C=us
ASN1-DN. El orden de las
entradas múltiples en el campo Autenticación
de identificación OU también ST=ca ST=
es idéntico. satisfactoria
L= sf L=
O=juniper O=juniper
OU=mkt,OU=dom,OU=west OU=mkt,OU=dom,OU=west
CN=rick CN=
ID IKE de ASN1-DN del usuario ID IKE Container del ASN1-DN

IKE de acceso telefónico del usuario IKE de grupo
E= E=
El segundo ASN1-DN de usuario

IKE de acceso telefónico C=us C=us
contiene valores exactamente
iguales a los de ASN1-DN. Sin Autenticación
embargo, el orden de las ST=ca ST=
entradas múltiples en el campo fallida
de identificación OU no es igual.
L= la L=
O=juniper O=juniper
OU=mkt,OU=west,OU=dom OU=mkt,OU=dom,OU=west
CN=tony CN=

Creación de una identificación IKE de grupo (certificados)

En este ejemplo definirá un nuevo usuario de identificación IKE de grupo llamado
Usuario1. Configurará la definición para que acepte un máximo de 10
negociaciones simultáneas en la fase 1 por parte de clientes VPN con certificados
RSA que contengan O=netscreen y OU=marketing. La autoridad de certificación
(CA) será Verisign. El grupo de usuarios IKE de acceso telefónico será oficina_1.
Figura 48: Identificación IKE de grupo

Interfaz de salida Zona Trust
Zona Untrust ethernet1, 10.1.1.1/24
ethernet3, 1.1.1.1/24 Modo NAT

Usuario telefónico
ID IKE: Internet LAN web1
o=juniper Túnel VPN 10.1.1.5
ou=marketing Perfil de usuario de
identificación IKE de grupo
Nombre de usuario:
puerta de enlace 1.1.1.250 Usuario1
Grupo de usuarios: oficina_1
Nombre distinguido:
o=juniper
ou=marketing
Los usuarios IKE de acceso telefónico envían un nombre completo como su ID IKE.
El nombre completo (DN) en un certificado para un usuario IKE de acceso
telefónico en este grupo puede aparecer como la siguiente cadena:
C=us,ST=ca,L=sunnyvale,O=netscreen,OU=marketing,CN=carrie
nowocin,CN=a2010002,CN=ns500,
CN=4085557800,CN=rsa-key,CN=10.10.5.44
Como los valores O=netscreen y OU=marketing aparecen en el certificado del

interlocutor y el usuario utiliza el nombre completo como su tipo de identificación
IKE, el dispositivo de seguridad autenticará el usuario.
Para los niveles de seguridad de las fase 1 y fase 2, debe especificar la propuesta de
fase 1 (rsa-g2-3des-sha para certificados) y seleccionar el conjunto de propuestas
predefinido “Compatible” para la fase 2.
Ahora debe configurar una VPN de acceso telefónico y una directiva que permita el
tráfico HTTP a través del túnel VPN para acceder al servidor Web1. También se
incluirá la configuración del cliente VPN remoto (utilizando NetScreen-Remote).
WebUI
1. Interfaces
haga clic en OK:
Zone Name: Trust

Interface Mode: NAT

haga clic en OK:
Zone Name: Untrust

2. Dirección
Address Name: web1

Zone: Trust
3. Usuarios
Nombre de usuario: Usuario1

Status Enable: (seleccione)
Number of Multiple Logins with same ID: 10
Use Distinguished Name For ID: (seleccione)
OU: marketing
Organization: juniper
Objects > User Groups > Local > New: Escriba oficina_1 en el campo Group
Name, realice la acción que se indica a continuación y después haga clic en OK:
Seleccione Usuario1 y utilice el botón << para mover esta definición de la

4. VPN
y haga clic en OK:
Gateway Name: Corp_GW

Remote Gateway Type: Dialup User Group: (seleccione), Group: oficina_1

enlace:

rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG

VPN Name: Corp_VPN

Remote Gateway: Predefined: (seleccione), Corp_GW
5. Ruta

6. Directiva
haga clic en OK:
Source Address:
Service: HTTP
Action: Tunnel
Tunnel VPN: Corp_VPN
CLI
1. Interfaces
2. Dirección
set address trust web1 10.1.1.5/32
3. Usuarios
set user Usuario1 ike-id asn1-dn wildcard o=juniper,ou=marketing share-limit 10
set user-group oficina_1 user Usuario1
4. VPN
set ike gateway Corp_GW dialup oficina_1 aggressive outgoing-interface ethernet3
set ike gateway Corp_GW cert peer-ca 1
set ike gateway Corp_GW cert peer-cert-type x509-sig
set vpn Corp_VPN gateway Corp_GW sec-level compatible

5. Ruta

6. Directiva
set policy top from untrust to trust “Dial-Up VPN” web1 http tunnel vpn Corp_VPN
save

2. Haga clic en Add a new connection y escriba web1 junto al icono de nueva

Protocol: Seleccione All, escriba HTTP, pulse el tabulador y escriba 80.
4. Haga clic en el signo MÁS situado a la izquierda del icono de web1 para ampliar
la directiva de la conexión.
5. Haga clic en My Identity: Seleccione el certificado que tiene los elementos

o=netscreen,ou=marketing en su nombre completo en la lista desplegable
Select Certificate.
ID Type: Seleccione Distinguished Name en la lista desplegable.
NOTA: En este ejemplo se asume que ya ha cargado un certificado adecuado en el cliente

NetScreen-Remote. Para obtener más información sobre cómo cargar certificados
en el cliente NetScreen-Remote, consulte la documentación de NetScreen-Remote.

8. Haga clic en Authentication (Phase 1) > Proposal 1: Seleccione los siguientes

algoritmos de encriptación e integridad de datos:

Hash Alg: SHA-1
protocolos IPSec:

Hash Alg: SHA-1


Hash Alg: MD5

Encrypt Alg: DES
Hash Alg: SHA-1

Encrypt Alg: DES
Hash Alg: MD5
Configuración de una ID IKE de grupo con claves previamente compartidas

La identificación IKE de grupo con claves previamente compartidas es una técnica
para llevar a cabo la autenticación IKE para un grupo de usuarios IKE de acceso
telefónico sin tener que configurar un perfil de usuario independiente para cada
uno de ellos. En lugar de hacer eso, el dispositivo de seguridad utiliza un único perfil
de usuario de identificación IKE de grupo con una identificación IKE parcial. El
usuario IKE de acceso telefónico podrá establecer correctamente un túnel VPN a un
dispositivo de seguridad si la configuración de su cliente VPN tiene la clave
previamente compartida correcta y si la mayor parte de la ID IKE completa del
usuario coincide con la ID IKE parcial del perfil de usuario de la identificación IKE
de grupo.

Figura 49: ID IKE de grupo con claves previamente compartidas
ID IKE completa
Usuarios IKE de +
acceso telefónico Clave previamente Grupo de usuarios de acceso telefónico
compartida
alice.eng.jnpr.net
+
011fg3322eda837c
bob.eng.jnpr.net Usuario de identificación IKE de grupo

+ ID IKE parcial: eng.jnpr.net
bba7e22561c5da82 Valor de inicialización de clave previamente
compartida: N11wWd2
El dispositivo de seguridad genera en tiempo

real una clave previamente compartida cuando
un usuario IKE envía su identificación IKE
carol.jnpr.net completa.
+
834a2bbd32adc4e9 (Clave previamente compartida de cada usuario
Nota: Ya que la identificación de IKE para IKE = valor inicial de clave previamente
Carol no es carol.eng.jnpr.net, el dispositivo de compartida x ID IKE completa).
seguridad rechaza la petición de conexión.
El tipo de ID IKE que utilice para la ID IKE de grupo con función de clave
previamente compartida puede ser una dirección de correo electrónico o un
nombre de dominio completo (FQDN).
Puede configurar una identificación IKE de grupo con claves previamente

compartidas tal y como se indica a continuación:
En el dispositivo de seguridad:
1. Cree un nuevo usuario de identificación IKE de grupo con una identidad IKE
parcial (como juniper.net) y especifique la cantidad de usuarios de acceso
telefónico que podrán utilizar el perfil de la identificación IKE de grupo para
conectarse.
2. Asigne el nuevo usuario de ID IKE de grupo a un grupo de usuarios de acceso

telefónico.
3. En la configuración de la VPN de acceso telefónico AutoKey IKE, asigne un

nombre para la puerta de enlace remota (p. ej., road1), especifique el grupo de
usuarios de acceso telefónico e introduzca un valor inicial de clave previamente
compartida.
4. Utilice el siguiente comando CLI para generar una clave previamente

compartida individual para el usuario de acceso telefónico utilizando el valor
inicial de clave previamente compartida y la ID IKE completa del usuario (como
lisa@juniper.net).
exec ike preshare-gen cadena_nombre cadena_nombre_usuario

(por ejemplo) exec ike preshare-gen road1 lisa@juniper.net
5. Registre la clave previamente compartida para poder utilizarla durante la

configuración de un cliente VPN remoto.

En el cliente VPN:
Configure un túnel VPN al dispositivo de seguridad utilizando el modo dinámico
en las negociaciones de la fase 1 e introduzca la clave previamente compartida
que generó anteriormente en el dispositivo de seguridad.
A partir de ese momento, el dispositivo de seguridad podrá autenticar

correctamente a cada usuario individual cuya ID IKE contenga una sección que
coincida con el perfil de usuario de ID IKE de grupo parcial. Por ejemplo, si el
usuario de ID IKE de grupo tiene la identidad IKE juniper.net, cualquier usuario con
ese nombre de dominio en su ID IKE puede iniciar negociaciones IKE de fase 1 en
modo dinámico con el dispositivo de seguridad. Por ejemplo: alice@juniper.net,
bob@juniper.net, y carol@juniper.net. El número de usuarios que se pueden
conectar dependerá del número máximo de sesiones simultáneas especificadas en
el perfil de usuario de ID IKE de grupo.
En este ejemplo definirá un nuevo usuario de identificación IKE de grupo llamado

Usuario2. A continuación, configurará la definición para que acepte un máximo de
10 negociaciones simultáneas en la fase 1 por parte de clientes VPN con claves
previamente compartidas que contengan una ID IKE que termine con la cadena
juniper.net. El valor inicial de la clave previamente compartida es jk930k. El grupo
de usuarios IKE de acceso telefónico será oficina_2.
Figura 50: ID IKE de grupo (claves previamente compartidas)

Interfaz de salida Zona Trust
Zona Untrust ethernet1, 10.1.1.1/24
ethernet3, 1.1.1.1/24 Modo NAT
Zona Untrust
Zona Trust
Usuario de acceso
telefónico con Internet LAN web1
ID IKE: 10.1.1.5
joe@juniper.net Túnel VPN
Perfil de usuario de
identificación IKE de grupo
puerta de enlace 1.1.1.250 Nombre de usuario: Usuario2
Grupo de usuario: oficina_2
ID simple: juniper.net
Tanto para las negociaciones de fase 1 como para las de fase 2, deberá seleccionar
el nivel de seguridad predefinido como “Compatible”. Todas las zonas de seguridad
se encuentran en el dominio de enrutamiento trust-vr.
WebUI
1. Interfaces
haga clic en OK:
Zone Name: Trust

Interface Mode: NAT

haga clic en OK:
Zone Name: Untrust

2. Dirección
Address Name: web1

Zone: Trust
3. Usuarios
User Name: Usuario2

Status: Enable
IKE Identity: juniper.net
Policy > Policy Elements > User Groups > Local > New: Escriba oficina_2 en
el campo Group Name, realice la acción que se indica a continuación y después
haga clic en OK:
Seleccione Usuario2 y utilice el botón << para trasladarlo de la columna

Available Members a la columna Group Members.
4. VPN
NOTA: La WebUI sólo permite introducir un valor para la clave previamente compartida,
pero no un valor inicial a partir del cual el dispositivo de seguridad derive una
clave previamente compartida. Para introducir un valor inicial para clave
previamente compartida al configurar una puerta de enlace IKE, debe utilizar la
interfaz CLI.
VPN Name: Corp_VPN

Remote Gateway: Predefined: (seleccione), Corp_GW
5. Ruta


6. Directiva
haga clic en OK:
Source Address:
Service: HTTP
Action: Tunnel
Tunnel VPN: Corp_VPN
CLI
1. Interfaces
2. Dirección
3. Usuarios
set user Usuario2 ike-id u-fqdn juniper.net share-limit 10
set user-group oficina_2 user Usuario2
4. VPN
set ike gateway Corp_GW dialup oficina_2 aggressive seed-preshare jk930k
sec-level compatible
set vpn Corp_VPN gateway Corp_GW sec-level compatible
5. Ruta
6. Directiva
set policy top from untrust to trust “Dial-Up VPN” web1 http tunnel vpn Corp_VPN
save
Obtención de la clave previamente compartida

La clave previamente compartida sólo se puede obtener utilizando el siguiente
comando CLI:
exec ike preshare-gen cadena_nombre cadena_nombre_usuario
La clave previamente compartida, basada en el valor inicial de clave

previamente compartida jk930k (como se especificó en la configuración de la
puerta de enlace remota llamada Corp_GW) y la identificación completa de
usuario individual heidi@juniper.net es
11ccce1d396f8f29ffa93d11257f691af96916f2.



Protocol: Seleccione All, escriba HTTP, pulse el tabulador y escriba 80.

6. Haga clic en My Identity: Click Pre-shared Key > Enter Key: Escriba
11ccce1d396f8f29ffa93d11257f691af96916f2, después haga clic en OK.
ID Type: (seleccione E-mail Address) y escriba heidi@juniper.net.
después en el símbolo MÁS situado a la izquierda de Authentication (Fase 1) y
de Key Exchange (Fase 2) para ampliar aún más la directiva.


Hash Alg: SHA-1
9. Haga clic en Authentication (Fase 1) > Create New Proposal: Seleccione los

Hash Alg: MD5

Encrypt Alg: DES
Hash Alg: SHA-1


Encrypt Alg: DES
Hash Alg: MD5
protocolos IPSec:

Hash Alg: SHA-1

Hash Alg: MD5

Encrypt Alg: DES
Hash Alg: SHA-1

Encrypt Alg: DES
Hash Alg: MD5
Identificación IKE compartida

La función de identificación IKE compartida facilita la implementación de un gran
número de usuarios de acceso telefónico. Gracias a ella, el dispositivo de seguridad
autentica múltiples usuarios VPN de acceso telefónico utilizando una única
identificación IKE de grupo y clave compartida. De esta forma, proporciona
protección IPSec para grandes grupos de usuarios remotos por medio de una
configuración VPN común.
204 Identificación IKE compartida

Esta función es similar a la identificación IKE de grupo con función de claves

previamente compartidas, con las siguientes diferencias:
Con la función de ID IKE de grupo, la ID IKE puede ser una dirección de correo
electrónico o un nombre de dominio completo (FQDN). Para esta función, la ID
IKE debe ser una dirección de correo electrónico.
En lugar de utilizar el valor inicial de clave previamente compartida y la ID IKE

de usuario completa para generar una clave previamente compartida para cada
usuario, se especifica una única clave previamente compartida para todos los
usuarios del grupo.
Debe utilizar XAuth para autenticar los usuarios individuales.
Para configurar una ID IKE compartida y una clave previamente compartida en el

1. Cree un nuevo usuario de identificación IKE de grupo y especifique cuántos

usuarios de acceso telefónico podrán utilizar la ID IKE para conectarse. En esta
función, utilice una dirección de correo electrónico como la identificación IKE.
2. Asigne la nueva ID IKE de grupo a un grupo de usuarios de acceso telefónico.
3. En la configuración VPN de acceso telefónico a LAN AutoKey IKE, cree una

puerta de enlace de ID IKE compartida.
4. Defina los usuarios XAuth y habilite XAuth en la puerta de enlace IKE remota.
En el cliente VPN:
Configure un túnel VPN al dispositivo de seguridad utilizando el modo dinámico en

las negociaciones de la fase 1 e introduzca la clave previamente compartida que
definió anteriormente en el dispositivo de seguridad. A continuación, éste
autenticará cada usuario remoto tal y como se indica a continuación:
Durante las negociaciones de la fase 1, el dispositivo de seguridad primero

autentica el cliente VPN comparando la ID IKE y la clave previamente compartida
que el cliente envía con la ID IKE y la clave previamente compartida del dispositivo
de seguridad. Si coinciden, el dispositivo de seguridad utiliza XAuth para autenticar
el usuario individual. Envía una petición de inicio de sesión al usuario remoto entre
las negociaciones IKE de la fase 1 y la fase 2. Si el usuario remoto consigue
conectarse con el nombre de usuario y la contraseña correctos, comenzarán las
negociaciones de la fase 2.
En este ejemplo crearemos un nuevo usuario de identificación IKE de grupo

llamado Ventas_remotas. Aceptará hasta 250 negociaciones simultáneas de fase 1
desde clientes VPN con la misma clave previamente compartida (abcd1234). El
nombre del grupo de usuarios IKE de acceso telefónico será V_R. Además,
configuraremos dos usuarios XAuth, Joe y Mike.
Tanto para las negociaciones de fase 1 como de fase 2, deberá seleccionar el nivel
de seguridad predefinido como “Compatible”. Todas las zonas de seguridad se
Identificación IKE compartida 205

Figura 51: ID IKE compartida (claves previamente compartidas)

Usuario de acceso
telefónico con
ID IKE: joe@ns.com Interfaz de salida ethernet1, 10.1.1.1/24
Contraseña XAuth: 1234 ethernet3, 1.1.1.1/24 Modo NAT
Zona Untrust
Zona Trust
Túneles VPN LAN web1

10.1.1.5
Perfil de usuario de ID IKE
compartida
Usuario de acceso Nombre de usuario:
telefónico con Ventas_remotas
ID IKE: mike@ns.com Grupo de usuario: V_R
Contraseña XAuth: 5678 ID simple: sales@ns.com
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Dirección
Address Name: web1

Zone: Trust
3. Usuarios
User Name: Ventas_remotas

Status: Enable
IKE Identity: sales@ns.com

Policy > Policy Elements > User Groups > Local > New: Escriba V_R en el
campo Group Name, realice la acción que se indica a continuación y después
haga clic en OK:
Seleccione Ventas_remotas y utilice el botón << para moverlo de la columna

User Name: Joe

Status: Enable
XAuth User: (seleccione)
Contraseña: 1234
Confirm Password: 1234
User Name: Mike

Status: Enable
XAuth User: (seleccione)
Password: 5678
Confirm Password: 5678
4. VPN
y haga clic en OK:
Gateway Name: sales_gateway

Security Level: Compatible (seleccione)
Remote Gateway Type: Dialup Group (seleccione), V_R
Preshared Key: abcd1234
> Advanced: Introduzca los siguientes datos, después haga clic en Return
Enable XAuth: (seleccione)

Local Authentication: (seleccione)
Allow Any: (seleccione)
VPN Name: Sales_VPN

Remote Gateway: Predefined: (seleccione) sales_gateway

IKE:

5. Ruta

6. Directiva
haga clic en OK:
Source Address:
Service: HTTP
Action: Tunnel
Tunnel VPN: Sales_VPN
CLI
1. Interfaces
2. Dirección
3. Usuarios
set user Ventas_remotas ike-id sales@ns.com share-limit 250
set user-group V_R user Ventas_remotas
set user Joe password 1234
set user Joe type xauth
set user Mike password 5678
set user Mike type xauth
4. VPN
set ike gateway sales_gateway dialup V_R aggressive outgoing-interface ethernet3
preshare abcd1234 sec-level compatible
set ike gateway sales_gateway xauth
set vpn sales_vpn gateway sales_gateway sec-level compatible
set vpn sales_vpn bind zone untrust-tun
5. Ruta
set route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
6. Directiva
set policy top from untrust to trust “Dial-Up VPN” web1 http tunnel vpn sales_vpn
save


En este ejemplo se muestra la configuración del usuario Joe.

Remote Party ID Type: IP Address
ID Type: IP Address; 1.1.1.1

6. Haga clic en My Identity: Click Pre-shared Key > Enter Key: Escriba
abcd1234, después haga clic en OK.
ID Type: (seleccione E-mail Address) y escriba sales@ns.com.
después en el símbolo MÁS situado a la izquierda de Authentication (Fase 1) y
de Key Exchange (Fase 2) para ampliar aún más la directiva.

Authentication Method: Pre-Shared Key; Extended Authentication

Hash Alg: SHA-1

Hash Alg: MD5

Encrypt Alg: DES
Hash Alg: SHA-1


Encrypt Alg: DES
Hash Alg: MD5
protocolos IPSec:

Hash Alg: SHA-1

Hash Alg: MD5

Encrypt Alg: DES
Hash Alg: SHA-1

Encrypt Alg: DES
Hash Alg: MD5

Capítulo 6
Protocolo de encapsulamiento de la
capa 2
Este capítulo proporciona una introducción al protocolo de encapsulamiento de la

capa (Layer 2 Tunneling Protocol, L2TP), su utilización en solitario y con soporte
IPSec, y algunos ejemplos de la configuración de L2TP y L2TP sobre IPSec. Incluye
las siguientes secciones:
“Introducción al L2TP” en esta página
“Encapsulado y desencapsulado de paquetes” en la página 214
“Encapsulado” en la página 215
“Desencapsulado” en la página 216
“Ajuste de los parámetros L2TP” en la página 217
“L2TP y L2TP sobre IPSec” en la página 219
“Configuración de L2TP” en la página 219
“Configuración de L2TP sobre IPSec” en la página 224
“L2TP sobre IPSec bidireccional” en la página 232
Introducción al L2TP
El protocolo L2TP proporciona a un usuario de acceso telefónico una forma de
realizar una conexión con un protocolo punto a punto virtual (PPP) a un servidor de
red L2TP (LNS), que puede ser un dispositivo de seguridad. L2TP envía tramas PPP
por un túnel entre un concentrador de acceso L2TP (LAC) y el LNS.
En origen, el protocolo L2TP se diseñó para que un LAC residente en un sitio ISP se
conectase por túnel a un LNS en el sitio de otro ISP o empresa. El túnel L2TP no
llega hasta al equipo del usuario de acceso telefónico, sino únicamente hasta el LAC
en el ISP local del usuario de acceso telefónico. (A veces, a esto se le llama
configuración L2TP obligatoria.)
Introducción al L2TP 211

Un cliente NetScreen-Remote sobre Windows 2000 o Windows NT, o un cliente

Windows 2000 por sí mismo, puede actuar como un LAC. El túnel L2TP puede
llegar directamente hasta el equipo del usuario de acceso telefónico,
proporcionando así un encapsulado de protocolos punto a punto. (A veces, a esta
solución se le llama configuración L2TP voluntaria.)
Figura 52: Túnel L2TP entre el cliente VPN (LAC) y el dispositivo de seguridad (LNS)
NetScreen-Remote o
Windows 2000 (LAC) Dispositivo de
Internet seguridad (LNS)
ISP
LAN
corporativa
Túnel L2TP
(reenvío de sesiones PPP
del LAC al LNS)
Debido a que el enlace PPP va desde el usuario de acceso telefónico a través de

Internet hasta el dispositivo de seguridad (LNS), es el dispositivo de seguridad y no
el ISP quien asigna al cliente su dirección IP, las direcciones de los servidores DNS y
WINS, y autentica al usuario, ya sea desde la base de datos local o desde un
servidor de autenticado externo (RADIUS, SecurID o LDAP).
De hecho, el cliente recibe dos direcciones IP, una para su conexión física al ISP,
y otra lógica procedente del LNS. Cuando el cliente se conecta a su ISP, por ejemplo
utilizando el protocolo PPP, el ISP realiza las asignaciones de IP y DNS, y autentica
al cliente. Esto permite a los usuarios conectarse a Internet con una dirección IP
pública, que se convierte en la dirección IP externa del túnel L2TP.
Figura 53: Asignaciones IP y DNS del ISP
En primer lugar, el ISP asigna ISP

al cliente una dirección IP
pública y las direcciones de los
servidores DNS.

DNS: 6.6.6.6, 7.7.7.7
Después, cuando el túnel L2TP reenvía las tramas PPP encapsuladas al dispositivo
de seguridad, éste asigna al cliente una dirección IP y los ajustes de DNS y WINS. La
dirección IP puede ser del conjunto de direcciones privadas no utilizadas en
Internet. Ésta se convierte en la dirección IP interna del túnel L2TP.
212 Introducción al L2TP

Capítulo 6: Protocolo de encapsulamiento de la capa 2
Figura 54: Asignaciones IP y DNS del LNS
En segundo lugar, el dispositivo de seguridad, actuando

como LNS, asigna al cliente una dirección IP privada
(lógica) y las direcciones de los servidores DNS y WINS.
Dispositivo de
Internet seguridad (LNS)
LAN corporativa
10.1.1.0/24

DNS: 10.1.1.10, 1.2.2.10 Conjunto de direcciones IP
WINS: 10.1.1.48, 10.1.1.49 10.10.1.1 – 10.10.1.254
NOTA: Las direcciones IP asignadas al cliente L2TP deben estar en una subred diferente
de la de las direcciones IP en la LAN corporativa.
La versión actual de ScreenOS proporciona el siguiente soporte al L2TP:
Túneles L2TP con origen en un host con Windows 2000
NOTA: De forma predeterminada, Windows 2000 realiza L2TP sobre IPSec. Para obligarlo
a utilizar sólo L2TP, debe dirigirse a la clave ProhibitIPSec en el registro y cambiar
0 (L2TP sobre IPSec) por 1 (sólo L2TP). (Antes de hacerlo, Juniper Networks
recomienda hacer una copia de seguridad del registro). Haga clic en Inicio >
Ejecutar: Escriba regedit. Haga doble clic en HKEY_LOCAL_MACHINE >
System > CurrentControlSet > Services > RasMan > Parameters. Haga doble
clic en ProhibitIPSec: Escriba 1 en el campo Value data, seleccione Hexadecimal
como base de numeración y después haga clic en OK. Reinicie. (Si no encuentra
esta entrada en el registro, consulte la documentación de Microsoft Windows para
obtener información sobre como crear una).
Combinación de L2TP e IPSec en modo de transporte (L2TP sobre IPSec)
Para NetScreen-Remote: L2TP sobre IPSec con negociaciones en modo

principal utilizando certificados, y en modo dinámico utilizando una clave
previamente compartida o certificados
Para Windows 2000: L2TP sobre IPSec, con negociaciones en modo

principal que utilizan certificados
Directiva de acceso telefónico saliente para túneles L2TP y L2TP sobre IPSec
(Una directiva de acceso telefónico saliente se puede emparejar con una
entrante para proporcionar un túnel bidirecciones).
Autenticación de usuario utilizando los protocolos PAP (Password

Authentication Protocol) y CHAP (Challenge Handshake Authentication
Protocol) desde la base de datos local o un servidor externo de autenticado
(RADIUS, SecurID, o LDAP).
Introducción al L2TP 213

NOTA: La base de datos local y los servidores RADIUS son compatibles con PAP y con
CHAP SecurID y los servidores LDAP sólo son compatibles con PAP.
Asignación de las direcciones IP de los usuarios, los servidores DNS (sistema de

nombres de dominio), y los servidores WINS (servicio de nombres de Internet
en Windows) desde la base de datos local o un servidor RADIUS
Túneles L2TP y L2TP sobre IPSec para el sistema raíz y los sistemas virtuales
NOTA: Para utilizar el protocolo L2TP, el dispositivo de seguridad debe operar en la capa
3, con interfaces de la zona de seguridad en modo NAT o de rutas. Cuando el
dispositivo de seguridad opera en la capa 2, con interfaces de la zona de seguridad
en modo transparente, no aparece información relacionada con el L2TP en el
WebUI y los comandos CLI relativos al L2TP provocan mensajes de error.
Encapsulado y desencapsulado de paquetes

El protocolo L2TP emplea el encapsulado de paquetes como forma de transportar
tramas PPP desde el LAC hasta el LNS. Antes de ver ejemplos específicos de
configuración del L2TP y el L2TP sobre IPSec, se muestra un resumen del
encapsulado y desencapsulado implicados en el proceso L2TP.
214 Encapsulado y desencapsulado de paquetes

Encapsulado
Cuando un usuario de acceso telefónico dentro de una red IP envía datos por un
túnel L2TP, el LAC encapsula el paquete IP dentro de una serie de tramas de la
capa 2, paquetes de la capa 3 y segmentos de la capa 4. Suponiendo que el usuario
de acceso telefónico se conecte al ISP local por un enlace PPP, el encapsulado será
como se muestra en la Figura 55 en la página 215.
Figura 55: Encapsulado de paquetes L2TP
DATOS
IP CARGA DE DATOS
PPP CARGA DE DATOS
L2TP CARGA DE DATOS
UDP CARGA DE DATOS
IP CARGA DE DATOS
PPP CARGA DE DATOS
1. Los datos se ubican en la carga de la trama IP.
2. El paquete IP se encapsula en una trama PPP.
3. La trama PPP se encapsula en una trama L2TP.
4. La trama L2TP se encapsula en un segmento UDP.
5. El segmento UDP se encapsula en un paquete IP.
6. El paquete IP se encapsula en una trama PPP para realizar la conexión física

entre el usuario de acceso telefónico y el ISP.
Encapsulado y desencapsulado de paquetes 215

Desencapsulado
Cuando el LAC inicia el enlace PPP hacia el ISP, el desencapsulado y reenvío del
contenido anidado será como se indica en la Figura 56 en la página 216.
Figura 56: Desencapsulado de paquetes L2TP
ISP PPP CARGA DE DATOS
IP CARGA DE DATOS
UDP CARGA DE DATOS
L2TP CARGA DE DATOS
LNS
PPP CARGA DE DATOS
IP CARGA DE DATOS
DATOS
1. El ISP finaliza el enlace PPP y asigna una dirección IP al equipo del usuario.
En la carga PPP hay un paquete IP.
2. El ISP quita el encabezado PPP y reenvía el paquete IP al LNS.
3. El LNS quita el encabezado IP.
En la carga IP hay un segmento UDP que especifica el puerto 1701, el número

del puerto reservado para L2TP.
4. El LNS quita el encabezado UDP.
En la carga UDP hay una trama L2TP.
5. El LNS procesa la trama L2TP, utilizando los datos tunnel ID y call ID del
encabezado L2TP para identificar el túnel L2TP concreto. Después, el LNS quita
el encabezado L2TP.
En la carga L2TP hay una trama PPP.
6. El LNS procesa la trama PPP y asigna una dirección lógica IP al equipo del
usuario.
En la carga PPP hay un paquete IP.
7. El LNS enruta el paquete IP hacia su último destino, donde el encabezado IP se

elimina y los datos se extraen del paquete IP.
216 Encapsulado y desencapsulado de paquetes

Ajuste de los parámetros L2TP

El LNS utiliza L2TP para proporcionar los ajustes PPP para un usuario de acceso
telefónico que habitualmente proviene de un ISP. Estos ajustes son los siguientes:
Dirección IP: el dispositivo de seguridad selecciona una dirección de un

conjunto de direcciones IP y la asigna al equipo del usuario de acceso
telefónico. El proceso de selección recorre cíclicamente el conjunto de
direcciones IP, esto es, en el grupo desde 10.10.1.1 hasta 10.10.1.3, las
direcciones se seleccionan siguiendo el ciclo que se indica:
10.10.1.1 – 10.10.1.2 – 10.10.1.3 – 10.10.1.1 – 10.10.1.2 …
Direcciones IP de los servidores DNS primario y secundario: el dispositivo de

seguridad proporciona estas direcciones para uso del equipo del usuario de
acceso telefónico.
Direcciones WINS de los servidores DNS primario y secundario: el dispositivo

de seguridad también proporciona estas direcciones para uso del equipo del
usuario de acceso telefónico.
El LNS también autentica al usuario mediante un nombre de usuario y una

contraseña. Se pueden introducir los datos del usuario en la base de datos local o en
un servidor externo de autenticado (RADIUS, SecurID, o LDAP).
NOTA: El servidor RADIUS o SecurID que se utiliza para autenticar a los usuarios L2TP
puede ser el mismo servidor utilizado para los usuarios de red, u otro diferente.
Además, puede especificar uno de los siguientes esquemas para la autenticación

PPP:
Challenge Handshake Authentication Protocol (CHAP), en el que el dispositivo

de seguridad envía un desafío (clave de cifrado) al usuario de acceso telefónico
después de que él o ella haya hecho una petición de enlace PPP, y el usuario
cifra su nombre de usuario y contraseña con la clave. La base de datos local y
los servidores RADIUS soportan CHAP.
Password Authentication Protocol (PAP), que envía la contraseña del usuario de

acceso telefónico en claro junto con la petición de enlace PPP. La base de datos
local y los servidores RADIUS, SecurID, y LDAP soportan PAP.
“ANY”, lo que significa que el dispositivo de seguridad negocia el CHAP y si éste

falla, entonces el PAP.
Puede aplicar a los usuarios o grupos de usuarios de acceso telefónico los

parámetros predeterminados L2TP que se configuran en la página básica de
configuración de L2TP (VPN > L2TP > Default Settings) o con el comando set l2tp
default. También puede aplicar los parámetros L2TP que se configuran
específicamente para los usuarios L2TP en la página de configuración de usuario
(Users > Users > Local > New) o con el comando set user cadena_nombre
remote-settings. Los ajustes específicos de usuario L2TP reemplazan a los ajustes
predeterminados L2TP.
Ajuste de los parámetros L2TP 217

Como se muestra en la Figura 57 en la página 218, se define un conjunto de

direcciones IP en un rango de 10.1.3.40 a 10.1.3.100. Especifique las direcciones IP
de los servidores DNS 1.1.1.2 (primario) y 1.1.1.3 (secundario). El dispositivo de
seguridad realiza la autenticación PPP mediante CHAP.
NOTA: Especifique el servidor de autenticación para cada túnel L2TP.
Figura 57: Conjunto de direcciones IP y ajustes predeterminados L2TP
RADIUS10. DNS 1
1.1.245 1.1.1.2
Nota: El conjunto de direcciones

L2TP debe pertenecer a una subred Internet DNS 2
distinta de la de la zona Trust. 1.1.1.3
ethernet1, Conjunto de direcciones IP ethernet3,

10.1.1.1/24 L2TP 10.1.3.40 – 10.1.3.100 1.1.1.1/24
WebUI
1. Conjunto de direcciones IP
Objects > IP Pools > New: Introduzca los siguientes datos y haga clic en OK:
IP Pool Name: Sutro

Start IP: 10.1.3.40
End IP: 10.1.3.100
2. Ajustes predeterminados de L2TP
VPNs > L2TP > Default Settings: Introduzca los siguientes datos y haga clic
en Apply:
IP Pool Name: Sutro

PPP Authentication: CHAP
DNS Primary Server IP: 1.1.1.2
DNS Secondary Server IP: 1.1.1.3
WINS Primary Server IP: 0.0.0.0
WINS Secondary Server IP: 0.0.0.0
CLI
set ippool sutro 10.1.3.40 10.1.3.100
set l2tp default ippool sutro
set l2tp default ppp-auth chap
set l2tp default dns1 1.1.1.2
save
218 Ajuste de los parámetros L2TP

L2TP y L2TP sobre IPSec

Aunque el usuario de acceso telefónico puede ser autenticado mediante CHAP o
PAP, el túnel L2TP no está encriptado, y por tanto no es un túnel VPN auténtico.
El objetivo del L2TP es simplemente permitir al administrador del dispositivo de
seguridad local la asignación de direcciones IP a un usuario de acceso telefónico
remoto. Por lo tanto, es posible introducir referencias a estas direcciones en las
directivas.
Para encriptar un túnel L2TP, es necesario aplicarle un esquema de encriptación.

Puesto que L2TP supone que la red entre el LAC y el LNS es IP, se puede utilizar
IPSec para proporcionar la encriptación. Esta combinación se llama L2TP sobre
IPSec. L2TP sobre IPSec requiere el establecimiento de un túnel L2TP y otro IPSec
ambos con los mismos extremos, y después enlazarlos en una directiva. L2TP sobre
IPSec requiere que el túnel IPSec esté en modo de transporte para que la dirección
del extremo del túnel quede despejado. (Para obtener información sobre el modo
de transporte y el modo de túnel, consulte “Modos” en la página 4.)
Se puede crear un túnel L2TP entre un dispositivo de seguridad y un host con

Windows 2000 si se cambian los ajustes del registro de Windows 2000. (Para ver
las instrucciones de como cambiar el registro, consulte la nota de la página 213).
Se puede crear un túnel L2TP sobre IPSec entre un dispositivo de seguridad y

cualquiera de los siguientes clientes VPN:
Un host que ejecute NetScreen-Remote en los sistemas operativos

Windows 2000 o Windows NT
Un host que ejecute Windows 2000 (sin NetScreen-Remote)
NOTA: Para proporcionar autenticación cuando se utiliza Windows 2000 sin

NetScreen-Remote, se deben utilizar certificados.
Configuración de L2TP
En este ejemplo, como se muestra en la Figura 58 en la página 220, se crea un
grupo de usuarios de acceso telefónico llamado “fs” (de “field-sales”) y se configura
un túnel L2TP llamado “sales_corp”, utilizando ethernet3 (Untrust zone) como
interfaz de salida de túnel L2TP. El dispositivo de seguridad aplica los siguientes
ajustes del túnel L2TP predeterminados al grupo de usuarios de acceso telefónico.
Los usuarios L2TP se autentican a través de la base de datos local.
La autenticación PPP utiliza CHAP.
El rango del conjunto de direcciones IP (denominado “global”) es de

10.10.2.100 a 10.10.2.180.
Los servidores DNS son 1.1.1.2 (primario) y 1.1.1.3 (secundario).
L2TP y L2TP sobre IPSec 219

NOTA: Una configuración con sólo L2TP no es segura. Se recomienda sólo para
depuración
El conjunto de direcciones IP de L2TP debe pertenecer a una subred distinta de la

de las direcciones de la red corporativa.
Figura 58: Configuración de L2TP

Grupo de usuarios
Auth/L2TP de acceso
telefónico: fs
Zona de acceso Conjunto de direcciones
telefónico DNS1: 1.1.1.2 IP: global 10.10.2.100 –
Adam 10.10.2.180 Red
DNS2: 1.1.1.3 corporativa
Zona Trust
Betty
Internet
Carol
Túnel L2TP:
sales_corp Interfaz de salida ethernet1,
ethernet3, 1.1.1.1/24 10.1.1.1/24
Clientes
NetScreen-Remote
Los clientes remotos L2TP usan el sistema operativo Windows 2000. Para obtener
información sobre la configuración del L2TP en los clientes remotos, consulte la
documentación de Windows 2000. A continuación se proporciona sólo la
configuración del dispositivo de seguridad al final del túnel L2TP.
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

220 L2TP y L2TP sobre IPSec

2. Usuarios L2TP
en OK:
User Name: Adam

Status: Enable
L2TP User: (seleccione)
User Password: AJbioJ15
Confirm Password: AJbioJ15
en OK:
User Name: Betty

Status: Enable
User Password: BviPsoJ1
Confirm Password: BviPsoJ1
en OK:
User Name: Carol

Status: Enable
User Password: Cs10kdD3
Confirm Password: Cs10kdD3
3. Grupo de usuarios L2TP
Objects > User > Local Groups> New: Escriba fs en el campo Group Name,
realice la acción que se indica a continuación y después haga clic en OK:
Seleccione Adam y utilice el botón << para trasladarlo de la columna

Seleccione Betty y utilice el botón << para trasladarla de la columna

Seleccione Carol y utilice el botón << para trasladarla de la columna


IP Pool Name: global

Start IP: 10.10.2.100
End IP: 10.10.2.180
en OK:


5. Túnel L2TP
VPNs > L2TP > Tunnel > New: Introduzca los siguientes datos y haga clic
en OK:
Name: sales_corp
Use Custom Settings: (seleccione)
Authentication Server: Local
Dialup Group: Local Dialup Group - fs
Peer IP: 0.0.0.0
Host Name (optional): Introduzca el nombre del equipo que actúa como LAC.
Secret (optional): Introduzca un secreto compartido entre el LAC y el LNS.
Keep Alive: 60
Peer IP: Debido a que el ISP del interlocutor le asigna dinámicamente una dirección
IP, ingresaría en el ejemplo anterior 0.0.0.0.
LAC: Para encontrar el nombre del equipo que ejecuta Windows 2000, haga lo
siguiente: Haga clic en Inicio > Configuración > Panel de Control > Sistema.
Aparece el cuadro de diálogo de propiedades del sistema. Haga clic en la ficha de
Identificación de red, y consulte la entrada Nombre completo del equipo.
Para añadir un secreto al LAC para autenticar el túnel L2TP, se debe modificar el
registro de Windows 2000 de la siguiente forma:
1. Haga clic en Inicio > Ejecutar y luego escriba regedit. Se abre el editor del
registro.
2. Haga clic en HKEY_LOCAL_MACHINE.
3. Haga clic con el botón secundario en SYSTEM y luego seleccione Buscar en el

menú emergente que aparece.
4. Escriba ms_l2tpminiport y luego haga clic en Buscar siguiente.
5. En el menú Edit, resalte la opción New y luego seleccione String Value.
6. Escriba Password.
7. Haga doble clic en Password. Aparece el cuadro de diálogo Edit String.
8. Escriba la contraseña en el campo Value data. Debe coincidir con la palabra

introducida en el campo L2TP Tunnel Configuration Secret en el dispositivo de
seguridad.
9. Reinicie el equipo Windows 2000.
Cuando se utiliza L2TP sobre IPSec, que es la opción predeterminada de

Windows 2000, no es necesaria la autenticación del túnel; todos los mensajes
L2TP son encriptados y autenticados por IPSec.
Keep Alive: El valor Keep Alive (mantenimiento de conexión) es el número de

segundos de inactividad antes de que el dispositivo de seguridad envíe una señal
Hello L2TP al LAC.

6. Ruta
Network > Routing > Routing Entries > New: Introduzca los siguientes datos
y haga clic en OK:

7. Directiva
haga clic en OK:
Source Address:
NAT: Off
Service: ANY
Action: Tunnel
Tunnel L2TP: sales_corp
CLI
1. Usuarios de acceso telefónico
set user adam type l2tp
set user adam password AJbioJ15
unset user adam type auth
set user betty type l2tp
set user betty password BviPsoJ1
unset user betty type auth
set user carol type l2tp
set user carol password Cs10kdD3
unset user carol type auth
NOTA: Definir una contraseña para un usuario le clasifica automáticamente como un

usuario autenticado. Por lo tanto, para definir el tipo de usuario como L2TP en
sentido estricto, se debe desactivar el tipo de usuario autenticado.
2. Grupo de usuarios L2TP

set user-group fs location local
set user-group fs user adam
set user-group fs user betty
set user-group fs user carol
set ippool global 10.10.2.100 10.10.2.180
set l2tp default ippool global
set l2tp default auth server Local
4. Túnel L2TP
set l2tp sales_corp outgoing-interface ethernet3
set l2tp sales_corp auth server Local user-group fs

5. Ruta
6. Directiva
set policy top from untrust to trust “Dial-Up VPN” any any tunnel l2tp sales_corp
save
Configuración de L2TP sobre IPSec

Este ejemplo utiliza el túnel L2TP creado en el ejemplo anterior (“Configuración de
L2TP” en la página 219). Además, se superpone un túnel IPSec al túnel L2TP para
proporcionar encriptación. El túnel IPSec negocia la fase 1 en modo agresivo
utilizando un certificado RSA previamente cargado, cifrado 3DES y autenticación
SHA-1. La autoridad de certificación (CA) será Verisign. (Para obtener información
sobre la obtención y carga de certificados, consulte el Capítulo 2, “Criptografía de
claves públicas.”). El túnel IPSec está en modo de transporte.
La zona Trust predefinida y la zona de acceso telefónico definida por el usuario se

encuentran en el dominio de enrutamiento trust-vr. Las interfaces para las zonas de
acceso telefónico y Trust son ethernet2 (1.3.3.1/24) y ethernet1 (10.1.1.1/24),
respectivamente. La zona Trust está en modo NAT.
Los usuarios de acceso telefónico Adam, Betty y Carol utilizan clientes

NetScreen-Remote sobre un sistema operativo Windows 2000. La configuración de
NetScreen-Remote para el usuario de acceso telefónico Adam también se incluye en
lo que sigue. (La configuración del NetScreen-Remote para los otros dos usuarios de
acceso telefónico es la misma que para Adam.)
NOTA: Para configurar un túnel L2TP sobre IPSec para Windows 2000 (sin
NetScreen-Remote), las negociaciones de la fase 1 deben ser en modo principal y
el tipo de identificación IKE debe ser ASN1-DN.
Figura 59: Configuración de L2TP sobre IPSec

Grupo de usuarios IKE-L2TP
de acceso telefónico: fs
Zona de acceso Conjunto de direcciones
telefónico DNS1: 1.1.1.2 IP: global 10.10.2.100 –
Adam Red
10.10.2.180
DNS2: 1.1.1.3 corporativa
Zona Trust
Betty
Internet
Carol
Túnel L2TP: sales_corp
Túnel VPN: from_sales Interfaz de salida ethernet1,
ethernet2, 1.1.1.1/24 10.1.1.1/24
Clientes
NetScreen-Remote

WebUI
1. Zona definida por el usuario
Zone Name: Dialup

Zone Type: Layer 3 (seleccione)
TCP/IP Reassembly for ALG: (anule la selección)
NOTA: La zona Trust está preconfigurada. No es necesario crearla.
2. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Dialup

3. Usuarios IKE/L2TP
en OK:
User Name: Adam

Status: Enable
IKE Identity: ajackson@abc.com
User Password: AJbioJ15
Confirm Password: AJbioJ15
NOTA: La ID IKE debe ser la misma que la que envía el cliente NetScreen-Remote, que es
la dirección de correo electrónico que aparece en el certificado que el cliente
utiliza para la autenticación.

en OK:
User Name: Betty

Status: Enable
IKE Identity: bdavis@abc.com
User Password: BviPsoJ1
Confirm Password: BviPsoJ1
en OK:
User Name: Carol

Status: Enable
IKE Identity: cburnet@abc.com
User Password: Cs10kdD3
Confirm Password: Cs10kdD3
4. Grupo de usuarios IKE/L2TP
Objects > Users > Local Groups > New: Escriba fs en el campo Group Name,
realice la acción que se indica a continuación y después haga clic en OK:
Seleccione Adam y utilice el botón << para trasladarlo de la columna

Seleccione Betty y utilice el botón << para trasladarla de la columna

Seleccione Carol y utilice el botón << para trasladarla de la columna


Start IP: 10.10.2.100
End IP: 10.10.2.180
en Apply:


7. Túnel L2TP
en OK:
Name: sales_corp
Dialup Group: (seleccione) Local Dialup Group - fs
Authentication Server: Local
Peer IP: 0.0.0.0
Host Name (optional): Si desea restringir el túnel L2TP a un host específico,

introduzca el nombre del equipo que actúa como LAC.
Secret (optional): Introduzca un secreto compartido entre el LAC y el LNS.
Keep Alive: 60
LAC: Para encontrar el nombre del equipo que ejecuta Windows 2000, haga lo
siguiente: Haga clic en Inicio > Configuración > Panel de Control > Sistema.
Aparece el cuadro de diálogo de propiedades del sistema. Haga clic en la ficha de
Identificación de red, y consulte la entrada Nombre completo del equipo.
Secret: Para añadir un secreto al LAC para autenticar el túnel L2TP, se debe
modificar el registro de Windows 2000 de la siguiente forma:
1. Haga clic en Inicio > Ejecutar y luego escriba regedit. Se abre el editor del
registro.
2. Haga clic en HKEY_LOCAL_MACHINE.
3. Haga clic con el botón secundario en SYSTEM y luego seleccione Buscar en el

menú emergente que aparece.
4. Escriba ms_l2tpminiport y luego haga clic en Buscar siguiente.
5. En el menú Edit, resalte la opción New y luego seleccione String Value.
6. Escriba Password.
7. Haga doble clic en Password. Aparece el cuadro de diálogo Edit String.
8. Escriba la contraseña en el campo Value data. Debe coincidir con la palabra

introducida en el campo L2TP Tunnel Configuration Secret en el dispositivo de
seguridad.
9. Reinicie el equipo Windows 2000.
Cuando se utiliza L2TP sobre IPSec, que es la opción predeterminada de

Windows 2000, no es necesaria la autenticación del túnel; todos los mensajes
L2TP son encriptados y autenticados por IPSec.
Keep Alive: El valor Keep Alive (mantenimiento de conexión) es el número de

segundos de inactividad antes de que el dispositivo de seguridad envíe una señal
Hello L2TP al LAC.

NOTA: El nombre del host y los ajustes del secreto pueden pasarse por alto. Se
recomienda que sólo los usuarios avanzados utilicen estos ajustes.
8. Túnel VPN
y haga clic en OK:
Gateway Name: field

Dialup User Group: (seleccione), Group: fs

en Return para regresar a la página de configuración básica de Gateway:
Security Level: User Defined: Custom

Phase 1 Proposal: rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
NOTA: Windows 2000 (sin NetScreen-Remote) sólo admite negociaciones en modo

principal.
Name: from_sales
Remote Gateway: Predefined: field

IKE:

Transport Mode: (seleccione)
9. Directiva
Policies > (From: Dialup, To: Trust) New: Introduzca los siguientes datos y haga
clic en OK:
Source Address:
Service: ANY
Action: Tunnel
Tunnel VPN: from_sales
L2TP: sales_corp

CLI
1. Zona definida por el usuario
set zone name dialup
set zone dialup vrouter trust-vr
set zone dialup block
2. Interfaces
set interface ethernet2 zone dialup
3. Usuarios L2TP/IKE
set user adam type ike l2tp
set user adam password AJbioJ15
unset user adam type auth
set user adam ike-id u-fqdn ajackson@abc.com
set user betty type ike l2tp
set user betty password BviPsoJ1
unset user betty type auth
set user betty ike-id u-fqdn bdavis@abc.com
set user carol type ike l2tp
set user carol password Cs10kdD3
unset user carol type auth
set user carol ike-id u-fqdn cburnet@abc.com
4. Grupo de usuarios IKE/L2TP
set user-group fs location Local
set user-group fs user adam
set user-group fs user betty
set user-group fs user carol
set ippool global 10.10.2.100 10.10.2.180
set l2tp default ippool global
7. Túnel L2TP
set l2tp sales_corp outgoing-interface ethernet2
set l2tp sales_corp auth server Local user-group fs
8. Túnel VPN
set ike gateway field dialup fs aggressive outgoing-interface ethernet2 proposal
rsa-g2-3des-sha
set ike gateway field cert peer-ca1
set ike gateway field cert peer-cert-type x509-sig
set vpn from_sales gateway field transport sec-level compatible

NOTA: Windows 2000 (sin NetScreen-Remote) sólo admite negociaciones en modo

principal.

9. Directiva
set policy top from dialup to trust “Dial-Up VPN” any any tunnel vpn from_sales
l2tp sales_corp
save
Editor de directivas de seguridad de NetScreen-Remote (Adam)

Para configurar los túneles L2TP sobre IPSec para los clientes NetScreen-Remote de
Betty y Carol, siga el procedimiento que aquí se describe para Adam.
2. Haga clic en Add a new connection y escriba AJ junto al icono de nueva


IP Address: 1.3.3.1
Protocol: UDP
Port: L2TP
Connect using Secure Gateway Tunnel: (anule la selección)
4. Haga clic en el signo MÁS situado a la izquierda del icono de AJ para ampliar la
directiva de la conexión.
5. Haga clic en My Identity y configure lo siguiente:
Select the certificate with the email address specified as the user’s IKE ID on
the security device from the Select Certificate dropdown list:
ID Type: Dirección de correo electrónico

Port: L2TP

6. Haga clic en el icono Security Policy y seleccione Aggressive Mode.
7. Haga clic en el símbolo MÁS situado a la izquierda del icono Security Policy y,
a continuación, en el símbolo MÁS situado a la izquierda de Authentication
(Phase 1) y de Key Exchange (Phase 2) para ampliar más aún la directiva.



(o bien)
Hash Alg: SHA-1
Key Group: Grupo de Diffie-Hellman 2
protocolos IPSec:

Hash Alg: SHA-1
Encapsulation: Transport

Hash Alg: MD5

Encrypt Alg: DES
Hash Alg: SHA-1

Encrypt Alg: DES
Hash Alg: MD5
14. También es necesario configurar la conexión de red para Windows 2000

utilizando el asistente para conexión de red.
NOTA: Cuando se configura el asistente para conexión de red, se debe introducir un

nombre de host destino o una dirección IP. Introduzca 1.3.3.1. Posteriormente,
cuando inicie una conexión y el sistema le solicite un nombre de usuario y una
contraseña, introduzca adam, AJbioJ15. Para más información, consulte la
documentación de Microsoft Windows 2000.

L2TP sobre IPSec bidireccional

En este ejemplo, ethernet1 (10.1.1.1/24) es la interfaz de la zona Trust y se
encuentra en modo NAT, mientras que ethernet3 (1.1.1.1/24) es la interfaz de la
zona Untrust. Creará túneles L2TP sobre IPSec entre un usuario de acceso
telefónico NetScreen-Remote y una LAN corporativa. El usuario remoto trabaja con
una aplicación X-Windows, lo que requiere establecer directivas bidireccionales.
Configurará las directivas entrantes y salientes para el túnel VPN de acceso

telefónico AutoKey IKE denominado VPN_dial para el usuario IKE dialup-j con la ID
de IKE jf@ns.com. y el túnel L2TP denominado tun1. El usuario IKE inicia una
conexión IPSec al dispositivo de seguridad desde la zona Untrust para acceder a los
servidores corporativos de la zona Trust. En este punto, solamente se permite la
comunicación L2TP. Después de la negociación L2TP/PPP, se establece el túnel
L2TP. Con las directivas bidireccionales configuradas, el tráfico puede iniciarse
desde cualquier extremo del túnel.
El usuario de acceso telefónico dialup-j utiliza un cliente NetScreen-Remote con el

sistema operativo Windows 2000. La configuración de NetScreen-Remote para el
usuario de acceso telefónico dialup-j aparece después de la Figura 60 en la
página 232.
Figura 60: L2TP sobre IPSec bidireccional

ethernet3 ethernet3
1.1.1.1/24 10.1.1.1/24
Zona de acceso telefónico
Zona Trust
Internet
LAN
Cliente de NetScreen-Remote Túnel L2TP sobre Enrutador Servidor UNIX

ejecutando X-Windows Server IPSec externo1.1.1.250
NOTA: Para configurar un túnel L2TP sobre IPSec para Windows 2000 (sin
NetScreen-Remote), las negociaciones de la fase 1 deben ser en modo principal y
el tipo de identificación IKE debe ser ASN1-DN.
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT

haga clic en OK:
Zone Name: Untrust

2. Dirección
Address Name: trust_net

Zone: Trust
3. Usuario L2TP/IKE
en OK:
User Name: dialup-j

Status: Enable
IKE Identity: jf@ns.com
Authentication User: (seleccione)
User Password: abc123
Confirm Password: abc123
NOTA: La ID IKE debe ser la misma que la que envía el cliente NetScreen-Remote, que es
la dirección de correo electrónico que aparece en el certificado que el cliente
utiliza para la autenticación.
4. L2TP
en OK:
Name: tun1
Use Default Settings: (seleccione)
Secret: netscreen
Keepalive: 60
5. VPN
y haga clic en OK:

Security Level: (select), Standard
Remote Gateway Type: Dialup User; (seleccione), dialup-j
Preshared Key: n3TsCr33N
Outgoing Interface: (select), ethernet3

> Advanced: Introduzca los siguientes datos y haga clic en Return para
regresar a la página de configuración básica de la puerta de enlace AutoKey
IKE:

Enable NAT-Traversal: (seleccione)
UDP Checksum: (seleccione)
Keepalive Frequency: 5
VPN Name: VPN_dial

Remote Gateway: Predefined: (seleccione), dialup1
> Advanced: Introduzca los siguientes datos y haga clic en Return para
regresar a la página de configuración básica de AutoKey IKE:
Security Level: Standard (seleccione)

Transport Mode (sólo para L2TP sobre IPSec): (seleccione)
6. Ruta
y haga clic en OK:

7. Directivas
haga clic en OK:
Source Address:
Service: ANY
Action: Tunnel
Tunnel VPN: VPN_dial
L2TP: (seleccione) tun1
Policies > (From: Trust, To: Untrust) > New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Service: ANY
Action: Tunnel
Tunnel VPN: VPN_dial
L2TP: tun1

CLI
1. Interfaces
2. Dirección
set address trust trust_net 10.1.1.0/24
3. Usuario L2TP/IKE
set user dialup-j ike-id u-fqdn jf@ns.com
set user dialup-j type auth ike l2tp
set user dialup-j password abc123
4. L2TP
set L2TP tun1 outgoing-interface ethernet3 secret "netscreen" keepalive 60
5. VPN
set ike gateway dialup1 dialup "dialup-j" aggressive outgoing-interface ethernet3
preshare n3TsCr33N sec-level standard
set ike gateway dialup1 nat-traversal udp-checksum
set ike gateway dialup1 nat-traversal keepalive-frequency 5
set vpn VPN_dial gateway dialup1 no-replay transport idletime 0 sec-level standard
6. Ruta
7. Directivas
set policy from untrust to trust “Dial-Up VPN” trust_net any tunnel vpn VPN_dial
tun1
set policy from trust to untrust trust_net “Dial-Up VPN” any tunnel vpn VPN_dial
l2tp tun1
save
Editor de directivas de seguridad de NetScreen-Remote (para el usuario “dialup-j”)

2. Haga clic en Add a new connection y escriba dialup-j junto al icono de nueva

IP Address: 1.1.1.1
Protocol: UDP
Port: L2TP
Connect using Secure Gateway Tunnel: (anule la selección)
4. Haga clic en el signo MÁS situado a la izquierda del icono de dialup-j para

5. Haga clic en My Identity y configure lo siguiente:
En la lista desplegable Select Certificate, seleccione el certificado con la

dirección de correo especificada como la ID IKE del usuario en el dispositivo de
seguridad.
ID Type: Dirección de correo electrónico

Port: L2TP

6. Haga clic en el icono Security Policy y seleccione Aggressive Mode.
7. Haga clic en el símbolo MÁS situado a la izquierda del icono Security Policy y,
a continuación, en el símbolo MÁS situado a la izquierda de Authentication
(Phase 1) y de Key Exchange (Phase 2) para ampliar más aún la directiva.


(o bien)
Hash Alg: SHA-1
Key Group: Grupo de Diffie-Hellman 2
NOTA: Si la opción Perfect Forwarding Secrecy (PFS) está activada en el dispositivo de

seguridad (grupo DF 1, 2 ó 5), también debe estar activada para el cliente VPN en
NetScreen-Remote.
protocolos IPSec:

Hash Alg: SHA-1

Hash Alg: MD5

Encrypt Alg: DES
Hash Alg: SHA-1


Encrypt Alg: DES
Hash Alg: MD5
También es necesario configurar la conexión de red para Windows 2000 utilizando

el asistente para conexión de red.
NOTA: Cuando se configura el asistente para conexión de red, se debe introducir un

nombre de host destino o una dirección IP. Introduzca 1.1.1.1. Posteriormente,
cuando inicie la conexión y se le solicite el nombre de usuario y la contraseña,
introduzca dialup-j, abc123. Para más información, consulte la documentación de
Microsoft Windows 2000.


Capítulo 7
Funciones avanzadas de redes privadas
virtuales
Este capítulo abarca los siguientes usos de la tecnología de redes privadas virtuales
(VPN):
“NAT-Traversal” en la página 240
“Sondeos de NAT” en la página 241
“Atravesar un dispositivo NAT” en la página 243
“Suma de comprobación de UDP” en la página 245
“Paquetes de mantenimiento de conexión” en la página 246
“Simetría iniciador/respondedor” en la página 246
“Habilitación de NAT-Traversal” en la página 248
“Uso de identificaciones de IKE con NAT-Traversal” en la página 249
“Supervisión de VPN” en la página 250
“Opciones de reencriptación y optimización” en la página 251
“Interfaz de origen y dirección de destino” en la página 252
“Consideraciones sobre directivas” en la página 253
“Configuración de la función de supervisión de VPN” en la página 254
“Objetos y capturas SNMP para la supervisión de VPN” en la página 262
“Múltiples túneles por interfaz de túnel” en la página 263
“Asignación de rutas a túneles” en la página 264
“Direcciones de interlocutores remotos” en la página 266
“Entradas de tabla manuales y automáticas” en la página 267
239
“Puertas de enlace VPN redundantes” en la página 301
“Grupos VPN” en la página 302
“Mecanismos de supervisión” en la página 303
“Comprobación de indicador TCP SYN” en la página 307
“Creación de VPN adosadas” en la página 314
“Creación de VPN radiales” en la página 321
NAT-Traversal
Las normas de Internet NAT (traducción de direcciones de red, Network Address
Translation ) y NAPT (traducción de puertos de direcciones de red, Network Address
Port Translation) permiten que una red de área local (LAN) utilice un grupo de
direcciones IP para el tráfico interno y un segundo grupo de direcciones para el
tráfico externo. Los dispositivos NAT generan estas direcciones externas utilizando
conjuntos predeterminados de direcciones IP.
Cuando se configura un túnel IPSec, la presencia de un dispositivo NAT en la ruta de

datos no afecta a las negociaciones IKE de fase 1 y fase 2, que siempre encapsulan
paquetes IKE dentro de segmentos de protocolo de datagrama de usuarios UDP
(User Datagram Protocol). Sin embargo, si se aplica NAT a los paquetes IPSec una
vez finalizadas las negociaciones de fase 2, el túnel fallará. Una de las muchas
razones por las que NAT provoca el fallo de IPSec es que en el protocolo de
seguridad encapsulada ESP (Encapsulating Security Protocol), los dispositivos NAT
no pueden distinguir la ubicación del encabezado de capa 4 para la traducción del
puerto (porque está encriptado). En el protocolo de encabezado de la autenticación
(AH, o “Authentication Header”), los dispositivos NAT no pueden modificar el
número de puerto, pero falla la comprobación de autenticación, que incluye el
paquete IPSec completo.
NOTA: Para obtener una lista de las incompatibilidades IPSec/NAT, consulte el documento
draft-ietf-ipsec-nat-regts-00.txt de Bernard Aboba.
Para solucionar estos problemas, los dispositivos de seguridad y el cliente

NetScreen-Remote (versión 6.0 o posterior) pueden aplicar una función
NAT-Traversal (NAT-T). NAT-T agrega una capa de encapsulación UDP a los paquetes
IPSec si detecta al menos un dispositivo NAT en la ruta de datos durante los
intercambios de fase 1, según lo establecido en las especificaciones IETF
draft-ietf-ipsec-nat-t-ike-00.txt y draft-ietf-ipsec-udp-encaps-00.txt, así como en
versiones más recientes de estas especificaciones.
NOTA: NetScreen-Remote 6 y NetScreen-Remote 7 son compatibles con NAT-T según las

especificaciones draft-ietf-ipsec-nat-t-ike-00.txt y draft-ietf-ipsec-udp-encaps-00.txt.
NetScreen-Remote 8.2 es compatible con las especificaciones 02.
240 NAT-Traversal
Capítulo 7: Funciones avanzadas de redes privadas virtuales
Los dispositivos NAT pueden crear otro problema si también están preparados para
IKE/IPSec e intentan procesar paquetes con el número de puerto IKE 500 o con los
números de protocolo 50 (para ESP) y 51 (para AH). Para evitar ese procesamiento
intermedio de paquetes IKE, la versión 2 de las especificaciones IETF previamente
mencionadas propone el desplazamiento (o “flotación”) de los números de puertos
UDP 500 a 4500 para IKE. Para evitar el procesamiento intermedio de paquetes
IPSec, ambas especificaciones 0 y 2 insertan un encabezado UDP entre el
encabezado IP externo y el encabezado ESP o AH, cambiando así el valor 50 o 51
del campo “Protocol” (para ESP o AH, respectivamente) a 17 (para UDP). Además,
el encabezado UDP insertado también utiliza el puerto 4500. La versión actual de
ScreenOS es compatible con NAT-T de acuerdo con las especificaciones
draft-ietf-ipsec-nat-t-ike-02.txt y draft-ietf-ipsec-udp-encaps-02.txt, así como con la
versión 0 de estas especificaciones.
NOTA: NetScreen no admite NAT-T para los túneles de clave manual ni para el tráfico
IPSec usando AH. ScreenOS sólo admite NAT-T para túneles AutoKey IKE con ESP.
Sondeos de NAT
Para comprobar si ambos extremos del túnel VPN admiten NAT-T, ScreenOS envía
dos hashes MD-5 en la carga de datos de ID del fabricante en los dos primeros
intercambios de las negociaciones de fase 1, un hash para el título de la
especificación 0 y otro para el título de la especificación 2:
“4485152d 18b6bbcd 0be8a846 9579ddcc”, que es una transformación

(“hash”) MD-5 de “draft-ietf-ipsec-nat-t-ike-00”
“90cb8091 3ebb696e 086381b5 ec427b1f”, que es una transformación

(“hash”) MD-5 de “draft-ietf-ipsec-nat-t-ike-02”
Ambos interlocutores deben enviar y recibir al menos uno de estos valores en la ID

de carga de datos del fabricante para que el sondeo NAT-T continúe. Si envían
hashes correspondientes a ambas especificaciones, ScreenOS utiliza la
implementación NAT-T correspondiente a la especificación 2.
Si los dispositivos de cada punto terminal admiten NAT-T, se envían mutuamente

cargas de datos NAT de descubrimiento (NAT-D) durante los intercambios tercero y
cuarto de la fase 1 (modo principal) o durante los intercambios segundo y tercero
(modo dinámico). La carga de datos de descubrimiento NAT (“Nat-Discovery” o
NAT-D) es un tipo de carga de datos IKE para NAT-T. El número de tipo de carga de
datos NAT-D es 0130. Para obtener una lista de otros tipos de carga de datos IKE,
consulte “Paquetes IKE” en la página 13.
NOTA: ScreenOS puede manejar varias cargas de datos de descubrimiento NAT (NAT-D)
en una negociación IKE.
NAT-Traversal 241
Las cargas de datos de NAT-D contienen un hash negociado de la siguiente

información:
Hash del destino NAT-D:
Cookie del iniciador (CKY-I)
Cookie del respondedor (CKY-R)
Dirección IP del interlocutor IKE remoto (de destino)
Número del puerto de destino
Hash del origen NAT-D (uno o varios):
Cookie del iniciador (CKY-I)
Cookie del respondedor (CKY-R)
Dirección IP del interlocutor IKE local (de origen)
Número del puerto de origen
NOTA: NAT-T admite múltiples hashes de origen NAT-D para dispositivos equipados con
múltiples interfaces e implementaciones que no especifiquen una interfaz
saliente.
Cuando cada interlocutor compara los hashes que recibe con los que envía, puede
reconocer si entre ellos se ha producido una traducción de direcciones. La
identificación de los paquetes modificados implica la de la ubicación del dispositivo
NAT:
Si coincide con entonces

el hash de destino del al menos uno de los hashes de no se ha producido ninguna
interlocutor local origen del interlocutor remoto traducción de direcciones.
al menos uno de los hashes el hash de destino del no se ha producido ninguna
de origen del interlocutor interlocutor remoto traducción de direcciones.
local
Si no coincide con entonces

el hash de destino del al menos uno de los hashes de no se ha producido ninguna
interlocutor local origen del interlocutor remoto traducción de direcciones
al menos uno de los hashes el hash de destino del no se ha producido ninguna
de origen del interlocutor interlocutor remoto traducción de direcciones
local
242 NAT-Traversal
Conocer la ubicación del dispositivo NAT es importante porque los paquetes de

mantenimiento de conexión IKE deben iniciarse desde el interlocutor situado
detrás del dispositivo NAT. Consulte “Paquetes de mantenimiento de conexión” en
la página 246.
Si ambos interlocutores cumplen la especificación IETF 2, también desplazan

(“flotan”) el número de puerto IKE de 500 a 4500 tan pronto como detectan un
dispositivo NAT entre ellos durante las negociaciones de la fase 1. En el modo
principal, los números de puertos flotan a 4500 en el quinto y el sexto intercambios
de la fase 1, y posteriormente durante todos los intercambios de la fase 2. En modo
dinámico, el número de puerto se desplaza al 4500 en el tercer (y último)
intercambio de la fase 1, y luego durante todos los intercambios de la fase 2. Los
interlocutores también utilizan 4500 como número de puerto UDP para todo el
tráfico IPSec subsiguiente.
Atravesar un dispositivo NAT

En la Figura 61, un dispositivo NAT situado en el perímetro de la LAN de un hotel
recibe un paquete de un cliente de acceso telefónico a VPN con la dirección
IP 2.1.1.5, asignada por el hotel. Para todo el tráfico saliente, el dispositivo NAT
sustituye la dirección IP de origen en el encabezado externo por la nueva dirección
2.2.2.2. Durante las negociaciones de la fase 1, el cliente VPN y el dispositivo de
seguridad detectan que los dos participantes VPN admiten NAT-T, que hay un
dispositivo NAT en la ruta de datos y que se encuentra delante del cliente VPN.
Figura 61: NAT-Traversal

Empresa
Hotel
Dispositivo NAT
Internet
Túnel VPN
Cliente VPN telefónico
IP de origen 200.1.1.1 -> 210.2.2.2
Si se encapsulan los paquetes IPSec dentro de paquetes UDP (cosa que harán tanto
el cliente VPN como el dispositivo de seguridad) se resuelve el problema de fallo en
la comprobación de autenticación. El dispositivo NAT los procesa como paquetes
UDP, cambiando el puerto de origen en el encabezado UDP sin modificar el SPI en
el encabezado AH o ESP. Los participantes VPN retiran la capa UDP y procesan los
paquetes IPSec, que no tendrán problemas en la comprobación de autenticación,
ya que los contenidos autenticados no habrán cambiado.
NAT-Traversal 243
Puede presentarse otro problema si el dispositivo NAT está preparado para

IKE/IPSec. Un dispositivo NAT preparado para IKE/IPSec podría intentar procesar el
tráfico IKE/IPSec en lugar de reenviarlo. Para impedir tal procesamiento intermedio,
NAT-T (v2) cambia los números de puertos UDP de origen y de destino para IKE de
500 a 4500. NAT-T también inserta un marcador no-ESP en el encabezado UDP
justo antes de la carga de datos. Para el tráfico IPSec, NAT-T (v0 y v2) inserta un
encabezado UDP entre el encabezado IP externo y el encabezado ESP. El paquete
UDP también utiliza 4500 como número de ambos puertos, el de origen y el de
destino.
Según lo mencionado, NAT-T (v2) agrega un marcador no-ESP entre el encabezado y

la carga de datos del segmento del UDP que encapsula el paquete ISAKMP. El
marcador no ESP consta de 4 bytes a cero (0000) y se agrega al segmento UDP para
distinguir un paquete ISAKMP encapsulado de un paquete encapsulado ESP, que no
tiene tal marcador. Sin el marcador no ESP, el receptor no sabría si el paquete
encapsulado era un paquete ISAKMP o un paquete ESP, porque el encabezado UDP
utiliza 4500 para ambos tipos. Utilizando este marcador se indica el tipo correcto de
paquete encapsulado para que el receptor pueda desmultiplexarlo correctamente.
Como se muestra en la Figura 62 en la página 244, después de detectar un

dispositivo NAT en la ruta de datos, los números de los puertos de origen y de
destino en el encabezado UDP de un paquete IKE cambian de 500 a 4500.
Asimismo, los puntos terminales del túnel VPN insertan un marcador no ESP entre
el encabezado UDP y la carga de datos para distinguir el paquete ISAKMP
encapsulado de un paquete ESP. El receptor puede utilizar este marcador para
distinguir el paquete ISAKMP encapsulado de un paquete ESP y para
desmultiplexarlo correctamente.
Figura 62: Paquete IKE (para las fases 1 y 2)
Encabezado Encabezado Encabezado Carga de datos

IP UDP ISAKMP
Nota: ISAKMP es el formato de paquetes utilizado por IKE.
Segmento UDP
Carga de datos
Segmento UDP después de detectar un dispositivo NAT
Marcador no ESP (0000)
Carga de datos
244 NAT-Traversal
La Figura 63 muestra cómo después de detectar un dispositivo NAT en la ruta de

datos, los puntos terminales del túnel VPN insertan un encabezado UDP adicional
entre el encabezado IP externo y el encabezado ESP de un paquete IPSec. Dado que
no hay ningún marcador no ESP, el receptor puede distinguir el paquete ESP
encapsulado de un paquete ISAKMP y desmultiplexar el paquete ESP
correctamente.
Figura 63: Paquete IPSec ESP antes y después de la detección de NAT

Paquete IPSec ESP antes de detectar un dispositivo NAT
Paquete IPSec
Paquete original
Enviado por la puerta Enviado por el host iniciador
Encabezado Encabezado Encabezado Encabezado Carga de datos
IP2 ESP IP1 TCP

Paquete IPSec ESP después de detectar un dispositivo NAT

Paquete IPSec
Enviado por la puerta Paquete original Callouts
de enlace IKE Enviado por el host iniciador
Encabezado Encabezado Encabezado Encabezado Encabezado
Carga de datos
IP2 UDP ESP IP1 TCP

Encabezado UDP
Carga de datos
Suma de comprobación de UDP

Todos los paquetes UDP contienen una suma de comprobación de UDP, un valor
calculado que garantiza que los paquetes UDP no tienen errores de transmisión. Los
dispositivos de seguridad no necesitan utilizar la suma de comprobación de UDP
para NAT-T, de modo que la WebUI y la CLI presentan la suma de comprobación
como ajuste opcional. Aún así, ciertos dispositivos NAT precisan de suma de
comprobación, por lo que puede ser necesario habilitar o inhabilitar esta opción. De
forma predeterminada, al habilitar NAT-T se incluye la suma de comprobación UDP.
NAT-Traversal 245
WebUI
VPN > AutoKey Advanced > Gateway > New:
Introduzca los parámetros necesarios para la nueva puerta de enlace del túnel,
según se describe en “Redes privadas virtuales de punto a punto” en la
página 81 o en “Redes privadas virtuales de acceso telefónico” en la
página 163; introduzca los siguientes datos y, finalmente, haga clic en OK:

enlace:

UDP Checksum: Enable
CLI
set ike gateway nombre nat-traversal udp-checksum
unset ike gateway nombre nat-traversal udp-checksum
Paquetes de mantenimiento de conexión

Cuando un dispositivo NAT asigna una dirección IP a un host, el dispositivo NAT
determina el intervalo de tiempo que la nueva dirección será válida si no hay
tráfico. Por ejemplo, un dispositivo NAT podría invalidar cualquier dirección IP
generada que no se utilice durante 20 segundos. Por eso, suele ser necesario que los
participantes IPSec envíen periódicamente paquetes keepalive de mantenimiento
de conexión (paquetes UDP vacíos) a través del dispositivo NAT, de forma que la
asignación NAT no cambie hasta que las asociaciones de seguridad (SA) de fase 1 y
fase 2 expiren.
NOTA: Los dispositivos NAT tienen distintos intervalos de tiempo de espera de sesión,
dependiendo del fabricante y el modelo. Es importante determinar qué intervalo
tiene el dispositivo NAT, para poder establecer un valor de frecuencia de
mantenimiento de conexión por debajo de dicho intervalo.
Simetría iniciador/respondedor
Cuando dos dispositivos de seguridad establecen un túnel en ausencia de un
dispositivo NAT, cada dispositivo puede funcionar como iniciador o respondedor.
Sin embargo, si uno de los hosts se encuentra tras un dispositivo NAT, esta simetría
iniciador/respondedor podría llegar a ser imposible. Esto sucede cuando el
dispositivo NAT genera direcciones IP dinámicamente.
246 NAT-Traversal
Figura 64: Dispositivo de seguridad con una dirección IP asignada dinámicamente detrás de un dispositivo NAT
Nota: Las zonas de seguridad ilustradas se
muestran desde la perspectiva del Zona Untrust Zona Trust
dispositivo-B.
Dispositivo
NAT
Dispositivo A Internet Dispositivo B
Host A Host B
Zona 10.1.1.5
1.2.1.1 1.1.1.250
El dispositivo NAT traduce la dirección IP de origen en

Conjunto de paquetes que recibe del dispositivo-B, utilizando
direcciones IP direcciones que toma de su conjunto de direcciones IP.
1.2.1.2 - 1.2.1.50
En la Figura 64, el dispositivo B se encuentra en una subred situada tras un

dispositivo NAT. Si el dispositivo NAT genera nuevas direcciones IP de origen para
los paquetes que recibe desde el dispositivo B (tomándolas dinámicamente de un
conjunto de direcciones IP), el dispositivo A no puede identificar inequívocamente
al dispositivo B. Por lo tanto, el dispositivo A no podrá iniciar con éxito un túnel con
el dispositivo B. El dispositivo A debe actuar como respondedor, el dispositivo B
como iniciador y ambos deben realizar las negociaciones de fase 1 en modo
dinámico.
No obstante, si el dispositivo NAT genera la nueva dirección IP utilizando una

dirección IP asignada (MIP) o cualquier otro método de direccionamiento “1:1”, el
dispositivo A podrá identificar de forma exclusiva al dispositivo B. En consecuencia,
tanto el dispositivo A como el dispositivo B podrán actuar como iniciadores y
ambos podrán utilizar el modo principal o dinámico en la fase 1.
NOTA: Si habilita NAT-T en un dispositivo de seguridad que actúa como respondedor y lo

configura para que lleve a cabo las negociaciones IKE en modo principal, ese
dispositivo y todos sus interlocutores configurados en la misma interfaz de salida
deberán usar las mismas propuestas de fase 1 y presentadas en el mismo orden.
Los interlocutores podrán ser de los siguientes tipos:
Homólogo dinámico (interlocutores con direcciones IP asignadas dinámicamente)

Usuarios VPN de acceso telefónico
Interlocutores con direcciones IP estáticas tras un dispositivo NAT
Como no es posible conocer la identidad de un interlocutor durante las

negociaciones de fase 1 en modo principal hasta los dos últimos mensajes, las
propuestas de fase 1 deberán ser iguales para que las negociaciones IKE se
puedan llevar a cabo.
Cuando se configura IKE en modo principal para uno de los tipos de interlocutor
anteriormente mencionados en la misma interfaz de salida, el dispositivo de
seguridad comprueba automáticamente que todas las propuestas de fase 1 sean
iguales y tengan el mismo orden. Si las propuestas son distintas, el dispositivo de
seguridad generará un mensaje de error.
NAT-Traversal 247
Habilitación de NAT-Traversal
En la Figura 65, un dispositivo NAT ubicado en el perímetro de la red local (LAN) de
un hotel asigna una dirección al cliente VPN de acceso telefónico utilizado por Jose,
un comercial que está participando en una convención. Para que Jose pueda
acceder a la LAN corporativa por medio de un túnel VPN de acceso telefónico, se
debe habilitar NAT-T para la puerta de enlace remota “jose”, configurada en el
dispositivo de seguridad y para la puerta de enlace remota, configurada en el cliente
VPN de acceso telefónico. También deberá habilitar el dispositivo de seguridad para
que incluya una suma de comprobación de UDP en sus transmisiones, y establecer
una frecuencia de mantenimiento de conexión de 8 segundos.
Figura 65: Habilitación de NAT-Traversal

Hotel Empresa
Dispositivo NAT
Internet
Túnel VPN
Cliente VPN telefónico
WebUI
VPN > AutoKey Advanced > Gateway > New: Introduzca los parámetros
necesarios para la nueva puerta de enlace del túnel, según se describe en el
Capítulo 4, “Redes privadas virtuales de punto a punto,” o en el Capítulo 5,
“Redes privadas virtuales de acceso telefónico,” introduzca los datos siguientes
y, a continuación, haga clic en OK:

enlace:

UDP Checksum: Enable
Keepalive Frequency: 8 seconds (0~300 sec.)
NOTA: Cuando se configura una VPN de acceso telefónico con CLI, el dispositivo de
seguridad activa automáticamente NAT-Traversal.
CLI
set ike gateway jose nat-traversal
set ike gateway jose nat-traversal udp-checksum
set ike gateway jose nat-traversal keepalive-frequency 8
save
248 NAT-Traversal
Uso de identificaciones de IKE con NAT-Traversal

Cuando dos puertas de enlace VPN negocian en el modo principal, intercambian las
direcciones IP para identificarse entre sí y activar el túnel. Cuando los dispositivos
situados en uno o ambos extremos del túnel tienen direcciones IP asignadas
dinámicamente, no obstante, deberá configurar las identificaciones IKE (ID local e
ID del interlocutor) en los dispositivos situados en ambos extremos del túnel. Una
identificación IKE es un identificador único que permanece estático. La
identificación IKE se configura durante la fase cuando configura la puerta de enlace
IKE. Configurará las identificaciones IKE en lugar de la dirección IP remota.
Sin NAT-T, un túnel VPN se puede activar con sólo utilizar la ID local en el lado local
y sólo la ID del interlocutor en el lado remoto. Sin embargo, al utilizar NAT-Traversal
con la VPN dinámica en el modo principal con certificados, debe establecer tanto la
ID local como la ID del interlocutor en ambos lados del túnel VPN. El siguiente
ejemplo muestra cómo puede configurar las ID locales y las ID de interlocutores en
el cortafuegos1 y cortafuegos2 para que se puedan identificar entre sí y activar un
túnel entre las mismas.
WebUI
En el cortafuegos1, introduzca lo siguiente:
VPN > AutoKey IKE Advanced> Gateway > New (introduzca lo siguiente y
haga clic en Advanced:
Gateway Name: test_gw

Address/Hostname: 0.0.0.0
Peer-ID: cortafuegos2
Haga clic en Advanced e introduzca lo siguiente:

Local-ID: cortafuegos1
Mode: Main
VPN > AutoKey IKE Advanced> Gateway > New (introduzca lo siguiente y
haga clic en Advanced:
Gateway Name: gw_bap15_p1

Address/Hostname: 1.1.1.1
Peer-ID: cortafuegos1
Haga clic en Advanced e introduzca lo siguiente:

Local-ID: cortafuegos2
Mode: Main
NAT-Traversal 249
CLI
set ike gateway test-gw address 0.0.0.0 id cortafuegos2 main local-id

cortafuegos1 outgoing-interface ethernet0/0 proposal standard
set ike gateway gw_bap15_p1 address 1.1.1.1 id cortafuegos1 main local-id

cortafuegos2 outgoing-interface ethernet0/0 proposal standard
Supervisión de VPN
Cuando se habilita la supervisión de VPN para un túnel específico, el dispositivo de
seguridad envía peticiones de eco ICMP (o “pings”) a través del túnel en intervalos
determinados (configurados en segundos) para supervisar la conectividad de la red
a través del túnel.
NOTA: Para cambiar el intervalo de pings, puede utilizar el siguiente comando CLI: set
vpnmonitor interval número. El intervalo predeterminado es de 10 segundos.
Si la actividad de estas peticiones indica que el estado de supervisión de VPN ha

cambiado, el dispositivo de seguridad activará una de las siguientes capturas del
protocolo simple de gestión de redes (SNMP, o “Simple Network Management
Protocol”):
Up to Down: Esta captura se produce cuando el estado de supervisión de VPN

para el túnel está en línea (up), pero un número consecutivo de peticiones de
eco ICMP determinado no provoca respuesta y no hay otro tráfico VPN
entrante. Entonces el estado cambia a fuera de línea (down).
Down to Up: cuando el estado de la supervisión de VPN está fuera de línea

(down), pero la petición de eco ICMP obtiene una sola respuesta, el estado pasa
a en línea (up). La captura “down-to-up” sólo se produce si se ha inhabilitado la
opción de reencriptación y la asociación de seguridad de fase 2 aún está activa
cuando una petición de eco ICMP obtiene respuesta a través del túnel.
NOTA: Para cambiar el límite de peticiones de eco ICMP consecutivas sin respuesta,
puede utilizar el siguiente comando CLI: set vpnmonitor threshold number. El
valor predeterminado es de 10 peticiones.
Para obtener más información sobre los datos SNMP que proporciona la
supervisión de VPN, consulte “Objetos y capturas SNMP para la supervisión de
VPN” en la página 262.
250 Supervisión de VPN

La supervisión de VPN se aplica por cada objeto VPN, no necesariamente por cada
túnel VPN. Un objeto VPN es el que se define con el comando set vpn, o con sus
equivalentes de WebUI. Una vez definido un objeto VPN, puede hacer referencia a
él en unas o más directivas (creando VPN basadas en directivas). Dado que
ScreenOS deriva un túnel de VPN basada en directivas a partir de un objeto VPN
más los demás parámetros de la directiva, un solo objeto VPN puede ser un
elemento de numerosos túneles VPN. Esta distinción entre objeto VPN y túnel VPN
es importante porque Juniper Networks recomienda aplicar la supervisión de VPN a
no más de 100 túneles IPSec VPN (si no habilita la optimización). Si habilita la
optimización, no habrá límite al número de túneles VPN a los que pueda aplicar la
supervisión de VPN. Para obtener información sobre la opción de optimización,
consulte “Opciones de reencriptación y optimización” en la página 251.
NOTA: La optimización de la supervisión de VPN funciona objeto por objeto. Para

activarla en todos los objetos de la VPN, en ninguno o únicamente en algunos.
Opciones de reencriptación y optimización

Si se habilita la opción de reencriptación, el dispositivo de seguridad comienza a
enviar peticiones de eco ICMP inmediatamente después de completar la
configuración del túnel y seguirá enviándolas indefinidamente. Las peticiones de
eco desencadenan un intento de iniciar negociaciones IKE para establecer un túnel
VPN hasta que el estado de la supervisión de VPN del túnel sea en línea (up).
A continuación, el dispositivo de seguridad utiliza las peticiones de eco con fines de
supervisión de VPN. Si el estado de la supervisión de VPN para el túnel pasa de en
línea a fuera de línea, el dispositivo de seguridad desactivará su asociación de
seguridad (SA) de fase 2 para ese interlocutor. El dispositivo de seguridad
continuará enviando peticiones de eco a su interlocutor según los intervalos
definidos, desencadenando intentos de reiniciar las negociaciones IKE de fase 2
(y las de fase 1, si fuera necesario) hasta que tenga éxito. En ese momento, el
dispositivo de seguridad reactivará la asociación de seguridad de fase 2, generará
una nueva clave y restablecerá el túnel. En el registro de eventos aparecerá un
mensaje indicando que se ha realizado correctamente una operación de
reencriptación.
NOTA: Si un dispositivo de seguridad es un cliente DHCP, una actualización de DHCP en

una dirección distinta hará que IKE se reencripte. Sin embargo, una actualización
de DHCP en la misma dirección no provocará la reencriptación de IKE.
La opción de reencriptación se puede utilizar para garantizar que un túnel AutoKey

IKE siempre esté activo, quizá para supervisar dispositivos situados en la ubicación
remota o para permitir que los protocolos de enrutamiento dinámico memoricen
rutas en una ubicación remota y transmitir mensajes a través del túnel. Otra
aplicación de la supervisión de VPN con la opción de reencriptación es completar
automáticamente la tabla de asociación de túneles a saltos siguientes (tabla NHTB)
y la tabla de rutas cuando se asocian múltiples túneles VPN a una sola interfaz de
túnel. Para ver un ejemplo de este último uso, consulte “Múltiples túneles por
interfaz de túnel” en la página 263.
Si desactiva la opción de reencriptación, el dispositivo de seguridad sólo realizará la

supervisión de VPN cuando el túnel esté activo con tráfico generado por el usuario.
Supervisión de VPN 251

De forma predeterminada, la optimización de la supervisión de VPN está

inhabilitada. Si la habilita (set vpn nombre monitor optimized), el comportamiento
de la supervisión de VPN cambiará tal y como se indica a continuación:
El dispositivo de seguridad considerará el tráfico entrante a través del túnel

VPN equivalente a las respuestas de eco ICMP. Si se acepta tráfico entrante en
sustitución de las respuestas de eco ICMP se pueden reducir las falsas alarmas
que podrían producirse cuando hay mucho tráfico a través del túnel y las
respuestas de eco no consiguen pasar.
Si hay tráfico entrante y saliente a través del túnel VPN, el dispositivo de

seguridad también suprimirá las peticiones de eco de supervisión de VPN. Esto
puede contribuir a reducir el tráfico de red.
Aunque la optimización de supervisión de VPN presenta algunas ventajas, observe

que la supervisión deja de ofrecer estadísticas SNMP precisas, como el tiempo de
retardo de red de VPN, cuando se activa la opción de optimización. Además, si se
utiliza la supervisión de VPN para hacer un seguimiento de la disponibilidad de una
dirección IP de destino en el extremo remoto de un túnel, la función de
optimización puede hacer que los resultados sean erróneos.
Interfaz de origen y dirección de destino

De forma predeterminada, la función de supervisión de VPN utiliza la dirección IP
de la interfaz de salida local como dirección de origen y la dirección IP de la puerta
de enlace remota como dirección de destino. Si el interlocutor remoto es un cliente
VPN de acceso telefónico (como NetScreen-Remote) con una dirección IP interna, el
dispositivo de seguridad detectará automáticamente su dirección interna y la
utilizará como destino. El cliente VPN puede ser un usuario XAuth con una
dirección IP interna asignada, un usuario VPN o el miembro de un grupo VPN de
acceso telefónico con una dirección IP interna. También puede especificar el uso de
otras direcciones IP de origen y destino para la supervisión de VPN, sobre todo para
permitir la supervisión de VPN cuando el otro extremo de un túnel VPN no es un
Como la supervisión de VPN funciona de forma independiente en las ubicaciones

local y remota, la dirección de origen configurada en el dispositivo ubicado en un
extremo del túnel no tiene por qué ser la dirección de destino configurada en el
dispositivo ubicado en el otro extremo. De hecho, es posible habilitar la supervisión
de VPN en ambos extremos del túnel o sólo en uno de ellos.

Figura 66: Direcciones de origen y destino para la supervisión de VPN

Dispositivo-A –> dispositivo-B
Dirección de origen: Dirección de destino:
El dispositivo-A envía peticiones puerta de enlace remota
de eco desde su interfaz de salida Interfaz de salida
a la puerta de enlace remota; es
decir, desde la interfaz de zona Dispositivo A
Untrust en el dispositivo-A a la Túnel VPN Dispositivo B
interfaz de zona Untrust en el LAN LAN
dispositivo-B.
(comportamiento predeterminado)
Dispositivo-A –>NetScreen-Remote
El dispositivo-A envía peticiones Dirección de origen: Dirección de destino:
de eco desde la interfaz de zona Interfaz de la zona Trust NetScreen-Remote
Trust a NetScreen-Remote.
NetScreen-Remote necesita una
directiva que admita el tráfico Dispositivo A Túnel VPN
ICMP entrante desde una LAN
dirección más allá de la puerta
de enlace remota; es decir, Zona Trust Zona Untrust
desde más allá de la interfaz de
zona Untrust del dispositivo-A.
Nota: El dispositivo-A precisa de una directiva que permita el tráfico de
peticiones de eco de la zona Trust a la zona Untrust.
Dispositivo-A –> Terminador de
VPN de otro fabricante Dirección de destino:
Dirección de origen:
Dispositivo-A envía peticiones de Interfaz de la zona Trust remoto
eco desde la interfaz de zona
Trust a un dispositivo ubicado Terminador de VPN
más allá de la puerta de enlace Dispositivo A Túnel VPN de otro fabricante
remota. Esto podría ser LAN
necesario si el interlocutor
remoto no responde a peticiones Zona Trust Zona Untrust
de eco pero admite directivas que
permitan el tráfico entrante de Nota: El dispositivo-A precisa de una directiva que permita el tráfico de
estas peticiones. peticiones de eco de la zona Trust a la zona Untrust.
NOTA: Si al otro lado de un túnel se encuentra un cliente de VPN NetScreen-Remote que

recibe su dirección a través de XAuth, el dispositivo de seguridad utilizará de
forma predeterminada la dirección IP asignada a XAuth como destino para la
supervisión de VPN. Para obtener más información sobre XAuth, consulte
“Usuarios y grupos de usuarios XAuth” en la página 9-72.
Consideraciones sobre directivas

Debe crear una directiva en el dispositivo de envío para permitir que las peticiones
de eco procedentes de la zona donde se encuentra la interfaz de origen pasen a
través del túnel VPN a la zona que contiene la dirección de destino si:
La interfaz de origen se encuentra en una zona distinta de la dirección de

destino
La interfaz de origen se encuentra en la misma zona que la dirección de destino

y está habilitado el bloqueo intrazonal

Asimismo, debe crear una directiva en el dispositivo receptor para permitir que las
peticiones de eco procedentes de la zona donde se encuentra la dirección de origen
pasen a través del túnel VPN a la zona que contiene la dirección de destino si:
La dirección de destino se encuentra en una zona distinta de la dirección de

origen
La dirección de destino se encuentra en la misma zona que la dirección de

origen y está habilitado el bloqueo intrazonal
NOTA: Si el dispositivo receptor es un producto de otro fabricante que no responde a las

peticiones de eco ICMP, cambie el destino a un host interno en la LAN del
interlocutor remoto que sí responda. El cortafuegos del interlocutor remoto
siempre debe disponer de una directiva que permita el paso de las peticiones de
eco ICMP.
Configuración de la función de supervisión de VPN

Para habilitar la supervisión de VPN, siga estos pasos:
WebUI
VPN > AutoKey IKE > New: Configure la VPN, haga clic en Advanced,
introduzca los datos siguientes, haga clic en Return para regresar a la página de
configuración básica de VPN y, finalmente, haga clic en OK:
VPN Monitor: seleccione la opción para habilitar la supervisión de VPN en

este túnel VPN.
Source Interface: Elija una interfaz en la lista desplegable. Si elige default,

el dispositivo de seguridad utilizará la interfaz de salida.
Destination IP: introduzca una dirección IP de destino. Si no introduce

ningún dato, el dispositivo de seguridad utilizará la dirección IP de puerta
de enlace remota.
Rekey: seleccione esta opción si desea que el dispositivo de seguridad

intente realizar las negociaciones IKE de fase 2 (y de fase 1 si fuera
necesario) si el estado del túnel cambia de en línea a fuera de línea. Cuando
seleccione esta opción, el dispositivo de seguridad intentará realizar las
negociaciones IKE para configurar el túnel y comenzar la supervisión de
VPN inmediatamente después de terminar la configuración.
Anule la selección de esta opción si no desea que el dispositivo de

seguridad intente realizar las negociaciones IKE cuando el estado del
túnel cambie de en línea a fuera de línea. Si la opción de reencriptación
está inhabilitada, la supervisión de VPN comenzará cuando el tráfico
generado por el usuario haya desencadenado el inicio de las
negociaciones IKE y se detendrá cuando el estado del túnel pase de en
línea a fuera de línea.

(o bien)
VPNs > Manual Key > New: Configure la VPN, haga clic en Advanced,
introduzca los datos siguientes, haga clic en Return para regresar a la página de
configuración básica de VPN y, finalmente, haga clic en OK:
VPN Monitor: seleccione la opción para habilitar la supervisión de VPN en

este túnel VPN.
Source Interface: Elija una interfaz en la lista desplegable. Si elige default,

el dispositivo de seguridad utilizará la interfaz de salida.
Destination IP: introduzca una dirección IP de destino. Si no introduce

ningún dato, el dispositivo de seguridad utilizará la dirección IP de puerta
de enlace remota.
CLI
set vpnmonitor frequency número
set vpnmonitor threshold número
set vpn cadena_nombre monitor [ source-interface interfaz [ destination-ip dir_ip ] ]
[optimized] [ rekey ]
save
NOTA: La frecuencia de supervisión de VPN se mide en segundos. El ajuste

predeterminado es de 10 segundos.
El umbral de supervisión de VPN es el número de peticiones de eco ICMP seguidas

sin respuesta que determina si la puerta de enlace remota es accesible a través del
túnel o no. El límite predeterminado es de 10 peticiones de eco ICMP consecutivas
con respuesta o 10 peticiones consecutivas sin respuesta.
Si no elige una interfaz de origen, el dispositivo de seguridad utilizará la interfaz
de salida como predeterminada.
Si no elige una dirección IP de destino, el dispositivo de seguridad utilizará la

dirección IP de la puerta de enlace remota.
La opción de reencriptación no está disponible para los túneles VPN con clave
manual.
En este ejemplo configuraremos un túnel VPN AutoKey IKE entre dos dispositivos
de seguridad (dispositivo-A y dispositivo-B). En el dispositivo A, configure la
supervisión de VPN desde su interfaz de zona Trust (ethernet1) a la interfaz de zona
Trust (10.2.1.1/24) del dispositivo-B. En el dispositivo-B, configure la supervisión de
VPN desde su interfaz de zona Trust (ethernet1) a un servidor de red local
corporativa (10.1.1.5) ubicado tras el dispositivo-A.

Zonas e interfaces
ethernet1 ethernet1
Zona: Trust Zone: Trust
Dirección IP: 10.1.1.1/24 Dirección IP: 10.2.1.1/24
Modo de interfaz: NAT Modo de interfaz: NAT
ethernet3 ethernet3
Zona: Untrust Zone: Untrust
Dirección IP: 1.1.1.1/24 Dirección IP: 2.2.2.2/24
Parámetros de túnel AutoKey IKE basado en rutas

Fase 1 Fase 1
Nombre de puerta de enlace: gw1 Nombre de puerta de enlace: gw1
Dirección IP estática de puerta de enlace: Dirección IP estática de puerta de enlace:
2.2.2.2 1.1.1.1
Nivel de seguridad: Compatible1 Propuestas: Compatible
Clave previamente compartida: Ti82g4aX Clave previamente compartida: Ti82g4aX
Interfaz de salida: ethernet3 Interfaz de salida: ethernet3
Modo: Principal Modo: Principal
Fase 2 Fase 2
Nombre de túnel VPN: vpn1 Nombre de túnel VPN: vpn1
Nivel de seguridad: Compatible2 Nivel de seguridad: Compatible
Supervisión de VPN: orig = ethernet1; Supervisión de VPN: orig = ethernet1; dest
dest = 10.2.1.1 = 10.1.1.5
Asociado a la interfaz: tunnel.1 Asociado a la interfaz: tunnel.1
1.El nivel de seguridad Compatible en la fase 1 incluye las siguientes propuestas: pre-g2-3des-sha,
pre-g2-3des-md5, pre-g2-des-sha y pre-g2-des-md5.
2.El nivel de seguridad Compatible en la fase 2 incluye las siguientes propuestas:
nopfs-esp-3des-sha, nopfs-esp-3des-md5, nopfs-esp-des-sha y nopfs-esp-des-md5.
Rutas
A 0.0.0.0/0, utilizar ethernet3, puerta de A 0.0.0.0/0, utilizar ethernet3, puerta de enlace
enlace 1.1.1.250 2.2.2.250
A 10.2.1.0/24, utilizar tunnel.1, sin puerta de A 10.1.1.0/24, utilizar tunnel.1, sin puerta de
enlace enlace
(Ruta Null: para derivar el tráfico a 10.2.1.0/24 (Ruta Null: para derivar el tráfico a 10.1.1.0/24 si
si tunnel.1 queda fuera de línea) Para tunnel.1 queda fuera de línea) Para 10.1.1.0/24,
10.2.1.0/24, utilizar interfaz Null, métrica: 10 utilizar interfaz Null, métrica: 10
Como los dos dispositivos envían peticiones de eco ICMP desde una interfaz en su
zona Trust a una dirección de su zona Untrust, los administradores situados en
ambos extremos del túnel VPN deben definir directivas que permitan que las
peticiones pasen de una zona a otra.

NOTA: Como los dos terminadores VPN de este ejemplo son dispositivos de seguridad, es
posible utilizar las direcciones predeterminadas de origen y destino para la
supervisión de VPN. El uso de otras opciones se incluye únicamente para ilustrar
la configuración de un dispositivo de seguridad para que pueda utilizarlas.
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

Network > Interfaces > Tunnel IF New: Introduzca los siguientes datos y haga
clic en OK:

2. Direcciones

Zone: Trust
Address Name: Remote_LAN

Zone: Untrust

3. VPN
VPN Name: vpn1

Remote Gateway:
Gateway Name: gw1
Type:
Preshared Key: Ti82g4aX

IKE:

Service: ANY
VPN Monitor: (seleccione)
Destination IP: 10.2.1.1
Rekey: (anule la selección)
4. Rutas


Interface: Tunnel.1

Interface: Null
Metric: 10

5. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Remote_LAN
Service: ANY
Action: Permit
haga clic en OK:
Source Address:
Service: Any
Action: Permit
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

Network > Interfaces > Tunnel IF New: Introduzca los siguientes datos y haga
clic en OK:

2. Direcciones

Zone: Trust

Address Name: Remote_LAN

Zone: Untrust
3. VPN
VPN Name: vpn1

Remote Gateway:
Gateway Name: gw1
Type:
Preshared Key: Ti82g4aX

IKE:

Service: ANY
Rekey: (anule la selección)
4. Rutas


Interface: Tunnel.1


Interface: Null
Metric: 10
5. Directivas
haga clic en OK:
Source Address:
Service: ANY
Action: Permit
haga clic en OK:
Source Address:
Service: Any
Action: Permit
CLI (dispositivo-A)
1. Interfaces
2. Direcciones
set address untrust Remote_LAN 10.2.1.0/24
3. VPN
set ike gateway gw1 address 2.2.2.2 main outgoing-interface ethernet3 preshare
Ti82g4aX sec-level compatible
set vpn vpn1 monitor source-interface ethernet1 destination-ip 10.2.1.1

4. Rutas
5. Directivas
set policy top from trust to untrust Trust_LAN Remote_LAN any permit
set policy top from untrust to trust Remote_LAN Trust_LAN any permit
save
CLI (dispositivo-B)
1. Interfaces
2. Direcciones
set address untrust Remote_LAN 10.1.1.0/24
3. VPN
Ti82g4aX sec-level compatible
set vpn vpn1 monitor source-interface ethernet1 destination-ip 10.1.1.5
4. Rutas
5. Directivas
set policy top from trust to untrust Trust_LAN Remote_LAN any permit
set policy top from untrust to trust Remote_LAN Trust_LAN any permit
save
Objetos y capturas SNMP para la supervisión de VPN

ScreenOS permite determinar el estado y las condiciones de las VPN activas
utilizando objetos y capturas de protocolo de gestión simple de redes SNMP (Simple
Network Management Protocol) para la supervisión de VPN. La MIB de supervisión
de VPN indica si cada petición de eco ICMP provoca una respuesta, un promedio
actualizado de respuestas enviadas correctamente, la latencia de la respuesta y la
latencia media de los últimos 30 intentos.
NOTA: Para permitir que la aplicación de gestión SNMP reconozca las MIB de supervisión
de VPN, es necesario importar en la aplicación los archivos de extensión MIB
específicos de ScreenOS. Puede encontrar los archivos de extensión MIB en el CD
de documentación que recibió con su dispositivo de seguridad.

Si se habilita la función de supervisión de VPN en un túnel VPN AutoKey IKE o con

clave manual, el dispositivo de seguridad activará sus objetos SNMP de supervisión
de VPN, que incluyen los siguientes datos:
Número total de sesiones de VPN activas
Hora en la que se inició cada sesión
Elementos de asociación de seguridad de cada sesión:
Tipos de algoritmos de encriptación (DES o 3DES) y de autenticación (MD5

o SHA-1) ESP
Tipo de algoritmo de encabezado de autenticación (MD5 o SHA-1)
Protocolo de intercambio de claves (AutoKey IKE o clave manual)
Método de autenticación de fase 1 (clave previamente compartida o

certificados)
Tipo de VPN (acceso telefónico o punto a punto)
Direcciones IP de interlocutor y puerta de enlace local
IDs de interlocutor y puerta de enlace local
Número SPI (índice de parámetro de seguridad, “Security Parameter

Index”)
Parámetros de estado de sesión
Estado de supervisión de VPN (en línea o fuera de línea)
Estado de túnel (en línea o fuera de línea)
Estado de fase 1 y 2 (inactivo o activo)
Periodo de vigencia de fase 1 y 2 (tiempo en segundos antes de la

reencriptación; el periodo de vigencia de fase 2 también se registra en
bytes restantes antes de la reencriptación)
Múltiples túneles por interfaz de túnel

Es posible asociar múltiples túneles VPN IPSec a una sola interfaz de túnel. Para
vincular un destino específico a uno de los túneles VPN asociados a la misma
interfaz de túnel, el dispositivo de seguridad utiliza dos tablas: la tabla de rutas y la
de asociación de túneles a saltos siguientes (NHTB). El dispositivo de seguridad
asigna la dirección IP de puerta de enlace al siguiente salto, especificada en la
entrada de la tabla de rutas, a un túnel VPN particular especificado en la tabla
NHTB. Con esta técnica, una sola interfaz de túnel puede admitir muchos túneles
VPN. (Consulte “Asignación de rutas a túneles” en la página 264.)
Múltiples túneles por interfaz de túnel 263

Figura 67: Una interfaz de túnel unida a varios túneles
Túneles VPN basados en rutas

para múltiples interlocutores
remotos.
Todos los túneles

comparten la misma
interfaz de túnel.
El dispositivo de seguridad puede ordenar el tráfico VPN enviado a través de una sola interfaz de
túnel a tantos túneles VPN como admita la tabla de rutas o la capacidad del túnel VPN (lo que sea
menor).
El número máximo de túneles VPN no está limitado por el número de interfaces de

túnel que se puedan crear, sino por la capacidad de la tabla de rutas o por el
número máximo de túneles VPN dedicados que se admita (la cifra que sea menor).
Por ejemplo, si el dispositivo de seguridad admite 4,000 rutas y 1,000 túneles VPN
dedicados, será posible crear 1,000 túneles VPN y asociarlos a una sola interfaz de
túnel. Si el dispositivo de seguridad admite 8,192 rutas y 10.000 túneles VPN
dedicados, será posible crear 8,000 túneles VPN y asociarlos a una sola interfaz de
túnel. Para ver la capacidad máxima de rutas y túneles de su dispositivo de
seguridad, consulte la hoja de datos correspondiente del producto.
NOTA: Si la capacidad de la tabla de rutas es lo que va a establecer el límite, deberá restar

al total de túneles VPN basados en rutas las rutas generadas automáticamente por
las interfaces de la zona de seguridad y otras rutas estáticas (como la ruta a la
puerta de enlace predeterminada) que tendrá que definir.
Asignación de rutas a túneles

Para ordenar el tráfico a través de túneles VPN asociados a la misma interfaz de
túnel, el dispositivo de seguridad asigna la dirección IP de la puerta de enlace al
salto siguiente especificada en la ruta a un nombre de túnel VPN determinado. La
asignación de entradas en la tabla de rutas a entradas en la tabla NHTB se muestra
a continuación. En la Figura 68, el dispositivo local de seguridad enruta el tráfico
enviado de 10.2.1.5 a 10.1.1.5 a través de la interfaz tunnel.1 y, a continuación,
a través de vpn2.
264 Múltiples túneles por interfaz de túnel

Figura 68: Tabla de rutas y tabla de asociación de túneles a saltos siguientes (NHTB)
Dispositivo de seguridad local Interlocutores VPN remotos (con direcciones IP
con múltiples túneles asignados externas asignadas dinámicamente y
a la interfaz tunnel.1 direcciones IP de interfaz de túnel fijas) y sus
LAN protegidas
10.1.1.1
10.1.0.0/24
vpn1
10.2.1.5 tunnel.1 10.1.1.5
vpn2 10.1.2.1
10.1.1.0/24
10.2.0.0/16 vpn3
LAN de zona Trust 10.1.3.1
10.1.2.0/24
Tabla de rutas Tabla de asociación de túneles a saltos siguientes
ID IP-Prefix (Dst) Interface Gateway Next-Hop VPN Indicador
1 10.1.0.0/24 tunnel.1 10.1.1.1 10.1.1.1 vpn1 static

Se puede utilizar un protocolo de enrutamiento dinámico como Durante las negociaciones de fase 2, los dos interlocutores IKE
Border Gateway Protocol (BGP) para rellenar la tabla de rutas intercambian direcciones de interfaz de túnel e introducen
automáticamente, o bien introducir manualmente estas rutas. La automáticamente estas asociaciones de túnel a salto siguiente. De
dirección IP de la puerta de enlace es la dirección de la interfaz de forma opcional también se pueden introducir manualmente. La
túnel en la ubicación del interlocutor remoto. dirección IP del siguiente salto será la dirección IP de interfaz de
túnel del interlocutor remoto.
En las entradas anteriores, la dirección IP de la puerta de enlace en la tabla de rutas (que también es la dirección IP de salto siguiente en la
tabla NHTB) es la interfaz de túnel en la ubicación del interlocutor remoto. Esta dirección IP vincula la ruta (y, en consecuencia, la interfaz de
túnel especificada en la ruta) a un túnel VPN determinado para el tráfico destinado al prefijo IP especificado.
El dispositivo de seguridad utiliza la dirección IP de la interfaz de túnel del

interlocutor remoto como puerta de enlace y dirección IP del salto siguiente. Puede
introducir la ruta manualmente o hacer que un protocolo de enrutamiento
dinámico introduzca automáticamente una ruta que haga referencia a la dirección
IP de interfaz de túnel del interlocutor como puerta de enlace en la tabla de rutas.
La misma dirección IP se tiene que introducir como salto siguiente, junto con el
nombre de túnel VPN correspondiente, en la tabla NHTB. Una vez más, dispone de
dos alternativas: puede introducirla manualmente o hacer que el dispositivo de
seguridad la recoja del interlocutor remoto durante las negociaciones de fase 2 y la
introduzca manualmente.
El dispositivo de seguridad utiliza la dirección IP de puerta de enlace en la entrada

de la tabla de rutas y la dirección IP de salto siguiente en la entrada de la tabla
NHTB como elemento común para vincular la interfaz de túnel con el túnel VPN
correspondiente. El dispositivo de seguridad puede así dirigir el tráfico destinado al
prefijo IP especificado en la ruta con el túnel VPN adecuado especificado en la tabla
NHTB.

Direcciones de interlocutores remotos

El esquema de direccionamiento interno de los interlocutores remotos a los que se
accede por VPN basadas en rutas debe ser único para todos ellos. Una forma de
conseguirlo es realizar una traducción de direcciones de red (NAT) de las
direcciones de origen y de las de destino por cada interlocutor remoto. Además, las
direcciones IP de interfaz de túnel también deben ser únicas para todos los
interlocutores remotos. Si pretende conectar un gran número de ubicaciones
remotas, será absolutamente necesario elaborar un esquema de direcciones.
A continuación se muestra un ejemplo de esquema de direcciones para un máximo
de 1.000 túneles VPN:
Puerta de enlace/salto
siguiente
Dest. en tabla Interfaz de túnel (Interfaz de túnel del
local de rutas local interlocutor) Túnel VPN
10.0.3.0/24 tunnel.1 10.0.2.1/24 vpn1
10.0.5.0/24 tunnel.1 10.0.4.1/24 vpn2
10.0.7.0/24 tunnel.1 10.0.6.1/24 vpn3
… … … …
10.0.251.0/24 tunnel.1 10.0.250.1/24 vpn125
10.1.3.0/24 tunnel.1 10.1.2.1/24 vpn126

10.1.5.0/24 tunnel.1 10.1.4.1/24 vpn127
10.1.7.0/24 tunnel.1 10.1.6.1/24 vpn128
… … … …
10.1.251.0/24 tunnel.1 10.1.250.1/24 vpn250
10.2.3.0/24 tunnel.1 10.2.2.1/24 vpn251

… … … …
10.2.251.0/24 tunnel.1 10.2.250.1/24 vpn375
… … … …
10.7.3.0/24 tunnel.1 10.7.2.1/24 vpn876
… … … …
10.7.251.0/24 tunnel.1 10.7.250.1/24 vpn1000
La interfaz de túnel en el dispositivo de seguridad local es 10.0.0.1/24. En todos los

hosts remotos, hay una interfaz de túnel con una dirección IP que aparece como la
dirección IP de puerta de enlace/salto siguiente en la tabla de rutas local y en la
tabla NHTB.
Si desea ver un ejemplo que ilustra la asociación de múltiples túneles con una sola
interfaz de túnel con traducción de direcciones, consulte “Ajuste de VPN en una
interfaz de túnel para subredes superpuestas” en la página 269.

Figura 69: Múltiples túneles asociados a una única interfaz de túnel con traducción de direcciones
El dispositivo de seguridad local y todos 10.0.4.1/24
sus interlocutores ejecutan la NAT-dst 10.0.5.1 -> 10.0.6.1/24
traducción de direcciones de destino direcciones IP internas NAT-dst 10.0.7.1 ->
(NAT-dst) con desplazamiento de IP en direcciones IP internas
el tráfico VPN entrante y traducción de IF 10.0.2.1/24
direcciones de origen (NAT-src) desde NAT-dst 10.0.3.1 -> vpn2
direcciones IP internas vpn3
la dirección IP de interfaz de túnel de
salida con traducción de puertos en el vpn1 10.1.1.1/24
tráfico VPN saliente. NAT-dst 10.1.2.1 ->
IF 10.0.2.1/24 direcciones IP internas
NAT-dst 10.0.3.1 -> vpn251
direcciones IP internas
10.6.2.1/24
Dispositivo de NAT-dst 10.6.3.1->
seguridad local vpn751 direcciones IP internas
10.0.0.1/24
NAT-dst 10.0.1.1 ->
direcciones IP internas vpn1000
10.7.250.1/24
NAT-dst 10.7.251.1 ->
direcciones IP internas
Entradas de tabla manuales y automáticas

Puede incluir entradas manualmente en las tablas NHTB y de rutas. También puede
automatizar la carga de las tablas NHTB y de rutas. Si se va a trabajar con un
número pequeño de túneles asociados a una sola interfaz de túnel, el método
manual puede funcionar bien. Sin embargo, para un gran número de túneles, el
método automático reduce la configuración y el mantenimiento administrativos, ya
que las rutas se ajustan dinámicamente cuando los túneles o interfaces dejan de
estar disponibles en la interfaz de túnel en la ubicación del concentrador.
Entradas manuales en la tabla

Un túnel VPN se puede asignar manualmente a la dirección IP de la interfaz de
túnel de un interlocutor remoto en la tabla de asociación de túneles a saltos
siguientes (NHTB). En primer lugar debe ponerse en contacto con el administrador
remoto y conocer las direcciones IP utilizadas por la interfaz de túnel en ese
extremo del túnel. A continuación podrá asociar esta dirección al nombre de túnel
VPN en la tabla NHTB con el siguiente comando:
set interface tunnel.1 nhtb dirección_interfaz_túnel_interlocutor vpn nombre
Una vez hecho esto, podrá introducir una ruta estática en la tabla de rutas que
utiliza la dirección IP de interfaz de túnel como puerta de enlace. Puede introducir
la ruta por medio de la WebUI o con el siguiente comando CLI:
set vrouter cadena_nombre route dir_dest interface tunnel.1 gateway

dir_interfaz_túnel_interloc
Entradas automáticas en la tabla

Para que la tabla de rutas y la tabla NHTB se rellenen automáticamente, se deben
cumplir las siguientes condiciones:
Los interlocutores remotos de todos los túneles VPN asociados a una sola
interfaz de túnel local deben ser dispositivos de seguridad con ScreenOS 5.0.0
o posterior.

Cada interlocutor remoto debe asociar su túnel a una interfaz de túnel, y esa
interfaz debe tener una dirección IP única entre todas las direcciones de
interfaz de túnel de los interlocutores.
En ambos extremos del túnel VPN, habilite la supervisión de VPN con la opción
de reencriptación (Rekey), o habilite la opción de nueva conexión de pulsos de
IKE (IKE Heartbeat Reconnect) para cada puerta de enlace remota.
Los interlocutores locales y remotos deben tener habilitada una instancia de un

protocolo de enrutamiento dinámico en sus interfaces de túnel de conexión.
El uso de supervisión de VPN con la opción de reencriptación permite que los

dispositivos de seguridad situados en ambos extremos de un túnel puedan
establecer el túnel sin tener que esperar a que haya tráfico VPN originado por el
usuario. Una vez habilitada la supervisión de VPN con la opción de reencriptación a
los dos lados de un túnel VPN, los dos dispositivos de seguridad llevarán a cabo las
negociaciones IKE de fase 1 y 2 para establecer el túnel. (Para obtener más
información, consulte “Supervisión de VPN” en la página 250).
NOTA: Si se ejecuta un protocolo de enrutamiento dinámico en las interfaces de túnel, el

tráfico generado por el protocolo puede desencadenar negociaciones IKE aunque
no se habilite la supervisión de VPN con la opción de reencriptación o la opción de
nueva conexión de pulsos de IKE. En cualquier caso, se recomienda no confiar en
que el tráfico de enrutamiento dinámico desencadene las negociaciones IKE. En
lugar de ello, utilice la supervisión de VPN con la opción de reencriptación o de
nueva conexión de pulsos de IKE.
Para OSPF (Open Shortest Path First, abrir primero la ruta más corta), debe
configurar la interfaz de túnel en el interlocutor local como interfaz “punto a
multipunto” antes de activar el protocolo de enrutamiento en la interfaz.
En el caso de interlocutores remotos con una dirección IP externa asignada

dinámicamente o con un nombre de dominio totalmente clasificado (FQDN)
asignado a una dirección IP dinámica, el interlocutor remoto primero debe iniciar
las negociaciones IKE. Sin embargo, dado que la asociación de seguridad de fase 2
en el dispositivo de seguridad local guarda en caché la dirección IP asignada
dinámicamente del interlocutor remoto, cada interlocutor puede reiniciar las
negociaciones IKE para restablecer un túnel cuyo estado de supervisión de VPN
haya cambiado de en línea a fuera de línea.
Durante las negociaciones de fase 2, los dispositivos de seguridad intercambian

entre sí direcciones IP de interfaz de túnel. Cada módulo IKE puede introducir
automáticamente la dirección IP de interfaz de túnel y su nombre de túnel VPN
correspondiente en la tabla NHTB.
Para hacer que el dispositivo de seguridad local pueda introducir rutas a destinos
remotos automáticamente en su tabla de rutas, debe habilitar una instancia de BGP
en las interfaces de túnel locales y remotas. Los pasos básicos son los siguientes:
1. Crear una instancia de enrutamiento BGP en el enrutador virtual que contiene

la interfaz de túnel a la que se han asociado múltiples túneles VPN.
2. Habilitar la instancia de enrutamiento en el enrutador virtual.

3. Habilitar la instancia de enrutamiento en la interfaz de túnel que conduce a los

interlocutores BGP.
Los interlocutores remotos también llevan a cabo estos pasos.
En el dispositivo local (o concentrador), también debe definir una ruta

predeterminada y una ruta estática a cada dirección IP de interfaz de túnel de los
interlocutores. Las rutas estáticas a las interfaces de túnel de los interlocutores son
necesarias para que el dispositivo concentrador pueda acceder inicialmente a sus
vecinos BGP a través del túnel VPN correcto.
Después de establecer las comunicaciones, los vecinos BGP intercambian

información de enrutamiento, de forma que puedan rellenar automáticamente sus
tablas de rutas. Una vez que los dos interlocutores establecen un túnel VPN entre sí,
pueden enviar y recibir información de enrutamiento desde y hacia el dispositivo
local. Cuando la instancia de enrutamiento dinámico en el dispositivo de seguridad
aprende una ruta a un interlocutor a través de una interfaz de túnel local, incluye la
dirección IP de la interfaz de túnel del interlocutor remoto como puerta de enlace
en la ruta.
Para ver un ejemplo que ilustra la configuración de múltiples túneles asociados a

una única interfaz de túnel, donde el dispositivo concentrador rellena sus tablas
NHTB y de rutas automáticamente, consulte “Asociación de entradas automáticas
en la tabla de rutas y en la tabla NHTB” en la página 288.
Ajuste de VPN en una interfaz de túnel para subredes superpuestas

En este ejemplo asociaremos tres túneles VPN AutoKey IKE basados en rutas (vpn1,
vpn2 y vpn3) a una sola interfaz de túnel (tunnel.1). Los túneles van del dispositivo
A a tres interlocutores remotos: interloc1, interloc2 y interloc3. Las entradas de las
tablas NHTB y de rutas para los tres interlocutores se agregarán manualmente al
dispositivo A. Para ver una configuración que proporcione un medio automático de
rellenar las tablas de rutas y NHTB, consulte “Asociación de entradas automáticas
en la tabla de rutas y en la tabla NHTB” en la página 288.
Figura 70: Interfaz Tunnel.1 asociada con tres túneles VPN

vpn1
Puerta de enlace IKE: interloc1, 2.2.2.2
La zona Trust para el dispositivo-A no se muestra. Interfaz de túnel del interlocutor remoto: 10.0.2.1
Zona Untrust
interloc1
LAN vpn2
vpn1
Dispositivo A Puerta de enlace IKE:
vpn2 interloc2
LAN interloc2, 3.3.3.3
vpn3 Interfaz de túnel del
interloc3 interlocutor remoto: 10.0.4.1
LAN
Zona Trust tunnel.1 ethernet3 vpn3
ethernet1 10.0.0.1/30 ethernet3
1.1.1.1/24 Puerta de enlace IKE: interloc3, 4.4.4.4
10.1.1.1/24 Conjunto de DIP 5: 1.1.1.1/24
external router Interfaz de túnel del interlocutor remoto:
10.0.0.2 - 10.0.0.2 Enrutador externo
1.1.1.250 10.0.6.1
1.1.1.250

Las configuraciones de túnel VPN a ambos extremos de cada túnel utilizan los
siguientes parámetros:
AutoKey IKE
Clave previamente compartida para cada interlocutor:
interloc1 utiliza “netscreen1”
Nivel de seguridad predefinido como “Compatible” para ambas propuestas de

fase 1 y fase 2. (Para ver los detalles sobre estas propuestas, consulte
“Negociación de túnel” en la página 9).
Todas las zonas de seguridad e interfaces en cada dispositivo se encuentran en el

dominio de enrutamiento virtual trust-vr del dispositivo correspondiente.
En este ejemplo se utiliza el mismo espacio de direcciones (10.1.1.0/24) en cada

LAN para mostrar cómo se puede utilizar la traducción de direcciones de red de
origen y destino (NAT-src y NAT-dst) para evitar problemas de direccionamiento
entre los interlocutores IPSec. Para obtener más información sobre NAT-src y
NAT-dst, consulte el Volumen 8: Traducción de direcciones.
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

clic en OK:


ID: 5
2. Direcciones
Address Name: corp

Zone: Trust
Address Name: oda1

Zone: Trust
Address Name: peers

Zone: Untrust
3. VPN
VPN Name: vpn1

Gateway Name: interloc1

IKE:

Service: ANY

VPN Name: vpn2


IKE:

Service: ANY
VPN Name: vpn3


IKE:

Service: ANY
4. Rutas
Network > Routing > Routing Entries > (trust-vr) New: Introduzca los




Interface: tunnel.1

Interface: tunnel.1

Interface: tunnel.1

Interface: tunnel.1

Interface: tunnel.1

Interface: tunnel.1

Interface: null
Metric: 10

Network > Interfaces > Edit (para tunnel.1) > NHTB > New: Introduzca los
New Next Hop Entry:

VPN: vpn1
Network > Interfaces > Edit (para tunnel.1) > NHTB: Introduzca los
New Next Hop Entry:

VPN: vpn2
Network > Interfaces > Edit (para tunnel.1) > NHTB: Introduzca los
New Next Hop Entry:

VPN: vpn3
5. Directivas
haga clic en OK:
Source Address:
Address Book: (seleccione), corp
Address Book: (seleccione), peers
Service: Any
Action: Permit

NAT:
DIP On: 5 (10.0.0.2–10.0.0.2)/X-late
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), peers
Address Book Entry: (seleccione), oda1
Service: Any
Action: Permit

NAT:
Translate to IP Range: (seleccione), 10.1.1.0 - 10.1.1.254

CLI (dispositivo-A)
1. Interfaces
2. Direcciones
set address trust corp 10.1.1.0/24
set address trust oda1 10.0.1.0/24
set address untrust peers 10.0.0.0/16
3. VPN
set ike gateway interloc1 address 2.2.2.2 outgoing-interface ethernet3 preshare
set vpn vpn1 gateway interloc1 sec-level compatible
4. Rutas
set vrouter trust-vr route 10.0.3.0/24 interface tunnel.1 gateway 10.0.2.1
set interface tunnel.1 nhtb 10.0.2.1 vpn vpn1
5. Directivas
set policy from trust to untrust corp peers any nat src dip-id 5 permit
set policy from untrust to trust peers oda1 any nat dst ip 10.1.1.0 10.1.1.254
permit
save

Interloc1
La siguiente configuración, según se ilustra en la Figura 71, es la que el
administrador remoto del dispositivo de seguridad en la ubicación interloc1 debe
introducir para crear un túnel VPN al dispositivo-A en la empresa. El administrador
remoto configura el dispositivo de seguridad para que realice NAT en el origen y en
el destino (NAT-src y NAT-dst) porque las direcciones internas se encuentran en el
mismo espacio de direcciones que las de la LAN corporativa: 10.1.1.0/24. Interloc1
lleva a cabo NAT-src utilizando el conjunto de DIP 6 para traducir todas las
direcciones de origen internas a 10.0.2.2 al enviar tráfico a través de VPN1 al
dispositivo-A. Interloc1 lleva a cabo NAT-dst en el tráfico VPN enviado desde el
dispositivo-A, traduciendo las direcciones de 10.0.3.0/24 a 10.1.1.0/24 con
desplazamiento de direcciones.
Figura 71: Interloc1 realizando NAT-Dst
ethernet3 tunnel.10
2.2.2.2/24 10.0.2.1/30 Rango NAT-dst NAT-dst de
Enrutador externo Conjunto de DIP 6 10.0.3.0 – 10.0.3.255 10.0.3.0 – 10.0.3.255
2.2.2.250 10.0.2.2 - 10.0.2.2 a
ethernet1 10.1.1.0 – 10.1.1.255
10.1.1.1/24 con desplazamiento de
Zona Untrust Interloc1 direcciones
Zona Trust
vpn1 de
dispositivo-A
LAN
10.1.1.0/24
NOTA: Para obtener más información sobre NAT-src y NAT-dst, consulte el Volumen 8:
Traducción de direcciones.
WebUI (Interloc1)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

clic en OK:


ID: 6
2. Direcciones
Address Name: lan

Zone: Trust
Address Name: oda2

Zone: Trust
Address Name: to_corp

Zone: Untrust
Address Name: fr_corp

Zone: Untrust
3. VPN
VPN Name: vpn1

Gateway Name: corp


IKE:

Service: ANY
4. Rutas

Metric: 1

Metric: 1

Interface: tunnel.10
Metric: 10

Interface: null
Metric: 12
5. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), fr_corp
Service: Any
Action: Permit


NAT:
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), lan
Address Book Entry: (seleccione), to_corp
Service: Any
Action: Permit

NAT:
DIP On: 6 (10.0.2.2–10.0.2.2)/X-late
CLI (Interloc1)
1. Interfaces
2. Direcciones
set address trust lan 10.1.1.0/24
set address untrust to_corp 10.0.1.0/24
set address untrust fr_corp 10.0.0.2/32
3. VPN
4. Rutas
metric 1
set vrouter trust-vr route 10.0.3.0/24 interface ethernet1 metric 1
set vrouter trust-vr route 10.0.0.0/8 interface tunnel.10 metric 10

5. Directivas
set policy from trust to untrust lan to_corp any nat src dip-id 6 permit
set policy from untrust to trust fr_corp oda2 any nat dst ip 10.1.1.0 10.1.1.254
permit
save
Interloc2
dispositivo-A. Interloc2 lleva a cabo NAT-dst en el tráfico VPN enviado desde el
dispositivo-A, traduciendo las direcciones de 10.0.5.0/24 a 10.1.1.0/24 con
Figura 72: Interloc2
ethernet3 tunnel.20
10.0.4.1/30 Rango NAT-dst NAT-dst de
3.3.3.3/24 10.0.5.0 – 10.0.5.255
Enrutador externo Conjunto de DIP 7 10.0.5.0 – 10.0.5.255
3.3.3.250 10.0.4.2 - 10.0.4.2 ethernet1 a
10.1.1.1/24 10.1.1.0 – 10.1.1.255
con desplazamiento
Zona Untrust de direcciones
Interloc2
Zona Trust
vpn2 desde
dispositivo-A LAN
10.1.1.0/24
NOTA: Para obtener más información sobre NAT-src y NAT-dst, consulte el Volumen 8:
Traducción de direcciones.
WebUI (Interloc2)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust


clic en OK:

ID: 7
2. Direcciones
Address Name: lan

Zone: Trust
Address Name: oda3

Zone: Trust

Zone: Untrust

Zone: Untrust

3. VPN
VPN Name: vpn2

Gateway Name: corp

IKE:

Service: ANY
4. Rutas

Metric: 1

Metric: 1

Metric: 10

Interface: null
Metric: 12

5. Directivas
haga clic en OK:
Source Address:
Service: Any
Action: Permit

NAT:
DIP On: 7 (10.0.4.2–10.0.4.2)/X-late
haga clic en OK:
Source Address:
Service: Any
Action: Permit

NAT:
CLI (Interloc2)
1. Interfaces
2. Direcciones

3. VPN
4. Rutas
metric 1
5. Directivas
permit
save
Interloc3
dispositivo A. Interloc3 lleva a cabo NAT-dst en el tráfico VPN enviado desde el
dispositivo A, traduciendo las direcciones de 10.0.7.0/24 a 10.1.1.0/24 con
ethernet3
4.4.4.4/24 tunnel.30 Rango NAT-dst
Enrutador externo 10.0.6.1/30 NAT-dst de
Conjunto de DIP 8 10.0.7.0 – 10.0.7.255 10.0.7.0 – 10.0.7.255
4.4.4.250
10.0.6.2 - 10.0.6.2 a
ethernet1
vpn2 desde Zona Untrust 10.1.1.1/24
10.1.1.0 – 10.1.1.255
dispositivo-A con desplazamiento
Interloc3 de direcciones
Zona Trust
LAN
10.1.1.0/24
NOTA: Para obtener más información sobre NAT-dst, consulte el Volumen 8: Traducción de
direcciones.

WebUI (Interloc3)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

clic en OK:

ID: 7
2. Direcciones
Address Name: lan

Zone: Trust
Address Name: oda4

Zone: Trust


Zone: Untrust

Zone: Untrust
3. VPN
VPN Name: vpn3

Gateway Name: corp

IKE:

Service: ANY
4. Rutas

Metric: 1

Metric: 1


Metric: 10

Interface: null
Metric: 12
5. Directivas
haga clic en OK:
Source Address:
Service: Any
Action: Permit

NAT:
DIP On: 8 (10.0.6.2–10.0.6.2)/X-late
haga clic en OK:
Source Address:
Service: Any
Action: Permit

NAT:

CLI (Interloc3)
1. Interfaces
2. Direcciones
3. VPN
4. Rutas
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 3.3.3.250 metric
1
5. Directivas
permit
save

tabla NHTB
En la Figura 74 en la página 289, se asocian dos túneles VPN AutoKey IKE basados
en rutas (vpn1 y vpn2) a una sola interfaz de túnel (tunnel.1) en el dispositivo-A,
ubicado en la empresa. La red que cada interlocutor remoto protege tiene múltiples
rutas tras la ruta conectada. Utilizando el protocolo de puerta de enlace de límites
BGP (Border Gateway Protocol), los interlocutores comunican sus rutas al
dispositivo-A. Este ejemplo permite el tráfico VPN desde la ubicación corporativa
tras el dispositivo-A a los interlocutores.
NOTA: En este ejemplo también puede utilizar OSPF (“Open Shortest Path First” = “abrir
primero la ruta más corta”) en lugar de BGP como protocolo de enrutamiento.
Consulte “Uso de OSPF para entradas automáticas en la tabla de rutas” en la
página 300 para ver las configuraciones de OSPF.

Figura 74: Entradas automáticas en la tabla de rutas y la tabla NHTB (dispositivo-A)

vpn1
La interfaz tunnel.1 del dispositivo-A se Las rutas tras cada interlocutor son
asocia a dos túneles VPN. desconocidas para el dispositivo-A
Interfaz de túnel del interlocutor remoto: 2.3.3.1
hasta que los interlocutores utilizan
BGP para enviarlas.
Zona Untrust
interloc1
vpn1
Dispositivo A
interloc2
vpn2
Zona Trust tunnel.1 ethernet3
ethernet1 10.0.0.1/30 1.1.1.1/24
10.1.1.1/24 Enrutador externo
1.1.1.250
vpn2
Interfaz de túnel del interlocutor remoto: 3.4.4.1
Las configuraciones de túnel VPN a ambos extremos de cada túnel utilizan los
siguientes parámetros: AutoKey IKE, clave previa compartida (interloc1:
“netscreen1”, interloc2: “netscreen2”) y el nivel de seguridad predefinido como
“Compatible” para las propuestas de fase 1 y fase 2. (Para ver los detalles sobre
estas propuestas, consulte “Negociación de túnel” en la página 9).
Antes de configurar las dos siguientes funciones, puede habilitar el dispositivo-A

para que rellene sus tablas de rutas y NHTB automáticamente:
Supervisión de VPN con la opción de reencriptación (o de nueva conexión de

pulsos de IKE)
Enrutamiento dinámico BGP en tunnel.1
NOTA: Si se ejecuta un protocolo de enrutamiento dinámico en las interfaces de túnel, el

tráfico generado por el protocolo puede desencadenar negociaciones IKE aunque
no se habilite la supervisión de VPN con la opción de reencriptación o la opción de
nueva conexión de pulsos de IKE. En cualquier caso, Juniper Networks
recomienda no confiar en que el tráfico de enrutamiento dinámico desencadene
las negociaciones IKE. En lugar de ello, utilice la supervisión de VPN con la opción
de reencriptación o de nueva conexión de pulsos de IKE.
Si las interfaces de túnel se ejecutan con BGP, el tráfico generado por BGP puede
desencadenar negociaciones IKE aun cuando no se habilite la supervisión de VPN
con la opción de reencriptación o la opción de nueva conexión de pulsos de IKE.
En cualquier caso, Juniper Networks recomienda no confiar en que el tráfico BGP
desencadene las negociaciones IKE. En lugar de esto, utilice la supervisión de VPN
con la opción de reencriptación o de nueva conexión de pulsos de IKE.

Cuando se activa la supervisión de VPN con la opción de reencriptación para un

túnel VPN AutoKey IKE, el dispositivo A establece una conexión VPN con su
interlocutor remoto en el momento en que usted y el administrador en la ubicación
remota terminan de configurar el túnel. Los dispositivos no esperan a que aparezca
tráfico VPN generado por el usuario para iniciar las negociaciones IKE. Durante las
negociaciones de fase 2, el dispositivo de seguridad intercambia su dirección IP de
interfaz de túnel, de forma que el dispositivo A realiza automáticamente una
asociación de la VPN al siguiente salto en su tabla NHTB.
La opción de reencriptación garantiza que cuando finalice el periodo de validez de

las claves de fase 1 y 2, los dispositivos negociarán automáticamente la generación
de nuevas claves sin que ningún usuario tenga que intervenir. La supervisión de
VPN con la opción de reencriptación habilitada ofrece básicamente una forma de
conservar siempre activo un túnel VPN, aun cuando no haya tráfico generado por
usuario. Esto es necesario para que las instancias de enrutamiento dinámico BGP,
que usted y el administrador crean y habilitan en las interfaces de túnel a ambos
lados de los túneles, puedan enviar información de enrutamiento al dispositivo A y
rellenen automáticamente su tabla de rutas con las rutas que necesita para dirigir el
tráfico a través del túnel VPN antes de que esas rutas sean necesarias para el tráfico
generado por el usuario. (Los administradores en las ubicaciones de los
interlocutores tienen que introducir una única ruta estática al resto de la red privada
virtual a través de la interfaz de túnel en cada ubicación).
Debe introducir una ruta predeterminada y rutas estáticas en el dispositivo-A para

acceder a sus vecinos BGP a través de los túneles VPN adecuados. Todas las zonas
de seguridad e interfaces en cada dispositivo se encuentran en el dominio de
enrutamiento virtual trust-vr del dispositivo correspondiente.
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

clic en OK:


2. VPN
VPN Name: vpn1

> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en Return
para regresar a la página de configuración básica de AutoKey IKE:

Service: ANY
Rekey: (seleccione)
NOTA: Conserve los ajustes predeterminados en las opciones de interfaz de origen e IP

de destino. Para obtener más información sobre estas opciones, consulte
“Supervisión de VPN” en la página 250.
VPN Name: vpn2


IKE:

Service: ANY
Rekey: (seleccione)
NOTA: Conserve los ajustes predeterminados en las opciones de interfaz de origen e IP

de destino. Para obtener más información sobre estas opciones, consulte
“Supervisión de VPN” en la página 250.

3. Ruta estática


Interface: tunnel.1

Interface: tunnel.1
4. Enrutamiento dinámico
Network > Routing > Virtual Routers > Edit (para trust-vr) > Create BGP
Instance: Introduzca los siguientes datos y haga clic en OK:
AS Number (obligatorio): 99
BGP Enabled: (seleccione)
Network > Interfaces > Edit (para tunnel.1) > BGP: Seleccione la casilla de
verificación Protocol BGP, luego haga clic en OK.
Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit BGP
Instance > Neighbors: Introduzca los siguientes datos y haga clic en Add:
AS Number: 99
Remote IP: 2.3.3.1
AS Number: 99
Remote IP: 3.4.4.1

5. Directiva
haga clic en OK:
Source Address:
Address Book: (seleccione), Any
Address Book: (seleccione), Any
Service: ANY
Action: Permit
CLI (dispositivo-A)
1. Interfaces
2. VPN
set vpn vpn1 monitor rekey
3. Rutas estáticas
device-> set vrouter trust-vr protocol bgp 99
device-> set vrouter trust-vr protocol bgp enable
device-> set interface tunnel.1 protocol bgp
device-> set vrouter trust-vr
device(trust-vr)-> set protocol bgp
device(trust-vr/bgp)-> set neighbor 2.3.3.1 remote-as 99 outgoing interface
tunnel.1
device(trust-vr/bgp)-> set neighbor 2.3.3.1 enable
tunnel.1
device(trust-vr/bgp)-> exit
device(trust-vr)-> exit

5. Directiva
save
Interloc1
La siguiente configuración, según se ilustra en la Figura 75 en la página 294, es la
que el administrador remoto del dispositivo de seguridad en la ubicación interloc1
debe introducir para crear un túnel VPN al dispositivo-A en la empresa. El
administrador remoto configura el dispositivo de seguridad para permitir el tráfico
entrante desde la empresa. También configura el dispositivo de seguridad para
comunicar rutas internas a su vecino BGP a través de vpn1.

ethernet3
2.2.2.2/24
Enrutador externo tunnel.10 ethernet1 Zona Trust
2.2.2.250 2.3.3.1/30 2.3.4.1/24
Zona Untrust
2.3.
Interloc1
vpn2 desde 2.3.4.0/24

dispositivo-A
2.3.
WebUI (Interloc1)
1. Interfaces
haga clic en OK:
Zone Name: Trust

haga clic en OK:
Zone Name: Untrust

clic en OK:


2. Dirección
Address Name: corp

Zone: Untrust
3. VPN
VPN Name: vpn1

Gateway Name: corp

IKE:

Service: ANY
4. Rutas estáticas

Metric: 1

Metric: 1

AS Number: 99
Remote IP: 10.0.0.1
6. Directiva
haga clic en OK:
Source Address:
Service: ANY
Action: Permit
CLI (Interloc1)
1. Interfaces
2. Dirección
3. VPN
4. Rutas estáticas
metric 1
tunnel.10

6. Directiva
set policy from untrust to trust corp any any permit
save
Interloc2
remoto configura el dispositivo de seguridad para permitir el tráfico entrante desde
la empresa. También configura el dispositivo de seguridad para comunicar rutas
internas a su vecino BGP a través de vpn2.

ethernet3
3.3.3.3/24
Enrutador externo tunnel.20 ethernet1 Zona Trust
3.3.3.250 3.4.4.1/30 3.4.5.1/24
vpn2 desde
dispositivo-A 3.4.
Interloc
3.4.5.0/24
Zona Untrust
3.4.
WebUI (Interloc2)
1. Interfaces
haga clic en OK:
Zone Name: Trust

haga clic en OK:
Zone Name: Untrust

clic en OK:


2. Dirección
Address Name: corp

Zone: Untrust
3. VPN
VPN Name: vpn2

Gateway Name: corp

IKE:

Service: ANY
4. Rutas estáticas

Metric: 1

Metric: 1

AS Number: 99
Remote IP: 10.0.0.1
6. Directiva
haga clic en OK:
Source Address:
Service: ANY
Action: Permit
CLI (Interloc2)
1. Interfaces
2. Dirección
3. VPN
4. Rutas estáticas
metric 1
tunnel.20

6. Directiva
set policy from untrust to trust corp any any permit
save
Uso de OSPF para entradas automáticas en la tabla de rutas

También puede configurar OSPF en lugar del enrutamiento dinámico BGP para que
los interlocutores comuniquen sus rutas al dispositivo-A. Para permitir que tunnel.1
en el dispositivo-A pueda formar adyacencias OSPF con sus interlocutores, debe
configurar la interfaz de túnel como interfaz “punto a multipunto”. La configuración
de enrutamiento dinámico OSPF para cada dispositivo se muestra abajo.
Enrutamiento dinámico (OSPF)
Network > Routing > Virtual Routers > Edit (para trust-vr) > Create OSPF
Instance: Seleccione OSPF Enabled, luego haga clic en Apply.
Area > Configure (para el área 0.0.0.0): Haga clic en << Add para mover
la interfaz tunnel.1 de la lista “Available Interface(s)” a la lista “Selected
Interface(s)” y luego haga clic en OK.
Network > Interfaces > Edit (para tunnel.1) > OSPF: Introduzca los siguientes
Bind to Area: (seleccione), Seleccione 0.0.0.0 en la lista desplegable

Protocol OSPF: Enable
Link Type: Point-to-Multipoint (seleccione)
CLI (dispositivo-A)
device-> set vrouter trust-vr protocol ospf
device-> set vrouter trust-vr protocol ospf enable
device-> set interface tunnel.1 protocol ospf area 0
device-> set interface tunnel.1 protocol ospf link-type p2mp
device-> set interface tunnel.1 protocol ospf enable
device-> save
WebUI (Interloc1)


CLI (Interloc1)
device-> save
WebUI (Interloc2)

CLI (Interloc2)
device-> save
Puertas de enlace VPN redundantes

La función de puertas de enlace redundantes ofrece una solución para la
conectividad VPN continua durante y después de una conmutación por error punto
a punto. Es posible crear un grupo VPN para proporcionar un conjunto de hasta
cuatro puertas de enlace redundantes al que se pueden conectar túneles VPN
AutoKey IKE IPSec de interlocutor dinámico punto a punto o punto a punto basados
en directivas. Cuando el dispositivo de seguridad recibe por primera vez tráfico que
coincide con una directiva relativa a un grupo VPN, realiza las negociaciones IKE de
fase 1 y fase 2 con todos los miembros de ese grupo. El dispositivo de seguridad
envía datos a través del túnel VPN a la puerta de enlace con la mayor prioridad
(o peso) del grupo. Para todas las demás puertas de enlace del grupo, el dispositivo
de seguridad actualiza las asociaciones de seguridad de fase 1 y 2 y mantiene
activos los túneles enviando a través de ellos paquetes de mantenimiento de
conexión IKE. Si el túnel VPN activo falla, puede producir una conmutación por
error al túnel y la puerta de enlace con el segundo nivel de prioridad del grupo.
Puertas de enlace VPN redundantes 301

NOTA: Los grupos VPN no admiten túneles de los siguientes tipos: L2TP,
L2TP-sobre-IPSec, acceso telefónico, clave manual ni túneles VPN basados en
rutas. En una configuración de interlocutores dinámicos punto a punto, el
dispositivo de seguridad que supervisa el grupo VPN debe tener la dirección IP
Untrust asignada dinámicamente, mientras que las direcciones IP de los
miembros del grupo VPN deben ser estáticas.
En este esquema se asume que los sitios situados detrás de las puertas de enlace
redundantes están conectados de tal forma que los datos se replican entre los
hosts de todos los sitios. Además, cada sitio (al ser dedicado para alta
disponibilidad) tiene un conjunto redundante de dispositivos de seguridad que
funcionan en modo de alta disponibilidad. Así, el límite de conmutación de fallo
de VPN que se ajuste debe ser mayor que el límite de conmutación por error del
dispositivo o se podrían producir conmutaciones por error innecesarias.
Figura 77: Puertas de enlace VPN redundantes para conmutación por error del túnel VPN
Grupo VPN, ID 1 Grupo VPN, ID 1

= Datos (Después de una conmutación por error de VPN)
= Pulsos de IKE
Grupos VPN
Un grupo VPN es un conjunto de configuraciones de túnel VPN para hasta cuatro
puertas de enlace remotas de destino. Los parámetros de asociación de seguridad
(SA) de fase 1 y fase 2 para cada túnel de un grupo pueden ser distintos o idénticos
(excepto en el caso de la dirección IP de la puerta de enlace remota, que,
lógicamente, debe ser diferente). El grupo VPN, que se muestra en la Figura 78 en
la página 303, tiene un número de ID inequívoco, y a cada miembro del grupo se le
asigna un peso inequívoco para indicar su lugar en el rango de preferencia para
convertirse en el túnel activo. Un valor de 1 constituye el rango inferior o de menor
preferencia.
302 Puertas de enlace VPN redundantes

Figura 78: Puertas de enlace remotas de destino

Grupo VPN 1 Peso
D 4
E
S 3
Supervisor
T
I
2
N
O
Nota: En esta ilustración, el sombreado simboliza el peso de cada 1
túnel. Cuanto más oscuro sea el túnel, mayor será su prioridad. S
El dispositivo de seguridad que se comunica con los miembros del grupo VPN y los
propios miembros tienen una relación supervisor/destino. El dispositivo de
supervisión supervisa continuamente la conectividad y el correcto estado de cada
dispositivo de destino. El supervisor utiliza las siguientes herramientas para ello:
Pulsos de IKE
Intentos de recuperación de IKE
Ambas herramientas se describen en la sección siguiente, “Mecanismos de

supervisión,” en la página 303.
NOTA: La relación supervisor/destino no tiene por qué ser de un solo sentido. El

dispositivo de supervisión también puede ser un miembro de un grupo VPN y, por
tanto, ser a su vez el destino de otro dispositivo de supervisión.
Mecanismos de supervisión
Dos mecanismos supervisan los miembros de un grupo VPN con el fin de
determinar su capacidad para terminar tráfico VPN:
Pulsos de IKE
Intentos de recuperación de IKE
Utilizando estas dos herramientas junto con la opción de conmutación por error de
aplicación TCP (consulte “Comprobación de indicador TCP SYN” en la página 307),
los dispositivos de seguridad pueden detectar si es necesario realizar una
conmutación por error de la VPN y desviar el tráfico al nuevo túnel sin tener que
interrumpir el servicio de VPN.

Pulsos de IKE
Los pulsos de IKE son mensajes de saludo que los interlocutores IKE se envían
mutuamente bajo la protección de una asociación de seguridad (SA) de fase 1
establecida para confirmar la conectividad y el correcto estado del otro. Por
ejemplo, si dispositivo_s (el “supervisor”) no recibe un determinado número de
pulsos (el valor predeterminado es 5) de dispositivo_d (el “destino”), dispositivo_s
llega a la conclusión de que dispositivo_d está fuera de línea. Dispositivo_s elimina
de su memoria caché las asociaciones de seguridad (SA) de fase 1 y fase 2
correspondientes y comienza el procedimiento de recuperación IKE. (Consulte
“Procedimiento de recuperación IKE” en la página 306.) Dispositivo_d también
elimina sus SA.
NOTA: La función de pulsos de IKE debe estar habilitada en los dispositivos ubicados a
ambos extremos de un túnel VPN en un grupo VPN. Si está habilitada en
dispositivo_s pero no en dispositivo_d, dispositivo_s suprime la transmisión de
pulsos de IKE y genera el siguiente mensaje en el registro de eventos: “Heartbeats
have been disabled because the peer is not sending them” (los pulsos se han
desactivado porque el interlocutor no los está enviando).
Figura 79: Flujo de pulsos IKE en ambos sentidos
Los pulsos de IKE deben fluir en ambos sentidos a través del túnel VPN.
Para definir el intervalo de pulsos de IKE y el umbral para un túnel VPN específico
(el valor predeterminado es 5), realice los siguientes pasos:
WebUI
VPN > AutoKey Advanced > Gateway > Edit (para la puerta de enlace
cuyo umbral de pulsos de IKE desee modificar) > Advanced: Introduzca los
nuevos valores en los campos “Heartbeat Hello” y “Heartbeat Threshold” y
haga clic en OK.
CLI
set ike gateway cadena_nombre heartbeat hello número
set ike gateway cadena_nombre heartbeat threshold número
Detección de interlocutor muerto

DPD es un protocolo que utilizan los dispositivos de red para verificar la existencia
actual y la disponibilidad de otros dispositivos de interlocutor.
Se puede utilizar DPD como una alternativa para la función de pulsos IKE (que se
describe anteriormente). No obstante, no se pueden utilizar ambas funciones
simultáneamente. Además, el pulso IKE puede utilizarse como un ajuste global, que
afecta todas las puertas de enlace IKE configuradas en el dispositivo. El ajuste de
pulso IKE también puede aplicarse a un contexto individual de puerta de enlace
IKE, que afecta únicamente a una sola puerta de enlace. En contraste, se puede
configurar el DPD únicamente en el contexto de una puerta de enlace individual
IDE, no como un parámetro global.

Un dispositivo realiza la verificación de DPD enviando cargas encriptadas de

notificaciones IKE de fase 1 (R-U-THERE) a los interlocutores y esperar los
reconocimientos de DPD (R-U-THERE-ACK) por parte de los interlocutores. El
dispositivo envía una petición de R-U-THERE, si y sólo si no ha recibido ningún
tráfico desde el interlocutor durante un intervalo especificado de DPD. Si un
dispositivo habilitado para DPD recibe tráfico en un túnel, éste restablece su
contador de R-U-THERE para dicho túnel, con lo que inicia un nuevo intervalo. Si el
dispositivo recibe un R-U-THERE-ACK del interlocutor durante este intervalo, se
considera al interlocutor como activo. Si el dispositivo no recibe una respuesta al
R-U-THERE-ACK durante este intervalo, se considera al interlocutor como inactivo.
Cuando el dispositivo considera que un dispositivo de interlocutor está inactivo, el

dispositivo elimina la SA de la fase 1 y todas las SA de la fase 2 para dicho
interlocutor.
Se pueden configurar los siguientes parámetros de DPD, ya sea a través de la CLI o

de la WebUI:
El parámetro interval especifica el intervalo de DPD. Este intervalo indica la

cantidad de tiempo (expresado en segundos) que permite transcurrir un
dispositivo antes de considerar como inactivo a un interlocutor.
El parámetro always-send le indica al dispositivo que envíe peticiones de DPD,

independientemente de si existe tráfico IPSec con el interlocutor.
El parámetro retry especifica el número máximo de veces que se enviará la

petición de R-U-THERE, antes de considerar como inactivo al interlocutor.
Como sucede con la configuración de pulso de IKE, el número predeterminado
de transmisiones es 5 veces, con un rango permitido de 1-128 reintentos. Un
ajuste ‘cero’ desactiva la DPD.
En el ejemplo siguiente, se crea una puerta de enlace que utiliza un intervalo de

DPD de cinco segundos.
WebUI
VPN > AutoKey Advanced > Gateway > Edit: Cree una puerta de enlace
introduciendo los siguientes valores y luego haga clic en OK.
Gateway Name: our_gateway

Remote Gateway Type: Static IP Address
IP Address/Hostname: 1.1.1.1
Preshared Key: jun9345
VPN > AutoKey Advanced > Gateway > Edit (our_gateway): Introduzca los
siguientes valores y haga clic en OK.
Predefined: Standard (seleccione)

DPD:
Interval: 5
CLI
set ike gateway “our_gateway” address 1.1.1.1 main outgoing-interface “untrust”
preshare “jun9345” sec-level standard
set ike gateway “our_gateway” dpd interval 5

Procedimiento de recuperación IKE

Después de que el dispositivo de seguridad de supervisión haya determinado que
un dispositivo de destino está fuera de línea, el supervisor deja de enviar pulsos de
IKE y elimina las SA para dicho interlocutor de su caché de SA. Tras un intervalo
definido, el supervisor intenta iniciar negociaciones de fase 1 con el interlocutor
fallido. Si el primer intento no tiene éxito, el supervisor continúa intentando
establecer negociaciones de fase 1 a intervalos regulares hasta que obtiene
resultados satisfactorios.
Figura 80: Intentos repetidos de negociación de fase 1 IKE
Intentos de
negociación de fase 1
Supervisor IKE cada 5 minutos Destino
Intervalo:
5 minutos
(300 segundos) Intento fallido
..
. . ..
.. .
Intento fallido
.. .. ..
. . .
Intento con éxito
Para definir el intervalo de recuperación IKE para un túnel VPN específico (el ajuste
mínimo es 60 segundos), realice uno de los siguientes pasos:
WebUI
VPN > AutoKey Advanced > Gateway > Edit (para la puerta de enlace
cuyo intervalo de reconexión de IKE desee modificar) > Advanced:
Introduzca el valor en segundos en el campo Heartbeat Reconnect; luego,
haga clic en OK.
CLI
set ike gateway cadena_nombre heartbeat reconnect número
Cuando el miembro con el mayor peso de un grupo VPN realiza una conmutación
por error del túnel a otro miembro del grupo y, a continuación, conecta de nuevo
con el dispositivo de supervisión, se realiza automáticamente una conmutación por
recuperación del túnel al primer miembro. El sistema de ponderación hace que la
puerta de enlace que tiene la mayor valoración del grupo se encargue siempre de
gestionar los datos VPN si es posible.
La Figura 81 en la página 307 muestra el proceso al que se somete un miembro de

un grupo VPN cuando la ausencia de pulsos de una puerta de enlace de destino
sobrepasa el umbral de fallo.

Figura 81: Conmutación por error y luego recuperación
Supervisor Destino
Pulsos IKE en ambos sentidos
El destino deja de enviar pulsos IKE.
El supervisor realiza una conmutación por error de la VPN (si el destino estaba
gestionando datos VPN), elimina las SA de fase 1 y fase 2 e intenta establecer
de nuevo el túnel VPN con los intervalos especificados.
El destino responde a la iniciación de fase 1 con pulsos IKE habilitados.
Las negociaciones de fase 1 y fase 2 IKE tienen éxito, el túnel vuelve a

estar en línea y se realiza una conmutación por recuperación de la
VPN (si su peso da preferencia a otros miembros del grupo VPN).
Comprobación de indicador TCP SYN

Para que se produzca una conmutación por error VPN gradual, es necesario
organizar la gestión de las sesiones TCP. Si, después de una conmutación por error,
la nueva puerta de enlace activa recibe un paquete durante una sesión TCP
existente, la nueva puerta de enlace lo gestiona como si fuera el primer paquete de
una sesión TCP nueva y comprueba si el indicador SYN está activado en el
encabezado del paquete. Como este paquete en realidad forma parte de una sesión
existente, no tiene el indicador SYN activado. En consecuencia, la nueva puerta de
enlace rechaza el paquete. Con la comprobación de indicador TCP SYN habilitada,
todas las aplicaciones TCP se tienen que reconectar después de que se produzca la
conmutación por error.
Para resolver este problema, puede inhabilitar la comprobación de indicador SYN

para las sesiones TCP en túneles VPN del siguiente modo:
WebUI
No es posible inhabilitar la comprobación de indicador SYN mediante la
WebUI.

CLI
unset flow tcp-syn-check-in-tunnel
NOTA: De forma predeterminada, la comprobación de indicador SYN está habilitada.
Creación de puertas de enlace VPN redundantes

En este ejemplo, un sitio corporativo tiene un túnel VPN que conecta con un centro
de datos y un segundo túnel que conecta con un centro de datos de respaldo. Todos
los datos se replican a través de una conexión de línea punto a punto entre los dos
centros de datos. Los centros de datos están separados físicamente para
proporcionar un servicio continuo, incluso en caso de fallo catastrófico, como un
corte de corriente de 24 horas o una catástrofe natural.
El nombre y la ubicación del dispositivo, las interfaces físicas y sus direcciones IP

para las zonas Trust y Untrust, y la ID de grupo VPN y el peso de cada dispositivo de
seguridad son los siguientes:
Interfaz física y Interfaz física, dirección IP,

Ubicación del Nombre del dirección IP puerta de enlace predeterminada ID de
dispositivo dispositivo (zona Trust) (zona Untrust) grupo VPN y peso
Empresa Monitor1 ethernet1, 10.10.1.1/24 ethernet3, 1.1.1.1/24, (GW) 1.1.1.2 ––
Centro de datos Destino1 ethernet1, 10.1.1.1/16 ethernet3, 2.2.2.1/24, (GW) 2.2.2.2 ID = 1, Peso = 2
(primario)
Centro de datos (de Destino2 ethernet1, 10.1.1.1/16 ethernet3, 3.3.3.1/24, (GW) 3.3.3.2 ID = 1, Peso = 1
respaldo)
NOTA: El espacio de direcciones interno en ambos centros de datos debe ser idéntico.
Todas las zonas de seguridad se encuentran en el dominio de enrutamiento trust-vr.

Todos los túneles AutoKey IKE punto a punto utilizan el nivel de seguridad
predefinido como “Compatible” para propuestas de fase 1 y fase 2. Las claves
previamente compartidas autentican a los participantes.

Figura 82: Puertas de enlace VPN redundantes

Untrust, ethernet3 Trust, ethernet1
2.2.2.1/24 10.1.1.1/16
Destino1
Ubicación del
10.1.0.0/16 centro de datos
primario
Sitio corporativo Línea punto a punto
Monitor1 para la réplica de
datos del sitio
10.10.1.0/24 Internet primario al sitio de
respaldo
Trust, ethernet1 Untrust, ethernet3

10.10.1.1/24 1.1.1.1/24 Destino2
Ubicación del
10.1.0.0/16 respaldo del
centro de datos
Untrust, ethernet3 Trust, ethernet1

3.3.3.1/24 10.1.1.1/16
WebUI (Monitor1)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Direcciones
Address Name: in_trust

Zone: Trust
Address Name: data_ctr

Zone: Untrust

3. VPN
VPNs > AutoKey Advanced > VPN Group: Introduzca 1 en el campo VPN
Group ID; luego, haga clic en Add.
y haga clic en OK:
Gateway Name: target1

Remote Gateway Type: Static IP Address: (seleccione), IP Address: 2.2.2.1
Preshared Key: SLi1yoo129

enlace:

Heartbeat:
Hello: 3 Seconds
Reconnect: 60 segundos
Threshold: 5
VPN Name: to_target1

Remote Gateway: Predefined: (seleccione), target1

IKE:
VPN Group: VPN Group-1

Weight: 2
y haga clic en OK:
Gateway Name: target2

Remote Gateway Type: Static IP Address: (seleccione), IP Address: 3.3.3.1
Preshared Key: CMFwb7oN23

enlace:

Heartbeat:
Hello: 3 Seconds
Threshold: 5

VPN Name: to_target2

Remote Gateway: Predefined: (seleccione), target2

IKE:
VPN Group: VPN Group-1

Weight: 1
4. Ruta

Gateway IP Address: 1.1.1.2(untrust)
5. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), in_trust
Address Book Entry: (seleccione), data_ctr
Service: ANY
Action: Tunnel
VPN: VPN Group-1
WebUI (destino1)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust


2. Direcciones
Address Name: in_trust

Zone: Trust
Address Name: corp

Zone: Untrust
3. VPN
y haga clic en OK:
Gateway Name: monitor1

Preshared Key: SLi1yoo129

enlace:

Heartbeat:
Hello: 3 Seconds
Name: to_monitor1
Remote Gateway: Predefined: (seleccione), monitor1
4. Ruta


5. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), in_trust
Service: ANY
Action: Zona
Tunnel VPN: monitor1
WebUI (destino2)
NOTA: Siga los pasos de configuración de destino1 para configurar destino2, pero defina
la dirección IP de la interfaz de zona Untrust como 3.3.3.1/24, la dirección IP de
puerta de enlace predeterminada como 3.3.3.2 y utilice CMFwb7oN23 para
generar la clave previamente compartida.
CLI (Monitor1)
1. Interfaces
2. Direcciones
set address trust in_trust 10.10.1.0/24
set address untrust data_ctr 10.1.0.0/16
3. VPN
set ike gateway target1 address 2.2.2.1 main outgoing-interface ethernet3
preshare SLi1yoo129 sec-level compatible
set ike gateway target1 heartbeat hello 3
set ike gateway target1 heartbeat reconnect 60
set ike gateway target1 heartbeat threshold 5
set vpn to_target1 gateway target1 sec-level compatible
set ike gateway target2 address 3.3.3.1 main outgoing-interface ethernet3
preshare CMFwb7oN23 sec-level compatible
set ike gateway target2 heartbeat hello 3
set ike gateway target2 heartbeat reconnect 60
set ike gateway target2 heartbeat threshold 5
set vpn to_target2 gateway target2 sec-level compatible
set vpn-group id 1 vpn to_target1 weight 2
set vpn-group id 1 vpn to_target2 weight 1
unset flow tcp-syn-check-in-tunnel
4. Ruta

5. Directivas
set policy top from trust to untrust in_trust data_ctr any tunnel “vpn-group 1”
set policy top from untrust to trust data_ctr in_trust any tunnel “vpn-group 1”
save
CLI (destino1)
1. Interfaces
2. Direcciones
set address trust in_trust 10.1.0.0/16
3. VPN
set ike gateway monitor1 address 1.1.1.1 main outgoing-interface ethernet3
preshare SLi1yoo129 sec-level compatible
set ike gateway monitor1 heartbeat hello 3
set ike gateway monitor1 heartbeat threshold 5
set vpn to_monitor1 gateway monitor1 sec-level compatible
4. Ruta
5. Directivas
set policy top from trust to untrust in_trust corp any tunnel vpn to_monitor
set policy top from untrust to trust corp in_trust any tunnel vpn to_monitor
save
CLI (destino2)
NOTA: Siga los pasos de configuración de destino1 para configurar destino2, pero defina
la dirección IP de la interfaz de zona Untrust como 3.3.3.1/24, la dirección IP de
puerta de enlace predeterminada como 3.3.3.2 y utilice CMFwb7oN23 para
generar la clave previamente compartida.
Creación de VPN adosadas

Puede aplicar directivas interzonales en el lado del concentrador para el tráfico que
circule de un túnel VPN a otro ubicando los puntos radiales en zonas diferentes.
Como se encuentran en zonas distintas, el dispositivo de seguridad del
concentrador debe realizar una consulta de directivas antes de enrutar el tráfico de
un túnel a otro. Se puede controlar el tráfico que circule a través de los túneles VPN
entre los puntos radiales. Esta configuración se denomina VPN adosadas.
NOTA: De forma opcional, puede habilitar un bloqueo intrazonal y definir una directiva
intrazonal para controlar el tráfico entre las dos interfaces de túnel dentro de la
misma zona.
314 Creación de VPN adosadas

Figura 83: VPN adosadas
Zona X1
Zona X2
Red radial A Red radial B
VPN1 VPN2
Consulta
de
directivas
Concentrador
A continuación se mencionan algunas ventajas de las VPN adosadas:
Puede conservar el número de VPN que necesite crear. Por ejemplo, el punto de
perímetro A puede enlazar con el concentrador y los puntos de perímetro B, C,
D, etc., pero A sólo tiene que configurar un túnel VPN. Especialmente para
usuarios de NetScreen-5XP, que pueden utilizar un máximo de diez túneles
VPN de forma simultánea, aplicar el método radial aumenta de manera
significativa las opciones y capacidades VPN.
El administrador (admin) del dispositivo concentrador puede controlar

completamente el tráfico VPN entre los puntos de perímetro. Por ejemplo:
El administrador puede permitir sólo la circulación de tráfico HTTP desde A

hasta B, pero permitir la circulación de cualquier tipo de tráfico desde B
hasta A.
El administrador puede permitir el acceso a C del tráfico procedente de A,

pero denegar el acceso a A del tráfico procedente de C.
El administrador puede permitir a un host concreto de A el acceso a toda la

red D y, al mismo tiempo, permitir sólo a un host concreto de D acceder a
otro host distinto en A.
El administrador del dispositivo concentrador puede controlar completamente

el tráfico saliente de todas las redes del perímetro. En cada punto de perímetro
debe existir primero una directiva que dirija todo el tráfico de salida a través de
las VPN radiales hasta el concentrador; por ejemplo: set policy top from trust
to untrust any any any tunnel vpn cadena_nombre (donde cadena_nombre
define el túnel VPN específico que conecta cada punto de perímetro con el
concentrador). En el concentrador, el administrador puede controlar el acceso a
Internet, permitiendo cierto tipo de tráfico (por ejemplo, sólo HTTP), realizando
bloqueos de URL o sitios web no deseables, etc.
Se pueden utilizar concentradores regionales y túneles interconectados

mediante radios, permitiendo que los puntos de radio de una región accedan a
los puntos de radio de otra.
Creación de VPN adosadas 315

El ejemplo siguiente es parecido al descrito en “Creación de VPN radiales” en la

página 321, excepto en un detalle: el dispositivo de seguridad del lado del
concentrador en Nueva York realiza una comprobación de directivas en el tráfico
que enruta entre los dos túneles con destino a las sucursales de Tokio y París.
Colocando cada sitio remoto en una zona distinta, se controla el tráfico VPN en el
concentrador.
La dirección LAN de Tokio se encuentra en la zona definida por el usuario X1, y la

dirección LAN de París se encuentra en la zona definida por el usuario X2. Ambas
zonas se encuentran en el dominio de enrutamiento Trust-VR.
NOTA: Para crear zonas definidas por el usuario, primero se debería adquirir y cargar una
clave de software de zona en el dispositivo de seguridad.
El túnel VPN1 se asocia a la interfaz tunnel.1, y el túnel VPN2 se asocia a la interfaz

tunnel.2. Aunque no se asignan direcciones IP a las interfaces de zona X1 y X2, se
asignan direcciones a ambas interfaces de túnel. Las rutas para estas interfaces
aparecen automáticamente en la tabla de enrutamiento Trust-VR. Colocando la
dirección IP de una interfaz de túnel en la misma subred que la de destino, el
tráfico destinado a dicha subred se enruta a la interfaz de túnel.
La interfaz de salida es ethernet3, que está asociada a la zona Untrust. Como puede
ver en la Figura 84, ambos túneles terminan en la zona Untrust; sin embargo, los
puntos finales para el tráfico que utiliza estos túneles se encuentran en las zonas X1
y X2. Los túneles utilizan AutoKey IKE con claves previamente compartidas. Hay
que seleccionar el nivel de seguridad predefinido como “Compatible” para ambas
propuestas de fase 1 y fase 2. La zona Untrust se asocia a untrust-vr. Como los
túneles están basados en rutas (es decir, el túnel correcto se determina por el
enrutamiento, no por un nombre de túnel especificado en una directiva), las ID de
proxy se incluyen en la configuración de cada túnel.
Figura 84: VPN adosadas con dos dominios de enrutamiento y múltiples zonas de seguridad
Puerta de enlace Tokio (radio)
predeterminada 110.1.1.1
IP 123.1.1.2 París (radio)
Nueva York 220.2.2.2
Interfaz de salida Dominio de
Zona Untrust enrutamiento
Dominio de ethernet3, IP 123.1.1.1/24 VPN1 Untrust-VR
enrutamiento
Trust-VR Interfaz: VPN2
tunnel.1
10.10.1.2/24
Sede central en
Nueva York LAN de Tokio
(concentrador) Zona X1
10.10.1.0/24
Consulta
Zona Trust de
directivas
LAN de París
Zona X2 10.20.1.0/24
Interfaz:
ethernet1 tunnel.2
10.1.1.1/24 10.20.1.2/24

WebUI
1. Zonas de seguridad y enrutadores virtuales
haga clic en OK:
Manage IP: 0.0.0.0
haga clic en OK:
Zone Name: Null
Network > Zones > Edit (para Untrust): Introduzca los siguientes datos y haga
clic en OK:

Zone Name: X1
Zone Name: X2
2. Interfaces
haga clic en OK:
Zone Name: Untrust

clic en OK:

Zone (VR): X1 (trust-vr)
clic en OK:

Zone (VR): X2 (trust-vr)

3. VPN para la oficina de Tokio

VPN Name: VPN1

Gateway Name: Tokio

IKE:
Service: ANY
NOTA: Para configurar el túnel VPN en el dispositivo de seguridad que protege las oficinas
de Tokio y París, ejecute uno de estos procedimientos:
(VPN basada en rutas) Seleccione la casilla de verificación Enable Proxy-ID y

escriba 10.10.1.0/24 (Tokio) y 10.20.1.0/24 (París) para Local IP/Netmask,
y 10.20.1.0/24 (Tokio) y 10.10.1.0/24 (París) para Remote IP/Netmask.
(VPN basada en directivas) Realice una entrada en la libreta de direcciones de la

zona Trust para 10.10.1.0/24 (Tokio) y 10.20.1.0/24 (París), y otra en la libreta de
direcciones de la zona Untrust para 10.20.1.0/24 (Tokio) y 10.10.1.0/24 (París).
Utilícelas como direcciones de origen y destino en la directiva relativa al túnel VPN
al sitio del concentrador (hub).
4. VPN para la oficina de París

VPN Name: VPN2

Gateway Name: París

IKE:
Service: ANY

5. Rutas

Next Hop Virtual Router Name: (seleccione), untrust-vr
Network > Routing > Routing Entries > untrust-vr New: Introduzca los

6. Direcciones
Address Name: Tokio LAN

Zone: X1
Address Name: LAN de París

Zone: X2
7. Directivas
Policy > (From: X1, To: X2) New: Introduzca los siguientes datos y haga clic
en OK:
Source Address:
Address Book Entry: (seleccione), Tokio LAN
Address Book Entry: (seleccione), Paris LAN
Service: ANY
Action: Permit
Policy > (From: X2, To: X1) New: Introduzca los siguientes datos y haga clic
en OK:
Source Address:
Address Book Entry: (seleccione), Paris LAN
Address Book Entry: (seleccione), Tokio LAN
Service: ANY
Action: Permit

CLI
set zone untrust block
set zone name x1
set zone x1 vrouter trust-vr
set zone x1 block
set zone name x2
set zone x2 vrouter trust-vr
set zone x2 block
2. Interfaces
set interface tunnel.1 zone x1
set interface tunnel.2 zone x2
set ike gateway Tokio address 110.1.1.1 outgoing-interface ethernet3 preshare
set vpn VPN1 gateway Tokio sec-level compatible
set vpn VPN1 bind interface tunnel.1
set vpn VPN1 proxy-id local-ip 10.20.1.0/24 remote-ip 10.10.1.0/24 any
NOTA: Para configurar el túnel VPN en el dispositivo de seguridad que protege las oficinas
de Tokio y París, ejecute uno de estos procedimientos:
(VPN basada en rutas) Introduzca los siguientes comandos: set vpn VPN1
proxy-id local-ip 10.20.1.0/24 remote-ip 10.10.1.0/24 (Tokio) y set vpn VPN1
proxy-id local-ip 10.10.1.0/24 remote-ip 10.20.1.0/24 (París).
(VPN basada en directivas) Realice una entrada en la libreta de direcciones de la

zona Trust para 10.10.1.0/24 (Tokio) y 10.20.1.0/24 (París), y otra en la libreta de
direcciones de la zona Untrust para 10.20.1.0/24 (Tokio) y 10.10.1.0/24 (París).
Utilícelas como direcciones de origen y destino en las directivas relativas al túnel
VPN al sitio del concentrador (hub).

set ike gateway Paris address 220.2.2.2 outgoing-interface ethernet3 preshare
set vpn VPN2 gateway Paris sec-level compatible
5. Rutas
set vrouter untrust-vr route 0.0.0.0/0 interface ethernet3 gateway 123.1.1.2
6. Direcciones
set address x1 “Tokio LAN” 10.10.1.0/24
set address x2 “Paris LAN” 10.20.1.0/24

7. Directivas
set policy top from x1 to x2 “Tokio LAN” “Paris LAN” any permit
set policy top from x2 to x1 “Paris LAN” “Tokio LAN” any permit
save
NOTA: Puede hacer caso omiso al siguiente mensaje, que aparece porque las interfaces
de túnel están en modo NAT:
Warning (Advertencia): Some interfaces in the nombre_zona zone are in NAT

mode. Traffic might not pass through them!
Creación de VPN radiales

Si crea dos túneles VPN que terminen en un dispositivo de seguridad, puede
configurar un par de rutas para que el dispositivo de seguridad dirija el tráfico que
salga de un túnel hacia el otro. Si ambos túneles están incluidos en la misma zona,
no es necesario crear una directiva para permitir que el tráfico pase de un túnel a
otro. Sólo es necesario definir las rutas. Esta configuración se denomina VPN radial.
También es posible configurar VPN múltiples en una zona y enrutar el tráfico entre
dos túneles cualesquiera.
Figura 85: Túneles múltiples en una configuración de VPN radial
Zona Untrust
Túneles VPN radiales múltiples
El dispositivo de seguridad enruta el tráfico

entre túneles.
En este ejemplo, dos sucursales de Tokio y París se comunican entre sí a través de

un par de túneles VPN (VPN1 y VPN2). Cada túnel tiene su punto de origen en el
sitio remoto y termina en la sede central de Nueva York. El dispositivo de seguridad
de la sede central enruta el tráfico que sale de un túnel hacia el otro.
Inhabilitando el bloqueo intrazonal, el dispositivo de seguridad de la sede central

sólo tiene que hacer una consulta de rutas (no una consulta de directivas) para
dirigir el tráfico de un túnel a otro porque ambos puntos finales remotos se
encuentran en la misma zona (zona Untrust).
NOTA: De forma opcional, puede mantener el bloqueo intrazonal habilitado y definir una
directiva intrazonal que permita el tráfico entre las dos interfaces de túnel.
Creación de VPN radiales 321

Los túneles se asocian a las interfaces de túnel (tunnel.1 y tunnel.2), que están sin
numerar. Los túneles utilizan AutoKey IKE con claves previamente compartidas.
Hay que seleccionar el nivel de seguridad predefinido como “Compatible” para
ambas propuestas de fase 1 y fase 2. La zona Untrust se asocia a untrust-vr. La
interfaz de zona Untrust es ethernet3.
NOTA: La siguiente configuración es aplicable a VPN basadas en rutas. Si configura VPN

radiales basadas en directivas, debe utilizar las zonas Trust y Untrust en las
directivas; no puede utilizar zonas de seguridad definidas por el usuario.
Figura 86: VPN radiales

Zona Untrust Dominio de enrutamiento untrust-vr
Interfaz Puerta de enlace

predeterminada Tokio 2.2.2.2
de salida (radio)
ethernet3 IP 1.1.1.250
IP 1.1.1.1 LAN de Tokio
Internet 10.2.2.0/24
VPN1
París 3.3.3.3
VPN2 (radio)
Nueva York: sede central Interfaz: LAN de París
(concentrador) tunnel.1 10.3.3.0/24
Interfaz:
tunnel.2
WebUI (Nueva York)

haga clic en OK:
Manage IP: 0.0.0.0
haga clic en OK:
Zone Name: Null
clic en OK:

Block Intra-Zone Traffic: (anule la selección)
2. Interfaces
haga clic en OK:
Zone Name: Untrust

322 Creación de VPN radiales

clic en OK:

Zone (VR): Untrust (untrust-vr)
Interface: ethernet3 (untrust-vr)
clic en OK:

VPN Name: VPN1

Gateway Name: Tokio

IKE:
Service: ANY
VPN Name: VPN2

Gateway Name: París

IKE:
Service: ANY

5. Rutas

Interface: tunnel.1

Interface: tunnel.2

WebUI (Tokio)
haga clic en OK:
Manage IP: 0.0.0.0
haga clic en OK:
Zone Name: Null
clic en OK:

2. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT

haga clic en OK:
Zone Name: Untrust

clic en OK:

3. Dirección
Address Name: París

Zone: Untrust
4. VPN
VPN Name: VPN1

Gateway Name: Nueva York

IKE:
Service: ANY
5. Rutas




Interface: tunnel.1
6. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Paris
Service: ANY
Action: Permit
WebUI (París)
haga clic en OK:
Manage IP: 0.0.0.0
haga clic en OK:
Zone Name: Null
clic en OK:

2. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT

haga clic en OK:
Zone Name: Untrust

clic en OK:

3. Dirección
Address Name: Tokio

Zone: Untrust
4. VPN
VPN Name: VPN2

Gateway Name: Nueva York

IKE:
Service: ANY
5. Rutas




Interface: tunnel.1
6. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Tokio
Service: ANY
Action: Permit
CLI (Nueva York)

unset zone untrust block
2. Interfaces
set ike gateway Tokio address 2.2.2.2 outgoing-interface ethernet3 preshare
set vpn VPN1 gateway Tokio sec-level compatible
set ike gateway Paris address 3.3.3.3 outgoing-interface ethernet3 preshare
set vpn VPN2 gateway Paris sec-level compatible

5. Rutas
set vrouter untrust-vr route 10.2.2.0/24 interface tunnel.1
save
CLI (Tokio)
2. Interfaces
3. Dirección
set address untrust Paris 10.3.3.0/24
4. VPN
set ike gateway “Nueva York” address 1.1.1.1 outgoing-interface ethernet3
preshare netscreen1 sec-level compatible
set vpn VPN1 gateway “Nueva York” sec-level compatible
5. Rutas
6. Directivas
set policy from trust to untrust any Paris any permit
set policy from untrust to trust Paris any any permit
save
CLI (París)
2. Interfaces

3. Dirección
set address untrust Tokio 10.2.2.0/24
4. VPN
set ike gateway “Nueva York” address 1.1.1.1 outgoing-interface ethernet3
preshare netscreen2 sec-level compatible
set vpn VPN2 gateway “Nueva York” sec-level compatible
5. Rutas
6. Directivas
set policy from trust to untrust any Tokio any permit
set policy from untrust to trust Tokio any any permit
save

Capítulo 8
Redes privadas virtuales de
AutoConnect
Este capítulo describe la función (AC-VPN) de red privada virtual de AutoConnect en

ScreenOS, explica cómo funciona en una topología de red radial y proporciona un
ejemplo de configuración de un escenario típico en el cual se puede utilizar.
Vista general
Las organizaciones de empresas pequeñas que aseguran sus sitios satélites remotos
con los túneles de red privada virtual (VPN) suelen interconectar todos los sitios en
una VPN de malla completa, ya que los sitios remotos se deben comunicar entre sí,
al igual que con las oficinas centrales. En este tipo de red, generalmente los sitios
remotos ejecutan dispositivos de seguridad finales de pocas prestaciones que
admiten un máximo de 25 túneles VPN. Sin embargo, cuando la cantidad total de
sitios es superior a 25, la empresa debe colocar dispositivos de seguridad con
mayor capacidad en sus sitios remotos (a un costo considerable) o cambiar de una
topología de malla completa a una red radial.
Una configuración radial soluciona el problema de escalabilidad, pero su resultado

fundamental es que toda la comunicación entre las redes radiales debe pasar por el
concentrador. Esto por lo general, no es un problema cuando el tráfico consta de
pocos datos, incluso con más de mil redes radiales. Sin embargo, si el tráfico es de
vídeo o de voz sobre protocolo de Internet (VoIP), la carga máxima de
procesamiento en el concentrador puede ocasionar latencia, un problema serio
para estas aplicaciones.
AC-VPN le proporciona un método para configurar su red radial, de manera que las
redes radiales puedan crear túneles VPN de forma dinámica, directamente entre sí,
según sea necesario. Esto no sólo resuelve el problema de latencia entre las redes
radiales sino también reduce el gasto de procesamiento en el concentrador,
mejorando todo el funcionamiento de la red. Adicionalmente, debido a que AC-VPN
crea túneles de forma dinámica, que tienen un tiempo de espera cuando el tráfico
se detiene para fluir a través de los mismos, los administradores de la red se liberan
de la tarea de mantener una red compleja de túneles VPN estáticos, que exige
mucho tiempo de trabajo.
Vista general 331

Cómo funciona
AC-VPN está diseñada para implementarse en una red radial, donde todas las redes
radiales están conectadas al concentrador por medio de los túneles VPN. Después
de configurar un túnel VPN estático entre el concentrador y cada una de las redes
radiales, configure la AC-VPN en el concentrador y las redes radiales, y luego
habilite el protocolo de resolución de siguiente salto (NHRP). El concentrador utiliza
NHRP para obtener un rango de información sobre cada red radial, incluso sobre
sus asignaciones de direcciones públicas y privadas, longitud de la máscara de
subred y enrutamiento e información de recuento de saltos, que el concentrador
guarda en caché. Luego, cuando alguna red radial comienza a comunicarse con otra
red radial (a través del concentrador), el concentrador utiliza esta información,
junto con la información obtenida a través de la configuración de AC-VPN de las
redes radiales, para habilitar las redes radiales para configurar un túnel AC-VPN
entre dichas redes. Mientras se negocia el túnel, la comunicación continúa fluyendo
entre las dos redes radiales a través del concentrador. Cuando el túnel dinámico se
activa, el concentrador se desconecta y el tráfico fluye directamente entre las dos
redes radiales. Cuando el tráfico deja de fluir a través del túnel dinámico, el túnel
entra a tiempo de espera.
Mensajes NHRP
En el contexto de NHRP, el concentrador que está en una red radial se conoce como
servidor de siguiente salto (NHS) y la red radial se llama cliente de siguiente salto
(NHC). La comunicación NHRP entre NHS y NHC se lleva a cabo a través de un
intercambio formal de mensajes NHRP. El protocolo de resolución de siguiente salto
(RFC 2332) de acceso múltiple sin difusión (NBMA) define siete mensajes de NHRP.
A estos siete mensajes, ScreenOS agrega dos más. Estos nueve mensajes y su
funcionamiento en una red radial AC-VPN se definen de la siguiente manera:
Petición de registro: Después de que un túnel VPN estático se active entre un

NHC y su NHS, el NHC envía un mensaje de petición de registro NHRP a NHS.
El mensaje contiene varias entradas de información del cliente (CIE), que
incluyen datos como las asignaciones de direcciones públicas y privadas de
NHC, longitud de máscara de subred e información de recuento de saltos y
enrutamiento.
NOTA: En la implementación actual de ScreenOS, NHRP no redistribuye ninguna ruta a

sus interlocutores y BGP y OSPF no redistribuyen las rutas NHRP a sus
interlocutores.
Respuesta de registro: El NHS puede responder a una petición de registro con

ACK o NAK. Si el NHS no reconoce el paquete, no se emite una confirmación de
recibido (NAK) por el paquete y éste se descarta. Tras la realizacion satisfactoria
del registro, el NHS guarda en caché las CIE que están en la petición de registro
y envía un ACK de respuesta de registro.
332 Cómo funciona

Capítulo 8: Redes privadas virtuales de AutoConnect
Petición de resolución, Respuesta de resolución: Con la introducción de los

mensajes de Resolution-ack y Resolution-set de propiedad de ScreenOS, la
función del par de mensajes de petición de resolución de NHRP y respuesta de
resolución queda relegado para guardar en caché las CIE en el NHS actual. Los
NHC hacen esto junto con el tiempo de espera configurado en el NHS, que
especifica la duración de las entradas guardadas en caché por cada NHC. Para
garantizar que el NHS cuenta con la información actual sobre sus subredes, los
NHC envían periódicamente mensajes de petición de resolución al NHS. Si se
ha agregado o eliminado algún dispositivo de sus subredes, esa información se
encuentran en el mensaje de petición de resolución y el NHS actualiza su caché
y envía una respuesta de resolución.
Petición de eliminación, Respuesta de eliminación: Cuando un

administrador apaga un NHC, el dispositivo envía un mensaje de petición de
eliminación al NHS. Al recibir la petición de eliminación, el NHS elimina todas
las entradas guardadas en caché para ese NHC y envía una respuesta de
eliminación. Si el NHC experimenta un fallo en el sistema y se desconecta, el
NHS elimina las entradas guardadas en caché para el dispositivo después de
que expire la duración configurada para la caché.
Indicación de error: Este mensaje registra las condiciones de error de NHRP.
Para admitir AC-VPN, ScreenOS agrega el siguiente par de mensajes:
Resolution-set, Resolution-ack: Cuando el NHS detecta el tráfico de un túnel

VPN estático a otro, éste envía mensajes de Resolution-set a los NHC al final de
cada túnel estático. Estos mensajes contienen toda la información que cada
NHC necesita saber sobre el otro para configurar un túnel AC-VPN. Cuando el
NHC responde con mensajes de Resolution-ack, el NHS dirige uno de los NHC
para iniciar la negociación del túnel AC-VPN.
Iniciación del túnel AC-VPN

La Figura 87 ilustra cómo ScreenOS activa la configuración de un túnel AC-VPN con
los mensajes de petición de registro y respuesta de registro de NHRP, y los mensajes
personalizados de Resolution-set y Resolution-ack de ScreenOS. Para la
simplificación, la figura no muestra el intercambio de mensajes de petición de
resolución y respuesta de resolución, ni de los mensajes de eliminación y error. (Las
abreviaturas RR1 y RR2 se refieren a la red radial 1 y red radial 2 respectivamente,
D1 y D2 se refieren a los destinos situados detrás de esas redes radiales.)
Cómo funciona 333

Figura 87: Configuración de AC-VPN a través de NHRP
NHC - Red radial 1 NHS - Concentrador NHS - Red radial
1. RR1 entra en línea

Petición de registro
2.
(envía subredes protegidas, hash self-cert, ID local)
Respuesta de registro
3.
RR2 entra en línea 4.
(envía perfil AC-VPN)
Petición de registro
5.
(envía subredes protegidas, hash self-cert, ID local)
Respuesta de registro
6.
(envía perfil AC-VPN)
D1 tras RR1 envía nuevo tráfico a D2 tras RR2 El concentrador reenvía el tráfico a RR2
7.
El concentrador envía Resolution-set con detalles de RR1
8.
RR2 envía Resolution-ack
9.
El concentrador envía Resolution-set con detalles de RR2
10.
RR1 envía Resolution-ac

11.
RR1 inicia túnel AC-VPN con RR2

12.
El tráfico entre D1 y D2 fluye entre RR1 y RR2 en el túnel AC-VPN
Configuración de AC-VPN
Se aplican las siguientes restricciones generales:
Todos los túneles VPN configurados en el concentrador, se deben basar en

rutas.
La administración automática de claves en la fase 1 debe estar en el modo

dinámico.
El método de autenticación debe ser por medio de un certificado autofirmado y

genérico PKI.
Todas las redes radiales se deben conectar a una zona individual en el

concentrador.
La configuración de NHRP en varias instancias de enrutadores virtuales es

admitida sólo en el NHS.
334 Cómo funciona

El registro de NHC a NHS admite los protocolos de enrutamiento dinámico. Al

configurar las redes radiales, usted debe utilizar el comando set protocol nhrp
cache dir_ip/máscara para agregar rutas.
Traducción de direcciones de red

Las siguientes restricciones aplican con NAT:
Nat-Traversal: AC-VPN puede crear un túnel dinámico entre dos redes radiales,
si una de las redes está detrás de un dispositivo NAT en la ruta hacia el
concentrador; si ambas redes radiales están detrás de los dispositivos NAT, pero
no se creará un túnel dinámico y la comunicación entre las redes radiales
continuará a través del concentrador. Consulte NAT-Traversal en la página 240
para obtener más información sobre NAT-Traversal.
La traducción NAT es compatible únicamente con las direcciones del protocolo

de Internet asignado (MIP).
La traducción de direcciones de puerto (PAT) sólo se admite entre una red radial
y el concentrador. Por ejemplo, puede tener un dispositivo NAT entre una red
radial y el concentrador y se puede crear un túnel dinámico entre esa red radial
y otra red radial, siempre y cuando no exista un dispositivo NAT entre esa otra
red radial y el concentrador. En este escenario, el concentrador forzará la red
radial detrás del dispositivo de NAT para iniciar el túnel hacia otra red radial.
La PAT se admite directamente enfrente del concentrador.
No se admite la PAT entre las redes radiales.
Configuración en el concentrador
La configuración de la red radial incluye lo siguiente:
1. Crear una puerta de enlace estática y VPN.
2. Crear túneles estáticos en las redes radiales y conectar las VPN a los túneles.
3. Crear un perfil de puerta de enlace de AC-VPN.
4. Crear un perfil de VPN de AC-VPN.
5. Habilitar NHRP en el enrutador virtual.
6. Seleccione ACVPN-Perfil para NHRP.
7. Habilitar NHRP en la interfaz del túnel.
8. Configurar el enrutamiento.
Configuración en cada red radial

El concentrador incluye lo siguiente:
1. Crear un túnel estático hacia el enrutador.
2. Crear una puerta de enlace.
Cómo funciona 335

3. Crear una puerta de enlace de VPN.
4. Crear una puerta de enlace de ACVPN-dinámica.
5. Crear una VPN de ACVPN-dinámica.
6. Habilitar NHRP en el enrutador virtual.
7. Configurar la dirección IP de NHS.
8. Configurar la caché local.
9. Habilitar NHRP en la interfaz del túnel.
10. Configurar el enrutamiento.
Ejemplo
En este ejemplo, un dispositivo de seguridad final de altas prestaciones, que actúa
como el concentrador en una red radial, está configurado para actuar como el
servidor de siguiente salto (NHS) en una configuración AC-VPN, en la que
red_radial1 y red_radial2 (dispositivos de seguridad finales de bajas prestaciones)
son clientes de siguiente salto (NHC). Después de configurar las interfaces en los
dispositivos, configurará los túneles VPN estáticos entre el concentrador y cada una
de las redes radiales, luego configure la AC-VPN y habilite NHRP en las interfaces de
conexión. Aunque este ejemplo utiliza el protocolo de enrutamiento de abrir
primero la ruta más corta (OSPF), ScreenOS admite todos los protocolos de
enrutamiento dinámico con AC-VPN.
NOTA: AC-VPN también admite el protocolo de control de host dinámico (DHCP).
336 Cómo funciona

10.1.1.0/24
Concentrador
t.1--10.0.0.2 e2/1--1.1.1.1
Internet
t.1--10.0.0.2 e0/0--2.2.2.1/24 e0/0--3.3.3.1 t.1--10.0.0.3/24

Red radial--1 Red radial--2
Túnel dinámico
10.1.2.0/24 10.1.3.0/24
WebUI (concentrador)
NOTA: Después de configurar las puertas de enlace estáticas y las VPN estáticas del
concentrador a las redes radiales y de las redes radiales al concentrador, puede
utilizar el asistente de AC-VPN para completar la configuración de AC-VPN.
1. Interfaces
Zone Name: Untrust

Zone Name: Trust

Interface Mode: NAT
Cómo funciona 337

Network > Interfaces > New (Tunnel IF): Introduzca los siguientes datos y
haga clic en Apply:

Zone (VR): Trust-vr
Fixed IP
Unnumbered
Interface:
NHRP Enable: (Seleccione)
2. Configure los túneles en red_radial1 y red_radial2
VPN > AutoKey Advanced > Gateway > New: Configure la puerta de enlace de
IKE, haga clic en Advanced y establezca el nivel de seguridad, luego haga clic
en Return para regresar a la página de configuración de la puerta de enlace IKE
y haga clic en OK:
Gateway Name: Red_radial1

Remote Gateway: (Seleccione)
Static IP Address: (Seleccione) IPvc4/v6 Address/Hostname: 2.2.2.1
Preshare key: Juniper

Outgoing interface: (seleccione) ethernet2/1
y haga clic en OK:
Gateway Name: Red_radial2


3. Configure la red radial de VPN en la puerta de enlace
VPN > AutoKey IKE > New: Configure la puerta de enlace de IKE, haga clic
en Advanced y establezca el nivel de seguridad, luego haga clic en Return para
regresar a la página de configuración de la puerta de enlace IKE y haga clic
en OK:
VPN Name: red_radial1

Remote Gateway: (seleccione) Predefined
(seleccione el nombre de puerta de enlace correcto de la lista predefinida del
menú desplegable)
Security Level (seleccione) Standard
Bind To: (seleccione) Tunnel Interface
(seleccione Tunnel.1 del menú desplegable)
338 Cómo funciona

en OK:
VPN Name: red_radial2

menú desplegable)

4. Configure ACVPN-Perfil
y haga clic en OK:
Gatewary Name: ac-spoke-gw

ACVPN-Profile: (seleccione)
Security Level: (seleccione) Standard
VPN > AutoKey IKE > New: Configure el perfil de ACVPN, haga clic
en Advanced y establezca el nivel de seguridad y la Protección de respuesta,
luego haga clic en Return para regresar a la página de configuración de VPN y
haga clic en OK
VPN Name: ac-vpn

ACVPN-Profile: (seleccione)
Binding to tunnel: (seleccione) ac-spoke-gw
Security Level: (seleccione) Standard

Replay Protection: (seleccione)
5. Configure el vrouter
Network > Routing > Virtual Router > (para el trust-vr) Edit: Introduzca los
Next Hop Resolution Protocol(NHRP) Support

NHRP: (seleccione) NHRP Setting
NHS Setting: (seleccione)
Profile: (seleccione) ACVPN-Profile name
6. Habilite NHRP en la interfaz del túnel
Network > Interfaces > New (para TunnelIF): Introduzca los siguientes datos y
haga clic en Apply:

NHRP Enable: (seleccione)
Cómo funciona 339

7. Configure el enrutamiento
haga clic en Apply:
IP Address/netmask: 0.0.0.0
Gateway (seleccione)
CLI (concentrador)
set interface ethernet2/1 zone Untrust
set interface ethernet2/2 zone Trust
set interface tunnel.1 zone Trust

set ike gateway red_radial2 address 3.3.3.1 Main outgoing-interface ethernet2/1
preshare juniper== sec-level standard
set ike gateway red_radial1 address 2.2.2.1 Main outgoing-interface ethernet2/1
set vpn red_radial2 gateway red_radial2 no-replay tunnel idletime 0 sec-level

standard
set vpn red_radial2 id 1 bind interface tunnel.1
set vpn red_radial1 gateway red_radial1 no-replay tunnel idletime 0 sec-level
standard
set vpn red_radial1 id 2 bind interface tunnel.1
set ike gateway ac-spoke-gw acvpn-profile sec-level standard

set vpn ac-vpn acvpn-profile ac-spoke-gw no-replay tunnel idletime 0 sec-level
standard
set vrouter trust-vr

set protocol nhrp
set protocol nhrp acvpn-profile ac-vpn
exit
set interface tunnel.1 protocol nhrp enable
set vr trust protocol ospf

set vr trust protocol ospf enable
set vr trust protocol ospf area 10
set interface ethernet2/2 protocol ospf area 0.0.0.10
set interface ethernet2/2 protocol ospf enable
set interface tunnel.1 protocol ospf area 0.0.0.0
set interface tunnel.1 protocol ospf link-type p2mp
set interface tunnel.1 protocol ospf enable
set route 0.0.0.0/0 gateway 1.1.1.2
340 Cómo funciona

WebUI (Red_radial1)
1. Interfaces
Zone Name: Untrust

Network > Interfaces > Edit (para bgroup0): Introduzca los siguientes datos y
haga clic en Apply:
Zone Name: Trust
Zone Name: Trust

Interface Mode: NAT
Network > Interfaces > Edit (para ethernet2/2), Seleccione Bind Port, ingrese
lo siguiente, luego haga clic en Apply:
ethernet0/2 bgroup0: (seleccione) Bind to Current Bgroup
haga clic en Apply:

Zone (VR): Trust-vr
Fixed IP
2. Configure el túnel en el concentrador
y haga clic en OK:
Gateway Name: hub-gw


Cómo funciona 341


en OK:
VPN Name: vpn-hub

menú desplegable)

4. Configure ACVPN-Dinámica
y haga clic en OK:
Gatewary Name: ac-hub-gw

ACVPN-Dynamic: (seleccione)
VPN > AutoKey > New: Introduzca los siguientes datos y haga clic en OK:
VPN Name: ac-hub-vpn

Gateway (seleccione): ac-hub-gw
Tunnel Towards Hub: (seleccione) vpn-hub
5. Configure el enrutador virtual
Next Hop Resolution Protocol (NHRP) Support

NHC Setting: (seleccione)
NHS IP Address: 10.1.1.1
haga clic en Apply:

haga clic en Apply:
342 Cómo funciona

CLI (Red_radial1)
set interface bgroup0 zone Trust

set interface bgroup0 ip 10.1.2.1/24
set interface bgroup0 nat
set ike gateway hub-gw address 1.1.1.1 Main outgoing-interface ethernet0/0

set vpn vpn-hub id 1 bind interface tunnel.1
set ike gateway ac-hub-gw acvpn-dynamic

set vpn ac-hub-vpn acvpn-dynamic ac-hub-gw vpn-hub

set protocol nhrp
set protocol nhrp nhs 10.0.0.1
set protocol nhrp cache 10.1.2.0/24
exit

set interface bgroup0 protocol ospf area 0.0.0.20
set interface bgroup0 protocol ospf enable
WebUI (Red_radial2)
1. Interfaces
Zone Name: Untrust

Network > Interfaces > Edit (para bgroup0): Introduzca los siguientes datos y
haga clic en Apply:
Zone Name: Trust
Zone Name: Trust

Interface Mode: NAT
Cómo funciona 343

Network > Interfaces > Edit (para ethernet2/2), seleccione Bind Port, ingrese
lo siguiente, luego haga clic en Apply:
ethernet0/2 bgroup0: (seleccione) Bind to Current Bgroup
haga clic en Apply:

Zone (VR): Trust-vr
Fixed IP
2. Configure el túnel en el concentrador
y haga clic en OK:
Gateway Name: hub-gw


en OK:
VPN Name: vpn-hub

menú desplegable)

4. Configure ACVPN-Dinámica
y haga clic en OK:
Gatewary Name: ac-hub-gw

VPN > AutoKey > New: Introduzca los siguientes datos y haga clic en OK:
VPN Name: ac-hub-vpn

Gateway (seleccione): ac-hub-gw
Tunnel Towards Hub: (seleccione) vpn-hub
344 Cómo funciona

5. Configure el vrouter
Next Hop Resolution Protocol(NHRP) Support

NHC Setting: (seleccione)
NHS IP Address: 1.1.1.1
haga clic en Apply:

haga clic en Apply:
CLI (Red_radial2)
set interface bgroup0 zone Trust

set interface bgroup0 ip 10.1.3.1/24
set interface bgroup0 nat
set ike gateway hub-gw address 1.1.1.1 Main outgoing-interface ethernet0/0

set vpn vpn-hub id 1 bind interface tunnel.1
set ike gateway ac-hub-gw acvpn-dynamic
set vpn ac-hub-vpn acvpn-dynamic ac-hub-gw vpn-hub

set protocol nhrp
set protocol nhrp nhs 10.0.0.1
set protocol nhrp cache 10.1.3.0/24
exit
Cómo funciona 345


set interface bgroup0 protocol ospf area 0.0.0.30
set interface bgroup0 protocol ospf enable
346 Cómo funciona

Índice
Numerics conjuntos de DIP
3DES .................................................................................6 interfaces extendidas ............................................143
NAT para VPNs ......................................................143
A contenedores ................................................................193
Advanced Encryption Standard (AES) ...........................7 CRL
AES ....................................................................................7 véase Lista de revocación de certificados
AH..................................................................................3, 6
Ajustes de L2TP, DNS ..................................................217 D
archivos MIB, importación .........................................262 DES ....................................................................................6
asociaciones de seguridad Diffie-Hellman ................................................................11
véase SA Direcciones de protocolo de Internet (IP)
ataques véase direcciones IP
repetición .................................................................12 Direcciones IP
Autenticación extendidas ..............................................................143
algoritmos ..........................................6, 53, 57, 60, 63 directivas
VPN bidireccionales ..............................................128
C DN .................................................................................189
carga de seguridad encapsulada
véase ESP E
certificado local ..............................................................25 Encabezado de autenticación (AH) ................................6
certificados .......................................................................8 encriptación
CA........................................................................22, 25 algoritmos ..............................................6, 53, 56 a 63
carga .........................................................................28 ESP ................................................................................3, 6
carga de CRL ............................................................23 encriptación y autenticación ............................56, 63
local...........................................................................25 sólo autenticación ...................................................56
petición .....................................................................26 sólo encriptación .....................................................56
por medio del correo electrónico ..........................25
revocación ..........................................................25, 35 F
certificados de CA ....................................................22, 25 Fase 1 ................................................................................9
Challenge Handshake Authentication Protocol propuestas ..................................................................9
véase CHAP propuestas, predefinidas ..........................................9
CHAP .....................................................................213, 217 Fase 2 ..............................................................................11
clave manual propuestas ................................................................11
administración...........................................................7 propuestas, predefinidas ........................................12
claves firma digital ....................................................................20
manuales ........................................................120, 127 flujo de paquetes
previamente compartidas ....................................165 VPN basada en directivas ...............................70 a 71
claves previamente compartidas ...........................8, 165 VPN basada en rutas .......................................66 a 70
código de autenticación de mensajes basado en VPN de entrada ...............................................68 a 70
hash ................................................................................6 VPN de salida ...........................................................68
comodines ....................................................................192
comprobación contra reprocesamiento de H
paquetes ................................................................55, 61 HMAC ................................................................................6
confidencialidad directa perfecta
véase PFS
Índice IX-I
I L2TP en solitario sobre Windows 2000 .............213

ID de proxy .................................................................... 12 modo de funcionamiento .....................................214
coincidencia ....................................................... 65, 72 parámetros predeterminados ..............................217
identificación IKE de grupo señal hello ......................................................222, 227
certificados .................................................. 189 a 198 servidor de red: véase LNS
claves previamente compartidas .............. 198 a 204 Servidor RADIUS ...................................................217
IDs de proxy servidor SecurID ....................................................217
VPNs y NAT ................................................. 142 a 144 soporte de ScreenOS ............................................213
IKE................................................................. 7, 88, 97, 165 túnel ........................................................................219
ID de proxy .............................................................. 12 L2TP sobre IPSec .............................................4, 219, 224
ID IKE, Windows 2000 ................................. 225, 233 bidireccional ..........................................................213
ID local, ASN1-DN ................................................. 192 túnel ........................................................................219
ID remota, ASN1-DN ............................................ 192 LAC ................................................................................211
identificación IKE .............................. 53 a 55, 60 a 61 NetScreen-Remote 5.0..........................................212
identificación IKE de grupo, comodines ............ 192 Windows 2000 ......................................................212
identificación IKE de grupo, container ............... 193 Layer 2 Tunneling Protocol
mensajes de saludo .............................................. 304 véase L2TP
propuestas de fase 1, predefinidas ......................... 9 Lista de revocación de certificados........................23, 35
propuestas de fase 2, predefinidas ....................... 12 carga .........................................................................23
puertas de enlace redundantes ................. 301 a 314 LNS ................................................................................211
pulsos ..................................................................... 304
recomendaciones de ID IKE .................................. 73 M
usuario de identificación IKE mantenimiento de conexión
compartida ................................................ 204 a 210 frecuencia, NAT-T de ............................................246
usuario de identificación IKE de grupo .... 189 a 204 L2TP ........................................................................222
infraestructura de claves públicas MD5...................................................................................6
véase PKI Message Digest versión 5 (MD5)....................................6
intercambio de claves de Internet MIP, VPNs .....................................................................143
véase IKE modo de transporte.................................4, 213, 219, 224
Interfaces Modo de túnel ..................................................................4
extendidas ............................................................. 143 modo dinámico..............................................................10
null ............................................................................ 87 modo principal...............................................................10
IPSec modos
AH ................................................................... 2, 56, 62 Criptografía Fase 1 ............................................51, 58
ESP .................................................................. 2, 56, 62 dinámico ..................................................................10
firma digital ............................................................. 20 operacional L2TP ..................................................214
L2TP sobre IPSec ...................................................... 4 principal ...................................................................10
modo de transporte .......................... 4, 213, 219, 224 Transporte ....................................4, 62, 213, 219, 224
modo de túnel ........................................................... 4 túnel ......................................................................4, 62
negociación de túnel................................................. 9 módulo ............................................................................11
SA .................................................................. 2, 8, 9, 11
SPI ............................................................................... 2 N
túnel ............................................................................ 2 NAT
IPSec y NAT ...........................................................240
L servidores NAT ......................................................240
L2TP .................................................................... 211 a 237 NAT-dst
autenticado del túnel Windows 2000 ......... 222, 227 VPN .........................................................................143
bidireccional .......................................................... 213 NAT-src
concentrador de accesos: véase LAC VPN .........................................................................145
configuración obligatoria ..................................... 211 NAT-T ................................................................... 240 a 248
configuración voluntaria ...................................... 212 frecuencia de mantenimiento de conexión .......246
desencapsulado ..................................................... 216 habilitar ..................................................................248
Encapsulamiento................................................... 214 iniciador y respondedor .......................................246
Keep Alive ...................................................... 222, 227 obstáculos para VPN .............................................243
IX-II Índice
Índice
Paquete IKE ...........................................................244 Protocolos

Paquete IPSec ........................................................245 CHAP.......................................................................213
sondeos de NAT .......................................... 241 a 243 PAP..........................................................................213
NAT-Traversal PPP ..........................................................................212
Véase NAT-T puertas de enlace redundantes ........................301 a 314
NetScreen-Remote comprobación de indicador TCP SYN.................307
interlocutor dinámico ...................................170, 177 procedimiento de recuperación ..........................306
opción NAT-T .........................................................240
VPN AutoKey IKE ..................................................165 R
nombre completo (DN) ...............................................189 RADIUS
Norma de encriptación de datos (DES) .........................6 L2TP ........................................................................217
ruta Null ..........................................................................87
O rutas
OCSP (Online Certificate Status Protocol)...................35 null ............................................................................87
cliente .......................................................................35
servidor de respuesta .............................................35 S
opción de reencriptación, supervisión de VPN ........251 SA.............................................................................8, 9, 11
opciones criptográficas ......................................... 50 a 64 SAs
acceso telefónico ............................................. 57 a 64 comprobación en flujo de paquetes ......................68
algoritmos de autenticación.................53, 57, 60, 63 SCEP (Simple Certificate Enrollment Protocol) ..........31
algoritmos de encriptación ...................... 53 a 59, 63 Secure Hash Algorithm-1
comprobación contra reprocesamiento de véase SHA-1
paquetes ...........................................................55, 61 SecurID
ESP ......................................................................56, 63 L2TP ........................................................................217
identificación IKE .............................. 53 a 55, 60 a 61 Seguridad IP
longitudes de bits de los certificados ..............52, 59 véase IPSec
métodos de administración de claves ..................51 SHA-1 ................................................................................6
modo de transporte ................................................62 SNMP
Modo de túnel ..........................................................62 archivos MIB, importación ...................................262
modos de fase 1 ................................................51, 58 supervisión de VPN ...............................................262
PFS ......................................................................55, 61 supervisión de VPN ...........................................250 a 262
protocolos IPSec ................................................56, 62 cambios de estado ........................................250, 254
punto a punto .................................................. 50 a 57 dirección de destino ....................................252 a 255
recomendaciones VPN de acceso telefónico .......64 dirección de destino, XAuth .................................253
recomendaciones VPN punto a punto ..................57 directivas ................................................................253
tipos de autenticación.......................................52, 58 diseño de rutas ........................................................74
interfaz de salida .........................................252 a 255
P opción de reencriptación..............................251, 268
PAP ........................................................................213, 217 peticiones de eco ICMP ........................................262
par de claves pública/privada .......................................23 SNMP ......................................................................262
Password Authentication Protocol
véase PAP T
PFS ......................................................................12, 55, 61 tabla NHTB .........................................................263 a 268
PKI ...................................................................................22 asignación de rutas a túneles ...............................264
PPP ................................................................................212 entradas automáticas ............................................267
propuestas entradas manuales ................................................267
Fase 1 ...................................................................9, 72 esquema de direccionamiento ............................266
Fase 2 .................................................................11, 72 TCP
protección contra reprocesamiento de paquetes.......12 comprobación de indicador SYN.........................307
protocolo punto a punto Triple DES
véase PPP véase 3DES
Índice IX-III
U modo dinámico .......................................................10

UDP modo principal ........................................................10
encapsulación NAT-T ............................................ 240 múltiples túneles por interfaz de túnel ..... 263 a 300
suma de comprobación........................................ 245 NAT-dst ...................................................................143
usuarios NAT-src ...................................................................145
identificación IKE compartida ................... 204 a 210 opciones criptográficas ................................... 50 a 64
identificación IKE de grupo ....................... 188 a 204 protección contra reprocesamiento de
paquetes .................................................................12
V puertas de enlace redundantes ................. 301 a 314
Verisign ........................................................................... 35 SA ................................................................................8
VPN supervisión y reencriptación de VPN..................251
alias FQDN ............................................................. 133 túnel siempre activo .............................................251
AutoKey IKE .............................................................. 7 VPN AutoKey IKE .............................................................7
basadas en rutas o basadas en directivas ............ 64 administración...........................................................7
consejos de configuración.............................. 72 a 73 VPN basada en directivas .............................................64
Diffie-Hellman, grupos ........................................... 11 VPN basadas en rutas ........................................... 64 a 65
directiva para bidireccionales .............................. 128 VPNs
Fase 1 ......................................................................... 9 FQDN para puertas de enlace.................... 132 a 142
Fase 2 ....................................................................... 11 NAT para direcciones superpuestas .......... 142 a 154
flujo de paquetes ............................................. 66 a 71
grupos redundantes, procedimiento de W
recuperación........................................................ 306 WINS
grupos VPN ............................................................ 302 ajustes de L2TP......................................................217
ID de proxy, coincidencia ...................................... 72
intercambio Diffie-Hellman ................................... 11 X
MIP.......................................................................... 143 XAuth
modo de transporte .................................................. 4 supervisión de VPN ...............................................253
IX-IV Índice
Volumen 6:
Voz sobre el protocolo de Internet (VoIP)

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Copyright Notice
without notice.
FCC Statement
Disclaimer
ii
Contenido
Capítulo 1 Puerta de enlace en la capa de aplicación H.323 1

Vista general .................................................................................................... 1
Ejemplos .......................................................................................................... 2
Ejemplo: Equipo selector en la zona Trust ................................................. 2
Ejemplo: Equipo selector en la zona Untrust.............................................. 3
Ejemplo: Llamadas salientes con NAT ....................................................... 5
Ejemplo: Llamadas entrantes con NAT ......................................................8
Ejemplo: Equipo selector en la zona Untrust con NAT ............................. 10
Capítulo 2 Puerta de enlace de la capa de aplicación del protocolo de inicio de

sesión 13
Vista general .................................................................................................. 13
Métodos de petición del protocolo SIP ..................................................... 14
Clases de respuestas SIP .......................................................................... 16
Puerta de enlace en la capa de aplicación SIP.......................................... 17
Sesiones con protocolo de descripción de sesiones ................................. 18
Creación de ojos de aguja ........................................................................ 20
Tiempo de espera por inactividad de la sesión ........................................ 21
Protección contra ataques SIP .................................................................22
Ejemplo: SIP Protect Deny ................................................................ 22
medios ..............................................................................................23
Ejemplo: Protección contra inundaciones UDP ................................. 23
Ejemplo: Máximo de conexiones SIP ................................................ 24
SIP con traducción de direcciones de red (NAT) ............................................. 24
Llamadas salientes................................................................................... 25
Llamadas entrantes ................................................................................. 25
Llamadas reenviadas ............................................................................... 26
Terminación de la llamada ...................................................................... 26
Mensajes de llamada Re-INVITE .............................................................. 26
Temporizadores de sesiones de llamadas ................................................ 26
Cancelación de la llamada ....................................................................... 27
Bifurcación ..............................................................................................27
Mensajes SIP ........................................................................................... 27
Encabezados SIP ..................................................................................... 28
CONTENIDO iii
Concepts & Examples ScreenOS Reference Guide
Cuerpo SIP............................................................................................... 29
Supuesto de NAT con el protocolo SIP ..................................................... 30
Ejemplos ........................................................................................................ 31
Soporte de llamadas SIP entrantes utilizando el registrador SIP............... 32
Ejemplo: Llamada entrante (DIP de interfaz)..................................... 33
Ejemplo: Llamada entrante (conjunto de DIP) ................................... 36
Ejemplo: Llamada entrante con MIP ................................................. 38
Ejemplo: Proxy en la zona privada....................................................40
Ejemplo: Proxy en la zona pública ....................................................43
Ejemplo: Zona triple, proxy en DMZ ................................................. 45
Ejemplo: Untrust intrazonal .............................................................. 49
Ejemplo: Trust intrazonal .................................................................. 52
Ejemplo: VPN de malla completa para SIP ........................................ 55
Administración del ancho de banda para servicios de VoIP ..................... 65
Capítulo 3 Puerta de enlace en la capa de aplicación de protocolo de control

de la puerta de medios 67
Vista general .................................................................................................. 67
Seguridad de MGCP........................................................................................ 68
Protocolo MGCP ............................................................................................. 68
Entidades en MGCP ................................................................................. 69
Punto final ........................................................................................ 69
Conexión .......................................................................................... 69
Llamada ............................................................................................ 69
Agente de llamada ............................................................................ 70
Comandos ............................................................................................... 70
Códigos de respuesta............................................................................... 73
Ejemplos ........................................................................................................ 74
Puerta de enlace en las residencias de los abonados: agente de llamada
en el ISP............................................................................................ 74
Servicio alojado en ISP ............................................................................ 77
Capítulo 4 Puerta de enlace en la capa de aplicación del protocolo Skinny de

control de clientes 83
Vista general .................................................................................................. 83
Seguridad del SCCP........................................................................................ 84
Protocolo SCCP ..............................................................................................85
Componentes del SCCP ........................................................................... 85
Cliente del SCCP ............................................................................... 85
Gestor de llamadas............................................................................ 85
Clúster ..............................................................................................85
Transacciones con SCCP.......................................................................... 86
Inicialización del cliente .................................................................... 86
Registro del cliente............................................................................ 86
Establecimiento de la llamada........................................................... 87
Configuración de medios .................................................................. 87
Mensaje de control del SCCP y flujo del RTP............................................ 88
Mensajes del SCCP .................................................................................. 89
Ejemplos ........................................................................................................ 89
Ejemplo: Gestor de llamadas/servidor TFTP en la zona Trust ............ 90
Ejemplo: Gestor de llamadas/servidor TFTP en la zona Untrust......... 92
Ejemplo: Zona triple, gestor de llamadas/servidor TFTP en DMZ....... 94
iv CONTENIDO
CONTENIDO

Trust ........................................................................................... 98
Untrust .....................................................................................102
Ejemplo: VPN de malla completa para el SCCP ...............................104
ÍNDICE .......................................................................................................................IX-I
CONTENIDO v
Concepts & Examples ScreenOS Reference Guide
vi CONTENIDO
El Volumen 6: Voz sobre el protocolo de Internet (VoIP) describe las puertas de enlace
de la capa de aplicación (ALG) de VoIPs admitidas e incluye los siguientes capítulos:
Capítulo 1, “Puerta de enlace en la capa de aplicación H.323,” donde se

describe el protocolo H.323 y proporciona ejemplos de situaciones típicas.
Capítulo 2, “Puerta de enlace de la capa de aplicación del protocolo de inicio de

sesión,” donde se describe el protocolo de inicio de sesión (SIP) y muestra
cómo la ALG con SIP procesa llamadas con los modos de rutas y de traducción
de direcciones de red NAT (Network Address Translation). Después de un
resumen de la arquitectura del SIP se presentan ejemplos de las situaciones
típicas.
Capítulo 3, “Puerta de enlace en la capa de aplicación de protocolo de control

de la puerta de medios,” donde se ofrece una vista general de la ALG del
Protocolo de control de la puerta de medios (Gateway Control Protocol o MGCP)
y enumera las características de seguridad del cortafuegos de la
implementación. Después de un resumen de la arquitectura de MGCP se
presentan ejemplos de las situaciones típicas.
Capítulo 4, “Puerta de enlace en la capa de aplicación del protocolo Skinny de

control de clientes,” donde se ofrece una vista general de la ALG con el
protocolo Skinny de control de clientes (Skinny Client Control Protocol o SCCP)
y enumera las funciones de seguridad de cortafuegos de la implementación.
Después de un resumen de la arquitectura del SCCP se presentan ejemplos de
las situaciones típicas.

siguientes:
“Convenciones de la interfaz de usuario web” en la página viii
“Convenciones de interfaz de línea de comandos,” en la página viii
“Convenciones de nomenclatura y conjuntos de caracteres” en la página ix
Convenciones del documento vii



de una dirección:
Address Name: dir_1

Zone: Untrust


En ejemplos:










zona de seguridad

Internet

Interfaz de túnel
Servidor
Túnel VPN
Enrutador
Concentrador






Capítulo 1
Puerta de enlace en la capa de
aplicación H.323
En este capítulo se describe el protocolo H.323 y se ofrecen ejemplos para la

configuración de la puerta de enlace en la capa de aplicación (Aplication Layer
Gateway o ALG) en un dispositivo de seguridad de Juniper Networks. Este capítulo
consta de las siguientes secciones:
“Vista general” en esta página
“Ejemplos” en la página 2
Vista general
La puerta de enlace en la capa de aplicación (ALG) con protocolo H.323 permite
asegurar la comunicación de voz por IP (“Voice-over-IP” o VoIP) entre hosts
terminales, como teléfonos IP y dispositivos de multimedia. En estos sistemas de
telefonía, los equipos selectores (“gatekeeper”) gestionan el registro y la admisión
de llamadas, así como el estado de las llamadas “VoIP”. Los equipos selectores
pueden residir en dos zonas diferentes o en la misma zona.
Figura 2: Protocolo H.323
Equipo selector Equipo selector

Permitir
Zona Trust Internet

Permitir
Punto final Punto final Zona Untrust
NOTA: En las ilustraciones de este capítulo se utilizan teléfonos IP con fines ilustrativos,
aunque pueden configurarse otros hosts que utilicen el protocolo VoIP,
como dispositivos multimedia de NetMeeting.
Vista general 1
Ejemplos
Esta sección contiene los siguientes supuestos de configuraciones:
“Ejemplo: Equipo selector en la zona Trust” en esta página
“Ejemplo: Equipo selector en la zona Untrust” en la página 3
“Ejemplo: Llamadas salientes con NAT” en la página 5
“Ejemplo: Llamadas entrantes con NAT” en la página 8
“Ejemplo: Equipo selector en la zona Untrust con NAT” en la página 10
Ejemplo: Equipo selector en la zona Trust

En el ejemplo siguiente configurará dos directivas para permitir al tráfico H.323
pasar entre los hosts de telefonía IP y un equipo selector en la zona Trust y un
teléfono IP en la dirección IP 2.2.2.5 de la zona Untrust. En este ejemplo,
el dispositivo de seguridad puede estar en modo transparente (Transparent) o de
rutas (Route). Las dos zonas de seguridad Trust y Untrust se encuentran en el
Figura 3: Equipo selector H.323 en la zona Trust
Equipo Internet
selector
Teléfonos IP Teléfono IP
de punto final de punto final
2.2.2.5
WebUI
1. Dirección
Address Name: IP_Phone

Zone: Untrust
2. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), IP_Phone
Service: H.323
Action: Permit
2 Ejemplos
Capítulo 1: Puerta de enlace en la capa de aplicación H.323
haga clic en OK:
Source Address:
Service: H.323
Action: Permit
CLI
1. Dirección
set address untrust IP_Phone 2.2.2.5/32
2. Directivas
set policy from trust to untrust any IP_Phone h.323 permit
set policy from untrust to trust IP_Phone any h.323 permit
save
Ejemplo: Equipo selector en la zona Untrust

Dado que los modos transparente y de rutas no requieren ningún tipo de
asignación de direcciones, la configuración del dispositivo de seguridad para un
equipo selector en la zona Untrust es generalmente idéntica a la configuración de
un equipo selector en la zona Trust.
En el ejemplo siguiente configurará dos directivas para permitir al tráfico H.323

pasar entre los hosts de telefonía IP en la zona Trust y el teléfono IP en la dirección
IP 2.2.2.5 (y el equipo selector) de la zona Untrust. El dispositivo puede estar en
modo transparente o de rutas. Las dos zonas de seguridad Trust y Untrust se
Figura 4: Equipo selector H.323 en la zona Untrust

Internet
LAN
IP_Phone
IP_Phones 2.2.2.5/32
WebUI
1. Direcciones
Address Name: IP_Phone

Zone: Untrust
Ejemplos 3
Address Name: Gatekeeper

Zone: Untrust
2. Directivas
haga clic en OK:
Source Address:
Service: H.323
Action: Permit
haga clic en OK:
Source Address:
Service: H.323
Action: Permit
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Gatekeeper
Service: H.323
Action: Permit
CLI
1. Direcciones
set address untrust IP_Phone 2.2.2.5/32
set address untrust gatekeeper 2.2.2.10/32
2. Directivas
set policy from trust to untrust any IP_Phone h.323 permit
set policy from trust to untrust any gatekeeper h.323 permit
set policy from untrust to trust IP_Phone any h.323 permit
set policy from untrust to trust gatekeeper any h.323 permit
save
4 Ejemplos
Ejemplo: Llamadas salientes con NAT

Cuando el dispositivo de seguridad utiliza la traducción de direcciones de red
(“Network Address Translation” o NAT), un equipo selector o dispositivo de punto
final de la zona Trust tiene una dirección privada, y cuando se encuentra en la zona
Untrust tiene una dirección pública. Cuando un dispositivo de seguridad se
establece en el modo NAT, debe asignarse una dirección IP pública a cada
dispositivo que necesite recibir tráfico entrante con una dirección privada.
En este ejemplo, los dispositivos de la zona Trust son el host de punto final
(10.1.1.5) y el equipo selector (10.1.1.25). IP_Phone2 (2.2.2.5) está en la zona
Untrust. Configurará el dispositivo de seguridad para permitir tráfico entre el host
de punto final “IP_Phone1” y el equipo selector en la zona Trust y el host
“IP_Phone2” de punto final en la zona Untrust. Las dos zonas de seguridad Trust y
Untrust se encuentran en el dominio de enrutamiento trust-vr.
Figura 5: Traducción de direcciones de red: Llamadas salientes

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Equipo Internet
selector
10.1.1.25
IP_Phone1 MIP 1.1.1.25 -> 10.1.1.25 Puerta de enlace IP_Phone2
10.1.1.5 MIP 1.1.1.5 -> 10.1.1.5 1.1.1.250 2.2.2.5
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Direcciones
Address Name: IP_Phone1

Zone: Trust
Ejemplos 5

Zone: Trust

Zone: Untrust
3. Direcciones IP asignadas
Network > Interfaces > Edit (para ethernet3) > MIP > New: Introduzca los
Mapped IP: 1.1.1.5

Netmask: 255.255.255.255
Mapped IP: 1.1.1.25

Netmask: 255.255.255.255
4. Ruta

5. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), IP_Phone1
Service: H.323
Action: Permit
6 Ejemplos
haga clic en OK:
Source Address:
Service: H.323
Action: Permit
haga clic en OK:
Source Address:
Service: H.323
Action: Permit
haga clic en OK:
Source Address:
Service: H.323
Action: Permit
CLI
1. Interfaces
2. Direcciones
set address trust IP_Phone1 10.1.1.5/32
set address trust gatekeeper 10.1.1.25/32
set address untrust IP_Phone2 2.2.2.5/32
set interface ethernet3 mip 1.1.1.5 host 10.1.1.5
4. Ruta
5. Directivas
set policy from trust to untrust IP_Phone1 IP_Phone2 h.323 permit
set policy from trust to untrust gatekeeper IP_Phone2 h.323 permit
set policy from untrust to trust IP_Phone2 mip(1.1.1.5) h.323 permit
set policy from untrust to trust IP_Phone2 mip (1.1.1.25) h.323 permit
save
Ejemplos 7
Ejemplo: Llamadas entrantes con NAT

En este ejemplo configurará el dispositivo de seguridad para aceptar llamadas
entrantes sobre a través de un límite NAT. Para ello puede crear un conjunto de
direcciones DIP para direcciones de destino de asignación dinámica. Esto difiere de
la mayoría de configuraciones, en las que un conjunto DIP sólo proporciona
direcciones de origen.
Figura 6: Traducción de direcciones de red: Llamadas entrantes

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Internet
LAN
Conjunto de DIP con ID 5
1.1.1.12 ~ 1.1.1.150
El nombre del conjunto de DIP puede ser DIP(núm_id) para un DIP definido por el
usuario o DIP (interface) cuando el conjunto de DIP utilice la misma dirección que
una dirección IP de interfaz. Puede utilizar tales entradas de direcciones como
direcciones de destino en directivas, junto con servicios H.323, SIP u otros
protocolos VoIP (voz sobre IP) para admitir llamadas entrantes.
En el ejemplo siguiente se utiliza DIP en una configuración VoIP H.323. La palabra

clave “entrante” ordena al dispositivo agregar las direcciones DIP y de interfaz a la
zona global.
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

8 Ejemplos
2. DIP con NAT entrante

Network > Interfaces > Edit (para ethernet3) > DIP > New: Introduzca los
ID: 5
Incoming NAT: (seleccione)
3. Direcciones
Policy > Policy Elements > Addresses > List > New (for Trust): Introduzca los

Zone: Trust
Policy > Policy Elements > Addresses > List > New (for Untrust): Introduzca

Zone: Untrust
4. Directivas
haga clic en OK:
Source Address:
Service: H.323
Action: Permit
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), DIP(5)
Service: H.323
Action: Permit
CLI
1. Interfaces
set interface ethernet3 dip 5 1.1.1.12 1.1.1.150 incoming
Ejemplos 9
3. Direcciones
set address trust IP_Phones1 10.1.1.5/24
4. Directivas
set policy from trust to untrust IP_Phones1 any h.323 nat src dip 5 permit
set policy from untrust to trust IP_Phone2 dip(5) h.323 permit
save
Ejemplo: Equipo selector en la zona Untrust con NAT

En este ejemplo, el equipo selector (2.2.2.25) y el host IP_Phone2 (2.2.2.5) se
encuentran en la zona Untrust y el host IP_Phone1 (10.1.1.5) en la zona Trust.
Configurará el dispositivo de seguridad para permitir tráfico entre el host
IP_Phone1 en la zona Trust y el host IP_Phone2 (más el equipo selector) en la zona
Untrust. Las dos zonas de seguridad Trust y Untrust se encuentran en el dominio de
Figura 7: Equipo selector en la zona Untrust

ethernet1 ethernet3 Equipo selector
10.1.1.1/24 1.1.1.1/24 Puerta de 2.2.2.25
Modo NAT enlace 1.1.1.250
LAN Internet
IP_Phone1 IP_Phone2
MIP 1.1.1.5 -> 10.1.1.5 2.2.2.5
10.1.1.5
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

10 Ejemplos
2. Direcciones

Zone: Trust

Zone: Untrust

Zone: Untrust
Mapped IP: 1.1.1.5

Netmask: 255.255.255.255
4. Ruta

5. Directivas
haga clic en OK:
Source Address:
Service: H.323
Action: Permit
Ejemplos 11
haga clic en OK:
Source Address:
Service: H.323
Action: Permit
haga clic en OK:
Source Address:
Service: H.323
Action: Permit
haga clic en OK:
Source Address:
Service: H.323
Action: Permit
CLI
1. Interfaces
2. Direcciones
set address trust IP_Phone1 10.1.1.5/32
set address untrust gatekeeper 2.2.2.25/32
4. Ruta
5. Directivas
set policy from trust to untrust IP_Phone1 IP_Phone2 h.323 permit
set policy from trust to untrust IP_Phone1 gatekeeper h.323 permit
set policy from untrust to trust IP_Phone2 mip(1.1.1.5) h.323 permit
set policy from untrust to trust gatekeeper mip(1.1.1.5) h.323 permit
save
12 Ejemplos
Capítulo 2
Puerta de enlace de la capa de
aplicación del protocolo de inicio de
sesión
Este capítulo describe la puerta de enlace de la capa de aplicación (ALG) del

protocolo de inicio de sesión (SIP) y contiene las siguientes secciones:
“SIP con traducción de direcciones de red (NAT)” en la página 24
Vista general
El protocolo de inicio de sesión (SIP) es un protocolo que sigue la norma del equipo
de ingeniería para el desarrollo de Internet (IETF) en el que se define cómo iniciar,
modificar y finalizar sesiones multimedia a través de Internet. Estas sesiones
pueden ser de conferencias, telefonía o transferencias de datos multimedia, con
prestaciones como la mensajería inmediata y la movilidad de aplicaciones en
entornos de red.
Los dispositivos de seguridad Juniper Networks admiten SIP como servicio y

pueden monitorizar el tráfico SIP, permitiéndolo o rechazándolo según una directiva
configurada por el usuario. SIP es un servicio predefinido en ScreenOS y utiliza el
puerto 5060 como puerto de destino.
La función principal de SIP es distribuir la información de la descripción de la

sesión y, durante ésta, negociar y modificar sus parámetros. SIP también se utiliza
para terminar una sesión multimedia.
La información de la descripción de la sesión se incluye en los mensajes INVITE y

ACK e indica el tipo de multimedia de la sesión, por ejemplo, voz o vídeo. Aunque
el SIP puede utilizar varios protocolos para describir la sesión, la ALG con SIP de
Juniper Networks admite el protocolo de descripción de sesiones (SDP).
Vista general 13
El SDP proporciona la información necesaria para que un sistema pueda

incorporarse a una sesión multimedia. SDP puede proporcionar datos como
direcciones IP, números de puerto, fechas y horas. Observe que la dirección IP y el
número de puerto que figuran en el encabezado del protocolo SDP (los campos
“c=” y “m=”, respectivamente) corresponden a la dirección y al puerto donde el
cliente desea recibir las secuencias multimedia, y no representan la dirección IP y el
número de puerto donde se origina la petición SIP (aunque pueden coincidir). Para
obtener más información, consulte “Sesiones con protocolo de descripción de
sesiones” en la página 18.
Los mensajes del protocolo SIP consisten en peticiones de un cliente a un servidor y

en las correspondientes respuestas a esas peticiones enviadas por el servidor al
cliente con el propósito de establecer una sesión (o llamada). Un agente de usuario
(UA) es una aplicación que se ejecuta en los puntos finales de la llamada y consta de
dos partes: el cliente del agente de usuario (UAC), que envía peticiones SIP de parte
del usuario; y un servidor del agente del usuario (UAS), que escucha las respuestas y
notifica al usuario cuando llegan. Como ejemplos de UA pueden citarse los
servidores proxy SIP y los teléfonos.
Métodos de petición del protocolo SIP

El modelo transaccional SIP contempla una serie de mensajes de petición y de
respuesta, cada uno con un campo method que describe el propósito del mensaje.
ScreenOS admite los siguientes tipos de métodos y códigos de respuesta:
INVITE: Un usuario envía una petición INVITE para invitar a otro usuario a
participar en una sesión. El cuerpo de una petición INVITE puede contener la
descripción de la sesión. En el modo NAT, las direcciones IP en los campos de
encabezado Via:, From:, To:, Call-ID:, Contact:, Route:, y Record-Route: se
modifican según consta en la Tabla 2 en la página 28.
ACK: El usuario que generó la petición INVITE envía una petición ACK para
confirmar la recepción de la respuesta final a la petición INVITE. Si la petición
INVITE original no contenía la descripción de la sesión, entonces la petición
ACK debe incluirla. En el modo NAT, las direcciones IP en los campos de
OPTIONS: Utilizado por el agente del usuario (UA) para obtener información
sobre las capacidades del proxy del protocolo SIP. Un servidor responde con
información sobre los métodos, protocolos de descripción de sesiones y
codificación de mensajes que admite. En el modo NAT, cuando la petición
OPTIONS se envía desde un NAT fuera del UA a un NAT dentro del proxy, la ALG
del protocolo SIP traduce la dirección en Request-URI y la dirección IP del
campo To: a la dirección IP correspondiente al cliente interno. Cuando el UA se
encuentra dentro del NAT y el proxy fuera del NAT, la ALG con SIP traduce los
campos From:, Via: y Call-ID: según se muestra en la Tabla 2 en la página 28.
BYE: Un usuario envía una petición BYE para abandonar una sesión. Una
petición BYE de cualquier usuario cierra automáticamente la sesión. En el
modo NAT, las direcciones IP en los campos de encabezado Via:, From:, To:,
Call-ID:, Contact:, Route:, y Record-Route: se modifican según consta en la
Tabla 2 en la página 28.
14 Vista general
Capítulo 2: Puerta de enlace de la capa de aplicación del protocolo de inicio de sesión
CANCEL: Un usuario puede enviar una petición CANCEL para cancelar una
petición INVITE pendiente. Una petición CANCEL no tiene ningún efecto si el
servidor SIP que procesó la petición INVITE envió una respuesta final a dicho
INVITE antes de recibir la petición CANCEL. En el modo NAT, las direcciones IP
en los campos de encabezado Via:, From:, To:, Call-ID:, Contact:, Route:,
y Record-Route: se modifican según consta en la Tabla 2 en la página 28.
REGISTER: Un usuario envía una petición REGISTER a un servidor de registro

registrar SIP para informarle de la ubicación actual del usuario. El servidor de
registro SIP registra toda la información que recibe en las peticiones REGISTER
y pone esta información a disposición de cualquier servidor SIP que intente
localizar a un usuario. En el modo NAT, las peticiones REGISTER se gestionan
como sigue:
Peticiones REGISTER procedentes de un cliente externo a un registrador

interno: Cuando la ALG con SIP recibe la petición REGISTER entrante
traduce la dirección IP, si existe, en el Request-URI. Sólo se permiten
mensajes REGISTER entrantes a direcciones MIP o VIP. Para la respuesta
saliente no se requiere traducción.
Peticiones REGISTER procedentes de un cliente interno a un registro

externo: Cuando la ALG con SIP recibe la petición REGISTER saliente,
traduce las direcciones IP de los campos To:, From:, Via:, Call-ID:
y Contact:. Para la respuesta entrante se realiza una traducción inversa.
Info: Utilizado para comunicar la información de señales durante la sesión a lo

largo de la ruta de señales para la llamada. En el modo NAT, las direcciones IP
en los campos de encabezado Via:, From:, To:, Call-ID:, Contact:, Route:,
y Record-Route: se modifican según consta en la Tabla 2 en la página 28.
Subscribe: Utilizado para solicitar el estado actual y actualizaciones de estado a

un nodo remoto. En el modo NAT, la dirección Request-URI se transforma en
una dirección IP privada si los mensajes proceden de la red externa y entran en
la red interna. Las direcciones IP en los campos de encabezado Via:, From:, To:,
Call-ID:, Contact:, Route:, y Record-Route: se modifican según se muestra en la
tabla en Tabla 2 en la página 28.
Notify: Se envía para informar a abonados sobre cambios en el estado al que

están suscritos. En el modo NAT, la dirección IP en el campo de encabezado
Petición-URI: se transforma en una dirección IP privada si el mensaje procede
de la red externa y entra en la red interna. La dirección IP en los campos de
Refer: Se utiliza para enviar al destinatario (identificado por Request-URI) a un

tercero mediante la información de contacto proporcionada en la petición. En
el modo NAT, la dirección Request-URI se transforma en una dirección IP
privada si el mensaje procede de la red externa y entra en la red interna. Las
direcciones IP en los campos de encabezado Via:, From:, To:, Call-ID:, Contact:,
Route:, and Record-Route: se modifican según consta en la Tabla 2 en la
página 28.
Vista general 15
Por ejemplo, si el usuario A de una red privada establece una referencia para el
usuario B, que se encuentra en una red pública, hacia el usuario C, que también
pertenece a la red privada, la ALG con SIP asigna una nueva dirección IP y
número de puerto al usuario C para que el usuario B pueda ponerse en contacto
con él. Sin embargo, si el usuario C está registrado con un registrador, su
asignación de puerto se almacena en la tabla NAT de ALG y se reutiliza para
realizar la traducción.
Update: Se utiliza para abrir un ojo de aguja para información SDP nueva o
actualizada. Los campos de encabezado Via:, From:, To:, Call-ID:, Contact:,
Route:, y Record-Route: se modifican según consta en la Tabla 2 en la
página 28.
1Códigos de respuesta xx, 202, 2xx, 3xx, 4xx, 5xx, 6xx: Utilizados para indicar
el estado de una transacción. Los campos de encabezado se modifican según
consta en la Tabla 2 en la página 28.
Clases de respuestas SIP

Las respuestas SIP proporcionan la información de estado sobre las transacciones
SIP e incluyen un código de respuesta y el motivo. Las respuestas SIP se agrupan en
las siguientes clases:
Informativo (100 a 199): petición recibida, continúa procesando la petición.
Éxito (200 a 299): acción recibida correctamente, comprendida y aceptada.
Redirección (300 a 399): se requiere una acción adicional para completar la

petición.
Error del cliente (400 a 499): la petición es sintácticamente incorrecta o no se

puede ejecutar en este servidor.
Error del servidor (500 a 599): el servidor no pudo cumplir una petición
aparentemente válida.
Fallo global (600 a 699): la petición no se puede realizar en ningún servidor.
La Tabla 1 proporciona una lista completa de respuestas actuales de SIP que se

encuentran en los dispositivos de seguridad NetScreen compatibles.
Tabla 1: Respuestas de protocolo de inicio de sesión
Clase Código de respuesta-Motivo Código de respuesta-Motivo Código de respuesta-Motivo

Informativo 100 Trying (Intentando) 180 Ringing (Llamando) 181 Call is being forwarded
(Reenviando llamada)
182 Queued (En cola) 183 Session progress (Progreso de
la sesión)
Éxito 200 OK 202 Accepted (Aceptado)
Redirección 300 Multiple choices (Varias 301 Moved permanently (Movido 302 Moved temporarily (Movido
opciones) permanentemente) temporalmente)
305 Use proxy (Utilizar proxy) 380 Alternative service (Servicio
alternativo)
16 Vista general
Clase Código de respuesta-Motivo Código de respuesta-Motivo Código de respuesta-Motivo

Error del cliente 400 Bad request (Petición 401 Unauthorized (No autorizado) 402 Payment required (Requiere
incorrecta) pago)
403 Forbidden (Prohibido) 404 Not found (No encontrado) 405 Method not allowed (Método
no permitido)
406 Not acceptable (No aceptable) 407 Proxy authentication required 408 Request time-out (Petición
(Requiere autenticación del proxy) caducada)
409 Conflict (Conflicto) 410 Gone (Ausente) 411 Length required (Requiere
longitud)
413 Request entity too large 414 Request-URL too large (URL de 415 Unsupported media type (Tipo
(Tamaño de la petición excesivo) la petición demasiado grande) de medio incompatible)
420 Bad extension (Extensión 480 Temporarily not available 481 Call leg/transaction does not
incorrecta) (Temporalmente no disponible) exist (Tramo de la llamada o
transacción inexistente)
482 Loop detected (Detectado 483 Too many hops (Demasiado 484 Address incomplete
bucle) saltos) (Dirección incompleta)
485 Ambiguous (Ambiguo) 486 Busy here (Ocupado aquí) 487 Request canceled (Petición
cancelada)
488 Not acceptable here (No
aceptable aquí)
Error del 500 Server internal error (Error 501 Not implemented (No 502 Bad gateway (Puerta de enlace
servidor interno del servidor) implementado) incorrecta)
502 Service unavailable (Servicio 504 Gateway time-out (Puerta de 505 SIP version not supported
no disponible) enlace caducada) (Versión de SIP incompatible)
Fallo global 600 Busy everywhere (Ocupado en 603 Decline (Declinar) 604 Does not exist anywhere (No
todas partes) existe en ninguna parte)
606 Not acceptable (No aceptable)
Puerta de enlace en la capa de aplicación SIP

Existen dos tipos de tráfico SIP, el de señalización y el de las secuencia de medios
(“streams”). El tráfico de señalización de SIP consiste en mensajes de petición y de
respuesta intercambiados entre el cliente y el servidor y utiliza protocolos de
transporte como protocolo de datagrama de usuario (UDP) o protocolo de control
de transmisiones (TCP). La secuencia de medios transporta los datos (por ejemplo,
de audio) y utiliza protocolos de la capa de aplicación tales como protocolo de
transporte en tiempo real (RTP) sobre UDP.
Los dispositivos de seguridad de Juniper Networks admiten mensajes de

señalización SIP en el puerto 5060. Basta con crear una directiva que permita el
servicio SIP para que el dispositivo de seguridad filtre el tráfico de señalización SIP
como cualquier otro tipo de tráfico, permitiéndolo o rechazándolo. La secuencia
multimedia, sin embargo, utiliza números de puertos asignados dinámicamente y
que pueden cambiar varias veces durante el curso de una llamada. Sin puertos fijos
es imposible crear una directiva estática para controlar el tráfico de medios. En este
caso, el dispositivo de seguridad invoca la ALG con SIP. La ALG con SIP lee los
mensajes del protocolo SIP y su contenido SDP y extrae la información del número
de puerto que necesita para abrir dinámicamente ojos de aguja que permitan a la
secuencia de medios atravesar el dispositivo de seguridad.
Vista general 17
NOTA: Por “ojo de aguja” se entiende la apertura limitada de un puerto para permitir
tráfico exclusivo.
La ALG con SIP supervisa las transacciones SIP y crea y administra dinámicamente
los “ojos de aguja” basándose en la información que extrae de esas transacciones.
ALG con SIP de Juniper Networks admite todos los métodos y respuestas del
protocolo SIP (consulte “Métodos de petición del protocolo SIP” en la página 14 y
“Clases de respuestas SIP” en la página 16). Puede permitir a las transacciones SIP
atravesar el cortafuegos de Juniper Networks creando una directiva estática que
permita el servicio SIP. Esta directiva habilita el dispositivo de seguridad para que
intercepte tráfico SIP y ejecute una de las siguientes acciones: permitir o denegar el
tráfico o habilitar la ALG con SIP para abrir “ojos de aguja” por los que entregar la
secuencia multimedia. La ALG con SIP sólo necesita abrir “ojos de aguja” para las
peticiones y respuestas SIP que contienen información multimedia (SDP). En
cuanto a los mensajes SIP que no contienen SDP, el dispositivo de seguridad
simplemente los deja pasar.
La ALG con SIP intercepta los mensajes SIP que contienen SDP y, utilizando un
analizador sintáctico, extrae la información que requiere para crear ojos de aguja.
La ALG con SIP examina la porción SDP del paquete y un analizador sintáctico
extrae datos tales como direcciones IP y números de puerto, que la ALG con SIP
registra en una tabla de ojos de aguja. La ALG con SIP utiliza las direcciones IP y los
números de puerto registrados en la tabla de ojos de aguja para abrir nuevos ojos de
aguja que permitan a las secuencias multimedia atravesar el dispositivo de
seguridad.
NOTA: Los dispositivos de seguridad Juniper Networks no admiten SDP encriptado. Si un

dispositivo de seguridad recibe un mensaje SIP con el SDP encriptado, la ALG con
SIP permite que pase a través del cortafuegos, pero genera un mensaje del registro
y le informa al usuario de que no puede procesar el paquete. Si SDP está
encriptado, la ALG con SIP no puede extraer la información que necesita para
abrir ojos de aguja. Consecuentemente, el contenido multimedia descrito en el
SDP no puede atravesar el dispositivo de seguridad.
Sesiones con protocolo de descripción de sesiones

Las descripciones de sesiones SDP consisten en un conjunto de líneas de texto.
Pueden contener información de la sesión y del medio. La información a nivel de
sesión se refiere a toda la sesión, mientras que la información a nivel de medio se
refiere a una determinada secuencia multimedia. Una descripción de sesión SDP
siempre contiene información a nivel de sesión al principio de la descripción,
y puede contener información a nivel de medio, que se incluye después.
NOTA: En la descripción de la sesión SDP, la información a nivel del medio comienza con
el campo “m=”.
18 Vista general
De los muchos campos presentes en la descripción SDP, dos son particularmente

útiles para la ALG con SIP porque contienen la información de la capa de transporte.
Ambos campos son los siguientes:
c= para información de la conexión
Este campo puede aparecer a nivel de sesión o de medio. Se muestra en este

formato:
c=<tipo de red><tipo de dirección><dirección de conexión>
Actualmente, el dispositivo de seguridad admite solamente “IN” (abreviatura de

Internet) como tipo de red, “IP4” como tipo de dirección y una dirección IP o
nombre de dominio de unidifusión como dirección IP de destino (conexión).
NOTA: Generalmente, la dirección IP de destino también puede ser una dirección IP

multidifusión, pero por el momento ScreenOS no admite multidifusión con SIP.
Si la dirección IP de destino es una dirección IP unicast, la ALG con SIP crea

ojos de aguja usando la dirección IP y los números de puerto especificados en
el campo de descripción de medios m=.
m= para anuncio de medio
Este campo aparece a nivel de medios y contiene la descripción del medio. Se

muestra en este formato:
m=<medio><puerto><transporte><lista formatos>
Actualmente, el dispositivo de seguridad admite solamente “audio” como

medio y “RTP” como protocolo de transporte de la capa de aplicación. El
número de puerto indica el destino de la secuencia de medios (y no su origen).
La lista de formatos (“fmt list”) proporciona información sobre el protocolo de
la capa de aplicación utilizado por el medio.
En esta versión de ScreenOS, el dispositivo de seguridad abre puertos

solamente para RTP y RTCP. Cada sesión RTP tiene una sesión de protocolo de
control del transporte en tiempo real (RTCP) correspondiente. Por lo tanto,
siempre que una secuencia multimedia utilice RTP, la ALG con SIP debe
reservar puertos (crear ojos de aguja) tanto para el tráfico RTP como para el
RTCP. De forma predeterminada, el número de puerto para RTCP es el siguiente
al del puerto RTP.
NOTA: Generalmente, la dirección IP de destino también puede ser una dirección IP

multidifusión, pero por el momento ScreenOS no admite multidifusión con SIP.
Vista general 19
Creación de ojos de aguja

Los ojos de aguja para el tráfico RTP y RTCP comparten la misma dirección IP de
destino. La dirección IP procede del campo “c=” en la descripción de sesión de
SDP. Debido a que el campo “c=” puede aparecer tanto en la porción del nivel de
sesión como en la del nivel del medio dentro de la descripción de la sesión SDP, el
analizador sintáctico (“parser”) determina la dirección IP basándose en las reglas
siguientes (siguiendo las convenciones de SDP):
En primer lugar, el analizador sintáctico de la ALG con SIP verifica si hay un

campo “c=” que contenga una dirección IP en el nivel de medios. Si hay
alguno, extrae dicha dirección IP y la ALG con SIP la utiliza para crear un ojo de
aguja para los medios.
Si no hay ningún campo “c=” a nivel de medios, el analizador sintáctico de la

ALG con SIP extrae la dirección IP del campo “c=” en el nivel de sesión y la
ALG con SIP la utiliza para crear un ojo de aguja para los medios. Si la
descripción de la sesión no contiene un campo “c=” en ningún nivel, significa
que existe un error en la pila del protocolo, por lo que el dispositivo de
seguridad descarta el paquete y registra el evento.
La lista siguiente muestra la información que la ALG con SIP necesita para crear un
ojo de aguja. Esta información procede de la descripción de la sesión SDP y de los
parámetros del dispositivo de seguridad:
Protocolo: UDP.
IP de origen: Desconocido.
Puerto de origen: Desconocido.
IP de destino: El analizador sintáctico extrae la dirección IP de destino del

campo “c=” en el nivel de medio o de sesión.
Puerto de destino: El analizador sintáctico extrae el número del puerto de

destino para RTP del campo “m=” en el nivel de medios y calcula el número
del puerto de destino para RTCP utilizando la siguiente fórmula:
Número de puerto RTP + uno.
Duración: Este valor indica el tiempo (en segundos) que permanece abierto un
ojo de aguja para permitir el paso de un paquete. Un paquete debe pasar a
través del ojo de aguja antes de que caduque este tiempo. Cuando caduca, la
ALG con SIP elimina el ojo de aguja.
Cuando un paquete atraviesa el ojo de aguja dentro del periodo de vigencia,

inmediatamente después la ALG con SIP elimina el ojo de aguja para la
dirección de procedencia del paquete.
La Figura 8 describe una configuración de llamada entre dos clientes SIP y

cómo la ALG con SIP crea ojos de aguja para permitir el tráfico RTP y RTCP. La
ilustración asume que el dispositivo de seguridad tiene una directiva que
permite el tráfico SIP, abriendo el puerto 5060 para mensajes de señalización
SIP.
20 Vista general
Figura 8: Ajuste de llamada de ALG con SIP
Cliente A 1.1.1.1 Zona Trust Dispositivo de seguridad Proxy SIP Zona Untrust Cliente B 2.2.2.2
1.El cliente A envía una petición INVITE

destinada al Cliente B al proxy SIP
a través del puerto 5060 en el dispositivo 2. Por SDP, la ALG con SIP
de seguridad (SDP 1.1.1.1:2000) crea un ojo de aguja para 3. El proxy SIP transmite la petición INVITE
1.1.1.1: 2000 al Cliente B
5. El proxy SIP transmite la respuesta de

"Ringing" (llamando) del Cliente B al Cliente A 4. El Cliente B contesta al proxy SIP con una
a través del puerto 5060 en el dispositivo de respuesta "Ringing" (llamando)
seguridad
7. Por SDP, la ALG con SIP 6. El Cliente B envía una respuesta 200 OK al
crea un ojo de aguja para proxy SIP en respuesta a la petición INVITE
8. El proxy SIP transmite una respuesta 200 (SDP: 2.2.2.2: 3000)
OK del Cliente B al Cliente A a través del 2.2.2.2: 3000
9. El Cliente A envía una respuesta ACK

destinada al Cliente B al proxy SIP
a través del puerto 5060 en el dispositivo de 10. El proxy SIP transmite la respuesta
seguridad ACK al Cliente B
11. El Cliente B envía el tráfico de medios

Ojo de aguja 1 (RTP/RTCP) al Cliente A a través del ojo de aguja 1
12. El Cliente A envía el tráfico de medios

(RTP/RTCP) al Cliente B a través del ojo de aguja 2 Ojo de aguja 2
NOTA: La ALG con SIP no crea ojos de aguja para el tráfico RTP y RTCP cuando la
dirección IP de destino es 0.0.0.0 (ya que indica que la sesión está retenida). Para
poner una sesión en estado retenido (“on hold”), por ejemplo, durante una
comunicación telefónica, un usuario (Usuario A) envía al otro usuario (Usuario B)
un mensaje SIP en el cual la dirección IP de destino es 0.0.0.0. De este modo se
indica al Usuario B que no envíe ningún medio hasta nuevo aviso. Si aún así el
Usuario B envía algún medio, el dispositivo de seguridad descarta los paquetes.
Tiempo de espera por inactividad de la sesión

Normalmente, una llamada termina cuando uno de los clientes envía una petición
BYE o CANCEL. La ALG con SIP intercepta la petición BYE o CANCEL y elimina todas
las sesiones de medios de esa llamada. Existen posibles causas o problemas que
impedirían a los clientes de una llamada enviar peticiones BYE o CANCEL, por
ejemplo, un fallo de alimentación eléctrica. En este caso, la llamada podría
continuar indefinidamente, consumiendo recursos en el dispositivo de seguridad.
La función de tiempo de espera por inactividad permite al dispositivo de seguridad
supervisar el “estado vital” de la llamada para terminarla si no hay actividad
durante un periodo determinado de tiempo.
Una llamada puede tener uno o varios canales de voz. Cada canal de voz tiene dos
sesiones (o dos secuencias de medios), una para RTP y otra para RTCP. En cuanto a
la gestión de las sesiones, el dispositivo de seguridad trata las sesiones de cada
canal de voz como un grupo. Los ajustes tales como el tiempo de espera por
inactividad se aplican a nivel de grupo, no a cada sesión.
Vista general 21
Existen dos tipos de tiempo de espera por inactividad que determinan la duración
de un grupo:
Tiempo de espera por inactividad de señalización: Este parámetro indica el

tiempo máximo (en segundos) que una llamada puede seguir activa sin que se
señalice tráfico SIP. Cada vez que se genera un mensaje SIP durante una
llamada, este tiempo de espera se restablece. El ajuste predeterminado es de
43200 segundos (12 horas).
Tiempo de espera por inactividad de medios: Este parámetro indica el tiempo

máximo (en segundos) que una llamada puede permanecer activa sin que se
produzca tráfico de medios (RTP o RTCP) dentro de un grupo. Cada vez que se
genera un paquete RTP o RTCP durante una llamada, este tiempo de espera se
restablece. El ajuste predeterminado es de 120 segundos.
Si cualquiera de estos tiempos de espera caduca, el dispositivo de seguridad elimina

todas las sesiones de esa llamada en su tabla, terminando de ese modo la llamada.
Protección contra ataques SIP

La capacidad de procesamiento de llamadas del servidor proxy SIP puede verse
afectada por la repetición de peticiones INVITE de SIP, tanto malévolas como por
error del cliente o del servidor, denegadas inicialmente. Para impedir que el
servidor proxy SIP sea saturado por tales peticiones, puede utilizar el comando sip
protect deny para configurar el dispositivo de seguridad de modo que supervise las
peticiones INVITE y las correspondientes respuestas del servidor proxy. Si alguna
respuesta contiene un código de respuesta 3xx, 4xx o 5xx (véase “Clases de
respuestas SIP” en la página 16), ALG guarda la dirección IP de la petición y la
dirección IP del servidor proxy en una tabla. El dispositivo de seguridad comprueba
posteriormente todas las peticiones INVITE realizadas contra esta tabla y, durante
un número configurable de segundos (el predeterminado es de 3), descarta
cualquier paquete que coincida con entradas en la tabla. También puede configurar
el dispositivo de seguridad para que supervise las peticiones INVITE a un servidor
proxy determinado especificando la dirección IP de destino. La protección contra
ataques SIP se configura globalmente.
Ejemplo: SIP Protect Deny

En este ejemplo configurará el dispositivo de seguridad para que proteja un servidor
proxy de SIP (1.1.1.3/24) contra peticiones INVITE repetitivas a las que ya haya
denegado el servicio. Los paquetes se descartan durante 5 segundos, transcurridos
los cuales el dispositivo de seguridad reanuda el redireccionamiento de peticiones
INVITE procedentes de esos orígenes.
WebUI
Para proteger servidores proxy SIP contra inundaciones causadas por peticiones
INVITE, debe utilizar el CLI.
CLI
set alg sip app-screen protect deny dst-ip 1.1.1.3/24
set alg sip protect deny timeout 5
save
22 Vista general

medios
En este ejemplo configurará el tiempo de espera por inactividad de señalización en
30.000 segundos y el tiempo de espera por inactividad de medios en 90 segundos.
WebUI
NOTA: Para establecer tiempos de espera para señalizaciones SIP e inactividad de

medios, debe utilizar la CLI.
CLI
set alg sip signaling-inactivity-timeout 30000
set alg sip media-inactivity-timeout 90
save
Ejemplo: Protección contra inundaciones UDP

Puede proteger el dispositivo de seguridad contra inundaciones UDP por zona y por
dirección de destino. En este ejemplo, establecerá un umbral de 80.000 por
segundo para el número de paquetes UDP que se pueden recibir en la dirección
IP 1.1.1.5, en la zona Untrust, antes de que el dispositivo de seguridad genere una
alarma y descarte los paquetes subsiguientes durante el resto de ese segundo.
NOTA: Este ejemplo utiliza un comando general de ScreenOS, y no es necesariamente

específico de SIP. Si desea más información acerca de la protección contra
inundación UDP y cómo determinar la configuración efectiva, consulte
“Inundaciones UDP” en la página 4-51.
WebUI
Security > Screening > Screen: Introduzca los siguientes datos y haga clic
en Apply:
Zone: Untrust
UDP Flood Protection (seleccione)
>Destination IP: Escriba lo siguiente, luego haga clic en la flecha Atrás de

su explorador para regresar a la página de configuración de la pantalla:

Threshold: 80000
Add: (seleccione)
CLI
set zone untrust screen udp-flood dst-ip 1.1.1.5 threshold 80000
save
Vista general 23
Ejemplo: Máximo de conexiones SIP

En este ejemplo impedirá ataques de inundación en la red SIP procedentes de
atacantes de la zona Untrust, estableciendo un máximo de 20 sesiones simultáneas
desde una sola dirección IP. Si el dispositivo de seguridad detecta más de
20 intentos de conexión desde la misma dirección IP, comienza a descartar los
intentos subsiguientes hasta que el número de sesiones caiga por debajo del
máximo especificado.
NOTA: Este ejemplo utiliza un comando general de ScreenOS, y no es necesariamente

específico de SIP. Para obtener más información sobre límites de sesiones basados
en orígenes y cómo determinar los ajustes más eficaces, consulte “Límites a la
cantidad de sesiones según sus orígenes y destinos” en la página 4-30.
WebUI
Screening > Screen (Zone: Untrust): Introduzca los siguientes datos y haga clic
en OK:

CLI
set zone untrust screen limit-session source-ip-based 20
save
SIP con traducción de direcciones de red (NAT)

El protocolo de traducción de direcciones de red (NAT) permite a múltiples equipos
de una subred privada compartir una sola dirección IP pública para acceder a
Internet. Para el tráfico saliente, NAT reemplaza la dirección IP privada del equipo
dentro de la subred privada por la dirección IP pública. Para el tráfico entrante, la
dirección IP pública se transforma en la dirección privada y el mensaje se enruta al
equipo apropiado de la subred privada.
La utilización conjunta de NAT con el servicio SIP es más complicada, porque los
mensajes SIP contienen direcciones IP tanto en los encabezados como en el cuerpo
SIP. Los encabezados SIP contienen información sobre el llamante y el receptor, y el
dispositivo de seguridad traduce esta información para ocultarla a la red exterior. El
cuerpo del protocolo SIP contiene la información del protocolo de descripción de
sesiones (“Session Description Protocol” o SDP), que contiene las direcciones IP y
números de puerto para la transmisión de los medios. El dispositivo de seguridad
traduce la información del SDP para asignar los recursos necesarios para enviar y
recibir los medios.
La forma en que se reemplazan las direcciones IP y los números de puerto en

mensajes SIP depende de la dirección del mensaje. Para los mensajes salientes, la
dirección IP y el número de puerto privados del cliente se reemplazan por la
dirección IP y el número de puerto públicos del cortafuegos de NetScreen. Para los
mensajes entrantes, la dirección pública del cortafuegos se reemplaza por la
dirección privada del cliente.
24 SIP con traducción de direcciones de red (NAT)

Cuando se envía un mensaje INVITE a través del cortafuegos, la ALG con SIP recoge
información del encabezado del mensaje en una tabla de llamadas, que utiliza para
reenviar los mensajes subsiguientes al punto de destino correcto. Cuando llega un
mensaje nuevo, por ejemplo un ACK o un 200 OK, la ALG compara los campos
From:, To: y Call-ID: con la tabla de llamadas para identificar el contexto de llamada
del mensaje. Si llega un nuevo mensaje INVITE que coincida con la llamada
existente, ALG lo procesa como REINVITE.
Cuando llega un mensaje con información del SDP, ALG asigna puertos y crea una
asignación NAT entre ellos y los puertos en el SDP. Dado que el SDP requiere
puertos consecutivos para los canales del protocolo en tiempo real (“Real Time
Protocol” o RTP) y del protocolo de control en tiempo real (“Real Time Control
Protocol” o RTCP), ALG proporciona puertos pares-impares consecutivos. Si no
encuentra ningún par de puertos, descarta el mensaje SIP.
Llamadas salientes
Cuando una llamada SIP se inicia mediante un mensaje de petición SIP desde la red
interna hacia la red externa, NAT reemplaza las direcciones IP y los números de
puerto en el SDP y crea un enlace para asignar las direcciones IP y los números de
puerto al cortafuegos de Juniper Networks. los campos de encabezado de SIP Via:,
Contact:, Route:, y Record-Route:, si están presentes, también se vinculan a la
dirección IP del cortafuegos. ALG almacena estas asignaciones para utilizarlas en
retransmisiones y para los mensajes de respuesta SIP.
A continuación, la ALG con SIP abre ojos de aguja en el cortafuegos para permitir el
paso de medios a través del dispositivo de seguridad por los puertos
dinámicamente asignados, negociados basándose en la información del SDP y de
los campos de encabezado Via:, Contact: y Record- -Route: Los ojos de aguja
también permiten que los paquetes entrantes alcancen los campos Contact:, Via:
y Record-Route:, direcciones IP y puertos. Al procesar el tráfico de retorno, la ALG
vuelve a insertar los campos SIP originales Contact:, Via:, Route: y Record-Route: en
los paquetes.
Llamadas entrantes
Las llamadas entrantes se inician desde la red pública hacia direcciones IP públicas
asignadas (MIP) o hacia direcciones IP de interfaces del dispositivo de seguridad.
Las MIP son direcciones IP configuradas estáticamente que apuntan a hosts
internos; las direcciones IP de interfaz son registradas dinámicamente por la ALG
mientras supervisa los mensajes REGISTER enviados por hosts internos al
registrador SIP. (Para obtener más información, consulte “Ejemplos” en la
página 31). Cuando el dispositivo de seguridad recibe un paquete SIP entrante,
genera una sesión y reenvía la carga de datos del paquete a la ALG con SIP.
El ALG examina el mensaje de petición SIP (inicialmente un INVITE) y, basándose

en la información del SDP, abre las puertas para los medios salientes. Cuando llega
un mensaje de respuesta OK 200, la ALG con SIP aplica NAT a las direcciones y
puertos IP y abre ojos de aguja en la dirección de salida. (Las puertas abiertas tienen
un plazo de vida corto y caducan si no se recibe rápidamente un mensaje de
respuesta 200 OK).
SIP con traducción de direcciones de red (NAT) 25

Cuando llega una respuesta OK 200, el proxy SIP examina la información SDP y lee
las direcciones IP y números de puerto de cada sesión de medios. La ALG con SIP
del dispositivo de seguridad aplica NAT a las direcciones y números de puerto, abre
ojos de aguja para el tráfico saliente y restablece el tiempo de espera para las
puertas en la dirección de entrada.
Cuando llega la señal ACK de 200 OK, también atraviesa la ALG con SIP. Si el
mensaje contiene información del SDP, la ALG con SIP garantiza que las direcciones
IP y los números de puerto no sean cambiados con respecto al anterior INVITE; si lo
son, la ALG elimina los ojos de aguja antiguos y crea otros nuevos para permitir el
paso de los medios. La ALG supervisa también los campos de SIP Via:, Contact:,
y Record-Route: y abre nuevos ojos de aguja si detecta que estos campos han
cambiado.
Llamadas reenviadas
Una llamada es reenviada cuando, por ejemplo, el usuario A externo a la red llama
al usuario B dentro de la red y éste reenvía la llamada al usuario C fuera de la red.
La ALG con SIP procesa la señal INVITE del usuario A como llamada entrante
normal. Pero cuando la ALG examina la llamada reenviada desde B a C, que se
encuentra fuera de la red, y detecta que B y C se pueden alcanzar a través de la
misma interfaz, no abre ojos de aguja en el cortafuegos, ya que los medios podrán
fluir directamente entre el usuario A y el usuario C.
Terminación de la llamada
El mensaje BYE se utiliza para terminar una llamada. Cuando el dispositivo de
seguridad recibe un mensaje BYE, traduce los campos del encabezado igual que
hace con cualquier otro mensaje, pero debido a que los mensajes BYE debe ser
confirmados por el receptor con 200 OK, la ALG retrasa el desmantelamiento de la
llamada durante cinco segundos para dar tiempo a que se transmita el 200 OK.
Mensajes de llamada Re-INVITE

Los mensajes Re-INVITE se utilizan para agregar nuevas sesiones de medios a una
llamada y para eliminar sesiones de medios existentes. Cuando se agregan nuevas
sesiones de medios a una llamada, se abren nuevos ojos de aguja en el cortafuegos
y se crean nuevos enlaces de direcciones. El proceso es idéntico al establecimiento
original de la llamada. Cuando se eliminan una o más sesiones de medios de una
llamada, los ojos de aguja se cierran y los enlaces se anulan, igual que con un
mensaje BYE.
Temporizadores de sesiones de llamadas

La ALG con SIP utiliza el valor Session-Expires para hacer caducar una sesión si no
se recibe ningún mensaje Re-INVITE o UPDATE. El ALG obtiene el valor
Session-Expires, si está presente, de la respuesta 200 OK al INVITE y utiliza este
valor para señalizar el tiempo de espera. Si la ALG recibe otro INVITE antes de que
la sesión caduque, restablece todos los valores del tiempo de espera a este nuevo
INVITE o a valores predeterminados, y el proceso se repite.

Como medida preventiva, la ALG con SIP utiliza valores de tiempo de espera
estrictos para definir el tiempo máximo que una llamada puede existir. Esto
garantiza que el dispositivo de seguridad esté protegido en los siguientes casos:
El sistema final se viene abajo durante una llamada y el mensaje BYE no se

recibe nunca.
Usuarios malévolos nunca envían un BYE para intentar atacar una ALG con SIP.
Implementaciones deficientes del proxy SIP que no pueden procesar

Record-Route y nunca envían un mensaje BYE.
Fallos de red impiden la recepción de un mensaje BYE.
Cancelación de la llamada
Cualquier interlocutor puede cancelar una llamada enviando un mensaje CANCEL.
En el momento de recibir un mensaje CANCEL, la ALG con SIP cierra los ojos de
aguja (que haya abiertos) en todo el cortafuegos y libera los enlaces de direcciones.
Antes de liberar los recursos, la ALG retrasa el envejecimiento del canal de control
durante unos cinco segundos para dar tiempo a que pase la señal 200 OK final. La
llamada se termina cuando expira el tiempo de espera de cinco segundos, tanto si
llega una respuesta 487 como si llega una 200.
Bifurcación
La bifurcación permite a un proxy SIP enviar un mismo mensaje INVITE a múltiples
destinos simultáneamente. Cuando llegan los diferentes mensajes de respuesta
200 OK para esa única llamada, la ALG con SIP analiza pero actualiza la
información de la llamada con el mensaje primer mensaje 200 OK que recibe.
Mensajes SIP
El formato de un mensaje SIP consta de una sección de encabezado SIP y del
cuerpo SIP. En mensajes de petición, la primera línea de la sección de encabezado
es la línea de petición, que incluye el tipo de método, Request-URI y la versión del
protocolo. En mensajes de respuesta, la primera línea es la línea de estado, que
contiene un código de estado. Los encabezados SIP contienen las direcciones IP y
números de puerto utilizados para la señalización. El cuerpo SIP, separado de la
sección de encabezado por una línea en blanco, está reservado para la información
de descripción de la sesión, que es opcional. Actualmente, los dispositivos de
seguridad Juniper Networks sólo admiten el protocolo SDP. El cuerpo SIP contiene
las direcciones IP y los números de puerto utilizados para transportar los medios.
En el modo NAT, el dispositivo de seguridad traduce la información de los

encabezados SIP para ocultar la información a la red exterior. NAT se aplica a la
información del cuerpo SIP para asignar recursos, es decir, números de puerto en
los que se recibirán los medios.

Encabezados SIP
En el siguiente ejemplo de mensaje de petición SIP, NAT reemplaza las direcciones
IP en los campos del encabezado, mostrados en negrita, para ocultarlos a la red
exterior.
INVITE bob@10.150.20.5 SIP/2.0

Via: SIP/2.0/UDP 10.150.20.3:5434
From: alice@10.150.20.3
To: bob@10.150.20.5
Call-ID: a12abcde@10.150.20.3
Contact: alice@10.150.20.3:5434
Route: <sip:netscreen@10.150.20.3:5060>
Record-Route: <sip:netscreen@10.150.20.3:5060>
El método aplicado para traducir la dirección IP depende del tipo y de la dirección

del mensaje, que puede ser uno de los siguientes:
Petición entrante
Respuesta saliente
Petición saliente
Respuesta entrante
La Tabla 2 muestra cómo se aplica NAT en cada uno de estos casos. Observe que,
para varios de los campos de encabezado, la ALG necesita saber algo más que la
mera procedencia interior o exterior de los mensajes. También necesita saber qué
cliente inició la llamada y si el mensaje es una petición o una respuesta.
Tabla 2: Mensaje de solicitud con NAT
Tipo de mensaje Campos Acción

Petición entrante To: Reemplazar dirección ALG por dirección local
(de pública a privada) From: Ninguna
Call-ID: Ninguna
Via: Ninguna
Request-URI: Reemplazar dirección ALG por dirección local
Contact: Ninguna
Record-Route: Ninguna
Route: Ninguna
Respuesta saliente To: Reemplazar dirección ALG por dirección local
(de privada a pública) From: Ninguna
Call-ID: Ninguna
Via: Ninguna
Request-URI: N/A
Contact: Reemplazar dirección local por dirección ALG
Record-Route: Reemplazar dirección local por dirección ALG
Route: Ninguna

Tipo de mensaje Campos Acción

Petición saliente To: Ninguna
(de privada a pública) From: Reemplazar dirección local por dirección ALG
Call-ID: Reemplazar dirección local por dirección ALG
Via: Reemplazar dirección local por dirección ALG
Request-URI: Ninguna
Contact: Reemplazar dirección local por dirección ALG
Record-Route: Reemplazar dirección local por dirección ALG
Route: Reemplazar dirección ALG por dirección local
Respuesta saliente To: Ninguna
(de pública a privada) From: Reemplazar dirección ALG por dirección local
Call-ID: Reemplazar dirección ALG por dirección local
Via: Reemplazar dirección ALG por dirección local
Request-URI: N/A
Contact: Ninguna
Record-Route: Reemplazar dirección ALG por dirección local
Route: Reemplazar dirección ALG por dirección local
Cuerpo SIP
La información SDP en el cuerpo SIP contiene direcciones IP que ALG utiliza para
crear canales para la secuencia de medios. La traducción de la sección SDP también
asigna recursos, es decir, números de puerto para enviar y recibir los medios.
El siguiente extracto de una sección SDP muestra los campos que se traducen para
la asignación de recursos.
o=user 2344234 55234434 IN IP4 10.150.20.3

c=IN IP4 10.150.20.3
m=audio 43249 RTP/AVP 0
Los mensajes SIP pueden contener más de una secuencia de medios. El concepto es
similar a adjuntar varios archivos a un mensaje de correo electrónico. Por ejemplo,
un mensaje INVITE enviado desde un cliente SIP a un servidor SIP puede tener los
siguientes campos:
c=IN IP4 10.123.33.4

c=IN IP4 10.123.33.4
c=IN IP4 10.123.33.4
Los dispositivos de seguridad Juniper Networks admiten hasta seis canales SDP
negociados para cada dirección, hasta un total de 12 canales por llamada. Para
obtener más información, consulte “Sesiones con protocolo de descripción de
sesiones” en la página 18.

Supuesto de NAT con el protocolo SIP

En la Figura 9, ph1 envía un mensaje SIP INVITE a ph2. Observe cómo el
dispositivo de seguridad traduce las direcciones IP en los campos del encabezado,
que se muestran en fuente en negrita.
La sección SDP del mensaje INVITE indica dónde el llamante está dispuesto a
recibir medios. Observe que el ojo de aguja de los medios contiene dos números de
puertos, 52002 y 52003, para RTCP y RTP. El ojo de aguja Via/Contact proporciona
el número de puerto 5060 para la señalización SIP.
Observe cómo, en el mensaje de respuesta 200 OK, las traducciones realizadas en

el mensaje INVITE se invierten. Las direcciones IP de este mensaje, al ser públicas,
no se traducen, pero las puertas se abren para permitir el acceso de la secuencia de
medios a la red privada.
Figura 9: Supuesto de NAT con el protocolo SIP 1
SIP ph1 5.5.5.1 5.5.5.2 6.6.6.1 6.6.6.2 SIP ph2
Red interna Red externa

INVITE Sip: ph2@ 6.6.6.6 SIP/2.0 INVITE Sip: ph2@ 6.6.6.6 SIP/2.0
Via: SIP/2.0/UDP 5.5.5.1:5060 Via: SIP/2.0/UDP 6.6.6.1:5060
Call-ID: a1234@5.5.5.1 Call-ID: a1234@6.6.6.1
From: ph1@5.5.5.1 From: ph1@6.6.6.1
To: ph2@6.6.6.2 To: ph2@6.6.6.2
CSeq 1 INVITE CSeq 1 INVITE
Content-type: application/sdp Content-type: application/sdp
Content-Length: 98 Content-Length: 98
V=0 V=0
o=ph1 3123 1234 IP IP4 5.5.5.1 o=ph1 3123 1234 IP IP4 6.6.6.1
o=IN IPv4 5.5.5.1 o=IN IPv4 6.6.6.1
m=audio 62002 RTP/AVP 0 m=audio 52002 RTP/AVP 0
Ojo de aguja de los medios
5.5.5.1 Cualquier IP
6.6.6.1
52002/52003 Cualquier
puerto
45002/45003
Ojo de aguja Via/Contact
5.5.5.1
6.6.6.1 Cualquier IP
1234 Cualquier puerto
5060

Figura 10: Supuesto de NAT con el protocolo SIP 2

SIP ph1 5.5.5.1 5.5.5.2 6.6.6.1 6.6.6.2 SIP ph2

SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP 5.5.5.1:5060 Via: SIP/2.0/UDP 6.6.6.1:1234
Call-ID: a1234@5.5.5.1 Call-ID: a1234@6.6.6.1
From: ph1@5.5.5.1 From: ph1@6.6.6.1
To: ph2@6.6.6.2 To: ph2@6.6.6.2
CSeq 1 INVITE CSeq 1 INVITE
Content-type: application/sdp Content-type: application/sdp
Content-Length: 98 Content-Length: 98
V=0 Contact SIP: 6.6.6.6:5060
o=ph2 5454 565642 IP IP4 V=0
6.6.6.2 o=ph2 5454 565642 IP IP4
c=IN IP4 6.6.6.2 6.6.6.2
m=audio 62002 RTP/AVP 0 c=IN IP4 6.6.6.2
Ojo de aguja de los medios
Cualquier IP 6.6.6.2
Cualquier 62002/62003
puerto
Ojo de aguja Via/Contact
Cualquier IP
Cualquier 6.6.6.2
puerto 5060
ACK SIP:ph2@6.6.6.2 SIP/2.0 ACK SIP:ph2@6.6.6.2 SIP/2.0

.... ....
Ejemplos
Esta sección contiene los siguientes ejemplos de supuestos:
“Soporte de llamadas SIP entrantes utilizando el registrador SIP” en la

página 32
“Ejemplo: Llamada entrante con MIP” en la página 38
“Ejemplo: Proxy en la zona privada” en la página 40
“Ejemplo: Proxy en la zona pública” en la página 43
“Ejemplo: Zona triple, proxy en DMZ” en la página 45
“Ejemplo: Untrust intrazonal” en la página 49
“Ejemplo: Trust intrazonal” en la página 52
“Ejemplo: VPN de malla completa para SIP” en la página 55
Ejemplos 31
Soporte de llamadas SIP entrantes utilizando el registrador SIP

El registro SIP proporciona una función de descubrimiento que permite a los
proxies y servidores de ubicaciones SIP identificar las ubicaciones donde los
usuarios desean ser contactados. Un usuario registra una o más ubicaciones de
contacto enviando un mensaje REGISTER al registrador. Los campos To: y Contact:
en el mensaje REGISTER contienen la URI de la dirección del registro y al menos
una URI de contacto, según se muestra en la Figura 11. El registro crea enlaces en
un servicio de ubicación que asocia la dirección del registro a la dirección o a las
direcciones de contacto.
El dispositivo de seguridad supervisa los mensajes REGISTER salientes, aplica NAT a

estas direcciones y almacena la información en una tabla de DIP entrante.
A continuación, cuando se recibe un mensaje INVITE desde fuera de la red, el
dispositivo de seguridad utiliza la tabla de DIP entrante para identificar a qué host
interno enrutar el mensaje INVITE. Puede aprovechar el servicio de registro del
proxy SIP para permitir llamadas entrantes configurando DIP de interfaz o rangos
DIP en la interfaz de salida del dispositivo de seguridad. DIP de interfaz es
adecuado para gestionar llamadas entrantes en una pequeña oficina, mientras que
la creación de rangos DIP se recomienda para redes más grandes o entornos
empresariales.
NOTA: El soporte de llamadas entrantes usando DIP de interfaz o un rango DIP sólo se
admite para los servicios SIP y H.323.
Para llamadas entrantes, actualmente los dispositivos de seguridad sólo admiten

UDP y TCP. Hoy por hoy tampoco se admite la resolución de nombres de dominio,
por lo que las URI deben contener direcciones IP, según se muestra en la
Figura 11.
32 Ejemplos
Figura 11: SIP entrante
Tabla de DIP entrante

5.5.5.1 : 1234 6.6.6.1 : 5555 3600
SIP ph1 5.5.5.1 5.5.5.2 6.6.6.1 Registrador 6.6.6.2
REGISTER sip: 6.6.6.2 SIP/2.0

From: ph1@5.5.5.1 Agregar entrada
To: ph1@5.5.5.1 a la tabla de DIP
CSeq 1 INVITE entrante REGISTER sip:6.6.6.2 SIP/2.0
Contact <sip: 5.5.5.1:1234> From: ph1@6.6.6.1
Expires: 7200 To: ph1@6.6.6.1
CSeq 1 INVITE
Contact <sip: 6.6.6.1:5555>
Expires: 7200
200 OK
From: ph1@6.6.6.1
200 OK To: ph1@6.6.6.1
From: ph1@5.5.5.1
Actualizar el
valor del tiempo CSeq 1 INVITE
To: ph1@5.5.5.1 Contact <sip: 6.6.6.1:5555>
CSeq 1 INVITE de espera
Expires: 3600
Contact <sip: 5.5.5.1:1234>
Expires: 3600
Ejemplo: Llamada entrante (DIP de interfaz)

En este ejemplo, phone1 se encuentra en la interfaz ethernet1 en la zona Trust y
phone2 y el servidor proxy en la interfaz ethernet3 de la zona Untrust. Configurará
la DIP de interfaz en la interfaz ethernet3 para aplicar NAT a las llamadas entrantes,
a continuación creará una directiva que permita el tráfico SIP desde la zona Untrust
a la zona Trust y hará referencia a esa DIP en la directiva. También creará una
directiva que permita el tráfico SIP desde la zona Trust a la zona Untrust utilizando
NAT Source. Esto permitirá a phone1 en la zona Trust registrarse en el proxy de la
zona Untrust. Para obtener una explicación sobre cómo funciona DIP entrante con
el servicio de registro SIP, consulte “Ejemplos” en la página 31.
Ejemplos 33
Figura 12: Llamada entrante con DIP de interfaz en la Interfaz ethernet2

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Trust Untrust
LAN Internet
DIP de interfaz en
ethernet 3
phone2 Servidor proxy
phone1 1.1.1.3
10.1.1.3 1.1.1.4
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Direcciones
Address Name: phone1

Zone: Trust

Zone: Untrust
34 Ejemplos
Address Name: proxy

Zone: Untrust
Network > Interface > Edit (para ethernet3) > DIP > New: Seleccione la
opción NAT entrante y haga clic en OK.
4. Directivas
haga clic en OK:
Source Address
Address Book Entry: (seleccione), phone1
Destination Address
Address Book Entry: (seleccione), any
Service: SIP
Action: Permit
NAT:
(DIP on): None (utilizar la IP de la interfaz de salida)
haga clic en OK:
Source Address
Destination Address
Address Book Entry: (seleccione), DIP(ethernet3)
Service: SIP
Action: Permit
CLI
1. Interfaces
set interface ethernet3 route
2. Direcciones
set address trust phone1 10.1.1.3/24
set address untrust phone2 1.1.1.4/24
set address untrust proxy 1.1.1.3/24
set interface ethernet3 dip interface-ip incoming
set dip sticky
Ejemplos 35
4. Directivas
set policy from trust to untrust phone1 any sip nat src permit
set policy from untrust to trust any dip(ethernet3) sip permit
save
Ejemplo: Llamada entrante (conjunto de DIP)

En este ejemplo, phone1 se encuentra en la zona Trust y phone2 y el servidor proxy
en la zona Untrust. Configurará un rango DIP en la interfaz ethernet3 para aplicar
NAT a las llamadas entrantes y a continuación creará una directiva que permita el
tráfico SIP desde la zona Untrust a la zona Trust y hará referencia al rango DIP en la
directiva. También creará una directiva que permita el tráfico SIP desde la zona
Trust a la zona Untrust utilizando NAT Source. Esto permitirá a phone1 en la zona
Trust registrarse en el proxy de la zona Untrust. Para obtener una explicación sobre
cómo funciona DIP con el servicio de registro SIP, consulte “Ejemplos” en la
página 31.
Figura 13: Llamada entrante con conjunto de DIP

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Trust Untrust
LAN Internet
Conjunto de DIP en ethernet3

1.1.1.20 ->1.1.1.40
phone1 phone2 Servidor proxy
10.1.1.3 1.1.1.4 1.1.1.3
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

36 Ejemplos
2. Direcciones

Zone: Trust

Zone: Untrust
Address Name: proxy

Zone: Untrust
3. Conjunto de DIP con NAT entrante
Network > Interface > Edit (para ethernet3) > DIP > New: Introduzca los
ID: 5
4. Directivas
haga clic en OK:
Source Address
Destination Address
Service: SIP
Action: Permit
NAT:
(DIP on): 5 (1.1.1.20-1.1.1.40)/port-xlate
Ejemplos 37
haga clic en OK:
Source Address
Destination Address
Address Book Entry: (seleccione), DIP(5)
Service: SIP
Action: Permit
CLI
1. Interfaces
2. Direcciones
3. Conjunto de DIP con NAT entrante
set interface ethernet3 dip 5 1.1.1.20 1.1.1.40 incoming
set dip sticky
4. Directivas
set policy from trust to untrust phone1 any sip nat src dip 5 permit
set policy from untrust to trust any dip(5) sip permit
save
Ejemplo: Llamada entrante con MIP

phone2 y el servidor proxy en la interfaz ethernet3 de la zona Untrust. Pondrá una
MIP en la interfaz ethernet3 para phone1, luego creará una directiva que permita el
tráfico SIP desde la zona Untrust a la zona Trust y hará referencia a esa MIP en la
directiva. También creará una directiva permitiendo que phone1 se registre con el
servidor proxy en la zona Untrust. Este ejemplo es similar a los dos ejemplos
anteriores (“Ejemplo: Llamada entrante (DIP de interfaz)” en la página 33 y
“Ejemplo: Llamada entrante (conjunto de DIP)” en la página 36), salvo que con una
MIP se necesita una dirección pública por cada dirección privada en la zona Trust,
mientras que con DIP de interfaz o un conjunto de DIP una sola dirección de
interfaz puede servir múltiples direcciones privadas.
38 Ejemplos
Figura 14: Llamada entrante con MIP
ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Trust Untrust
LAN Internet
Servidor proxy
Dispositivo virtual MIP

phone1 en ethernet3 1.1.1.1/24
phone2
10.1.1.3 1.1.1.4
WebUI
1. Interfaces
haga clic en Apply:
Zone: Trust
Interface Mode: NAT
haga clic en OK:
Zone: Untrust
2. Direcciones

Zone: Trust

Zone: Untrust
Ejemplos 39
Address Name: proxy

Zone: Untrust
3. MIP
Mapped IP: 1.1.1.3

Netmask: 255.255.255.255
4. Directiva
haga clic en OK:
Source Address:
Service: SIP
Action: Permit
CLI
1. Interfaces
2. Direcciones
3. MIP
4. Directiva
set policy from untrust to trust any mip(1.1.1.3) sip permit
save
Ejemplo: Proxy en la zona privada

En este ejemplo, phone1 y el servidor proxy SIP están en la interfaz ethernet1 en la
zona (privada) Trust, y phone2 está en la interfaz ethernet3 en la zona Untrust.
Pondrá una MIP en la interfaz ethernet3 hacia el servidor proxy para permitir que
phone2 se registre en el proxy y luego creará una directiva permitiendo el tráfico
SIP desde la zona Untrust a la zona Trust y hará referencia a esa MIP en la directiva.
También creará una directiva desde la zona Trust a la zona Untrust para permitir
que phone1 efectúe llamadas externas.
40 Ejemplos
Figura 15: Proxy en la zona privada

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Trust Untrust
LAN Internet
Dispositivo virtual
MIP en ethernet3
Servidor proxy phone1 1.1.1.2 -> 10.1.1.4 phone2
10.1.1.4 10.1.1.3 1.1.1.4
WebUI
1. Interfaces
haga clic en OK:
Zone: Trust
Interface Mode: NAT
haga clic en OK:
Zone: Untrust
2. Direcciones

Zone: Trust

Zone: Untrust
Address Name: proxy

Zone: Trust
Ejemplos 41
3. MIP
Network > Interfaces > Edit (para loopback.3) > MIP > New: Introduzca los
Mapped IP: 1.1.1.2

Netmask: 255.255.255.255
4. Directivas
haga clic en OK:
Source Address:
Service: SIP
Action: Permit
NAT:
haga clic en OK:
Source Address:
Service: SIP
Action: Permit
CLI
1. Interfaces
2. Direcciones
set address trust proxy 10.1.1.4/24
3. MIP
4. Directivas
set policy from trust to untrust any phone2 sip nat src permit
set policy from untrust to trust phone2 mip(1.1.1.2) sip permit
save
42 Ejemplos
Ejemplo: Proxy en la zona pública

phone2 y el servidor proxy en la interfaz ethernet3 de la zona (pública) Untrust.
Configurará DIP de interfaz en la interfaz Untrust y creará una directiva
permitiendo el tráfico SIP desde la zona Untrust a la zona Trust y hará referencia a
esa DIP en la directiva. También creará una directiva de Trust a Untrust para
permitir que phone1 se registre en el servidor proxy en la zona Untrust. Este
ejemplo es similar a los ejemplos anteriores de llamadas entrantes (consulte
“Ejemplo: Llamada entrante (conjunto de DIP)” en la página 36 y “Ejemplo:
Llamada entrante con MIP” en la página 38) y, como en esos ejemplos, puede
utilizar DIP o MIP en la interfaz Untrust.
Figura 16: Proxy en la zona pública

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Trust Untrust
LAN Internet
DIP de interfaz
en ethernet3
phone1 phone2 Servidor proxy
10.1.1.3 1.1.1.4 1.1.1.3
WebUI
1. Interfaces
haga clic en Apply:
Zone: Trust
Interface Mode: NAT
haga clic en OK:
Zone: Untrust
2. Direcciones

Zone: Trust
Ejemplos 43

Zone: Untrust
Address Name: proxy

Zone: Untrust
3. DIP de interfaz
Network > Interface > Edit (para ethernet3) > DIP: Seleccione la casilla de
verificación Incoming NAT.
4. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione) phone1
Address Book Entry: (seleccione) Any
Service: SIP
Action: Permit
NAT:
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), DIP(ethernet3)
Service: SIP
Action: Permit
CLI
1. Interfaces
44 Ejemplos
2. Direcciones
3. DIP de interfaz
4. Directivas
set policy from trust to untrust phone1 any sip nat src permit
set policy from untrust to trust any dip(ethernet3) sip permit
save
Ejemplo: Zona triple, proxy en DMZ

En este ejemplo, phone1 se encuentra en la interfaz ethernet1 de la zona Trust,
phone2 en la interfaz ethernet3 de la zona Untrust y el servidor proxy en la interfaz
ethernet2 de DMZ. Situará una MIP en la interfaz ethernet2 hacia phone1 en la
zona Trust, creará una directiva desde DMZ a la zona Trust y luego hará referencia a
esa MIP en la directiva. De hecho, con tres zonas necesitará crear directivas
bidireccionales entre cada una de ellas. Las flechas en la Figura 17 muestran el flujo
del tráfico SIP cuando phone2 de la zona Untrust genere una llamada a phone1 en
la zona Trust. Después de iniciar la sesión, los medios fluyen directamente entre
phone1 y phone2.
Figura 17: Proxy en DMZ
Untrust
Internet
phone2
1.1.1.4
ethernet3
1.1.1.1/24
ethernet2
2.2.2.2/24
DMZ
Dispositivo
de seguridad Servidor proxy
2.2.2.4
ethernet1
10.1.1.1/24
Dispositivo virtual
MIP en ethernet2
2.2.2.3-> 10.1.1.3
LAN
phone1
10.1.1.3
Trust
Ejemplos 45
WebUI
1. Interfaces
haga clic en Apply:
Zone: Trust
Interface Mode: NAT
haga clic en OK:
Zone Name: DMZ

haga clic en OK:
Zone Name: Untrust

2. Dirección

Zone: Trust

Zone: Untrust
Address Name: proxy

Zone: DMZ
3. MIP
Mapped IP: 2.2.2.3

Netmask: 255.255.255.255
46 Ejemplos
4. Directivas
clic en OK:
Source Address:
Address Book Entry: (seleccione), proxy
Service: SIP
Action: Permit
> Advanced: Escriba lo siguiente, haga clic en Return para establecer las
NAT:
Source Translation: Enable
haga clic en OK:
Source Address:
Service: SIP
Action: Permit
haga clic en OK:
Source Address:
Service: SIP
Action: Permit
haga clic en OK:
Source Address:
Service: SIP
Action: Permit
Policies > (From: DMZ, To: Trust) New: Introduzca los siguientes datos y haga
clic en OK:
Source Address:
Service: SIP
Action: Permit
Ejemplos 47
haga clic en OK:
Source Address:
Service: SIP
Action: Permit
> Advanced: Escriba lo siguiente, haga clic en Return para establecer las
NAT:
CLI
1. Interfaces
2. Direcciones
set address dmz proxy 2.2.2.4
3. MIP
set interface2 mip 2.2.2.3 host 10.1.1.3
4. Directivas
set policy from trust to dmz phone1 proxy sip nat src permit
set policy from dmz to untrust proxy phone2 sip permit
set policy from untrust to trust phone2 phone1 sip permit
set policy from untrust to dmz phone2 proxy sip permit
set policy from dmz to trust proxy mip(2.2.2.3) sip permit
set policy from trust to untrust phone1 phone2 sip nat src permit
save
48 Ejemplos
Ejemplo: Untrust intrazonal

En este ejemplo, phone1 se encuentra en la interfaz ethernet4 de la zona Untrust,
phone2 en una subred en la interfaz ethernet3 de la zona Untrust y el servidor
proxy en la interfaz ethernet1 de la zona Trust. Para permitir tráfico SIP intrazonal
entre los dos teléfonos de la zona Untrust, creará una interfaz de bucle invertido
(loopback), agregará ethernet3 y ethernet4 a un grupo de bucle invertido y
finalmente situará una MIP en la interfaz de bucle invertido apuntando a la
dirección IP del servidor proxy. Crear una interfaz de bucle invertido le permitirá
utilizar una sola MIP para el servidor proxy en la zona Trust. Dado que el bloqueo
está activado de forma predeterminada en la zona Untrust, también debe
desactivarlo para permitir la comunicación intrazonal. Si desea más información
acerca del uso de interfaces de bucle invertido, consulte “MIP y la interfaz de bucle
invertido” en la página 8-74.
Figura 18: Untrust intrazonal
Untrust
phone1 phone2
1.1.1.4 1.1.2.4
Internet
ethernet4 ethernet3
1.1.1.1./24 1.1.2.1/24
Loopback 1
1.1.4.1/24
MIP en Loopback.1
1.1.4.5 -> 10.1.1.5
ethernet1
10.1.1.1/24
LAN
proxy
10.1.1.5
Trust
Ejemplos 49
WebUI
1. Interfaces
haga clic en Apply:
Zone: Trust
Interface Mode: NAT
haga clic en OK:
Zone: Untrust
haga clic en OK:
Zone: Untrust
haga clic en OK:

2. Direcciones
Address Name: proxy

Zone: Trust

Zone: Untrust
50 Ejemplos

Zone: Untrust
3. Grupo de bucle invertido
haga clic en OK:
As member of loopback group: (select), loopback.1

Zone Name: Untrust
haga clic en OK:
As member of loopback group: (select), loopback.1

Zone Name: Untrust
4. MIP
Mapped IP: 1.1.4.5

Netmask: 255.255.255.255
5. Bloqueo
clic en OK:

6. Directivas
haga clic en OK:
Source Address:
Service: SIP
Action: Permit
NAT:
Ejemplos 51
haga clic en OK:
Source Address:
Service: SIP
Action: Permit
CLI
1. Interfaces
set interface loopback.1 route
2. Direcciones
set interface ethernet3 loopback-group loopback.1
4. MIP
set interface loopback.1 mip 1.1.4.5 host 10.1.1.5
5. Bloqueo
6. Directivas
set policy from trust to untrust proxy any sip nat src permit
set policy from untrust to trust any mip(1.1.4.5) sip permit
save
Ejemplo: Trust intrazonal

En este ejemplo, phone1 se encuentra en la interfaz ethernet1 de la zona Trust,
phone2 en la interfaz ethernet2 en una subred de la zona Trust y el servidor proxy
en la interfaz ethernet3 de la zona Untrust. Para permitir que ambos teléfonos de la
zona Trust se comuniquen entre sí, configurará DIP de interfaz en la interfaz
ethernet3 para permitir que entren en contacto con el servidor proxy y luego
establecerá directivas determinadas para permitir el tráfico SIP bidireccional entre
las zonas Trust y Untrust. De forma predeterminada, el bloqueo está desactivado en
la zona Trust (como lo está en las zonas personalizadas que defina).
52 Ejemplos
Figura 19: Trust intrazonal

phone1 ethernet1 ethernet3 Servidor proxy
10.1.1.3 10.1.1.1/24 3.3.3.3/24 3.3.3.4
Trust Untrust
Internet
LAN
DIP de interfaz
phone2 ethernet2 en ethernet3
10.1.2.2 10.1.2.1/24
WebUI
1. Interfaces
haga clic en Apply:
Zone: Trust
Interface Mode: NAT
haga clic en Apply:
Zone: Trust
Interface Mode: NAT
haga clic en OK:
Zone: Untrust
2. Direcciones

Zone: Trust
Ejemplos 53

Zone: Trust
Address Name: proxy

Zone: Untrust
Network > Interface > Edit (para ethernet3) > DIP > New: Introduzca los

4. Directivas
haga clic en OK:
Source Address:
Service: SIP
Action: Permit
NAT:
haga clic en OK:
Source Address
Address Book Entry: (seleccione) proxy
Destination Address
Address Book Entry: (seleccione) Any
Service: SIP
Action: Permit
> Advanced: Introduzca los siguientes datos, luego haga clic en Return
para establecer las opciones avanzadas:
NAT:
54 Ejemplos
CLI
1. Interfaces
2. Direcciones
3. DIP de interfaz
4. Directivas
set policy from trust to untrust any proxy sip nat src permit
set policy from untrust to trust proxy dip(ethernet3) sip permit
save
Ejemplo: VPN de malla completa para SIP

En este ejemplo, la oficina central y dos sucursales están unidas por una VPN de
malla completa. Cada sitio tiene un solo dispositivo de seguridad. El servidor proxy
se encuentra en la zona Trust de la oficina central, phone1 en la zona Trust de la
sucursal primera y phone2 en la zona Trust de la sucursal segunda. Todas las
interfaces que conectan los dispositivos se encuentran en sus respectivas zonas
Untrust. En cada dispositivo configurará dos túneles, uno hacia cada uno de los
otros dispositivos, para crear una red completamente interconectada.
NOTA: Los dispositivos de seguridad utilizados en este ejemplo deben tener disponibles
por lo menos tres interfaces configurables independientemente.
Ejemplos 55
Figura 20: VPN de malla completa para SIP
Proxy
Nota: La zona Untrust de cada Oficina central 10.1.3.3
dispositivo no se muestra Zona Trust
Trust
eth2/8-10.1.3.1
túnel 1 túnel 2
6.6.6.6 Central 7.7.7.7
Untrust eth2/1: Untrust eth2/2
1.1.1.1 1.1.2.1
Enrutador de puerta de Enrutador de puerta de

enlace a central: 1.1.1.1 enlace a central: 1.1.2.1
A sucursal: 3.3.3.3 VPN 1 VPN 2 A sucursal: 2.2.2.2
Untrust eth3 Untrust eth3

3.3.3.3 2.2.2.2
interfaz tunnel.1 sin VPN 3 interfaz tunnel.2 sin
numerar Sucursal 1 Sucursal-2 numerar
Trust eth1 Untrust Untrust Trust eth1

10.1.1.1 eth4-4.4.4.4 eth4-5.5.5.5 10.1.2.1
Enrutador de puerta de enlace
Zona Trust A sucursal-1: 4.4.4.4 Zona Trust
A sucursal-2: 5.5.5.5
Sucursal primera interfaz tunnel.3 sin interfaz tunnel.3 sin Sucursal segunda
phone1 numerar numerar phone2
10.1.1.3 10.1.2.3
WebUI (para la central)

1. Interfaces
Zone: Untrust
Zone: Untrust
56 Ejemplos
Zone: Trust
Interface Mode: route
clic en Apply:

Zone (VR): Untrust
clic en Apply:

Zone (VR): Untrust
2. Dirección
Address Name: Proxy

IPv4/Netmask: 10.1.3.3/32
Zone: Trust
3. VPN
y haga clic en OK:
Gateway Name: to-branch-1

IPvc4/v6 Address/Hostname: 3.3.3.3
Preshare Key: netscreen
VPN Name: vpn-branch-1
Advanced: Introduzca los siguientes ajustes avanzados y haga clic

enlace:
Bind to: (seleccione) Tunnel Interface, tunnel.1
Ejemplos 57
y haga clic en OK:


enlace:

4. Enrutamiento
haga clic en OK:

interface (seleccione): tunnel.1
haga clic en OK:

5. Directivas
haga clic en OK:
Source Address (seleccione) Address Book Entry: Proxy

Destination Address (seleccione) Address Book Entry: Any-IPv4
Service: SIP
Action: Permit
haga clic en OK:
Source Address (seleccione) Address Book Entry: Any-IPv4

Destination Address (seleccione) Address Book Entry: Proxy
Service: SIP
Action: Permit
58 Ejemplos
CLI (para la central)

1. Interfaces
2. Dirección
3. VPN
set ike gateway to-branch-1 address 3.3.3.3 main outgoing-interface ethernet2/1
preshare netscreen sec-level standard
set vpn vpn_branch-1 gateway to-branch-1 no-reply tunnel idletime 0 sec-level
standard
set vpn vpn-branch-1 id 1 bind interface tunnel.1
set vpn vpn-branch-2 gateway to-branch-2 no-reply tunnel idletime 0 sec-level
standard
4. Enrutamiento
5. Directivas
set policy from untrust to trust any proxy sip permit
set policy from trust to untrust proxy any sip permit
save
WebUI (Sucursal 1)
1. Interfaces
haga clic en Apply:
Zone: Trust
Interface Mode: NAT
haga clic en Apply:
Zone: Untrust
Ejemplos 59
haga clic en Apply:
Zone: Untrust
clic en Apply:

Zone (VR): Untrust
Unnumbered (seleccione) Interface: ethernet3
clic en Apply:

Zone (VR): Untrust
2. Dirección

Zone: V1-Trust
3. VPN
y haga clic en OK:
Gateway Name: to-central

VPN Name: vpn-central

enlace:
Bind to (seleccione): Tunnel Interface, tunnel.1
y haga clic en OK:
Gateway Name: to-ns50

60 Ejemplos
VPN Name: vpn-ns50

enlace:

4. Enrutamiento
haga clic en OK:

haga clic en OK:

5. Directivas
haga clic en OK:
Source Address (seleccione) Address Book Entry: phone2

Service: SIP
Action: Permit
haga clic en OK:

Destination Address (seleccione) Address Book Entry: phone2
Service: SIP
Action: Permit
CLI (Sucursal 1)
1. Interfaces
2. Dirección
Ejemplos 61
3. VPN
set ike gateway to-central address 1.1.1.1 main outgoing-interface ethernet3
set ike gateway to-ns50 address 5.5.5.5 main outgoing-interface ethernet4
set vpn vpncentral gateway to-central no-replay tunnel idletime 0 sec-level standard
set vpn vpncentral bind interface tunnel.1
set vpn vpn-ns50 gateway to-ns50 no-replay tunnel idletime 0 sec-level standard
set vpn vpn-ns50 bind interface tunnel.3
4. Rutas
5. Directivas
set policy from trust to untrust phone1 any sip permit
set policy from untrust to trust any phone1 sip permit
save
WebUI (Sucursal 2)
1. Interfaces
haga clic en Apply:
Zone: Trust
Interface Mode: NAT
haga clic en Apply:
Zone: Untrust
haga clic en Apply:
Zone: Untrust
clic en Apply:

Zone (VR): Untrust
clic en Apply:

Zone (VR): Untrust
62 Ejemplos
2. Dirección

Zone: Trust
3. VPN
y haga clic en OK:


enlace:
y haga clic en OK:

VPN Name: vpn-ns50

enlace:

4. Enrutamiento
haga clic en OK:

Ejemplos 63
haga clic en OK:

5. Directivas
Policies > (From: Trust, To: Untrust) Introduzca los siguientes datos y haga clic
en OK:
Source Address (seleccione) Address Book Entry: phone2

Service: SIP
Action: Permit
haga clic en OK:

Destination Address (seleccione) Address Book Entry: phone2
Service: SIP
Action: Permit
CLI (Sucursal 2)
1. Interfaces
2. Dirección
3. VPN
set ike gateway to-central address 1.1.2.1 Main outgoing-interface ethernet3
set ike gateway to-ns50 address 4.4.4.4Main outgoing-interface ethernet4
set vpn vpncentral id 4 bind interface tunnel.2
set vpn vpn-ns50 id 5 bind interface tunnel.3
4. Rutas
5. Directivas
set policy from trust to untrust phone2 any sip permit
set policy from untrust to trust any phone2 sip permit
save
64 Ejemplos
Administración del ancho de banda para servicios de VoIP

Recomendamos los siguientes métodos de administración del ancho de banda para
servicios de VoIP, utilizando los mecanismos de asignación de tráfico estándar de
ScreenOS:
Garantizar el ancho de banda para el tráfico VoIP: La manera más eficaz de

asegurar calidad para el servicio VoIP sin impedir otros tipos de tráfico en la
interfaz, consiste en crear una directiva que garantice el ancho de banda
mínimo necesario para la cantidad prevista de tráfico VoIP en la interfaz y
establecer una cola de prioridades al más alto nivel. La ventaja de esta
estrategia es que el tráfico VoIP podrá utilizar ancho de banda adicional cuando
esté disponible, mientras que otros tipos de tráfico podrán utilizar el ancho de
banda no garantizado para VoIP cuando el tráfico VoIP no lo esté utilizando.
Limitar el ancho de banda para el tráfico ajeno a VoIP: Estableciendo un ancho

de banda máximo para el tráfico ajeno a VoIP, se pone el ancho de banda
restante a disposición del tráfico VoIP. También se establecerá una cola de
prioridades al más alto nivel para el tráfico VoIP. El inconveniente de este
método es que el tráfico ajeno a VoIP no puede utilizar ancho de banda
adicional aunque el tráfico VoIP no lo esté utilizando.
Utilizar una cola de prioridades y las marcas de punto de código de servicios

diferenciados (Differentiated Services Codepoin, DSCP): Garantizando el ancho
de banda para el tráfico VoIP y limitando el ancho de banda para el tráfico
ajeno a VoIP se permite controlar el flujo de datos en el dispositivo de
seguridad. El marcado DSCP permite conservar los ajustes de cola de
prioridades en sentido descendente, así como mantener o cambiar el valor
DSCP recibido establecido por el dispositivo de red o enrutador emisor en
sentido ascendente, de modo que el enrutador del siguiente salto,
generalmente el enrutador LAN o WAN “fronterizo”, pueda hacer cumplir la
calidad del servicio (QoS) en su dominio DiffServ. En las configuraciones VPN,
el dispositivo de seguridad marca el encabezado exterior del paquete IP (si la
directiva está configurada para hacer esto), o deja el byte TOS como 0, para que
el siguiente enrutador de salto pueda forzar la QoS correcta en el tráfico
encriptado. Para obtener información sobre el funcionamiento de DSCP con
niveles de prioridad en directivas, consulte “Asignación de tráfico” en la
página 175.
La Figura 21 en la página 66muestra cómo los ajustes de niveles de prioridad

pueden afectar al uso del ancho de banda garantizado (“guaranteed bandwidth” o
gbw) y del ancho de banda máximo (“maximum bandwidth” o mbw) en una
interfaz ethernet1 (2 Mbps). La ilustración asume que se ha determinado la
necesidad de permitir al menos ocho llamadas de VoIP (ancho de banda de 8 x 64
kbps por llamada, obteniendo un total de 512 kbps) y, ocasionalmente, hasta 16
llamadas. Ha garantizado el ancho de banda restante al tráfico general de la oficina
y ha establecido el ancho de banda máximo para que el tráfico de la oficina
disponga del ancho de banda no garantizado al servicio de VoIP. Esto crea una
superposición de 512 kbps en el ancho de banda máximo para los servicios de VoIP
y del tráfico de la oficina, indicado mediante líneas discontinuas.
Ejemplos 65
El lado izquierdo de la Figura 21 muestra la utilización del ancho de banda con esos
ajustes y una utilización elevada de tráfico de oficina y un nivel de utilización bajo
de VoIP atravesando la interfaz. Si el tráfico VoIP necesitase repentinamente más
ancho de banda, no podría conseguirla a menos que su prioridad fuese superior a la
de los servicios del tráfico de la oficina. El lado derecho de la Figura 21 muestra el
grado de utilización del ancho de banda en las mismas circunstancias que cuando
el tráfico de VoIP tiene prioridad superior y el tráfico de la oficina tiene una
prioridad inferior. Para obtener más información sobre niveles de configuración de
ancho de banda y de la prioridad, consulte “Asignación de tráfico” en la
página 2-195.
Figura 21: Ajustes de nivel de prioridad
Ajustes de ancho de banda garantizado y máximo Añadiendo los ajustes de nivel de prioridad
VoIP
gbw 512 kbps Tráfico de
VoIP
VoIP
Ancho de banda mbw 1536 kbps mbw 1024 kbps Ancho de banda
total de 2 Mbps total de 2 Mbps
Tráfico de la oficina gbw 1024 kbps

Tráfico de la oficina
Tráfico de la oficina
66 Ejemplos
Capítulo 3
aplicación de protocolo de control de la
puerta de medios
Este capítulo ofrece una vista general de la puerta de enlace en la capa de

aplicación del protocolo de control de la puerta de medios (Gateway Control
Protocol o MGCP) y enumera las características de seguridad de cortafuegos de la
implementación. Después de un resumen de la arquitectura de MGCP se presentan
ejemplos de las situaciones típicas. Este capítulo incluye las siguientes secciones:
“Seguridad de MGCP” en la página 68
“Protocolo MGCP” en la página 68
Vista general
El protocolo de control de la puerta de medios (MGCP) se admite en los dispositivos
de seguridad en modo de ruta, modo transparente y modo de traducción de
direcciones de red (NAT). MGCP es un protocolo de la capa de aplicación basado en
texto que se utiliza para establecer y controlar llamadas. MGCP se basa en una
arquitectura de control de llamadas maestro-esclavo en el que el controlador de la
puerta de medios, por medio del agente de llamada, mantiene inteligencia de
control de las llamadas, mientras que las puertas de medios siguen las instrucciones
del agente de llamadas.
La ALG con MGCP realiza los siguiente procedimientos:
Realiza la inspección de la carga de la trama de señalización de VoIP. La carga

de la trama del paquete de señalización VoIP entrante se inspecciona
completamente según las normas RFC relacionadas y las normas de cada
fabricante. Si se descubre algún ataque de paquetes malformados, la ALG los
bloquea.
Realiza la inspección de la carga de la trama de señalización de MGCP. La carga

del paquete de señalización de MGCP entrante se inspecciona completamente
según la norma RFC 3435. Si se descubre algún ataque de paquetes
malformados, la ALG los bloquea.
Vista general 67
Ofrece procesamiento del estado. Invoca las máquinas de estado basadas en el

protocolo VoIP para procesar la información analizada. Cualquier paquete que
esté fuera de estado o fuera de transacción se identifica y se maneja
apropiadamente.
Ejecuta la traducción de direcciones de red (NAT). Cualquier información de

puerto y dirección IP incrustada en la carga de trama se convierte
apropiadamente con base en la información de enrutamiento existente y la
topología de la red y se reemplaza, si es necesario, con el número de puerto y
dirección IP traducida.
Maneja ojos de aguja para tráfico de VoIP. Para mantener la red VoIP segura,
ALG identifica la información del puerto y dirección IP utilizada para medios o
señalización y crea de forma dinámica cualquier ojo de aguja que sea necesario
y lo cierra durante el establecimiento de la llamada.
Seguridad de MGCP
MGCP ALG incluye las siguientes características de seguridad:
Protección contra ataques de rechazo de servicio (DoS).—ALG realiza una

inspección de estado a nivel del paquete de UDP, a nivel de transacción y a
nivel de la llamada. Se procesan los paquetes de MGCP que coinciden con el
formato de mensaje RFC 3435, el estado de la transacción y el estado de la
llamada. Se descartan todos los demás.
Cumplimiento de las directivas de cortafuegos entre el controlador de la puerta

y la puerta (directivas de señalización).
Cumplimiento de las directivas de cortafuegos entre las puertas de enlace

(directivas de medios).
Control de inundaciones de mensajes MGCP por puerta. Si hay una puerta que
no funciona bien o está pirateada, no se interrumpirá la red completa de VoIP.
Al combinarla con el control de inundación por cada puerta de enlace, el daño
se reduce a la puerta de enlace afectada.
Control de inundaciones de conexión MGCP por puerta.
Cambio y conmutación por error sin fisuras si las llamadas, incluidas las
llamadas en curso, se conmutan al cortafuegos que está en espera por si se
producen fallos del sistema.
Protocolo MGCP
El MGCP es un protocolo de la capa de aplicación basado en texto que se utiliza
para establecer y controlar llamadas. El protocolo se basa en una arquitectura de
control de llamadas maestro/esclavo: El controlador de la puerta de medios (agente
de llamada) mantiene la inteligencia de control de la llamada y las puertas de
medios siguen las instrucciones del agente de llamada.
68 Seguridad de MGCP
Capítulo 3: Puerta de enlace en la capa de aplicación de protocolo de control de la puerta de medios
Entidades en MGCP
Hay cuatro entidades básicas en MGCP:
“Punto final” en la página 69
“Conexión” en la página 69
“Llamada” en la página 69
“Agente de llamada” en la página 70
Punto final
Una puerta de medios (MG) es una colección de puntos finales. Un punto final
puede ser una línea analógica, una troncal o cualquier otro punto de acceso. Un
punto final se denomina de la siguiente manera:
nombre-punto-final-local@nombre-dominio
A continuación se incluyen algunos identificadores válidos de puntos finales:
group1/Trk8@mi_red.net
group2/Trk1/*@[192.168.10.8] (comodines)
$@voiptel.net (cualquier punto final dentro de MG)
*@voiptel.net (todos los puntos finales dentro de MG)
Conexión
Las conexiones se crean en cada punto final por medio de una MG durante el
establecimiento de llamadas. Una llamada VoIP típica implica dos conexiones: Una
llamada compleja, por ejemplo una llamada de terceros o llamada de conferencia,
podría requerir más conexiones. El controlador de la puerta de medios (MGC)
puede instruir a las puertas de medios para crear, modificar, eliminar y auditar una
conexión.
La identificación de la conexión representa a una conexión. La MG crea dicha

conexión cuando se le solicita que lo haga. La ID de conexión se presenta como una
cadena hexadecimal, con una longitud máxima de 32 caracteres.
Llamada
La identificación de la llamada representa la llamada. MGC crea dicha identificación
al establecer una nueva llamada. La identificación de la llamada es una cadena
hexadecimal con una longitud máxima de 32 caracteres. La identificación de la
llamada es única dentro de MGC. Dos o más conexiones pueden tener la misma
identificación de llamada, siempre que pertenezcan a la misma llamada.
Protocolo MGCP 69
Agente de llamada
El protocolo MGCP admite uno o más agentes de llamada (también llamados
controladores de la puerta de medios) para mejorar la fiabilidad en la red VoIP.
A continuación se incluyen dos ejemplos de nombres de agentes de llamada:
AgenteLlamada@voipCA.mi_red.com
voipCA.mi_red.com
Diversas direcciones de red se pueden asociar bajo un nombre de dominio en el

sistema de nombres de dominios (DNS). Al dar seguimiento al tiempo de vida (TTL)
de lo datos de consulta/respuesta del DNS e implementar la retransmisión a través
de direcciones de red alternas, se logra la conmutación y cambio en caso de fallo en
el MGCP.
El concepto de entidad notificada es esencial en MGCP. La entidad notificada para un

punto final es el agente de llamada que actualmente controla ese punto final. Un
punto final debe enviar cualquier comando MGCP a su entidad notificada.
Sin embargo, distintos agentes de llamadas podrían enviar comandos MGCP a este
punto final.
La entidad notificada se establece en un valor provisional en el arranque, pero

podría cambiar si un agente de llamada utiliza un parámetro de entidad notificada
incluido en el mensaje MGCP. Si la entidad notificada para un punto final está vacía
o no se ha establecido explícitamente, su valor se predetermina en la dirección de
origen del último comando MGCP no auditado satisfactoriamente que se recibió
para ese puno final.
Comandos
El protocolo MGCP define nueve comandos para controlar los puntos finales y las
conexiones. Todos los comandos están compuestos de un encabezado del
comando, seguido opcionalmente por la información del protocolo de descripción
de sesión (SDP). Un encabezado de comando tiene los siguientes elementos:
Una línea de comando: Verbo de comando + identificación de la

transacción + identificación del punto final + versión de MGCP.
Líneas de cero o más parámetros, compuestas de un nombre de parámetro,

seguido de un valor del parámetro.
La Tabla 3 enumera los comandos MGCP admitidos, con una descripción de cada
uno, la sintaxis del comando y ejemplos. Consulte RFC 2234 para obtener una
explicación completa de la sintaxis del comando.
70 Protocolo MGCP
Tabla 3: Comandos MGCP
Verbo del
comando Descripción Sintaxis del comando Ejemplos
EPCF EndpointConfiguration: ReturnCode EPCF 2012 wxx/T2@mi_red.com MGCP 1.0
utilizado por un agente de [PackageList] B: e:mu
llamada para informar EndpointConfiguration
sobre una puerta de (EndpointId,
características de [BearerInformation])
codificación (a-law o
mu-law) que se espera
recibir en el lado de la
línea correspondiente al
punto final.
CRCX CreateConnection: ReturnCode, CRCX 1205 aaln/1@gw-25.att.net MGCP 1.0
utilizado por un agente de [ConnectionId,] C: A3C47F21456789F0
llamada para indicarle a la [SpecificEndPointId,] L: p:10, a:PCMU
puerta que cree una [LocalConnectionDescriptor,] M: sendrecv
conexión con un punto [SecondEndPointId,] X: 0123456789AD
final dentro de la puerta. [SecondConnectionId,][Pac R: L/hd
kageList] S: L/rg
CreateConnection (CallId, v=0
EndpointId, o=- 25678 753849 IN IP4 128.96.41.1
[NotifiedEntity,] s=-
[LocalConnectionOption,] c=IN IP4 128.96.41.1
Mode, t=0 0
[{RemoteConnectionDescriptor | m=audio 3456 RTP/AVP 0
SecondEndpointId},]
[encapsulated RQNT,]
[encapsulated EPCF])
MDCX ModifyConnection: ReturnCode, MDCX 1210 aaln/1@rgw-25.att.net MGCP 1.0
utilizado por un agente de [LocalConnectionDescriptor,] C: A3C47F21456789F0
llamada para indicarle a [PackageList] I: FDE234C8
una puerta que cambie ModifyConnection (CallId, M: recvonly
los parámetros de una EndpointId, X: 0123456789AE
conexión existente. ConnectionId, R: L/hu
[NotifiedEntity,] S: G/rt
[LocalConnectionOption,] v=0
[Mode,] o=- 4723891 7428910 IN IP4 128.96.63.25
[RemoteConnectionDescriptor,] s=-
[encapsulated RQNT,] c=IN IP4 128.96.63.25
[encapsulated EPCF]) t=0 0
DLCX DeleteConnection: ReturnCode, Ejemplo 1: MGC -> MG
utilizado por un agente de ConnectionParameters, DLCX 9210 aaln/1@rgw-25.att.net MGCP 1.0
llamada para indicarle a [PackageList] C: A3C47F21456789F0
una puerta que elimine DeleteConnection (CallId, I: FDE234C8
una conexión existente. EndpointId,
ConnectionId, Ejemplo 2: MG -> MGC
Una puerta puede utilizar
el comando [NotifiedEntity,] DLCX 9310 aaln/1@rgw-25.att.net MGCP 1.0
DeleteConnection para [encapsulated RQNT,] C: A3C47F21456789F0
liberar una conexión que [encapsulated EPCF]) I: FDE234C8
ya no puede mantenerse. E: 900 - Hardware error
P: PS=1245, OS=62345, PR=780,
OR=45123, PL=10, JI=27, LA=48
Protocolo MGCP 71
Verbo del
RQNT Un agente de llamada ReturnCode, RQNT 1205 aaln/1@rgw-25.att.net MGCP 1.0
utiliza el comando [PackageList] N: ca-new@callagent-ca.att.net
NotificationRequest para NotificationRequest[ (EndpointId, X: 0123456789AA
indicarle a una MG que [NotifiedEntity,] R: L/hd(A, E(S(L/dl),R(L/oc,L/hu,D/[0-9#*T](D))))
supervise cierto(s) [RequestedEvents,] D: (0T|00T|xx|91xxxxxxxxxx|9011x.T)
evento(s) o señal(es) de RequestIdentifier, S:
un punto final específico. [DigitMap,] T: G/ft
[SignalRequests,]
[QuarantineHandling,]
[DetectEvents,]
[encapsulated EPCF])
NTFY Notify: lo utiliza una ReturnCode, NTFY 2002 aaln/1@rgw-25.att.net MGCP 1.0
puerta de enlace para [PackageList] N: ca@ca1.att.net:5678
informarle al agente de Notify (EndpointID, X: 0123456789AC
llamada cuando se [NotifiedEntity,] O: L/hd,D/9,D/1,D/2,D/0,D/1,D/8,D/2,D/9,D/4,
produce algún(os) RequestIdentifier, D/2,D/6,D/6
evento(s) o señal(es) ObservedEvents)
solicitada.
AUEP AuditEndpoint: lo utiliza ReturnCode, Ejemplo 1:
un agente de llamada EndPointIdList, | { AUEP 1201 aaln/1@rgw-25.att.net MGCP 1.0
para revisar el estado del [RequestedEvents,] F: A, R,D,S,X,N,I,T,O
punto final. [QuarantineHandling,] Ejemplo 2:
[DigitMap,] AUEP 1200 *@rgw-25.att.net MGCP 1.0
[SignalRequests,]
[RequestedIdentifier,]
[NotifiedEntity,]
[ConnectionIdentifier,]
[DetectEvents,]
[ObservedEvents,]
[EventStats,]
[BearerInformation,]
[BearerMethod,]
[RestartDelay,]
[ReasonCode,]
[MaxMGCPDatagram,]
[Capabilities]}
[PackageList]
AuditEndpoint (EndpointId,
[RequestedInfo])
72 Protocolo MGCP
Verbo del
AUCX AuditConnection: lo utiliza ReturnCode, AUCX 3003 aaln/1@rgw-25.att.net MGCP 1.0
el agente de llamada para [CallId,] I: 32F345E2
recopilar los parámetros [NotifiedEntity,] F: C,N,L,M,LC,P
que se aplicaron a una [LocalConnectionOptions,]
conexión. [Mode,]
[RemoteConnectionDescriptor,]
[LocalConnectionDescriptor,]
[ConnectionParameters,]
[PackageList]
AuditConnection (EndpointId,
ConnectionId,
RequestedInfo)
RSIP RestartInProgress: lo ReturnCode, RSIP 5200 aaln/1@rg2-25.att.net MGCP 1.0
utiliza una puerta de [NotifiedEntity,] RM: graceful
enlace para notificar a un [PackageList] RD: 300
agente de llamada de que RestartInProgress (EndpointId,
uno o varios puntos RestartMethod,
finales dejan de funcionar [RestartDelay,]
o vuelven a entrar en [ReasonCode])
funcionamiento.
Códigos de respuesta
Cada comando que envía el agente de llamada o la puerta de enlace, sea exitoso o
no, requiere un código de respuesta. El código de respuesta se encuentra en el
encabezado del mensaje de respuesta y, opcionalmente, también puede incluir la
información de descripción de la sesión.
El encabezado de respuesta está compuesto de una línea de respuesta, seguida cero

o más líneas de parámetros, cada una con una letra del nombre del parámetro
seguida por su valor. El encabezado de respuesta se compone de un código de
respuesta de tres dígitos, ID de transacción y, opcionalmente, también puede incluir
un comentario. El encabezado de respuesta en el mensaje de respuesta siguiente
muestra el código de respuesta 200 (finalización exitosa), seguido por la ID 1204 y
el comentario: OK:
200 1204 OK
I: FDE234C8
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
a=rtpmap:96 G726-32/8000
Los rango de códigos de respuesta se definen de la siguiente forma:
000 – 099: indica un reconocimiento de respuesta.
100 – 199: indica una respuesta provisional.
200 – 299: indica una finalización exitosa (respuesta final).
Protocolo MGCP 73
400 – 499: indica un error transitorio (respuesta final).
500 – 599: indica un error permanente (respuesta final).
Consulte RFC 3661 si desea información detallada sobre los códigos de respuesta.
La respuesta a un comando se envía a la dirección de origen del comando, no a la

entidad notificada actualmente. Una puerta de enlace de medios puede recibir
comandos MGCP de varias direcciones de red simultáneamente y devolver
respuestas a las direcciones de red correspondientes. Sin embargo, envía todos los
comandos MGCP a su entidad notificada actual.
Ejemplos
Esta sección incluye los siguientes supuestos de configuraciones:
“Puerta de enlace en las residencias de los abonados: agente de llamada en el

ISP” en esta página
“Servicio alojado en ISP” en la página 77
Puerta de enlace en las residencias de los abonados: agente de llamada en el ISP

En este ejemplo, (consulte la Figura 22) se configura un dispositivo de seguridad en
un proveedor de servicio de cable para admitir MGCP para los abonados
residenciales de su red. El dispositivo de seguridad y el agente de llamada se
encuentran en las instalaciones del proveedor de servicio de cable. En cada una de
las residencias de los suscriptores se encuentra un dispositivo de acceso integrado
(IAD) o una caja set-top, que actúa como una puerta de enlace (cada IAD representa
una residencia individual). El agente de llamada está en la zona trust_ca; los
clientes residenciales están en la zona res_cust.
Después de la creación de las zonas (untrust_subscriber para los clientes y trust_ca

para el proveedor de servicio), se deben configurar las direcciones y después las
directivas. Aunque las puertas de enlace frecuentemente residen en diferentes
zonas, que requieren directivas para el tráfico de medios, en este ejemplo las dos
puertas de enlace están en la misma subred. El tráfico RTP entre las puertas de
enlace nunca pasa a través del cortafuegos, por lo tanto no es necesaria ninguna
directiva para los medios.
74 Ejemplos
Figura 22: Puerta de enlace en la residencia de los abonados
Untrust
IAD
IAD Teléfono IP
Dispositivo de seguridad Ethernet3

2.2.2.0/24
Teléfono IP
Red del proveedor IAD
de servicio de cable
Ethernet 4
10.1.1.2
Teléfono IP
IAD
Trust
Agente de
llamada
Teléfono IP
WebUI
1. Zonas
Zone Name: untrust_subscriber
Zone Name: trust_ca

2. Direcciones
Address Name: SubscriberSubNet

Comment: Nuestra red de abonados
Zone: untrust-subscriber
Address Name: call_agent1

Comment: Nuestro agente de llamada No. 1
Zone: trust_ca
Ejemplos 75
3. Interfaces
haga clic en Apply:
Zone Name: untrust_subscriber

haga clic en Apply:
Zone Name: trust_ca

4. Directivas
Policies > (From: trust-ca, To: untrust_subscriber) New: Introduzca los
Name: Pol-CA-To-Subscribers
Source Address
Address Book Entry: (seleccione), call_agent1
Destination Address
Address Book Entry: (seleccione), SubscriberSubNet
Service: MGCP-UA
Action: Permit
Policies > (From: untrust_subscriber, To: trust-ca) New: Introduzca los

Name: Pol-Subscribers-To-CA
Source Address
Address Book Entry: (seleccione), SubscriberSubNet
Destination Address
Address Book Entry: (seleccione), call_agent1
Service: MGCP-UA
Action: Permit
CLI
1. Zonas
set zone name untrust_subscriber
set zone name trust_ca
2. Direcciones
set address untrust_subscriber SubscriberSubNet 2.2.2.0 255.255.255.0 “Our
subscribers' network”
set address trust_ca call_agent1 10.1.1.101 255.255.255.255 “Our No. 1 call
agent”
76 Ejemplos
3. Interfaces
set interface ethernet3 zone untrust_subscriber “Our subscribers’ network”
set interface ethernet4 zone trust_ca “Our No. 1 call agent”

4. Directivas
set policy name Pol-CA-TO-Subscribers from trust_ca to untrust_subscriber
call_agent1 SubscriberSubNet mgcp-ua permit
set policy name Pol-Subscribers-To-CA from untrust_subscriber to trust_ca
SubscriberSubNet call_agent1 mgcp-ca permit
Servicio alojado en ISP

En este ejemplo, (consulte la Figura 23) un ISP que se encuentra en la costa oeste
americana proporciona servicio MGCP a los clientes en Asia y San Francisco. Los
clientes de asia están en la zona Untrust y son admitidos por la puerta de enlace.
asia_gw (3.3.3.110); los clientes de San Francisco están en la zona Trust y son
admitidos por la puerta de enlace: sf_gw (2.2.2.201). El agente de llamada: west_ca
(10.1.1.101) esta en la zona DMZ.
Después de configurar las direcciones para las puerta de enlace y el agente de

llamada, se deben configurar las interfaces, colocando a ethernet4 y ethernet5, que
son fiables, en el modo ruta para permitir el flujo de medios directamente después
de configurar la llamada. Para proteger la dirección IP del agente de llamada en la
zona DMZ de la exposición, debe colocar un MIP en ethernet6, es decir, se debe
asignar la dirección IP del agente de llamada (10.1.1.101) a una dirección IP de un
conjunto de direcciones en la interfaz ethernet6, en dicho caso: 3.3.3.101.
Por último, se deben crear las directivas. Para permitir la señalización de MGCP
entre el agente de llamada en la zona DMZ y la puerta de enlace en la zona Untrust,
se debe crear una directiva para cada dirección, haciendo referencia a la MIP que
protege al agente de llamada. Se debe crear otro par de directivas para permitir la
señalización entre el agente de llamada y la puerta de enlace en la zona Trust. Una
sola directiva es suficiente para permitir la comunicación bidireccional entre las
puertas de enlace en la zona Trust y Untrust.
Ejemplos 77
Figura 23: Servicio alojado en ISP
Dispositivo virtual
DMZ MIP en Ethernet6 -
3.3.3.101 - 10.1.1.101
west_ca
10.1.1.101
Eth5 - 10.1.1.2 Dispositivo de seguridad

asia_gw
3.3.3.110
Red ISP
Eth6 - 3.3.3.10 Zona Untrust
Eth4 - 2.2.2.10
Teléfono IP
Zona Trust
sf_gw
2.2.2.201 Teléfono IP
WebUI
1. Direcciones
Address Name: sf_gw

Comment: gateway en Asia
zone: Trust
Address Name: asia_gw

Comment: gateway in sf
Zone: Untrust
Address Name: west_ca

Comment: ca en la costa oeste
zone: DMZ
78 Ejemplos
2. Interfaces
haga clic en Apply:
Zone Name: Trust

haga clic en Apply:
Zone Name: DMZ

haga clic en Apply:
Zone Name: Untrust

Interface Mode: NAT
3. MIP
Mapped IP: 3.3.3.101

Netmask: 255.255.255.255
4. Directivas
Policies > (From: DMZ To: Untrust) New: Introduzca los siguientes datos y haga
clic en OK:
Source Address
Address Book Entry: (seleccione), west_ca
Destination Address
Address Book Entry: (seleccione), asia_gw
Service: MGCP-UA
Action: Permit
Policies > (From: Untrust To: DMZ) New: Introduzca los siguientes datos y haga
clic en OK:
Source Address
Destination Address
Service: MGCP-UA
Action: Permit
Ejemplos 79
Policies > (From: Trust To: DMZ) New: Introduzca los siguientes datos y haga
clic en OK:
Source Address
Address Book Entry: (seleccione), sf_gw
Destination Address
Service: MGCP-UA
Action: Permit
Policies > (From: DMZ To: Trust) New: Introduzca los siguientes datos y haga
clic en OK:
Source Address
Destination Address
Service: MGCP-UA
Action: Permit
Policies > (From: Trust To: Untrust) New: Introduzca los siguientes datos y haga
clic en OK:
Source Address
Destination Address
Service: MGCP-UA
Action: Permit
NAT:
DIP on: None (utilizar la IP de la interfaz de salida)
CLI
1. Direcciones
set address trust sf_gw 2.2.2.201/32 “gateway in s.f.”
set address untrust asia_gw 3.3.3.110/32 “gateway in asia”
set address dmz west_ca 10.1.1.101/32 “ca in west coast”
2. Interfaces


set interface ethernet6 mip 3.3.3.101 host 10.1.1.101 netmask
255.255.255.255 vrouter trust-vr
80 Ejemplos
4. Directivas
set policy from dmz to untrust west_ca asia_gw mgcp-ua permit
set policy from untrust to dmz asia_gw mip(3.3.3.101) mgcp-ca permit
set policy from trust to dmz sf_gw west_ca mgcp-ca permit

set policy from dmz to trust west_ca sf_gw mgcp-ua permit
set policy from trust to untrust sf_gw asia_gw mgcp-ua nat src permit
Ejemplos 81
82 Ejemplos
Capítulo 4
aplicación del protocolo Skinny de
control de clientes
Este capítulo ofrece una vista general de la puerta de enlace en la capa de

aplicación (ALG) del protocolo de control de la puerta de enlace del cliente Skinny
(SCCP) y detalla las funciones de seguridad de cortafuegos de la implementación.
Después de un resumen de la arquitectura del SCCP se presentan ejemplos de las
situaciones típicas. Este capítulo incluye las siguientes secciones:
“Seguridad del SCCP” en la página 84
Vista general
El protocolo Skinny de control de clientes (SCCP) se admite en dispositivos de
seguridad en los modos de ruta, transparente y de traducción de direcciones de red
(NAT). El SCCP es un protocolo de la capa de aplicación basado en binarios que se
utiliza para configurar y controlar el protocolo de voz por Internet (VoIP). En la
arquitectura del SCCP, un proxy H.323 de Cisco conocido como el gestor de
llamadas hace la mayor parte del procesamiento. Los teléfonos IP, también
denominados estaciones finales, ejecutan el cliente Skinny y se conectan a un
gestor de llamadas primario (y también a uno secundario si está disponible) sobre
TCP en el puerto 2000 y se registran con el gestor de llamadas primario. Luego esta
conexión se utiliza para establecer las llamadas que entran o salen del cliente.
La ALG con SCCP admite lo siguiente:
Flujo de llamada de un cliente Skinny a otro cliente Skinny a través del gestor
de llamadas.
Conmutación por error sin fisuras: conmuta todas las llamadas en proceso
hacia el cortafuegos en espera durante los fallos del primario.
Inspección de la carga de la trama de señalización de VoIP: inspecciona

completamente la carga de paquetes de señalización VoIP entrantes según las
normas RFC y de cada fabricante que se apliquen. Si se descubre algún ataque
de paquetes malformados, la ALG los bloquea.
Vista general 83
Inspección de la carga de la trama de señalización del SCCP: inspecciona

completamente la carga de paquetes de señalización del SCCP entrantes de
acuerdo con RFC 3435. Si se descubre algún ataque de paquetes malformados,
la ALG los bloquea.
Procesamiento del estado: activa las máquinas de estado con protocolo VoIP
correspondientes para procesar la información analizada. Cualquier paquete
que esté fuera de estado o fuera de transacción se identifica y se maneja
apropiadamente.
Traducción de direcciones de red (NAT): traduce cualquier dirección de IP

incorporada y la información de puerto en la carga, con base en la información
de enrutamiento y la topología de la red, la dirección de IP traducida y el
número de puerto, si fuera necesario.
Creación y administración de ojos de aguja para tráfico de VoIP: identifica la

dirección de IP y la información de puerto utilizada para medios o señalización
y abre en forma dinámica (y cierra) los ojos de aguja para secuenciar los
medios de forma segura.
Seguridad del SCCP

La ALG con SCCP incluye las siguientes funciones de seguridad:
Protección contra los ataques de denegación de servicio (DoS). La ALG realiza

una inspección de estado a nivel de paquete de UDP, a nivel de transacción y a
nivel de la llamada. Se procesan los paquetes del SCCP que coinciden con el
formato de mensaje, el estado de la transacción y el estado de la llamada. Se
descartan todos los demás.
Cumplimiento de las directivas de cortafuegos entre los teléfonos IP de Cisco y

el gestor de llamadas (dentro del clúster).
Cumplimiento de las directivas de cortafuegos entre los gestores de llamadas

(Inter-Cluster).
Control de grandes cantidades de paquetes simultáneos del gestor de llamadas.

Protege al gestor de llamadas contra inundaciones de paquetes simultáneos de
nuevas llamadas, ya sea de un cliente conectado que está comprometido o por
un dispositivo defectuoso.
Cumplimiento de las directivas de pared de fuego entre las puertas (directivas

de medios).
Control de grandes cantidades de paquetes simultáneos de conexión SCCP por

puerta de enlace.
Cambio y conmutación por error sin fisuras si las llamadas, incluidas las
llamadas en curso, se conmutan al cortafuegos que está en espera por si se
producen fallos del sistema.
84 Seguridad del SCCP

Capítulo 4: Puerta de enlace en la capa de aplicación del protocolo Skinny de control de clientes
Protocolo SCCP
Las siguientes secciones dan una breve vista general del SCCP y su funcionamiento:
“Componentes del SCCP” en esta página
“Transacciones con SCCP” en la página 86
“Mensajes del SCCP” en la página 89
Componentes del SCCP

Los componentes principales de la arquitectura de VoIP del SCCP incluyen los
siguientes:
Cliente del SCCP
Gestor de llamadas
Clúster
Cliente del SCCP

El cliente del SCCP se ejecuta por medio de un teléfono de IP, también llamado
estación final, que utiliza el SCCP para señalización y para realizar llamadas. Para
que un cliente Skinny realice una llamada se debe registrar primero con un gestor
de llamadas primario (y con un secundario si está disponible). La conexión entre el
cliente y el gestor de llamadas es a través de TCP en el puerto 2000. Luego se usa
esta conexión para establecer llamadas hacia o desde el cliente. La transmisión de
medios se realiza con RTP, UDP e IP.
Gestor de llamadas
El gestor de llamadas es un servidor H.323 de Cisco con control general de toda la
comunicación y dispositivos en la red VoIP con SCCP. Sus funciones incluyen
definir, supervisar y controlar grupos del SCCP, regiones de números y planes de
rutas; proporcionar inicialización, admisión y registro de dispositivos en la red;
proporcionar una base de datos redundantes que contenga direcciones, números de
teléfono y formatos de números, e iniciar el contacto con los dispositivos llamados
o sus agentes para establecer sesiones lógicas en las que pueda fluir la
comunicación de voz.
Clúster
Un clúster es un conjnto de clientes del SCCP y un gestor de llamadas. El gestor de
llamadas en el clúster tiene conocimiento sobre todos los clientes del SCCP en el
clúster. En un clúster puede haber más de un gestor de llamadas para tener un
respaldo. El comportamiento del gestor de llamadas varía en cada una de las
siguientes situaciones de un clúster:
Dentro del clúster, en el cual el gestor de llamadas conoce a cada cliente del
SCCP y la llamada es entre clientes del SCCP del mismo clúster.
Entre clústeres, en la cual el gestor de llamadas necesita comunicarse con otro

gestor de llamadas usando H.323 para establecer llamadas.
Protocolo SCCP 85
Las llamadas entre clústeres que usan el equipo selector para el control de
admisión y la resolución de dirección.
El comportamiento del gestor de llamadas también varía con las llamadas entre
un cliente del SCCP y un teléfono en una red conmutada de teléfonos pública
(PSTN) y con las llamadas entre un cliente del SCCP y un teléfono en otro
dominio administrativo que utiliza H.323.
Transacciones con SCCP

Las transacciones con SCCP son los procesos que deben realizarse para que se
inicie una llamada con el SCCP. Las transacciones con SCCP incluyen las siguientes:
Inicialización del cliente
Registro del cliente
Establecimiento de la llamada
Configuración de medios
Inicialización del cliente

El cliente del SCCP debe saber la dirección IP del gestor de llamadas, su propia
dirección IP y otra información sobre la puerta de enlace IP y los servidores DNS. La
inicialización se lleva a cabo en la LAN local. El cliente envía una solicitud de
protocolo de control dinámico de host (DHCP) para obtener una dirección IP, la
dirección del servidor DNS y el nombre y dirección del servidor TFTP. El cliente
necesita el nombre del servidor TFTP para descargar el archivo de configuración:
sepdir_mac.cnf. Si no se proporciona el nombre del TFTP, el cliente usa el nombre
del archivo predeterminado en el teléfono IP. Después, el cliente descarga el archivo
de configuración .cnf (xml) del servidor TFTP. Los archivos CNF contienen la
dirección o direcciones IP del gestor de llamadas de Cisco primario y secundario. El
cliente se comunica con el gestor de llamadas para registrarse con esta
información.
Registro del cliente

Después de la inicialización, el cliente del SCCP se registra con el gestor de llamadas
a través de una conexión TCP en un puerto 2000 predeterminado bien conocido. El
cliente se registra proporcionando su dirección IP al gestor de llamadas, la dirección
MAC del teléfono y otra información, tal como el protocolo y la versión. El cliente no
puede iniciar o recibir llamadas hasta que está registrado. Los mensajes de
mantenimiento de conexión mantienen abierta esta conexión TCP entre el cliente y
el gestor de llamadas para que el cliente puede iniciar o recibir llamadas en
cualquier momento, siempre que lo permita una directiva en el dispositivo de
seguridad.
86 Protocolo SCCP
La Tabla 4 muestra los mensajes del SCCP e inicia los mensajes que son de interés
para el dispositivo de seguridad.
Tabla 4: Mensajes de registro del SCCP
De interés para el dispositivo

Del cliente Del gestor de llamadas de seguridad
RegisterMessage b
IPortMessage b
RegisterAckMessage b
CapabilitiesRequest
CapabilitiesResMessage
ButtonTemplateReqMessage
ButtonTemplateResMessage
SoftKeyTemplateReqMessage
SoftKeyTemplateResMessage
LineStatReqMessage b
LineStatMessage b
Establecimiento de la llamada
El gestor de llamadas siempre maneja el establecimiento de la llamada de teléfono
IP a teléfono IP utilizando el SCCP. Los mensajes para el establecimiento de la
llamada se envían al gestor de llamadas, desde donde se devuelven mensajes
correspondientes al estado de la llamada. El gestor de llamadas envía al cliente el
mensaje de configuración de medios si tiene éxito el establecimiento de la llamada
y una directiva en el dispositivo de seguridad permite la llamada.
Configuración de medios
El gestor de llamadas envía la dirección IP y el número de puerto del interlocutor
que recibe la llamada al interlocutor que hace la llamada. El gestor de llamadas
envía la dirección IP de medios y el número de puerto del interlocutor que hace la
llamada al interlocutor que recibe la llamada. Los medios se transmiten
directamente entre los clientes después de la configuración de medios. Cuando
termina la llamada, el gestor de llamadas recibe la información y termina las
secuencias de medios. En ningún momento durante este proceso el gestor de
llamadas entrega al cliente la función de establecimiento de la llamada. Los medios
pasan directamente entre los clientes a través de RTP/UDP/IP.
Protocolo SCCP 87
Mensaje de control del SCCP y flujo del RTP

La Figura 24 muestra los mensajes de control del SCCP utilizados para establecer y
terminar una llamada simple entre Teléfono1 y Teléfono2. Con excepción del
mensaje OffHook que inicia la llamada desde el Teléfono1 y el mensaje OnHook que
señaliza el fin de la llamada, todos los aspectos de la llamada están controlados por
el gestor de llamadas.
Figura 24: Configuración y terminación de llamada
Teléfono1 Gestor de llamadas Teléfono2

OffHook
CallState(offhook, ln 1, CID 16777332)
keypadbutton
Callstate(RingIn, ln 1, CID 16777333)
CallInfo(Inbound, ln 1, 2001->2002, Orig: 2002. CID16777333)
CallState(Proceed, ln 1, CID 16777332)
CallInfo(Outbound, ln 1, 2001->2002, Orig: 2002. CID16777332)
CallState(Ringout, ln 1, CID 16777332)
CallInfo(Outbound, ln 1, 2001->2002, CID16777332) OffHook
CallState(OffHook, ln 1, CID 16777333)

OpenRcvChn1(PPID 16778577, CnfrId: 0)
OpenRcvChn1(PPID 16778561, CnfrId: 0)
CallState(Connected, ln 1, CID 16777333)
CallInfo(Inbound, ln 1, 2001->2002, Orig: 2002. CID16777333)
CallState(Connected, ln 1, CID 16777332)
CallInfo(outboundcall, ln 1, 2001->2002, CID16777332)
OpenRcvChnAck1(PPID 16778561, IP:10.10.10.10/Port:24038)
StartMediaX(PPID 16778577, IP:10.10.10.10/Port:24038), CnfrnId:0
OpenRcvChnAck1(PPID 16778577, IP:10.10.10.20/Port:30198)
StartMediaX(PPID 16778561, IP:10.10.10.20/Port:30198), CnffId:0
RTP/UDP (10.10.10.10/24038 -> 10.10.10.20/30198, 10.10.10.20/30198 -> 10.10.10.10/24038)
CallState(OnHook, ln 1, CID 16777332)

CloseRcvChn1(PPID 16778561, CnfrId:0) CloseRcvChn1(PPID 16778577, CnfrId:0)
StopMediaX(PPID 16778561, CnffId:0) StopMediaX(PPID 16778577, CnffId:0)
CallState(Terminate, ln 1, CID 16777332)
88 Protocolo SCCP
Mensajes del SCCP

La Tabla 5, la Tabla 6, la Tabla 7 y la Tabla 8 enumeran las ID de mensajes de
llamadas de SCCP en los cuatro intervalos permitidos por el dispositivo de
seguridad.
Tabla 5: Mensajes de la estación al gestor de llamadas
Mensaje Range
#define STATION_REGISTER_MESSAGE 0x00000001
#define STATION_IP_PORT_MESSAGE 0x00000002
#define STATION_ALARM_MESSAGE 0x00000020
#define STATION_OPEN_RECEIVE_CHANNEL_ACK 0x00000022
Tabla 6: Mensajes del gestor de llamadas a la estación
Mensaje Range
#define STATION_START_MEDIA_TRANSMISSION 0x00000001
#define STATION_STOP_MEDIA_TRANSMISSION 0x00000002
#define STATION_CALL_INFO_MESSAGE 0x00000020
#define STATION_OPEN_RECEIVE_CHANNEL_ACK 0x00000022
#define STATION_CLOSE_RECEIVE_CHANNEL 0x00000106
Tabla 7: Mensajes del gestor de llamadas 4.0 y Post Skinny 6.2
Mensaje Range
#define STATION_REGISTER_TOKEN_REQ_MESSAGE 0x00000029
#define STATION_MEDIA_TRANSMISSION_FAILURE 0x0000002A
#define STATION_OPEN_MULTIMEDIA_RECEIVE_CHANNEL_ACK 0x00000031
Tabla 8: Gestor de llamadas a estación
Mensaje Range
#define STATION_OPEN_MULTIMEDIA_RECEIVE_CHANNEL 0x00000131
#define STATION_START_MULTIMEDIA_TRANSMISSION 0x00000132
#define STATION_STOP_MULTIMEDIA_TRANSMISSION 0x00000133
#define STATION_CLOSE_MULTIMEDIA_RECEIVE_CHANNEL 0x00000136
Ejemplos
Esta sección contiene los siguientes ejemplos de supuestos:
“Ejemplo: Gestor de llamadas/servidor TFTP en la zona Trust” en la página 90
“Ejemplo: Gestor de llamadas/servidor TFTP en la zona Untrust” en la

página 92
“Ejemplo: Zona triple, gestor de llamadas/servidor TFTP en DMZ” en la

página 94
Ejemplos 89
“Ejemplo: Intrazonal, gestor de llamadas/servidor TFTP en la zona Trust” en la

página 98
“Ejemplo: Intrazonal, gestor de llamadas/servidor TFTP en la zona Untrust” en

la página 102
“Ejemplo: VPN de malla completa para el SCCP” en la página 104
Ejemplo: Gestor de llamadas/servidor TFTP en la zona Trust

En este ejemplo, Teléfono1 y el gestor de llamadas/servidor TFTP están en la
interfaz ethernet1 en la zona Trust (privada) y Teléfono2 está en la interfaz
ethernet3 en la zona Untrust. Coloque una MIP para el gestor de llamadas/servidor
TFTP en la interfaz ethernet3 para que cuando el Teléfono2 se inicie pueda entrar
en contacto con el servidor TFTP y obtener la dirección IP del gestor de llamadas.
(Recomendamos que cambie la dirección IP del gestor de llamadas en el archivo de
configuración del servidor TFTP (sep <dir_mac>.cnf) a la dirección IP de MIP del
gestor de llamadas). Luego se crea una directiva que permita el tráfico del SCCP de
la zona Untrust a la zona Trust y crea una referencia de ese MIP en la directiva.
También creará una directiva desde la zona Trust a la zona Untrust para permitir
que Teléfono1 efectúe llamadas externas.
Figura 25: Gestor de llamadas/servidor TFTP en la zona privada
ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Trust Untrust
LAN Internet
Dispositivo virtual
MIP en ethernet3 Teléfono2
Servidor CM/TFTP Teléfono1 1.1.1.2 -> 10.1.1.4
10.1.1.4 10.1.1.3 1.1.1.4
WebUI
1. Interfaces
haga clic en OK:
Zone: Trust
haga clic en OK:
Zone: Untrust
90 Ejemplos
2. Direcciones
Address Name: Teléfono1

Zone: Trust

Zone: Untrust
Address Name: CM-TFTP_Server

Zone: Trust
3. MIP
Mapped IP: 1.1.1.2

Netmask: 255.255.255.255
4. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Teléfono2
Service: SCCP
Action: Permit
NAT:
haga clic en OK:
Source Address:
Ejemplos 91
Service: SCCP
Action: Permit
CLI
1. Interfaces
2. Direcciones
set address trust Teléfono1 10.1.1.3/24
set address untrust Teléfono2 1.1.1.4/24
set address trust cm-tftp_server 10.1.1.4/24
3. MIP
4. Directivas
set policy from trust to untrust any Teléfono2 sccp nat src permit
set policy from untrust to trust Teléfono2 mip(1.1.1.2) sccp permit
save
NOTA: Siempre es más seguro especificar explícitamente un servicio, como se muestra

en esta configuración de ejemplo, que utilizar la palabra clave que permite
designar cualquier servicio: any.
Ejemplo: Gestor de llamadas/servidor TFTP en la zona Untrust

En este ejemplo, el Teléfono1 se encuentra en la interfaz ethernet1 en la zona Trust
y el Teléfono2 y el gestor de llamadas/servidor TFTP en la interfaz ethernet3 de la
zona Untrust. Puede crear la directiva desde la zona Trust hasta la zona Untrust
después de configurar las interfaces y direcciones. Esto permite al Teléfono1
registrarse con el gestor de llamadas/servidor TFTP en la zona Untrust.
Figura 26: Gestor de llamadas/servidor TFTP en la zona Untrust

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Trust Untrust
Internet
LAN
Servidor CM/TFTP
Teléfono1 Teléfono2 1.1.1.3
10.1.1.3 1.1.1.4
92 Ejemplos
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

haga clic en OK:
Zone Name: Untrust

2. Direcciones

Zone: Trust

Zone: Untrust
Address Name: CM/TFTP Server

Zone: Untrust
3. Directivas
haga clic en OK:
Source Address
Destination Address
Service: SCCP
Action: Permit
Ejemplos 93
NAT:
CLI
1. Interfaces
2. Direcciones
set address untrust cm-tftp_server 1.1.1.3/24
3. Directivas
set policy from trust to untrust Teléfono1 any sccp nat src permit
save

Ejemplo: Zona triple, gestor de llamadas/servidor TFTP en DMZ

En este ejemplo, el Teléfono1 se encuentra en la interfaz ethernet1 de la zona Trust,
el Teléfono2 en la interfaz ethernet3 de la zona Untrust y el gestor de
llamadas/servidor TFTP en la interfaz ethernet2 en DMZ. Para señalización, se crea
una directiva desde la zona Trust a DMZ para permitir que el Teléfono1 se
comunique con el gestor de llamadas/servidor TFTP, y se crea una directiva desde la
zona Untrust a DMZ para permitir que el Teléfono2 se comunique con el gestor de
llamadas/servidor TFTP. Para la transmisión de medios se crea una directiva de
Trust a Untrust para permitir la comunicación directa entre Teléfono1 y Teléfono2.
Las flechas de la Figura 27 muestran el flujo del tráfico del SCCP cuando el
Teléfono2 de la zona Untrust genera una llamada al Teléfono1 en la zona Trust.
Después de iniciar la sesión, los medios fluyen directamente entre Teléfono1 y
Teléfono2.
94 Ejemplos
Figura 27: Gestor de llamadas/servidor TFTP en DMZ
Untrust
Teléfono2
1.1.1.4 Internet
Servidor CM/TFTP
ethernet3 2.2.2.4
1.1.1.1/24
ethernet2
2.2.2.2/24
DMZ
LAN
ethernet1
10.1.1.1/24
LAN
Teléfono1
10.1.1.3
Trust
WebUI
1. Interfaces
haga clic en Apply:
Zone: Trust
Interface Mode: NAT
haga clic en OK:
Zone Name: DMZ

haga clic en OK:
Zone Name: Untrust

Ejemplos 95
2. Dirección

Zone: Trust

Zone: Untrust

Zone: DMZ
3. Directivas
clic en OK:
Source Address:
Address Book Entry: (seleccione), CM-TFTP_Server
Service: SCCP
Action: Permit
NAT:
haga clic en OK:
Source Address:
Service: SCCP
Action: Permit
96 Ejemplos
haga clic en OK:
Source Address:
Service: SCCP
Action: Permit
NAT:
CLI
1. Interfaces
2. Direcciones
set address dmz cm-tftp_server 2.2.2.4
3. Directivas
set policy from trust to dmz Teléfono1 cm-tftp_server sccp nat src permit
set policy from untrust to dmz Teléfono2 cm-tftp_server sccp permit
set policy from trust to untrust Teléfono1 Teléfono2 sccp nat src permit
save

Ejemplos 97

Trust
En este ejemplo, el Teléfono1 se encuentra en la interfaz ethernet4 de la zona
Untrust, el Teléfono2 en una subred en la interfaz ethernet3 de la zona Untrust y el
gestor de llamadas/servidor TFTP en la interfaz ethernet1 de la zona Trust. Para
permitir tráfico SCCP intrazonal entre los dos teléfonos de la zona Untrust debe
crear una interfaz de bucle invertido, agregar ethernet3 y ethernet4 a un grupo de
bucle invertido y finalmente situará una MIP en la interfaz de bucle invertido
apuntando a la dirección IP del gestor de llamadas/servidor TFTP. Crear una interfaz
de bucle invertido le permitirá utilizar una sola MIP para el gestor de
llamadas/servidor TFTP en la zona Trust. (Para obtener más información sobre la
utilización de interfaces de bucle invertido, consulte “MIP y la interfaz de bucle
invertido” en la página 8-74.) Finalmente, dado que el bloqueo interzonal está
activado de forma predeterminada, debe desactivar el bloqueo en la zona Untrust
para permitir la comunicación interzonal.
Figura 28: Intrazonal, gestor de llamadas/servidor TFTP en la zona Trust
Untrust
Teléfono1 Teléfono2
1.1.1.4 1.1.2.4
Internet
ethernet4 ethernet3
1.1.1.1/24 1.1.2.1/24
loopback 1
1.1.4.1/24
MIP en loopback 1
1.1.4.5 -> 10.1.1.5
ehternet1
10.1.1.1/24
Servidor CM/TFTP
10.1.1.5
LAN
Trust
98 Ejemplos
WebUI
1. Interfaces
haga clic en Apply:
Zone: Trust
Interface Mode: NAT
haga clic en OK:
Zone: Untrust
haga clic en OK:
Zone: Untrust
haga clic en OK:

2. Direcciones

Zone: Trust

Zone: Untrust
Ejemplos 99

Zone: Untrust
haga clic en OK:
As member of loopback group: (seleccione), loopback.1

Zone Name: Untrust
haga clic en OK:
As member of loopback group: (seleccione), loopback.1

Zone Name: Untrust
4. MIP
Mapped IP: 1.1.4.5

Netmask: 255.255.255.255
5. Bloqueo
clic en OK:

6. Directivas
haga clic en OK:
Source Address:
Service: SCCP
Action: Permit
NAT:
100 Ejemplos
haga clic en OK:
Source Address:
Service: SCCP
Action: Permit
CLI
1. Interfaces
set interface loopback.1 route
2. Direcciones
4. MIP
set interface loopback.1 mip 1.1.4.5 host 10.1.1.5
5. Bloqueo
6. Directivas
set policy from trust to untrust cm/tftp_server any sccp nat src permit
set policy from untrust to trust any mip(1.1.4.5) sccp permit
save
NOTA: Aunque en este ejemplo desactivó el bloqueo en la zona Untrust para permitir la
comunicación interzonal, puede lograr lo mismo mediante la siguiente directiva:
set policy from untrust to untrust any any sccp permit
Tenga en cuenta que siempre es más seguro especificar explícitamente un

servicio, como se muestra en esta configuración de ejemplo, que utilizar la palabra
clave que permite designar cualquier servicio: any.
Ejemplos 101

Untrust
En este ejemplo, el Teléfono1 se encuentra en la interfaz ethernet1 de la zona Trust,
el Teléfono2 en la interfaz ethernet2 en una subred de la zona Trust y el gestor de
llamadas/servidor TFTP en la interfaz ethernet3 de la zona Untrust. Después de
configurar las interfaces y direcciones se crea una directiva desde la zona Trust a
Untrust para permitir el registro del Teléfono1 y Teléfono2 con el gestor de
llamadas/servidor TFTP en la zona Untrust. De forma predeterminada, el bloqueo
está desactivado en la zona Trust (como lo está en las zonas personalizadas que
defina), por lo que no es necesario crearlo. Sin embargo, para mayor seguridad
podría desactivar el bloqueo y crear una directiva de Trust a Trust. Esto permitiría
especificar el servicio SCCP y restringir las llamadas interzonales del Teléfono1 y
Teléfono2.
Figura 29: Intrazonal, gestor de llamadas/servidor TFTP en la zona Trust

Teléfono1 ethernet3 GL/Servidor TFTP
10.1.1.3 ethernet1
3.3.3.3/24 3.3.3.4
10.1.1.1/24
Trust Untrust
LAN Internet
ethernet2
Teléfono2 10.1.2.1/24
10.1.2.2
WebUI
1. Interfaces
haga clic en Apply:
Zone: Trust
haga clic en Apply:
Zone: Trust
haga clic en OK:
Zone: Untrust
102 Ejemplos
2. Direcciones

Zone: Trust

Zone: Trust

Zone: Untrust
3. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione) CM/TFTP Server
Service: SCCP
Action: Permit
NAT:
CLI
1. Interfaces
2. Direcciones
set address untrust cm-tftp_server 3.3.3.4/24
Ejemplos 103
3. Directivas
set policy from trust to untrust any cm-tftp_server sccp nat src permit
save

Ejemplo: VPN de malla completa para el SCCP

En este ejemplo, la oficina central y dos sucursales están unidas por una VPN de
malla completa. Cada sitio tiene un solo dispositivo de seguridad. El gestor de
llamadas/servidor TFTP se encuentra en la zona Trust de la oficina central, el
Teléfono1 en la zona Trust de la sucursal primera y el Teléfono2 en la zona Trust de
la sucursal segunda. Todas las interfaces que conectan los dispositivos se
encuentran en sus respectivas zonas Untrust. En cada dispositivo configurará dos
túneles, uno hacia cada uno de los otros dispositivos, para crear una red
completamente interconectada.
NOTA: Los dispositivos de seguridad utilizados en este ejemplo deben tener disponibles
por lo menos tres interfaces configurables independientemente.
104 Ejemplos
Figura 30: VPN de malla completa para el SCCP
Nota: La zona Untrust de Oficina central GL/servidor TFTP

cada dispositivo no se 10.1.3.3
muestra
Zona Trust
Trust
eth2/8-10.1.3.1
tunnel.1 Central tunnel.2

6.6.6.6 7.7.7.7
Untrust eth2/1: Untrust
1.1.1.1 eth2/2-1.1.2.1
Enrutador de puerta de Enrutador de puerta de

enlace a central: 1.1.1.1 enlace a central: 1.1.2.1
sucursal: 3.3.3.3 VPN 1 VPN 2 sucursal: 2.2.2.2
Untrust eth3 Untrust eth3-2.2.2.2

3.3.3.3
interfaz tunnel.1 sin interfaz tunnel.2 sin
Sucursal 1 VPN 3 numerar
numerar Sucursal 2
Trust eth1 Untrust Untrust Trust eth1

10.1.1.1 eth4-4.4.4.4 eth4-5.5.5.5 10.1.2.1
Enrutador de puerta de enlace
A sucursal 1: 4.4.4.4
Zona Trust A sucursal 2: 5.5.5.5 Zona Trust
Sucursal primera Sucursal segunda

interfaz tunnel.3 sin interfaz tunnel.3 sin
Teléfono1 numerar numerar Teléfono2
10.1.1.3 10.1.2.3

WebUI (para la central)

1. Interfaces
Zone: Untrust
Ejemplos 105
Zone: Untrust
Zone: Trust
clic en Apply:

Zone (VR): Untrust
clic en Apply:

Zone (VR): Untrust
2. Dirección

Zone: Trust
3. VPN
y haga clic en OK:


en Return para regresar a la página de configuración básica de la puerta de
enlace:
106 Ejemplos
y haga clic en OK:


enlace:

4. Enrutamiento
haga clic en OK:

haga clic en OK:

5. Directivas
haga clic en OK:
Source Address (seleccione) Address Book Entry: CM/TFTP Server

Service: SCCP
Action: Permit
haga clic en OK:

Destination Address (seleccione) Address Book Entry: CM/TFTP Server
Service: SCCP
Action: Permit
Ejemplos 107
CLI (para la central)

1. Interfaces
2. Dirección
3. VPN
preshare“netscreen sec-level standard
set vpn vpn_branch-1 gateway to-branch-1 no-reply tunnel idletime 0 sec-level
standard
set vpn vpn-branch-2 gateway to-branch-2 no-reply tunnel idletime 0 sec-level
standard
4. Enrutamiento
5. Directivas
set policy from trust to untrust cm-tftp_server any sccp permit
set policy from untrust to trust any cm-tftp_server sccp permit
save
WebUI (Sucursal 1)
1. Interfaces
haga clic en Apply:
Zone: Trust
haga clic en Apply:
Zone: Untrust
108 Ejemplos
haga clic en Apply:
Zone: Untrust
clic en Apply:

Zone (VR): Untrust
clic en Apply:

Zone (VR): Untrust
2. Dirección

Zone: V1-Trust
3. VPN
y haga clic en OK:


enlace:
y haga clic en OK:

Ejemplos 109
VPN Name: vpn-ns50

enlace:

4. Enrutamiento
haga clic en OK:

haga clic en OK:

5. Directivas
haga clic en OK:
Source Address (seleccione) Address Book Entry: Teléfono2

Service: SCCP
Action: Permit
haga clic en OK:

Destination Address (seleccione) Address Book Entry: Teléfono2
Service: SCCP
Action: Permit
CLI (Sucursal 1)
1. Interfaces
2. Dirección
110 Ejemplos
3. VPN
set ike gateway to-central address 1.1.1.1 main outgoing-interface ethernet3
set ike gateway to-ns50 address 5.5.5.5 main outgoing-interface ethernet4
set vpn vpncentral bind interface tunnel.1
set vpn vpn-ns50 bind interface tunnel.3
4. Rutas
5. Directivas
set policy from trust to untrust Teléfono1 any sccp permit
set policy from untrust to trust any Teléfono1 sccp permit
save
WebUI (Sucursal 2)
1. Interfaces
haga clic en Apply:
Zone: Trust
haga clic en Apply:
Zone: Untrust
haga clic en Apply:
Zone: Untrust
clic en Apply:

Zone (VR): Untrust
clic en Apply:

Zone (VR): Untrust
Ejemplos 111
2. Dirección

Zone: Trust
3. VPN
y haga clic en OK:


enlace:
y haga clic en OK:

VPN Name: vpn-ns50

enlace:

4. Enrutamiento
haga clic en OK:

112 Ejemplos
haga clic en OK:

5. Directivas
Policies > (From: Trust, To: Untrust) Introduzca los siguientes datos y haga clic
en OK:
Source Address (seleccione) Address Book Entry: Teléfono2

Service: SCCP
Action: Permit
haga clic en OK:

Destination Address (seleccione) Address Book Entry: Teléfono2
Service: SCCP
Action: Permit
CLI (Sucursal 2)
1. Interfaces
2. Dirección
3. VPN
set ike gateway to-central address 1.1.1.1 Main outgoing-interface ethernet3
set ike gateway to-ns50 address 4.4.4.4 Main outgoing-interface ethernet4
set vpn vpncentral id 4 bind interface tunnel.2
set vpn vpn-ns50 id 5 bind interface tunnel.3
4. Rutas
Ejemplos 113
5. Directivas
set policy from trust to untrust Teléfono2 any sccp permit
set policy from untrust to trust any Teléfono2 sccp permit
save
114 Ejemplos
Índice
A T
ALG ..................................................................................17 Tiempo de espera SIP
SIP .............................................................................13 por inactividad .........................................................21
SIP NAT ....................................................................24 por inactividad de la sesión ...................................21
por inactividad de medios ................................22, 23
G por inactividad de señalización .......................22, 23
gatekeeper (equipos selectores) .....................................1
V
L voz sobre IP
libro de servicio, grupos de servicios (WebUI) ...........66 administración del ancho de banda ......................65
O
ojos de aguja ..................................................................20
S
SDP .......................................................................... 18 a 19
sesiones multimedia, SIP ..............................................14
SIP
ALG .....................................................................17, 21
anuncios de medios ................................................19
códigos de respuesta ..............................................16
definido ....................................................................13
información de la conexión ...................................19
mensajes ..................................................................14
métodos de petición ...............................................14
ojos de aguja ............................................................18
RTCP .........................................................................19
RTP ...........................................................................19
SDP ................................................................... 18 a 19
señalización .............................................................17
sesiones multimedia ...............................................14
SIP NAT
configuración de llamadas ...............................24, 30
definido ....................................................................24
DIP, utilizar entrante...............................................32
entrante, con MIP..............................................36, 38
proxy en DMZ ..........................................................45
proxy en zona privada......................................40, 90
proxy en zona pública ............................................43
trust intrazonal ........................................................52
untrust intrazonal ....................................................98
untrust intrazone .....................................................49
utilizar DIP de interfaz ............................................33
utilizar un rango DIP ...............................................36
VPN, con uso de malla completa ..................55, 104
ÍNDICE IX-I
IX-II ÍNDICE
Volumen 7:
Enrutamiento

Sunnyvale, CA 94089
USA.
408-745-2000
www.juniper.net
Copyright Notice
without notice.
FCC Statement
Caution: Changes or modifications to this product could void the user’s warranty and authority to operate this device.
Disclaimer
ii
Contenido
Acerca de este volumen xi
Convenciones del documento ........................................................................ xii
Convenciones de la interfaz de usuario web ............................................ xii
Convenciones de interfaz de línea de comandos ..................................... xii
Convenciones de nomenclatura y conjuntos de caracteres ..................... xiii
Convenciones para las ilustraciones ....................................................... xiv
Asistencia y documentación técnica............................................................... xv
Capítulo 1 Enrutamiento estático 1

Vista general .................................................................................................... 1
Cómo funciona el enrutamiento estático ................................................... 2
Cuándo configurar rutas estáticas .............................................................. 3
Configuración de rutas estáticas ................................................................ 4
Ajuste de rutas estáticas ...................................................................... 5
Establecimiento de una ruta estática para una interfaz de túnel.......... 8
Habilitación del seguimiento de puertas de enlace .................................... 9
Reenvío de tráfico a la interfaz Null ............................................................... 10
Impedir las consultas de rutas en otras tablas de enrutamiento............... 10
Impedir que el tráfico de túnel se envíe a través de interfaces que no sean
de túnel ................................................................................................... 10
Evitar bucles creados por las rutas resumidas.......................................... 11
Rutas permanentemente activas .................................................................... 11
Cambiar la preferencia de enrutamiento con enrutamiento multidireccional de
igual coste ............................................................................................... 12
Capítulo 2 Enrutamiento 13
Vista general .................................................................................................. 14
Tablas de enrutamiento del enrutador virtual................................................. 15
Tabla de enrutamiento basada en destinos.............................................. 16
Tabla de enrutamiento basada en el origen ............................................. 18
Tabla de enrutamiento según la interfaz de origen .................................. 20
Creación y modificación de enrutadores virtuales .......................................... 22
Modificación de enrutadores virtuales ..................................................... 22
Asignación de una ID de enrutador virtual............................................... 23
Reenvío de tráfico entre enrutadores virtuales......................................... 24
Configuración de dos enrutadores virtuales ............................................. 24
Creación y eliminación de enrutadores virtuales ..................................... 26
Creación de un enrutador virtual personalizado ................................ 26
Eliminación de un enrutador virtual personalizado ........................... 27
Enrutadores virtuales y sistemas virtuales ............................................... 27
Creación de un enrutador virtual en un Vsys..................................... 28
Compartir rutas entre enrutadores virtuales...................................... 29
Contenido iii
Limitación del número máximo de entradas de la tabla de

enrutamiento........................................................................................... 30
Ejemplos y funciones del enrutamiento ......................................................... 30
Selección de rutas.................................................................................... 31
Establecimiento de una preferencia de ruta ...................................... 31
Métricas de ruta ................................................................................ 32
Cambio de la secuencia predeterminada de consulta de rutas .......... 33
Consulta de rutas en múltiples enrutadores virtuales ........................ 35
Configuración del enrutamiento multidireccional de igual coste .............. 36
Configuración de un mapa de rutas .................................................. 39
Filtrado de rutas................................................................................ 41
Configuración de una lista de acceso................................................. 41
Redistribución de rutas en OSPF ....................................................... 42
Exportación e importación de rutas entre enrutadores virtuales.............. 43
Configuración de una regla de exportación ....................................... 44
Configuración de la exportación automática ..................................... 45
Capítulo 3 Abrir primero la ruta más corta 47

Vista general .................................................................................................. 48
Áreas ....................................................................................................... 48
Clasificación de enrutadores .................................................................... 49
Protocolo de saludo ................................................................................. 50
Tipos de redes ......................................................................................... 50
Redes de difusión.............................................................................. 50
Redes punto a punto ......................................................................... 50
Redes punto a multipunto .................................................................51
Notificaciones de estado de conexiones .................................................. 51
Configuración básica de OSPF ....................................................................... 51
Creación y eliminación de una instancia de enrutamiento OSPF ............. 53
Creación de una instancia de OSPF................................................... 53
Eliminación de una instancia de OSPF .............................................. 53
Creación y eliminación de un área OSPF ................................................. 54
Creación de un área OSPF.................................................................54
Eliminación de un área OSPF............................................................ 55
Asignación de interfaces a un área OSPF................................................. 55
Asignación de interfaces a áreas ....................................................... 55
Configuración de un rango de áreas.................................................. 56
Habilitación de OSPF en interfaces.......................................................... 56
Habilitación de OSPF en interfaces ................................................... 56
Inhabilitar OSPF en una interfaz ....................................................... 57
Verificación de la configuración............................................................... 57
Redistribución de rutas en protocolos de enrutamiento ................................. 59
Resumen de rutas redistribuidas .................................................................... 60
Resumen de rutas redistribuidas ............................................................. 60
Parámetros globales de OSPF ........................................................................ 61
Conexiones virtuales ............................................................................... 62
Creación de una conexión virtual ...................................................... 63
Creación de una conexión virtual automática.................................... 64
Ajuste de parámetros OSPF de interfaz .......................................................... 64
Autenticación de vecinos ......................................................................... 67
Configuración de una contraseña de texto no cifrado .......................67
iv Contenido
Contenido
Configuración de una contraseña MD5 ............................................. 67

Configuración de una lista de vecinos de OSPF ....................................... 68
Configuración de un umbral de saludo.............................................. 70
Configuración de un umbral de LSA .................................................. 70
Habilitación de la inundación reducida ............................................. 70
Creación de un circuito de demanda OSPF en una interfaz de túnel .............. 71
Interfaz de túnel punto a multipunto.............................................................. 71
Establecer el tipo de conexión OSPF ....................................................... 72
Inhabilitación de la restricción Route-Deny ............................................. 72
Creación de una red punto a multipunto ................................................. 73
Capítulo 4 Protocolo de información de enrutamiento 79

Vista general .................................................................................................. 80
Configuración básica de RIP........................................................................... 81
Creación y eliminación de una instancia RIP ........................................... 82
Creación de una instancia RIP........................................................... 82
Eliminación de una instancia RIP ...................................................... 83
Habilitación y deshabilitación de RIP en interfaces.................................. 83
Habilitar RIP en una interfaz ............................................................. 83
Inhabilitación de RIP en una interfaz ................................................ 83
Visualización de la información de RIP .......................................................... 85
Visualización de la base de datos RIP ...................................................... 85
Visualización de los detalles de RIP ......................................................... 86
Visualización de información de vecino RIP ............................................ 87
Visualización de detalles de RIP para una interfaz específica ................... 88
Parámetros globales de RIP............................................................................ 89
Notificación de la ruta predeterminada .......................................................... 90
Configuración de los parámetros de interfaz de RIP....................................... 90
Autenticar vecinos al establecer una contraseña...................................... 92
Configuración de un umbral de actualización.................................... 95
Habilitación de RIP en interfaces de túnel ......................................... 95
Configuraciones opcionales de RIP ................................................................ 96
Configuración de la versión de RIP .......................................................... 96
Habilitación e inhabilitación de un resumen de prefijos........................... 98
Habilitación de un resumen de prefijos ............................................. 98
Inhabilitar un resumen de prefijo ...................................................... 99
Establecimiento de rutas alternas ............................................................ 99
Circuitos de demanda en interfaces de túnel .........................................101
Configuración de un vecino estático ......................................................102
Configuración de una interfaz de túnel punto a multipunto..........................102
Capítulo 5 Protocolo de puertas de enlace de límite 109

Vista general ................................................................................................110
Tipos de mensajes BGP..........................................................................110
Atributos de ruta....................................................................................111
BGP externo e interno ...........................................................................112
Contenido v
Configuración básica de BGP........................................................................112

Creación y habilitación de una instancia de BGP ...................................113
Creación de una instancia BGP........................................................113
Eliminación de una instancia de BGP ..............................................114
Habilitación e inhabilitación de BGP en interfaces .................................114
Habilitación de BGP en interfaces ...................................................114
Inhabilitación de BGP en interfaces.................................................115
Configuración de grupos de interlocutores e interlocutores BGP ............115
Configuración de un interlocutor BGP .............................................117
Configuración de un grupo de interlocutores IBGP ..........................117
Comprobación de la configuración BGP.................................................119
Configuración de seguridad..........................................................................120
Autenticación de vecinos BGP ...............................................................120
Rechazo de rutas predeterminadas........................................................121
Configuraciones opcionales de BGP .............................................................122
Redistribución de rutas en BGP .............................................................123
Configuración de una lista de acceso AS-Path ........................................124
Agregar rutas a BGP...............................................................................125
Notificación de ruta condicional......................................................125
Establecimiento del peso de la ruta.................................................126
Establecimiento datributos de ruta..................................................126
Capacidad de route-refresh....................................................................127
entrante ..........................................................................................128
saliente ...........................................................................................128
Configuración de la reflexión de rutas ...................................................128
Configurar una confederación ...............................................................131
Comunidades BGP .................................................................................133
Agregación de rutas ...............................................................................134
Agregación de rutas con diferentes AS-Paths...................................134
Supresión de las rutas más específicas en actualizaciones ..............134
Selección de rutas para el atributo Path ..........................................136
Capítulo 6 Enrutamiento basado en directivas 139

Vista general del enrutamiento basado en directivas....................................140
Listas de acceso extendidas...................................................................140
Grupos de coincidencias ........................................................................141
Grupos de acciones................................................................................141
Consulta de rutas con enrutamiento basado en directivas............................142
Configuración del enrutamiento basado en directivas ..................................143
Configuración de una lista de acceso extendida.....................................143
Configuración de un grupo de coincidencias .........................................145
Configuración de un grupo de acciones .................................................145
Configuración de una directiva de PBR..................................................146
Enlace de una directiva de enrutamiento basado en directivas..............146
Enlace de una directiva de enrutamiento basado en directivas a una
interfaz ...........................................................................................146
Enlace de una directiva de enrutamiento basado en directivas a una
zona................................................................................................147
enrutador virtual .............................................................................147
vi Contenido
Contenido
Visualización de la salida de enrutamiento basado en directivas..................147

Visualización de una lista de acceso extendida ......................................147
Visualización de un grupo de coincidencias ...........................................148
Visualización de un grupo de acciones...................................................148
Visualización de la configuración de una directiva de enrutamiento
basado en directivas ..............................................................................149
Visualización de la configuración completa de enrutamiento basado en
directivas...............................................................................................150
Ejemplo de PBR avanzado ...........................................................................150
Enrutamiento ........................................................................................152
Elementos PBR ......................................................................................153
Listas de acceso extendidas ............................................................153
Grupos de coincidencias..................................................................154
Grupos de acciones .........................................................................154
Directivas de PBR............................................................................154
Asociación de interfaces ........................................................................155
PBR avanzado con alta disponibilidad y posibilidad de ampliación ..............155
Solución de resistencia en PBR ..............................................................155
Solución con posibilidad de ampliación en PBR.....................................156
Capítulo 7 Enrutamiento multicast 157

Vista general ................................................................................................157
Direcciones multicast ............................................................................158
Reenvío por rutas inversas ....................................................................158
Enrutamiento multicast en dispositivos de seguridad...................................159
Tabla de enrutamiento multicast ...........................................................159
Configuración de una ruta multicast estática .........................................160
Listas de acceso .....................................................................................161
Configurar Encapsulado de enrutamiento genérico en interfaces de
túnel ......................................................................................................161
Directivas multicast......................................................................................163
Capítulo 8 Protocolo de administración de grupos de Internet 165

Vista general ................................................................................................166
Hosts .....................................................................................................166
Enrutadores multicast............................................................................167
IGMP en dispositivos de seguridad ...............................................................167
Habilitación e inhabilitación de IGMP en interfaces ...............................167
Habilitación de IGMP en una interfaz ..............................................168
Desactivación de IGMP en una interfaz ...........................................168
Configuración de una lista de accesos para grupos aceptados ...............168
Configuración de IGMP ..........................................................................169
Verificación de una configuración de IGMP ...........................................171
Parámetros operativos de IGMP.............................................................172
Proxy de IGMP .............................................................................................173
Informes de miembros en sentido ascendente hacia el origen ..............174
Datos multicast en sentido descendente a los receptores ......................175
Configuración del proxy de IGMP ..........................................................176
Configuración de un proxy de IGMP en una interfaz..............................176
Directivas multicast para configuraciones de IGMP y proxy de IGMP ....178
Creación de una directiva de grupo multicast para IGMP ................178
Creación de una configuración de proxy de IGMP...........................178
Configuración de un proxy de remitente de IGMP .................................185
Contenido vii
Capítulo 9 Multicast independiente de protocolo 191

Vista general ................................................................................................192
PIM-SM ..................................................................................................193
Árboles de distribución multicast ....................................................194
Enrutador designado.......................................................................194
Asignación de puntos de encuentro a grupos ..................................195
Reenvío de tráfico a través del árbol de distribución .......................195
PIM-SSM ................................................................................................197
Configuración de PIM-SM en dispositivos de seguridad ................................198
Habilitación y eliminación de una instancia PIM-SM en un VR ..............199
Habilitación de una instancia PIM-SM .............................................199
Eliminación de una instancia PIM-SM .............................................199
Habilitación e inhabilitación de PIM-SM en interfaces............................200
Habilitación de PIM-SM en una interfaz...........................................200
Desactivación de PIM-SM en una interfaz........................................200
Directivas de grupo multicast ................................................................200
Mensajes Static-RP-BSR...................................................................201
Mensajes Join-Prune........................................................................201
Definición de una directiva de grupo multicast para PIM-SM...........201
Ajuste de una configuración de PIM-SM básica.............................................202
Verificación de la configuración ...................................................................207
Configuración de puntos de encuentro.........................................................209
Configuración de un punto de encuentro estático..................................209
Configuración de un punto de encuentro candidato ..............................210
Consideraciones sobre seguridad .................................................................211
Restricción de grupos multicast .............................................................211
Restricción de orígenes multicast ..........................................................212
Restricción de puntos de encuentro.......................................................213
Parámetros de la interfaz PIM-SM ................................................................214
Definición de una directiva vecina.........................................................214
Definición de un límite bootstrap ..........................................................215
Configuración de un punto de encuentro del proxy .....................................215
PIM-SM e IGMPv3 ........................................................................................225
Capítulo 10 Protocolo de descubrimiento de enrutador de ICMP 227

Vista general ................................................................................................227
Configuración del protocolo de descubrimiento de enrutador de ICMP ........228
Habilitación del protocolo de descubrimiento de enrutador de ICMP.....228
desde WebUI .........................................................................................228
desde CLI...............................................................................................229
Notificación de una interfaz ............................................................229
Difusión de la dirección...................................................................229
Configuración de un intervalo máximo de notificación ...................230
Configuración de un intervalo mínimo de notificación ....................230
Configuración de un valor de duración de la notificación ................230
Configuración de un retardo de respuesta.......................................230
Configuración de un intervalo de notificación inicial .......................231
Configuración de un número de paquetes de notificación inicial.....231
viii Contenido
Contenido
Deshabilitación de IRDP...............................................................................231
Visualización de los ajustes de IRDP.............................................................231
Índice ........................................................................................................................IX-I
Contenido ix
x Contenido
El Volumen 7: Enrutamiento incluye las siguientes secciones:
El Capítulo 1, “Enrutamiento estático,” explica las tablas de rutas y cómo

configurar las rutas estáticas para enrutamiento basado en los destinos,
enrutamiento basado en la interfaz de origen o enrutamiento basado en
orígenes.
El Capítulo 2, “Enrutamiento,” explica cómo configurar los enrutadores

virtuales en los dispositivos de seguridad y cómo redistribuir las entradas de la
tabla de enrutamiento entre protocolos o entre enrutadores virtuales.
El Capítulo 3, “Abrir primero la ruta más corta,” explica cómo configurar OSPF
(abrir primero la ruta más corta).
El Capítulo 4, “Protocolo de información de enrutamiento,” explica cómo

configurar el protocolo de información de enrutamiento (RIP).
El Capítulo 5, “Protocolo de puertas de enlace de límite,” explica cómo

configurar el protocolo de puerta de enlace de límites (BGP).
El Capítulo 6, “Enrutamiento basado en directivas,” explica la manera de

obligar al tráfico interesante a que siga una ruta específica en la red.
El Capítulo 7, “Enrutamiento multicast,” explica los fundamentos del

enrutamiento multicast, incluyendo cómo configurar rutas multicast estáticas.
El , “Protocolo de administración de grupos de Internet,” explica cómo

configurar el protocolo de gestión de grupos de Internet (IGMP).
El Capítulo 9, “Multicast independiente de protocolo,” explica cómo configurar

la opción de multicast independiente de protocolo en modo Sparse (PIM-SM) y
multicast independiente de protocolo - multicast de origen específico
(PIM-SSM).
El Capítulo 10, “Protocolo de descubrimiento de enrutador de ICMP,” explica la

forma de configurar un intercambio de mensajes del protocolo de mensajes de
control de Internet (ICMP) entre un host y un enrutador.
xi

Este documento utiliza las convenciones descritas en las secciones siguientes:
“Convenciones de interfaz de línea de comandos” en esta página
“Convenciones de nomenclatura y conjuntos de caracteres” en la página xiii
“Convenciones para las ilustraciones” en la página xiv


de una dirección:
Address Name: dir_1

Zone: Untrust


En ejemplos:







Convenciones del documento xiii



zona de seguridad

Internet

Interfaz de túnel
Servidor
Túnel VPN
Enrutador
Concentrador
xiv Convenciones del documento




Asistencia y documentación técnica xv

xvi Asistencia y documentación técnica

Capítulo 1
Enrutamiento estático
Este capítulo explica el enrutamiento estático y explica cuándo y cómo configurar

rutas estáticas. Incluye las siguientes secciones:
“Cómo funciona el enrutamiento estático” en la página 2
“Cuándo configurar rutas estáticas” en la página 3
“Configuración de rutas estáticas” en la página 4
“Habilitación del seguimiento de puertas de enlace” en la página 9
“Reenvío de tráfico a la interfaz Null” en la página 10
“Impedir las consultas de rutas en otras tablas de enrutamiento” en la

página 10
“Impedir que el tráfico de túnel se envíe a través de interfaces que no sean

de túnel” en la página 10
“Evitar bucles creados por las rutas resumidas” en la página 11
“Rutas permanentemente activas” en la página 11
“Cambiar la preferencia de enrutamiento con enrutamiento multidireccional de

igual coste” en la página 12
Vista general
Una ruta estática es una asignación configurada manualmente de una dirección de
red IP a un destino de salto siguiente (otro enrutador) que define en un dispositivo
de reenvío de capa 3, como un enrutador.
En una red que tiene pocas conexiones a otras redes o en las redes cuyas
interconexiones de red son relativamente estables, suele resultar más práctico
definir rutas estáticas que rutas dinámicas. ScreenOS mantiene las rutas estáticas
hasta que se eliminan explícitamente. No obstante, cuando sea necesario se puede
dar prioridad a rutas dinámicas frente a las estáticas.
1
Puede ver rutas estáticas en la tabla de enrutamiento de ScreenOS. Para forzar el

equilibrio de cargas, puede configurar en enrutamiento multidireccional de igual
coste (ECMP). Para utilizar únicamente puertas de enlace activas, puede establecer
el seguimiento de las puertas de enlace.
Debe establecer por lo menos una ruta predeterminada como una ruta
predeterminada (dirección de red 0.0.0.0/0). Una ruta predeterminada es una
entrada comodín para los paquetes destinados a redes distintas de las definidas en
la tabla de enrutamiento.
Cómo funciona el enrutamiento estático

Cuando un host envía paquetes a un host de otra red, cada encabezado de paquete
contiene la dirección del host de destino. Cuando un enrutador recibe un paquete,
compara la dirección de destino con todas las direcciones existentes en la tabla de
enrutamiento. El enrutador selecciona en la tabla la ruta más específica a la
dirección de destino y, a partir de la entrada de ruta seleccionada, determina el
siguiente salto (“next-hop”) al que debe reenviar el paquete.
NOTA: La ruta más específica se determina aplicando en primer lugar el operador lógico
AND bit por bit a la dirección de destino y a la máscara de red de cada entrada
existente en la tabla de enrutamiento. Por ejemplo, el AND lógico bit por bit de la
dirección IP 10.1.1.1 con la máscara de subred 255.255.255.0 es 10.1.1.0. La ruta
que tenga el mayor número de bits con el valor 1 en la máscara de subred será la
más específica (también denominada “ruta con la mayor coincidencia”).
La Figura 2 representa una red que utiliza enrutamiento estático y un ejemplo de

paquete IP. En este ejemplo, el host 1 de la red A desea acceder al host 2 de la red
C. El paquete que se enviará incluye los siguientes datos en el encabezado:
Dirección IP de origen
Dirección IP de destino
Carga (mensaje)
Figura 2: Ejemplo de enrutamiento estático

IP IP
ORIG DEST
Host 1 Host 2 Carga de datos

Enrutador Y
Enrutador X
Red A Red B Red C
Host 1 Enrutador Z Host 2
2 Vista general
Capítulo 1: Enrutamiento estático
La Tabla 1 resume la tabla de enrutamiento de cada enrutador.
Tabla 1: Resumen de la tabla de enrutamiento para los enrutadores X, Y y Z
Enrutador X Enrutador Y Enrutador Z

Puerta de Puerta de Puerta de
Red enlace Red enlace Red enlace
Red A Conectada Red A Enrutador X Red A Enrutador X
Red B Conectada Red B Conectada Red B Conectada
Red C Enrutador Y Red C Conectada Red C Conectada
En la Tabla 1, el enrutador X tiene configurada una ruta estática hacia la red C con
la puerta de enlace (siguiente salto) como enrutador Y. Cuando el enrutador X
recibe el paquete destinado al host 2 de la red C, compara la dirección de destino
del paquete con el contenido de su tabla de enrutamiento y detecta que la última
entrada corresponde a la ruta más específica para la dirección de destino. En la
última entrada de ruta se especifica que el tráfico destinado a la red C debe enviarse
al enrutador Y para su entrega. El enrutador Y recibe el paquete y, como sabe que la
red C está conectada directamente, envía el paquete a través de la interfaz
conectada a esa red.
Si el enrutador Y falla o si la conexión entre el enrutador Y y la red C deja de estar

disponible, el paquete no puede alcanzar el host 2. Aunque existe otra ruta hacia la
red C a través del enrutador Z, no está configurada de forma estática en el
enrutador X, por lo que éste no detecta la ruta alternativa.
Cuándo configurar rutas estáticas

Tiene que definir por lo menos algunas rutas estáticas incluso cuando utilice
protocolos de enrutamiento dinámicos. Es necesario definir rutas estáticas cuando
se cumplen condiciones como las siguientes:
Para agregar una ruta predeterminada (0.0.0.0/0) a la tabla de enrutamiento de

un enrutador virtual (VR) es necesario definir una ruta estática. Por ejemplo, si
está utilizando dos VR en el mismo dispositivo de seguridad, la tabla de
enrutamiento de trust-vr podría contener una ruta predeterminada que
especificaría untrust-vr como el salto siguiente. Esto permitiría enrutar hacia
untrust-vr el tráfico destinado a direcciones no expresadas en la tabla de
enrutamiento de trust-vr. También puede definir una ruta predeterminada en
untrust-vr para desviar el tráfico de la dirección IP específica a direcciones no
encontradas en la tabla de enrutamiento de untrust-vr.
Si una red no está conectada directamente con el dispositivo de seguridad pero

es accesible a través de un enrutador de una interfaz contenida en un enrutador
virtual (VR), debe definirse una ruta estática hacia la red que contenga la
dirección IP del enrutador. Por ejemplo, la interfaz de zona Untrust puede ser
una subred con dos enrutadores, cada uno de los cuales se conecta a diferentes
proveedores de servicio de Internet (ISP). Debe definir cuál enrutador va a
utilizar para reenviar el tráfico a ISP específicos.
Vista general 3
Si está utilizando dos VR en el mismo dispositivo de seguridad y llega tráfico

entrante a una interfaz de untrust-vr destinado a una red conectada a una
interfaz de trust-vr, deberá definir una entrada estática en la tabla de
enrutamiento de untrust-vr para la red de destino, indicando trust-vr como salto
siguiente. Puede evitar establecer una ruta estática en este caso, si exporta las
rutas de trust-vr a untrust-vr.
Cuando el dispositivo funciona en modo transparente, es necesario definir rutas

estáticas que dirijan el tráfico administrativo originado en el dispositivo mismo
(distinto del tráfico de usuario que pasa por el cortafuegos) a los destinos
remotos. Por ejemplo, deberá definir rutas estáticas que dirijan los mensajes de
syslog, SNMP y WebTrends a la dirección de un administrador remoto. También
deberá definir rutas que dirijan las peticiones de autenticación a los servidores
RADIUS, SecurID y LDAP, y las comprobaciones de URL al servidor Websense.
NOTA: Cuando el dispositivo de seguridad trabaja en modo transparente, es necesario

definir una ruta estática para el tráfico administrativo generado por el dispositivo
incluso aunque el destino se encuentre en la misma subred que éste.
Para el tráfico de red privada virtual (VPN) saliente donde exista más de una
interfaz de salida hacia el destino, deberá establecer una ruta para dirigir el
tráfico saliente al enrutador externo a través de la interfaz deseada.
Si una interfaz en una zona de seguridad de trust-vr es NAT, y si esa interfaz

tiene configurada una IP asignada (MIP) o IP virtual (VIP) para recibir tráfico
procedente de un origen en el dominio de enrutamiento untrust-vr, deberá
crear una ruta a la MIP o VIP en untrust-vr que apunte a trust-vr como puerta de
enlace.
De forma predeterminada, el dispositivo de seguridad utiliza direcciones IP de

destino para encontrar la mejor ruta por la que reenviar paquetes. En un VR,
también puede habilitar tablas de enrutamiento basadas en orígenes o basadas
en interfaces de origen. Ambas tablas de enrutamiento, las basadas en orígenes
y las basadas en interfaces de origen, contienen las rutas estáticas que usted
configura en el VR.
Configuración de rutas estáticas

Para configurar una ruta estática se necesita definir lo siguiente:
Enrutador virtual (VR) al que pertenece la ruta.
La dirección IP y la máscara de red de la red de destino.
El salto siguiente para la ruta, que puede ser otro VR en el dispositivo de

seguridad o la dirección IP de una puerta de enlace (enrutador). Si especifica
otro VR, asegúrese de que en su tabla de enrutamiento exista una entrada para
la red de destino.
4 Vista general
La interfaz a través de la cual se reenvía el tráfico enrutado. La interfaz puede

ser cualquier interfaz compatible con ScreenOS, como una interfaz física (por
ejemplo, ethernet1/2) o una interfaz de túnel. También puede especificar la
interfaz Null para determinadas aplicaciones. Consulte la “Reenvío de tráfico a
la interfaz Null” en la página 10.
Opcionalmente, puede definir los siguientes elementos:
La métrica de ruta se utiliza para seleccionar la ruta activa cuando existen

varias rutas hacia la misma red de destino y todas con el mismo valor de
preferencia. La métrica predeterminada para las rutas estáticas es 1.
Una etiqueta de ruta es un valor que se puede utilizar como filtro al redistribuir
rutas. Por ejemplo, puede seleccionar importar solamente aquellas rutas que
contengan valores de etiqueta especificados a un VR.
Valor de preferencia para la ruta. De forma predeterminada, todas las rutas

estáticas tienen el mismo valor de preferencia que se establece en el VR.
Si la ruta es permanente (se mantiene activa aunque la interfaz del reenvío esté
inactiva o se haya eliminado la dirección IP de la interfaz).
Esta sección contiene los siguientes ejemplos:
“Ajuste de rutas estáticas” en la página 5
“Establecimiento de una ruta estática para una interfaz de túnel” en la página 8
Ajuste de rutas estáticas

En la Figura 3 en la página 6, un dispositivo de seguridad que opera con su interfaz
de zona Trust en modo de traducción de direcciones de red (NAT) protege una red
de múltiples niveles. Se utiliza tanto administración local como remota (a través de
NetScreen-Security Manager). El dispositivo de seguridad envía capturas SNMP e
informes syslog al administrador local (situado en una red de la zona Trust) y envía
informes de NetScreen-Security Manager al administrador remoto (situado en una
red de la zona Untrust). El dispositivo utiliza un servidor SecurID en la zona
desmilitarizada (DMZ) para autenticar usuarios y un servidor Websense en la zona
Trust para realizar el filtrado de web.
NOTA: Las siguientes zonas deben vincularse antes de que se complete este ejemplo:
ethernet1 a la zona Trust, ethernet2 a la zona DMZ y ethernet3 a la zona Untrust.
Las direcciones IP de las interfaces son 10.1.1.1/24, 2.2.10.1/24 y 2.2.2.1/24,
respectivamente.
Las tablas de enrutamiento trust-vr y untrust-vr deben incluir rutas para los
siguientes destinos:
untrust-vr
1. Puerta de enlace predeterminada hacia Internet (ruta predeterminada para el
VR)
2. Administrador remoto en la subred 3.3.3.0/24
Vista general 5
3. La subred 2.2.40.0/24 en DMZ
4. La subred 2.20.0.0/16 en DMZ
trust-vr
5. untrust-vr para todas las direcciones no encontradas en la tabla de
enrutamiento de trust-vr (ruta predeterminada para el VR)
6. La subred 10.10.0.0/16 en la zona Trust
Figura 3: Configuración de rutas estáticas

Administración remota
NetScreen-Security Manager untrust-vr
3.3.3.10/32
Dominio de
2 DMZ
enrutamiento virtual
Internet 2.2.10.3/24
1 2.2.10.0/24 2.20.30.1/24
Zona Untrust 3.3.3.0/24
2.2.10.0/24 4
200.20.2.2/24 2.2.40.1/24
2.20.30.0/24
2.2.2.2/24 3.3.3.1/24 3 2.2.40.0/24
2.2.2.3/24
2.2.2.0/24 2.20.30.2/24
2.2.45.7/32 2.20.3.1/24
2.20.4.1/24
2.20.3.0/24 2.20.4.0/24
5
Ruta Dispositivo de
predeterminada seguridad
= Enrutador
Dominio del
10.1.1.0/24 enrutador = Conmutador/concentrador
virtual
10.1.1.4/24
10.1.1.2/24 10.30.1.1/24
10.10.30.1/24
10.10.30.1/24 10.1.1.3/24
6 10.20.1.1/24 8 trust-vr
7
10.10.30.0/24 10.10.40.0/24 10.30.1.0/24
10.20.1.0/24
Administración local
10.10.30.5/32 10.20.1.1/24
Servidor Websense
10.30.4.7/32
10.20.3.1/24
10.20.4.1/24
10.20.3.0/24 10.20.4.0/24
Zona Trust
6 Vista general
WebUI
1. untrust-vr
Network > Routing > Destination > untrust-vr New: Introduzca los siguientes
datos para crear la puerta de enlace predeterminada untrust y haga clic en OK:

Network > Routing > Destination> untrust-vr New: Introduzca los siguientes
datos para dirigir los informes del sistema generados por el dispositivo de
seguridad a la administración remota, luego haga clic en OK:



2. trust-vr



Vista general 7

NOTA: Para eliminar una entrada, haga clic en Remove. Aparecerá un mensaje pidiendo
confirmación para realizar la eliminación. Haga clic en OK para continuar o en
Cancel para cancelar la acción.
CLI
1. untrust-vr
2. trust-vr
save
Establecimiento de una ruta estática para una interfaz de túnel

En la Figura 4, un host fiable reside en una subred diferente de la interfaz fiable. Un
servidor del protocolo de transferencia de archivos (FTP) recibe tráfico a través de
un túnel VPN. Se necesita establecer una ruta estática para dirigir el tráfico que sale
por la interfaz de túnel al enrutador interno que conduce a la subred donde reside el
servidor.
Figura 4: Ruta estática para una interfaz Tunnel

Interfaz Trust Interfaz Untrust
ethernet1 ethernet3 Servidor FTP
10.1.1.1/24 1.1.1.1/24 10.2.2.5
Internet
Túnel VPN
tunnel.1 Enrutador
10.10.1.1/24 1.1.1.250
8 Vista general
WebUI

Interface: tunnel.1
NOTA: Para que el tunnel.1 aparezca en la lista desplegable Interface, debe crear primero
la interfaz tunnel.1.

CLI
save
Habilitación del seguimiento de puertas de enlace

El dispositivo de seguridad permite que se dé seguimiento a las rutas estáticas
independientes de la interfaz con puertas de enlace para obtener accesibilidad. No
se da seguimiento a las rutas estáticas de forma predeterminada, pero es posible
configurar un dispositivo de seguridad para dar seguimiento a la accesibilidad de las
rutas de las puertas de enlace. El dispositivo registra las rutas sometidas a
seguimiento según estén activas o inactivas, dependiendo de la accesibilidad de
cada puerta de enlace. Por ejemplo, si no se puede obtener acceso a una puerta de
enlace, el dispositivo de seguridad cambia la ruta a inactiva. Cuando la puerta de
enlace se vuelve a activar, la ruta se invierte a activa.
Para agregar una ruta estática con el seguimiento de la puerta de enlace, deberá
establecer explícitamente la ruta a nivel del enrutador virtual (VR) y en la dirección
de la puerta de enlace. No establezca una dirección IP para la interfaz.
Puede utilizar este comando para agregar una ruta estática con una puerta de
enlace de seguimiento para la dirección IP 1.1.1.254 con prefijo 1.1.1.0 y una
longitud de 24. Establezca el seguimiento de la puerta de enlace introduciendo la
dirección IP de la puerta de enlace pero no establezca la interfaz.
WebUI
Network > Routing > Destination: Haga clic en New y luego introduzca lo
siguiente:
Vista general 9
CLI
set vrouter trust route 1.1.1.0/24 gateway 1.1.1.254
unset vrouter trust route 1.1.1.0/24 gateway 1.1.1.254
save
Reenvío de tráfico a la interfaz Null

Puede configurar rutas estáticas usando la interfaz Null como interfaz de salida. La
interfaz Null siempre se considera activa y el tráfico destinado a la interfaz Null
siempre se descarta. Para convertir la ruta a la interfaz Null en una ruta de último
recurso, defínala con una métrica más alta que la de las demás rutas. Las rutas
estáticas que reenvían tráfico a la interfaz Null se utilizan principalmente con tres
objetivos:
Impedir la consulta de rutas en otras tablas de enrutamiento
Impedir que el tráfico del túnel se envíe en interfaces que no sean de túnel
Evitar bucles de tráfico
Impedir las consultas de rutas en otras tablas de enrutamiento

Si se habilita el enrutamiento basado en interfaz de origen, de forma
predeterminada el dispositivo de seguridad realiza operaciones de consulta en la
tabla de enrutamiento basada en la interfaz de origen. (Para obtener información
sobre la configuración del enrutamiento basado interfaz de origen, consulte “Tabla
de enrutamiento según la interfaz de origen” en la página 20.) Si la ruta no se
encuentra en la tabla de enrutamiento basada en la interfaz de origen y si el
enrutamiento basado en el origen no está activado, el dispositivo de seguridad
realiza operaciones de consulta de rutas en la tabla de enrutamiento basada en el
origen. Si la ruta no se encuentra en la tabla de enrutamiento basada en el origen, el
dispositivo de seguridad realiza operaciones de consulta de la ruta en la tabla de
enrutamiento basada en los destinos. Si desea evitar las operaciones de consulta de
rutas en la tabla de enrutamiento basada en el origen o en la tabla de enrutamiento
basada en los destinos, puede crear una ruta predeterminada en la tabla de
enrutamiento basada en le interfaz de origen con la interfaz Null como la interfaz
de salida. Utilice una métrica más alta que el resto de las rutas para asegurar que
esta ruta sólo se utilice si no existe ninguna otra ruta basada en la interfaz que
coincida con la ruta.
Impedir que el tráfico de túnel se envíe a través de interfaces que no sean de túnel
Puede utilizar las rutas estáticas o dinámicas con las interfaces de túnel de salida
para encriptar el tráfico dirigido a destinos específicos. Si una interfaz de túnel se
queda inactiva, todas las rutas definidas en la interfaz se quedan inactivas. Si hay
una ruta alternativa en una interfaz que no sea de túnel, el tráfico no se envía
encriptado. Para impedir que el tráfico que debe estar encriptado se envíe a una
interfaz que no sea de túnel, defina una ruta estática al mismo destino que el tráfico
del túnel con la interfaz Null como interfaz de salida. Asigne a esta ruta una métrica
más alta que la de la ruta de la interfaz de túnel de modo que la ruta solamente se
active si la ruta de la interfaz de túnel no está disponible. Si la interfaz de túnel se
queda inactiva, la ruta con la interfaz Null se activa y el tráfico para el destino del
túnel se descarta.
10 Reenvío de tráfico a la interfaz Null

Evitar bucles creados por las rutas resumidas

Cuando el dispositivo de seguridad anuncia rutas resumidas, es posible que el
dispositivo reciba el tráfico destinado a prefijos que no se encuentran en sus tablas
de enrutamiento. Puede reenviar el tráfico basado en su ruta predeterminada. El
enrutador de recepción puede reenviar el tráfico de nuevo al dispositivo de
seguridad debido a el anuncio de la ruta resumida. Para evitar dichos bucles, puede
definir una ruta estática para el prefijo de la ruta resumida con la interfaz Null como
la interfaz de salida y una métrica de ruta alta. Si el dispositivo de seguridad recibe
el tráfico para los prefijos que se encuentren en su anuncio de ruta resumida pero
no en sus tablas de enrutamiento, se descarta el tráfico.
En este ejemplo establecerá una interfaz NULL para la ruta resumida creada hacia la
red 2.1.1.0/24 del ejemplo anterior. Dentro de la red 2.1.1.0/24 se encuentran los
hosts 2.1.1.2, 2.1.1.3 y 2.1.1.4. Cualquier paquete dirigido a 2.1.1.10 caerá en el
rango de la ruta resumida. El dispositivo de seguridad acepta estos paquetes pero
no tiene a dónde reenviarlos, salvo de vuelta al origen, lo que inicia un bucle de red.
Para evitar este comportamiento, establecerá una interfaz NULL para esta ruta.
Establecer una preferencia y métrica elevadas es importante al establecer una
interfaz NULL.
WebUI

Interface: Null
Preference: 255
Metric: 65535
CLI
set vrouter trust-vr route 2.1.1.0/24 interface null preference 255 metric 65535
save
Rutas permanentemente activas

Hay ciertas situaciones en las que posiblemente desee que una ruta mantenga su
estado activo en una tabla de enrutamiento incluso si la interfaz física asociada a la
ruta se queda inactiva o no tiene una dirección IP asignada. Por ejemplo, un
servidor XAuth puede asignar una dirección IP a una interfaz en un dispositivo de
seguridad siempre que se necesite enviar tráfico al servidor. La ruta hacia el
servidor de XAuth debe mantenerse activa incluso cuando no haya dirección IP
asignada en la interfaz de modo que el tráfico que está destinado al servidor XAuth
no se descarte.
También es útil mantener activas las rutas a través de las interfaces en las que se
configura el seguimiento de IP. El seguimiento de IP permite que el dispositivo de
seguridad reencamine el tráfico saliente a través de una interfaz diferente si las
direcciones IP de destino no se pueden alcanzar a través de la interfaz original.
Aunque el dispositivo de seguridad puede reencaminar el tráfico a otra interfaz,
necesita ser capaz de enviar peticiones del comando ping en la interfaz original
para determinar si los destinos llegan a ser otra vez accesibles.
Rutas permanentemente activas 11

Cambiar la preferencia de enrutamiento con enrutamiento multidireccional de

igual coste
También puede cambiar la preferencia de enrutamiento de las rutas estáticas con
enrutamiento multidireccional de igual coste (Equal Cost Multipath, ECMP).
Consulte “Configuración del enrutamiento multidireccional de igual coste” en la
página 36 para obtener más información.
12 Cambiar la preferencia de enrutamiento con enrutamiento multidireccional de igual coste

Capítulo 2
Enrutamiento
Este capítulo describe la administración del enrutamiento y del enrutador virtual

(VR). Incluye las siguientes secciones:
“Tablas de enrutamiento del enrutador virtual” en la página 15
“Tabla de enrutamiento basada en destinos” en la página 16
“Tabla de enrutamiento basada en el origen” en la página 18
“Tabla de enrutamiento según la interfaz de origen” en la página 20
“Creación y modificación de enrutadores virtuales” en la página 22
“Modificación de enrutadores virtuales” en la página 22
“Asignación de una ID de enrutador virtual” en la página 23
“Reenvío de tráfico entre enrutadores virtuales” en la página 24
“Configuración de dos enrutadores virtuales” en la página 24
“Creación y eliminación de enrutadores virtuales” en la página 26
“Enrutadores virtuales y sistemas virtuales” en la página 27
“Limitación del número máximo de entradas de la tabla de enrutamiento”

en la página 30
“Ejemplos y funciones del enrutamiento” en la página 30
“Selección de rutas” en la página 31
“Configuración del enrutamiento multidireccional de igual coste” en la

página 36
“Redistribución de rutas” en la página 38
“Exportación e importación de rutas entre enrutadores virtuales” en la

página 43
13
Vista general
El enrutamiento es el proceso de reenviar paquetes de una red a otra hasta que
alcanzan su destino final. Un enrutador es un dispositivo que está donde una red se
encuentra con otra y dirige el tráfico entre esas redes.
De forma predeterminada, un dispositivo de seguridad entra al modo de

funcionamiento de ruta y opera como un enrutador de capa 3. Sin embargo, puede
configurar un dispositivo de seguridad para que funcione en modo transparente
como un conmutador de capa 2.
NOTA: En cualquier modo de funcionamiento, tendrá que configurar manualmente

algunas rutas.
Los dispositivos de seguridad de Juniper Networks logran enturarse a través de un

proceso llamado enrutador virtual (VR). Un dispositivo de seguridad divide sus
componentes de enrutamiento en dos o más VR y cada VR mantiene su propia lista
de redes conocidas en forma de una tabla de enrutamiento, lógica de enrutamiento
y zonas de seguridad relacionadas. Un solo VR puede admitir una o más de las
siguientes rutas:
Rutas estáticas o configuradas manualmente
Rutas dinámicas, como las que se aprenden por medio de un protocolo de

enrutamiento dinámico
Rutas multicast, como una ruta a un grupo de máquinas host
Los dispositivos de seguridad de Juniper Networks tienen dos VR predefinidos:
trust-vr, que de forma predeterminada contiene todas las zonas de seguridad

predefinidas y todas las zonas definidas por el usuario
untrust-vr, que de forma predeterminada no contiene ninguna zona de

seguridad
No puede eliminar los enrutadores virtuales trust-vr ni untrust-vr. Pueden existir

varios VR, pero trust-vr es el predeterminado. En la tabla de VR, un asterisco (*)
indica que trust-vr es el VR predeterminado en la interfaz de línea de comandos
(CLI). Puede ver la tabla de VR ejecutando el comando CLI get vrouter. Para
configurar zonas e interfaces en otros VR, debe especificar el VR por nombre, por
ejemplo untrust-vr. Para obtener información sobre las zonas, consulte “Zonas” en
la página 2-25.
Algunos dispositivos de seguridad le permiten crear otros VR personalizados. Al

separar la información de enrutamiento en varios VR, podrá controlar cuánta
información sobre enrutamiento puede ver en otros dominios de enrutamiento. Por
ejemplo, puede mantener la información de enrutamiento de todas las zonas de
seguridad de una red corporativa en el VR predefinido trust-vr y la información de
enrutamiento de todas las zonas fuera de la red corporativa en el otro VR
predefinido untrust-vr. Puede mantener la información sobre enrutamiento de
redes internas separada de los orígenes no fiables afuera de la empresa porque los
detalles de la tabla de enrutamiento de un VR no se pueden ver en la otra.
14 Vista general
Capítulo 2: Enrutamiento
Tablas de enrutamiento del enrutador virtual

En un dispositivo de seguridad, cada VR mantiene sus propias tablas de
enrutamiento. Una tabla de enrutamiento es una lista actualizada de redes y
direcciones conocidas, desde donde se puede obtener acceso a éstas. Cuando un
dispositivo de seguridad procesa un paquete entrante, realiza una consulta en la
tabla de enrutamiento para buscar la interfaz correspondiente que conduzca a la
dirección de destino.
Cada entrada de la tabla de enrutamiento identifica la red destino a la que se puede

reenviar el tráfico. La red destino puede ser una red IP, una subred, una supernet o
un host. Cada entrada de la tabla de enrutamiento puede ser unicast (paquete
enviado a una sola dirección IP que hace referencia a una sola máquina host) o
multicast (paquete enviado a una sola dirección IP que hace referencia a varias
máquinas host).
Las entradas de la tabla de enrutamiento pueden provenir de los siguientes

orígenes:
Redes interconectadas directamente (la red de destino es la dirección IP que

asigna a una interfaz en el modo de ruta)
Protocolos de enrutamiento dinámico, como protocolo de abrir primero la ruta

más corta (OSPF), el protocolo de puerta de enlace de límites (BGP) o el
protocolo de información de enrutamiento (RIP)
Otros enrutadores o enrutadores virtuales en forma de rutas importadas
Rutas configuradas estáticamente
Rutas host
NOTA: Cuando establece una dirección IP para identificar una interfaz en el modo de
ruta, la tabla de enrutamiento conecta automáticamente una ruta hacia la subred
adyacente para canalizar el tráfico que pasa por la interfaz.
Un VR admite tres tipos de tablas de enrutamiento:
La tabla de enrutamiento basada en destinos permite al dispositivo de

seguridad realizar operaciones de consulta de rutas basándose en la dirección
IP de destino de un paquete de datos entrante. De forma predeterminada, el
dispositivo de seguridad utiliza únicamente direcciones IP de destino para
encontrar la mejor ruta por la cual reenviar paquetes.
La tabla de enrutamiento basada en orígenes permite al dispositivo de

seguridad realizar operaciones de consulta de rutas basándose en la dirección
IP de origen de un paquete de datos entrante. Para agregar entradas a la tabla
de enrutamiento basada en orígenes, debe configurar rutas estáticas para
direcciones de origen específicas en las que el dispositivo de seguridad puede
realizar operaciones de consulta de rutas. De forma predeterminada, esta tabla
de enrutamiento está inhabilitada. Consulte “Tabla de enrutamiento basada en
el origen” en la página 18.
Tablas de enrutamiento del enrutador virtual 15

La tabla de enrutamiento basada en orígenes permite al dispositivo de

seguridad realizar las operaciones de consulta de rutas basándose en la interfaz
por la cual un paquete de datos entra al dispositivo. Para agregar entradas a la
tabla de enrutamiento basada en orígenes, debe configurar rutas estáticas para
determinadas interfaces en las que el VR realiza operaciones de consulta de
rutas. De forma predeterminada, esta tabla de enrutamiento está inhabilitada.
Consulte “Tabla de enrutamiento según la interfaz de origen” en la página 20.
Tabla de enrutamiento basada en destinos

La tabla de enrutamiento basada en destinos está siempre presente en un VR.
Además, puede habilitar las tablas de enrutamiento basadas en orígenes o basadas
en interfaces de origen, o ambas, en un VR. El siguiente es un ejemplo de tablas de
enrutamiento con base en el destino de ScreenOS:
device-> get route

--------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
* 8 0.0.0.0/0 eth1/1 10.100.37.1 S 20 1 Root
* 7 1.1.1.1/32 eth1/2 0.0.0.0 H 0 0 Root
* 3 192.168.1.1/32 mgt 0.0.0.0 H 0 0 Root
* 2 192.168.1.0/24 mgt 0.0.0.0 C 0 0 Root
* 4 10.100.37.0/24 eth1/1 0.0.0.0 C 0 0 Root
* 5 10.100.37.170/32 eth1/1 0.0.0.0 H 0 0 Root
* 6 1.1.1.0/24 eth1/2 0.0.0.0 C 0 0 Root
* 9 11.3.3.0/24 agg1 0.0.0.0 C 0 0 Root
* 10 11.3.3.0/32 agg1 0.0.0.0 H 0 0 Root
* 11 3.3.3.0/24 tun.1 0.0.0.0 C 0 0 Root
* 12 3.3.3.0/32 tun.1 0.0.0.0 H 0 0 Root
La tabla de enrutamiento contiene la siguiente información de cada red de destino:
La interfaz del dispositivo de seguridad a través del que se reenvía el tráfico a la

red de destino.
El siguiente salto (next-hop), que puede ser otro VR en el dispositivo de

seguridad o la dirección IP de una puerta de enlace (normalmente la dirección
de un enrutador).
El protocolo del cual se deriva la ruta. La columna del protocolo de la tabla de

enrutamiento le permite conocer el tipo de ruta:
Red conectada (C)
Estática (S)
Autoexportada (A)
16 Tablas de enrutamiento del enrutador virtual

Importada (I)
Los protocolos de enrutamiento dinámico, como RIP (R), abrir primero la

ruta más corta u OSPF (O), tipo externo 1 y 2 de OSPF (E1 o E2,
respectivamente), protocolo de puerta de enlace de límite interno o externo
(iB o eB, respectivamente)
Permanente (P)
Host (H)
Aparece una entrada host-ruta con una máscara de 32 bits cuando se

configura cada interfaz con una dirección IP. La ruta host siempre está
activa en la tabla de rutas para que la consulta de rutas siempre tenga éxito.
Las rutas host se actualizan automáticamente con los cambios
configurados, como eliminación de la dirección IP de interfaz, y nunca se
redistribuyen ni se exportan. Las rutas host descartan la posibilidad de que
haya tráfico errático y conservan la capacidad de procesamiento.
La preferencia se utiliza para seleccionar la ruta a utilizar cuando existen varias

rutas hacia la misma red de destino. Este valor lo determina el protocolo o el
origen de la ruta. Cuanto menor sea el valor de preferencia de una ruta, más
posibilidades existen que esa ruta se seleccione como ruta activa.
Puede modificar el valor de preferencia en cada enrutador virtual para cada

protocolo u origen de ruta. Consulte “Selección de rutas” en la página 31 para
obtener más información.
La métrica también se puede utilizar para seleccionar la ruta a utilizar cuando

existen varias rutas para la misma red de destino con el mismo valor de
preferencia. El valor de métrica de las rutas conectadas es siempre 0. La
métrica predeterminada de las rutas estáticas es 1, pero puede especificar un
valor diferente cuando se definen estas rutas.
El sistema virtual (vsys) al cual pertenece esta ruta. Para obtener más
información sobre enrutadores virtuales, consulte “Enrutadores virtuales y
sistemas virtuales” en la página 27. En este ejemplo, no aparecen entradas bajo
el encabezado de la tabla untrust-vr; sin embargo, bajo el encabezado de la
tabla trust-vr aparecen once entradas.
La mayoría de las tablas de enrutamiento contienen una ruta predeterminada (con la

dirección de red 0.0.0.0/0), que es una entrada comodín para los paquetes
destinados a redes distintas de las definidas en la tabla de enrutamiento.
Para ver un ejemplo del enrutamiento basado en el destino, consulte

“Configuración de rutas estáticas” en la página 4.

Tabla de enrutamiento basada en el origen

Puede obligar a un dispositivo de seguridad a reenviar tráfico según la dirección IP
de origen de un paquete de información en lugar de la dirección IP de destino. Esta
función permite que el tráfico de los usuarios de una subred concreta se reenvíe por
una ruta mientras que el tráfico de los usuarios de una subred diferente se reenvía
por otra. Cuando el enrutamiento según el origen se habilita en un VR, el dispositivo
de seguridad realiza operaciones de consulta de la tabla de enrutamiento en la
dirección IP del origen del paquete en una tabla de enrutamiento con base en
orígenes. Si el dispositivo de seguridad no encuentra una ruta para la dirección IP
de origen en la tabla de enrutamiento basada en orígenes, utiliza la dirección IP de
destino del paquete para las operaciones de consulta de rutas en la tabla de
enrutamiento basada en destinos.
Usted define las rutas basadas en el origen como rutas configuradas estáticamente
en VR especificados. Las rutas basadas en orígenes son aplicables al VR en el que
usted las configura; sin embargo, puede especificar otro VR como siguiente salto
para una ruta basada en orígenes. Tampoco puede redistribuir rutas basadas en el
origen a otros VR o protocolos de enrutamiento.
Para utilizar esta función:
1. Cree al menos una ruta basada en origen especificando esta información:
El nombre del VR en el que es aplicable el enrutamiento según el origen.
La dirección IP de origen, que aparece como una entrada en la tabla de

enrutamiento basada en orígenes, en la cual el dispositivo de seguridad
realiza una consulta de la tabla de enrutamiento.
El nombre de la interfaz de salida por la que se reenvía el paquete.
El salto siguiente para la ruta basada en el origen (tenga en cuenta que si ya

ha especificado una puerta de enlace predeterminada para la interfaz con
el comando CLI set interface interfaz gateway dir_ip, no necesita
especificar el parámetro de puerta de enlace; la puerta de enlace
predeterminada de la interfaz se usa como siguiente salto para la ruta
basada en el origen. También puede especificar otro VR como siguiente
salto para la ruta basada en el origen con el comando set vrouter
enrut_virtual route source dir_ip/máscara_red vrouter
enrut_virtual_salto_siguiente.)
La métrica para la ruta basada en el origen. (Si hay varias rutas basadas en
el origen con el mismo prefijo, sólo la ruta con la métrica más baja se
utiliza para la consulta de rutas y el resto se marcan como “inactivas”.)
2. Habilitar el enrutamiento según el origen en el VR. El dispositivo de seguridad

utiliza la IP de origen del paquete para las operaciones de consulta de rutas en
la tabla de enrutamiento basada en orígenes. Si no se encuentra ninguna ruta
para la dirección IP de origen, se utiliza la dirección IP de destino para consultar
la tabla de enrutamiento.

En la Figura 5, el tráfico de los usuarios de la subred 10.1.1.0/24 se reenvía al ISP 1,

mientras que el tráfico de los usuarios de la subred 10.1.2.0/24 se reenvía al ISP 2.
Es necesario configurar dos entradas en la tabla de enrutamiento del VR
predeterminado trust-vr y habilitar el enrutamiento según el origen:
La subred 10.1.1.0/24, con ethernet3 como interfaz de reenvío y enrutador del

ISP 1 (1.1.1.1) como siguiente salto
La subred 10.1.2.0/24, con ethernet4 como interfaz de reenvío y enrutador del

ISP 2 (2.2.2.2) como siguiente salto
Figura 5: Ejemplo de enrutamiento según el origen
10.1.1.0/24 ISP1
1.1.1.1
ethernet1
ethernet2
ISP2
10.1.2.0/24
2.2.2.2
WebUI
Network > Routing > Source Routing > New (para el trust-vr): Introduzca los
Network Address/Netmask: 10.1.1.0 255.255.255.0

Interface: ethernet3 (seleccione)
Network > Routing > Source Routing > New (para el trust-vr): Introduzca los

NOTA: En la WebUI, la preferencia y el valor de métrica predeterminados son 1.
Network > Routing > Virtual Routers > Edit (para el trust-vr): Seleccione
Enable Source Based Routing, luego haga clic en OK.
CLI
set vrouter trust-vr route source 10.1.1.0/24 interface ethernet3 gateway 1.1.1.1
metric 1
set vrouter trust-vr route source 10.1.2.0/24 interface ethernet4 gateway 2.2.2.2
metric 1
set vrouter trust-vr source-routing enable
save

Tabla de enrutamiento según la interfaz de origen

El enrutamiento según la interfaz de origen (SIBR) permite al dispositivo de
seguridad reenviar el tráfico en función de la interfaz de origen (la interfaz por la
que el paquete de datos llega al dispositivo de seguridad.) Cuando SIBR se habilita
en un enrutador virtual (VR), el dispositivo de seguridad realiza operaciones de
consulta de rutas en una tabla de enrutamiento de SIBR. Si el dispositivo de
seguridad no encuentra ninguna entrada de ruta en la tabla de enrutamiento de
SIBR para la interfaz de origen, puede realizar consultas de ruta en la tabla de
enrutamiento basada en orígenes (si el enrutamiento basado en orígenes está
habilitado en el VR) o en la tabla de enrutamiento basada en destinos.
Las rutas basadas en la interfaz origen se definen como rutas estáticas para las
interfaces de origen especificadas. Las rutas basadas en la interfaz de origen se
aplican al VR en el que se configuran; sin embargo, también puede especificar otro
VR como siguiente salto para una ruta basada en la interfaz de origen. Sin embargo,
tampoco puede exportar rutas basadas en la interfaz de origen a otros VR ni
redistribuirlas a un protocolo de enrutamiento.
Para utilizar esta función:
1. Cree al menos una ruta basada en la interfaz de origen especificando la

información siguiente:
El nombre del VR en el que es aplicable el enrutamiento según la interfaz

de origen.
La interfaz de origen en la que el dispositivo de seguridad realiza una

consulta en la tabla SIBR. (Esta interfaz aparece como una entrada en la
tabla de enrutamiento.)
La dirección IP y el prefijo de máscara de red para la ruta.
El nombre de la interfaz de salida por la que se reenvía el paquete.
El salto siguiente para la ruta basada en interfaz de origen. (Tenga en

cuenta que si ya ha especificado una puerta de enlace predeterminada para
la interfaz con el comando CLI interface gateway dir_ip, no es necesario
especificar el parámetro de puerta de enlace; la puerta de enlace
predeterminada de la interfaz se usa como siguiente salto para la ruta
basada en la interfaz de origen. También puede especificar otro VR como
siguiente salto para la ruta basada en el origen con el comando set vrouter
enrut_virtual route source dir_ip/máscara_red vrouter
enrut_virtual_salto_siguiente.)
La métrica para la ruta basada en interfaz de origen. (Si hay varias rutas
con base en la interfaz de origen con el mismo prefijo, sólo la ruta con la
métrica más baja se utiliza para la consulta de rutas y el resto se marcan
como “inactivas”.)
2. Habilite SIBR para el VR. El dispositivo de seguridad utiliza la interfaz de origen

del paquete para las operaciones de consulta de rutas en la tabla SIBR.

En la Figura 6, el tráfico de los usuarios de la subred 10.1.1.0/24 llega al dispositivo

de seguridad en la interfaz ethernet1 y se reenvía al ISP 1, mientras que el tráfico
procedente de los usuarios de la subred 10.1.2.0/24 llega al dispositivo en ethernet2
y se reenvía al ISP 2. Deberá configurar dos entradas en la tabla de enrutamiento
del VR predeterminado trust-vr y habilitar SIBR:
La subred 10.1.1.0/24, con ethernet1 como interfaz de origen para reenvíos y

ethernet3 como interfaz de reenvío y el enrutador del ISP 1 (1.1.1.1) como
siguiente salto
La subred 10.1.2.0/24, con ethernet2 como interfaz de origen y ethernet4

como interfaz de reenvío y el enrutador del ISP 2 (2.2.2.2) como siguiente salto
Figura 6: Ejemplo de enrutamiento según la interfaz de origen (SIBR)
10.1.1.0/24 ISP1
1.1.1.1
ethernet1 ethernet3
ethernet2 ethernet4
ISP2
10.1.2.0/24 2.2.2.2
WebUI
Network > Routing > Source Interface Routing > New (para ethernet1):

Network > Routing > Source Interface Routing > New (para ethernet2):

NOTA: En la WebUI, la preferencia y el valor de métrica predeterminados son 1.
Network > Routing > Virtual Routers > Edit (para el trust-vr): Seleccione
Enable Source Interface Based Routing, luego haga clic en OK.

CLI
set vrouter trust-vr route source in-interface ethernet1 10.1.1.0/24 interface
ethernet3 gateway 1.1.1.1 metric 1
set vrouter trust-vr route source in-interface ethernet2 10.1.2.0/24 interface
ethernet4 gateway 2.2.2.2 metric 1
set vrouter trust-vr sibr-routing enable
save
Creación y modificación de enrutadores virtuales

Esta sección incluye varios ejemplos y procedimientos para modificar enrutadores
virtuales (VR) existentes y para crear o eliminar VR personalizados.
Modificación de enrutadores virtuales

Puede modificar un VR personalizado o predeterminado mediante la WebUI o la
CLI. Por ejemplo, para modificar el VR trust-vr:
WebUI
Network > Routing > Virtual Router (trust-vr) > Edit
CLI
Puede modificar los siguientes parámetros de los VR:
Identificador de enrutador virtual (consulte “Limitación del número máximo de

entradas de la tabla de enrutamiento” en la página 30.)
Número máximo de entradas permitidas en la tabla de enrutamiento.
El valor de preferencia para las rutas, según el protocolo (consulte

“Establecimiento de una preferencia de ruta” en la página 31.)
Hacer que el VR reenvíe el tráfico según la dirección IP de origen del paquete

de datos (de forma predeterminada, un VR reenvía el tráfico según la dirección
IP de destino del paquete de datos.) Consulte “Tabla de enrutamiento basada en
el origen” en la página 18.)
Habilitar o deshabilitar la exportación de rutas automática al untrust-vr para

interfaces configuradas en modo de ruta (sólo para el trust-vr.)
Añadir una ruta predeterminada con otro VR como siguiente salto (sólo para el
trust-vr.)
Hacer capturas SNMP privadas para las MIB de enrutamiento dinámico (sólo
para el VR de nivel raíz.)
Permitir que rutas de interfaces inactivas sean tenidas en cuenta para

notificación (de forma predeterminada, sólo las rutas activas definidas en
interfaces activas pueden ser redistribuidas a otros protocolos o exportadas a
otros VR.)
22 Creación y modificación de enrutadores virtuales

Hacer que el VR ignore las direcciones de subredes superpuestas para

interfaces (de forma predeterminada, no es posible configurar direcciones IP de
subredes superpuestas para interfaces en el mismo VR.)
Permitir que el VR sincronice su configuración con el VR en su interlocutor del

protocolo de redundancia de NetScreen (NSRP.)
Asignación de una ID de enrutador virtual

Con los protocolos de enrutamiento dinámico, cada dispositivo de enrutamiento
utiliza una identidad de enrutador exclusiva para comunicarse con otros dispositivos
de enrutamiento. La identidad puede ser en forma de notación decimal con puntos,
como una dirección IP, o un valor entero. Si no define una ID de enrutador virtual
concreto (VR ID) antes de la habilitación de un protocolo de enrutamiento
dinámico, ScreenOS automáticamente selecciona la dirección IP más alta de las
interfaces activas en el enrutador virtual (VR) como identidad del enrutador.
De forma predeterminada todos los dispositivos de seguridad tienen asignada la

dirección IP 192.168.1.1 a la interfaz VLAN1. Si no especifica una ID del enrutador
antes de la habilitación de un protocolo de enrutamiento dinámico en un
dispositivo de seguridad, la dirección IP elegida como ID del enrutador será
probablemente la dirección predeterminada 192.168.1.1. Esto puede provocar un
problema de enrutamiento puesto que no puede haber varios VR de seguridad con
la misma ID de VR en un dominio de enrutamiento. Por lo tanto, recomendamos
que siempre asigne una ID de VR explícita que sea única en la red. Puede establecer
la ID del VR en la dirección de la interfaz de bucle invertido, puesto que la interfaz
de bucle invertido no es una VSI (interfaz de seguridad virtual) en un clúster NSRP
(protocolo de redundancia de NetScreen.) (Consulte el Volumen 11:
Alta disponibilidad para obtener más información sobre la configuración de un
clúster NSRP.)
En este ejemplo, asignará 0.0.0.10 como ID de enrutador para el trust-vr.
NOTA: En la WebUI debe introducir la ID del enrutador en notación decimal de puntos.

En la CLI, puede introducir la ID del enrutador en notación decimal de puntos
(0.0.0.10) o simplemente introducir 10 (la CLI la convierte en 0.0.0.10.)
WebUI
Network > Routing > Virtual Router (trust-vr) > Edit: Introduzca los siguientes
Virtual Router ID: Custom (seleccione)

En el cuadro de texto, escriba 0.0.0.10
CLI
set vrouter trust-vr router-id 10
save
Creación y modificación de enrutadores virtuales 23

NOTA: No puede asignar o cambiar una ID de enrutador si ya ha habilitado un protocolo

de enrutamiento dinámico en el VR. Si necesita cambiar la ID del enrutador, debe
primero deshabilitar el protocolo de enrutamiento dinámico en el VR. Para
obtener información sobre la desactivación del protocolo de enrutamiento
dinámico en VR, consulte el capítulo correspondiente en este volumen.
Reenvío de tráfico entre enrutadores virtuales

Cuando hay dos versiones de VR en un dispositivo de seguridad, el tráfico de las
zonas en un VR no se reenvía automáticamente a zonas de otro VR, aunque haya
directivas que permitan el tráfico. Si el tráfico debe pasar entre los VR, tiene que
realizar uno de estos procedimientos:
Configurar una ruta estática en un VR que defina otro VR como el siguiente

salto para la ruta. Esta ruta puede incluso ser la ruta predeterminada del VR. Por
ejemplo, puede configurar una ruta predeterminada para el trust-vr con el
untrust-vr como siguiente salto. Si el destino de un paquete de salida no
coincide con ninguna de las entradas de la tabla de enrutamiento del trust-vr, se
reenvía al untrust-vr. Para obtener información sobre la configuración de rutas
estáticas, consulte “Configuración de rutas estáticas” en la página 4.
Exportar rutas de la tabla de enrutamiento de un VR a la tabla de enrutamiento

de otro VR. Puede exportar e importar rutas concretas. También puede exportar
todas las rutas de la tabla de enrutamiento del trust-vr a la tabla del untrust-vr.
Esto permite el reenvío de paquetes recibidos en el untrust-vr a destinos del
trust-vr. Para obtener información, consulte “Exportación e importación de
rutas entre enrutadores virtuales” en la página 43.
Configuración de dos enrutadores virtuales

Cuando hay varios VR dentro de un dispositivo de seguridad, cada VR mantiene
tablas de enrutamiento separadas. De forma predeterminada, todas las zonas de
seguridad predefinidas y definidas por el usuario están asociadas al trust-vr. Esto
significa que todas las interfaces asociadas a esas zonas de seguridad también
pertenecen al trust-vr. Esta sección analiza cómo asociar una zona de seguridad
(y sus interfaces) al VR untrust-vr.
Puede asociar una zona de seguridad a un sólo VR. Puede asociar varias zonas de
seguridad a un sólo VR cuando no hay superposición de direcciones entre zonas.
Esto es, todas las interfaces de las zonas deben estar en modo de ruta. Una vez que
una zona está asociada a un VR, todas las interfaces de la zona pertenecen al VR.
Puede cambiar la asociación de una zona de seguridad de un VR a otro, pero
primero hay que quitar todas las interfaces de la zona. (Para obtener más
información sobre cómo enlazar y desenlazar una interfaz de una zona de
seguridad, consulte “Interfaces” en la página 2-33.)
A continuación se enumeran los pasos básicos para asociar una zona de seguridad
al VR untrust-vr:
1. Eliminar todas las interfaces de la zona que quiera asociar al untrust-vr. No

puede modificar el vínculo de zona a VR si hay una interfaz asignada a la zona.
Si ha asignado una dirección IP a una interfaz, deberá eliminar la asignación de
direcciones antes de quitar la interfaz de la zona.

2. Asignar la zona al VR untrust-vr.
3. Volver a asignar las interfaces a la zona.
En el siguiente ejemplo, la zona de seguridad untrust está asociada de forma

predeterminada al trust-vr y la interfaz ethernet3 está asociada a la zona de
seguridad untrust. (No hay otras interfaces asociadas a la zona de seguridad
untrust.) Primero debe definir la dirección IP y la máscara de red de la interfaz
ethernet3 con un valor de 0.0.0.0, después cambiar los enlaces para que la zona de
seguridad untrust se asocie al untrust-vr.
WebUI
1. Desasociar la interfaz de la zona untrust
Network > Interfaces (ethernet3) > Edit: Introduzca los siguientes datos y
haga clic en OK:
Zone Name: Null

2. Asociar la zona untrust al untrust-vr
Network > Zones (untrust) > Edit: Seleccione untrust-vr de la lista
3. Asociar la interfaz a la zona untrust

Network > Interfaces (ethernet3) > Edit: Seleccione Untrust en la lista
desplegable Zone Name, luego haga clic en OK.
CLI
1. Desasociar la interfaz de la zona untrust
2. Asociar la zona untrust al untrust-vr
3. Asociar la interfaz a la zona untrust
set interface eth3 zone untrust
save
En el resultado del siguiente ejemplo, el comando get zone muestra la interfaz,

zona y enlaces VR predeterminados. En los enlaces predeterminados, la zona
untrust está asociada al trust-vr.
device-> get zone

Total of 12 zones in vsys root. 7 policy configurable zone(s)
-------------------------------------------------------------
ID Name Type Attr VR Default-IF VSYS
0 Null Null Shared untrust-vr null Root
1 Untrust Sec(L3) Shared trust-vr ethernet3 Root
2 Trust Sec(L3) trust-vr ethernet1 Root
3 DMZ Sec(L3) trust-vr ethernet2 Root
4 Self Func trust-vr self Root
5 MGT Func trust-vr vlan1 Root
6 HA Func trust-vr null Root
10 Global Sec(L3) trust-vr null Root
11 V1-Untrust Sec(L2) trust-vr v1-untrust Root
12 V1-Trust Sec(L2) trust-vr v1-trust Root

13 V1-DMZ Sec(L2) trust-vr v1-dmz Root

16 Untrust-Tun Tun trust-vr null Root
-------------------------------------------------------------
Puede elegir cambiar el enlace de la zona para untrust-vr. Al ejecutar el comando

get zone, se muestra la interfaz, la zona y los enlaces de VR modificados; en este
caso, la zona untrust está ahora vinculada a untrust-vr.
device-> get zone

Total of 12 zones in vsys root. 7 policy configurable zone(s)
-------------------------------------------------------------
ID Name Type Attr VR Default-IF VSYS
0 Null Null Shared untrust-vr null Root
1 Untrust Sec(L3) Shared untrust-vr ethernet3 Root
2 Trust Sec(L3) trust-vr ethernet1 Root
3 DMZ Sec(L3) trust-vr ethernet2 Root
4 Self Func trust-vr self Root
5 MGT Func trust-vr vlan1 Root
6 HA Func trust-vr null Root
10 Global Sec(L3) trust-vr null Root
11 V1-Untrust Sec(L2) trust-vr v1-untrust Root
12 V1-Trust Sec(L2) trust-vr v1-trust Root
13 V1-DMZ Sec(L2) trust-vr v1-dmz Root
16 Untrust-Tun Tun trust-vr null Root
---------------------------------------------------------------
Creación y eliminación de enrutadores virtuales

Algunos dispositivos de seguridad le permiten crear VR personalizados además de
los dos predefinidos. Puede modificar todos los aspectos de un VR definido por el
usuario, incluidos la identidad del VR, el número máximo de entradas permitidas
en la tabla de enrutamiento, y el valor de preferencia de las rutas de determinados
protocolos.
NOTA: Sólo ciertos dispositivos de seguridad admiten VR personalizados. Para crear VR

personalizados, necesita una clave de licencia de software.
Creación de un enrutador virtual personalizado

En este ejemplo, creará un VR personalizado denominado trust2-vr y habilitará una
exportación de rutas automática del VR trust2-vr al untrust-vr.
WebUI
Network > Routing > Virtual Routers > New: Introduzca los siguientes datos y
haga clic en OK:
Virtual Router Name: trust2-vr

Auto Export Route to Untrust-VR: (seleccione)
CLI
set vrouter name trust2-vr
set vrouter trust2-vr auto-route-export
save

Eliminación de un enrutador virtual personalizado

En este ejemplo, eliminará un VR definido por el usuario existente denominado
trust2-vr.
WebUI
Network > Routing > Virtual Routers: Haga clic en Remove para trust2-vr.
Cuando aparezca la petición de confirmación de la eliminación, haga clic

en OK.
CLI
unset vrouter trust2-vr
Cuando aparezca la petición de confirmación para la eliminación (vrouter

unset, are you sure? y/[n]), teclee Y.
save
NOTA: No puede eliminar los VR predefinidos untrust-vr y trust-vr, pero se puede

eliminar cualquier VR definido por el usuario. Para modificar el nombre de un VR
definido por el usuario o cambiar la ID del VR, debe eliminar primero el VR y
después volver a crearlo con el nuevo nombre o ID del VR.
Enrutadores virtuales y sistemas virtuales

Cuando un administrador del nivel raíz crea un vsys en sistemas con sistema virtual
habilitado, automáticamente el vsys tiene los siguientes VR disponibles para su uso:
Cualquier VR de nivel raíz que haya sido definido como compartido. El

untrust-vr es, de forma predefinida, un VR compartido accesible por cualquier
vsys. Puede configurar otro VR de nivel raíz como compartido.
Un VR de nivel vsys. Cuando crea un vsys, se crea automáticamente un VR de

nivel vsys que mantiene la tabla de enrutamiento de la zona
Trust-nombresistvirt. Puede elegir nombrar el VR como nombresistvirt-vr o con
un nombre definido por el usuario. Un VR de nivel vsys no puede ser
compartido por otros vsys.
NOTA: Únicamente los sistemas de seguridad de Juniper Networks (NetScreen-500,

NetScreen-5200, NetScreen-5400) admiten vsys. Para crear objetos vsys, necesita
una clave de licencia de software.
Puede definir uno o más VR personalizados para un vsys. Para obtener más
información sobre los sistemas virtuales, consulte el Volumen 10: Sistemas virtuales.
En la Figura 7, cada uno de los tres vsys tiene dos VR asociados con éste: un VR de
nivel vsys llamado nombresistvirt-vr y el untrust-vr.

Figura 7: Enrutadores virtuales dentro de un Vsys
trust-vr
untrust-vr Finanzas
(enrutador virtual a
nivel de raíz DMZ
compartido)
Correo Trust Ingeniería
sistema raíz vsys1-vr

Trust-vsys1
Untrust vsys1
vsys2-vr Automáticamente
vsys2 creados cuando
Trust-vsys2 crea vsys
vsys3
vsys3-vr
Trust-vsys3
Creación de un enrutador virtual en un Vsys

En este ejemplo, definirá un VR personalizado vr-1a con la ID de VR 10.1.1.9 para
el vsys mi-vsys1.
WebUI
Vsys > Configure > Enter (para mi-vsys1) > Network > Routing > Virtual
Routers > New: Introduzca los siguientes datos, luego haga clic en Apply:
Virtual Router Name: vr-1a

En el cuadro de texto, introduzca 10.1.1.9
CLI
set vsys mi-vsys1
(mi-vsys1) set vrouter name vr-1a
(mi-vsys1/vr-1a) set router-id 10.1.1.9
(mi-vsys1/vr-1a) exit
(mi-vsys1) exit
Teclee Y cuando aparezca la siguiente pregunta:
Configuration modified, save? [y]/n

El VR de nivel vsys que se crea cuando usted crea el vsys es el VR predeterminado

para un vsys. Puede cambiar el VR predeterminado de un vsys por un VR
personalizado. Por ejemplo, puede hacer que el VR personalizado vr-1a creado
anteriormente en este ejemplo sea el VR predeterminado para el vsys mi-vsys1:
WebUI
Vsys > Configure > Enter (para mi-vsys1) > Network > Routing > Virtual
Routers > Edit (para vr-1a): Seleccione Make This Vrouter Default-Vrouter for
the System y haga clic en Apply.
CLI
set vsys mi-vsys1
(mi-vsys1) set vrouter vr-1a
(mi-vsys1/vr-1a) set default-vrouter
(mi-vsys1/vr-1a) exit
(mi-vsys1) exit

La zona de seguridad predefinida Trust-nombresistvirt está asociada de forma

predeterminada al VR de nivel vsys que se crea al crear el vsys. No obstante, puede
asociar la zona de seguridad predefinida Trust-nombresistvirt y cualquier zona de
seguridad de nivel vsys definida por el usuario a cualquier VR disponible para el
vsys.
El untrust-vr es compartido de forma predefinida por todo el vsys. Aunque los VR de

nivel vsys no se pueden compartir, puede definir cualquier VR de nivel raíz para ser
compartido por el vsys. Esto le permite definir rutas en un VR de nivel vsys que
utilizan un VR de nivel raíz como siguiente salto. Puede también configurar la
redistribución de rutas entre un VR de nivel vsys y un VR de nivel raíz compartido.
Compartir rutas entre enrutadores virtuales

En este ejemplo, el VR de nivel raíz mi-enrutador contiene las entradas de la tabla
de enrutamiento para la red 4.0.0.0/8. Si configura el VR de nivel raíz mi-enrutador
como compartible por el vsys, puede definir una ruta en un VR de nivel vsys para el
destino 4.0.0.0/8 con mi-enrutador como siguiente salto. En este ejemplo, el vsys es
mi-vsys1 y el VR de nivel vsys es mi-vsys1-vr.
WebUI
Network > Routing > Virtual Routers > New: Introduzca los siguientes datos y
haga clic en OK:
Virtual Router Name: mi-enrutador

Shared and accessible by other vsys (seleccione)
Vsys > Configure > Enter (para mi-vsys1) > Network > Routing > Routing
Entries > New (para mi-vsys1-vr): Introduzca los siguientes datos y haga clic
en OK:

Next Hop Virtual Router Name: (seleccione) mi-enrutador

CLI
set vrouter name mi-enrutador sharable
set vsys mi-vsys1
(mi-vsys1) set vrouter mi-vsys1-vr route 40.0.0.0/8 vrouter mi-enrutador
(mi-vsys1) exit
Limitación del número máximo de entradas de la tabla de enrutamiento

A cada VR se le asignan las entradas de la tabla de enrutamiento que necesita de
entre un conjunto del sistema. El número máximo de entradas disponibles depende
del dispositivo de seguridad y del número de VR configurados en el dispositivo.
Puede limitar el número máximo de entradas de la tabla de enrutamiento que
pueden ser asignadas para un VR concreto. Esto sirve para prevenir que un VR
utilice todas las entradas del sistema.
NOTA: Consulte la hoja de datos del producto pertinente para determinar el número
máximo de entradas de la tabla de enrutamiento disponible en su dispositivo de
seguridad de Juniper Networks.
En este ejemplo, ajustará a 20 el número máximo de entradas de la tabla de

enrutamiento para el trust-vr.
WebUI
Network > Routing > Virtual Routers > Edit (para el trust-vr): Introduzca los
Maximum Route Entry:

Set limit at: (seleccione), 20
CLI
set vrouter trust-vr max-routes 20
save
Ejemplos y funciones del enrutamiento

Después de configurar los VR requeridos para su red, puede determinar qué
funciones de enrutamiento desea emplear. Estas funciones afectan el
comportamiento del enrutamiento y los datos de la tabla de enrutamiento. Estas
funciones se aplican a protocolos de enrutamiento estático y dinámico.
Esta sección contiene los siguientes temas:
“Selección de rutas” en la página 31
“Configuración del enrutamiento multidireccional de igual coste” en la

página 36
30 Ejemplos y funciones del enrutamiento

“Exportación e importación de rutas entre enrutadores virtuales” en la

página 43
Selección de rutas
Pueden existir varias rutas con el mismo prefijo (dirección IP y máscara) en la tabla
de enrutamiento. Cuando la tabla de enrutamiento contiene varias rutas para el
mismo destino, se comparan los valores de preferencia de cada ruta. Se selecciona
la que tiene el valor de preferencia más bajo. Si los valores de preferencia son
iguales, se comparan los valores de métrica. En ese caso, se selecciona la ruta que
tiene el valor de métrica más bajo.
NOTA: Si hay varias rutas para el mismo destino con los mismos valores de preferencia y
los mismos valores de métrica, entonces cualquiera de ellas puede resultar
seleccionada. En este caso, la elección de una ruta concreta sobre otra no está
garantizada ni es predecible.
Establecimiento de una preferencia de ruta

Una preferencia de ruta es un peso añadido a la ruta que influye en la
determinación del mejor camino para que el tráfico alcance su destino. Cuando se
importa o añade una ruta a la tabla de enrutamiento, el VR añade un valor de
preferencia, determinado por el protocolo por el cual es reconocida. Se prefiere un
valor de preferencia bajo (un número próximo a 0) a un valor de preferencia alto
(un número alejado de 0.)
En un VR, puede establecer el valor de preferencia para rutas de acuerdo con el

protocolo. La Tabla 2 detalla los valores de preferencia predeterminados para rutas
de cada protocolo.
Tabla 2: Valores de preferencia predeterminados de las rutas
Preferencia
Protocolo predeterminada
Conectado 0
Estático 20
Autoexportado 30
EBGP 40
OSPF 60
RIP 100
Importado 140
OSPF externo de tipo 2 200
IBGP 250
También puede ajustar el valor de preferencia de la ruta para dirigir el tráfico por el
camino preferido.
Ejemplos y funciones del enrutamiento 31

En este ejemplo, especifica un valor de 4 como preferencia para cualquier ruta

“conectada” añadida a la tabla de rutas del untrust-vr.
NOTA: Si la preferencia de la ruta cambia para un tipo de ruta (por ejemplo, las rutas
OSPF de tipo 1), la nueva preferencia aparece en la tabla de rutas, pero no tiene
efecto hasta que la ruta sea reconocida de nuevo (lo cual se consigue inhabilitando
y a continuación habilitando el protocolo de enrutamiento dinámico), o, en el caso
de rutas estáticas, eliminándola y volviéndola a añadir.
Si cambia la preferencia de ruta no afectará a las rutas existentes. Para aplicar

cambios a las rutas existentes, debe borrar las rutas y luego volver a agregarlas.
Para las rutas dinámicas, debe deshabilitar el protocolo, luego volver a habilitarlo o
reiniciar el dispositivo.
Una ruta es conectada cuando el enrutador tiene una interfaz con una dirección IP
en la red de destino.
WebUI
Network > Routing > Virtual Routers > Edit (para untrust-vr): Introduzca los
Route Preference:
Connected: 4
CLI
set vrouter untrust-vr preference connected 4
save
Métricas de ruta
Las métricas de ruta determinan el mejor camino que un paquete puede tomar para
alcanzar un destino dado. Los enrutadores utilizan las métricas de ruta para sopesar
dos rutas al mismo destino y determinar la elección de una ruta sobre la otra.
Cuando hay varias rutas hacia la misma red de destino con el mismo valor de
preferencia, prevalece la ruta con la métrica más baja.
Una métrica de ruta se puede basar en cualquier elemento o bien en una

combinación de éstos:
Número de enrutadores que un paquete debe atravesar para alcanzar un

destino
Velocidad y ancho de banda relativas de la ruta
Costo de los vínculos que conforman la ruta
Otros factores
Cuando las rutas son reconocidas dinámicamente, el enrutador contiguo al de

origen de la ruta proporciona la métrica. La métrica predeterminada para rutas
conectadas siempre es 0. La métrica predeterminada para rutas estáticas es 1.

Cambio de la secuencia predeterminada de consulta de rutas

Si habilita tanto el enrutamiento basado en el origen como el enrutamiento basado
en interfaz de origen en un VR, el VR realiza consultas de rutas, comprobando el
paquete entrante con las tablas de enrutamiento en un orden específico. Esta
sección describe la secuencia de consulta de la ruta predeterminada y cómo puede
modificar dicha secuencia configurando los valores de preferencia para cada tabla
de enrutamiento.
Si un paquete entrante no coincide con una sesión existente, el dispositivo de

seguridad ejecuta los pasos restantes con procesamiento del primer paquete. La
Figura 8 muestra la secuencia predeterminada de consulta de rutas.
Figura 8: Secuencia predeterminada de consulta de rutas
paquete entrante
Sí ¿La ruta se
SIBR encontró en
habilitado tabla SIBR?
No No
Sí ¿La ruta se Sí
SBR encontró en Reenvíe el paquete en la
habilitado tabla SBR? interfaz de salida especificada o
de siguiente salto
No No
¿Se
encontró la Sí
ruta en
DRT?
No
Descartar el paquete
1. Si el enrutamiento basado en la interfaz de origen se habilita en el VR, el

dispositivo de seguridad primero comprueba la tabla de enrutamiento basada
en la interfaz de origen para ver si existe una entrada de ruta que coincida con
la interfaz en la que llegó el paquete. Si el dispositivo de seguridad encuentra
una entrada de ruta para la interfaz de origen en la tabla de enrutamiento
basada en la interfaz de origen, reenvía los paquetes según lo especificado por
la entrada de enrutamiento correspondiente. Si el dispositivo de seguridad no
encuentra una entrada de enrutamiento para la interfaz de origen en la tabla de
enrutamiento basada en la interfaz de origen, el dispositivo comprueba si el
enrutamiento basado en el origen está habilitado en el VR.

2. Si el enrutamiento basado en el origen se habilita en el VR, el dispositivo de

seguridad comprueba la tabla de enrutamiento basada en el origen para ver si
existe una entrada de ruta que coincida con la dirección IP de origen del
paquete. Si el dispositivo de seguridad encuentra una entrada de enrutamiento
que coincida con la dirección IP de origen, reenvía el paquete según lo
especificado por la entrada. Si el dispositivo de seguridad no encuentra una
entrada de enrutamiento para la dirección IP de origen en la tabla de
enrutamiento basada en el origen, el dispositivo comprueba la tabla de
enrutamiento basada en los destinos.
3. El dispositivo de seguridad comprueba la tabla de enrutamiento basada en los

destinos en consulta de una entrada de enrutamiento que coincida con la
dirección IP de destino del paquete. Si el dispositivo de seguridad encuentra
una entrada de enrutamiento que coincida con la dirección IP de destino,
reenvía el paquete según lo especificado por la entrada. Si el dispositivo no
encuentra una entrada de enrutamiento que coincida exactamente con la
dirección IP de destino pero hay una ruta predeterminada configurada para el
VR, el dispositivo reenvía el paquete según lo especificado por la ruta
predeterminada. Si el dispositivo de seguridad no encuentra una entrada de
enrutamiento para la dirección IP de destino y no hay ruta predeterminada
configurada para el VR, el paquete se descarta.
El orden en el que el dispositivo de seguridad comprueba las tablas de

enrutamiento para encontrar una ruta que coincida está determinado por un valor
de preferencia asignado a cada tabla de enrutamiento. La tabla de enrutamiento
con el valor de preferencia más alto se comprueba primero mientras que la tabla de
enrutamiento con el valor de preferencia más bajo es la última en comprobarse. De
forma predeterminada, la tabla de enrutamiento basada en la interfaz de origen
tiene el valor de preferencia más alto (3), la tabla de enrutamiento basada en el
origen tiene el siguiente valor de preferencia más alto (2) y la tabla de enrutamiento
basada en los destinos tiene el valor de preferencia más bajo (1).
Puede reasignar nuevos valores de preferencia a una tabla de enrutamiento para

modificar el orden en el que el dispositivo de seguridad realiza la consulta de rutas
en un VR. Recuerde que el dispositivo comprueba las tablas de enrutamiento del
valor de preferencia más alto al más bajo.
En el ejemplo siguiente, habilitará tanto el enrutamiento SIBR como el

enrutamiento basado en el origen en el enrutador trust-vr. Desea que el dispositivo
de seguridad lleve a cabo operaciones de consulta de rutas en las tablas de
enrutamiento con el siguiente orden: Enrutamiento basado en el origen primero,
SIBR, y luego enrutamiento basado en destinos Para configurar esta secuencia de
consulta en la tabla de enrutamiento, debe configurar el enrutamiento basado en el
origen con un valor de preferencia más alto que el de SIBR — en este ejemplo,
asignará un valor de preferencia de 4 al enrutamiento basado en el origen.
WebUI
Network > Routing > Virtual Router > Edit (para el trust-vr): Introduzca los
Route Lookup Preference (1-255): (seleccione)

For Source Based Routing: 4
Enable Source Based Routing: (seleccione)
Enable Source Interface Based Routing: (seleccione)

CLI
set vrouter trust-vr sibr-routing enable
set vrouter trust-vr source-routing enable
set vrouter trust-vr route-lookup preference source-routing 4
save
Consulta de rutas en múltiples enrutadores virtuales

Sólo puede especificar otro VR como el salto siguiente para una entrada de
enrutamiento basada en destinos, y no para una entrada de enrutamiento basada
en el origen o en la interfaz. Por ejemplo, la ruta predeterminada en la tabla de
enrutamiento basada en destinos puede especificar el untrust-vr como el siguiente
salto, luego la entrada del untrust-vr puede especificar otro VR, como DMZ. El
dispositivo verificará hasta un total de tres VR. Donde la consulta de rutas en un VR
da lugar a consultas de rutas en otro VR, el dispositivo de seguridad siempre lleva a
cabo las segundas operaciones de consulta de rutas en la tabla de enrutamiento
basada en destinos.
En el ejemplo, habilitará el enrutamiento basado en origen tanto en las tablas de

enrutamiento trust-vr como en las tablas de enrutamiento untrust-vr. Trust-vr posee
las siguientes entradas de enrutamiento:
Una entrada de enrutamiento basada en origen para la subred 10.1.1.0/24, con

ethernet3 como la interfaz de reenvío y el enrutador en 1.1.1.1 como el
siguiente salto
Una ruta predeterminada, con el untrust-vr como el siguiente salto
El untrust-vr posee las siguientes entradas de enrutamiento:
Una entrada de enrutamiento basada en origen para la subred 10.1.1.0/24, con

ethernet4 como la interfaz de reenvío y el enrutador en 2.2.2.2 como el
siguiente salto
Una ruta predeterminada, con ethernet3 como la interfaz de reenvío y el

enrutador en 1.1.1.1 como el siguiente salto
La Figura 9 muestra cómo el tráfico de la subred 10.1.2.0/24 siempre se reenvía a

través de ethernet3 al enrutador en 1.1.1.1.
Figura 9: Consulta de rutas en múltiples VR
ISP1
10.1.1.0/24 1.1.1.1
ethernet1 ethernet3
ethernet2 ethernet4
ISP2
10.1.2.0/24 2.2.2.2

La tabla de enrutamiento basada en el origen para el trust-vr incluye la siguiente

entrada:

* 1 10.1.1.0/24 eth3 2.2.2.250 S 20 1 Root
La tabla de enrutamiento basada en destinos para el untrust-vr incluye la siguiente

entrada:

* 1 0.0.0.0/24 n/a untrust-vr S 20 0 Root
El tráfico desde la subred 10.1.2.0/24 llega en el dispositivo de seguridad en

ethernet2. Puesto que no hay entrada de enrutamiento basada en el origen que
coincida, el dispositivo de seguridad realiza consultas de rutas en la tabla de
enrutamiento basada en destinos. La ruta predeterminada en la tabla de
enrutamiento basada en destinos especifica el untrust-vr como el salto siguiente.
A continuación, el dispositivo de seguridad no comprueba la tabla de enrutamiento

basada en el origen del untrust-vr para que busque la siguiente entrada:

* 1 10.1.2.0/24 eth4 2.2.2.250 S 20 1 Root
En su lugar, el dispositivo de seguridad comprueba la tabla de enrutamiento con

base en destinos y busca la siguiente entrada:

* 1 0.0.0.0/24 eth3 1.1.1.150 S 20 0 Root
En el untrust-vr, el dispositivo de seguridad sólo realiza consultas de rutas en la

tabla de enrutamiento basada en destinos, incluso si la tabla de enrutamiento
basada en origen del untrust-vr contiene una entrada que coincida con el tráfico. La
ruta que coincide en la tabla de enrutamiento basada en destinos (la ruta
predeterminada) reenvía el tráfico en la interfaz ethernet3.
Configuración del enrutamiento multidireccional de igual coste

Los dispositivos de seguridad de Juniper Networks admiten el enrutamiento
multidireccional de igual coste (ECMP) de forma específica en cada sesión. Las rutas
de igual coste tienen los mismos valores de preferencia y de métrica. Una vez que
un dispositivo de seguridad asocia una sesión con una ruta, el dispositivo de
seguridad utiliza dicha ruta hasta que memoriza otra mejor o hasta que la actual
deja de ser utilizable. Las rutas elegibles deben tener interfaces de salida que
pertenezcan a las misma zona.
NOTA: Si las interfaces de salida no pertenecen a las misma zona y el paquete de vuelta
va a una zona diferente a la prevista, no se podrá producir una coincidencia de
sesiones y es posible que el tráfico no pueda pasar.

NOTA: Cuando el ECMP se habilita y las interfaces salientes son diferentes y están en el
modo NAT, las aplicaciones (como HTTP) que crean sesiones múltiples no
funcionarán correctamente. Las aplicaciones (como telnet o SSH) que crean una
sesión, deberían funcionar correctamente.
ECMP asiste con equilibrio de cargas entre dos a cuatro rutas al mismo destino o
aumenta la eficacia de utilización del ancho de banda entre dos o más destinos.
Cuando el ECMP está habilitado, los dispositivos de seguridad utilizan las rutas
definidas estáticamente o memorizan dinámicamente varias rutas al mismo
destino mediante un protocolo de enrutamiento. El dispositivo de seguridad asigna
rutas de igual coste en el modo de ronda recíproca (round robin).
Sin ECMP, el dispositivo de seguridad utiliza únicamente la primera ruta aprendida

o definida. Las otras rutas que sean de igual coste no se utilizan hasta que la ruta
activa deje de estarlo.
NOTA: Al usar ECMP, si tiene dos dispositivos de seguridad en una relación de vecindad y
observa la pérdida de un paquete y un equilibrio de cargas incorrecto, compruebe
la configuración del protocolo de resolución de direcciones (ARP) del dispositivo
vecino para asegurarse de que la función arp always-on-dest está deshabilitada
(predeterminado). Para obtener más información acerca de los comandos
relacionados con ARP, consulte “Interfaces fuera de línea y flujo de tráfico” en la
página 2-73.
Por ejemplo, considere las dos rutas siguientes que aparecen en la tabla de
enrutamiento basad en destinos trust-vr:
* 8 0.0.0.0/0 ethernet3 1.1.1.250 C 0 1 Root

9 0.0.0.0/0 ethernet2 2.2.2.250 S 20 1 Root
En este ejemplo, hay dos rutas predeterminadas para proporcionar conexiones a

dos ISP diferentes, y el objetivo es utilizar ambas rutas predeterminadas con ECMP.
Las dos rutas tienen los mismos valores métricos; sin embargo, la primera ruta es
una ruta conectada (C con una preferencia de 0). El dispositivo de seguridad
adquirió la primera ruta a través de DHCP o de PPP y el dispositivo adquirió la ruta
predeterminada a través de la configuración manual. La segunda ruta es una ruta
estática configurada manualmente (S con una preferencia automática de 20). Con
ECMP deshabilitado, el dispositivo de seguridad reenvía todo el tráfico a la ruta
conectada en ethernet3.

Para alcanzar equilibrio de carga con ambas rutas, cambie la preferencia de ruta de
la ruta estática a cero (0) para que coincida con la ruta conectada introduciendo el
comando set vrouter trust-vr preference static 0 y luego habilitando ECMP. Con
ECMP habilitado, la carga del dispositivo de seguridad equilibra el tráfico alternando
entre dos rutas ECMP válidas. La siguiente pantalla muestra la tabla de
enrutamiento actualizada.
* 8 0.0.0.0/0 ethernet3 1.1.1.250 C 0 1 Root

* 9 0.0.0.0/0 ethernet2 2.2.2.250 S 0 1 Root
Si habilita ECMP y el dispositivo de seguridad encuentra más de una ruta

coincidente del mismo coste en una tabla de enrutamiento, el dispositivo
selecciona una ruta diferente de igual coste para cada consulta de ruta. Con las
rutas indicadas anteriormente, el dispositivo de seguridad alterna entre ethernet3 y
ethernet2 para reenviar el tráfico a la red 0.0.0.0/0.
Si hay más de dos rutas de igual coste en la red, el dispositivo de seguridad realiza
una selección de las rutas en orden rotativo (ronda recíproca) hasta el máximo
configurado de modo que el dispositivo seleccione una ruta ECMP diferente para
cada consulta de ruta.
ECMP está inhabilitado de forma predeterminada (el número máximo de rutas

es 1). Para habilitar el enrutamiento ECMP, debe especificar el número máximo de
rutas de igual coste por enrutador. Puede especificar hasta cuatro rutas. Una vez que
establezca el número máximo de rutas, el dispositivo de seguridad no añadirá o
modificará rutas aunque reconozca más.
En el siguiente ejemplo, establecerá el número máximo de rutas ECMP en el

trust-vr en 2. Aunque puede haber 3 ó 4 rutas de igual coste dentro de la misma
zona y en la tabla de enrutamiento, el dispositivo de seguridad únicamente alterna
entre el número configurado de rutas elegibles. En este caso, los datos sólo se
redireccionan a lo largo de las 2 rutas ECMP especificadas.
WebUI
Network > Routing > Virtual Routers > Edit (para el trust-vr): Introduzca los
Maximum ECMP Routes:

Set Limit at: (seleccione), 2
CLI
set vrouter trust-vr max-ecmp-routes 2
save
Redistribución de rutas
La tabla de enrutamiento de un VR contiene rutas agrupadas según todos los
protocolos de enrutamiento dinámico que se ejecutan en el VR, así como las rutas
estáticas y las rutas conectadas directamente. De forma predeterminada, un
protocolo de enrutamiento dinámico (como OSPF, RIP o BGP) notifica a sus
adyacentes o interlocutores sólo las rutas que cumplen las siguientes condiciones:
Las rutas deben estar activas en la tabla de enrutamiento.

Las rutas deben ser reconocidas por el protocolo de enrutamiento dinámico.
NOTA: OSPF, RIP, y BGP también notifican las rutas conectadas de las interfaces de
ScreenOS en las que estos protocolos están habilitados.
Para que un protocolo de enrutamiento dinámico pueda notificar rutas previamente

reconocidas por otro protocolo, incluidas la rutas configuradas estáticamente, es
necesario redistribuir las rutas del protocolo origen al protocolo que realiza la
notificación.
Puede redistribuir las rutas reconocidas por un protocolo de enrutamiento (incluidas

la rutas configuradas estáticamente) a otro protocolo de enrutamiento diferente en
el mismo VR. Esto permite al protocolo de enrutamiento receptor notificar las rutas
redistribuidas. Cuando se importa una ruta, el dominio actual tiene que traducir
toda la información, en particular las rutas conocidas, del otro protocolo al suyo
propio. Por ejemplo, si un dominio de enrutamiento utiliza OSPF y conecta con un
dominio de enrutamiento que utiliza el protocolo BGP, el dominio OSPF tiene que
importar todas las rutas del dominio BGP para informar a todos sus vecinos OSPF
sobre cómo llegar a los dispositivos del dominio BGP.
Las rutas se distribuyen entre los protocolos según una regla de redistribución que
define el administrador del sistema o de la red. Cuando se añade una ruta a la tabla
de enrutamiento de un enrutador virtual, se le aplican una a una todas las reglas de
redistribución definidas en el VR para determinar si la ruta tiene que ser
redistribuida. Cuando se elimina una ruta de la tabla de enrutamiento de un
enrutador virtual, se le aplican una a una todas las reglas de redistribución definidas
en el VR para determinar si la ruta tiene que ser eliminada de otro protocolo de
enrutamiento del VR. Observe que todas las reglas de redistribución se aplican
cuando se añade o se elimina una ruta. No existe el concepto de orden de las reglas
o de “primera regla aplicable” para las reglas de redistribución.
NOTA: Sólo puede definir una regla de redistribución entre dos protocolos cualesquiera.
En el dispositivo de seguridad, se configura un mapa de rutas para especificar qué

rutas van a ser redistribuidas y los atributos de las rutas redistribuidas.
Configuración de un mapa de rutas

Un mapa de rutas consiste en un conjunto de declaraciones que se aplican en orden
secuencial a una ruta. Cada declaración del mapa de rutas define una condición que
se comprueba con la ruta. Una ruta se compara con cada declaración de un mapa
de rutas determinado en orden creciente del número de secuencia hasta que haya
una coincidencia, entonces se realiza la acción especificada en la declaración. Si la
ruta cumple la condición de la declaración del mapa de rutas, la ruta es aceptada o
rechazada. Una declaración del mapa de rutas puede también modificar ciertos
atributos de una ruta coincidente. Hay un rechazo implícito al final de todo mapa de
rutas; esto es, si una ruta no coincide con ninguna entrada del mapa de rutas, se
rechaza. La Tabla 3 detalla las condiciones de comparación del mapa de rutas y
ofrece una descripción de cada una.

Tabla 3: Condiciones de comparación del mapa de rutas
Condición de
comparación Descripción
BGP AS Path Compara con una lista de acceso AS path determinada. Consulte “Filtrado
de rutas” en la página 41.
BGP Community Compara con una lista de comunidades determinada. Consulte “Filtrado
de rutas” en la página 41.
OSPF route type Compara con un OSPF interno, externo de tipo 1 o externo de tipo 2.
Interface Compara con una interfaz determinada.
IP address Compara con una lista de acceso determinada. Consulte “Filtrado de rutas”
en la página 41.
Metric Compara con un valor de métrica de ruta determinado.
Next-hop Compara con una lista de acceso determinada. Consulte “Filtrado de rutas”
en la página 41.
Tag Compara con una dirección IP o etiqueta de ruta determinada.
Para cada condición de comparación, especifica si una ruta que cumple la

condición es aceptada (permit) o rechazada (deny). Si una ruta cumple la condición
y es aceptada, puede opcionalmente dar valor a los atributos para la ruta. La Tabla 4
detalla los atributos del mapa de rutas y las descripciones de cada uno.
Tabla 4: Atributos del mapa de rutas
Atributos
establecidos Descripción
BGP AS Path Añade una lista de acceso AS path determinada al principio de la lista de
atributos de camino de la ruta coincidente.
BGP Community Establece el atributo de comunidad de la ruta coincidente a la lista de
comunidades especificada.
BGP local preference Establece el atributo local-pref de la ruta coincidente al valor
especificado.
BGP weight Establece el peso de la ruta coincidente.
Offset metric Aumenta la métrica de la ruta coincidente hasta el valor especificado.
Esto aumenta la métrica en una ruta menos deseable. Para las rutas RIP,
puede aplicar el incremento tanto a las rutas notificadas (route-map out)
o a las rutas reconocidas (route-map in). Para otras rutas, puede aplicar
el incremento a las rutas que se exportan a otro VR.
OSPF metric type Establece el tipo de métrica OSPF de la ruta coincidente a externo tipo 1
o externo tipo 2.
Metric Establece la métrica de la ruta coincidente al valor especificado.
Next-hop of route Establece el siguiente salto de la ruta coincidente a la dirección IP
especificada.
Preserve metric Preserva la métrica de una ruta coincidente que se exporta a otro VR.
Preserve preference Conserva el valor de preferencia de la ruta coincidente que se exporta a
otro VR.
Tag Establece la etiqueta de la ruta coincidente al valor especificado o la
dirección IP.

Filtrado de rutas
El filtrado de rutas le permite controlar qué rutas se admiten en un VR, cuáles se
notifican a los interlocutores y cuáles se redistribuyen de un protocolo de
enrutamiento a otro. Puede aplicar filtros a las rutas entrantes enviadas por un
interlocutor de enrutamiento o a rutas salientes enviadas por el VR de seguridad a
los enrutadores de interlocución. Puede utilizar los siguientes mecanismos de
filtrado:
Lista de acceso: Consulte ”Configuración de una lista de acceso” para obtener

información sobre la configuración de la lista de acceso.
Lista de acceso BGP AS-path: Un atributo AS-path es una lista de los sistemas
autónomos por los que ha pasado una notificación de ruta y es parte de la
información de ruta. Una lista de acceso AS-path es un conjunto de expresiones
regulares que representan AS específicos. Puede utilizar una lista de acceso
AS-path para filtrar las rutas según el AS por el que ha pasado la ruta. Consulte
“Configuración de una lista de acceso AS-Path” en la página 124 para obtener
información sobre la configuración de una lista de acceso AS-path.
Lista de comunidades BGP: Un atributo de comunidad contiene los

identificadores de las comunidades a las que pertenece una ruta BGP. Una lista
de comunidades BGP es un conjunto de comunidades BGP que puede utilizar
para filtrar las rutas según las comunidades a las que pertenecen. Consulte
“Comunidades BGP” en la página 133 para obtener información sobre la
configuración de la lista de comunidades BGP.
Configuración de una lista de acceso

Una lista de acceso es una lista de declaraciones de secuencia con la que se
compara la ruta. Cada declaración especifica la dirección/máscara IP de un prefijo
de red y el estado de reenvío (acepta o rechaza la ruta). Por ejemplo, una
declaración de una lista de acceso puede permitir las rutas de la subred 1.1.1.0/24.
Otra de la misma lista de acceso puede rechazar rutas de la subred 2.2.2.0/24. Si
una ruta coincide con la declaración de la lista de acceso, se aplica el estado de
reenvío especificado.
La secuencia de declaraciones de una lista de acceso es importante, puesto que una

ruta se compara ordenadamente con todas las declaraciones desde la primera hasta
que coincide con una. Si hay una coincidencia, todas las demás de la lista se
ignoran. Debe colocar las declaraciones más específicas antes de las menos
específicas. Por ejemplo, colocar la declaración que rechaza las rutas de la subred
1.1.1.1/30 antes de la que permite las rutas de la subred 1.1.1.0/24.
También puede utilizar listas de acceso para controlar el flujo del tráfico multicast.
Para obtener información, consulte “Listas de acceso” en la página 161.
En este ejemplo, creará una lista de acceso en el trust-vr. La lista de acceso tiene las
siguientes características:
Identifier: 2 (debe especificar un identificador de lista de acceso cuando se

configura la lista de acceso)
Forwarding Status: permit

IP Address/Netmask Filtering: 1.1.1.1/24
Sequence Number: 10 (sitúa esta declaración con respecto a otras en la lista de

acceso)
WebUI
Network > Routing > Virtual Routers > Access List: > New (para el trust-vr):
Access List ID: 2

Sequence No.: 10
IP/Netmask: 1.1.1.1/24
Action: Permit
CLI
set vrouter trust-vr access-list 2 permit ip 1.1.1.1/24 10
save
Redistribución de rutas en OSPF

En este ejemplo, redistribuirá determinadas rutas BGP que han pasado por el
sistema autónomo 65000 en OSPF. Primero configura una lista de acceso AS-path
que permite las rutas que han pasado por el AS 65000. (Para obtener más
información sobre la configuración de una lista de acceso AS-path, consulte
“Configuración de una lista de acceso AS-Path” en la página 124.) Luego,
configurará un mapa de rutas “mapa_rutas1” que selecciona las rutas de la lista de
acceso AS-path. Por último, en OSPF especificará una regla de redistribución que
utilizará el mapa de rutas “mapa_rutas1” y luego especificará BGP como protocolo
de origen de las rutas.
WebUI
1. Lista de acceso BGP AS-path
Network > Routing > Virtual Routers > Edit (para el trust-vr) > Edit BGP
Instance > AS Path: Introduzca los siguientes datos y haga clic en Add:
AS Path Access List ID: 1

Permit: (seleccione)
AS Path String: _65000_
2. Mapa de rutas
Network > Routing > Virtual Routers > Route Map > New (para el trust-vr):
Map Name: mapa_rutas1

Sequence No.: 10
Action: Permit (seleccione)
Match Properties:
AS Path: (seleccione), 1

3. Regla de redistribución
Network > Routing > Virtual Router > Edit (para el trust-vr) > Edit OSPF
Instance > Redistributable Rules: Seleccione los siguientes datos y haga clic
en Add:
Route Map: mapa_rutas1

Protocol: BGP
CLI
1. Lista de acceso BGP AS-path
set vrouter trust-vr protocol bgp as-path-access-list 1 permit _65000_
2. Mapa de rutas
device(trust-vr)-> set route-map name mapa_rutas1 permit 10
device(trust-vr/mapa_rutas1-10)-> set match as-path 1
device(trust-vr/mapa_rutas1-10)-> exit
3. Regla de redistribución
set vrouter trust-vr protocol ospf redistribute route-map mapa_rutas1 protocol
bgp
save
Exportación e importación de rutas entre enrutadores virtuales

Si tiene dos VR configurados en un dispositivo de seguridad, puede permitir que
rutas especificadas en un VR sean reconocidas por el otro VR. Para hacerlo, debe
definir reglas de exportación en el VR origen que exporten las rutas al VR destino.
Cuando se exportan rutas, un enrutador virtual permite a otros VR reconocer su
red. En el VR destino, puede configurar opcionalmente reglas de importación para
controlar las rutas que pueden ser importadas del VR origen. Si no hay reglas de
importación en el VR destino, se aceptan todas las rutas exportadas.
Para exportar e importar rutas entre enrutadores virtuales:
1. Defina una regla de exportación en el VR origen.
2. Defina una regla de importación en el VR destino (opcional). Aunque este paso

es opcional, una regla de importación le permite un mayor control de las rutas
que el enrutador virtual de destino acepta del enrutador virtual de origen.
En el dispositivo de seguridad, se configura una regla de exportación o importación

con las especificaciones que se dan a continuación:
El enrutador virtual de destino (para las reglas de exportación) o el enrutador

virtual de origen (para las reglas de importación)
El protocolo de las rutas que van a ser exportadas/importadas
Qué rutas van a ser exportadas/importadas
Los atributos nuevos o modificados de las rutas exportadas/importadas

(opcional)

La configuración de una regla de exportación o importación es similar a la de una

regla de redistribución. Los mapas de rutas se configuran para especificar qué rutas
van a ser exportadas/importadas y los atributos de las mismas.
Puede configurar la exportación automática de todas las entradas de la tabla de

rutas del trust-vr al untrust-vr. Puede configurar también que un enrutador virtual
definido por el usuario exporte automáticamente rutas a otro enrutador virtual. Las
rutas de las redes directamente conectadas a las interfaces en modo NAT no pueden
ser exportadas.
Configuración de una regla de exportación

En este ejemplo, las rutas OSPF de la red 1.1.1.1/24 del enrutador virtual trust-vr se
exportan al dominio de enrutamiento del untrust-vr. Primero creará una lista de
acceso para el prefijo de red 1.1.1.1/24, que luego se utilizará en el mapa de rutas
“mapa_rutas1” para filtrar las rutas de la red 1.1.1.1/24. En segundo lugar, creará
una regla de exportación de rutas para exportar las rutas OSPF coincidentes del
trust-vr al enrutador virtual untrust-vr.
WebUI
trust-vr
1. Lista de accesos
Access List ID: 2

Sequence No.: 10
Action: Permit
2. Mapa de rutas
Network > Routing > Virtual Routers > Route Map > New (para el trust-vr):
Map Name: mapa_rutas1

Sequence No.: 10
Match Properties:
Access List: (seleccione), 2
3. Regla de exportación
Network > Routing > Virtual Routers > Export Rules > New (para el trust-vr):
Destination Virtual Router: untrust-vr

Route Map: mapa_rutas1
Protocol: OSPF
CLI
trust-vr
1. Lista de accesos
device(trust-vr)-> set access-list 2 permit ip 1.1.1.1/24 10

2. Mapa de rutas
device(trust-vr)-> set route-map name mapa_rutas1 permit 10
device(trust-vr/mapa_rutas1-10)-> set match ip 2
device(trust-vr/mapa_rutas1-10)-> exit
3. Regla de exportación
device(trust-vr)-> set export-to vrouter untrust-vr route-map mapa_rutas1
protocol ospf
save
Configuración de la exportación automática

Puede configurar la exportación automática de todas las rutas del trust-vr al
untrust-vr.
PRECAUCIÓN: Esta función puede anular el aislamiento entre trust-vr y untrust-vr

al poner a la vista todas las rutas fiables en la red no fiable.
Si define reglas de importación para el untrust-vr, sólo se importan las rutas que
cumplan las reglas de importación. En este ejemplo, el trust-vr exporta
automáticamente todas las rutas al untrust-vr, pero una regla de importación del
untrust-vr permite que se exporten sólo las rutas de OSPF interno.
WebUI
trust-vr
Network > Routing > Virtual Router > Edit (para el trust-vr): Seleccione Auto
Export Route to Untrust-VR, luego haga clic en OK.
untrust-vr
Network > Routing > Virtual Router > Route Map (para untrust-vr) > New:
Map Name: from-ospf-trust

Sequence No.: 10
Route Type: internal-ospf (seleccione)
CLI
trust-vr
set vrouter trust-vr auto-route-export
untrust-vr
set vrouter untrust-vr
device(untrust-vr)-> set route-map name from-ospf-trust permit 10
device(untrust-vr/from-ospf-trust-10)-> set match route-type internal-ospf
device(untrust-vr/from-ospf-trust-10)-> exit
device(untrust-vr)-> set import-from vrouter trust-vr route-map from-ospf-trust
protocol ospf
device(untrust-vr)-> exit
save


Capítulo 3
Abrir primero la ruta más corta
En este capítulo se describe el protocolo de enrutamiento OSPF (Open Shortest Path

First) en los dispositivos de seguridad. Incluye las siguientes secciones:
“Áreas” en la página 48
“Clasificación de enrutadores” en la página 49
“Protocolo de saludo” en la página 50
“Tipos de redes” en la página 50
“Notificaciones de estado de conexiones” en la página 51
“Configuración básica de OSPF” en la página 51
“Creación y eliminación de una instancia de enrutamiento OSPF” en la

página 53
“Creación y eliminación de un área OSPF” en la página 54
“Asignación de interfaces a un área OSPF” en la página 55
“Habilitación de OSPF en interfaces” en la página 56
“Verificación de la configuración” en la página 57
“Redistribución de rutas en protocolos de enrutamiento” en la página 59
“Resumen de rutas redistribuidas” en la página 60
“Parámetros globales de OSPF” en la página 61
“Notificación de la ruta predeterminada” en la página 62
“Conexiones virtuales” en la página 62
“Ajuste de parámetros OSPF de interfaz” en la página 64
47
“Configuración de seguridad” en la página 67
“Autenticación de vecinos” en la página 67
“Configuración de una lista de vecinos de OSPF” en la página 68
“Rechazo de rutas predeterminadas” en la página 69
“Protección contra inundaciones” en la página 69
“Creación de un circuito de demanda OSPF en una interfaz de túnel” en la

página 71
“Interfaz de túnel punto a multipunto” en la página 71
“Establecer el tipo de conexión OSPF” en la página 72
“Inhabilitación de la restricción Route-Deny” en la página 72
“Creación de una red punto a multipunto” en la página 73
Vista general
El protocolo de enrutamiento OSPF (Open Shortest Path First, abrir primero la ruta
más corta) es un protocolo de puerta de enlace interior (IGP) desarrollado para
ejecutarse dentro de un único sistema autónomo. Un enrutador que ejecute OSPF
distribuye su información de estado (como interfaces disponibles para el uso
y accesibilidad por parte de equipos vecinos) inundando periódicamente el sistema
autónomo con notificaciones de estado de conexiones (LSA, link-state
advertisements).
Los enrutadores OSPF utilizan las LSA de los enrutadores contiguos para actualizar
una base de datos de estado de conexiones. Esta base de datos es una tabla que
informa de la topología y el estado de las redes de un área. La distribución
constante de las LSA a través del dominio de enrutamiento permite a todos los
enrutadores de un sistema autónomo disponer de bases de datos de estado de
conexiones idénticas.
El protocolo OSPF utiliza la base de datos de estado de conexiones para determinar

cuál es la mejor ruta a una red cualquiera dentro del sistema autónomo. Esto se
consigue generando un árbol de ruta más corta, que es una representación gráfica
de la ruta más corta a una determinada red dentro del sistema autónomo. Aunque
todos los enrutadores tienen la misma base de datos de estado de conexiones, sus
árboles de ruta más corta son exclusivos, ya que los enrutadores generan estos
árboles situándose a sí mismos en su raíz.
Áreas
De forma predeterminada, todos los enrutadores se agrupan en una única área
troncal llamada area 0 o “backbone” (normalmente es el área 0.0.0.0). Sin
embargo, las redes de gran tamaño que se encuentran dispersas geográficamente
se suelen segmentar en múltiples áreas. A medida que la red se amplía, las bases de
datos de estado de conexión también crecen y se dividen en grupos más pequeños
para mejorar su posibilidad de ampliación.
48 Vista general
Capítulo 3: Abrir primero la ruta más corta
Las áreas reducen el volumen de información de enrutamiento que pasa a través de

la red, ya que cada enrutador sólo tiene que actualizar la base de datos de estado
del área a la que pertenece. No necesita actualizar la información de estado de las
redes o enrutadores que se encuentran en otras áreas. Un enrutador conectado
a múltiples áreas mantiene una base de estado de conexiones por cada área a la
que está conectado. Las áreas deben estar conectadas directamente al área 0,
excepto cuando crean una conexión virtual. Para obtener más información sobre
conexiones virtuales, consulte la página 62.
Las notificaciones externas de AS describen rutas a destinos en otros sistemas AS

y se inundan en todo un AS. Ciertas áreas OSPF se pueden configurar como áreas
de rutas internas (stub areas); de este modo, las notificaciones externas de sistemas
autónomos no inundarán estas áreas. En OSPF se utilizan normalmente dos tipos
de áreas habituales:
Área de ruta interna: área que recibe resúmenes de ruta del área troncal pero
que no recibe notificaciones de estado de conexiones de otras áreas acerca de
enrutadores reconocidos por protocolos distintos a OSPF (BGP, por ejemplo).
Un área de ruta interna se puede considerar un área exclusiva de rutas internas
(totally stubby) si en ella no se admiten rutas de resumen.
Área NSSA: al igual que las áreas de rutas internas normales, las NSSA (Not So
Stubby Area, áreas no exclusivas de rutas internas) no pueden recibir
enrutadores de protocolos distintos de OSPF fuera del área actual. Sin embargo,
los enrutadores externos conocidos dentro del área también se pueden
reconocer en otras áreas, y así pasar a ellas.
Clasificación de enrutadores
Los enrutadores que participan en el enrutamiento OSPF se clasifican de acuerdo
con su función o su posición en la red:
Enrutador interno: enrutador cuyas interfaces pertenecen a la misma área.
Enrutador de área troncal: enrutador con una interfaz en el área troncal.
Enrutador de límite de área: enrutador conectado a dos o más áreas. Este tipo
de enrutador resume las rutas desde distintas áreas para su distribución al área
troncal. En los dispositivos de seguridad con OSPF, el área troncal se crea de
forma predeterminada. Si se crea una segunda área en un enrutador virtual, el
dispositivo funcionará como enrutador de límite de área.
Enrutador de límite de sistema autónomo: cuando un área OSPF limita con

otro sistema autónomo, el enrutador situado entre los dos sistemas autónomos
se considera el enrutador de límite. Estos enrutadores se encargan de distribuir
la información de enrutamiento de los sistemas autónomos externos por su
sistema autónomo.
Vista general 49
Protocolo de saludo
Dos enrutadores con interfaces en la misma subred se consideran vecinos. Los
enrutadores utilizan el protocolo de saludo para establecer y mantener estas
relaciones de vecindad. Cuando dos enrutadores establecen comunicación
bidireccional, se dice que han establecido una adyacencia. Si dos enrutadores no
establecen una relación de adyacencia, no podrán intercambiar información de
enrutamiento.
Cuando hay múltiples enrutadores en una red, es necesario configurar un enrutador

como enrutador designado y otro como enrutador designado de respaldo. El
enrutador designado es responsable de inundar la red con LSA que contengan una
lista de todos los enrutadores que admitan OSPF incorporados a la red. El enrutador
designado es el único que puede formar adyacencias con otros enrutadores de la
red. Así, el enrutador designado es el único de la red que puede proporcionar
información de enrutamiento al resto de enrutadores. El enrutador designado de
respaldo sustituye al enrutador designado en caso de que éste falle.
Tipos de redes
Los dispositivos de seguridad de Juniper Networks admiten los siguientes tipos de
redes OSPF:
Redes de difusión
Redes punto a punto
Redes punto a multipunto
Redes de difusión
Una red de difusión (broadcast) es una red que interconecta varios enrutadores y
que puede enviar (o difundir) un único mensaje físico a todos los enrutadores
conectados. Se parte de la base de que dos enrutadores cualesquiera en una red de
difusión son capaces de comunicarse entre sí. Ethernet es un ejemplo de red de
difusión.
En las redes de difusión, el enrutador OSPF detecta dinámicamente los enrutadores

vecinos enviando paquetes de saludo a la dirección multidifusión 224.0.0.5. En las
redes de difusión, el protocolo de saludo decide cuál será el enrutador designado
y el enrutador designado de respaldo para la red.
Una red que no sea de difusión conecta varios enrutadores entre sí pero no puede
difundir mensajes a los enrutadores conectados. En las redes que no son de
difusión, los paquetes del protocolo OSPF (que normalmente son multidifusión) se
tienen que enviar a cada uno de los enrutadores vecinos. Los dispositivos de
seguridad Juniper Networks no admiten OSPF en redes que no sean de difusión.
Redes punto a punto

Una red punto a punto une dos enrutadores a través de una red de área extensa
(WAN). Un ejemplo de red punto a punto serían dos dispositivos de seguridad
conectados a través de un túnel VPN IPSec. En las redes punto a punto, el enrutador
OSPF detecta dinámicamente los enrutadores vecinos enviando paquetes de saludo
a la dirección multicast 224.0.0.5.
50 Vista general
Redes punto a multipunto

Una red punto a multipunto es una red que no es de difusión en la que OSPF trata
las conexiones entre enrutadores como vínculos punto a punto. Para la red no
existe ninguna elección de un enrutador designado ni de inundación LSA. Un
enrutador en una red punto a multipunto envía paquetes de saludo a todos los
vecinos con quienes pueda comunicarse directamente.
NOTA: En dispositivos de seguridad, la configuración punto a multipunto del OSPF

solamente se admite en interfaces de túnel y se debe inhabilitar route-deny para
que la red funcione correctamente. No se puede configurar una interfaz física
Ethernet para conexiones punto a multipunto. Para obtener más información,
consulte “Interfaz de túnel punto a multipunto” en la página 71.
Notificaciones de estado de conexiones

Cada enrutador OSPF envía notificaciones de estado de conexiones (LSA) que
definen la información de estado local del enrutador. Además, hay otros tipos de
LSA que un enrutador envía, dependiendo de la función de OSPF del enrutador. La
Tabla 5 detalla los tipos de LSA, dónde se inunda cada tipo de LSA y el contenido de
cada tipo de LSA.
Tabla 5: Resumen del contenido y tipos de LSA
Distribuido
Tipo de LSA Enviado por en Información enviada en la LSA
LSA de Todos los enrutadores OSPF Área Describe el estado de todas las interfaces de enrutador en
enrutador toda el área.
LSA de red Enrutador designado en redes de Área Contiene una lista de todos los enrutadores conectados a la
difusión y NBMA red.
LSA de Enrutadores de límite de área Área Describe una ruta a un destino fuera del área, pero dentro
resumen del sistema autónomo. Hay dos tipos:
Las LSA de resumen de tipo 3 describen rutas a redes.
Las LSA de resumen de tipo 4 describen rutas limítrofes
con otros sistemas autónomos.
Externo de Enrutador de límite de sistema Sistema Rutas a redes en otro sistema autónomo. A menudo, se
sistema autónomo autónomo trata de la ruta predeterminada (0.0.0.0/0).
autónomo
Configuración básica de OSPF

Creará OSPF por cada enrutador virtual en un dispositivo de seguridad. Si dispone
de varios enrutadores virtuales (VR) en un sistema, podrá habilitar una instancia de
OSPF por cada enrutador virtual.
NOTA: Antes de configurar un protocolo de enrutamiento dinámico en el dispositivo de

seguridad, deberá asignar una ID de enrutador virtual, tal y como se describe en el
Capítulo 2,“Enrutamiento.”
Configuración básica de OSPF 51

En esta sección se describen los pasos básicos para configurar OSPF en un

enrutador virtual ubicado en un dispositivo de seguridad:
1. Crear y habilitar la instancia de enrutamiento OSPF en un enrutador virtual. En

este paso también se crea automáticamente un área troncal de OSPF, con una
ID de área de 0.0.0.0, que no se podrá eliminar.
2. (Opcional) A menos que todas las interfaces OSPF se conecten al área troncal,
tendrá que configurar una nueva área OSPF con su propia ID de área. Por
ejemplo, si el dispositivo de seguridad va a funcionar como enrutador de límite
de área, tendrá que crear otra área OSPF además del área troncal. La nueva
área que se cree podrá ser normal, de rutas internas o no exclusiva de rutas
internas.
3. Asignar una o varias interfaces a cada área OSPF. Las interfaces se deben
agregar a un área OSPF explícitamente, incluyendo el área troncal.
4. Habilitar OSPF en cada interfaz.
5. Comprobar que el protocolo OSPF está configurado correctamente y funciona.
En este ejemplo configuraremos el dispositivo de seguridad como enrutador de

límite de área conectándolo al área 0 a través de la interfaz ethernet3 y al área 10
a través de ethernet1. Consulte la Figura 10.
Figura 10: Ejemplo de configuración de OSPF

Zona Trust ethernet1 ethernet3 Zona Untrust
Internet
10.1.1.0/24 10.1.2.0/24
Área 10
Área 0
Opcionalmente también es posible configurar otros parámetros de OSPF, como:
Parámetros globales, como conexiones virtuales, que se configuran en el

enrutador virtual para el protocolo OSPF (consulte “Parámetros globales de
OSPF” en la página 61).
Parámetros de interfaz, como la autenticación, que se configuran en la interfaz

para el protocolo OSPF (consulte “Ajuste de parámetros OSPF de interfaz” en la
página 64).
Parámetros OSPF relacionados con la seguridad, que se configuran en el

enrutador virtual o en la interfaz (consulte “Configuración de seguridad” en la
página 67).
52 Configuración básica de OSPF

Creación y eliminación de una instancia de enrutamiento OSPF

Es posible crear y habilitar una instancia de enrutamiento OSPF en un VR específico
ubicado en un dispositivo de seguridad. Para eliminar una instancia de
enrutamiento OSPF, desactive la instancia OSPF y luego elimínela. Al crear la
instancia de enrutamiento OSPF se crea automáticamente el área troncal OSPF. Si
crea y habilita una instancia de enrutamiento OSPF en un enrutador virtual, OSPF
podrá transmitir y recibir paquetes en todas las interfaces habilitadas para OSPF del
enrutador.
Creación de una instancia de OSPF

En el siguiente ejemplo, en primer lugar asignará 0.0.0.10 como ID de enrutador
a trust-vr. A continuación creará una instancia de enrutamiento OSPF en él. (Para
obtener más información sobre VR y la configuración de un VR en dispositivos de
seguridad, consulte “Enrutamiento” en la página 13).
WebUI
1. ID de enrutador

En el cuadro de texto, introduzca 0.0.0.10
2. Instancia de enrutamiento OSPF
Network > Routing > Virtual Router (trust-vr) > Edit > Create OSPF Instance:
Seleccione OSPF Enabled, luego haga clic en OK.
CLI
1. ID de enrutador
2. Instancia de enrutamiento OSPF
set vrouter trust-vr protocol ospf
set vrouter trust-vr protocol ospf enable
save
NOTA: En la línea de comandos CLI, tendrá que crear la instancia de enrutamiento OSPF
antes de poder habilitarla. Por lo tanto, tendrá que ejecutar dos comandos CLI
para habilitar una instancia de enrutamiento OSPF.
Eliminación de una instancia de OSPF

En este ejemplo inhabilitará la instancia de enrutamiento OSPF en el enrutador
virtual trust-vr. OSPF dejará de transmitir y procesar paquetes OSPF en todas las
interfaces habilitadas para OSPF en el enrutador trust-vr.
WebUI
Network > Routing > Virtual Routers (trust-vr) > Edit > Edit OSPF Instance:
Desactive OSPF Enabled, luego haga clic en OK.
Network > Routing > Virtual Routers (trust-vr) > Edit > Delete OSPF
Instance, luego haga clic en OK en el mensaje de confirmación.

CLI
unset vrouter trust-vr protocol ospf
deleting OSPF instance, are you sure? y/[n]
save
NOTA: En CLI, confirme la eliminación de la instancia OSPF.
Creación y eliminación de un área OSPF

Las áreas reducen el volumen de información de enrutamiento que tiene que pasar
por la red, ya que los enrutadores OSPF sólo actualizan la base de datos de estado
de conexiones del área a la que pertenecen. No necesitan actualizar la información
de estado de las redes o enrutadores que se encuentran en otras áreas.
Todas las zonas deben conectarse a la zona 0, que se crea al configurar una
instancia de enrutamiento OSPF en el enrutador virtual. Si es necesario crear un
área OSPF adicional, también es posible definirla como área de rutas internas
o área no exclusiva de rutas internas. Si desea más información sobre estos tipos de
áreas, consulte “Áreas” en la página 48.
La Tabla 6 detalla los parámetros de área, con descripciones de cada parámetro,

e indica el valor predeterminado de cada uno de éstos.
Tabla 6: Parámetros de áreas de OSPF y sus valores predeterminados
Valor
Parámetro de área Descripción predeterminado
Metric for default route (Sólo áreas NSSA y de rutas internas.) Especifica 1
la métrica para la notificación de ruta
predeterminada
Metric type for the default (Sólo área NSSA.) Especifica el tipo de métrica 1
route externa (1 ó 2) para la ruta predeterminada
No summary (Sólo áreas NSSA y de rutas internas.) Especifica Las LSA de
que las LSA de resumen no se difundirán por el resumen se
área difunden por el
área
Range (Todas las áreas.) Especifica un rango de —
direcciones IP que se notificarán en las LSA de
resumen, y si éstas se notificarán o no
Creación de un área OSPF

En el siguiente ejemplo creará un área OSPF con la ID de area 10.
WebUI
Network > Routing > Virtual Routers > Edit (trust-vr) > Edit OSPF Instance
> Area: Introduzca los siguientes datos y haga clic en OK:
Area ID: 10
Type: normal (seleccione)
Action: Add

CLI
set vrouter trust-vr protocol ospf area 10
save
Eliminación de un área OSPF

Antes de que pueda eliminar un área de OSPF, debe desactivar el proceso de OSPF
para VR. En el siguiente ejemplo, detenga el proceso de OSPF y luego elimine un
área de OSPF con una ID de área de 10.
WebUI
Network > Routing > Virtual Routers (trust-vr) > Edit > Edit OSPF Instance:
Elimine la selección OSPF Enabled, luego haga clic en OK.
> Area: Haga clic en Remove.
CLI
unset vrouter trust-vr protocol ospf enable
unset vrouter trust-vr protocol ospf area 0.0.0.10
save
Asignación de interfaces a un área OSPF

Una vez que se ha creado un área, es posible asignarle una o varias interfaces, ya
sea utilizando la WebUI o el comando CLI set interface.
Asignación de interfaces a áreas

En el siguiente ejemplo asignará la interfaz ethernet1 al area OSPF 10 y la interfaz
ethernet3 al area OSPF 0.
WebUI
> Area > Configure (Area 10): Utilice el botón Add para mover la interfaz
ethernet1 de la columna Available Interface(s) a la columna Selected Interfaces.
Haga clic en OK.
Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit OSPF
Instance > Area > Configure (Area 0): Utilice el botón Add para mover la
interfaz ethernet3 de la columna Available Interface(s) a la columna Selected
Interfaces. Haga clic en OK.
CLI
set interface ethernet1 protocol ospf area 10
set interface ethernet3 protocol ospf area 0
save

Configuración de un rango de áreas

De forma predeterminada, un enrutador de límite de área no agrega las rutas
enviadas de un área a otra. Si configura un rango de áreas permitirá que un grupo
de subredes en un área se consolide en una única dirección de red para notificarse
en otras áreas por medio de una única notificación de conexión de resumen. Al
configurar un rango de áreas, deberá especificar si desea notificar o retener el rango
de áreas definido en las notificaciones.
En el siguiente ejemplo definirá los siguientes rangos de áreas para el area 10:
10.1.1.0/24, se notificará.
10.1.2.0/24, no se notificará.
WebUI
Instance > Area > Configure (0.0.0.10): Introduzca los siguientes datos en la
sección Area Range y haga clic en Add:
IP/Netmask: 10.1.1.0/24
Type: (seleccione) Advertise
Introduzca los siguientes datos en la sección Area Range y haga clic en Add:
IP/Netmask: 10.1.2.0/24
Type: (seleccione) No Advertise
CLI
set vrouter trust-vr protocol ospf area 10 range 10.1.1.0/24 advertise
set vrouter trust-vr protocol ospf area 10 range 10.1.2.0/24 no-advertise
save
Habilitación de OSPF en interfaces

De forma predeterminada, el protocolo OSPF está inhabilitado en todas las
interfaces del enrutador virtual (VR). Este protocolo se debe habilitar explícitamente
en una interfaz antes de poder asignarla a un área. Si se desactiva OSPF en una
interfaz, dejará de transmitir o recibir paquetes en esa interfaz, pero sus
parámetros de configuración se conservarán.
NOTA: Si se desactiva la instancia de enrutamiento OSPF en el enrutador virtual (consulte

“Eliminación de una instancia de OSPF” en la página 53), OSPF dejará de
transmitir y procesar paquetes en todas las interfaces del enrutador que tengan
este protocolo habilitado.
Habilitación de OSPF en interfaces

En este ejemplo habilitará la instancia de enrutamiento OSPF en la interfaz
ethernet1 (que previamente se había asignado al area 10) y en la interfaz ethernet3
(que previamente se asignó al area 0).

WebUI
Network > Interfaces > Edit (para ethernet1) > OSPF: Seleccione Enable
Protocol OSPF, luego haga clic en Apply.
Network > Interfaces > Edit (para ethernet3) > OSPF: Seleccione Enable
CLI
set interface ethernet1 protocol ospf enable
save
Inhabilitar OSPF en una interfaz

En este ejemplo inhabilitará la instancia de enrutamiento OSPF únicamente en la
interfaz ethernet1. Las demás interfaces del enrutador virtual trust-vr (VR) en que
se habilitó OSPF seguirán transmitiendo y procesando paquetes OSPF.
WebUI
Network > Interfaces > Edit (para ethernet1) > OSPF: Elimine Enable
CLI
unset interface ethernet1 protocol ospf enable
save
NOTA: Si se desactiva la instancia de enrutamiento OSPF en el enrutador virtual, OSPF

dejará de transmitir y procesar paquetes en todas las interfaces del enrutador que
tengan este protocolo habilitado (consulte “Eliminación de una instancia de OSPF”
en la página 53).
Verificación de la configuración
Puede ver la configuración introducida para trust-vr ejecutando el siguiente
comando CLI:
device-> get vrouter trust-vr protocol ospf config

VR: trust-vr RouterId: 10.1.1.250
----------------------------------
set protocol ospf
set enable
set area 0.0.0.10 range 10.1.1.0 255.255.255.0 advertise
set area 0.0.0.10 range 10.1.2.0 255.255.255.0 no-advertise
set interface ethernet1 protocol ospf area 0.0.0.10
set interface ethernet3 protocol ospf area 0.0.0.0

Puede verificar si OSPF se está ejecutando en el enrutador virtual con el comando

get vrouter trust-vr protocol ospf.
device-> get vrouter trust-vr protocol ospf

----------------------------------
OSPF enabled
Supports only single TOS(TOS0) route
Enrutador interno
Automatic vlink creation is disabled
Numbers of areas is 2
Number of external LSA(s) is 0
SPF Suspend Count is 10 nodes
Hold time between SPFs is 3 second(s)
Advertising default-route lsa is off
Default-route discovered by ospf will be added to the routing table
RFC 1583 compatibility is disabled.
Hello packet flooding protection is not enabled
LSA flooding protection is not enabled
Area 0.0.0.0
Total number of interfaces is 1, Active number of interfaces is 1
SPF algorithm executed 2 times
Number of LSA(s) is 1
Area 0.0.0.10
Total number of interfaces is 1, Active number of interfaces is 1
SPF algorithm executed 2 times
Number of LSA(s) is 0
Las zonas resaltadas muestran que OSPF se está ejecutando y verifican las zonas
OSPF activas y las interfaces activas en cada zona OSPF.
NOTA: Es recomendable asignar una ID de enrutador de forma explícita, en lugar de

utilizar el valor predeterminado. Para obtener más información sobre cómo
configurar una ID de enrutador, consulte “Enrutamiento” en la página 13.
Puede verificar si OSPF está habilitado en las interfaces y ver el estado de las
interfaces con el comando get vrouter trust-vr protocol ospf interface.
device-> get vrouter trust-vr protocol ospf interface

----------------------------------
Interface IpAddr NetMask AreaId Status State
--------------------------------------------------------------------------------
ethernet3 2.2.2.2 255.255.255.0 0.0.0.0 enabled Designated Router
ethernet1 10.1.1.1 255.255.255.0 0.0.0.10 enabled Up
Puede configurar la prioridad del enrutador virtual que desee seleccionar: el

enrutador designado (DR) o el enrutador designado de respaldo (BDR). En el
ejemplo anterior, la columna de estado (State) indica la prioridad del enrutador
virtual.

Puede verificar si la instancia de enrutamiento OSPF en el dispositivo de seguridad

ha establecido adyacencias con los vecinos OSPF ejecutando el comando get
vrouter trust-vr protocol ospf neighbor.
device-> get vrouter trust-vr protocol ospf neighbor

----------------------------------
Neighbor(s) on interface ethernet3 (Area 0.0.0.0)
IpAddr/If Index RouterId Priority State Options
------------------------------------------------------------------------------
2.2.2.2 2.2.2.250 1 Full E
Neighbor(s) on interface ethernet1 (Area 0.0.0.10)
IpAddr/If Index RouterId Priority State Options
------------------------------------------------------------------------------
10.1.1.1 10.1.1.252 1 Full E
En la columna “State” del ejemplo anterior, “Full” indica adyacencias OSPF

completas con vecinos.
Redistribución de rutas en protocolos de enrutamiento

La redistribución de rutas es el intercambio de información sobre rutas entre
protocolos de enrutamiento. Por ejemplo, se pueden redistribuir los siguientes tipos
de rutas en la instancia de enrutamiento OSPF de un mismo enrutador virtual:
Rutas reconocidas por BGP o RIP
Rutas conectadas directamente
Rutas importadas
Cuando se configura la redistribución de rutas, primero se debe especificar un

mapa de rutas para filtrar las rutas que se vayan a redistribuir. Para obtener más
información sobre la creación de mapas de rutas para la redistribución, consulte el
Capítulo 2, “Enrutamiento.”
En el siguiente ejemplo redistribuirá en el dominio de enrutamiento OSPF actual

una ruta originada en un dominio de enrutamiento BGP. Tanto en el ejemplo de la
WebUI como en el de la CLI, partiremos de la base de que ya ha creado un mapa de
rutas llamado add-bgp.
WebUI
Instance > Redistributable Rules: Introduzca los siguientes datos y haga clic
en Add:
Route Map: add-bgp

Protocol: BGP
CLI
set vrouter trust-vr protocol ospf redistribute route-map add-bgp protocol bgp
save
Redistribución de rutas en protocolos de enrutamiento 59

Resumen de rutas redistribuidas

En las grandes redes, donde pueden coexistir miles de direcciones de red, algunos
enrutadores podrían llegar a congestionarse por la gran cantidad de información de
ruta. Si ya redistribuyó rutas de un protocolo externo en la instancia de
enrutamiento OSPF actual, podrá reunir las rutas en una ruta de red general
o resumida. Al resumir múltiples direcciones, hará que un grupo de rutas se
reconozcan como una sola, simplificando así el proceso de consulta.
Una de las ventajas de crear resúmenes de rutas en redes grandes y complejas es

que se pueden aislar los cambios topológicos de otros enrutadores. Por ejemplo, si
una conexión específica en un dominio falla continuamente, la ruta resumida no
cambiaría, de modo que ningún enrutador externo al dominio tendría que
modificar una y otra vez su tabla de enrutamiento debido a los fallos de conexión.
Además de crear menos entradas en las tablas de enrutamiento de los enrutadores

troncales, la generación de resúmenes evita que las LSA se propaguen por otras
áreas cuando una de las redes incluidas en el resumen queda fuera de línea o
vuelve a ponerse en línea. En los resúmenes también se pueden incluir rutas
interzonales y rutas externas.
En ocasiones, una ruta resumida puede crear oportunidades para que se produzcan
bucles. Puede configurar una ruta hacia una interfaz NULL para evitar bucles. Al
final de esta sección encontrará un ejemplo de creación de una ruta resumida y un
ejemplo de establecer una interfaz NULL.
Resumen de rutas redistribuidas

En este ejemplo redistribuirá las rutas BGP a la instancia de enrutamiento OSPF
actual. A continuación resumirá el conjunto de rutas importadas en la dirección de
red 2.1.1.0/24.
WebUI
Instance > Redistributable Rules: Introduzca los siguientes datos y haga clic
en Add:
Route Map: add-bgp

Protocol: BGP
Instance > Summary Import: Introduzca los siguientes datos y haga clic
en Add:
CLI
set vrouter trust-vr protocol ospf redistribute route-map add-bgp protocol bgp
set vrouter trust-vr protocol ospf summary-import ip 2.1.1.0/24
save
60 Resumen de rutas redistribuidas

Parámetros globales de OSPF

En esta sección se describen parámetros globales de OSPF que se pueden
configurar de forma opcional en un enrutador virtual (VR). Cuando se configura un
parámetro OSPF en el nivel de enrutador virtual, los datos de configuración
afectarán a las operaciones de todas las interfaces que tengan habilitado el
protocolo OSPF. Es posible modificar los valores de los parámetros globales del
protocolo de enrutamiento OSPF por medio de las interfaces CLI y WebUI.
La Tabla 7 detalla los parámetros globales de OSPF y sus valores predeterminados.
Tabla 7: Parámetros globales de OSPF y sus valores predeterminados
Parámetros Valor
globales de OSPF Descripción predeterminado
Advertise default Especifica que una ruta predeterminada activa La ruta
route (0.0.0.0/0) en la tabla de rutas del enrutador virtual predeterminada no
se notifica en todas las áreas OSPF. También es se notifica.
posible especificar el valor de métrica o si la métrica
original de la ruta se preservará, así como el tipo de
métrica (ASE tipo 1 o tipo 2). También se puede
especificar que la ruta predeterminada siempre se
notifique.
Reject default route Especifica que cualquier ruta predeterminada La ruta
reconocida en OSPF no se agregará a la tabla de predeterminada
rutas. reconocida en
OSPF se agrega a la
tabla de rutas.
Automatic virtual Especifica que el VR creará una conexión virtual Desactivado.
link automáticamente si no puede acceder al área troncal
de OSPF.
Maximum hello Especifica el número máximo de paquetes de saludo 10.
packets OSPF que el VR puede recibir en un intervalo de
saludo.
Maximum LSA Especifica el número máximo de paquetes LSA de No hay valor
packets OSPF que el VR puede recibir dentro del intervalo en predeterminado.
segundos especificado.
RFC 1583 Especifica que la instancia de enrutamiento OSPF es OSPF versión 2, tal
compatibility compatible con la norma RFC 1583, una versión y como se define
anterior de OSPF. en RFC 2328.
Enrutamiento Especifica el número máximo de rutas (1-4) a utilizar Disabled (1).
multidireccional de para equilibrar cargas con los destinos que tengan
igual coste (ECMP) múltiples rutas de igual coste. Consulte la
“Configuración del enrutamiento multidireccional de
igual coste” en la página 36.
Virtual link Configura el área OSPF y la ID de enrutador para la No hay conexión
configuration conexión virtual. De forma opcional también puede virtual configurada.
configurar el método de autenticación, el intervalo de
saludo y el de retransmisión, el retardo de
transmisión o el intervalo de interlocutor muerto
para la conexión virtual.
Parámetros globales de OSPF 61

Notificación de la ruta predeterminada

La ruta predeterminada, 0.0.0.0/0, coincide con cada red de destino en una tabla de
rutas, aunque un prefijo más específico anulará la ruta predeterminada.
En este ejemplo, usted anunciará la ruta predeterminada de la instancia de

enrutamiento OSPF actual.
WebUI
Instance: Seleccione Advertising Default Route Enable, luego haga clic en OK.
NOTA: En la WebUI, la métrica predeterminada (1) 62 debe introducirse manualmente y

el tipo de métrica predeterminado es ASE tipo 1.
CLI
set vrouter trust-vr protocol ospf advertise-default-route metric 1 metric-type 1
save
Conexiones virtuales
Aunque todas las áreas deben estar conectadas directamente al área troncal,
algunas veces debe crear un área nueva que no se puede conectar físicamente al
área troncal. Para resolver este problema se puede configurar una conexión virtual.
Una conexión virtual proporciona un área remota con una ruta lógica al área troncal
a través de otra área.
En los enrutadores, la conexión virtual se debe configurar en los dos extremos de la

conexión. Para configurar una conexión virtual en el dispositivo de seguridad, debe
definir:
La ID del área OSPF que va a cruzar la conexión virtual. No es posible crear una
conexión virtual que cruce el área troncal o un área de rutas internas.
La ID del enrutador al otro extremo de la conexión virtual.
La Tabla 8 detalla los parámetros opcionales para las conexiones virtuales.
Tabla 8: Parámetros opcionales para conexiones virtuales
Parámetro de
conexión Valor
virtual Descripción predeterminado
Authentication Especifica la autenticación por contraseña de texto no Sin autenticación
encriptado o la autenticación MD5.
Dead interval Especifica el intervalo en segundos en que no se 40 segundos
producirá respuesta desde un dispositivo OSPF vecino
antes de que se determine que éste no funciona.
Hello interval Especifica el tiempo en segundos entre dos saludos 10 segundos
OSPF.
62 Parámetros globales de OSPF

Parámetro de
conexión Valor
virtual Descripción predeterminado
Retransmit Especifica el tiempo en segundos que transcurrirá antes 5 segundos
interval de que la interfaz reenvíe una LSA a un vecino que no
respondió a la primera LSA.
Transmit delay Especifica el tiempo en segundos entre las 1 segundo
transmisiones de paquetes de actualización de estado
de conexión enviados a una interfaz.
Creación de una conexión virtual

En el siguiente ejemplo creará una conexión virtual a través del área OSPF 10 desde
el dispositivo-A con ID de enrutador 10.10.1.250 al dispositivo-B con la ID de
enrutador 10.1.1.250. Consulte “Enrutamiento” en la página 13 para obtener más
información sobre la configuración de ID de enrutadores en los dispositivos de
seguridad). También puede configurar la conexión virtual con un retardo de tránsito
de 10 segundos. En cada dispositivo de seguridad, tendrá que identificar la ID de
enrutador del dispositivo en el otro extremo de la conexión virtual.
La Figura 11 muestra el ejemplo de configuración de red para una conexión virtual.
Figura 11: Creación de una conexión virtual
Área 0
Área 10 Dispositivo B
ethernet1 ethernet2
ID de Internet
enrutador
Dispositivo A ethernet 1 10.1.1.250
ID de
enrutador El dispositivo-A y el dispositivo-B
10.1.1.250 tienen una conexión virtual entre sí
ethernet 2
a través del área OSPF 10.
Área 20
NOTA: Debe habilitar OSPF en ambas interfaces de cada dispositivo y cerciorarse de que
OSPF se esté ejecutando en las interfaces de los dispositivos A y B antes de que la
conexión virtual se active.
Instance > Virtual Link: Introduzca los siguientes datos y haga clic en Add:
Area ID: 10 (seleccione)

Router ID: 10.1.1.250
> Configure: En el campo Transmit Delay, escriba 10 y haga clic en OK.
Parámetros globales de OSPF 63

CLI (dispositivo-A)
set vrouter trust-vr protocol ospf vlink area-id 10 router-id 10.1.1.250
set vrouter trust-vr protocol ospf vlink area-id 10 router-id 10.1.1.250 transit-delay
10
save
NOTA: En la interfaz CLI, primero tendrá que crear la conexión virtual y, a continuación,
configurar cualquier parámetro opcional para la conexión. Así, en el ejemplo
anterior, tendrá que ejecutar dos comandos distintos para crear y después
configurar la conexión virtual.
Instance > Virtual Link: Introduzca los siguientes datos y haga clic en Add:
Area ID: 10
Router ID: 10.10.1.250
> Configure: En el campo Transmit Delay, escriba 10 y haga clic en OK.
CLI (dispositivo-B)
transit-delay 10
save
Creación de una conexión virtual automática

Puede hacer que un enrutador virtual (VR) cree automáticamente una conexión
virtual para las instancias en las que no sea posible acceder al área troncal de la red.
Si el enrutador virtual crea conexiones virtuales automáticamente se ahorrará el
tiempo necesario para crear cada una de las conexiones virtuales de forma manual.
En el siguiente ejemplo configuraremos la creación automática de conexiones
virtuales.
WebUI
Instance: Seleccione Automatically Generate Virtual Links, luego haga clic
en OK.
CLI
set vrouter trust-vr protocol ospf auto-vlink
save
Ajuste de parámetros OSPF de interfaz

En esta sección se describen los parámetros OSPF que se pueden configurar en el
nivel de interfaz. Cuando se configura un parámetro OSPF en el nivel de interfaz,
los datos de configuración afectan únicamente al funcionamiento OSPF de la
interfaz especificada. Puede modificar los ajustes de los parámetros de la interfaz
mediante comandos de interfaz en la CLI o utilizando la WebUI.
64 Ajuste de parámetros OSPF de interfaz

La Tabla 9 detalla los parámetros opcionales de interfaz de OSPF y sus valores

predeterminados.
Tabla 9: Parámetros opcionales de interfaz de OSPF y sus valores predeterminados
Parámetro
OSPF de
interfaz Descripción Valor predeterminado
Authentication Especifica si la comunicación OSPF de la interfaz se No se utiliza
verificará mediante autenticación por contraseña de autenticación.
texto no encriptado o por MD5 (Message Digest 5).
La contraseña de texto no encriptado debe ser una
cadena de hasta 8 dígitos, mientras que la
contraseña para autenticación MD5 puede ser una
cadena de hasta 16 dígitos. Para la contraseña MD5
también es necesario que se configuren cadenas
clave.
Cost Especifica la métrica de la interfaz. El coste 1 para una conexión de
asociado a una interfaz depende del ancho de 100 MB o más
banda de la conexión que tenga establecida dicha 10 para una conexión de
interfaz. Cuanto mayor sea el ancho de banda, 10 MB
menor será el valor del coste (preferible). 100 para una conexión
de 1 MB
Dead interval Especifica el intervalo en segundos en que no se 40 segundos.
producirá respuesta desde un dispositivo OSPF
vecino antes de que OSPF determine que no
funciona.
Hello interval Especifica el intervalo en segundos que transcurrirá 10 segundos.
entre el envío de un paquete de saludo a la red y el
siguiente.
Link type Especifica una interfaz de túnel como vínculo punto Las interfaces Ethernet
a punto o como vínculo punto a multipunto. se tratan como interfaces
Consulte la “Interfaz de túnel punto a multipunto” de difusión.
en la página 71. De forma
predeterminada, las
interfaces de túnel
asociadas a las zonas
OSPF son punto a punto.
Neighbor list Especifica subredes, en forma de lista de acceso, en Ninguna (las adyacencias
las que residen vecinos OSPF que pueden utilizarse se forman con todos los
para formar adyacencias. vecinos de la interfaz).
Passive Especifica que la dirección IP de la interfaz se Las interfaces con OSPF
Interface notificará en el dominio OSPF como ruta OSPF y no habilitado transmiten
como ruta externa, pero que la interfaz no y reciben paquetes OSPF.
transmitirá ni recibirá paquetes OSPF. Esta opción
resulta útil cuando en la interfaz también se ha
habilitado BGP.
Priority Especifica la prioridad del enrutador virtual que se 1.
elegirá: enrutador designado o enrutador designado
de respaldo. El enrutador con el valor de prioridad
más alto tiene más posibilidades de ser elegido
(aunque no se garantiza).
Retransmit Especifica el tiempo en segundos que transcurrirá 5 segundos.
interval antes de que la interfaz reenvíe una LSA a un vecino
que no respondió a la primera LSA.
Ajuste de parámetros OSPF de interfaz 65

Parámetro
OSPF de
interfaz Descripción Valor predeterminado
Transit delay Especifica el tiempo en segundos entre las 1 segundo.
transmisiones de paquetes de actualización de
estado de conexión enviados a la interfaz.
Demand circuit (Sólo interfaces de túnel) Configura una interfaz de Desactivado.
túnel como circuito de demanda, según RFC 1793.
Consulte “Creación de un circuito de demanda
OSPF en una interfaz de túnel” en la página 71.
Reduce flooding Especifica la reducción de inundaciones LSA en un Desactivado.
circuito de demanda.
Ignore MTU Especifica que se pase por alto cualquier Desactivado.
incoherencia en los valores de la unidad de
transmisión máxima (MTU) entre las interfaces
locales y remotas que se encuentre durante las
negociaciones de la base de datos OSPF será
ignorada. Esta opción sólo debe utilizarse cuando la
MTU de la interfaz local sea más lenta que la MTU
de la interfaz remota.
NOTA: Para formar adyacencias, todos los enrutadores OSPF de un área deben utilizar los
mismos valores en el intervalo de saludo, el intervalo muerto y el intervalo de
retransmisión.
En el siguiente ejemplo, configuramos los siguientes parámetros OSPF para la

interfaz ethernet1:
Aumentar el intervalo entre los mensajes de saludo en OSPF a 15 segundos.
Aumentar el intervalo entre las retransmisiones OSPF a 7 segundos.
Aumentar el intervalo entre las transmisiones de LSA a 2 segundos.
WebUI
Network > Interfaces > Edit (para ethernet1) > OSPF: Introduzca los
Hello Interval: 15
Retransmit Interval: 7
Transit Delay: 2
CLI
set interface ethernet1 protocol ospf hello-interval 15
set interface ethernet1 protocol ospf retransmit-interval 7
set interface ethernet1 protocol ospf transit-delay 2
save
66 Ajuste de parámetros OSPF de interfaz

Configuración de seguridad
En esta sección se describen posibles problemas de seguridad en el dominio de
enrutamiento OSPF y métodos de prevención de ataques.
NOTA: Para que OSPF sea más seguro, todos los enrutadores de un dominio OSPF deben
configurarse con el mismo nivel de seguridad. De lo contrario, un solo enrutador
OSPF peligroso podría llegar a dejar fuera de línea todo el domino de
enrutamiento OSPF.
Autenticación de vecinos
Un enrutador OSPF se puede suplantar fácilmente, ya que las LSA no se encriptan
y la mayoría de los analizadores de protocolo permiten desencapsular paquetes
OSPF. La mejor forma de acabar con el riesgo de este tipo de ataques será
autenticando los vecinos OSPF.
OSPF ofrece dos formas de validar los paquetes OSPF recibidos de los vecinos: por
autenticación de contraseña simple y por autenticación MD5. Todos los paquetes
OSPF recibidos en la interfaz que no se autentiquen se descartarán. De forma
predeterminada, ninguna interfaz OSPF tiene la autenticación habilitada.
Para la autenticación MD5 se necesita la misma clave utilizada para los enrutadores
OSPF de envío y recepción. Puede especificar más de una clave MD5 en el
dispositivo de seguridad, cada una de las cuales tendrá su propia clave. Si configura
varias claves MD5 en el dispositivo de seguridad, podrá seleccionar un identificador
para la clave que se utilizará para autenticar las comunicaciones con el enrutador
vecino. De esta forma es posible cambiar periódicamente las claves MD5 por
parejas de enrutadores minimizando el riesgo de que algún paquete se descarte.
Configuración de una contraseña de texto no cifrado

En este ejemplo, crearemos la contraseña de texto no encriptado 12345678 para
OSPF en la interfaz ethernet1.
WebUI
Password: (seleccione), 12345678
CLI
set interface ethernet1 protocol ospf authentication password 12345678
save
Configuración de una contraseña MD5

En el siguiente ejemplo, creará dos claves MD5 distintas para la interfaz ethernet1
y seleccionará una de ellas para que sea la clave activa. Cada clave MD5 puede
tener 16 caracteres. El número identificador de clave debe estar entre 0 y 255. El
identificador de clave predeterminado es 0, de manera que no es necesario
especificar el identificador de clave para la primera clave MD5 que introduzca.
Configuración de seguridad 67
WebUI
Authentication:
MD5 Keys: (seleccione)
1234567890123456
9876543210987654
Key ID: 1
Preferred: (seleccione)
CLI
set interface ethernet1 protocol ospf authentication md5 1234567890123456
set interface ethernet1 protocol ospf authentication md5 9876543210987654
key-id 1
set interface ethernet1 protocol ospf authentication md5 active-md5-key-id 1
save
Configuración de una lista de vecinos de OSPF

Los entornos de acceso múltiple permiten que los dispositivos, incluyendo los
enrutadores, se puedan conectar a una red de forma relativamente sencilla. Esto
puede provocar problemas de estabilidad o rendimiento si el dispositivo conectado
no es fiable.
De forma predeterminada, la instancia de enrutamiento OSPF en el enrutador

virtual (VR) ScreenOS forma adyacencias con todos los vecinos OSPF que se
comunican en una interfaz con OSPF. Es posible limitar los dispositivos de una
interfaz que pueden formar adyacencias con la instancia de enrutamiento OSPF
definiendo una lista de subredes que contengan vecinos OSPF que se puedan elegir.
Sólo los hosts o enrutadores que se encuentren en la subredes definidas podrán
formar adyacencias con la instancia de enrutamiento OSPF. Para especificar las
subredes que contienen vecinos OSPF válidos, se debe definir una lista de acceso
a las subredes en el nivel del enrutador virtual (VR).
En este ejemplo configuraremos una lista de acceso que permitirá la comunicación

con los hosts de la subred 10.10.10.130/27. A continuación especificaremos la lista
de acceso para que configure vecinos OSPF válidos.
WebUI
Network > Routing > Virtual Router (trust-vr) > Access List > New:
Access List ID: 4

Sequence No.: 10
IP/Netmask: 10.10.10.130/27
Neighbor List: 4
68 Configuración de seguridad
CLI
set vrouter trust-vr access-list 4
set interface ethernet1 protocol ospf neighbor-list 4
save
Rechazo de rutas predeterminadas

En los ataques con desvío de rutas, un enrutador inyecta una ruta predeterminada
(0.0.0.0/0) en el dominio de enrutamiento para que los paquetes se desvíen a él. El
enrutador puede descartar los paquetes, causando una interrupción en el servicio,
o puede entregar información crítica a los paquetes antes de reenviarlos. En los
dispositivos de seguridad de Juniper Networks, OSPF acepta en principio cualquier
ruta predeterminada reconocida en OSPF y agrega la ruta predeterminada a la tabla
de rutas.
En el siguiente ejemplo especificaremos que una ruta predeterminada no se

reconozca en OSPF.
WebUI
Instance: Seleccione la casilla de verificación Do Not Add Default-route
Learned in OSPF, luego haga clic en OK.
CLI
set vrouter trust-vr protocol ospf reject-default-route
save
Protección contra inundaciones

Un enrutador peligroso o que no funcione correctamente puede inundar a sus
vecinos con paquetes de saludo OSPF o con LSA. Cada enrutador capta la
información de las LSA enviadas por otros enrutadores en la red para recuperar la
información de rutas para la tabla de enrutamiento. La protección contra
inundaciones de LSA permite determinar el número de LSA que entrarán en el
enrutador virtual (VR). Si éste recibe demasiadas LSA, el enrutador fallará por una
inundación LSA. Los ataques por LSA se producen cuando un enrutador genera un
número excesivo de LSA en un periodo corto de tiempo, puesto que hace que los
demás enrutadores OSPF de la red se mantengan ocupados ejecutando el algoritmo
SPF.
En los enrutadores virtuales que utilizan ScreenOS, es posible configurar el número

máximo de paquetes de saludo por intervalo de saludo y el número máximo de LSA
que recibirá una interfaz OSPF durante un intervalo determinado. Los paquetes que
excedan el límite configurado se descartarán. De forma predeterminada, el límite
de paquetes de saludo OSPF es de 10 paquetes por intervalo de saludo (el intervalo
de saludo predeterminado para una interfaz OSPF es de 10 segundos). No hay
ningún límite de LSA predefinido; si no impone un límite de LSA, se aceptarán
todas.
Configuración de un umbral de saludo

En el siguiente ejemplo configuraremos un umbral de 20 paquetes por intervalo de
saludo. Este intervalo, que se puede configurar independientemente en cada
interfaz OSPF, no variará; seguirá ajustado a 10 segundos.
WebUI
Prevent Hello Packet Flooding Attack: On

Max Hello Packet: 20
CLI
set vrouter trust-vr protocol ospf hello-threshold 20
save
Configuración de un umbral de LSA

En este ejemplo estableceremos un límite OSPF de 10 paquetes LSA cada 20
segundos para evitar ataques por inundación de LSA.
WebUI
LSA Packet Threshold Time: 20

Maximum LSAs: 10
CLI
set vrouter trust-vr protocol ospf lsa-threshold 20 10
save
Habilitación de la inundación reducida

Puede habilitar la característica de reducción de inundaciones para suprimir la
inundación LSA en las interfaces de punto a punto, como serie, de túnel o línea
asíncrona de abonado digital (ADSL), o interfaces de difusión, como las interfaces
de Ethernet. En el ejemplo siguiente, habilitará la supresión periódica de LSA sin
afectar al flujo de paquetes de saludo hacia la interfaz tunnel.1.
WebUI
datos, luego haga clic en Apply:
Reduce Flooding: (seleccione)
CLI
set interface tunnel.1 protocol ospf reduce-flooding
save
Creación de un circuito de demanda OSPF en una interfaz de túnel

Los circuitos de demanda de OSPF, según lo definido en la norma RFC 1793, son
segmentos de red en los que el tiempo de conexión o de utilización afecta al coste
de uso de dichas conexiones. En un circuito de demanda, el tráfico generado por
OSPF necesita limitarse a los cambios en la topología de la red. En los dispositivos
de seguridad de Juniper Networks, únicamente las interfaces de punto a punto,
como las interfaces serie, de túnel o de línea asíncrona de abonado digital (ADSL),
pueden ser circuitos de demanda, y para que funcionen adecuadamente, ambos
extremos del túnel se deben configurar manualmente como circuitos de demanda.
En interfaces de túnel configuradas como circuitos de demanda, el dispositivo de

seguridad suprime el envío de paquetes de saludo OSPF y la actualización periódica
de inundaciones LSA para disminuir la sobrecarga. Cuando el vecino OSPF alcanza
el estado completo “Full” (los saludos “Hello”coinciden y los LSA del enrutador y de
la red reflejan a todos los vecinos adyacentes), el dispositivo de seguridad suprime
los paquetes de saludo periódicos y el LSA se actualiza. El dispositivo de seguridad
inunda solamente LSA cuyo contenido haya cambiado.
En el ejemplo siguiente, configurará la interfaz tunnel.1 como un circuito de

demanda.
NOTA: Deberá configurar la interfaz de túnel del interlocutor remoto como un circuito de
demanda. Sin embargo, no necesita configurar la inundación LSA reducida en el
interlocutor remoto.
WebUI
Network > Interfaces > Edit > OSPF: Introduzca los siguientes datos, luego
haga clic en Apply:
Demand Circuit: (seleccione)
CLI
set interface tunnel.1 protocol ospf demand-circuit
save
Interfaz de túnel punto a multipunto

Al asociar una interfaz de túnel a una zona OSPF en un dispositivo de seguridad, de
forma predeterminada se crea un túnel OSPF punto a punto. La interfaz de túnel
punto a punto puede formar una adyacencia con solamente un enrutador OSPF en
el extremo remoto. Si la interfaz de túnel local va a ser asociada a múltiples túneles,
debe configurar la interfaz de túnel local como interfaz punto a multipunto e
inhabilitar la característica route-deny en la interfaz de túnel.
Creación de un circuito de demanda OSPF en una interfaz de túnel 71

NOTA: Debe configurar una interfaz de túnel como interfaz punto a multipunto antes de
habilitar OSPF en la interfaz. Una vez configurada la interfaz como interfaz punto
a multipunto, ya no podrá configurarla como circuito de demanda (consulte
“Creación de un circuito de demanda OSPF en una interfaz de túnel” en la
página 71). No obstante, puede configurar la interfaz para la inundación LSA
reducida.
Para ver un ejemplo de asociación de túneles múltiples a una interfaz de túnel,

consulte “Asociación de entradas automáticas en la tabla de rutas y en la tabla
NHTB” en la página 5-288. Las siguientes secciones incluyen ejemplos para:
Configurar el tipo de conexión (consulte “Establecer el tipo de conexión OSPF”

en la página 72)
Establecer la función de rechazo de ruta (consulte “Inhabilitación de la

restricción Route-Deny” en la página 72)
Configurar una red con una interfaz de túnel de punto a multipunto (consulte
“Creación de una red punto a multipunto” en la página 73)
Establecer el tipo de conexión OSPF

Si se propone formar adyacencias OSPF en múltiples túneles, necesitará establecer
el tipo de conexión como punto a multipunto (p2mp).
En el siguiente ejemplo establecerá el tipo de conexión de tunnel.1 en punto

a multipunto (p2mp) para cumplir con los requisitos de su red.
WebUI
Network > Interface > Edit > OSPF: Seleccione Point-to-Multipoint de la lista
de botones de opción “Link Type”.
CLI
save
Inhabilitación de la restricción Route-Deny

De forma predeterminada, el dispositivo de seguridad puede enviar y recibir
paquetes a través de la misma interfaz a menos que esté configurado
explícitamente para no enviarlos y recibirlos en la misma interfaz. En un entorno
punto a multipunto, este comportamiento puede ser deseable. Para configurar el
dispositivo de seguridad para enviar y recibir en la misma interfaz, debe inhabilitar
la restricción route-deny. En este ejemplo inhabilitará la restricción route-deny
mediante CLI en la interfaz de túnel punto a multipunto tunnel.1.
WebUI
NOTA: Para establecer la restricción route-deny debe utilizarse la CLI.
72 Interfaz de túnel punto a multipunto

CLI
unset interface tunnel.1 route-deny
save
Creación de una red punto a multipunto

La Figura 12 muestra una empresa de tamaño mediano con su oficina central (OC)
en San Francisco y delegaciones en Chicago, Los Angeles, Montreal y Nueva York.
Cada oficina tiene un solo dispositivo de seguridad.
Los siguientes son los requisitos de configuración específicos del dispositivo de

seguridad en la OC:
1. Configurar el VR para que ejecute una instancia de OSPF, habilitar OSPF y,

a continuación, configurar la interfaz tunnel.1.
2. Configurar las cuatro VPN y asociarlas a la interfaz tunnel.1.
Los siguientes son los requisitos de configuración propios de los dispositivos de

seguridad remotos:
1. Configurar el VR para que ejecute una instancia de OSPF, habilitar OSPF y,

2. Configurar la VPN y asociarla a la interfaz tunnel.1.
Los valores de temporizadores para todos los dispositivos deben coincidir para que
las adyacencias puedan formarse. La Figura 12 muestra el escenario descrito de la
red.
Interfaz de túnel punto a multipunto 73

Figura 12: Ejemplo de red punto a multipunto

Los Angeles Montreal
tunnel.1 10.0.0.3 tunnel.1 10.0.0.4

untrust 3.3.3.3 untrust 4.4.4.4
Nueva York Chicago
tunnel.1 10.0.0.2 tunnel.1 10.0.0.5

Untrust 2.2.2.2 Untrust 5.5.5.5
VPN 2 VPN 3
Internet
VPN 1 VPN 4
San Francisco (OC) ethernet3

1.1.1.1
tunnel.1 10.0.0.1
4 VPN asociadas a tunnel.1
En la Figura 12, se originan cuatro VPN en el dispositivo de seguridad de San

Francisco e irradian hacia las oficinas remotas en Nueva York, Los Angeles,
Montreal y Chicago.
En este ejemplo, configurará los siguientes ajustes en el dispositivo de seguridad de

la oficina central OC:
1. Interfaces y zona de seguridad
2. VPN
3. Rutas y OSPF
Para completar la configuración de la red, configurará los siguientes ajustes en cada

uno de los cuatro dispositivos de seguridad de las oficinas remotas:
1. Interfaz y OSPF
2. VPN
3. Directiva

NOTA: Los procedimientos de WebUI aparecen abreviados debido a que el ejemplo es

muy largo. La porción CLI del ejemplo está completa. Puede consultar en la
porción CLI los ajustes y valores exactos que deben utilizarse.
WebUI (dispositivo de la oficina central)

Network > Interfaces > Haga clic en New Tunnel IF y continúe en la página
de configuración.
Network > Interfaces > Edit (para ethernet3) y configure la zona y la dirección
IP.
Network > Interface > Edit (para tunnel.1) > OSPF: Seleccione
Point-to-Multipoint de la lista de botones de opción “Link Type”.
2. VPN
VPNs > AutoKey Advanced > Gateway
3. Rutas y OSPF
Network > Routing > Virtual Routers > Haga clic en Edit para el enrutador
virtual y configure los parámetros de OSPF.
CLI (dispositivo de la oficina central)

2. VPN
ospfp2mp proposal pre-g2-3des-sha
set vpn vpn1 gateway gw1 no-replay tunnel idletime 0 proposal g2-esp-3des-sha
set vpn1 id 1 bind interface tunnel.1

3. Rutas y OSPF
set vrouter trust router-id 10
set vrouter trust protocol ospf
set vrouter trust protocol ospf enable
set interface tunnel.1 protocol ospf area 0
unset interface tunnel.1 route-deny
save
NOTA: De forma predeterminada, route-deny está inhabilitado. Sin embargo, si habilitó la

característica route-deny en algún momento, necesitará inhabilitar la
característica para que la interfaz de túnel punto a multipunto funcione
correctamente.
Puede seguir estos pasos para configurar el dispositivo de seguridad de la oficina

remota. Los dispositivos de seguridad de Juniper Networks aprenden sobre sus
vecinos a través de LSA.
Para completar la configuración mostrada en la Figura 12 en la página 74, debe

repetir la sección siguiente por cada dispositivo remoto y cambiar las direcciones IP,
los nombres de puerta de enlace y los nombres de VPN, así como establecer
directivas para cumplir las necesidades de la red. En cada sitio remoto, las zonas
trust y untrust cambian.

WebUI (dispositivo de oficina remota)

1. Interfaz y OSPF
Network > Interfaces > Haga clic en New Tunnel IF y continúe con la página
de configuración.
2. VPN
3. Directiva
Directivas (de todas las zonas a todas las zonas) > Haga clic en New
CLI (dispositivo de oficina remota)

1. Interfaz y OSPF
set vrouter trust protocol ospf
set vrouter trust protocol ospf enable
set interface untrust ip 2.2.2.2/24
set interface tunnel.1 protocol ospf area 0

2. VPN
set ike gateway gw1 address 1.1.1.1/24 main outgoing-interface untrust preshare
set vpn vpn1 id 1 bind interface tunnel.1
3. Directiva (configure como sea necesario)
set policy id 1 from trust to untrust any any any permit
set policy id 2 from untrust to trust any any any permit
save
Puede ver los nuevos cambios ejecutando el comando get vrouter enrut_virtual
protocol ospf config.


Capítulo 4
Protocolo de información de
enrutamiento
En este capítulo se describe la versión 2 del protocolo de información de

enrutamiento (RIP) en los dispositivos de seguridad de Juniper Networks. Incluye
las siguientes secciones:
“Configuración básica de RIP” en la página 81
“Creación y eliminación de una instancia RIP” en la página 82
“Habilitación y deshabilitación de RIP en interfaces” en la página 83
“Visualización de la información de RIP” en la página 85
“Visualización de la base de datos RIP” en la página 85
“Visualización de los detalles de RIP” en la página 86
“Visualización de información de vecino RIP” en la página 87
“Visualización de detalles de RIP para una interfaz específica” en la

página 88
“Parámetros globales de RIP” en la página 89
“Notificación de la ruta predeterminada” en la página 90
“Configuración de los parámetros de interfaz de RIP” en la página 90
“Autenticar vecinos al establecer una contraseña” en la página 92
“Configuración de vecinos fiables” en la página 93
“Protección contra inundaciones” en la página 94
79
“Configuraciones opcionales de RIP” en la página 96
“Configuración de la versión de RIP” en la página 96
“Habilitación e inhabilitación de un resumen de prefijos” en la página 98
“Establecimiento de rutas alternas” en la página 99
“Circuitos de demanda en interfaces de túnel” en la página 101
“Configuración de un vecino estático” en la página 102
“Configuración de una interfaz de túnel punto a multipunto” en la página 102
Vista general
El protocolo de información de enrutamiento RIP (Routing information protocol) es
un protocolo de vector distancia que se utiliza como protocolo de puerta de enlace
interior (IGP) en sistemas autónomos (AS) de tamaño moderado. ScreenOS admite
la versión 2 de RIP (RIPv2) tal como se define en la norma RFC 2453. Mientras que
RIPv2 sólo admite la autenticación de contraseña simple (texto sin formato), la
implementación RIP de ScreenOS también admite extensiones de autenticación
MD5, tal como se definen en la norma RFC 2082.
NOTA: El protocolo RIP no se admite en interfaces de túnel sin numerar. Se deben

numerar todas las interfaces que utilizan protocolo RIP. Cualquier intento por
configurar y ejecutar una interfaz sin numerar utilizando RIP puede provocar un
fallo impredecible en el enrutamiento.
El protocolo RIP administra la información de rutas en redes pequeñas y

homogéneas, como las LAN corporativas. La ruta más larga admitida en una red RIP
es de 15 saltos. Un valor métrico de 16 indica un destino no válido o inaccesible
(este valor también se denomina “infinito” ya que excede el máximo de 15 saltos
permitidos para las redes RIP).
El protocolo RIP no está diseñado para grandes redes o para redes en las que las
rutas se eligen en función de parámetros en tiempo real, como carga, fiabilidad
o retardo medido. El protocolo RIP admite redes punto a punto (utilizadas con VPN)
y redes Ethernet de difusión/multidifusión (broadcast/multicast). El protocolo RIP
admite las conexiones de "punto a multipunto" a través de las interfaces de túnel
con o sin tener configurado un circuito de demanda. Para obtener más información
sobre circuitos de demanda, consulte “Circuitos de demanda en interfaces de túnel”
en la página 101.
El protocolo RIP envía mensajes que contienen la tabla de enrutamiento completa a

todos los enrutadores vecinos cada 30 segundos. Estos mensajes se envían
normalmente como multidifusiones (multicast) a la dirección 224.0.0.9 del puerto
RIP.
80 Vista general
Capítulo 4: Protocolo de información de enrutamiento
La base de datos de enrutamiento RIP contiene una entrada para cada destino que
sea accesible a través de la instancia de enrutamiento RIP. La base de datos de
enrutamiento RIP incluye la siguiente información:
Dirección IPv4 de un destino. Recuerde que RIP no distingue entre redes

y hosts.
Dirección IP del primer enrutador de la ruta hacia el destino (el siguiente salto).
Interfaz de red utilizada para acceder al primer enrutador.
Valor métrico que indica la distancia (o coste) para alcanzar el destino. La

mayoría de implementaciones RIP utilizan un valor métrico de 1 para cada red.
Un temporizador que indica el tiempo que ha transcurrido desde la última

actualización de la entrada de la base de datos.
Configuración básica de RIP

Creará RIP por cada enrutador virtual en un dispositivo de seguridad. Si dispone de
varios enrutadores virtuales (VR) dentro de un sistema, podrá habilitar múltiples
instancias de RIP, una instancia de la versión 1 o de la 2 por cada enrutador virtual.
De forma predeterminada, los dispositivos de seguridad de Juniper Networks
admiten la versión 2 de RIP.

seguridad, deberá asignar una ID de enrutador virtual, tal y como se describe en
“Enrutamiento” en la página 13.
En esta sección se describen los pasos básicos para configurar el protocolo RIP en
un dispositivo de seguridad:
1. Crear la instancia de enrutamiento RIP en un enrutador virtual.
2. Habilitar la instancia RIP.
3. Habilitar RIP en las interfaces que conectan con otros enrutadores RIP.
4. Redistribuir las rutas reconocidas de otros protocolos de enrutamiento (como

OSPF, BGP, o rutas configuradas de forma estática) en la instancia RIP.
En esta sección se describe la correcta ejecución de cada una de estas tareas

utilizando la interfaz WebUI y la línea de comandos CLI.
Configuración básica de RIP 81

Opcionalmente, es posible configurar parámetros de RIP, como:
Parámetros globales, como temporizadores y vecinos RIP fiables, que se

configuran en el VR para el protocolo RIP (consulte “Parámetros globales de
RIP” en la página 89)
Parámetros de interfaz, como la autenticación de dispositivos vecinos, que se

configuran en la interfaz para el protocolo RIP (consulte “Configuración de los
parámetros de interfaz de RIP” en la página 90)
Parámetros RIP relacionados con la seguridad, que se configuran en el

enrutador virtual o en la interfaz (consulte “Configuración de seguridad” en la
página 92)
Creación y eliminación de una instancia RIP

Cada instancia de enrutamiento de RIP se crea y se habilita en un enrutador virtual
(VR) específico ubicado en un dispositivo de seguridad. Cuando se crea y se habilita
una instancia de enrutamiento de RIP en un enrutador virtual, RIP transmite
y recibe paquetes en todas las interfaces habilitadas para RIP de dicho enrutador.
Cuando se elimina una instancia de enrutamiento de RIP en un enrutador virtual, se

eliminan las configuraciones RIP correspondientes para todas las interfaces de
dicho enrutador.
(Para obtener más información sobre VR y su configuración en dispositivos de

seguridad, consulte “Enrutamiento” en la página 13.
Creación de una instancia RIP

Cree una instancia de enrutamiento RIP en el trust-vr y a continuación habilite el
RIP.
WebUI
Network > Routing > Virtual Router (trust-vr) > Edit: Escriba una Virtual
Router ID y luego seleccione Create RIP Instance.
Seleccione Enable RIP y haga clic en OK.
CLI
1. ID de enrutador
2. Instancia de enrutamiento de RIP
set vrouter trust-vr protocol rip
set vrouter trust-vr protocol rip enable
save
NOTA: En CLI, el proceso de crear una instancia de enrutamiento RIP se realiza en dos
etapas. Cree la instancia RIP y, a continuación, habilite RIP.
82 Configuración básica de RIP

Eliminación de una instancia RIP

En este ejemplo, inhabilitará la instancia de enrutamiento de RIP en trust-vr. RIP
dejará de transmitir y procesar paquetes en todas las interfaces habilitadas para RIP
en trust-vr.
WebUI
Network > Routing > Virtual Router (trust-vr) > Edit > Edit RIP Instance:
Anule la selección de Enable RIP y haga clic en OK.
Network > Routing > Virtual Router (trust-vr) > Edit > Delete RIP Instance
y luego haga clic en OK en el mensaje de confirmación.
CLI
unset vrouter trust-vr protocol rip enable
unset vrouter trust-vr protocol rip
save
Habilitación y deshabilitación de RIP en interfaces

De forma predeterminada, el protocolo RIP está inhabilitado en todas las interfaces
del enrutador virtual (VR) y es necesario habilitarlo de forma explícita en una
interfaz. Si se inhabilita RIP a nivel de interfaz, RIP no transmitirá ni recibirá
paquetes en la interfaz especificada. Los parámetros de configuración de interfaz se
conservan cuando se inhabilita RIP en una interfaz.
NOTA: Si se desactiva la instancia de enrutamiento de RIP en el enrutador virtual

(consulte “Eliminación de una instancia RIP” en la página 83), RIP dejará de
transmitir y procesar paquetes en todas las interfaces del enrutador que tengan
este protocolo habilitado.
Habilitar RIP en una interfaz

En este ejemplo, habilitará RIP en la interfaz Trust.
WebUI
Network > Interface > Edit (para Trust) > RIP: Seleccione Protocol RIP
Enable, luego haga clic en Apply.
CLI
set interface trust protocol rip enable
save
Inhabilitación de RIP en una interfaz

En este ejemplo, inhabilitará RIP en la interfaz Trust. Para eliminar completamente
la configuración de RIP introduzca el segundo comando CLI antes de guardar.
WebUI
Network > Interface (para Trust) > RIP: Elimine el Protocol RIP Enable, luego
haga clic en Apply.
Configuración básica de RIP 83

CLI
unset interface trust protocol rip enable
unset interface trust protocol rip
save
Redistribución de rutas
protocolos de enrutamiento. Por ejemplo, los siguientes tipos de rutas se pueden
redistribuir en la instancia de enrutamiento de RIP de un mismo enrutador virtual
(VR):
Rutas reconocidas por el protocolo BGP
Rutas reconocidas por el protocolo OSPF
Rutas importadas
Es necesario configurar un mapa de rutas para filtrar las rutas distribuidas. Para
obtener más información sobre la creación de mapas de rutas para la
redistribución, consulte “Enrutamiento” en la página 13.
Las rutas importadas en RIP a partir de otros protocolos tienen un valor métrico
predeterminado de 10. Este valor se puede modificar (consulte “Parámetros
globales de RIP” en la página 89).
En este ejemplo, redistribuirá rutas estáticas que se encuentran en la subred

20.1.0.0/16 entre dispositivos vecinos RIP ubicados en el enrutador virtual trust-vr.
Para ello, primero deberá crear una lista de acceso para permitir las direcciones en
la subred 20.1.0.0/16. A continuación, configure un mapa de rutas que permita las
direcciones incluidas en la lista de acceso que acaba de generar. Utilice el mapa de
rutas para especificar la redistribución de rutas estáticas en la instancia de
enrutamiento de RIP.
WebUI
Access List ID: 20

Sequence No.: 1
IP/Netmask: 20.1.0.0/16
Network > Routing > Virtual Router (trust-vr) > Route Map > New:
Map Name: rtmap1

Sequence No.: 1
Match Properties:
Access List: (seleccione), 20 (seleccione)
84 Configuración básica de RIP

Network > Routing > Virtual Router (trust-vr) > Edit > Edit RIP Instance >
Redistributable Rules: Introduzca los siguientes datos y haga clic en Add:
Route Map: rtmap1 (seleccione)

Protocol: Static (seleccione)
CLI
set vrouter trust-vr route-map name rtmap1 permit 1
set vrouter trust-vr route-map rtmap1 1 match ip 20
set vrouter trust-vr protocol rip redistribute route-map rtmap1 protocol static
save
Visualización de la información de RIP

Después de modificar los parámetros RIP, puede visualizar los siguientes tipos de
detalles de RIP:
Base de datos, que muestra la información de enrutamiento
Protocolo, que proporciona los detalles de interfaz y de RIP de un enrutador

virtual (VR)
Vecinos
Visualización de la base de datos RIP

Puede verificar la información de enrutamiento de RIP desde la CLI. Puede elegir
visualizar una lista completa de todas las entradas de la base de datos RIP o de una
sola entrada.
En este ejemplo, visualiza la información detallada desde la base de datos RIP.

Puede visualizar todas las entradas de la base de datos o limitar el resultado a una
sola entrada de la base de datos añadiendo la dirección IP y la máscara del VR que
desee.
En este ejemplo, especifica trust-vr y añade el prefijo y la dirección IP 10.10.10.0/24

para visualizar una sola entrada de la tabla.
WebUI
NOTA: Debe utilizar la CLI para visualizar la base de datos RIP.
CLI
get vrouter trust-vr protocol rip database prefix 10.10.10.0/24
save
Visualización de la información de RIP 85

Después de introducir el siguiente comando CLI, puede visualizar la entrada de la

base de datos RIP:
device-> get vrouter trust-vr protocol rip database 10.10.10.0/24

VR: trust-vr
-------------------------------------------------------------------------
Total database entry: 3
Flags : Added in Multipath - M, RIP - R, Redistributed - I,
Default (advertised) - D, Permanent - P, Summary - S,
Unreachable - U, Hold - H
DBID Prefix Nexthop Ifp Cost Flags Source
7 10.10.10.0/24 20.20.20.1 eth1 2 MR 20.20.20.1
-------------------------------------------------------------------------
La base de datos RIP contiene los campos siguientes:
DBID, el identificador de base de datos de la entrada
Prefix, el prefijo y la dirección IP
Nexthop, la dirección del salto siguiente (enrutador)
Ifp, el tipo de conexión (Ethernet o túnel)
La métrica de coste asignada para indicar la distancia desde el origen
Los indicadores (flags) pueden ser uno o varios de los siguientes: multidireccional
(M), RIP (R), redistribuido (I), notificado de forma predeterminada (D), permanente
(P), resumen (S), inaccesible (U) o retención (H).
En este ejemplo, el identificador de base de datos es 7, la dirección IP y el prefijo es

10.10.10.0/24 y el salto siguiente es 20.20.20.1. Es una conexión Ethernet con un
coste de 2. Los indicadores son M y R e indican que esta ruta es multidireccional y
usa RIP.
Visualización de los detalles de RIP

Puede visualizar los detalles de RIP para verificar que la configuración de RIP
coincida con sus necesidades de red. Puede limitar el resultado solamente a la tabla
de resumen de la interfaz añadiendo interface al comando CLI.
Puede visualizar la información de RIP completa para comprobar una configuración

o verificar que los cambios guardados estén activos.
WebUI
NOTA: Debe utilizar la CLI para visualizar los detalles de RIP.
CLI
get vrouter trust-vr protocol rip
86 Visualización de la información de RIP

Este comando produce resultados similares al siguiente resultado:

device-> get vrouter trust-vr protocol rip
VR: trust-vr
----------------------------------------------------------------------------
State: enabled
Version: 2
Default metric for routes redistributed into RIP: 10
Maximum neighbors per interface: 16
Not validating neighbor in same subnet: disabled
RIP update transmission not scheduled
Maximum number of Alternate routes per prefix: 2
Advertising default route: disabled
Default routes learnt by RIP will not be accepted
Incoming routes filter and offset-metric: not configured
Outgoing routes filter and offset-metric: not configured
Update packet threshold is not configured
Total number of RIP interfaces created on vr(trust-vr): 1
Update| Invalid| Flush| DC Retransmit| DC Poll| Hold Down (Timers in seconds)
----------------------------------------------------------------------------
30| 180| 120| 5| 40|90
Flags : Split Horizon - S, Split Horizon with Poison Reverse - P, Passive - I
Demand Circuit - D
Interface IP-Prefix Admin State Flags NbrCnt Metric Ver-Rx/Tx
-----------------------------------------------------------------------------
tun.1 122.1.2.114/8 enabled disabled SD 1 1 v1v2/v1v
Puede visualizar los valores de RIP, los detalles del paquete, la información del
temporizador RIP y una tabla de interfaz resumida.
Visualización de información de vecino RIP

Puede visualizar los detalles sobre los vecinos RIP de un enrutador virtual (VR).
Puede recuperar una lista de información de todos los vecinos o una entrada de un
vecino específico añadiendo la dirección IP del vecino que desee. Puede comprobar
el estado de una ruta y verificar la conexión entre el vecino y el dispositivo de
seguridad desde estas estadísticas.
En el ejemplo siguiente, visualice la información de vecino RIP para el trust-vr.
WebUI
NOTA: Debe utilizar la CLI para visualizar la información de vecino RIP.
CLI
get vrouter trust-vr protocol rip neighbors
device-> get vrouter trust-vr protocol rip neighbors

VR: trust-vr
--------------------------------------------------------------------------------
Flags : Static - S, Demand Circuit - T, NHTB - N, Down - D, Up - U, Poll - P,
Demand Circuit Init - I
Neighbors on interface tunnel.1
--------------------------------------------------------------------------------
IpAddress Version Age Expires BadPackets BadRoutes Flags
--------------------------------------------------------------------------------
10.10.10.1 v2 - - 0 0 TSD
Visualización de la información de RIP 87

Además de visualizar la dirección IP y la versión de RIP, puede visualizar la

información siguiente del vecino RIP:
Antigüedad de la entrada
Tiempo de vencimiento
Número de paquetes incorrectos
Número de rutas incorrectas
Indicadores: estática (S), circuito de demanda (T), NHTB (N), fuera de línea (D),
en línea (U), sondeo (P) o inicio de circuito de demanda (I)
Visualización de detalles de RIP para una interfaz específica

Puede visualizar toda la información pertinente de RIP de todas las interfaces y un
resumen de los detalles del enrutador vecino. Opcionalmente, puede añadir la
dirección IP de un vecino específico para limitar el resultado.
En el ejemplo siguiente, puede visualizar la información sobre la interfaz tunnel.1

del vecino que reside en la dirección IP 10.10.10.2.
WebUI
NOTA: Debe utilizar la CLI para visualizar los detalles de la interfaz RIP.
CLI
get interface tunnel.1 protocol rip neighbor 10.10.10.2
device-> get interface tunnel.1 protocol rip

VR: trust-vr
----------------------------------------------------------------------------
Interface: tunnel.1, IP: 10.10.10.2/8, RIP: enabled, Router: enabled
Receive version v1v2, Send Version v1v2
State: Down, Passive: No
Metric: 1, Split Horizon: enabled, Poison Reverse: disabled
Demand Circuit: configured
Authentication: none
Current neighbor count: 1
Update not scheduled
Transmit Updates: 0 (0 triggered), Receive Updates: 0
Update packets dropped because flooding: 0
Bad packets: 0, Bad routes: 0
Flags : Static - S, Demand Circuit - T, NHTB - N, Down - D, Up - U, Poll - P
Neighbors on interface tunnel.1
----------------------------------------------------------------------------
IpAddress Version Age Expires BadPackets BadRoutes Flags
----------------------------------------------------------------------------
10.10.10.1 - - - 0 0 TSD
f
88 Visualización de la información de RIP

Desde este resumen de información puede visualizar el número de paquetes

incorrectos o de rutas incorrectas presentes, verificar qué gasto de procesamiento
añade RIP a la conexión y ver la configuración de la autenticación.
Parámetros globales de RIP

En esta sección se describen los parámetros globales de RIP que se pueden
configurar en un enrutador virtual (VR). Cuando se configura un parámetro RIP
a nivel de enrutador virtual, los datos de configuración afectarán a las operaciones
de todas las interfaces que tengan habilitado el protocolo RIP. Es posible modificar
los valores de los parámetros globales del protocolo de enrutamiento RIP por medio
de las interfaces CLI y WebUI.
La Tabla 10 detalla los parámetros globales de RIP y sus valores predeterminados.
Tabla 10: Parámetros globales de RIP y sus valores predeterminados
Parámetro global de Valores

RIP Descripción predeterminados
Default metric Valor métrico predeterminado para rutas importadas en RIP a partir de otros 10
protocolos, como OSPF y BGP.
Update timer Indica (en segundos) cuándo enviar actualizaciones de rutas RIP a los 30 segundos
dispositivos vecinos.
Maximum packets per Indica el número máximo de paquetes recibidos por actualización. Sin máximo
update
Invalid timer Indica el tiempo (en segundos) que tiene que transcurrir para que una ruta deje 180 segundos
de ser válida desde el momento en el que un vecino deja de notificar la ruta.
Flush timer Indica el tiempo (en segundos) que tiene que transcurrir para que se elimine 120 segundos
una ruta desde el momento de su invalidación.
Maximum neighbors Indica el número máximo de vecinos RIP permitidos. Depende de la
plataforma
Trusted neighbors Indica una lista de acceso en la que se definen los vecinos RIP. Si no se Todos los vecinos
especifica ningún vecino, RIP utiliza la difusión o la multidifusión para detectar son fiables
vecinos en una interfaz. Consulte “Configuración de vecinos fiables” en la
página 93.
Allow neighbors on Indica que se admiten vecinos RIP de otras subredes. Desactivado
different subnet
Advertise default route Indica si se notifica la ruta predeterminada (0.0.0.0/0). Desactivado
Reject default routes Indica si RIP debe rechazar una ruta predeterminada reconocida de otro Desactivado
protocolo. Consulte “Rechazo de rutas predeterminadas” en la página 94.
Incoming route map Indica el filtro para las rutas que debe reconocer RIP. Ninguno
Outgoing route map Indica el filtro para las rutas que debe notificar RIP. Ninguno
Maximum alternate Especifica el número máximo de rutas RIP para el mismo prefijo que se puede 0
routes añadir a la base de datos de la ruta RIP. Consulte “Establecimiento de rutas
alternas” en la página 99.
Summarize advertised Especifica la notificación de una ruta de resumen que corresponde a todas las Ninguno
routes rutas incluidas dentro de un rango de resumen. Consulte “Habilitación e
inhabilitación de un resumen de prefijos” en la página 98.
RIP protocol version Especifica la versión de RIP que utiliza el VR. Puede ignorar la versión interfaz Versión 2
a interfaz. Consulte “Configuración de la versión de RIP” en la página 96.
Parámetros globales de RIP 89

Parámetro global de Valores

RIP Descripción predeterminados
Hold-timer Evita el ‘flapping’ (rechazo) de una ruta a la tabla de rutas. Puede especificar un 90 segundos
valor entre los valores mínimo (tres veces el valor del temporizador de
actualización (update)) y máximo (suma del temporizador de actualización
(update) y el de retención (hold), sin exceder el valor del temporizador flush).
Retransmit timer Especifica el intervalo de retransmisión de las respuestas desencadenadas en 5 segundos
un circuito de demanda. Puede establecer el temporizador de retransmisión 10 reintentos
y asignar una cuenta de reintentos que se ajuste a sus necesidades de red.
Poll-timer Comprueba el vecino remoto del circuito de demanda para ver si está en línea. 180 segundos
Puede configurar el temporizador de sondeo en minutos y asignar una cuenta 0 reintentos
de reintentos que se ajuste a sus necesidades de red. Una cuenta de reintentos
de cero (0) supone un sondeo interminable.
Notificación de la ruta predeterminada

Puede cambiar la configuración de RIP incluyendo la notificación de la ruta
predeterminada (una ruta que no es RIP) y modificando la métrica asociada con la
ruta predeterminada presente en una tabla de enrutamiento de VP determinada.
De forma predeterminada, la ruta predeterminada (0.0.0.0/0) no se notifica a los

vecinos RIP. El siguiente comando notifica la ruta predeterminada a los vecinos RIP
en el enrutador virtual trust-vr con un valor métrico de 5 (hay que introducir un
valor métrico). La ruta predeterminada debe existir en la tabla de enrutamiento.
WebUI
Advertising Default Route: (seleccione)

Metric: 5
CLI
set vrouter trust-vr protocol rip advertise-def-route metric number 5
save
NOTA: Consulte el Manual ScreenOS CLI Reference Guide: IPv4 Command Descriptions para
obtener más información sobre los parámetros globales que puede configurar en
el contexto del protocolo de enrutamiento de RIP.
Configuración de los parámetros de interfaz de RIP

En esta sección se describen los parámetros RIP que se pueden configurar en el
nivel de interfaz. Cuando se configura un parámetro RIP en el nivel de interfaz, los
datos de configuración afectan únicamente al funcionamiento RIP de la interfaz
especificada. Puede modificar los ajustes de los parámetros de la interfaz mediante
comandos de interfaz en la CLI o utilizando la WebUI.
90 Notificación de la ruta predeterminada

La Tabla 11 detalla los parámetros de interfaz de RIP y sus valores predeterminados.
Tabla 11: Parámetros de interfaz de RIP y sus valores predeterminados
Parámetro RIP de interfaz Descripción Valor predeterminado

Split-horizon Indica si está habilitada la opción de horizonte La opción de horizonte dividido
dividido (no notificar rutas reconocidas de una está habilitada. Las rutas
interfaz en actualizaciones enviadas a dicha interfaz, inalcanzables están
"split horizon"). Si está habilitada la opción de inhabilitadas.
horizonte dividido con rutas inalcanzables (poison
reverse), las rutas reconocidas de una interfaz se
notifican con un valor métrico de 16 en las
actualizaciones enviadas a dicha interfaz.
RIP metric Especifica la métrica RIP de la interfaz. 1.
Authentication Especifica la autenticación por contraseña de texto no No se utiliza autenticación.
encriptado o la autenticación MD5. Consulte
“Autenticar vecinos al establecer una contraseña” en
la página 92.
Passive mode Indica que la interfaz puede recibir, pero no transmitir No.
paquetes RIP.
Incoming route map Indica el filtro para las rutas que debe reconocer RIP. Ninguna.
Outgoing route map Indica el filtro para las rutas que debe notificar RIP. Ninguna.
RIP version for sending or receiving Especifica la versión de protocolo RIP utilizada para Versión configurada para el
updates enviar o recibir actualizaciones en la interfaz. La enrutador virtual.
versión de la interfaz utilizada para enviar
actualizaciones no necesita ser la misma que la
versión para recibir las actualizaciones. Consulte
“Configuración de la versión de RIP” en la página 96.
Route summarization Especifica si los resúmenes de rutas están habilitados Desactivado.
en la interfaz. Consulte “Habilitación e inhabilitación
de un resumen de prefijos” en la página 98.
Demand-circuit Especifica el circuito de demanda en una interfaz de Ninguna.
túnel especificada. El dispositivo de seguridad envía
mensajes de actualización solamente cuando se
producen cambios. Consulte “Circuitos de demanda
en interfaces de túnel” en la página 101.
Static neighbor IP Especifica la dirección IP de un vecino RIP asignado Ninguna.
manualmente.
Puede definir mapas de rutas de entrada y salida en el nivel del enrutador virtual
o en el nivel de la interfaz. Un mapa de rutas definido en el nivel de la interfaz tiene
preferencia sobre un mapa de rutas definido en el nivel del enrutador virtual. Por
ejemplo, si define un mapa de rutas de entrada en el nivel del enrutador virtual
y otro mapa de rutas de entrada en el nivel de la interfaz, éste último tendrá
preferencia sobre el primero. Para obtener más información, consulte
“Configuración de un mapa de rutas” en la página 39.
En el siguiente ejemplo, configuramos los siguientes parámetros RIP para la interfaz

trust:
Active la autenticación MD5 con la clave 1234567898765432 y la ID de

clave 215.
Habilite la opción de horizonte dividido con rutas inalcanzables para la interfaz.
Configuración de los parámetros de interfaz de RIP 91

WebUI
Network > Interfaces > Edit (para Trust) > RIP: Introduzca los siguientes
Authentication: MD5 (seleccione)

Key: 1234567898765432
Key ID: 215
Split Horizon: Enabled with poison reverse (seleccione)
CLI
set interface trust protocol rip authentication md5 1234567898765432 key-id
215
set interface trust protocol rip split-horizon poison-reverse
save
enrutamiento RIP y métodos de prevención de ataques.
NOTA: Para que RIP sea más seguro, todos los enrutadores de un dominio RIP deben
RIP comprometido podría llegar a dejar inservible todo el domino de
enrutamiento RIP.
Autenticar vecinos al establecer una contraseña

Un enrutador RIP se puede suplantar fácilmente, ya que los paquetes RIP no se
encriptan, y la mayoría de los analizadores de protocolo permiten desencapsular
paquetes RIP. La mejor forma de acabar con el riesgo de este tipo de ataques será
autenticando los vecinos RIP.
RIP ofrece dos formas de validar los paquetes RIP recibidos de los vecinos: por
autenticación de contraseña simple y por autenticación MD5. Todos los paquetes
RIP recibidos en la interfaz que no se autentiquen se descartarán. De forma
predeterminada, ninguna interfaz RIP tiene la autenticación habilitada.
Para la autenticación MD5 es necesario utilizar la misma clave para los enrutadores
RIP de envío y recepción. Puede especificar más de una clave MD5 en el dispositivo
de seguridad, cada una de las cuales tendrá su propia clave. Si configura varias
claves MD5 en el dispositivo de seguridad, podrá seleccionar un identificador para
la clave que se utilizará para autenticar las comunicaciones con el enrutador vecino.
De esta forma es posible cambiar periódicamente las claves MD5 por parejas de
enrutadores minimizando el riesgo de que algún paquete se descarte.
En el siguiente ejemplo, creará dos claves MD5 distintas para la interfaz ethernet1
y seleccionará una de ellas para que sea la clave activa. El identificador de clave
predeterminado es 0, de forma que no tendrá que especificar el identificador para
la primera clave MD5 que introduzca.
WebUI
Network > Interfaces > Edit (para ethernet1) > RIP: Introduzca los siguientes
MD5 Keys: (seleccione)

1234567890123456 (primer campo de clave)
9876543210987654 (segundo campo de clave)
Key ID: 1
Preferred: (seleccione)
CLI
set interface ethernet1 protocol rip authentication md5 1234567890123456
set interface ethernet1 protocol rip authentication md5 9876543210987654
key-id 1
set interface ethernet1 protocol rip authentication md5 active-md5-key-id 1
save
Configuración de vecinos fiables

Los entornos de acceso múltiple permiten que los dispositivos, incluyendo los
enrutadores, se puedan conectar a una red de forma relativamente sencilla. Esto
puede provocar problemas de estabilidad o rendimiento si los dispositivos
conectados no son fiables. Con objeto de evitar este problema, puede utilizar una
lista de acceso para filtrar los dispositivos admitidos como vecinos RIP. De forma
predeterminada, sólo se admiten como vecinos RIP los dispositivos ubicados en la
misma subred que el enrutador virtual (VR).
En este ejemplo, configurará los siguientes parámetros globales para la instancia de

enrutamiento RIP que se está ejecutando en el trust-vr:
El número máximo de vecinos RIP es 1.
La dirección IP del vecino fiable, 10.1.1.1, figura en una lista de acceso.
WebUI
Access List ID: 10

Sequence No.: 1
IP/Netmask: 10.1.1.1/32
Trusted Neighbors: (seleccione), 10

Maximum Neighbors: 1
CLI
device(trust-vr)-> set access-list 10 permit ip 10.1.1.1/32 1
device(trust-vr)-> set protocol rip
device(trust-vr/rip)-> set max-neighbor-count 1
device(trust-vr/rip)-> set trusted-neighbors 10
device(trust-vr/rip)-> exit
save

o puede entregar información crítica a los paquetes antes de reenviarlos. En los
dispositivos de seguridad de Juniper Networks, RIP acepta en principio cualquier
ruta predeterminada reconocida en RIP y agrega la ruta predeterminada a la tabla
de rutas.
En el siguiente ejemplo, configurará la instancia de enrutamiento RIP que se está

ejecutando en el trust-vr para que rechace todas las rutas predeterminadas
reconocidas en RIP.
WebUI
Reject Default Route Learnt by RIP: (seleccione)
CLI
set vrouter trust-vr protocol rip reject-default-route
save
Protección contra inundaciones

Un enrutador que se encuentre comprometido o que no funcione correctamente
puede inundar a sus vecinos con paquetes de actualización de enrutamiento RIP. En
el enrutador virtual (VR), es posible configurar el número máximo de paquetes de
actualización que se pueden recibir en una interfaz RIP durante un intervalo de
actualización para impedir la inundación con paquetes de actualización. Todos los
paquetes de actualización que excedan el umbral de actualización configurado se
descartarán. Si no se establece ningún umbral de actualización, se aceptarán todos
los paquetes de actualización.
Es necesario actuar con cuidado al configurar un umbral de actualización cuando

los vecinos tienen tablas de enrutamiento de grandes dimensiones, ya que el
número de actualizaciones de enrutamiento puede ser bastante elevado durante un
intervalo determinado debido a las actualizaciones flash. Los paquetes de
actualización que excedan el umbral se descartan, y es posible que no se
reconozcan rutas válidas.
Configuración de un umbral de actualización

En este ejemplo, ajustará a 4 el número máximo de paquetes de actualización de
enrutamiento que RIP puede recibir en una interfaz.
WebUI
Maximum Number Packets per Update Time: (seleccione), 4
CLI
set vrouter trust-vr protocol rip threshold-update 4
save
Habilitación de RIP en interfaces de túnel

En el siguiente ejemplo se crea y habilita una instancia de enrutamiento RIP en el
trust-vr del Dispositivo-A. RIP se habilita en la interfaz de túnel VPN y en la interfaz
de zona Trust. Sólo las rutas que se encuentran en la subred 10.10.0.0/16 se
notifican al vecino RIP del Dispositivo-B. Esto se realiza configurando en primer
lugar una lista de acceso que sólo permita las direcciones de la subred 10.10.0.0/16
y especificando después un mapa de rutas abcd que permita las rutas que coincidan
con la lista de acceso. A continuación, se indica el mapa de rutas para filtrar las
rutas notificadas a los vecinos RIP.
La Figura 13 muestra el escenario descrito de la red.
Figura 13: Ejemplo de interfaz de túnel con RIP
10.20.0.0/16 Dispositivo-A (RIP) Dispositivo-B (RIP) 1.1.1.1/16

Internet
10.10.0.0/16 2.2.2.2/16
Túnel VPN
Enrutador RIP tunnel.1 Enrutador RIP
WebUI
Network > Routing > Virtual Router > Edit (para trust-vr) > Create RIP
Instance: Seleccione Enable RIP y haga clic en OK.
Network > Routing > Virtual Router > Access List (para trust-vr) > New:
Access List ID: 10

Sequence No.: 10
IP/Netmask: 10.10.0.0/16
Action: Permit
Network > Routing > Virtual Router > Route Map (para trust-vr) > New:
Map Name: abcd

Sequence No.: 10
Action: Permit
Match Properties:
Access List: (seleccione), 10
Network > Routing > Virtual Router > Edit (para trust-vr) > Edit RIP
Instance: Seleccione los siguientes datos y haga clic en OK:
Outgoing Route Map Filter: abcd
Network > Interfaces > Edit (para tunnel.1) > RIP: Introduzca los siguientes
Enable RIP: (seleccione)
Network > Interfaces > Edit (para trust) > RIP: Introduzca los siguientes
Enable RIP: (seleccione)
CLI
set interface tunnel.1 protocol rip enable
set interface trust protocol rip enable
set vrouter trust-vr route-map name abcd permit 10
set vrouter trust-vr route-map abcd 10 match ip 10
set vrouter trust-vr protocol rip route-map abcd out
save
Configuraciones opcionales de RIP

Esta sección describe las diversas funciones de RIP que puede configurar.
Configuración de la versión de RIP

En los dispositivos de seguridad de Juniper Networks, puede configurar la versión
de Routing Information Protocol (RIP) para el enrutador virtual (VR) y para cada
interfaz RIP que envíe y reciba actualizaciones. Según RFC 2453, el VR puede
ejecutar una versión de RIP diferente de la instancia de RIP ejecutada en una
interfaz determinada. Puede configurar también diversas versiones de RIP para
enviar y recibir actualizaciones en una interfaz RIP.
En el VR, puede configurar la versión 1 o la versión 2 de RIP; el valor

predeterminado es la versión 2. Para enviar actualizaciones en interfaces RIP, puede
configurar la versión 1, la versión 2 o el modo compatible con la versión 1 de RIP
(descrito en RFC 2453). Para recibir actualizaciones en interfaces RIP, puede
configurar la versión 1 o la versión 2 de RIP o ambas versiones; 1 y 2.
96 Configuraciones opcionales de RIP

NOTA: No se recomienda usar ambas versiones 1 y 2 a la vez. Entre la versión 1 y 2 del

protocolo pueden producirse complicaciones de red.
Para enviar y recibir actualizaciones en interfaces RIP, la versión predeterminada de

RIP es la versión que está configurada para el VR.
En el ejemplo siguiente, establece la versión 1 de RIP en trust-vr. Para la interfaz

ethernet3, establece la versión 2 de RIP tanto para enviar como para recibir
actualizaciones.
WebUI
Network > Routing > Virtual Router > Edit (para trust-vr) > Edit RIP
Instance: Seleccione V1 for Version, luego haga clic en Apply.
Network > Interfaces > Edit (para ethernet3) > RIP: Seleccione V2 for
Sending and Receiving in Update Version, luego haga clic en Apply.
CLI
set vrouter trust-vr protocol rip version 1
set interface ethernet3 protocol rip receive-version v2
set interface ethernet3 protocol rip send-version v2
save
Para verificar la versión de RIP en el VR y en las interfaces RIP, puede introducir el

comando get vrouter trust-vr protocol rip.
device-> get vrouter trust-vr protocol rip

VR: trust-vr
----------------------------------
State: enabled
Version: 1
Default metric for routes redistributed into RIP: 10
Maximum neighbors per interface: 512
Not validating neighbor in same subnet: disabled
Next RIP update scheduled after: 14 sec
Advertising default route: disabled
Default routes learnt by RIP will be accepted
Update packet threshold is not configured
Total number of RIP interfaces created on vr(trust-vr): 1
Update Invalid Flush (Timers in seconds)
-------------------------------------------------------------
30 180 120
Flags : Split Horizon - S, Split Horizon with Poison Reverse - P, Passive - I
Demand Circuit - D
Interface IP-Prefix Admin State Flags NbrCnt Metric Ver-Rx/Tx
--------------------------------------------------------------------------------
ethernet3 20.20.1.2/24 enabled enabled S 0 1 2/2
En el ejemplo de arriba, el dispositivo de seguridad está ejecutando la versión 1 de

RIP en trust-vr; pero se está ejecutando la versión 2 de RIP en la interfaz ethernet3
para enviar y recibir actualizaciones.
Configuraciones opcionales de RIP 97

Habilitación e inhabilitación de un resumen de prefijos

Puede configurar una ruta de resumen que englobe el rango de prefijos de ruta al
que deberá notificar RIP. El dispositivo de seguridad notificará solamente la ruta
que corresponde al rango de resumen en lugar de notificar individualmente cada
ruta incluida en el rango del resumen. Esto puede reducir el número de entradas de
ruta enviadas en las actualizaciones de RIP y reducir el número de entradas que los
vecinos RIP necesitan almacenar en sus tablas de enrutamiento. Habilite el
resumen de ruta en la interfaz RIP desde la que el dispositivo envía. Puede elegir
resumir las rutas en una interfaz y enviar las rutas sin el resumen en otra interfaz.
NOTA: No puede habilitar selectivamente el resumen para un rango de resumen

específico; cuando habilita el resumen en una interfaz, todas las rutas de resumen
configuradas aparecen en las actualizaciones de enrutamiento.
Al configurar la ruta de resumen, no puede especificar los rangos de prefijos

múltiples solapados. Tampoco puede especificar un rango de prefijos que incluya la
ruta predeterminada. Puede especificar opcionalmente una métrica para la ruta de
resumen. Si no especifica una métrica, se utilizará la métrica más grande para
todas las rutas incluidas en el rango de resumen.
En ocasiones, una ruta resumida puede crear oportunidades para que se produzcan
bucles. Puede configurar una ruta hacia una interfaz NULL para evitar bucles. Para
obtener más información sobre cómo establecer una interfaz NULL, consulte“Evitar
bucles creados por las rutas resumidas” en la página 11.
Habilitación de un resumen de prefijos

En el ejemplo siguiente, configure una ruta de resumen 10.1.0.0/16, que englobe
los prefijos 10.1.1.0/24 y 10.1.2.0/24. Para permitir que ethernet3 envíe la ruta de
resumen en las actualizaciones de RIP, necesita habilitar el resumen en la interfaz.
WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit RIP Instance
> Summary IP: Introduzca los siguientes datos y haga clic en Add:
Summary IP: 10.1.0.0

Netmask: 16
Metric: 1
Network > Interface > Edit (for ethernet3) > RIP: Seleccione Summarization,
luego haga clic en Apply.
CLI
set vrouter trust-vr protocol rip summary-ip 10.1.0.0/16
set interface ethernet3 protocol rip summary-enable
save

Inhabilitar un resumen de prefijo

En el ejemplo siguiente, inhabilite una ruta de resumen del prefijo para ethernet3
en el trust-vr.
WebUI
Network > Interfaces > Edit > RIP: Desactive Summarization, luego haga clic
en Apply.
CLI
unset vrouter trust-vr protocol rip summary-ip 10.1.0.0/16
unset interface ethernet3 protocol rip summary-enable
save
Establecimiento de rutas alternas

El dispositivo de seguridad mantiene una base de datos RIP para las rutas que ha
aprendido el protocolo y las rutas que se redistribuyen en RIP. De forma
predeterminada, solamente se mantiene la mejor ruta de un prefijo dado en la base
de datos. Puede permitir la existencia de una, dos o tres rutas alternativas de RIP
para el mismo prefijo en la base de datos RIP. Si permite las rutas alternativas para
un prefijo en la base de datos RIP, las rutas al mismo prefijo con un origen RIP o un
‘siguiente salto’ diferente se añaden a la base de datos RIP. Esto hace que RIP pueda
admitir los circuitos de demanda y la conmutación por error rápida.
NOTA: Recomendamos el uso de rutas alternativas con los circuitos de demanda. Para
obtener más información sobre los circuitos de demanda, consulte “Circuitos de
demanda en interfaces de túnel” en la página 101.
Solamente se añade a la tabla de enrutamiento de un enrutador virtual (VR) y se

anuncia en actualizaciones RIP la mejor ruta de la base de datos RIP de un prefijo
dado. Si se elimina la mejor ruta de la tabla de enrutamiento de un VR, el RIP añade
la siguiente ruta mejor para el mismo prefijo de la base de datos RIP. Si se añade
a la base de datos RIP una ruta nueva, que es mejor que la mejor ruta existente en
la tabla de enrutamiento de un VR, RIP se actualiza para utilizar la nueva ruta mejor
a la tabla de enrutamiento y deja de utilizar la ruta antigua. Según el límite de la ruta
alternativa que haya configurado, RIP puede o no eliminar la ruta antigua de la base
de datos RIP.
Puede visualizar la base de datos RIP ejecutando este comando CLI: get vrouter
enrut_virtual protocol rip database. En el ejemplo siguiente, el número de rutas
alternativas para la base de datos RIP se ajusta a un número mayor que 0. La base
de datos RIP muestra dos entradas para el prefijo 10.10.70.0/24 en la base de datos
RIP, una con un coste de 2 y otra con un coste de 4. La mejor ruta para el prefijo, la
ruta con el coste más bajo, se incluye en la tabla de enrutamiento de VR.

device-> get vrouter trust-vr protocol rip database

VR: trust-vr
--------------------------------------------------------------------------------
Total database entry: 14
Flags : Added in Multipath - M, RIP - R, Redistributed - I
Default (advertised) - D, Permanent - P, Summary - S
Unreachable - U, Hold - H
DBID Prefix Nexthop Interface Cost Flags Source
--------------------------------------------------------------------------------
.
.
.
47 10.10.70.0/24 10.10.90.1 eth4 2 MR 10.10.90.1
46 10.10.70.0/24 10.10.90.5 eth4 4 R 10.10.90.5
.
.
Si está habilitado el enrutamiento multidireccional de igual coste (ECMP) (consulte

“Configuración del enrutamiento multidireccional de igual coste” en la página 36) y
existen rutas múltiples de igual coste en la base de datos RIP para un prefijo dado,
el protocolo RIP añade las rutas múltiples para el prefijo en la tabla de enrutamiento
del VR hasta el límite de ECMP. En algunos casos, el límite de la ruta alternativa en
la base de datos RIP puede hacer que las rutas RIP no se añadan a la tabla de
enrutamiento del VR. Si el límite de ECMP es inferior o igual al límite de la ruta
alternativa en la base de datos RIP, las rutas RIP que no se añadan a la tabla de
enrutamiento del VR permanecerán en la base de datos RIP; estas rutas se añaden
a la tabla de enrutamiento del VR solamente si se elimina una ruta anteriormente
añadida o si ya no es la “mejor” ruta RIP para el prefijo de red.
Por ejemplo, si el límite de ECMP es 2 y el límite de la ruta alternativa en la base de

datos RIP es 3, solamente podrá haber dos rutas RIP para el mismo prefijo con el
mismo coste en la tabla de enrutamiento del VR. Puede haber otras rutas con el
mismo prefijo/mismo coste en la base de datos RIP, pero solamente se añaden dos
rutas a la tabla de enrutamiento del VR.
En el ejemplo siguiente, establezca en 1 el número de rutas alternativas permitidas

para un prefijo de la base de datos RIP en trust-vr. Esto permite que haya una ruta
“mejor” y una ruta alternativa en cualquier prefijo dado de la base de datos RIP en
el VR.
WebUI
Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit RIP
Instance: Introduzca 1 en el campo Maximum Alternative Route, luego haga clic
en Apply.
CLI
set vrouter trust-vr protocol rip alt-route 1
save

Circuitos de demanda en interfaces de túnel

Un circuito de demanda es una conexión de punto a punto entre dos interfaces de
túnel. La carga de procesamiento de la red es mínima en lo que respecta a la
cantidad de mensajes que pasan entre los extremos del circuito de demanda. Los
circuitos de demanda de RIP, definidos en la norma RFC 2091 para las redes de
área extensa, admiten grandes cantidades de vecinos RIP en los túneles VPN de los
dispositivos de seguridad de Juniper Networks.
Los circuitos de demanda de RIP eliminan la transmisión periódica de los paquetes

RIP a través de la interfaz de túnel. Para miticar la carga de procesamiento de la
red, el dispositivo de seguridad envía la información de RIP solamente cuando se
producen cambios en la base de datos de enrutamiento. El dispositivo de seguridad
retransmite también las actualizaciones y peticiones hasta que se reciben los
reconocimientos válidos. El dispositivo de seguridad aprende los vecinos RIP
mediante la configuración de vecinos estática; y si queda fuera de línea el túnel
VPN, el protocolo RIP limpia las rutas aprendidas desde la dirección IP del vecino.
Las rutas aprendidas de los circuitos de demanda no caducan con los

temporizadores RIP porque los circuitos de demanda están en un estado
permanente. Las rutas en estado permanente se eliminan solamente bajo las
condiciones siguientes:
Una ruta que antes estaba accesible pasa a estar inaccesible en una respuesta
entrante
El túnel VPN queda fuera de línea o el circuito de demanda está fuera de línea
debido a un número excesivo de retransmisiones no reconocidas
En el dispositivo de seguridad, también puede configurar una interfaz de túnel de

punto a punto o de punto a multipunto como circuito de demanda. Debe inhabilitar
route-deny (si está configurado) en un túnel de punto a multipunto de modo que
todas las rutas puedan alcanzar sitios remotos. Aunque no se requiera, también
puede inhabilitar el horizonte dividido en la interfaz de punto a multipunto con los
circuitos de demanda. Si inhabilita el horizonte dividido, los puntos extremos
podrán reconocerse mutuamente.
Debe configurar la supervisión de VPN con reencriptación en los túneles VPN para
aprender el estado del túnel.
Después de configurar el circuito de demanda y los vecinos estáticos, puede ajustar

el temporizador/retransmisor RIP, el temporizador de sondeo, y el temporizador de
retención para ajustarse a sus requisitos de red.
Los ejemplos sobre cómo configurar un circuito de demanda y un vecino estático se

muestran después de esta sección. Un ejemplo de configuración de red RIP con
circuitos de demanda a través de interfaces de túnel de punto a multipunto empieza
en la página 103.
En el ejemplo siguiente, configurará la interfaz_tunnel.1 para que actúe como

circuito de demanda y guardará la configuración.
WebUI
Network > Interfaces > Edit > RIP: Seleccione Demand Circuit, luego haga
clic en Apply.

CLI
set interface tunnel.1 protocol rip demand-circuit
save
Después de habilitar un circuito de demanda, puede activar su estado y sus

temporizadores con el comando get vrouter enrut_virtual protocol rip database. La
Tabla 12 detalla sugerencias para solucionar problemas de rendimiento provocados
por ajustes del temporizador.
Tabla 12: Solución de problemas del temporizador de retransmisión del circuito de

demanda
Rendimiento del circuito de

demanda Sugerencia
Relativamente lento Puede reconfigurar el temporizador de retransmisión a un
valor superior para reducir el número de retransmisiones.
Sin pérdidas Puede reconfigurar el temporizador de retransmisiones
para reducir la cuenta de reintentos.
Congestionado y con pérdidas Puede reconfigurar el temporizador de retransmisiones
a una cuenta de reintentos superior para dar al vecino
estático más tiempo de respuesta antes de forzar al vecino
estático a un estado de sondeo (POLL).
Configuración de un vecino estático

Una interfaz de punto a multipunto que esté ejecutando RIP requiere vecinos
configurados estáticamente. Para los circuitos de demanda de configuración
manual, es la única forma de que un dispositivo de seguridad aprenda las
direcciones vecinas en las interfaces de punto a multipunto. Para configurar un
vecino estático RIP introduzca el nombre de la interfaz y la dirección IP del vecino
RIP.
En el ejemplo siguiente configurará el vecino RIP con la dirección IP 10.10.10.2 de

la interfaz tunnel.1.
WebUI
Network > Interfaces > (Edit) RIP: Haga clic en el botón Static Neighbor IP
para avanzar a la tabla Static Neighbor IP. Introduzca la dirección IP del vecino
estático y haga clic en Add.
CLI
set interface tunnel.1 protocol rip neighbor 10.10.10.2
unset interface tunnel.1 protocol rip neighbor 10.10.10.2
save
Configuración de una interfaz de túnel punto a multipunto

El protocolo RIP punto a multipunto se admite en las interfaces de túnel numeradas
de las versiones 1 y 2 de RIP.
102 Configuración de una interfaz de túnel punto a multipunto

PRECAUCIÓN: RIP no se admite en interfaces de túnel sin numerar. Se debe

numerar todas las interfaces que utilizan protocolo RIP. Cualquier intento de
configurar y ejecutar una interfaz sin numerar utilizando RIP puede provocar un
fallo impredecible en el enrutamiento.
Debe inhabilitar el horizonte dividido en un túnel de interfaz de punto a multipunto

que configure con circuitos de demanda de modo que los mensajes alcancen todos
los sitios remotos. Para una interfaz de túnel punto a multipunto sin circuitos de
demanda, puede dejar habilitada la opción de horizonte dividido (predeterminada).
RIP aprende dinámicamente sobre los vecinos. El protocolo RIP envía todos los
mensajes transmitidos a la dirección multicast 224.0.0.9 y los reduplica a todos los
túneles según convenga.
Si desea configurar RIP como túnel punto a multipunto con circuitos de demanda,
debe diseñar su red en una configuración radial “hub and spoke”.
NOTA: En este ejemplo, únicamente se hace referencia a las interfaces de línea de

comandos y no describimos zonas y otros pasos de configuración necesarios.
La red de este ejemplo pertenece a una empresa de tamaño mediano con su oficina
central (OC) en San Francisco y delegaciones en Chicago, Los Angeles, Montreal
y Nueva York. Cada oficina tiene un solo dispositivo de seguridad. Consulte la
Los siguientes son los requisitos de configuración específicos del dispositivo de

seguridad en la OC:
1. Configure el VR para que ejecute una instancia de RIP, habilitar RIP y,

2. Configure las cuatro VPN y asociarlas a la interfaz tunnel.1.
3. Configure vecinos estáticos RIP en el dispositivo de seguridad de la oficina

central (OC).
4. No cambie los valores predeterminados del temporizador en este ejemplo.
Los siguientes son los requisitos de configuración propios de los dispositivos de

seguridad remotos de Juniper Networks:
1. Configure el VR para que ejecute una instancia de RIP, habilite RIP y,

a continuación, configure la interfaz tunnel.1.
2. Configure la VPN y asóciela a la interfaz tunnel.1.
3. No configure vecinos estáticos en los dispositivos de seguridad de la oficina

remota. Los dispositivos de la oficina remota solamente tienen un dispositivo
vecino que será descubierto por las peticiones multicast iniciales.
Configuración de una interfaz de túnel punto a multipunto 103

NOTA: No es necesario cambiar los valores predeterminados del temporizador en este

ejemplo.
Figura 14: Ejemplo de red punto a multipunto con interfaz de túnel
Los Angeles Montreal
tunnel.1 10.0.0.3 tunnel.1 10.0.0.4

Nueva York Chicago
tunnel.1 10.0.0.2 tunnel.1 10.0.0.5

VPN 2 VPN 3
Internet
VPN 4
VPN 1
San Francisco (OC)

ethernet3 1.1.1.1
tunnel.1 10.0.0.1
4 VPN asociadas a tunnel.1
En el diagrama de red que se muestra en la Figura 14, se originan cuatro VPNs en el

dispositivo de seguridad de San Francisco e irradian hacia las oficinas remotas en
Nueva York, Los Angeles, Montreal y Chicago.
En este ejemplo, configurará los siguientes ajustes en el dispositivo de seguridad de

la oficina central OC:
2. VPN
3. Rutas y RIP
4. Vecinos estáticos
5. Ruta de resumen
Para poder comprobar el estado del circuito en el dispositivo de la oficina central

OC, debe habilitar la supervisión de VPN.
Para completar la configuración de la red, configurará los siguientes ajustes en cada

uno de los cuatro dispositivos de seguridad de las oficinas remotas:
2. VPN

3. Rutas y RIP
5. Ruta de resumen

WebUI (dispositivo de la oficina central)

1. Zonas e interfaces de seguridad
de configuración.
Network > Interfaces > Edit (para ethernet3)
2. VPN
3. Rutas y RIP
virtual y haga clic en Create RIP Instance, luego habilite RIP en el enrutador
virtual.
Network > Interfaces > Edit > Haga clic en Edit y luego haga clic en RIP,
posteriormente habilite RIP en la interfaz.
Network > Interfaces > Edit > RIP > Static Neighbor IP y luego en Add
Neighbor IP Address.
5. Ruta de resumen
Network > Routing > Virtual Router Edit (RIP) > Haga clic en Summary IP
y configure la dirección IP del resumen.
CLI (dispositivo de la oficina central)

2. VPN
ripdc proposal pre-g2-3des-sha

3. Rutas y RIP
set vrouter trust protocol rip
set vrouter trust protocol rip enable
set vrouter protocol rip summary-ip 100.10.0.0/16
set interface tunnel.1 protocol rip

5. Ruta de resumen
set interface tunnel.1 protocol rip summary-enable
save
Puede seguir estos pasos para configurar el dispositivo de seguridad de la oficina

remota. Al configurar la oficina remota, no necesita configurar vecinos estáticos. En
un entorno de circuito de demanda, solamente existe un vecino para el dispositivo
remoto y éste aprende la información del vecino cuando envía un mensaje
multicast durante el arranque.
Para completar la configuración mostrada en el diagrama de la página 104, debe

repetir esta sección por cada dispositivo remoto y cambiar las direcciones IP, los
nombres de puerta de enlace y los nombres de VPN para cumplir las necesidades
de la red. En cada sitio remoto, las zonas trust y untrust cambian.


WebUI (dispositivo de oficina remota)

de configuración.
Network > Interfaces > Edit (para ethernet3)
2. VPN
3. Rutas y RIP
virtual y haga clic en Create RIP Instance, luego habilite RIP en el enrutador
virtual.
Network > Interfaces > Edit > Haga clic en Edit y luego haga clic en RIP,
posteriormente habilite RIP en la interfaz.

Directivas (de todas las zonas a todas las zonas) > Haga clic en New
CLI (dispositivo de oficina remota)

1. Protocolo de enrutamiento e interfaz
set interface untrust ip 1.1.1.1/24
2. VPN
set ike gateway gw1 address 1.1.1.1/24 main outgoing-interface untrust preshare
set vpn vpn1 id 1 bind interface tunnel.1
3. Rutas y RIP
set interface tunnel.1 protocol rip
set policy id 1 from trust to untrust any any any permit
set policy id 2 from untrust to trust any any any permit
save
Puede ver los nuevos cambios ejecutando el comando get vrouter enrut_virtuale
protocol rip neighbors. Los vecinos de un circuito de demanda aparecen en la tabla
de vecinos; la información del vecino no envejece ni expira. Puede ver la base de
datos RIP ejecutando el comando get vrouter enrut_virtuale protocol rip database.
Aparece una P de permanent junto a las entradas de los circuitos de demanda.


Capítulo 5
Protocolo de puertas de enlace de
límite
En este capítulo se describe el protocolo de puertas de enlace de límite (Border

Gateway Protocol, BGP) en los dispositivos de seguridad de Juniper Networks.
Incluye las siguientes secciones:
“Tipos de mensajes BGP” en la página 110
“Atributos de ruta” en la página 111
“BGP externo e interno” en la página 112
“Configuración básica de BGP” en la página 112
“Creación y habilitación de una instancia de BGP” en la página 113
“Habilitación e inhabilitación de BGP en interfaces” en la página 114
“Configuración de grupos de interlocutores e interlocutores BGP” en la

página 115
“Comprobación de la configuración BGP” en la página 119
“Autenticación de vecinos BGP” en la página 120
“Redistribución de rutas en BGP” en la página 123
“Configuración de una lista de acceso AS-Path” en la página 124
“Agregar rutas a BGP” en la página 125
“Capacidad de route-refresh” en la página 127
“Configuración de la reflexión de rutas” en la página 128
“Configurar una confederación” en la página 131
109
“Comunidades BGP” en la página 133
“Agregación de rutas” en la página 134
Vista general
El protocolo BGP es un protocolo de vectores de rutas que se utiliza para transportar
información de enrutamiento entre sistemas autónomos (AS). Un AS es un conjunto
de enrutadores que se encuentran en el mismo dominio administrativo.
La información de enrutamiento BGP incluye la secuencia de números de los AS

que un prefijo de red (una ruta) ha atravesado. La información de ruta asociada al
prefijo se utiliza para prevenir bucles y reforzar las directivas de enrutamiento.
ScreenOS es compatible con la versión 4 de BGP (BGP-4) tal y como se define en la
norma RFC 1771.
Dos interlocutores BGP establecen una sesión BGP para intercambiar información de
enrutamiento. Un enrutador BGP puede participar en sesiones BGP con distintos
interlocutores. En primer lugar, los interlocutores BGP deben establecer una
conexión TCP entre sí para abrir una sesión BGP. Una vez establecida la conexión
inicial, los interlocutores intercambian las tablas de enrutamiento completas.
A medida que cambian las tablas de enrutamiento, los enrutadores BGP
intercambian mensajes de actualización con los interlocutores. Cada enrutador BGP
mantiene actualizadas las tablas de enrutamiento de todos los interlocutores con los
que tiene sesiones, enviándoles periódicamente mensajes de mantenimiento de
conexión para verificar las conexiones.
El interlocutor BGP sólo notifica las rutas que está utilizando en ese momento.
Cuando un interlocutor BGP notifica una ruta a su vecino, incluye atributos de ruta
que describen sus características. El enrutador BGP compara los atributos de ruta
y el prefijo para elegir la mejor ruta de todas las disponibles para un destino
determinado.
Tipos de mensajes BGP

El protocolo BGP utiliza cuatro tipos de mensajes para la comunicación con los
interlocutores:
Los mensajes de Open permiten que los interlocutores BGP se identifiquen

mutuamente antes de iniciar la sesión GP. Estos mensajes se envían cuando los
interlocutores han establecido una sesión TCP. Durante el intercambio de
mensajes de apertura, los interlocutores BGP especifican su versión de
protocolo, número de AS, tiempo de espera e identificador BGP.
Los mensajes de Update notifican rutas al interlocutor y descartan las rutas

notificadas previamente.
Los mensajes de Notification indican errores. La sesión BGP se termina y se

cierra la sesión TCP.
110 Vista general

Capítulo 5: Protocolo de puertas de enlace de límite
NOTA: El dispositivo de seguridad no enviará un mensaje de notificación a un

interlocutor si, durante el intercambio de mensajes de apertura, el interlocutor
indica que admite protocolos con los que el dispositivo de seguridad no es
compatible.
Los mensajes de Keepalive se utilizan para el mantenimiento de la sesión BGP.

De forma predeterminada, el dispositivo de seguridad envía mensajes de
mantenimiento de conexión a los interlocutores cada 60 segundos. Este
intervalo se puede configurar.
Atributos de ruta
Los atributos de ruta BGP son un grupo de parámetros que describen las
características de una ruta. El protocolo BGP empareja los atributos con la ruta que
describen y, a continuación, compara todas las rutas disponibles para un destino
para así seleccionar la mejor ruta de acceso a ese destino. Los atributos de ruta
obligatorios y bien conocidos son:
Origin describe el origen de la ruta (puede ser IGP, EGP o estar incompleto).
AS-Path contiene una lista de sistemas autónomos a través de los cuales ha

pasado la notificación de ruta.
Next-Hop es la dirección IP del enrutador al que se envía tráfico para la ruta.
Los atributos de ruta opcionales son:
Multi-Exit Discriminator (MED) es una métrica para aquellas rutas en las que
hay múltiples vínculos entre sistemas autónomos (un AS configura el MED
y otro AS lo utiliza para elegir una ruta).
Local-Pref es una métrica utilizada para informar a los interlocutores BGP de

las preferencias del enrutador local para elegir una ruta.
Atomic-Aggregate informa a los interlocutores BGP de que el enrutador local

seleccionó una ruta menos específica de un conjunto de rutas superpuestas
recibidas de un interlocutor.
Aggregator especifica el AS y el enrutador que realizaron la agregación de la

ruta.
Communities especifica una o varias comunidades a las que pertenece la ruta.
Cluster List contiene una lista de los clústeres de reflexión a través de los
cuales ha pasado la ruta.
Un enrutador BGP puede decidir si desea agregar o modificar los atributos de ruta
opcionales antes de notificársela a los interlocutores.
Vista general 111

BGP externo e interno

El protocolo BGP externo (EBGP) se utiliza entre sistemas autónomos, p. ej., cuando
distintas redes ISP se conectan entre sí o una red empresarial se conecta a una red
ISP. El protocolo BGP interno (IBGP) se utiliza dentro de un sistema autónomo, p.
ej., una red de una empresa. El objetivo principal de IBGP es distribuir los
enrutadores reconocidos por EBGP en los enrutadores del AS. Un enrutador IBGP
puede notificar a sus interlocutores IBGP rutas reconocidas por sus interlocutores
EBGP, pero no puede notificar rutas reconocidas por sus interlocutores IBGP a otros
interlocutores IBGP. Esta restricción impide que se formen bucles de notificación de
ruta dentro de la red, pero también implica que una red IBGP debe estar
absolutamente mallada (es decir, cada enrutador BGP de la red debe tener una
sesión con cada uno de los otros enrutadores de la red).
Algunos atributos de ruta sólo son aplicables a EBGP o a IBGP. Por ejemplo, el
atributo MED sólo se utiliza en mensajes EBGP, mientras que el atributo
LOCAL-PREF sólo está presente en mensajes IBGP.
Configuración básica de BGP

En un dispositivo de seguridad, cada instancia BGP se crea individualmente por
cada enrutador virtual (VR). Si dispone de varios VR en un dispositivo, podrá
habilitar múltiples instancias de BGP, una por cada enrutador virtual.

seguridad, deberá asignar una ID de enrutador virtual, tal y como se describe en el
Los cinco pasos básicos para configurar BGP en un VR en un dispositivo de

seguridad son:
1. Crear y habilitar la instancia de enrutamiento de BGP en un enrutador virtual,

asignando primero un número de sistema autónomo a la instancia de BGP
y habilitando después la instancia.
2. Habilitar BGP en la interfaz conectada al interlocutor.
3. Habilitar cada interlocutor BGP.
4. Configurar uno o varios interlocutores BGP remotos.
5. Comprobar que el protocolo BGP está configurado correctamente y funciona.
Esta sección describe cómo realizar cada una de estas tareas utilizando CLI o WebUI
para el siguiente ejemplo. La Figura 15 muestra el dispositivo de seguridad como un
interlocutor BGP en AS 65000. Tiene que configurar el dispositivo de seguridad para
que pueda establecer una sesión BGP con el interlocutor en AS 65500.
112 Configuración básica de BGP

Figura 15: Ejemplo de configuración BGP
Número del Número del

sistema sistema
autónomo autónomo
Sistemas autónomos
AS 65000 AS 65500

Enrutador remoto
Dirección IP de ID de enrutador
ID del enrutador Dirección IP de interfaz 2.2.2.2/24 2.2.2.250
1.1.1.250 interfaz 1.1.1.1/24 BGP habilitado
BGP habilitado
Interlocutores BGP
Creación y habilitación de una instancia de BGP

Cada instancia de enrutamiento de BGP se crea y se habilita en un enrutador virtual
(VR) específico ubicado en un dispositivo de seguridad. Para crear una instancia de
enrutamiento BGP, primero se debe especificar el número de sistema autónomo en
el se que se encuentra el VR. Si el enrutador virtual es un enrutador IBGP, el número
de sistema autónomo será el mismo que el de otros enrutadores IBGP de la red.
Cuando se habilita la instancia de enrutamiento BGP en un VR, la instancia de
enrutamiento BGP será capaz de establecer contacto e iniciar una sesión con los
interlocutores BGP que configure.
NOTA: Los números de sistemas autónomos (AS) son números únicos a nivel global que
se utilizan para intercambiar información de enrutamiento EBGP y para identificar
el sistema autónomo. Las siguientes entidades asignan números de AS: American
Registry for Internet Numbers (ARIN), Réseaux IP Européens (RIPE) y Asia Pacific
Network Information Center (APNIC). Los números 64512 a 65535 son de uso
privado y no para su notificación global en Internet.
Creación de una instancia BGP

En el siguiente ejemplo, en primer lugar asignará 0.0.0.10 como ID de enrutador
a trust-vr. A continuación creará y habilitará una instancia de enrutamiento BGP en
el trust-vr, que se encuentra en el dispositivo de seguridad en AS 65000. (Para
obtener más información sobre enrutadores virtuales y cómo configurar un
enrutador virtual en dispositivos de seguridad, consulte “Enrutamiento” en la
página 13).
Configuración básica de BGP 113

WebUI
1. ID de enrutador

In the text box, enter 0.0.0.10
2. Instancia de enrutamiento de BGP

CLI
1. ID de enrutador
2. Instancia de enrutamiento de BGP
set vrouter trust-vr protocol bgp 65000
set vrouter trust-vr protocol bgp enable
save
Eliminación de una instancia de BGP

En este ejemplo inhabilitará y eliminará la instancia de enrutamiento de BGP en el
enrutador trust-vr. BGP detendrá todas las sesiones con los interlocutores.
WebUI
Network > Routing > Virtual Routers (trust-vr) > Edit > Edit BGP Instance:
Anule la selección de BGP Enabled y haga clic en OK.
Network > Routing > Virtual Routers (trust-vr) > Edit: Seleccione Delete BGP
Instance, luego haga clic en OK cuando aparezca el mensaje de confirmación.
CLI
unset vrouter trust-vr protocol bgp enable
unset vrouter trust-vr protocol bgp 65000
save
Habilitación e inhabilitación de BGP en interfaces

Es necesario habilitar BGP en la interfaz donde resida el interlocutor. (De forma
predeterminada, las interfaces del dispositivo de seguridad no están asociadas
a ningún protocolo de enrutamiento).
Habilitación de BGP en interfaces

En este ejemplo habilitará BGP en la interfaz ethernet4.
WebUI
Network > Interfaces > Edit> BGP: Marque la opción Protocol BGP enable,
y luego haga clic en OK.

CLI
set interface ethernet4 protocol bgp
save
Inhabilitación de BGP en interfaces

En este ejemplo inhabilitará BGP en la interfaz ethernet4. En las demás interfaces
en las que haya habilitado BGP podrán continuar transmitiendo y procesando
paquetes BGP.
WebUI
Network > Interfaces > Configure (para ethernet4): Elimine la marca de la
opción Protocol BGP enable, y luego haga clic en OK.
CLI
unset interface ethernet4 protocol bgp
save
Configuración de grupos de interlocutores e interlocutores BGP

Antes de que dos dispositivos BGP puedan comunicarse e intercambiar rutas,
necesitan identificarse mutuamente para poder iniciar una sesión BGP. Es necesario
especificar las direcciones IP de los interlocutores BGP y, opcionalmente, configurar
parámetros para establecer y mantener la sesión. Los interlocutores pueden ser
interlocutores internos (IBGP) o externos (EBGP). Si se trata de un interlocutor EBGP,
habrá que especificar el sistema autónomo en el que reside el interlocutor.
Todas las sesiones BGP se autentican comprobando el identificador de interlocutor

BGP y el número de AS notificado por los interlocutores. Las conexiones correctas
con un interlocutor se registran. Si surge algún problema durante la conexión con el
interlocutor, el interlocutor enviará o recibirá un mensaje de notificación BGP, lo
que hará que la conexión falle o se cierre.
Es posible configurar parámetros para direcciones de interlocutores individuales.

También se pueden asignar interlocutores a un grupo de interlocutores, lo que
permitirá configurar parámetros para el grupo en su conjunto.
NOTA: No es posible asignar interlocutores IBGP y EBGP al mismo grupo de

interlocutores.
La Tabla 13 describe parámetros que se pueden configurar para interlocutores BGP

y sus valores predeterminados. Una “X” en la columna Interlocutor indica un
parámetro que se puede configurar para la dirección IP de un interlocutor, mientras
que una “X” en la columna Grupo de interlocutores indica un parámetro que se
puede configurar para un grupo de interlocutores.

Tabla 13: Parámetros de interlocutores BGP y grupos de interlocutores y valores predeterminados
Grupo de
Parámetro BGP Interlocutor interlocutores Descripción Valor predeterminado
Advertise default X Notifica la ruta predeterminada en el La ruta predeterminada no
route enrutador virtual a interlocutores BGP. se notifica
EBGP multihop X X Número de nodos entre el BGP local y el 0 (desactivado)
vecino.
Force connect X X Hace que la instancia de BGP descarte una N/A
conexión BGP existente con el interlocutor
especificado y acepte una nueva conexión.
Este parámetro resulta de utilidad cuando hay
una conexión con un enrutador que queda
fuera de línea y luego vuelve a ponerse en
línea e intenta restablecer una conexión BGP,
ya que permite un restablecimiento más
rápido de la conexión entre interlocutores1.
Hold time X X Tiempo transcurrido sin que lleguen mensajes 180 segundos
de un interlocutor antes de que se considere
fuera de línea.
Keepalive X X Tiempo entre transmisiones de 1/3 del tiempo de
mantenimiento de conexión (keepalive). retención (hold-time)
MD5 X X Configura la autenticación MD-5. Sólo se comprueba el
authentication identificador de
interlocutor y el número
de AS
MED X Configura el valor de atributo MED. 0
Next-hop self X X En las rutas enviadas al interlocutor, el Atributo de salto siguiente
atributo de ruta al salto siguiente se ajusta en no cambiado
la dirección IP de la interfaz del enrutador
virtual local.
Reflector client X X El interlocutor es un cliente de reflexión Ninguno
cuando el protocolo BGP local se configura
como el reflector de rutas.
Reject default X No tiene en cuenta las notificaciones de ruta Las rutas predeterminadas
route predeterminada procedentes de los de los interlocutores se
interlocutores BGP. agregan a la tabla de
enrutamiento
Retry time X X Tras un intento fallido de inicio de sesión, 120 segundos
tiempo que se tarda en reintentar iniciar la
sesión BGP.
Send X X Transmite el atributo de comunidad al Atributo de comunidad no
community interlocutor. enviado a los
interlocutores
Weight X X Prioridad de ruta entre el BGP local y el 100
interlocutor.
1.Puede utilizar el comando exec neighbor disconnect para hacer que la instancia de BGP descarte una conexión BGP con el
interlocutor especificado y acepte una nueva conexión. El uso de este comando de ejecución no modifica la configuración del
interlocutor BGP. Por ejemplo, puede utilizarlo si desea cambiar la configuración del mapa de rutas que se aplica a este
interlocutor.

Es posible configurar algunos parámetros en el nivel de interlocutores y en el de

protocolo (consulte “Configurar una confederación” en la página 131). Por ejemplo,
puede configurar el valor de tiempo de espera para un interlocutor específico con
un valor de 210 segundos, mientras que el valor de tiempo de espera
predeterminado en el nivel de protocolo es de 180 segundos; en tal caso, la
configuración del interlocutor tendrá preferencia. Los valores MED ajustados en el
nivel de protocolo y en el nivel de interlocutor pueden ser distintos; el valor MED
ajustado en el nivel de interlocutor sólo se aplicará a las rutas que se notifiquen
a esos interlocutores.
Configuración de un interlocutor BGP

En el siguiente ejemplo configuraremos y habilitaremos un interlocutor BGP. Este
interlocutor tiene los siguientes atributos:
Dirección IP 1.1.1.250
Reside en AS 65500
NOTA: Deberá habilitar cada conexión de interlocutor que configure.
WebUI
AS Number: 65500
Remote IP: 1.1.1.250
Instance > Neighbors > Configure (para el interlocutor que acabe de agregar):
Seleccione Peer Enabled y luego haga clic en OK.
CLI
set vrouter trust-vr protocol bgp neighbor 1.1.1.250 remote-as 65500
set vrouter trust-vr protocol bgp neighbor 1.1.1.250 enable
save
Configuración de un grupo de interlocutores IBGP

Ahora configurará un grupo de interlocutores IBGP llamado ibgp que contendrá las
siguientes direcciones IP: 10.1.2.250 y 10.1.3.250. Una vez haya definido un grupo
de interlocutores, podrá configurar parámetros (como la autenticación MD5) que se
aplicarán a todos los miembros del grupo de interlocutores.
NOTA: Deberá habilitar cada conexión de interlocutor que configure. Si configura

interlocutores como parte de un grupo, tendrá que habilitar las conexiones de los
interlocutores una a una.

WebUI
Instance > Peer Group: Escriba ibgp en el campo Group Name, luego haga clic
en Add.
> Configure (para ibgp): En el campo Peer authentication, introduzca

verify03 y haga clic en OK.
AS Number: 65000
Remote IP: 10.1.2.250
Peer Group: ibgp (seleccione)
Introduzca los siguientes datos y haga clic en Add:
AS Number: 65000
Remote IP: 10.1.3.250
Peer Group: ibgp (seleccione)
Instance > Neighbors > Configure (para 10.1.2.250): Seleccione Peer Enabled
Instance > Neighbors > Configure (para 10.1.3.250): Seleccione Peer Enabled
CLI
set vrouter trust-vr protocol bgp neighbor peer-group ibgp
set vrouter trust-vr protocol bgp neighbor peer-group ibgp remote-as 65000
set vrouter trust-vr protocol bgp neighbor peer-group ibgp md5-authentication
verify03
set vrouter trust-vr protocol bgp neighbor 10.1.2.250 peer-group ibgp
set vrouter trust-vr protocol bgp neighbor 10.1.3.250 peer-group ibgp
save

Comprobación de la configuración BGP

Puede revisar la configuración introducida a través de WebUI o CLI ejecutando el
comando get vrouter enrut_virtual protocol bgp config.
device-> get vrouter trust-vr protocol bgp config

set protocol bgp 65000
set enable
set neighbor peer-group "ibgp"
set neighbor peer-group "ibgp" md5-authentication "cq1tu6gVNU5gvfsO60CsvxVPNnntO
PwY/g=="
set neighbor 10.1.2.250 remote-as 65000
output continues...
exit
Para comprobar si BGP se está ejecutando en el enrutador virtual, ejecute el

comando get vrouter enrut_virtual protocol bgp .
device-> get vrouter trust-vr protocol bgp

Admin State: habilitar
Local Router ID: 10.1.1.250
Local AS number: 65000
Hold time: 180
Keepalive interval: 60 = 1/3 hold time, default
Local MED is: 0
Always compare MED: disable
Local preference: 100
Route Flap Damping: disable
IGP synchronization: disable
Route reflector: disable
Cluster ID: not set (ID = 0)
Confederation based on RFC 1965
Confederation (confederación): disable (confederation ID = 0)
Member AS: none
Origin default route: disable
Ignore default route: disable
Puede visualizar el estado administrativo del enrutador virtual (VR) y de la

identificación del enrutador, así como todos los demás parámetros configurados
relativos al BGP.
NOTA: Es recomendable asignar una ID de enrutador de forma explícita, en lugar de

utilizar la ID predeterminada. Para más información sobre cómo configurar una ID
de enrutador, consulte “Enrutamiento” en la página 13.
Para comprobar si un interlocutor o grupo de interlocutores BGP está habilitado

y Ver el estado de la sesión BGP, ejecute el comando get vrouter enrut_virtual
protocol bgp neighbor.
device-> get vrouter trust-vr protocol bgp neighbor
Peer AS Remote IP Local IP Wt Status State ConnID
65500 1.1.1.250 0.0.0.0 100 Enabled ACTIVE up
Total 1 BGP peers shown
En este ejemplo puede verificar si el interlocutor BGP está habilitado y si la sesión

está activa.

El estado puede ser uno de los que aquí se indican:
Idle: primer estado de la conexión.
Connect: BGP está esperando una conexión de transporte TCP correcta.
Active: BGP está iniciando una conexión de transporte.
OpenSent: BGP está esperando un mensaje de apertura (OPEN) del

interlocutor.
OpenConfirm: BGP está esperando un mensaje de mantenimiento de conexión

(KEEPALIVE) o notificación (NOTIFICATION) del interlocutor.
Established: BGP está intercambiado paquetes de actualización (UPDATE) con

el interlocutor.
NOTA: Un estado de sesión que cambia continuamente entre Active y Connect podría
indicar un problema con la conexión entre interlocutores.
enrutamiento BGP y ciertos métodos de prevención de ataques.
NOTA: Para que BGP sea más seguro, todos los enrutadores de un dominio BGP deben
BGP comprometido podría llegar a dejar fuera de línea todo el domino de
enrutamiento BGP.
Autenticación de vecinos BGP

Un enrutador BGP se puede suplantar fácilmente, ya que los paquetes BGP no se
encriptan, y la mayoría de los analizadores de protocolo permiten desencapsular
paquetes BGP. La mejor forma de acabar con el riesgo de este tipo de ataques será
autenticando los interlocutores BGP.
BGP ofrece autenticación MD5 para validar los paquetes BGP recibidos de un
interlocutor. Para la autenticación MD5 es necesario utilizar la misma clave para los
enrutadores BGP de envío y de recepción. Todos los paquetes BGP recibidos de un
determinado interlocutor que no se autentiquen se descartarán. De forma
predeterminada, para un determinado interlocutor BGP sólo se comprobarán el
identificador de interlocutor y el número de AS.
En el siguiente ejemplo configuraremos un interlocutor BGP con la dirección IP

remota 1.1.1.250 en AS 65500. A continuación configuraremos el interlocutor para
la autenticación MD5 utilizando la clave 1234567890123456.

WebUI
AS Number: 65500
> Configure (para IP remota 1.1.1.250): Introduzca los siguientes datos

y haga clic en OK:
Peer Authentication: Enable (seleccione)

MD5 password: 1234567890123456
Peer Enabled: (seleccione)
CLI
(trust-vr)-> set protocol bgp
(trust-vr/bgp)-> set neighbor 1.1.1.250 remote-as 65500
(trust-vr/bgp)-> set neighbor 1.1.1.250 md5-authentication 1234567890123456
(trust-vr/bgp)-> set neighbor 1.1.1.250 enable
(trust-vr/bgp)-> exit
(trust-vr)-> exit
save

o puede eliminar información crítica de los paquetes antes de reenviarlos. En los
dispositivos de seguridad, BGP acepta en principio cualquier ruta predeterminada
enviada por interlocutores BGP y agrega la ruta predeterminada a la tabla de rutas.
En este ejemplo, configurará la instancia de enrutamiento BGP que se está

ejecutando en el trust-vr para que no tenga en cuenta las rutas predeterminadas
enviadas por interlocutores BGP.
WebUI
Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance:
Ignore default route from peer: (seleccione)
CLI
set vrouter trust-vr protocol bgp reject-default-route
save

Configuraciones opcionales de BGP

En esta sección se describen los parámetros que se pueden configurar para el
protocolo de enrutamiento BGP en el enrutador virtual. Es posible configurarlos con
los comandos contextuales BGP de la interfaz de línea de comandos o con la
WebUI. Esta sección explica parte de las configuraciones de parámetros más
complejas. La Tabla 14 describe los parámetros de BGP y sus valores
predeterminados.
Tabla 14: Parámetros opcionales de BGP y sus valores predeterminados
Parámetro del protocolo

BGP Descripción Valor predeterminado
Advertise default route Notifica la ruta predeterminada en el La ruta predeterminada
enrutador virtual a interlocutores BGP. no se notifica
Aggregate Crea rutas agregadas. Consulte Desactivado
“Agregación de rutas” en la página 134.
Always compare MED Compara los valores MED de las rutas. Desactivado
AS path access list Crea una lista de acceso a rutas AS para —
permitir o denegar rutas.
Community list Crea listas de comunidades. Consulte —
“Comunidades BGP” en la página 133.
AS confederation Crea confederaciones. Consulte —
“Configurar una confederación” en la
página 131.
Equal cost multipath Se pueden agregar rutas múltiples de Desactivado
(ECMP) igual coste para proporcionar equilibrio (predeterminado = 1)
de cargas. Consulte “Configuración del
enrutamiento multidireccional de igual
coste” en la página 36.
Flap damping Bloquea las notificaciones de una ruta Desactivado
hasta que es estable.
Hold time Tiempo transcurrido sin que lleguen 180 segundos
mensajes de un interlocutor antes de que
se considere fuera de línea.
Keepalive Tiempo entre transmisiones de 1/3 del tiempo de
mantenimiento de conexión (keepalive). espera (hold-time)
Local preference Configura la métrica de LOCAL_PREF. 100
MED Configura el valor de atributo MED. 0
Network Agrega entradas estáticas de red y de —
subred en BGP. BGP anuncia estas rutas
estáticas a todos los interlocutores BGP.
Consulte “Agregar rutas a BGP” en la
página 125.
Route redistribution Importa rutas a BGP desde otros —
protocolos de enrutamiento.
Reflector Configura la instancia BGP local como Desactivado
reflector de rutas para clientes. Consulte
“Configuración de la reflexión de rutas”
en la página 128.
122 Configuraciones opcionales de BGP

Parámetro del protocolo

BGP Descripción Valor predeterminado
Reject default route No tiene en cuenta las notificaciones de Las rutas
ruta predeterminada procedentes de los predeterminadas de los
interlocutores BGP. interlocutores se
agregan a la tabla de
enrutamiento
Retry time Tiempo que debe transcurrir desde un 12 segundos
establecimiento de sesión BGP fallido con
un interlocutor para que se vuelva a
intentar establecer la sesión.
Synchronization Permite la sincronización con un Desactivado
protocolo de puerta de enlace interior,
como OSPF o RIP.
Redistribución de rutas en BGP

protocolos de enrutamiento. Por ejemplo, se pueden redistribuir los siguientes tipos
de rutas en la instancia de enrutamiento de RIP de un mismo enrutador virtual:
Rutas reconocidas por OSPF o RIP
Rutas importadas
Cuando se configura la redistribución de rutas, primero se debe especificar un

mapa de rutas para filtrar las rutas que se vayan a redistribuir. Para obtener más
información sobre la creación de mapas de rutas para la redistribución, consulte el
En el siguiente ejemplo redistribuirá en el dominio de enrutamiento BGP actual una

ruta originada en un dominio de enrutamiento OSPF. Tanto en el ejemplo de la
WebUI como en el de la CLI, partiremos de la base de que ya ha creado un mapa de
rutas llamado add-ospf.
WebUI
Instance > Redist. Rules: Introduzca los siguientes datos y haga clic en Add:
Route Map: add-ospf

Protocol: OSPF
CLI
set vrouter trust-vr protocol bgp redistribute route-map add-ospf protocol ospf
save
Configuraciones opcionales de BGP 123

Configuración de una lista de acceso AS-Path

El atributo AS-path contiene una lista de sistemas autónomos (AS) que atraviesa una
ruta determinada. BGP añade el número de AS local al atributo AS-path cuando una
ruta pasa por el AS. Para filtrar rutas de acuerdo con la información de AS-path es
posible utilizar una lista de acceso AS-path. Esta lista está formada por un conjunto
de expresiones regulares que definen la información de ruta del sistema autónomo
e indican si las rutas que coinciden con esa información se deben permitir
o denegar. Por ejemplo, podemos utilizar una lista de acceso AS-path para filtrar
rutas que han pasado por un AS determinado o rutas que proceden de un AS.
Las expresiones regulares son un método para definir la búsqueda de un patrón

específico en el atributo AS-path. Es posible utilizar símbolos y caracteres especiales
para construir una expresión regular. Por ejemplo, para buscar rutas que hayan
pasado por AS 65000, puede utilizar la expresión regular _65000_ (los guiones
equivalen a un número cualquiera de caracteres delante o detrás de 65000).
También puede utilizar la expresión regular “65000$” para buscar rutas originadas
en AS 65000 (el signo de dólar indica el final del atributo AS-path, que podría ser el
AS donde se originó la ruta).
En el siguiente ejemplo configuraremos una lista de acceso AS-path para el trust-vr

que permitirá las rutas que hayan pasado por AS 65000, pero no las que hayan sido
originadas en AS 65000.
WebUI

Deny: (seleccione)
AS Path String: 65000$

Permit: (seleccione)
AS Path String: _65000_
CLI
set vrouter trust-vr protocol bgp as-path-access-list 2 deny 65000$
set vrouter trust-vr protocol bgp as-path-access-list 2 permit _65000_
save

Agregar rutas a BGP

Para permitir que el BGP anuncie las rutas de red, es necesario redistribuir las rutas
desde el protocolo de origen al protocolo de notificación (BGP) en el mismo
enrutador virtual (VR). También puede agregar rutas estáticas directamente en BGP.
Si el prefijo de red es accesible desde el VR, el BGP anuncia esta ruta a los
interlocutores sin exigir que la ruta esté redistribuida en BGP. Al agregar un prefijo
de red en BGP, puede especificar varias opciones:
Seleccionando “Yes” en la opción de comprobación de accesibilidad, puede

especificar si desde el VR debe ser accesible un prefijo de red diferente antes de
que BGP anuncie la ruta a los interlocutores. Por ejemplo, si el prefijo que desea
que el BGP anuncie se debe alcanzar a través de una interfaz de enrutador
específica, asegúrese de que la interfaz del enrutador sea accesible antes de
que el BGP anuncie la red a los interlocutores. Si la interfaz del enrutador que
especifique es accesible, BGP anuncia la ruta a sus interlocutores. Si la interfaz
del enrutador que especifique no es accesible, la ruta no se agregará al BGP y,
consecuentemente, no se anunciará a los interlocutores del BGP. Si la interfaz
del enrutador que especifique deja de ser accesible, el BGP retira la ruta a sus
interlocutores.
Seleccionando “No” en la opción de comprobación de accesibilidad, puede

especificar que el prefijo de red sea anunciado tanto si es accesible desde el VR
como si no. De forma predeterminada, el prefijo de red debe ser accesible
desde el VR antes de que el BGP anuncie la ruta a los interlocutores. Si habilita
la comprobación de accesibilidad, la ruta se puede conectar.
Puede asignar un peso al prefijo de la red. El peso es un atributo que se puede

asignar localmente a una ruta; no se anuncia a los interlocutores. Si existe más
de una ruta hacia un destino, tiene prioridad la ruta con el valor de peso más
alto.
Puede establecer los atributos de la ruta tomándolos de un mapa de rutas

(consulte “Configuración de un mapa de rutas” en la página 39). El BGP
anuncia la ruta con los atributos de ruta especificados en el mapa de rutas.
Notificación de ruta condicional

En el ejemplo siguiente, agregará una ruta estática a la red 4.4.4.0/24. Especificará
que la interfaz del enrutador 5.5.5.0/24 debe ser accesible desde el enrutador
virtual para que el BGP pueda anunciar la ruta 4.4.4.0/24 a los interlocutores. Si no
es posible acceder a la red 5.5.5.0.24, BGP no notificará la red 4.4.4.0/24. Consulte
la Figura 16.

Figura 16: Ejemplo de notificación de ruta BGP condicional
4.4.4.0/24
5.5.5.0/24
Internet
La ruta a 4.4.4.0/24 sólo se anuncia si

5.5.5.0/24 se vuelve inaccesible.
WebUI
Instance > Networks: Introduzca los siguientes datos y haga clic en Add:
Check Reachability:
Yes: (seleccione), 5.5.5.0/24
CLI
set vrouter trust-vr protocol bgp network 4.4.4.0/24 check 5.5.5.0/24
save
Establecimiento del peso de la ruta

En el ejemplo siguiente establecerá un valor de 100 para el peso de la ruta
4.4.4.0/24. (Puede especificar un valor de peso entre 0 y 65535).
WebUI
Weight: 100
CLI
set vrouter trust-vr protocol bgp network 4.4.4.0/24 weight 100
save
Establecimiento datributos de ruta

En el ejemplo siguiente configurará un setattr del mapa de ruta que establecerá la
métrica de la ruta en 100. A continuación, configurará una ruta estática en BGP que
utilice el setattr del mapa de rutas. (No es necesario establecer el mapa de rutas de
forma que coincida con el prefijo de red de la entrada de la ruta).

WebUI
Network > Routing > Virtual Routers > Route Map (para trust-vr) > New:
Map Name: setattr

Sequence No.: 1
Set Properties:
Metric: (seleccione), 100
Route Map: setattr (seleccione)
CLI
set vrouter trust-vr route-map name setattr permit 1
set vrouter trust-vr route-map setattr 1 metric 100
set vrouter trust-vr protocol bgp network 4.4.4.0/24 route-map setattr
save
Capacidad de route-refresh
La característica de route-refresh de BGP definida en RFC 2918 ofrece un
mecanismo de restablecimiento suave que permite el intercambio dinámico de
información sobre enrutamiento y solicitudes de actualización de rutas entre los
interlocutores de BGP y la nueva notificación de la tabla de enrutamiento entrante
y saliente.
Las directivas de enrutamiento para un interlocutor BGP que utiliza mapas de rutas
podrían afectar las actualizaciones de la tabla de enrutamiento entrante o saliente
ya que cuando se modifica una directiva de enrutamiento, la nueva directiva entra
en vigencia únicamente después de que se restablece la sesión BGP. Una sesión
BPG se puede borrar mediante un restablecimiento suave o abrupto.
NOTA: Un restablecimiento abrupto es perjudicial porque las sesiones BGP activas se

interrumpen y se vuelven a recuperar.
Un restablecimiento suave permite que se aplique una directiva nueva o modificada

sin borrar una sesión BGP activa. La característica de route-refresh permite que se
realice un restablecimiento suave por vecino y no requiere configuración previa o
memoria adicional.
Los restablecimientos suaves entrantes y dinámicos se utilizan para generar

actualizaciones entrantes de un vecino. Un restablecimiento suave saliente se utiliza
para enviar un nuevo conjunto de actualizaciones a un vecino. Los
restablecimientos salientes no requieren configuración previa o almacenamiento de
las actualizaciones de la tabla de enrutamiento.

La característica de enrutamiento y actualización requiere que ambos interlocutores

BGP notifiquen que admiten la función route-refresh en el mensaje de apertura
(OPEN). Si el método de route-refresh se negocia satisfactoriamente, cualquier
interlocutor BGP puede utilizar la característica de route-refresh para solicitar
información completa sobre el enrutamiento desde el otro extremo.
NOTA: Utilice el comando get neighbor dir_ip, un administrador puede verificar si se

negoció la capacidad de route-refresh. El comando también muestra contadores,
como el número de veces en que se envió o recibió la solicitud de route-refresh.
Solicitud de una actualización de la tabla de enrutamiento entrante

En este ejemplo, usted solicita que se envíe la tabla de enrutamiento entrante del
intelocutor vecino en 10.10.10.10 al trust-vr del interlocutor BGP local utilizando el
comando soft-in.
NOTA: Si la característica de route-refresh no está disponible, el comando lanza una

excepción cuando el administrador intenta utilizarla.
WebUI
Esta característica no está disponible en WebUI.
CLI
clear vrouter trust-vr protocol bgp neighbor 10.10.10.10 soft-in
Solicitud de una actualización de la tabla de enrutamiento saliente

En este ejemplo, usted envía la tabla de enrutamiento completa para trust-vr
a través de las actualizaciones del interlocutor BGP local al interlocutor vecino en
10.10.10.10 utilizando el comando soft-out.
WebUI
Esta característica no está disponible en WebUI.
CLI
clear vrouter trust-vr protocol bgp neighbor 10.10.10.10 soft-out
Configuración de la reflexión de rutas

Como un enrutador IBGP no puede notificar rutas reconocidas por un interlocutor
IBGP a otro interlocutor IBGP (consulte “BGP externo e interno” en la página 112),
es necesaria una malla completa de sesiones IBGP, donde cada enrutador en un AS
BGP será interlocutor de todos los demás enrutadores del AS.
NOTA: Una malla completa no implica que cada par de enrutadores esté conectado
directamente, sino que cada enrutador tiene que ser capaz de establecer
y mantener una sesión IBGP con cada uno de los demás enrutadores.

Una configuración de malla completa en las sesiones IBGP puede presentar

problemas de ampliación. Por ejemplo, en un AS con 8 enrutadores, cada uno de
los 8 enrutadores necesitaría intercomunicarse con los otros 7 enrutadores, lo que
puede calcularse con esta fórmula:
Para un AS con 8 enrutadores, el número de sesiones IBGP de malla completa sería

de 28.
La reflexión de rutas es un método para solucionar el problema de escalabilidad

IBGP (descrito en RFC 1966). Un reflector de ruta es un enrutador que entrega rutas
reconocidas por IBGP a los vecinos IBGP especificados (clientes), eliminando así la
necesidad de sesiones de malla completa. El reflector de rutas y sus clientes forman
un clúster, que se puede identificar por medio de una ID de clúster. Los enrutadores
situados fuera de ese clúster lo consideran una única entidad, en lugar de
intercomunicarse de forma independiente con cada enrutador en malla completa.
De esta forma se reduce la carga de procesamiento. Los clientes intercambian rutas
con el reflector, mientras que éste refleja rutas entre clientes.
El enrutador virtual (VR) local del dispositivo de seguridad puede actuar como
reflector de rutas y se le puede asignar una identificación de clúster. Si especifica
una identificación de clúster, la instancia de enrutamiento de BGP añade la
identificación del clúster al atributo Cluster-List de una ruta. La ID de clúster
contribuye a evitar la formación de bucles, puesto que la instancia de enrutamiento
de BGP local descarta una ruta cuando su ID de clúster aparece en la lista de
clústeres de la ruta.
NOTA: Antes de poder configurar una ID de clúster, es necesario inhabilitar la instancia de

enrutamiento de BGP.
Después de configurar un reflector de rutas en el enrutador virtual local, se definen

los clientes del reflector. Es posible especificar direcciones IP individuales o un
grupo de interlocutores para los clientes. No es necesario llevar a cabo ninguna
configuración en los clientes.
En el siguiente ejemplo, el enrutador EBGP notifica el prefijo 5.5.5.0/24 al cliente 3.

Sin reflexión de rutas, el cliente 3 notificará la ruta al dispositivo-A, pero el
dispositivo-A no notificará esa ruta nuevamente a los clientes 1 y 2. Si configura el
dispositivo-A como reflector de rutas y cliente 1, cliente 2 y cliente 3 como sus
clientes, el dispositivo-A notificará las rutas recibidas del cliente 3 a los clientes 1
y 2. Consulte la Figura 17.

Figura 17: Ejemplo de reflexión de rutas BGP
Número del sistema Número del sistema

autónomo autónomo
Sistemas autónomos
AS 65000 AS 65500
ID de
Cliente 1 ID enrutador
de enrutador 2.2.2.250
1.1.3.250
Dispositivo A Cliente 3 Interlocutor

ID de enrutador ID del EBGP que
del reflector de enrutador notifica la ruta a
Cliente 2 rutas 1.1.1.250
ID del enrutador 1.1.1.250 5.5.5.0/24
1.1.4.250
WebUI
Instance: Introduzca los siguientes datos, luego haga clic en Apply:
Route reflector: Enable

Cluster ID: 99
> Neighbors: Introduzca los siguientes datos y haga clic en Add:
AS Number: 65000
AS Number: 65000
AS Number: 65000
> Configure (para IP remota 1.1.2.250): Seleccione Reflector Client, luego

haga clic OK.
> Configure (para Remote IP 1.1.3.250): Seleccione Reflector Client,

luego haga clic OK.
> Configure (para Remote IP 1.1.4.250): Seleccione Reflector Client,

luego haga clic OK.

CLI
set vrouter trust-vr protocol bgp reflector
set vrouter trust-vr protocol bgp reflector cluster-id 99
set vrouter trust-vr protocol bgp neighbor 1.1.2.250 reflector-client
save
Configurar una confederación

Al igual que la reflexión de rutas (consulte “Configuración de la reflexión de rutas”
en la página 128), las confederaciones ofrecen otra forma de resolver el problema de
ampliación de las mallas completas en entornos IBGP y se describen en la norma
RFC 1965. Una confederación divide un sistema autónomo en varios AS más
pequeños, con cada subsistema autónomo funcionando como una red IBGP de
malla completa. Cualquier enrutador situado fuera de la confederación verá la
confederación completa como un único sistema autónomo con un solo
identificador; las redes de los subsistemas no son visibles fuera de la confederación.
Las sesiones entre enrutadores en dos subsistemas distintos de la misma
confederación, conocidas como sesiones EIBGP, no son más que sesiones EBGP
entre sistemas autónomos, pero en las que los enrutadores también intercambian
información de enrutamiento como si fueran interlocutores IBGP. La Figura 18
ilustra las confederaciones BGP.
Figura 18: Confederaciones BGP
Sistemas autónomos
AS 65000 (confederación)
Subsistema AS 65001 Subsistema AS 65002 Subsistema AS 65003 AS 65500
EBGP EBGP EBGP
IBGP IBGP IBGP
Subsistemas autónomos
Hay que especificar los siguientes datos por cada enrutador de una confederación:
El número de subsistema autónomo (número de AS especificado cuando se

crea la instancia de enrutamiento BGP).
La confederación a la que pertenece el subsistema autónomo (número de AS

visible para los enrutadores BGP fuera de la confederación).
Los números de los otros subsistemas de la confederación.
Si la confederación admite las normas RFC 1965 (predeterminado) o

RFC 3065.

NOTA: El atributo AS-Path (consulte “Atributos de ruta” en la página 111) se compone

normalmente de una secuencia. Los ASs atravesados por la actualización de
enrutamiento. La norma RFC 3065 permite que el atributo AS-Path incluya todos
los AS que forman parte de la confederación local atravesados por la actualización
de enrutamiento.
Figura 19muestra el dispositivo de seguridad como un enrutador BGP en el

subsistema autónomo 65003 que pertenece a la confederación 65000. Los otros
subsistemas de la confederación 65000 son 65002 y 65003.
Figura 19: Ejemplo de configuración de confederación BGP
AS 65000 (confederación)
Subsistema AS 65001 Subsistema AS 65002 Subsistema AS 65003
Subsistemas autónomos
WebUI
Instance: Introduzca los siguientes datos, luego haga clic en Apply:

> Confederation: Introduzca los siguientes datos y haga clic en Apply:
Enable: (seleccione)
ID: 65000
Supported RFC: RFC 1965 (seleccione)
Peer member area ID: 65001
Peer member area ID: 65002
> Parámetros: Seleccione BGP Enable
CLI
set vrouter trust-vr protocol bgp 65003
set vrouter trust-vr protocol bgp confederation id 65000
set vrouter trust-vr protocol bgp confederation peer 65001
set vrouter trust-vr protocol bgp confederation peer 65002
set vrouter trust-vr protocol bgp enable
save

Comunidades BGP
El atributo de ruta Communities ofrece un modo de agrupar destinos (llamados
comunidades), que un enrutador BGP podrá después utilizar para controlar las rutas
que acepta, prefiere o redistribuye a los equipos vecinos. Un enrutador BGP puede
agregar comunidades a una ruta (si la ruta no tiene el atributo Communities)
o modificar las comunidades de una ruta (si ésta incluye el atributo de ruta
Communities). Este atributo ofrece una técnica alternativa para distribuir
información de rutas de acuerdo con los prefijos de direcciones IP o el atributo
AS-path. Puede utilizar el atributo Communities de muchas formas, pero su
principal objetivo es simplificar la configuración de directivas de enrutamiento en
entornos de redes completos.
La norma RFC 1997 describe el funcionamiento de las comunidades BGP. Un

administrador de AS puede asignar a una comunidad una serie de rutas que
precisen de las mismas decisiones de enrutamiento; a esto se le llama en ocasiones
coloreado de rutas. Por ejemplo, es posible asignar un valor de comunidad a las
rutas con acceso a Internet y otro valor de comunidad a las rutas que no tienen
acceso.
Hay dos tipos de comunidades:
Una comunidad específica está formada por un identificador de AS y un

identificador de comunidad. Este último es definido por el administrador de
AS.
Una comunidad bien conocida implica un manejo especial de las rutas que
contienen esos valores de comunidad. A continuación se muestran valores de
comunidad bien conocida que se pueden especificar para las rutas BGP en el
no-export: las rutas con este atributo de ruta Communities no se notifican

fuera de una confederación BGP.
no-advertise: las rutas con este atributo de ruta Communities no se

notifican a otros interlocutores BGP.
no-export-subconfed: las rutas con este atributo de ruta Communities no

se notifican a interlocutores EBGP.
Puede utilizar un mapa de rutas para filtrar las rutas que coinciden con los datos de
una lista de comunidad especificada, eliminar o asignar atributos a las rutas,
agregar comunidades a la ruta o eliminarlas de ella.
Por ejemplo, si un proveedor de servicios de Internet (ISP) ofrece conectividad

a Internet a sus clientes, cada una de las rutas de esos clientes podrá recibir un
número de comunidad específico. A continuación, esas rutas de clientes se
notificarán a los ISP vecinos. Las rutas de otros ISP recibirán otros números de
comunidad y no se notificarán a los ISP vecinos.

Agregación de rutas
La agregación es una técnica para resumir rangos de direcciones de enrutamiento
(conocidas como rutas contribuyentes) en una sola entrada de ruta. Hay varios
parámetros opcionales que se pueden establecer al configurar una ruta agregada.
Esta sección contiene ejemplos de configuración de rutas agregadas.
Agregación de rutas con diferentes AS-Paths

Al configurar una ruta agregada, puede especificar que el campo AS-Set del atributo
de ruta AS-Path de BGP incluya las rutas AS de todas las rutas contribuyentes. Para
especificar esto, utilice la opción AS-Set en la configuración de rutas agregadas.
NOTA: Si utiliza la opción AS-Set con una ruta agregada, un cambio en una ruta
contribuyente puede provocar que el atributo de la ruta agregada también cambie.
Esto provoca que BGP vuelva a anunciar la ruta agregada con el atributo de ruta
cambiado.
WebUI
Instance > Aggregate Address: Introduzca los siguientes datos, luego haga clic
en Apply:
Aggregate State: Enable (seleccione)

AS-Set: (seleccione)
CLI
set vrouter trust protocol bgp
set vrouter trust protocol bgp aggregate
set vrouter trust protocol bgp aggregate 1.0.0.0/8 as-set
set vrouter trust protocol bgp enable
save
NOTA: Debe habilitar la agregación de BGP antes de habilitar BGP.
Supresión de las rutas más específicas en actualizaciones

Al configurar una ruta agregada, puede especificar que las rutas más específicas
(More-Specific) sean filtradas (excluidas) de las actualizaciones de enrutamiento.
(Un interlocutor BGP prefiere una ruta más específica, si está anunciada, a una ruta
agregada). Puede suprimir las rutas más específicas de cualquiera de estas dos
maneras:
Utilice la opción Summary-Only en la configuración de rutas agregadas para

suprimir todas las rutas más específicas.
Utilice la opción Supress-Map en la configuración de rutas agregadas para

suprimir las rutas especificadas en un mapa de rutas.
En el ejemplo siguiente, el BGP anuncia la ruta agregada 1.0.0.0/8, pero las rutas
más específicas son excluidas mediante filtro de las actualizaciones de rutas
salientes.

WebUI
en Apply:

Suppress Option: Summary-Only (seleccione)
CLI
set vrouter trust protocol bgp aggregate 1.0.0.0/8 summary-only
save
En el ejemplo siguiente, filtrará las rutas del rango 1.2.3.0/24 para que sean
eliminadas de las actualizaciones que incluyan la ruta agregada 1.0.0.0/8. Para ello,
primero configurará una lista de accesos que especifique las rutas a filtrar
(1.2.3.0/24). A continuación, configurará un mapa de rutas ‘noadvert’ para permitir
las rutas 1.2.3.0/24. Después configurará una ruta agregada 1.0.0.0/8 y especificará
el mapa de ruta ‘noadvert’ como opción de supresión para las actualizaciones
salientes.
WebUI
Network > Routing > Virtual Routers > Access List (para trust-vr) > New:
Access List ID: 1

Sequence No.: 777
Map Name: noadvert

Sequence No.: 2
Match Properties:
Access List (seleccione), 1 (seleccione)
en Apply:

Suppress Option: Route-Map (seleccione), noadvert (seleccione)
CLI
set vrouter trust-vr route-map name noadvert permit 2
set vrouter trust-vr route-map noadvert 2 match ip 1
set vrouter trust protocol bgp aggregate 1.0.0.0/8 suppress-map noadvert
save

Selección de rutas para el atributo Path

Al configurar una ruta agregada, puede especificar qué rutas deben o no deben ser
utilizadas para construir el atributo de ruta AS-Path del BGP de la ruta agregada.
Utilice la opción Advertise-Map en la configuración de rutas agregadas para
seleccionar las rutas. Puede utilizar esta opción con la opción AS-Set para
seleccionar rutas anunciadas con el atributo AS-Set.
En el ejemplo siguiente, configurará una ruta agregada 1.0.0.0/8 que se anunciará

con el atributo AS-Set. El atributo AS-Set anunciado consiste en todas las rutas más
específicas que caigan en el rango de prefijo 1.5.0.0/16, pero no las rutas que
caigan en el rango de prefijo 1.5.6.0/24; configurará los rangos de prefijo a incluir
y excluir en el mapa de rutas “advertset”.
WebUI
Access List ID: 3

Sequence No.: 888
Action: Deny (seleccione)
Access List ID: 3

Sequence No.: 999
Map Name: advertset

Sequence No.: 4
Match Properties:
Access List (seleccione), 3 (seleccione)
en Apply:

Advertise Map: advertset (seleccione)
CLI
set vrouter trust-vr access-list 3 deny ip 1.5.6.0/24 888
set vrouter trust-vr route-map name advertset permit 4
set vrouter trust-vr route-map advertset 4 match ip 3
set vrouter trust protocol bgp aggregate 1.0.0.0/8 advertise-map advertset
save

Cambiar atributos de una ruta agregada

Al configurar una ruta agregada, puede establecer sus atributos basándose en un
mapa de ruta especificado. En el ejemplo siguiente, configurará una ruta agregada
1.0.0.0/8 que se anunciará con la métrica 1111 en las actualizaciones salientes.
WebUI
Map Name: aggmetric

Sequence No.: 5
Set Properties: (seleccione)
Metric: 1111
en Apply:

Attribute Map: aggmetric (seleccione)
CLI
set vrouter trust-vr route-map name aggmetric permit 5
set vrouter trust-vr route-map aggmetric 5 metric 1111
set vrouter trust protocol bgp aggregate 1.0.0.0/8 attribute-map aggmetric
save


Capítulo 6
Enrutamiento basado en directivas
El enrutamiento basado en directivas (PBR) proporciona un mecanismo flexible

para reenviar los paquetes de datos basados en directivas que un administrador de
red configura.
“Vista general del enrutamiento basado en directivas” en la página 140
“Listas de acceso extendidas” en la página 140
“Grupos de coincidencias” en la página 141
“Grupos de acciones” en la página 141
“Consulta de rutas con enrutamiento basado en directivas” en la página 142
“Configuración del enrutamiento basado en directivas” en la página 143
“Configuración de una lista de acceso extendida” en la página 143
“Configuración de un grupo de coincidencias” en la página 145
“Configuración de un grupo de acciones” en la página 145
“Configuración de una directiva de PBR” en la página 146
“Enlace de una directiva de enrutamiento basado en directivas” en la

página 146
“Visualización de la salida de enrutamiento basado en directivas” en la

página 147
“Visualización de una lista de acceso extendida” en la página 147
“Visualización de un grupo de coincidencias” en la página 148
“Visualización de un grupo de acciones” en la página 148
“Visualización de la configuración de una directiva de enrutamiento basado

en directivas” en la página 149
139
“Visualización de la configuración completa de enrutamiento basado en

directivas” en la página 150
“Ejemplo de PBR avanzado” en la página 150
“PBR avanzado con alta disponibilidad y posibilidad de ampliación” en la

página 155
Vista general del enrutamiento basado en directivas

El enrutamiento PBR le permite implementar directivas que ocasiona que los
paquetes tomen rutas distintas de manera selectiva. El enrutamiento PBR
proporciona un mecanismo de enrutamiento para las redes que se basan en el
soporte de la capa de aplicación, como el antivirus (AV), deep inspection (DI) o
antispam, filtrado de web o que requieren de una vía automática para aplicaciones
específicas.
Como primera parte del proceso de consulta de rutas, ScreenOS revisa si hay PBR y
la revisión de PBR es transparente para todo el tráfico que no es PBR, cuando un
paquete entra en el dispositivo de seguridad. PBR está habilitado en el nivel de
interfaz y configurado dentro de un contexto de enrutador virtual; pero puede elegir
la asociación de las directivas de PBR a una interfaz, una zona, un enrutador virtual
(VR) o una combinación de interfaz, zona o VR.
Se utilizan los siguientes tres módulos para crear una directiva de PBR:
Listas de acceso extendidas
Grupos de coincidencias
Grupos de acciones

Las listas de acceso extendido enumeran los criterios de coincidencia que define
para las directivas de PBR. Los criterios de coincidencia de PBR determinan la ruta
de un flujo determinado de tráfico de datos. Los criterios de coincidencia incluyen
los siguientes:
Dirección IP de origen
Dirección IP destino
Puerto de origen
Puerto de destino
Protocolo, como HTTP
Prioridad de calidad de servicio (QoS) (opcional)
140 Vista general del enrutamiento basado en directivas

Capítulo 6: Enrutamiento basado en directivas
Los grupos de coincidencias proporcionan una manera de organizar (por grupo,
nombre y prioridad) las listas de acceso extendidas. Los grupos de coincidencias
asocian el número de ID de lista de acceso extendida con un nombre de grupo de
coincidencias única y un número de ID de grupo de coincidencias. Este número de
ID de grupo de coincidencias define el orden en el cual desea que el dispositivo de
seguridad procese las listas de ACL extendidas. Puede asignar varias listas de acceso
extendidas al mismo grupo de coincidencias.
Grupos de acciones
Los grupos de acciones especifican la ruta que desea que tome el paquete. Se
especifica la “acción” de la ruta al definir la siguiente interfaz, el salto siguiente o
ambos.
Cada entrada de acción configurada se supervisa para revisar la accesibilidad como

se muestra a continuación:
NOTA: La supervisión de la accesibilidad no se refiere a las consultas del Protocolo de

resolución de dirección (ARP) de la capa 2 o seguimiento de la capa 3.
Accesibilidad únicamente de la siguiente interfaz
Si asocia la entrada de acción únicamente con la siguiente interfaz, el estado de

conexiones determina la accesibilidad.
Si la siguiente interfaz está activa, la entrada de acción es posible. Cualquier

interfaz, incluyendo todas las interfaces lógicas, tales como de túnel, agregadas
o redundantes, que son visibles en el VR en el cual reside la directiva, son
candidatas para la siguiente interfaz.
Por ejemplo, si configura la entrada de acción con una interfaz NULL, la entrada
de acción es alcanzable todo el tiempo. Con una interfaz NULL como la
siguiente interfaz, la consulta de PBR siempre tiene éxito, de manera que
ScreenOS detiene la consulta de rutas y descarta los paquetes.
Accesibilidad únicamente de salto siguiente
Si asocia el grupo de acciones únicamente con el salto siguiente, éste debe ser
alcanzable a través de una entrada de ruta en la tabla de enrutamiento de las
rutas de destino. El salto siguiente configurado es alcanzable en tanto exista
una ruta válida en la tabla de enrutamiento de rutas de destino para resolver el
salto siguiente.
Accesibilidad de la siguiente interfaz y de salto siguiente
Si configura la accesibilidad tanto para el salto siguiente como para la siguiente

interfaz, el salto siguiente configurado debe ser alcanzable a través de la
siguiente interfaz configurada.
Vista general del enrutamiento basado en directivas 141

Si el salto siguiente es alcanzable a través de la siguiente interfaz, la entrada de

acción es alcanzable. Cualquier interfaz incluyendo todas las interfaces lógicas,
tal como túnel, agregado o redundante, que son visibles en VR en el cual reside
la directiva, son candidatas para ser la siguiente interfaz.
ScreenOS descarta el paquete si el salto siguiente es alcanzable pero la

siguiente interfaz es una interfaz NULL. Si configura la entrada de acción con
una interfaz NULL como la siguiente interfaz y el salto siguiente como ruta
estática, ScreenOS pasa los paquetes a la ruta estática.
En el momento de la configuración, también asigna un número de secuencia para

especificar el orden en el cual desea que se procese la entrada de grupo de
acciones.
Consulta de rutas con enrutamiento basado en directivas

Cuando se habilita el enrutamiento basado en directivas en una interfaz, ScreenOS
revisa todo el tráfico enviado a esa interfaz para ver si incluye enrutamiento basado
en directivas. Cuando un paquete entra al dispositivo de seguridad, ScreenOS revisa
la interfaz de entrada para una configuración de directiva de PBR. Si PBR está
habilitado en esa interfaz de entrada, se aplican las siguientes acciones al paquete:
1. ScreenOS aplica la directiva de PBR asociada a la interfaz de entrada al

paquete.
2. Si no existe una directiva de PBR al nivel de la interfaz, entonces ScreenOS

aplica la directiva de PBR unida a la zona asociada con la interfaz de entrada al
paquete.
3. Si no existe una directiva de PBR al nivel de zona, entonces ScreenOS aplica la

directiva de PBR unida a VR asociado con la interfaz de entrada al paquete.
ScreenOS encuentra el grupo de coincidencias y luego procesa las entradas de

grupo de acciones. La primera entrada de acción alcanzable del grupo de acciones
con una ruta válida es la que se utiliza para reenviar el paquete. Si no existen rutas
alcanzables entre las entradas de acción, entonces se realiza una consulta de rutas
regular.
Si la entrada de acción es alcanzable, ScreenOS realiza una consulta de rutas con la

interfaz preferida como la siguiente interfaz (si se especifica) y el salto siguiente
como la dirección IP (si se especifica) en lugar de utilizar el IP de destino. Si una
ruta coincide con la siguiente interfaz y salto siguiente indicados, ScreenOS reenvía
el paquete. De lo contrario, ScreenOS utiliza la dirección IP de destino.
NOTA: Para obtener más información sobre la consulta de rutas, consulte el Volumen 2:
Fundamentos.
142 Consulta de rutas con enrutamiento basado en directivas

Configuración del enrutamiento basado en directivas

La Figura 20 muestra una manera en que PBR diferencia las rutas de tráfico de
servicio enviando el tráfico de HTTP a lo largo de una ruta y el tráfico de HTTPS a lo
largo de otra. La Figura 20 muestra dos nodos, uno en 172.18.1.10 y otro en
172.18.2.10. Cuando el dispositivo de seguridad recibe el tráfico de HTTP,
ScreenOS enruta el tráfico a través del enrutador 172.24.76.1; y cuando el
dispositivo de seguridad recibe el tráfico de HTTPS, ScreenOS enruta el tráfico a
través del enrutador 172.24.76.2.
Lo contrario sucede en el nodo 172.18.2.10. El tráfico de HTTP del nodo

172.18.2.10 fluye al enrutador 172.24.76.2 y el tráfico de HTTPS fluye al enrutador
172.24.76.1.
Figura 20: Enrutamiento del tráfico de HTTP y HTTPS con enrutamiento basado en
directivas
172.24.76.1 172.24.76.2
Enrutador izquierdo Enrutador derecho
172.24.76.71/22
El tráfico de HTTP fluye de 172.18.2.10/24 al enrutador
172.24.76.2
El tráfico de HTTPS fluye de 172.18.1.10/24 al enrutador
172.24.76.1
10.25.10.0/24
172.18.1.10/24 172.18.2.10/24
Configuración de una lista de acceso extendida

Puede configurar una lista de acceso extendida con la interfaz de usuario web
(WebUI) o la interfaz de línea de comandos (CLI) desde dentro de un contexto de
enrutador virtual. Primero, configure la lista de acceso extendida en el enrutador
virtual (VR) de ingreso.
En este ejemplo que se encuentra en la página 143, el VR de ingreso es trust-vr. Si

utiliza CLI, necesita introducir el contexto del enrutador virtual. Este ejemplo
requiere de dos listas de acceso: 10 y 20. El número de secuencia de acceso es un
número de 1 a 99. Las entradas 1 y 2 son necesarias para cada lista de acceso
extendida.
NOTA: Opcionalmente, puede agregar también el número de tipo de servicio (TOS), el

cual es un número de 1 a 255. En este ejemplo no se requiere un número TOS.
Configuración del enrutamiento basado en directivas 143

La lista de acceso 10 define la dirección IP de origen como 172.18.1.10, el puerto

de destino como 80 y el protocolo como TCP. El punto de destino para la lista de
acceso 10 define la dirección IP de destino como 172.18.2.10, el puerto de destino
como 443 y el protocolo como TCP.
La lista de acceso 20 define la dirección IP de origen como 172.18.2.10, el puerto

de destino como 443 y el protocolo como TCP. El punto de destino para la lista de
acceso 10 define la dirección IP de destino como 172.18.1.10, el puerto de destino
como 80 y el protocolo como TCP.
En la CLI después de realizar la configuración de la lista de acceso extendida, usted

sale del contexto del enrutador virtual. El ejemplo de WebUI únicamente muestra la
creación de la lista de acceso 10.
WebUI
Network > Routing > PBR > Extended ACL List: Seleccione el enrutador
virtual de la lista desplegable, luego haga clic en New para ver la página
Configuration.
Introduzca la siguiente información para crear las entradas de la lista de

acceso 10:
Creación de la lista de acceso 10

Extended ACL ID: 10
Sequence No.: 1
Source IP Address/Netmask: 172.18.1.10/32
Destination Port: 80-80
Protocol: TCP
Haga clic en OK. ScreenOS vuelve a una lista de listas de acceso.
Haga clic en New para configurar una segunda entrada para la lista de acceso
10 e introduzca la siguiente información:
Creación de la lista de acceso 10

Extended ACL ID: 10
Sequence No.: 2
Source IP Address/Netmask: 172.18.2.10/32
Destination Port: 443-443
Protocol: TCP
Haga clic en OK. ScreenOS lo regresa a una lista de listas de acceso.
CLI
set access-list extended 10 src-ip 172.18.1.10/32 dest-port 80-80 protocol tcp
entry 1
entry 2
entry 1
entry 2
exit
144 Configuración del enrutamiento basado en directivas

Configuración de un grupo de coincidencias

Puede configurar un grupo de coincidencias desde dentro de un contexto de
enrutador virtual.
En el ejemplo de la página 143, necesita configurar dos grupos de coincidencias:

Enrutador izquierdo y enrutador derecho. Puede asociar una lista de acceso 10
extendida con el enrutador izquierdo y una lista de acceso 20 extendida con el
enrutador derecho. Un nombre de grupo de coincidencias es un identificador único
de no más de 31 caracteres alfanuméricos.
El VR de ingreso es trust-vr. Si utiliza CLI, necesita introducir el contexto del

enrutador virtual. En la CLI, después de realizar la configuración de la lista de
acceso extendida, se sale del contexto del enrutador virtual.
El ejemplo de WebUI únicamente muestra la creación de un grupo de coincidencias

para el enrutador izquierdo.
WebUI
Network > Routing > PBR > Match Group > Seleccione el enrutador virtual
correcto de la lista desplegable, luego haga clic en New para ver la página Match
Group Configuration. Introduzca la siguiente información para configurar el
enrutador izquierdo:
Match Group Name: enrutador_izquierdo

Sequence No.: 1
Extended ACL: Seleccione 10 de la lista desplegable.
CLI
set match-group name enrutador_izquierdo
set match-group left ext-acl 10 match-entry 1
set match-group name enrutador_derecho
set match-group right ext-acl 20 match-entry 1
exit
Configuración de un grupo de acciones

Puede configurar un grupo de acciones dentro de un contexto de enrutamiento
virtual.
En el ejemplo que se encuentra en la página 143 es posible que existan dos grupos
de acciones diferentes: el dispositivo de seguridad puede reenviar el tráfico al
enrutador izquierdo o al enrutador derecho. Por esta razón, necesita configurar dos
diferentes grupos de acciones.
Para configurar estos dos grupos de acciones, realice las siguientes tareas:
1. Entre al contexto de enrutamiento virtual. En este ejemplo, el enrutador virtual

es trust-vr.
2. Denomine el grupo de acciones con un nombre único y con significado. En este

ejemplo, los nombres acci-derecha y acci-izquierda son descriptivos de los
flujos de tráfico posibles.
Configuración del enrutamiento basado en directivas 145

3. Configure los detalles del grupo de acciones. En este ejemplo, establecerá la

dirección de salto siguiente para cada grupo de acciones y luego asignará un
número para indicar la prioridad de procesamiento. En este ejemplo, la
prioridad de cada grupo de acciones es 1.
WebUI
Network > Routing > PBR > Action Group > Haga clic en New para ver la
página Configuration
CLI
set action-group name acci-derecha
set action-group acci-derecha next-hop 172.24.76.2 action-entry 1
set action-group name acci-izquierda
set action-group acci-izquierda next-hop 172.24.76.1 action-entry 1
exit
Configuración de una directiva de PBR

Puede configurar una directiva de PBR desde dentro de un contexto de enrutador
virtual.
Cada directiva de PBR necesita tener un nombre único. En este ejemplo, la directiva
se denomina directiva-redireccionar.
Una directiva de PBR puede contener un nombre de grupo de coincidencias y un

nombre de grupo de acciones. En este ejemplo, el tráfico puede fluir de dos
diferentes formas, así que se necesitan dos instrucciones diferentes: acci-izquierda
con el número de secuencia 1 y acci-derecha con el número de secuencia 2. La
instrucción de directiva con el número de secuencia 1 se procesa primero.
WebUI
Network > Routing > PBR > Policy > Haga clic en New para ver la página
Configuration
CLI
set pbr policy name directiva-redireccionar
set pbr policy directiva-redireccionar match-group left action-group acci-izquierda 1
set pbr policy directiva-redireccionar match-group right action-group acci-derecha 2
exit
Enlace de una directiva de enrutamiento basado en directivas

Puede asociar una directiva de PBR a una interfaz, una zona o un enrutador virutal
dentro de un contexto de enrutador virtual.

una interfaz
Puede asociar la directiva de PBR directiva-redireccionar a la interfaz de ingreso.
En este ejemplo, la interfaz es la interfaz trust.
146 Configuración del enrutamiento basado en directivas

WebUI
Network > Routing > PBR > Policy Binding
CLI
set interface trust pbr directiva-redireccionar

una zona
Puede asociar la directiva de PBR directiva-redireccionar a una zona. En este
ejemplo, la zona es la zona Trust.
WebUI
CLI
set zone trust pbr directiva-redireccionar

enrutador virtual
Puede asociar la directiva de PBR directiva-redireccionar a un enrutador virtual. En
este ejemplo, el enrutador virtual es trust-vr.
WebUI
CLI
set vrouter trust-vr pbr directiva-redireccionar
Visualización de la salida de enrutamiento basado en directivas

Puede ver la información relacionada con el enrutamiento basado en directivas con
WebUI o CLI.
Visualización de una lista de acceso extendida

Puede ver la lista completa de las listas de acceso extendidas desde WebUI o CLI.
En CLI puede especificar ver una lista de acceso extendida determinada. En el

segundo ejemplo de CLI, el ejemplo muestra que existen dos listas de acceso
extendidas en trust-vr, pero el usuario indicó la lista de acceso extendido 2. Según
se especificó, ScreenOS regresó dos entradas de lista de acceso, 10 y 20,
únicamente para la segunda lista de acceso extendida.
WebUI
Network > Routing > PBR > Access List Ext
CLI 1
get vrouter trust-vr pbr access-list configuration
Visualización de la salida de enrutamiento basado en directivas 147

Ejemplo:
set access-list extended 1 src-ip 172.16.10.10/32 dest-ip 192.169.10.10/32

dest-port 80-80 protocol tcp entry 1
set access-list extended 1 src-port 200-300 entry 2
set access-list extended 2 dest-port 500-600 protocol udp entry 10
set access-list extended 2 dest-ip 50.50.50.0/24 protocol udp entry 20
CLI 2
get vrouter trust-vr pbr access-list 2
Ejemplo:
PBR access-list: 2 in vr: trust-vr, number of entries: 2

------------------------------------------------
PBR access-list entry: 10
------------------------
dest port range 500-600
protocols: udp
PBR access-list entry: 20
------------------------
dest ip-address 50.50.50.0/24
protocols: udp
Visualización de un grupo de coincidencias

Puede ver los detalles de grupo de coincidencias desde WebUI o CLI.
WebUI
Network > Routing > PBR > Match Group
CLI
get vrouter trust-vr pbr match-group config
Ejemplo:
set match-group name pbr1_mg

set match-group pbr1_mg ext-acl 1 match-entry 1
set match-group name pbr1_mg2
set match-group pbr1_mg2 ext-acl 2 match-entry 10
Visualización de un grupo de acciones

Puede ver los detalles de grupo de acciones desde WebUI o CLI.
WebUI
Network > Routing > PBR > Action Group
CLI 1
get vrouter trust-vr pbr action-group configuration
148 Visualización de la salida de enrutamiento basado en directivas

Ejemplo:
set action-group name pbr1_ag

set action-group pbr1_ag next-interface ethernet2 next-hop 10.10.10.2
action-entry 1
set action-group name pbr1_ag2
set action-group pbr1_ag2 next-hop 30.30.30.30 action-entry 10
set action-group pbr1_ag2 next-interface ethernet3 action-entry 20
set action-group pbr1_ag2 next-interface ethernet3 next-hop 60.60.60.60
action-entry 30
CLI 2
get vrouter trust-vr pbr match-group name pbr1_ag2
Ejemplo:
device-> get vr tr pbr action-group name pbr1_ag2

PBR action-group: pbr1_ag2 in vr: trust-vr number of entries: 3
------------------------------------------------
PBR action-group entry: 10
next-interface: N/A, next-hop: 30.30.30.30
------------------------
next-interface: ethernet3, next-hop: 0.0.0.0
------------------------
next-interface: ethernet3, next-hop: 60.60.60.60
------------------------
Visualización de la configuración de una directiva de enrutamiento basado en directivas

Puede ver la configuración de directivas de enrutamiento basado en directivas
desde WebUI o CLI. En la CLI puede escoger ver la configuración o puede introducir
el nombre de directiva para ver una configuración de directiva individual.
WebUI
Network > Routing > PBR > Policy
CLI
get vrouter trust-vr pbr policy config
Ejemplo:
set pbr policy name pbr1_policy

set pbr policy pbr1_policy match-group pbr1_mg2 action-group pbr1_ag2 50
set pbr policy pbr1_policy match-group pbr1_mg action-group pbr1_ag 256
Visualización de la salida de enrutamiento basado en directivas 149

CLI
get vrouter trust-vr pbr policy name pbr1_policy
Ejemplo:
PBR policy: pbr1_policy in vr: trust-vr number of entries: 2

------------------------------------------------
PBR policy entry: 50
match-group: pbr1_mg2, action-group: pbr1_ag2
------------------------
PBR policy entry: 256
match-group: pbr1_mg, action-group: pbr1_ag
------------------------
Visualización de la configuración completa de enrutamiento basado en directivas

Puede ver la configuración de enrutamiento basado en directivas desde WebUI o
CLI.
WebUI
Network > Routing > PBR > Access List Ext
Network > Routing > PBR > Match Group
Network > Routing > PBR > Action Group
Network > Routing > PBR > Policy
CLI
get vrouter trust-vr pbr configuration
Ejemplo:
set access-list extended 1 src-ip 172.16.10.10/32 dest-ip 192.169.10.10/32

dest-port 80-80 protocol tcp entry 1
set access-list extended 1 src-port 200-300 entry 2
set access-list extended 2 dest-port 500-600 protocol udp entry 10
set access-list extended 2 dest-ip 50.50.50.0/24 protocol udp entry 20
set match-group name pbr1_mg
set match-group pbr1_mg ext-acl 1 match-entry 1
set match-group name pbr1_mg2
set match-group pbr1_mg2 ext-acl 2 match-entry 10
set action-group name pbr1_ag
set action-group pbr1_ag next-interface ethernet2 next-hop 10.10.10.2
action-entry 1
set action-group name pbr1_ag2
set action-group pbr1_ag2 next-hop 30.30.30.30 action-entry 10
set action-group pbr1_ag2 next-interface ethernet3 action-entry 20
set action-group pbr1_ag2 next-interface ethernet3 next-hop 60.60.60.60
action-entry 30
set pbr policy name pbr1_policy
set pbr policy pbr1_policy match-group pbr1_mg2 action-group pbr1_ag2 50
set pbr policy pbr1_policy match-group pbr1_mg action-group pbr1_ag 256
Ejemplo de PBR avanzado

PBR le permite definir y descargar únicamente los tipos de tráfico que ScreenOS
necesita procesar. Durante el procesamiento de tipos específicos de tráfico, como el
tráfico que necesita análisis antivirus (AV), la red no se satura porque no analiza los
tipos de paquetes que no requieren análisis en busca de virus.
150 Ejemplo de PBR avanzado

NOTA: También podría configurar PBR para enviar tráfico específico para antispam, deep
inspection (DI), prevención y detección de intrusión (IDP), filtrado de web o caché.
Puede combinar varios tipos de dispositivos de seguridad de Juniper Networks para

que trabajen conjuntamente y proporcionen los servicios al mismo tiempo que
mantienen una buena velocidad de procesamiento en la red y generan una carga de
análisis de AV aceptable. La Figura 21 muestra un dispositivo de seguridad que
ejecuta PBR para dividir el tráfico de AV de todo el otro tráfico (derecha).
Figura 21: Enrutamiento selectivo por tipo de tráfico
Tráfico TCP
Dispositivo de seguridad con PBR configurado
Analizador de AV
Las directivas de PBR envían el tráfico

de HTTP, SMTP y POP3 a un analizador
de AV.
Por ejemplo, si desea utilizar PBR para descargar únicamente el tráfico de HTTP,
SMTP y POP3 para el procesamiento de AV, por lo menos necesita utilizar un
dispositivo de seguridad con cuatro interfaces 10/100 disponibles para proporcionar
enrutamiento y un dispositivo de seguridad para proporcionar el soporte de la
aplicación (AV).
NOTA: Si únicamente tiene tres interfaces 10/100 disponibles, puede colocar un

conmutador entre los dos dispositivos de seguridad y utilizar el etiquetado VLAN
(802.1q) para configurar las mismas rutas para el tráfico.
En el siguiente ejemplo, realice los siguientes pasos para configurar el dispositivo de

seguridad que proporciona las rutas de enrutamiento:
1. Configure el enrutamiento.
2. Configure PBR.
3. Enlace las directivas de PBR a las interfaces apropiadas.
Las siguientes secciones explican cada uno de estos pasos. Los ejemplos muestran
únicamente los comandos CLI y la salida.
Para obtener más información sobre la configuración de AV, consulte el Volumen 4:

Detección ataques y mecanismos de defensa.
Ejemplo de PBR avanzado 151

Enrutamiento
En este ejemplo, necesita crear dos zonas personalizadas.
av-dmz-1 para trust-vr
av-dmz-2 para untrust-vr
Para configurar las zonas, introduzca los siguientes comandos:
set zone name av-dmz-1

set zone name av-dmz-2
Con la información que se muestra en la Tabla 15, configurará cuatro interfaces

10/100 Ethernet.
Tabla 15: Configuración de interfaz para enrutamiento
Nombre de interfaz Zona Enrutador virtual Dirección de IPv4

E1 trust trust-vr 10.251.10.0/24
E2 av-dmz-1 trust-vr 192.168.100.1/24
E3 av-dmz-2 untrust-vr 192.168.101.1/24
E4 untrust untrust-vr 172.24.76.127/24
Para configurar las interfaces, introduzca los siguientes comandos:
set interface e1 zone trust vrouter trust-vr ip 10.251.10.0/24

set interface e2 zone av-dmz-1 vrouter trust-vr ip 192.168.100.1/24
set interface e3 zone av-dmz-2 vrouter untrust-vr ip 192.168.101.1/24
set interface e4 zone untrust vrouter untrust-vr ip 172.24.76.127/24
Después de configurar las zonas, las interfaces y las rutas, necesita realizar las
siguientes dos tareas:
1. Configure una ruta estática de untrust-vr a trust-vr. Asigne una dirección IP de la

puerta de enlace de 10.251.10.0/24 y un valor de preferencia de 20 a la
entrada:
set vrouter "untrust-vr"

set route 10.251.10.0/24 vrouter "trust-vr" preference 20
exit
2. Configure la interfaz NULL con un valor de preferencia mayor que cero (0) de la
interfaz Trust a la interfaz Untrust:
set vrouter "trust-vr"

set route 0.0.0.0/0 vrouter "untrust-vr" preference 20
exit

Puede verificar los cambios con el comando get route:
Routing Table:
----------------------------------------------------------------------------
----------------------------------------------------------------------------
* 6 0.0.0.0/0 eth4 172.24.76.1 C 0 1 Root
* 3 10.251.10.0/24 n/a trust-vr S 20 0 Root
* 4 172.24.76.0/22 eth4 0.0.0.0 C 0 0 Root
* 2 192.168.101.1/32 eth3 0.0.0.0 H 0 0 Root
* 5 172.24.76.127/32 eth4 0.0.0.0 H 0 0 Root
* 1 192.168.101.0/24 eth3 0.0.0.0 C 0 0 Root

------------------------------------------------------------
------------------------------------------------------------
* 5 0.0.0.0/0 n/a untrust-vr S 20 0 Root
* 1 10.251.10.0/24 eth1 0.0.0.0 C 0 0 Root
* 4 192.168.100.1/32 eth2 0.0.0.0 H 0 0 Root
* 3 192.168.100.0/24 eth2 0.0.0.0 C 0 0 Root
* 2 10.251.10.1/32 eth1 0.0.0.0 H 0 0 Root
Ahora está listo para configurar PBR.
Elementos PBR
Después de configurar las interfaces y rutas, puede configurar PBR. Para que PBR
funcione correctamente, debe configurar los siguientes elementos para trust-vr:
Lista de acceso extendida
Grupo de coincidencias
Grupo de acciones
Directiva de PBR

Para este ejemplo, determinará que desea enviar el tráfico de HTTP (puerto 80),
SMTP (puerto 110) y POP3 (puerto 25) para el procesamiento de AV. Para enviar
estos tres tipos de paquetes a un dispositivo de seguridad, configure una lista de
acceso extendido en trust-vr.
NOTA: No necesita configurar una lista de acceso extendida para el tráfico de regreso ya
que el dispositivo de seguridad realiza una consulta de sesión antes que una
consulta de rutas y luego aplica una directiva de PBR según sea necesario. El
tráfico de retorno tiene una sesión existente.
Cuando cualquier cliente en la subred 10.251.10.0/24 inicia el tráfico que utiliza

TCP al puerto 80, 110 ó 25, desea que ScreenOS compare ese tráfico con los
criterios de lista de acceso extendida y realice la acción asociada con la lista de
acceso. La acción obliga a ScreenOS a enrutar el tráfico como usted indica, y no
como otro tráfico. Cada lista de acceso necesita tres entradas, una para cada tipo de
tráfico de TCP al que se dirige.
Ejemplo de PBR avanzado 153

Para configurar la lista de acceso extendida para trust-vr, introduzca los siguientes
comandos:
set vrouter "trust-vr"

entry 1
set access-list extended 10 src-ip 10.251.10.0/24 dest-port 110-110 protocol
tcp entry 2
entry 3
exit
Un grupo de coincidencias asocia una lista de acceso extendida con un nombre
significativo al que se hace referencia en la directiva de PBR. Primero introduzca un
contexto de enrutador virtual, luego cree un grupo de coincidencias y finalmente
agregue una entrada que asocia el nombre del grupo de coincidencias
recientemente creado con una lista de acceso y el número de entrada.
Para crear grupos de coincidencias en trust-vr, introduzca los siguientes comandos:

set match-group name av-match-trust-vr
set match-group av-match-trust-vr ext-acl 10 match-entry 1
exit
Grupos de acciones
A continuación, creará un grupo de acciones, el cual indica a donde enviar el
paquete. Para este ejemplo, creará un grupo de acciones para trust-vr con la acción
establecida para enviar el tráfico al salto siguiente.
PRECAUCIÓN: Si la acción es enviar el tráfico a la siguiente interfaz, el cambio de

estado de enlace activará/desactivará la directiva de enrutamiento.
Con el salto siguiente, la acción se resuelve con el protocolo de resolución de

dirección (ARP).
Para trust-vr, reenviará el tráfico con la instrucción de siguiente salto a través de

192.168.100.254 por medio de los siguientes comandos:

set action-group name av-action-redirect-trust-vr set action-group
av-action-redirect-trust-vr next-hop 192.168.100.254 action-entry 1
exit
Directivas de PBR
A continuación, definirá la directiva de PBR, que requiere de los siguientes
elementos:
Nombre de la directiva de PBR

Nombre del grupo de coincidencias
Nombre del grupo de acciones
Para configurar la directiva de PBR, introduzca los siguientes comandos:

set pbr policy name av-redirect-policy-trust-vr
set pbr policy av-redirect-policy-trust-vr match-group av-match-trust-vr
action-group av-action-redirect-trust-vr 1
exit
Asociación de interfaces
Finalmente, asociará la directiva de PBR a la interfaz de ingreso, e1.
Para asociar la directiva de PBR a su interfaz de ingreso, introduzca los siguientes

comandos:
set interface e1 pbr av-redirect-policy-trust-vr
PBR avanzado con alta disponibilidad y posibilidad de ampliación

Con el ejemplo anterior de PBR como base, puede mejorar la flexibilidad de su red
con alta disponibilidad (HA) o posibilidad de ampliación.
Solución de resistencia en PBR

Una solución sólida de PBR puede incluir las siguientes configuraciones de
dispositivo:
Dos dispositivos de seguridad que proporcionan red
Otros dos dispositivos de seguridad que proporcionan análisis de AV
Cada par de dispositivos ejecuta el protocolo de redundancia de NetScreen (NSRP)

en una configuración activa/pasiva para proporcionar protección de cambio en caso
de fallo. Para los dos dispositivos de seguridad que ejecutan el enrutamiento, un
dispositivo se encarga de la función de enrutamiento si ocurre un fallo del
hardware. En caso del par que proporciona el análisis de AV, si ocurre un fallo en
uno de los dispositivos, el otro dispositivo se encarga de la función de análisis.
NOTA: Para obtener más información, consulte el Volumen 11: Alta disponibilidad.
PBR avanzado con alta disponibilidad y posibilidad de ampliación 155

Solución con posibilidad de ampliación en PBR

Las soluciones PBR se amplían bien. Si necesita más capacidad, puede agregar más
dispositivos de seguridad. Al dividir la subred /24 en dos subredes /25, puede
configurar una lista de acceso extendida para la subred inferior /25 y otra lista de
acceso extendido para la subred superior /25, luego agregue dos dispositivos de
seguridad para proporcionar servicios de análisis en DMZ.
También puede implementar el equilibrio de carga si crea una configuración de

NSRP activa/activa. Un dispositivo puede procesar el tráfico de la subred inferior /25
y el otro dispositivo puede procesar el tráfico de la subred superior /25. Cada
dispositivo respalda al otro.
156 PBR avanzado con alta disponibilidad y posibilidad de ampliación

Capítulo 7
Enrutamiento multicast
Este capítulo presenta los conceptos básicos sobre el enrutamiento multicast.

Incluye las siguientes secciones:
“Direcciones multicast” en la página 158
“Reenvío por rutas inversas” en la página 158
“Enrutamiento multicast en dispositivos de seguridad” en la página 159
“Tabla de enrutamiento multicast” en la página 159
“Configuración de una ruta multicast estática” en la página 160
“Listas de acceso” en la página 161
“Configurar Encapsulado de enrutamiento genérico en interfaces de túnel”

en la página 161
“Directivas multicast” en la página 163
Vista general
Las empresas utilizan el enrutamiento multicast para transmitir tráfico, como
secuencias de datos o vídeo, desde un origen a un grupo de receptores
simultáneamente. Cualquier host puede ser un origen y los receptores pueden estar
en cualquier punto de Internet.
El enrutamiento IP multicast proporciona un método eficiente para reenviar tráfico

a múltiples hosts, porque los enrutadores habilitados para multicast transmiten
tráfico multicast solamente a los hosts que desean recibirlo. Los hosts deben indicar
su interés por recibir datos multicast y deben unirse a un grupo multicast para
recibir los datos. Los enrutadores habilitados para multicast reenvían el tráfico
multicast solamente a los receptores interesados en recibirlo.
Vista general 157

Los entornos de enrutamiento multicast requieren los siguientes elementos para

reenviar información multicast:
Un mecanismo que se ejecute entre hosts y enrutadores para comunicar la

información de miembros del grupo multicast. Los dispositivos de seguridad
admiten las versiones 1, 2 y 3 del protocolo de administración de grupo (IGMP).
Los enrutadores y hosts utilizan IGMP sólo para transmitir la información de
miembros, no para reenviar ni enrutar tráfico multicast. (Para obtener
información sobre IGMP, consulte “Protocolo de administración de grupos de
Internet” en la página 165.)
Un protocolo de enrutamiento multicast para alimentar la tabla de rutas

multicast y reenviar datos a los hosts a través de la red. Los dispositivos de
seguridad de Juniper Networks admiten multicast independiente de protocolo –
modo Sparse (PIM-SM) y multicast independiente de protocolo – modo de
origen específico (PIM-SSM). (Para obtener información sobre PIM-SM y
PIM-SSM, consulte el “Multicast independiente de protocolo” en la página 191).
Alternativamente, puede utilizar la función IGMP proxy para reenviar tráfico

multicast sin sobrecargar la CPU con la ejecución de un protocolo de
enrutamiento multicast. (Para obtener más información, consulte “Proxy de
IGMP” en la página 173).
Las siguientes secciones presentan los conceptos básicos utilizados en el

Direcciones multicast
Cuando un origen envía tráfico multicast, la dirección de destino es una dirección
del grupo multicast. Las direcciones del grupo multicast son direcciones de clase D
desde la 224.0.0.0 hasta la 239.255.255.255.
Reenvío por rutas inversas

Cuando un enrutador multicast recibe paquetes multicast, utiliza un proceso
denominado reenvío por rutas inversas (reverse path forwarding o RPF) para
comprobar la validez de los paquetes. Antes de crear una ruta multicast, el
enrutador realiza operaciones de consulta de rutas en la tabla de rutas unicast para
comprobar si la interfaz en la cual recibió el paquete (interfaz de entrada) es la
misma interfaz que debe utilizar para enviar los paquetes de vuelta al remitente. Si
lo es, el enrutador crea la entrada de la ruta multicast y reenvía el paquete al
enrutador del salto siguiente. Si no lo es, el enrutador descarta el paquete. Los
enrutadores multicast no efectúan esta comprobación de RPF para rutas estáticas.
La Figura 22 muestra el dispositivo de seguridad y el flujo de procesamiento de
paquetes multicast.
158 Vista general

Capítulo 7: Enrutamiento multicast
Figura 22: Reenvío por rutas inversas

El paquete multicast
procedente de 1.1.1.250 ethernet3
llega a ethernet1. 10.1.1.1
Origen enrutador externo ethernet1 El dispositivo de

3.3.3.6 1.1.1.250 1.1.1.1 seguridad comprueba 3a. En caso afirmativo,
si la interfaz de entrada enviar los paquetes
coincide con la de multicast al destino.
salida para los
paquetes destinados al
remitente.
Consulta en la tabla 3b. En caso negativo,

de rutas descartar el paquete.
DST IF GATE
0.0.0.0.eth1 ---
10.1.1.0 eth3 ----
1.1.1.0 eth1 ---
Enrutamiento multicast en dispositivos de seguridad

Los dispositivos de seguridad de Juniper Networks tienen dos enrutadores virtuales
predefinidos (VR): trust-vr y untrust-vr. Cada enrutador virtual es un componente de
enrutamiento independiente, con sus propias tablas de rutas unicast y multicast.
(Para obtener información sobre tablas de rutas unicast, consulte “Enrutamiento
estático” en la página 1.) Cuando el dispositivo de seguridad recibe un paquete
multicast entrante, consulta la ruta entre las rutas indicadas en la tabla de rutas
multicast.
Tabla de enrutamiento multicast

La tabla de rutas multicast se alimenta con las rutas estáticas multicast o las rutas
aprendidas a través del protocolo de enrutamiento multicast. El dispositivo de
seguridad utiliza la información de la tabla de rutas multicast para reenviar tráfico
multicast. Los dispositivos de seguridad mantienen una tabla de enrutamiento
multicast para cada protocolo de enrutamiento de un enrutador virtual.
La tabla de enrutamiento multicast contiene información específica sobre el

protocolo de enrutamiento más la información siguiente:
Cada entrada comienza con el estado de reenvío. El estado de reenvío puede

tener uno de los siguientes formatos: (*, G) o (S, G). El formato (*, G) se
denomina entrada “asterisco coma G”, donde el * se refiere a cualquier origen
y G es una dirección de grupo multicast específica. El formato (S, G) se
denomina entrada “S coma G”, donde S es la dirección IP de origen y G es la
dirección del grupo multicast.
Las interfaces de sentido ascendente y descendente.
El vecino de reenvío por rutas inversas (RPF).
Enrutamiento multicast en dispositivos de seguridad 159

A continuación se incluye un ejemplo de una tabla de enrutamiento multicast

PIM-SM en el enrutador virtual trust-vr:
trust-vr - PIM-SM routing table

-----------------------------------------------------------------------------
Register - R, Connected members - C, Pruned - P, Pending SPT Alert - G
Forward - F, Null - N , Negative Cache - E, Local Receivers - L
SPT - T, Proxy-Register - X, Imported - I, SGRpt state - Y, SSM Range Group - S
Turnaround Router - K
-----------------------------------------------------------------------------
Total PIM-SM mroutes: 2
(*, 236.1.1.1) RP 20.20.20.10 0:06:24/- Flags: LF
Zone: Untrust
Upstream : ethernet1/2 State : Joined
RPF Neighbor : local Expires : -
Downstream :
ethernet1/2 00:06:24/00:02:57 Join 0.0.0.0 FC
(20.20.20.200/24, 236.1.1.1) 00:06:24/00:00:36 Flags: TXLF Register Prune
Zone: Untrust
Proxy register : (10.10.10.1, 238.1.1.1) of zone Trust
Upstream : ethernet1/1 State : Joined
RPF Neighbor : local Expires : -
Downstream :
ethernet1/2 0:06:24/- Join 236.1.1.1 20.20.20.200 FC
Configuración de una ruta multicast estática

Puede definir una ruta multicast estática desde un origen a un grupo multicast (S, G)
o utilizar comodines tanto para el origen como para el grupo multicast, o para
ambos. Las rutas multicast estáticas se utilizan típicamente para admitir el reenvío
de datos multicast desde hosts pertenecientes a interfaces en modo “proxy de
enrutador IGMP” a los enrutadores en sentido ascendente de las interfaces en el
modo host de IGMP. (Para obtener más información, consulte “Proxy de IGMP” en
la página 173). También puede utilizar rutas multicast estáticas para permitir el
reenvío multicast entre dominios. Puede crear una ruta estática para una pareja
(S, G) con cualquier interfaz de entrada o de salida. También puede crear una ruta
estática y definir mediante comodines el origen o el grupo multicast, o ambos,
indicando 0.0.0.0. Al configurar una ruta estática, también puede especificar la
dirección del grupo multicast original y una dirección diferente para el grupo
multicast en la interfaz saliente.
En este ejemplo configurará una ruta multicast estática desde un origen con la
dirección IP 20.20.20.200 hasta el grupo multicast 238.1.1.1. Configure el
dispositivo de seguridad para traducir el grupo multicast de 238.1.1.1 a 238.2.2.1
en la interfaz saliente.
WebUI
Network > Routing > MCast Routing > New: Introduzca los siguientes datos y
haga clic en OK:
Source IP: 20.20.20.200

MGroup: 238.1.1.1
Incoming Interface: ethernet1 (seleccione)
Outgoing Interface: ethernet3(seleccione)
Translated MGroup: 238.2.2.1
160 Enrutamiento multicast en dispositivos de seguridad

CLI
set vrouter trust-vr mroute mgroup 238.1.1.1 source 20.20.20.200 iif ethernet1
oif ethernet3 out-group 238.2.2.1
save
Listas de acceso
Una lista de acceso es una lista de una secuencia de declaraciones con la que se
compara la ruta. Cada declaración especifica la dirección/máscara IP de un prefijo
de red y el estado de reenvío (acepta o rechaza la ruta). En el enrutamiento
multicast, una instrucción también puede contener una dirección de grupo
multicast. En el enrutamiento multicast, usted crea listas de acceso para permitir el
tráfico multicast a determinados grupos o hosts multicast. Por lo tanto, el estado de
la acción o del reenvío siempre es Permit. No se pueden crear listas de acceso para
denegar el acceso a determinados grupos o hosts. (Para obtener información
adicional sobre listas de acceso, consulte “Configuración de una lista de acceso” en
la página 41.)
Configurar Encapsulado de enrutamiento genérico en interfaces de túnel

El encapsulado de paquetes multicast en paquetes unicast es un método común
para transmitir paquetes multicast a través de una red no preparada para multicast
y a través de túneles IPSec. La versión 1 del protocolo de Encapsulado de
enrutamiento genérico (GRE) es un mecanismo que encapsula cualquier tipo de
paquete dentro de paquetes unicast IPv4. Los dispositivos de seguridad de Juniper
Networks admiten GREv1 para encapsular paquetes IP en paquetes unicast IPv4.
Para obtener información adicional sobre GRE, consulte RFC 1701, Encapsulado de
enrutamiento genérico (GRE).
En los dispositivos de seguridad, usted habilita la encapsulación GRE en interfaces

de túnel.
NOTA: Puede habilitar GRE en una interfaz de túnel asociada a una interfaz de bucle
invertido, siempre que la interfaz de bucle invertido se encuentre en la misma
zona que la interfaz saliente. Para obtener información sobre las interfaces de
bucle invertido, consulte “Interfaces de bucle invertido (o “loopback”)” en la
página 2-57.
Si desea transmitir paquetes multicast a través de un túnel VPN IPSec entre un

dispositivo de seguridad de Juniper Networks y un dispositivo o enrutador de otro
fabricante, debe habilitar GRE.
Los dispositivos de seguridad tienen limitaciones específicas de cada plataforma en

cuanto al número de interfaces salientes a través de las cuales se pueden transmitir
paquetes multicast. En grandes entornos de VPN radiales (“hub-and-spoke” o “cubo
y radios”), en los que el dispositivo de seguridad es el cubo, se puede evitar esta
limitación al crear un túnel GRE entre el enrutador de sentido ascendente del
dispositivo de seguridad situado en el “cubo” y los dispositivos de seguridad
situados en los radios.
Enrutamiento multicast en dispositivos de seguridad 161

En la Figura 23, el enrutador-A se encuentra en sentido ascendente con respecto al

dispositivo-A. El enrutador-A tiene dos túneles GRE que terminan en el dispositivo-1
y dispositivo-2. El dispositivo-A está conectado al dispositivo-1 y al dispositivo-2 a
través de túneles VPN. Antes de que el enrutador-A transmita paquetes multicast,
primero los encapsula en paquetes unicast IPv4. El dispositivo-A recibe estos
paquetes como paquetes unicast y los envía al dispositivo-1 y al dispositivo-2.
Figura 23: GRE en interfaces de túnel
Origen
Internet
Enrutador-A
Túneles GRE
Túneles VPN
con GRE
Dispositivo-1 Dispositivo-2
Receptores Receptores
En este ejemplo, configurará la interfaz de túnel en el dispositivo-1. Realizará los

pasos siguientes:
1. Crear la interfaz tunnel.1 y asociarla a ethernet3 y a la zona Untrust en trust-vr.
2. Habilitar la encapsulación de GRE en el tunnel.1.
3. Especificar los puntos terminales local y remoto del túnel GRE.
Este ejemplo muestra la configuración de GRE solamente para el dispositivo de

seguridad. (Para obtener información sobre las VPN, consulte el Volumen 5:
Redes privadas virtuales).
162 Enrutamiento multicast en dispositivos de seguridad

WebUI
Network > Interfaces > New Tunnel IF: Introduzca los siguientes datos, luego
haga clic en Apply:

Network > Interfaces > Tunnel (tunnel.1): Introduzca los siguientes datos,
Encap: GRE (seleccione)

Local Interface: ethernet3
CLI
set interface tunnel.1 tunnel encap gre
set interface tunnel.1 tunnel local-if ethernet3 dst-ip 3.3.3.1
save
Directivas multicast
De forma predeterminada, los dispositivos de seguridad de Juniper Networks no
permiten que el tráfico de control multicast, como mensajes IGMP o PIM, pase por
los dispositivos de seguridad. Para permitir tráfico de control multicast entre las
zonas, debe configurar una directiva multicast que especifique lo siguiente:
Origen: La zona desde la que se inicia el tráfico
Destino: La zona a la que se envía el tráfico
Grupo Multicast: El grupo multicast cuyo tráfico de control multicast desea que
el dispositivo de seguridad permita. Puede especificar uno de los siguientes:
La dirección IP del grupo multicast
Una lista de accesos que defina a los grupos multicast a los que los hosts
pueden unirse
La palabra clave any, para permitir el tráfico de control multicast para

cualquier grupo multicast
Tráfico de control multicast: El tipo de mensaje de control multicast: mensajes

IGMP o mensajes PIM. (Para obtener información sobre IGMP, consulte
“Protocolo de administración de grupos de Internet” en la página 165. Para
obtener información sobre PIM, consulte “Multicast independiente de
protocolo” en la página 191.)
Directivas multicast 163

Además, puede especificar lo siguiente:
Dirección multicast traducida: El dispositivo de seguridad puede traducir una

dirección del grupo multicast de una zona interna a una dirección distinta en la
interfaz de salida. Para traducir una dirección de grupo, debe especificar tanto
la dirección multicast original como la dirección del grupo multicast traducida
en la directiva multicast.
Bi-direccional: Puede crear una directiva bidireccional para aplicarla a ambos

sentidos del tráfico.
NOTA: Las directivas multicast solamente controlan el flujo del tráfico de control de
multicast. Para permitir el paso del tráfico de datos (tanto unicast como multicast)
entre las zonas, debe configurar directivas de cortafuegos. (Para obtener
información sobre las directivas, consulte el Volumen 2: Fundamentos).
No ordene directivas multicast como haría con las directivas de cortafuegos. De este
modo, la directiva multicast más reciente no sobrescribe ninguna anterior en caso
de conflicto. En lugar de ello, el dispositivo de seguridad selecciona la coincidencia
más larga para resolver cualquier conflicto, igual que hacen otros protocolos de
enrutamiento. Si encuentra una subred más pequeña que cumpla el criterio de
consulta, utilizará esa directiva.
NOTA: Para ver un ejemplo de configuración de una directiva multicast para mensajes
IGMP, consulte “Creación de una directiva de grupo multicast para IGMP” en la
página 178. Para ver un ejemplo de configuración de una directiva multicast para
mensajes PIM, consulte “Definición de una directiva de grupo multicast para
PIM-SM” en la página 201.
164 Directivas multicast

Capítulo 8
Protocolo de administración de grupos
de Internet
Este capítulo describe el protocolo multicast para administración de grupos de

Internet (IGMP) en dispositivos de seguridad de Juniper Networks. Incluye las
“Hosts” en la página 166
“Enrutadores multicast” en la página 167
“IGMP en dispositivos de seguridad” en la página 167
“Habilitación e inhabilitación de IGMP en interfaces” en la página 167
“Configuración de una lista de accesos para grupos aceptados” en la

página 168
“Configuración de IGMP” en la página 169
“Verificación de una configuración de IGMP” en la página 171
“Parámetros operativos de IGMP” en la página 172
“Proxy de IGMP” en la página 173
“Configuración del proxy de IGMP” en la página 176
“Configuración de un proxy de IGMP en una interfaz” en la página 176
“Directivas multicast para configuraciones de IGMP y proxy de IGMP” en la

página 178
“Configuración de un proxy de remitente de IGMP” en la página 185
165
Vista general
El protocolo multicast para administración de grupos de Internet (IGMP) se utiliza
entre hosts y enrutadores para establecer y mantener miembros de grupos
multicast en una red. Los dispositivos de seguridad admiten las siguientes versiones
de IGMP:
IGMPv1, según lo definido en la norma RFC 1112, Extensiones de host para

multicast IP, define las operaciones básicas para miembros de grupos multicast.
IGMPv2, según lo definido en la norma RFC 2236, Protocolo de administración

de grupos de Internet, versión 2, amplía la funcionalidad de IGMPv1.
IGMPv3, según lo definido en la norma RFC 3376, Protocolo de administración

de grupos de Internet, Versión 3, permite la filtración de orígenes. Los hosts que
ejecutan IGMPv3 indican a qué grupos multicast desean unirse y desde qué
orígenes esperan recibir tráfico multicast. IGMPv3 es necesario para ejecutar
multicast independiente de protocolo en modo de origen específico (PIM-SSM).
(Para obtener más información, consulte “PIM-SSM” en la página 197).
El protocolo IGMP proporciona un mecanismo para que hosts y enrutadores puedan

mantener los miembros de grupos multicast. Los protocolos de enrutamiento
multicast, como PIM, procesan la información de miembros IGMP, crean entradas
en la tabla de enrutamiento multicast y reenvían el tráfico multicast a los hosts a
través de la red.
Las secciones siguientes explican los diversos tipos de mensajes IGMP que hosts y
enrutadores intercambian para mantener actualizada la información de miembro
de grupos a través de la red. Los hosts y los enrutadores que ejecutan versiones más
recientes de IGMP pueden funcionar con los que ejecuten versiones de IGMP
anteriores.
Hosts
Los hosts envían mensajes IGMP para unirse a grupos multicast y mantenerse como
miembros en esos grupos. Los enrutadores aprenden qué hosts son miembros de
grupos multicast al escuchar estos mensajes IGMP en sus redes locales. La Tabla 16
enumera los mensajes de IGMP que los hosts envían y el destino de los mensajes.
Tabla 16: Mensajes de host IGMP
Versión de
IGMP Mensaje de IGMP Destino
IGMPv1 y v2 Un host envía un informe de miembro la primera vez que se une a un grupo Dirección IP del grupo
multicast y periódicamente, una vez que ya es miembro del grupo. El informe de multicast al que el host
miembros indica a qué grupo multicast desea unirse el host. desea unirse
IGMPv3 Un host envía un informe de miembro la primera vez que se une a un grupo 224.0.0.22
multicast y periódicamente, una vez que ya es miembro del grupo. El informe de
miembro contiene la dirección multicast del grupo, el modo de filtración, que es
incluir o excluir y una lista de orígenes. Si el modo de filtración es incluir,
entonces los paquetes procedentes de las direcciones de la lista de origen se
aceptan. Si el modo de filtración es excluir, entonces los paquetes procedentes de
orígenes distintos a los de la lista de origen se aceptan.
IGMPv2 Un host envía un mensaje Leave group cuando desea dejar el grupo multicast y “grupo de todos los
dejar de recibir datos para ese grupo. enrutadores” (224.0.0.2)
166 Vista general

Capítulo 8: Protocolo de administración de grupos de Internet
Enrutadores multicast
Los enrutadores utilizan IGMP para aprender qué grupos multicast tienen miembros
en su red local. Cada red selecciona un enrutador designado, denominado el
consultador. Generalmente, hay un consultador para cada red. El consultador envía
mensajes IGMP a todos los hosts de la red para solicitar información de miembros
de grupo. Cuando los hosts responden con sus informes de miembros, los
enrutadores toman la información de estos mensajes y actualizan su lista de
miembros de grupos basándose en cada interfaz. Los enrutadores IGMPv3
mantienen una lista que incluye la dirección del grupo multicast, el modo de
filtración (incluir o excluir) y la lista de orígenes.
NOTA: Con IGMPv1, cada protocolo de enrutamiento multicast determina el consultador

de una red. Con IGMPv2 y v3, el consultador es la interfaz de enrutador con la
dirección IP más baja de la red.
La Tabla 17 describe los mensajes que un contestador envía y los destinos.
Tabla 17: Mensajes del consultador IGMP
Versión de
IGMP Mensaje de IGMP Destino
IGMPv1, v2 y El consultador envía periódicamente consultas generales para solicitar la grupo de “todos los hosts”
v3 información de miembros de grupos. (224.0.0.1).
IGMPv2 y v3 El consultador envía una consulta específica de grupo cuando recibe un El grupo multicast del que va a
mensaje Leave Group de IGMPv2 o un informe de miembros IGMPv3 que salir el host.
indique un cambio en los miembros del grupo. Si el consultador no recibe
ninguna respuesta en un plazo especificado, asume que no hay miembros
para ese grupo en su red local y deja de reenviar el tráfico multicast a ese
grupo.
IGMPv3 El consultador envía una consulta específica de grupo y origen para El grupo multicast del que va a
verificar si hay algún receptor para ese grupo y origen específico. salir el host.
IGMP en dispositivos de seguridad

En algunos enrutadores, IGMP se habilita automáticamente cuando habilita un
protocolo de enrutamiento multicast. En los dispositivos de seguridad de
Juniper Networks, debe habilitar explícitamente IGMP y un protocolo de
Habilitación e inhabilitación de IGMP en interfaces

De forma predeterminada, IGMP está desactivado en todas las interfaces. Debe
habilitar IGMP en el modo de enrutador en todas las interfaces que estén
conectadas a hosts. En el modo de enrutador, el dispositivo de seguridad ejecuta
IGMPv2 de forma predeterminada. Puede cambiar el ajuste predeterminado y
ejecutar IGMPv1, IGMPv2 y v3 o solamente IGMPv3.
IGMP en dispositivos de seguridad 167

Habilitación de IGMP en una interfaz

En este ejemplo, habilita IGMP en modo enrutador en la interfaz ethernet1 que está
conectada con un host.
WebUI
Network > Interfaces > Edit (para ethernet1) > IGMP: Introduzca los
IGMP Mode: Router (seleccione)

Protocol IGMP: Enable (seleccione)
CLI
set interface ethernet1 protocol igmp router
set interface ethernet1 protocol igmp enable
save
Desactivación de IGMP en una interfaz

En este ejemplo, desactivará IGMP en la interfaz ethernet1. El dispositivo de
seguridad mantiene la configuración de IGMP, pero la desactiva.
WebUI
Network > Interfaces > Edit (para ethernet1) > IGMP: Clear Protocol IGMP
Enable, luego haga clic en Apply.
CLI
unset interface ethernet1 protocol igmp enable
save
Para borrar la configuración de IGMP introduzca el comando unset interface

interfaz protocol igmp router.
Configuración de una lista de accesos para grupos aceptados

Hay algunos problemas de seguridad que debe tener en cuenta al ejecutar IGMP.
Los usuarios maliciosos pueden falsificar consultas IGMP, informes de miembros y
dejar mensajes. En los dispositivos de seguridad, puede restringir el tráfico
multicast sólo a los hosts y grupos multicast conocidos. Además, también puede
especificar los consultadores permitidos en su red. Estas restricciones se establecen
por medio de la creación de listas de accesos y su aplicación a una interfaz.
Una lista de acceso es una secuencia de declaraciones que especifica una dirección
IP y un estado de reenvío (permit o deny). En IGMP, las listas de accesos siempre
deben tener un estado de reenvío permit y deben especificar uno de los siguientes:
Grupos multicast a los que los hosts se pueden unir
Hosts desde los que la interfaz del enrutador IGMP puede recibir mensajes
IGMP
Consultadores desde los que la interfaz del enrutador de IGMP puede recibir
mensajes IGMP
168 IGMP en dispositivos de seguridad

Después de crear una lista de accesos, aplíquela a una interfaz. Una vez que aplique
una lista de accesos a una interfaz, ésta aceptará tráfico solamente de los orígenes
especificados en la lista de accesos. Por lo tanto, para denegar tráfico procedente de
un determinado grupo, host o consultador multicast, simplemente exclúyalo de la
lista de accesos. (Para obtener información adicional sobre listas de accesos,
consulte “Configuración de una lista de acceso” en la página 41).
En este ejemplo, creará una lista de acceso en el trust-vr. La lista de accesos

especifica lo siguiente:
La identificación de la lista de accesos es 1.
Permitir el tráfico a un grupo multicast 224.4.4.1/32.
El número secuencial de esta declaración es 1.
Después de crear la lista de accesos, permita que los hosts de ethernet1 se unan al
grupo multicast especificado en la lista de accesos.
WebUI
Access List ID: 1

Sequence No.: 1
IP/Netmask: 224.4.4.1/32
Accept Group’s Access List ID: 1
CLI
set interface ethernet1 protocol igmp accept groups 1
save
Configuración de IGMP
Para ejecutar IGMP en un dispositivo de seguridad de Juniper Networks,
simplemente habilítelo en modo enrutador en las interfaces que están conectadas
directamente a los hosts. Para garantizar la seguridad de la red, utilice las listas de
accesos para limitar el tráfico multicast sólo a grupos, hosts y enrutadores multicast
conocidos.
En la Figura 24, los hosts de la zona Trust protegida por el dispositivo de seguridad
NS1 son receptores potenciales del flujo multicast procedente del origen en la zona
Untrust. Las interfaces ethernet1 y ethernet2 están conectadas a los hosts. El origen
multicast está transmitiendo datos al grupo multicast 224.4.4.1. Realice los pasos
siguientes para configurar IGMP en las interfaces que están conectadas a los hosts:
1. Asigne direcciones IP a las interfaces y enlácelas a zonas.
2. Cree una lista de accesos que especifique el grupo multicast 224.4.4.1/32.

3. Habilite IGMP en modo enrutador en ethernet1 y ethernet2.
4. Restrinja las interfaces (ethernet1 y ethernet2) para que reciban mensajes IGMP
del grupo multicast 224.4.4.1/32.
Figura 24: Ejemplo de configuración de IGMP

ethernet1
10.1.1.1/24
Origen
NS1
Enrutador ethernet3
designado 1.1.1.1/24
de origen ethernet 2
10.1.2.1/24
WebUI
1. Zonas e interfaces
haga clic en OK:
Zone Name: Trust

haga clic en OK:
Zone Name: Trust

haga clic en OK:
Zone Name: Untrust

2. Lista de accesos
Access List ID: 1

Sequence No.: 1
IP/Netmask: 224.4.4.1/32
Action: Permit

3. IGMP


CLI
2. Lista de accesos
set vrouter trust access-list 1 permit ip 224.4.4.1/32 1
3. IGMP
save
Después de configurar IGMP en ethernet1 y ethernet2, debe configurar un

protocolo de enrutamiento multicast, como PIM, para reenviar el tráfico multicast.
(Para obtener información sobre PIM, consulte “Multicast independiente de
protocolo” en la página 191).
Verificación de una configuración de IGMP

Para verificar la conectividad y asegurarse de que IGMP se esté ejecutando
correctamente, existe una serie de comandos exec y get que puede utilizar.
Para enviar consultas generales o específicas de grupos a una interfaz en

particular, utilice el comando exec igmp interface interfaz query. Por ejemplo,
para enviar una consulta general desde ethernet2, introduzca el siguiente
comando:
exec igmp interface ethernet2 query
Para enviar una consulta específica de grupo desde ethernet2 al grupo multicast
224.4.4.1, introduzca el siguiente comando:
exec igmp interface ethernet2 query 224.4.4.1

Para enviar un informe de miembros de una interfaz en particular, utilice el

comando exec igmp interface interfaz report. Por ejemplo, para enviar un
informe de miembro desde ethernet2, introduzca el siguiente comando:
exec igmp interface ethernet2 report 224.4.4.1
Puede revisar los parámetros IGMP de una interfaz al introducir el comando

siguiente:
device-> get igmp interface

Interface trust support IGMP version 2 router. It is enabled.
IGMP proxy is disabled.
Querier IP is 10.1.1.90, it has up 23 seconds. I am the querier.
There are 0 multicast groups active.
Inbound Router access list number: not set
Inbound Host access list number: not set
Inbound Group access list number: not set
query-interval: 125 segundos
query-max-response-time 10 seconds
leave-interval 1 seconds
last-member-query-interval 1 seconds
Este resultado enumera la siguiente información:
IGMP versión (2)
Estado del consultador (yo soy el consultador.)
Set and unset parameters
Para mostrar información sobre grupos multicast, ejecute el siguiente comando CLI:
device-> get igmp group
total groups matched: 1

multicast group interface last reporter expire ver
*224.4.4.1 trust 0.0.0.0 ------ v2
Parámetros operativos de IGMP

Cuando habilita IGMP en modo de enrutador en una interfaz, la interfaz se inicia
como consultador. Como consultador, la interfaz utiliza determinados ajustes
predeterminados que usted puede modificar. Cuando establece parámetros en este
nivel, solamente resulta afectada la interfaz que se haya especificado. La Tabla 18
enumera los parámetros de interfaz del consultador de IGMP y sus valores
predeterminados.

Tabla 18: Parámetros de la interfaz del consultador de IGMP y valores predeterminados
Parámetros de la Valor
interfaz IGMP Descripción predeterminado
General query interval El intervalo en el cual la interfaz consultadora envía consultas generales al 125 segundos
grupo de “todos los hosts” (224.0.0.1).
Maximum response El tiempo máximo entre una consulta general y la respuesta procedente del 10 segundos
time host.
Last Member Query El intervalo en el que la interfaz envía una consulta específica de grupo. Si no 1 segundo
Interval recibe ninguna respuesta después de la segunda consulta específica de grupo,
asume que no hay más miembros en ese grupo en su red local.
De forma predeterminada, un enrutador habilitado para IGMPv2/v3 solamente

acepta paquetes IGMP con la opción router-alert IP y descarta los paquetes que no
tienen esta opción. Los paquetes IGMPv1 no tienen esta opción y, por lo tanto, un
dispositivo de seguridad que ejecuta IGMPv2/v3 descarta los paquetes IGMPv1 de
forma predeterminada. Puede configurar el dispositivo de seguridad para dejar de
comprobar si los paquetes IGMP contienen la opción router-alert IP y aceptar todos
los paquetes IGMP, haciéndolo compatible con versiones anteriores de enrutadores
IGMPv1. Por ejemplo, para permitir que la interfaz ethernet1 acepte todos los
paquetes IGMP:
WebUI
Network > Interfaces > Edit (para ethernet1) > IGMP: Seleccione los
Packet Without Router Alert Option: Permit (seleccione)
CLI
set interface ethernet1 protocol igmp no-check-router-alert
save
Proxy de IGMP
Los enrutadores esperan y envían mensajes IGMP sólo a sus hosts conectados; no
reenvían mensajes IGMP más allá de su red local. Puede permitir que las interfaces
de un dispositivo de seguridad de Juniper Networks reenvíen mensajes IGMP un
salto más allá de su red local habilitando el proxy de IGMP. El proxy de IGMP
permite a las interfaces reenviar mensajes IGMP en sentido ascendente hacia el
origen sin sobrecargar la CPU con un protocolo de enrutamiento multicast.
Cuando ejecuta un proxy IGMP en un dispositivo de seguridad, las interfaces

conectadas a hosts funcionan como enrutadores y aquellas conectadas a
enrutadores en sentido ascendente funcionan como hosts. Las interfaces de host y
enrutador generalmente están en zonas diferentes. Para permitir que los mensajes
de IGMP pasen entre zonas, debe configurar una directiva multicast. Luego, para
permitir que el tráfico de datos multicast pase entre zonas, también debe configurar
una directiva de cortafuegos.
Proxy de IGMP 173

En los dispositivos que admiten múltiples sistemas virtuales, debe configurar una
interfaz en el sistema virtual raíz (vsys) y la otra interfaz en vsys separados.
A continuación, cree una directiva multicast para permitir tráfico de control
multicast entre los dos sistemas virtuales. (Para obtener más información sobre los
sistemas virtuales, consulte el Volumen 10: Sistemas virtuales.)
Mientras las interfaces reenvían información de miembros IGMP, crean entradas en

la tabla de rutas multicast del enrutador virtual al que están asociadas, formando un
árbol de distribución multicast desde los receptores hasta el origen. Las siguientes
secciones describen cómo las interfaces de hosts y enrutadores IGMP reenvían la
información de miembros de IGMP en sentido ascendente hacia el origen, y cómo
reenvían datos multicast en sentido descendente desde el origen hasta el receptor.
Informes de miembros en sentido ascendente hacia el origen

Cuando un host conectado a una interfaz de enrutador en un dispositivo de
seguridad se une a un grupo multicast, envía un informe de miembros al grupo
multicast. Cuando la interfaz del enrutador recibe el informe de miembros del host
que se acaba de conectar, comprueba si tiene una entrada para el grupo multicast.
A continuación, el dispositivo de seguridad lleva a cabo una de las acciones
siguientes:
Si la interfaz del enrutador tiene una entrada para el grupo multicast, ignora el
informe de miembros.
Si la interfaz del enrutador no tiene ninguna entrada para el grupo multicast,

comprueba si hay una directiva multicast para el grupo que especifique a qué
zona la interfaz del enrutador debe enviar el informe.
Si no hay ninguna directiva multicast para el grupo, la interfaz del

enrutador no reenvía el informe.
Si hay alguna directiva multicast para el grupo, la interfaz del enrutador

crea una entrada para el grupo multicast y reenvía el informe de miembros
a la interfaz del host proxy en la zona especificada en la directiva multicast.
Cuando una interfaz del host proxy recibe el informe de miembros, comprueba si
tiene una entrada (*, G) para ese grupo multicast.
Si tiene una entrada (*, G) para el grupo, la interfaz del host agrega la interfaz
del enrutador a la lista de las interfaces de salida para esa entrada.
Si no contiene ninguna entrada (*, G) para ese grupo, la crea; la interfaz de

entrada es la interfaz del host proxy y la interfaz de salida es la interfaz del
enrutador. A continuación, la interfaz del host proxy reenvía el informe a su
enrutador en sentido ascendente.
174 Proxy de IGMP

Datos multicast en sentido descendente a los receptores

Cuando la interfaz del host en el dispositivo de seguridad recibe datos multicast
para un grupo multicast, comprueba si hay una sesión existente para ese grupo.
Si hay una sesión para el grupo, la interfaz reenvía los datos multicast
basándose en la información de la sesión.
Si no hay sesión para el grupo, la interfaz comprueba si el grupo tiene una

entrada (S, G) en la tabla de rutas multicast.
Si hay una entrada (S, G), la interfaz reenvía los datos multicast en
consecuencia.
Si no hay ninguna entrada (S, G), la interfaz comprueba si hay alguna

entrada (*, G) para el grupo.
Si no hay ninguna entrada (*, G) para el grupo, la interfaz descarta el

paquete.
Si no hay ninguna entrada (*, G) para el grupo, la interfaz crea una entrada
(S, G). Cuando la interfaz recibe paquetes multicast subsiguientes para ese
grupo, reenvía el tráfico a la interfaz del enrutador (la interfaz de salida)
que, a su vez, reenvía el tráfico a su host conectado.
La Figura 25 muestra un ejemplo de una configuración de host proxy de IGMP.
Figura 25: Configuración del host proxy de IGMP
3. La interfaz del host proxy de IGMP comprueba si Origen 4. El origen envía datos multicast en
tiene una entrada (*, G) para el grupo multicast: sentido descendente hacia el receptor.
• En caso afirmativo, agrega la interfaz del 5. La interfaz del host proxy de IGMP
enrutador a las interfaces salientes en una Enrutador
designado comprueba si existe alguna sesión
entrada multicast de la tabla de rutas. para el grupo:
de origen
• En caso negativo, crea la entrada y reenvía el • En caso afirmativo, reenvía los datos
informe de miembros al enrutador en sentido multicast.
ascendente. Internet
• En caso negativo, compruebe si hay
alguna entrada (S, G) para el grupo:
• En caso afirmativo, reenvía los datos

Interfaz del host multicast.
2. La interfaz del enrutador proxy de IGMP Zona proxy de IGMP
comprueba si hay alguna entrada para el grupo Untrust
• En caso negativo, compruebe si hay
multicast: alguna entrada (*, G):
• En caso afirmativo, ignora el informe de • En caso negativo, descarta los
miembros. datos.
Zona
• En caso negativo y si no hay ninguna directiva Trust Interfaz del • En caso afirmativo, crea una
multicast para el grupo, descarta el informe de enrutador proxy entrada (S, G) y reenvía datos
miembros. de IGMP utilizando la interfaz de entrada y
de salida desde la entrada (*, G).
• En caso negativo, pero si existe alguna
directiva multicast para el grupo, crea una
entrada (*, G) en la tabla de rutas multicast,
con el host como iif y el enrutador como oif.
Reenvía el informe en sentido ascendente 6. La interfaz del enrutador proxy de
hacia la interfaz del host en la zona IGMP reenvía datos a los receptores.
especificada en la directiva multicast.
1. Los hosts envían informes de miembros en

sentido ascendente. Receptores
Proxy de IGMP 175

Configuración del proxy de IGMP

En esta sección se describen los pasos básicos necesarios para configurar IGMP
proxy en un dispositivo de seguridad de Juniper Networks:
1. Habilitar IGMP en el modo host en interfaces en sentido ascendente. De forma

predeterminada, el proxy de IGMP está habilitado en las interfaces de hosts.
2. Habilitar IGMP en el modo enrutador en interfaces en sentido descendente.
3. Habilitar IGMP proxy en interfaces de enrutador.
4. Configurar una directiva multicast que permita que el tráfico de control

multicast pase de una zona a otra.
5. Configurar una directiva para entregar tráfico de datos entre zonas.
Configuración de un proxy de IGMP en una interfaz

Cuando ejecute IGMP proxy en un dispositivo de seguridad, la interfaz en sentido
descendente se configura en modo enrutador y la interfaz en sentido ascendente
en modo host. (Observe que una interfaz puede estar en modo host o en modo
enrutador, pero no en ambos). Además, para que una interfaz de enrutador reenvíe
el tráfico multicast, debe ser el consultador en la red local. Para permitir que una
interfaz no consultadora reenvíe el tráfico multicast, debe especificar la palabra
clave always al habilitar IGMP en la interfaz.
De forma predeterminada, una interfaz IGMP sólo acepta los mensajes IGMP de su
propia subred. Ignora los mensajes IGMP procedentes de orígenes externos. Debe
habilitar el dispositivo de seguridad para que acepte mensajes IGMP procedentes de
orígenes de otras subredes cuando ejecute IGMP proxy.
En este ejemplo, la interfaz ethernet1 tiene la dirección IP 10.1.2.1/24 y está

conectada al enrutador en sentido ascendente. Configure lo siguiente en ethernet1:
Habilite IGMP en el modo host
Permita que acepte mensajes IGMP desde todos los orígenes, sin importar la
subred
La interfaz ethernet3 tiene la dirección IP 10.1.1.1/24 y está conectada a los hosts.

Configure lo siguiente en ethernet3:
Habilite IGMP en el modo enrutador.
Permita que reenvíe tráfico multicast aunque no sea un consultador.
Permita que acepte mensajes IGMP procedentes de orígenes de otras subredes.
176 Proxy de IGMP

WebUI
haga clic en OK:
Zone Name: Trust

Zone Name: Trust

2. IGMP
IGMP Mode: Host (seleccione)

Packet From Different Subnet: Permit (seleccione)

Proxy: (seleccione)
Always (seleccione)
CLI
2. IGMP
set interface ethernet1 protocol igmp host
set interface ethernet1 protocol igmp no-check-subnet
set interface ethernet3 protocol igmp proxy
set interface ethernet3 protocol igmp proxy always
save
Proxy de IGMP 177

Directivas multicast para configuraciones de IGMP y proxy de IGMP

Normalmente, un dispositivo de seguridad intercambia mensajes IGMP sólo con sus
hosts conectados. Con IGMP proxy, los dispositivos de seguridad podrían necesitar
enviar mensajes IGMP a un host o a un enrutador en otra zona. Para permitir el
envío de mensajes IGMP entre zonas, debe configurar una directiva multicast que lo
permita específicamente. Cuando cree una directiva multicast, debe especificar lo
siguiente:
Origen: La zona desde la que se inicia el tráfico
Destino: La zona a la que se envía el tráfico
Grupo multicast: Puede ser un grupo multicast, una lista de accesos que
especifique grupos multicast o “any”
Además, puede especificar que la directiva sea bidireccional para aplicar la directiva
a ambos sentidos del tráfico.
Creación de una directiva de grupo multicast para IGMP

En este ejemplo, la interfaz del enrutador se encuentra en la zona Trust y la interfaz
del host en la zona Untrust. Defina una directiva multicast que permita que los
mensajes IGMP para el grupo multicast 224.2.202.99/32 puedan pasar entre las
zonas Trust y Untrust. Utilice la palabra clave bidirectional para permitir el tráfico
en ambos sentidos.
WebUI
MCast Policies (From: Trust, To: Untrust) > New: Introduzca los siguientes
MGroup Address: IP/Netmask (seleccione) 224.2.202.99/32

Bidirectional: (seleccione)
IGMP Message: (seleccione)
CLI
set multicast-group-policy from trust mgroup 224.2.202.99/32 to untrust
igmp-message bi-directional
save
Creación de una configuración de proxy de IGMP

Como se indica en la Figura 26, se configura IGMP proxy en los dispositivos de
seguridad NS1 y NS2. Están interconectados a través de un túnel VPN. Realice los
pasos siguientes en los dispositivos de seguridad de ambas ubicaciones:
1. Asignar direcciones IP a las interfaces físicas asociadas a las zonas de

seguridad.
2. Crear los objetos de direcciones.
178 Proxy de IGMP

3. Habilitar IGMP en las interfaces del host y del enrutador, y habilitar IGMP proxy
en la interfaz del enrutador. (De forma predeterminada, IGMP proxy está
habilitado en las interfaces de host).
a. Especificar la palabra clave always (siempre) en ethernet1 de NS1 para

permitir que reenvíe el tráfico multicast aunque no sea consultador.
b. De forma predeterminada, una interfaz IGMP sólo acepta paquetes IGMP

de su propia subred. En el ejemplo, las interfaces están en subredes
diferentes. Cuando habilite IGMP, permita que las interfaces acepten
paquetes IGMP (consultas, informes de miembros y mensajes leave)
procedentes de cualquier subred.
4. Configurar las rutas.
5. Configurar el túnel VPN.
6. Configurar una directiva para transmitir tráfico de datos entre zonas.
7. Configurar una directiva multicast para entregar mensajes IGMP entre zonas.
En este ejemplo, restringirá el tráfico multicast a un grupo multicast
(224.4.4.1/32).
Figura 26: Configuración de IGMP proxy entre dos dispositivos
Elementos relacionados
con NSI
ethernet3
ethernet1 2.2.2.2/24
10.2.2.1/24
Enrutador Interfaz de túnel,

tunnel.1 Receptores
designado
NS1 Internet
Origen
NS2
Interfaz de túnel, ethernet1
Túnel VPN tunnel.1 10.3.1.1/24
ethernet3
3.1.1.1/24
Zona Untrust
Zona Trust
Elementos relacionados
con NS2
WebUI (NS1)
1. Interfaces
Zone Name: Trust

Seleccione los siguientes datos y haga clic en OK:
Interface Mode: NAT
Proxy de IGMP 179

haga clic en OK:
Zone Name: Untrust

clic en OK:

2. Direcciones
Address Name: branch

Zone: Untrust
3. IGMP

Network > Interfaces > Edit (para tunnel.1) > IGMP: Introduzca los siguientes

Proxy (seleccione): Always (seleccione)
4. Rutas
y haga clic en OK:

Gateway (seleccione):
Interface: tunnel.1 (seleccione)
5. VPN
y haga clic en OK.
Gateway Name: To_Branch

Preshared Key: fg2g4h5j
180 Proxy de IGMP

>> Advanced: Introduzca los siguientes ajustes avanzados y haga clic

enlace:

Phase 1 Proposal (para nivel de seguridad compatible): pre-g2-3des-sha
6. Directiva
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), branch
Address Book Entry: (seleccione), any (seleccione)
Service: any
Action: Permit
7. Directiva multicast
MCast Policies > (From: Trust, To: Untrust) > New: Introduzca los siguientes
Mgroup Address: IP/Netmask (seleccione): 224.4.4.1/32

WebUI (NS2)
1. Interfaces
haga clic en OK:
Zone Name: Trust

haga clic en OK:
Zone Name: Untrust

Network > Interfaces > New Tunnel IF: Introduzca los siguientes datos, luego
haga clic en Apply:

2. Direcciones
Address Name: mgroup1

Zone: Trust
Proxy de IGMP 181

Address Name: source-dr

Zone: Untrust
3. IGMP

Proxy (seleccione): Always (seleccione)
Network > Interfaces > Edit (para tunnel.1) > IGMP: Introduzca los siguientes

4. Rutas
Network > Routing > Routing Entries > New (trust-vr): Introduzca los

Gateway (seleccione):
Interface: tunnel.1 (seleccione)
5. VPN
y haga clic en OK:
Gateway Name: To_Corp

Preshared Key: fg2g4hvj

enlace:

Phase 1 Proposal (para nivel de seguridad compatible): pre-g2-3des-sha
182 Proxy de IGMP

6. Directiva
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), source-dr
Address Book Entry: (seleccione), mgroup1
Service: ANY
Action: Permit
MCast Policies > (From: Untrust, To: Trust) > New: Introduzca los siguientes
Mgroup Address: IP/Netmask (seleccione): 224.4.4.1/32

CLI (NS1)
1. Interfaces
Set interface ethernet1 zone trust
2. Direcciones
set address untrust branch1 10.3.1.0/24
3. IGMP
set interface ethernet1 protocol igmp host
set interface tunnel.1 protocol igmp router
set interface tunnel.1 protocol igmp proxy
set interface tunnel.1 protocol igmp proxy always
set interface tunnel.1 protocol igmp enable
set interface tunnel.1 protocol igmp no-check-subnet
4. Rutas
5. Túnel VPN
set ike gateway To_Branch address 3.1.1.1 main outgoing-interface ethernet3
preshare fg2g4h5j proposal pre-g2-3des-sha
set vpn Corp_Branch gateway To_Branch sec-level compatible
set vpn Corp_Branch bind interface tunnel.1
set vpn Corp_Branch proxy-id local-ip 10.2.2.0/24 remote-ip 10.3.1.0/24 any
6. Directivas
set policy name To_Branch from untrust to trust branch1 any any permit
Proxy de IGMP 183

7. Directivas multicast
set multicast-group-policy from trust mgroup 224.4.4.1/32 to untrust
save
CLI (NS2)
1. Interfaces
Set interface ethernet1 zone trust
2. Direcciones
set address trust mgroup1 224.4.4.1/32
set address untrust source-dr 10.2.2.1/24
3. IGMP
set interface ethernet1 protocol igmp proxy
set interface ethernet1 protocol igmp proxy always
set interface tunnel.1 protocol igmp host
set interface tunnel.1 protocol igmp enable
set interface tunnel.1 protocol igmp no-check-subnet
4. Rutas
5. Túnel VPN
set ike gateway To_Corp address 2.2.2.2 main outgoing-interface ethernet3
preshare fg2g4hvj proposal pre-g2-3des-sha
set vpn Branch_Corp gateway To_Corp sec-level compatible
set vpn Branch_Corp bind interface tunnel.1
set vpn Branch_Corp proxy-id local-ip 10.3.1.0/24 remote-ip 10.2.2.0/24 any
6. Directiva
set policy from untrust to trust source-dr mgroup1 any permit
set multicast-group-policy from untrust mgroup 224.4.4.1/32 to trust
save
184 Proxy de IGMP

Configuración de un proxy de remitente de IGMP

En IGMP proxy, el tráfico multicast generalmente viaja en sentido descendente
desde la interfaz del host a la interfaz del enrutador. En determinadas situaciones,
el origen puede estar en la misma red que la interfaz del enrutador. Cuando un
origen se conecta a una interfaz que se encuentra en la misma red a la que la
interfaz del proxy del enrutador IGMP envía tráfico multicast, el dispositivo de

Volumen 1: Vista General: Conceptos Y Ejemplos Manual de Referencia de Screenos

Uploaded by

Copyright:

Available Formats

You might also like

Volumen 1: Vista General: Conceptos Y Ejemplos Manual de Referencia de Screenos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Volumen 1: Vista General: Conceptos Y Ejemplos Manual de Referencia de Screenos

Uploaded by

Copyright:

Available Formats

Conceptos y ejemplos

Manual de referencia de ScreenOS

Release 6.0.0, Rev. 02

Juniper Networks, Inc.

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

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

Capítulo 1 Arquitectura de ScreenOS 1

Seguimiento de direcciones IP.................................................................62

Capítulo 4 Modos de las interfaces 79

Capítulo 5 Bloques para la construcción de directivas 103

Servicios varios ...............................................................................122

Capítulo 6 Directivas 161

Deep Inspection ..............................................................................171

Capítulo 7 Asignación de tráfico 195

Capítulo 8 Parámetros del sistema 219

Establecimiento de DDNS para un servidor DDO ............................224

Ajuste de las direcciones IP de administración para múltiples

Capítulo 2 Supervisión de dispositivos de seguridad 59

Capítulo 1 Protección de una red 1

Capítulo 2 Bloqueo de reconocimiento 7

Sondeos del sistema operativo ....................................................................... 12

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

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

Análisis de protocolos de aplicación ........................................................ 72

Capítulo 5 Deep Inspection 119

Actualización manual ......................................................................130

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

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

Creación de una norma de exclusión desde el visualizador de

Capítulo 7 Atributos de los paquetes sospechosos 243

Opciones IP incorrectas ...............................................................................245

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

Capítulo 1 Seguridad del protocolo de Internet 1

Capítulo 2 Criptografía de claves públicas 19

Configuración de ajustes de CRL.............................................................. 29

Capítulo 3 Directrices para las redes privadas virtuales 49

Capítulo 4 Redes privadas virtuales de punto a punto 81

Capítulo 5 Redes privadas virtuales de acceso telefónico 163

VPN de acceso telefónico basada en rutas, interlocutor dinámico .........170

Capítulo 6 Protocolo de encapsulamiento de la capa 2 211

Capítulo 7 Funciones avanzadas de redes privadas virtuales 239

Detección de interlocutor muerto....................................................304

Capítulo 8 Redes privadas virtuales de AutoConnect 331

Capítulo 1 Puerta de enlace en la capa de aplicación H.323 1

Capítulo 2 Puerta de enlace de la capa de aplicación del protocolo de inicio

Ejemplo: Tiempos de espera por inactividad de señalización o de

Capítulo 3 Puerta de enlace en la capa de aplicación de protocolo de control

Capítulo 4 Puerta de enlace en la capa de aplicación del protocolo Skinny de

Cliente del SCCP ............................................................................... 85

Capítulo 1 Enrutamiento estático 1

Capítulo 3 Abrir primero la ruta más corta 47

Asignación de interfaces a un área OSPF................................................. 55

Capítulo 4 Protocolo de información de enrutamiento 79

Protección contra inundaciones............................................................... 94

Capítulo 5 Protocolo de puertas de enlace de límite 109

Capítulo 6 Enrutamiento basado en directivas 139

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.

Cortafuegos: Un cortafuegos analiza el tráfico que atraviesa el límite entre una

Seguridad en capas: La solución de seguridad en capas se implementa en

Seguridad de contenido: Protege a los usuarios de URL maliciosas y

Funciones de red integradas: Los protocolos de enrutamiento dinámico

Administración centralizada: La herramienta Netscreen-Security Manager

Redundancia: Alta disponibilidad de interfaces, rutas de encaminamiento,

“Contenido” incluye un índice global de todos los volúmenes del manual.

“Índice maestro” es un índice de todos los volúmenes en el manual.

Capítulo 1, “Arquitectura de ScreenOS,” describe los elementos fundamentales

Capítulo 3, “Interfaces,” describe las diferentes interfaces físicas, lógicas y

Capítulo 4, “Modos de las interfaces,” explica los conceptos relacionados con

Capítulo 5, “Bloques para la construcción de directivas,” explica los elementos

Capítulo 6, “Directivas,” examina los componentes y las funciones de las

Capítulo 7, “Asignación de tráfico,” se explica cómo gestionar el ancho de

Capítulo 8, “Parámetros del sistema,” se describen los conceptos relacionados

Organización de los volúmenes xlix