Manual SSG 140

Conceptos y ejemplos
Manual de Referencia de ScreenOS
Volumen 1:
Vista general
Versión 5.3.0, Rev. B
Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Número de pieza: 093-1659-000-SP, Revisión B
Copyright Notice
Copyright © 2005 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 Network’s 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 xxxiii
Organización del volumen ......................................................................... xxxv
Convenciones del documento ........................................................................ xli
Convenciones de la interfaz de línea de comandos (CLI) ......................... xli
Convenciones para las ilustraciones ....................................................... xlii
Convenciones de nomenclatura y conjuntos de caracteres .................... xliii
Convenciones de la interfaz gráfica (WebUI) ......................................... xliv
Documentación de Juniper Networks ............................................................ xlv
Apéndice A Glosario A-I
Índice ........................................................................................................................IX-I
Volumen 2:
Fundamentos
Acerca de este volumen ix
Convenciones del documento .......................................................................... x
Convenciones de la interfaz de línea de comandos (CLI) ........................... x
Convenciones para las ilustraciones ......................................................... xi
Convenciones de nomenclatura y conjuntos de caracteres ...................... xii
Convenciones de la interfaz gráfica (WebUI) .......................................... xiii
Documentación de Juniper Networks ............................................................ xiv
Capítulo 1 Arquitectura de ScreenOS 1

Zonas de seguridad .......................................................................................... 2
Interfaces de zonas de seguridad ..................................................................... 3
Interfaces físicas ........................................................................................ 3
Subinterfaces............................................................................................. 4
Enrutadores virtuales ....................................................................................... 4
Directivas......................................................................................................... 5
Redes privadas virtuales................................................................................... 7
Sistemas virtuales .......................................................................................... 10
Secuencia de flujo de paquetes ...................................................................... 11
Ejemplo: (Parte 1) Empresa con seis zonas.............................................. 14
Ejemplo: (Parte 2) Interfaces para seis zonas........................................... 16
Ejemplo: (Parte 3) Dos dominios de enrutamiento .................................. 18
Ejemplo: (Parte 4) Directivas ................................................................... 20
Contenido iii
Concepts & Examples ScreenOS Reference Guide
Capítulo 2 Zonas 25
Visualizar las zonas preconfiguradas .............................................................. 26
Zonas de seguridad ........................................................................................ 28
Zona Global ............................................................................................. 28
Opciones SCREEN ................................................................................... 28
Enlazar una interfaz de túnel a una zona de túnel.......................................... 28
Configurar zonas de seguridad y zonas de túnel ............................................ 30
Crear una zona ........................................................................................ 30
Modificar una zona.................................................................................. 31
Eliminar una zona ................................................................................... 32
Zonas de función ........................................................................................... 32
Zona Null................................................................................................. 32
Zona MGT................................................................................................ 32
Zona HA .................................................................................................. 33
Zona de registro propio (Self) .................................................................. 33
Zona VLAN ..............................................................................................33
Modos de puerto ............................................................................................ 33
Modo Trust-Untrust.................................................................................. 34
Modo Home-Work ................................................................................... 35
Modo Dual Untrust .................................................................................. 36
Modo combinado (Combined) .................................................................37
Modo Trust/Untrust/DMZ (extendido) ...................................................... 38
Modo DMZ/Dual Untrust .......................................................................... 38
Modo Dual DMZ ...................................................................................... 39
Ajustar los modos de puertos ......................................................................... 40
Ejemplo: Modo de puerto Home-Work.............................................. 40
Zonas en los modos “Home-Work” y “Combined Port” ................................. 41
Ejemplo: Zonas Home-Work ............................................................. 42
Capítulo 3 Interfaces 45
Tipos de interfaces......................................................................................... 45
Interfaces de la zona de seguridad........................................................... 45
Interfaces físicas ............................................................................... 45
Subinterfaces .................................................................................... 46
Interfaces agregadas ......................................................................... 46
Interfaces redundantes...................................................................... 46
Interfaces de seguridad virtuales ....................................................... 47
Interfaces de zonas de función ................................................................ 47
Interfaces de administración ............................................................. 47
Interfaces de alta disponibilidad........................................................ 47
Interfaces de túnel................................................................................... 48
Eliminar interfaces de túnel .............................................................. 51
Visualizar interfaces ....................................................................................... 52
Configurar interfaces de la zona de seguridad................................................ 53
Asociar una interfaz a una zona de seguridad.......................................... 54
Desasociar una interfaz de una zona de seguridad .................................. 54
Direccionar una interfaz de la zona de seguridad L3 ............................... 54
Direcciones IP públicas ..................................................................... 55
Direcciones IP privadas..................................................................... 56
Direccionar una interfaz.................................................................... 56
Modificar los ajustes de la interfaz........................................................... 56
Crear una subinterfaz en el sistema raíz .................................................. 57
Eliminar una subinterfaz ......................................................................... 58
iv Contenido
Contenido
Crear una dirección IP secundaria.................................................................. 59

Interfaces de bucle invertido (loopback)......................................................... 60
Crear una interfaz de bucle invertido....................................................... 60
Ajustar la interfaz de bucle invertido para administración .......................61
Ajustar BGP en una interfaz de bucle invertido ........................................ 61
Ajustar VSI en una interfaz de bucle invertido ......................................... 62
Ajustar la interfaz de bucle invertido como interfaz de origen ................. 62
Cambios de estado de la interfaz ................................................................... 62
Supervisar la conexión física ................................................................... 64
Dar seguimiento a direcciones IP ............................................................ 65
Supervisar interfaces ............................................................................... 70
Supervisar dos interfaces .................................................................. 71
Supervisar un bucle de interfaz ......................................................... 72
Supervisar zonas de seguridad.................................................................75
Interfaces inactivas y flujo de tráfico ....................................................... 75
Fallo en la interfaz de salida.............................................................. 76
Fallo en la interfaz de entrada........................................................... 78
Capítulo 4 Modos de las interfaces 81

Modo transparente......................................................................................... 82
Ajustes de zona ....................................................................................... 83
Zona VLAN........................................................................................ 83
Zonas de capa 2 predefinidas............................................................ 83
Reenviar tráfico ....................................................................................... 83
Opciones “unicast” desconocidas ............................................................ 84
Método de inundación ...................................................................... 85
Método ARP/Trace-Route .................................................................. 86
Configurar la interfaz VLAN1 para administración ............................ 89
Configurar el modo transparente ...................................................... 91
Modo NAT...................................................................................................... 94
Tráfico NAT entrante y saliente ............................................................... 96
Ajustes de interfaz ................................................................................... 97
Configurar el modo NAT .......................................................................... 97
Modo de ruta ...............................................................................................100
Ajustes de interfaz .................................................................................101
Configurar el modo de ruta....................................................................101
Capítulo 5 Bloques para la construcción de directivas 105

Direcciones ..................................................................................................106
Entradas de direcciones.........................................................................106
Modificar una dirección...................................................................107
Eliminar una dirección ....................................................................108
Grupos de direcciones ...........................................................................108
Editar una entrada de grupo de direcciones ....................................110
Eliminar un miembro y un grupo ....................................................110
Servicios ......................................................................................................111
Servicios predefinidos............................................................................111
Protocolo de mensajes de control de Internet .................................112
Servicios de llamadas de procedimiento remoto de Microsoft.........117
Protocolos de enrutamiento dinámico.............................................119
Vídeo de secuencia .........................................................................119
Servicios de llamadas de procedimiento remoto de Sun .................120
Servicios de túnel y seguridad .........................................................121
Contenido v
Servicios relacionados con IP ..........................................................121

Servicios de administración ............................................................122
Servicios de correo..........................................................................123
Servicios varios ...............................................................................124
Servicios personalizados........................................................................125
Agregar un servicio personalizado...................................................126
Modificar un servicio personalizado ................................................126
Eliminar un servicio personalizado..................................................127
Establecer el tiempo de espera de un servicio .......................................127
Buscar y configurar el tiempo de espera de servicio........................127
Ejemplo...........................................................................................130
Definir un servicio de protocolo de mensaje de control de Internet
personalizado..................................................................................130
Puerta de enlace “Remote Shell” en la capa de aplicación ....................131
Puerta de enlace de llamada de procedimiento remoto de Sun en la
capa de aplicación...........................................................................131
Situación típica de llamadas RPC ....................................................131
Personalizar los servicios Sun RPC ..................................................132
Personalizar la puerta de enlace de la capa de aplicaciones del
procedimiento de llamadas remotas de Microsoft ...........................133
Puerta de enlace de la capa de aplicación del protocolo
de secuencias en tiempo real ..........................................................134
Métodos de petición RTSP...............................................................135
Códigos de estado de RTSP .............................................................137
Configurar un servidor de medios en un dominio público...............140
Grupos de servicios................................................................................142
Modificar un grupo de servicios ......................................................143
Eliminar un grupo de servicios ........................................................144
Conjuntos de IP dinámicas...........................................................................144
Traducción de direcciones de puertos....................................................145
Crear un conjunto de DIP con PAT ........................................................146
Modificar un conjunto de DIP ................................................................147
Direcciones DIP “sticky”........................................................................147
Usar DIP en otra subred ........................................................................148
Utilizar una DIP en una interfaz de bucle invertido................................153
Crear un grupo de DIP ...........................................................................157
Configurar una programación recurrente .....................................................160
Capítulo 6 Directivas 163

Elementos básicos .......................................................................................164
Tres tipos de directivas ................................................................................165
Directivas interzonales ..........................................................................165
Directivas intrazonales ..........................................................................165
Directivas globales.................................................................................166
Listas de conjuntos de directivas ..................................................................167
Definición de directivas................................................................................168
Directivas y reglas .................................................................................168
Anatomía de una directiva.....................................................................169
ID....................................................................................................170
Zonas ..............................................................................................170
Direcciones .....................................................................................170
Servicios .........................................................................................170
Nombre...........................................................................................172
Encapsulamiento VPN.....................................................................172
vi Contenido
Contenido
Encapsulamiento L2TP....................................................................173
Deep Inspection ..............................................................................173
Colocación al principio de la lista de directivas ...............................173
Traducción de direcciones de origen ...............................................174
Traducción de direcciones de destino .............................................174
Autenticación de usuarios ...............................................................174
Respaldo HA de la sesión ................................................................176
Filtrado de Web ..............................................................................176
Registro...........................................................................................176
Recuento.........................................................................................177
Umbral de alarma de tráfico ...........................................................177
Tareas programadas........................................................................177
Análisis antivirus .............................................................................177
Asignación de tráfico.......................................................................178
Directivas aplicadas .....................................................................................179
Visualizar directivas ...............................................................................179
Crear directivas .....................................................................................179
Crear servicio de correo de directivas interzonales .........................179
Crear un conjunto de directivas interzonales...................................183
Crear directivas intrazonales ...........................................................187
Crear una directiva global ...............................................................189
Entrar al contexto de una directiva........................................................190
Varios elementos por componente de directiva .....................................190
Ajustar la denegación de direcciones .....................................................191
Modificar y desactivar directivas............................................................194
Verificar directivas.................................................................................194
Reordenar directivas..............................................................................195
Eliminar una directiva ...........................................................................196
Capítulo 7 Asignar tráfico 197

Administrar el ancho de banda a nivel de directivas ....................................197
Ajustar la asignación de tráfico ....................................................................198
Ajustar las prioridades del servicio ...............................................................202
Ajustar las colas de prioridades ....................................................................203
Directivas de entrada ...................................................................................206
Asignar tráfico en interfaces virtuales ..........................................................207
Asignar el tráfico a nivel de interfaz.......................................................207
Asignar el tráfico a nivel de directiva .....................................................209
Flujo de paquetes ..................................................................................210
Ejemplo: VPN basada en rutas con directivas de entrada ......................210
Ejemplo: VPN basada en directivas con directivas de entrada ...............214
Asignar tráfico utilizando una interfaz de bucle invertido.............................217
Asignación y marcado DSCP ........................................................................218
Capítulo 8 Parámetros del sistema 221

Compatibilidad con DNS ..............................................................................221
Consulta DNS ........................................................................................222
Tabla de estado de DNS.........................................................................223
Ajustar el servidor DNS y programar actualizaciones ......................224
Establecer un intervalo de actualización de DNS .............................224
Sistema de nombres de dominio dinámico............................................224
Configurar el DDNS para un servidor DynDNS ................................225
Configurar DDNS para un servidor DDO .........................................226
Dividir direcciones DNS del proxy .........................................................227
Contenido vii
Protocolo de configuración dinámica de hosts .............................................229

Configurar un servidor DHCP ................................................................230
Personalizar opciones de servidor DHCP.........................................234
Colocar el servidor DHCP en un clúster de NSRP ............................236
Detectar el servidor DHCP ..............................................................236
Activar la detección del servidor DHCP ...........................................236
Desactivar la detección del servidor DHCP......................................237
Asignar un dispositivo de seguridad como agente de retransmisión
de DHCP .........................................................................................237
Utilizar un dispositivo de seguridad como cliente DHCP........................241
Propagar ajustes TCP/IP.........................................................................243
Protocolo punto a punto sobre Ethernet.......................................................245
Configurar PPPoE ..................................................................................246
Configurar PPPoE en las interfaces principal y de respaldo de la
zona Untrust ...................................................................................249
Configurar múltiples sesiones de PPPoE a través de una sola interfaz ...250
PPPoE y alta disponibilidad ...................................................................252
Claves de licencia.........................................................................................253
Registrar y activar los servicios de suscripción .............................................254
Servicio de prueba.................................................................................254
Actualizar claves de suscripción.............................................................255
Agregar antivirus, filtrado web, antispam y DI a un dispositivo .............255
Reloj del sistema ..........................................................................................256
Fecha y hora..........................................................................................256
Huso horario..........................................................................................256
Protocolo de hora de la red....................................................................257
Configurar múltiples servidores NTP ...............................................257
Configurar un servidor de respaldo del protocolo de hora
de la red ...................................................................................257
Desfase temporal máximo ..............................................................258
Protocolos NTP y NSRP ...................................................................259
Ajustar un valor de desfase horario máximo en un servidor NTP ....259
Asegurar los servidores NTP............................................................260
Índice ........................................................................................................................IX-I
Volumen 3:
Administración
Acerca de este volumen vii
Convenciones del documento ........................................................................ vii
Convenciones CLI ................................................................................... viii
Convenciones para las ilustraciones ......................................................... ix
Convenciones de nomenclatura y conjuntos de caracteres ........................ x
Convenciones de la interfaz gráfica (WebUI) ............................................ xi
Documentación de Juniper Networks ............................................................. xii
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
Desvío de WebUI a la nueva ubicación de la ayuda............................. 3
Protocolo de transferencia de hipertexto ................................................... 3
Identificación de sesión ............................................................................. 4
viii Contenido
Contenido
Secure Sockets Layer ................................................................................. 5

Configurar SSL .................................................................................... 7
Reenviar HTTP a SSL........................................................................... 8
Administración a través de la interfaz de línea de comandos........................... 9
Telnet ........................................................................................................ 9
Asegurar las conexiones Telnet ............................................................... 10
Secure Shell ............................................................................................. 11
Configuración básica de SSH en el dispositivo................................... 12
Autenticación .................................................................................... 14
SSH y Vsys ........................................................................................ 16
Clave del host.................................................................................... 16
Ejemplo: SSHv1 con PKA para inicios de sesión de automatizados ... 17
Secure Copy ............................................................................................ 18
Consola serie ........................................................................................... 19
Puerto de módem.................................................................................... 20
Administración a través de NetScreen-Security Manager................................ 20
Iniciar la conectividad entre el agente de NSM y el sistema MGT............. 21
Habilitar, inhabilitar y desactivar el agente de NSM ................................. 22
Ajustar la dirección IP del servidor principal del sistema
de administración ............................................................................. 23
Ajustar la generación de informes de alarmas y de estadísticas............... 23
Sincronizar la configuración .................................................................... 24
Ejemplo: Visualización del estado de la configuración.......................25
Ejemplo: Consulta del hash de la configuración ................................ 25
Consultar la marca de hora de configuración........................................... 26
Controlar el tráfico administrativo.................................................................. 26
Interfaces MGT y VLAN1.......................................................................... 27
Ejemplo: Administración a través de la interfaz MGT ........................ 27
Ejemplo: Administración a través de la interfaz VLAN1..................... 28
Ajustar las opciones de la interfaz administrativa .................................... 28
Ajustar las direcciones IP de administración para múltiples interfaces .... 29
Niveles de administración .............................................................................. 31
Administrador raíz................................................................................... 32
Administrador de lectura/escritura........................................................... 32
Administrador de sólo lectura.................................................................. 32
Administrador de sistema virtual............................................................. 33
Administrador de sólo lectura del sistema virtual .................................... 33
Definir usuarios con permisos de administrador ............................................ 33
Ejemplo: Adición de un administrador de sólo lectura ............................. 33
Ejemplo: Modificación de un administrador ............................................ 34
Ejemplo: Eliminación de un administrador.............................................. 34
Ejemplo: Configuración de las cuentas de administrador para las
conexiones de acceso telefónico ....................................................... 34
Ejemplo: Borrado de una sesión de administrador .................................. 35
Asegurar el tráfico administrativo .................................................................. 36
Cambiar el número de puerto.................................................................. 37
Cambiar nombre y contraseña de inicio de sesión del administrador...... 37
Ejemplo: Cambio de su propia contraseña ........................................ 39
Restablecer el dispositivo con los ajustes predeterminados de fábrica..... 40
Restringir el acceso administrativo .......................................................... 41
Ejemplo: Restricción de la administración a una sola estación
de trabajo ................................................................................... 41
Restringir el acceso del administrador raíz desde la consola ............. 41
Túneles de VPN para tráfico administrativo ............................................. 42
Contenido ix
Administración a través de un túnel VPN de clave manual

basado en rutas .......................................................................... 43
Administración a través de un túnel VPN de clave manual
basado en directivas ................................................................... 47
Capítulo 2 Supervisar dispositivos de seguridad 53

Almacenar la información del registro ........................................................... 53
Registro de eventos........................................................................................ 54
Ver el registro de eventos según nivel de gravedad y palabra clave ......... 55
Clasificar y filtrar el registro de eventos ................................................... 56
Descargar el registro de eventos.............................................................. 57
Ejemplo: Descarga del registro de eventos completo ........................ 57
Registro de tráfico.......................................................................................... 58
Visualizar el registro de tráfico.................................................................59
Ejemplo: Visualización de las entradas del registro de tráfico............ 59
Clasificar y filtrar el registro de tráfico............................................... 60
Ejemplo: Clasificación del registro de tráfico por horas ..................... 60
Descargar el registro de tráfico ................................................................ 61
Registro propio ..............................................................................................61
Visualizar el registro propio ..................................................................... 62
Clasificar y filtrar el registro propio ................................................... 62
Ejemplo: Filtro del registro propio por horas ..................................... 63
Descargar el registro propio..................................................................... 63
Descargar el registro de recuperación de equipos .......................................... 63
Alarmas de tráfico.......................................................................................... 64
Ejemplo: Detección de intrusiones basada en directivas.......................... 65
Ejemplo: Notificación de sistema en peligro ............................................ 65
Ejemplo: Envío de alertas de correo electrónico ...................................... 66
Syslog ............................................................................................................ 67
Ejemplo: Habilitación de múltiples servidores Syslog............................... 68
Habilitar WebTrends para eventos de notificación................................... 68
Protocolo simple de administración de redes................................................. 69
Vista general de la implementación ......................................................... 71
Definir una comunidad SNMP de lectura/escritura................................... 72
Túneles VPN para tráfico administrativo autogenerado.................................. 73
Ejemplo: Tráfico autogenerado a través de túnel basado en rutas ........... 75
Ejemplo: Tráfico autogenerado a través de túnel basado en directivas .... 82
Visualizar contadores de pantalla ................................................................... 88
Apéndice A Archivos MIB para SNMP A-I

Carpetas de archivos MIB del nivel principal ............................................... A-II
Carpetas de archivos MIB del segundo nivel ............................................... A-IV
netscreenProducts ................................................................................ A-IV
netScreenIds......................................................................................... A-IV
netscreenVpn ....................................................................................... A-IV
netscreenQos ....................................................................................... A-IV
netscreenSetting.................................................................................... A-V
netscreenZone....................................................................................... A-V
netscreenPolicy ..................................................................................... A-V
netscreenNAT ........................................................................................ A-V
netscreenAddr ....................................................................................... A-V
netscreenService ................................................................................... A-V
netscreenSchedule................................................................................ A-VI
x Contenido
Contenido
netscreenVsys ...................................................................................... A-VI

netscreenResource ............................................................................... A-VI
netscreenIp........................................................................................... A-VI
netscreenVR ......................................................................................... A-VI
Índice ........................................................................................................................IX-I
Volumen 4:
Mecanismos de detección y defensa de ataques
Convenciones del documento ....................................................................... viii
Convenciones de la interfaz de línea de comandos (CLI) ........................ viii
Convenciones para las ilustraciones .......................................................... x
Convenciones de nomenclatura y conjuntos de caracteres ....................... xi
Convenciones de la interfaz gráfica (WebUI) ........................................... xii
Documentación de Juniper Networks ............................................................ xiii
Capítulo 1 Protección de una red 1

Etapas de un ataque......................................................................................... 2
Mecanismos de detección y defensa ................................................................ 2
Supervisar explotaciones de vulnerabilidades .................................................. 5
Ejemplo: Supervisión de ataques desde la zona Untrust ...................... 5
Capítulo 2 Disuasión de reconocimiento 6

Barrido de direcciones IP ................................................................................. 7
Análisis de puertos........................................................................................... 8
Reconocimiento de red mediante opciones IP ................................................. 9
Sondeo del sistema operativo ........................................................................ 11
Flags SYN y FIN activados ....................................................................... 11
Flag FIN sin flag ACK ............................................................................... 12
Encabezado TCP sin flags activados ........................................................ 13
Técnicas de evasión ....................................................................................... 14
Análisis FIN ............................................................................................. 14
Flags no SYN ........................................................................................... 15
Simulación de IP...................................................................................... 18
Ejemplo: Protección contra simulación de IP en la capa 3................. 20
Opciones IP de ruta de origen .................................................................24
Capítulo 3 Defensas contra los ataques de denegación de servicio (DoS) 32

Ataques de DoS contra el cortafuegos ............................................................ 33
Inundación de la tabla de sesiones .......................................................... 33
Límites de sesiones basadas en sus orígenes y destinos.................... 33
Ejemplo: Limitación de sesiones según su origen.............................. 35
Ejemplo: Limitación de sesiones según su destino ............................ 35
Envejecimiento agresivo ................................................................... 36
Ejemplo: Forzar el envejecimiento agresivo de sesiones ................... 37
Inundación proxy SYN-ACK-ACK ............................................................. 38
Ataques DoS contra la red.............................................................................. 40
Inundación SYN....................................................................................... 40
Cookie SYN..............................................................................................50
Contenido xi
Inundación ICMP ..................................................................................... 52

Inundación UDP ...................................................................................... 53
Ataque terrestre (“Land Attack”).............................................................. 54
Ataques de DoS específicos de cada sistema operativo .................................. 55
“Ping of Death” ....................................................................................... 55
Ataque “Teardrop” .................................................................................. 56
WinNuke ................................................................................................. 57
Capítulo 4 Supervisión y filtrado de contenidos 59

Reensamblar fragmentos ............................................................................... 60
Protección contra URL maliciosas............................................................ 60
Puerta de enlace en la capa de aplicación................................................ 61
Ejemplo: Bloqueo de URL maliciosas en paquetes fragmentados ...... 62
Análisis antivirus ............................................................................................ 63
Analizar el tráfico de FTP......................................................................... 64
Analizar el tráfico de HTTP ...................................................................... 65
Extensiones MIME de HTTP .............................................................. 66
Correo web HTTP.............................................................................. 67
Analizar el tráfico de IMAP y POP3.......................................................... 68
Analizar el tráfico de SMTP...................................................................... 69
Actualizar el archivo de patrón de AV ...................................................... 71
Ejemplo: Actualización automática....................................................73
Ejemplo: Actualización manual ......................................................... 73
Protección contra Spyware y Phishing..................................................... 74
Análisis AV basado en directivas.............................................................. 75
Ajustes globales del analizador de AV ...................................................... 76
Asignar recursos de AV ..................................................................... 76
Comportamiento en modo de fallo ................................................... 76
Máximo de mensajes y tamaño máximo del contenido .................... 77
HTTP Keep-Alive (mantenimiento de conexión)................................ 77
Goteo HTTP....................................................................................... 78
Ajustes de perfiles del analizador de AV .................................................. 79
Iniciar un perfil de AV ....................................................................... 80
Ejemplo: Análisis de todos los tipos de tráfico................................... 80
Ejemplo: Análisis de AV únicamente para el tráfico SMTP y HTTP .... 81
Ajustes de perfiles de AV................................................................... 81
Filtrado anti-spam .......................................................................................... 84
Listas blancas y listas negras ................................................................... 85
Configuración básica ............................................................................... 85
Filtrar tráfico Spam ........................................................................... 86
Descartar mensajes de spam ............................................................ 86
Definir una lista negra ............................................................................. 86
Definir una lista blanca............................................................................ 87
Definir una acción predeterminada ......................................................... 87
Definir una lista de bloqueo de spam ...................................................... 88
Filtrado de Web ............................................................................................. 88
Filtrado de Web integrado ....................................................................... 88
Ejemplo: Activación del filtrado de Web............................................ 90
Ejemplo: Categoría de URL................................................................ 91
Ejemplo: Perfil de filtrado de Web..................................................... 93
Servidores de SurfControl .................................................................96
Caché de filtrado de Web .................................................................. 96
Ejemplo: Parámetros de caché .......................................................... 97
Redirigir el filtrado de Web...................................................................... 97
xii Contenido
Contenido
Compatibilidad con sistemas virtuales .............................................. 99

Configurar el redireccionamiento de filtrado de Web ........................ 99
Ejemplo: Configuración del filtrado de Web ....................................102
Capítulo 5 Deep Inspection 105

Vista general ................................................................................................106
Servidor de la base de datos de objetos de ataque .......................................110
Paquetes de firmas predefinidos............................................................110
Actualizar paquetes de firmas................................................................111
Antes de empezar las descargas......................................................112
Ejemplo: Actualización inmediata ...................................................113
Ejemplo: Actualizaciones automáticas.............................................114
Ejemplo: Notificación automática y actualización inmediata ...........115
Ejemplo: Actualización manual .......................................................116
Objetos de ataque y grupos..........................................................................118
Protocolos admitidos .............................................................................120
Firmas completas ..................................................................................124
Firmas de secuencias TCP .....................................................................125
Anomalías en el protocolo .....................................................................125
Grupos de objetos de ataque..................................................................126
Cambiar los niveles de gravedad.....................................................126
Ejemplo: Deep Inspection para P2P ................................................127
Desactivar objetos de ataque .................................................................129
Acciones de ataque ......................................................................................130
Ejemplo: Acciones de ataque – Close Server, Close, Close Client.....131
Acciones de ataques de fuerza bruta .....................................................137
Objetos de ataques de fuerza bruta .................................................138
Objetivos de ataques de fuerza bruta ..............................................138
Tiempo de espera de ataques de fuerza bruta .................................139
Ejemplo 1........................................................................................139
Ejemplo 2........................................................................................140
Ejemplo 3........................................................................................140
Registrar ataques .........................................................................................140
Ejemplo: Inhabilitación del registro por grupo de ataque ................140
Asignar servicios personalizados a aplicaciones ...........................................142
Ejemplo: Asignación de una aplicación a un
servicio personalizado ..............................................................143
Ejemplo: Asignación de aplicaciones a servicios
para ataques HTTP ...................................................................145
Objetos de ataque y grupos personalizados .................................................146
Objetos de ataque de firma completa definidos por el usuario ..............146
Expresiones regulares .....................................................................147
Ejemplo: Objetos de ataque de firma completa definidos
por el usuario ...........................................................................148
Objetos de ataque de la firma de las secuencias TCP.............................151
Ejemplo: Objeto de ataque de firma de secuencia definido
por el usuario ...........................................................................152
Parámetros configurables de anomalías de protocolos ..........................153
Ejemplo: Modificar parámetros .......................................................153
Negación......................................................................................................154
Ejemplo: Negación de objeto de ataque ..........................................154
Contenido xiii
Bloqueo granular de los componentes de HTTP ...........................................159

Controles ActiveX ..................................................................................160
Applets de Java ......................................................................................160
Archivos EXE.........................................................................................160
Archivos ZIP ..........................................................................................161
Capítulo 6 Atributos de los paquetes sospechosos 163

Fragmentos ICMP ........................................................................................164
Paquetes ICMP grandes................................................................................165
Opciones IP incorrectas ...............................................................................166
Protocolos desconocidos ..............................................................................167
Fragmentos de paquetes IP..........................................................................168
Fragmentos SYN ..........................................................................................169
Apéndice A Contextos para las firmas definidas por el usuario A-I
Índice ........................................................................................................................IX-I
Volumen 5:
Redes privadas virtuales
Capítulo 1 Seguridad del protocolo de Internet 1

Introducción a las redes privadas virtuales (VPN) ............................................. 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
Administrar 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............................................................... 10
Fase 2...................................................................................................... 11
Confidencialidad directa perfecta ...................................................... 12
Protección antirreprocesamiento ...................................................... 12
Paquetes IKE e IPSec ..................................................................................... 12
Paquetes IKE ........................................................................................... 13
Paquetes IPSec ........................................................................................ 16
xiv Contenido
Contenido
Capítulo 2 Criptografía de claves públicas 19

Introducción a la criptografía de claves públicas ............................................ 20
Firmar un certificado ............................................................................... 20
Verificar una firma digital ........................................................................ 20
Infraestructura de claves públicas .................................................................. 22
Certificados y CRL.......................................................................................... 24
Petición manual de un certificado ........................................................... 26
Cargar certificados y listas de revocación de certificados......................... 28
Configurar ajustes de CRL........................................................................ 29
Obtención automática de un certificado local .......................................... 30
Renovación automática de certificado ..................................................... 34
Generar pares de claves........................................................................... 34
Protocolo OCSP..............................................................................................35
Especificar un método de comprobación de revocación de certificados .. 36
Visualizar los atributos de comprobación de estado ................................ 36
Especificar un URL del servidor de respuesta del protocolo OCSP ........... 36
Eliminar atributos de comprobación de estado........................................ 37
Certificados autofirmados .............................................................................. 37
Validar certificados .................................................................................. 38
Crear manualmente certificados autofirmados ........................................ 39
Establecer un certificado autofirmado y definido por el administrador.... 40
Autogenerar certificados.......................................................................... 44
Eliminar certificados autofirmados .......................................................... 45
Capítulo 3 Directivas de red privada virtual 47

Opciones criptográficas.................................................................................. 48
Opciones criptográficas punto a punto ....................................................48
Opciones VPN de acceso telefónico ......................................................... 56
Túneles basados en directivas y en rutas ....................................................... 63
Flujo de paquetes: VPN punto a punto ........................................................... 64
Directrices para la configuración de un túnel ................................................. 70
Consideraciones de seguridad en VPN basadas en rutas ................................ 72
Ruta nula ................................................................................................. 73
Línea de acceso telefónico o arrendada ................................................... 75
Conmutación por error de la VPN hacia la línea arrendada o la
ruta nula ........................................................................................... 75
Interfaz de túnel ficticia ........................................................................... 78
Enrutador virtual para interfaces de túnel................................................ 79
Reencaminar a otro túnel ........................................................................ 79
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, AutoKey IKE............................ 97
VPN punto a punto basada en rutas, interlocutor dinámico ...................103
VPN punto a punto basada en directivas, interlocutor dinámico............111
VPN punto a punto basada en rutas, clave manual ................................120
VPN punto a punto basada en directivas, clave manual.........................126
Puertas de enlace IKE dinámicas con FQDN ................................................131
Alias ......................................................................................................132
Ajuste del interlocutor AutoKey IKE con FQDN......................................132
Puntos VPN con direcciones superpuestas ...................................................141
VPN en modo transparente..........................................................................152
Contenido xv
Capítulo 5 Redes privadas virtuales de acceso telefónico 159

Acceso telefónico .........................................................................................160
VPN de acceso telefónico basada en directivas, AutoKey IKE ................160
VPN de acceso telefónico basada en rutas, interlocutor dinámico .........166
VPN de acceso telefónico basada en directivas, interlocutor dinámico ..173
Directivas bidireccionales para usuarios de VPN de acceso telefónico ...178
Identificación IKE de grupo ..........................................................................183
Identificación IKE de grupo con certificados ..........................................183
Tipos de identificación IKE ASN1-DN Wildcard y Container ..................185
Creación de una identificación IKE de grupo (certificados) ....................188
Configuración de una ID IKE de grupo con claves previamente
compartidas ....................................................................................192
Identificación IKE compartida ......................................................................198
Capítulo 6 Protocolo de encapsulamiento de la capa 2 (L2TP) 205

Introducción al L2TP ....................................................................................205
Encapsular y desencapsular paquetes ..........................................................208
Encapsular.............................................................................................208
Desencapsular .......................................................................................209
Ajuste de los parámetros L2TP .....................................................................211
L2TP y L2TP sobre IPSec..............................................................................213
Configurar L2TP ....................................................................................213
Configurar L2TP sobre IPSec .................................................................218
L2TP bidireccional sobre IPSec ..............................................................225
Capítulo 7 Funciones avanzadas de redes privadas virtuales 231

NAT-Traversal ..............................................................................................232
Sondeos de NAT ....................................................................................233
Atravesar un dispositivo NAT.................................................................235
Suma de comprobación de UDP ............................................................237
Paquetes de mantenimiento de conexión..............................................238
Simetría iniciador/respondedor .............................................................238
Habilitación de NAT-Traversal ...............................................................239
Supervisión de VPN......................................................................................240
Opciones de reencriptación y optimización ...........................................241
Interfaz de origen y dirección de destino...............................................242
Consideraciones sobre directivas...........................................................243
Configuración de la función de supervisión de VPN...............................244
Objetos y capturas SNMP para la supervisión de VPN............................252
Múltiples túneles por interfaz de túnel .........................................................254
Asignación de rutas a túneles ................................................................255
Direcciones de interlocutores remotos...................................................256
Entradas de tabla manuales y automáticas ............................................257
Entradas manuales en la tabla ........................................................257
Entradas automáticas en la tabla.....................................................257
Ajustar una VPN en una interfaz de túnel para subredes
superpuestas ............................................................................259
Asociar entradas automáticas en la tabla de rutas y en
la tabla NHTB ...........................................................................278
Puertas de enlace VPN redundantes.............................................................290
Grupos VPN ...........................................................................................291
Mecanismos de supervisión...................................................................292
Detección de interlocutor muerto (DPD) .........................................293
Procedimiento de recuperación IKE ................................................295
xvi Contenido
Contenido
Comprobar flag TCP SYN.......................................................................296

Crear puertas de enlace VPN redundantes ......................................297
Crear VPN adosadas.....................................................................................303
Crear VPN radiales .......................................................................................310
Índice ........................................................................................................................IX-I
Volumen 6:
Voz sobre protocolo de Internet (VoIP)
Acerca de este volumen v
Convenciones del documento .......................................................................... v
Convenciones de la interfaz de línea de comandos (CLI) .......................... vi
Convenciones para las ilustraciones ........................................................ vii
Convenciones de nomenclatura y conjuntos de caracteres ..................... viii
Convenciones de la interfaz gráfica (WebUI) ............................................ ix
Documentación de Juniper Networks ............................................................... x
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 ....................................................... 4
Ejemplo: Llamadas entrantes con NAT ......................................................7
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
ALG: puerta de enlace en la capa de aplicación ....................................... 17
SDP ......................................................................................................... 18
Crear ojos de aguja .................................................................................. 19
Tiempo de espera por inactividad de la sesión ........................................ 21
Protección contra ataques SIP .................................................................22
Ejemplo: SIP Protect Deny ................................................................ 22
Ejemplo: Protección contra inundaciones UDP ................................. 23
SIP con traducción de direcciones de red (NAT) ............................................. 24
Llamadas salientes................................................................................... 25
Llamadas entrantes ................................................................................. 25
Llamadas reenviadas ............................................................................... 26
Terminar la llamada ................................................................................ 26
Mensajes de llamada Re-INVITE .............................................................. 26
Temporizadores de sesiones de llamadas ................................................ 26
Cancelar la llamada ................................................................................. 27
Bifurcación ..............................................................................................27
Mensajes SIP ........................................................................................... 27
Encabezados SIP ..................................................................................... 27
Cuerpo SIP............................................................................................... 29
Supuesto de NAT con el protocolo SIP ..................................................... 30
Contenido xvii
Ejemplos ........................................................................................................ 32
Admisión de llamadas SIP entrantes utilizando el registrador SIP............ 33
Ejemplo: Llamada entrante (DIP de interfaz)..................................... 34
Ejemplo: Llamada entrante (conjunto de DIP) ................................... 37
Ejemplo: Llamada entrante con MIP ................................................. 39
Ejemplo: Proxy en la zona privada....................................................41
Ejemplo: Proxy en la zona pública ....................................................43
Ejemplo: Untrust intrazonal .............................................................. 49
Ejemplo: Trust intrazonal .................................................................. 53
Ejemplo: VPN de malla completa para SIP ........................................ 55
Administrar el ancho de banda para servicios de VoIP ............................ 60
Capítulo 3 Puerta de enlace en la capa de aplicación del Protocolo

de control de la puerta de medios 63
Vista general .................................................................................................. 63
Seguridad de MGCP........................................................................................ 64
Protocolo MGCP ............................................................................................. 64
Entidades en MGCP ................................................................................. 64
Punto final ........................................................................................ 65
Conexión .......................................................................................... 65
Llamada ............................................................................................ 65
Agente de llamada ............................................................................ 65
Comandos ............................................................................................... 66
Códigos de respuesta............................................................................... 69
Ejemplos ........................................................................................................ 70
Puerta de enlace en el domicilio de los abonados: agente
de llamada en el ISP.......................................................................... 70
Servicio alojado en el ISP......................................................................... 73
Índice ........................................................................................................................IX-I
Volumen 7:
Enrutamiento
Convenciones del documento ......................................................................... ix
Capítulo 1 Enrutamiento estático 1

Vista general .................................................................................................... 2
Cómo funciona el enrutamiento estático ................................................... 2
Cuándo configurar rutas estáticas .............................................................. 3
Configurar rutas estáticas .......................................................................... 5
Ajustar rutas estáticas ......................................................................... 5
Establecer una ruta estática para una interfaz de túnel ....................... 8
Habilitar el seguimiento de las puertas de enlace ...................................... 9
xviii Contenido
Contenido
Reenviar tráfico a la interfaz nula................................................................... 10

Impedir búsqueda 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
Impedir la creación de bucles por las rutas resumidas............................. 11
Rutas permanentemente activas .................................................................... 11
Cambiar la preferencia de enrutamiento con rutas múltiples 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 ............................................. 17
Tabla de enrutamiento basada en la interfaz de origen ........................... 20
Crear y modificar enrutadores virtuales ......................................................... 22
Modificar enrutadores virtuales ............................................................... 22
Asignar una ID del enrutador virtual ........................................................ 23
Reenviar tráfico entre enrutadores virtuales ............................................ 23
Configurar dos enrutadores virtuales ....................................................... 24
Crear y eliminar enrutadores virtuales..................................................... 26
Crear un enrutador virtual personalizado .......................................... 27
Eliminar un enrutador virtual personalizado ..................................... 27
Enrutadores virtuales y sistemas virtuales ............................................... 27
Crear un enrutador virtual en un Vsys............................................... 28
Compartir rutas entre enrutadores virtuales...................................... 29
Limitar el número máximo de entradas de la tabla de enrutamiento ...... 30
Ejemplos y características del enrutamiento .................................................. 31
Seleccionar rutas ..................................................................................... 31
Establecer una preferencia de ruta ....................................................31
Métricas de ruta ................................................................................ 32
Cambiar la secuencia predeterminada de consulta de rutas .............. 33
Consultar rutas en múltiples enrutadores virtuales ............................ 36
Configurar el enrutamiento de rutas múltiples de igual coste................... 37
Redistribuir rutas ..................................................................................... 39
Configurar un mapa de rutas............................................................. 40
Filtrar rutas ....................................................................................... 42
Configurar una lista de acceso........................................................... 42
Redistribuir rutas en OSPF ................................................................ 43
Exportar e importar rutas entre enrutadores virtuales ............................. 44
Configurar una regla de exportación ................................................. 45
Configurar la exportación automática ............................................... 46
Capítulo 3 Protocolo OSPF 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
Contenido xix
Crear y eliminar una instancia de enrutamiento de OSPF........................ 53

Crear una instancia de OSPF............................................................. 53
Eliminar una instancia de OSPF ........................................................ 53
Crear y eliminar un área OSPF ................................................................ 54
Crear un área OSPF........................................................................... 54
Eliminar un área OSPF...................................................................... 55
Asignar interfaces a un área OSPF........................................................... 55
Asignar interfaces a áreas .................................................................55
Configurar un rango de áreas............................................................ 56
Habilitar OSPF en interfaces .................................................................... 56
Habilitar OSPF en interfaces ............................................................. 56
Inhabilitar OSPF en una interfaz ....................................................... 57
Comprobar la configuración .................................................................... 58
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
Notificar la ruta predeterminada.............................................................. 62
Conexiones virtuales ............................................................................... 63
Crear una conexión virtual ................................................................ 63
Crear una conexión virtual automática.............................................. 65
Ajustar parámetros de interfaz OSPF ............................................................. 65
Configuración de seguridad............................................................................ 67
Autenticar vecinos ................................................................................... 67
Configurar una contraseña de texto no cifrado ................................. 68
Configurar una contraseña MD5 ....................................................... 68
Configurar una lista de vecinos de OSPF ................................................. 68
Rechazar rutas predeterminadas ............................................................. 69
Proteger contra inundaciones .................................................................. 70
Configurar un límite de saludo .......................................................... 70
Configurar un límite de LSAs............................................................. 70
Habilitar la inundación reducida ....................................................... 71
Crear un circuito de demanda OSPF en una interfaz de túnel ........................ 71
Interfaz de túnel punto a multipunto.............................................................. 72
Establecer el tipo de conexión OSPF ....................................................... 72
Inhabilitar la restricción Route-Deny........................................................ 72
Crear 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
Crear y eliminar una instancia RIP .......................................................... 82
Crear una instancia RIP..................................................................... 82
Eliminar una instancia RIP ................................................................ 82
Habilitar y deshabilitar RIP en interfaces ................................................. 83
Habilitar RIP en una interfaz ............................................................. 83
Inhabilitación de RIP en una interfaz ................................................ 83
Visualizar la información de RIP .................................................................... 85
Visualizar la base de datos RIP ................................................................ 85
Visualizar los detalles de RIP ................................................................... 86
Visualizar información de vecino RIP ...................................................... 87
Visualizar detalles de RIP para una interfaz específica ............................. 88
Parámetros globales de RIP............................................................................ 89
xx Contenido
Contenido
Notificar la ruta predeterminada .................................................................... 90

Configurar los parámetros de interfaz de RIP................................................. 91
Autenticar vecinos mediante una contraseña .......................................... 92
Configurar vecinos fiables........................................................................ 93
Habilitar RIP en interfaces de túnel ................................................... 95
Configuraciones opcionales de RIP ................................................................ 97
Configurar la versión de RIP .................................................................... 97
Habilitar y deshabilitar un resumen de prefijo ......................................... 99
Habilitar un resumen de prefijo......................................................... 99
Ajustar rutas alternas.............................................................................100
Circuitos de demanda en interfaces de túnel .........................................101
Configurar un vecino estático ................................................................103
Configurar una interfaz de túnel punto a multipunto....................................103
Capítulo 5 Protocolo BGP 109

Vista general ................................................................................................110
Tipos de mensajes BGP..........................................................................110
Atributos de ruta....................................................................................111
BGP externo e interno ...........................................................................111
Configuración básica de BGP........................................................................112
Crear y habilitar una instancia de BGP...................................................113
Crear una instancia BGP..................................................................113
Habilitar y deshabilitar BGP en interfaces ..............................................114
Habilitar BGP en interfaces .............................................................114
Inhabilitar BGP en interfaces...........................................................114
Configurar grupos de interlocutores e interlocutores BGP ......................115
Configurar un interlocutor BGP .......................................................116
Configurar un grupo de interlocutores IBGP ....................................117
Comprobar la configuración BGP...........................................................118
Configuración de seguridad..........................................................................119
Autenticar vecinos BGP..........................................................................120
Rechazar rutas predeterminadas ...........................................................120
Configuraciones opcionales de BGP .............................................................121
Redistribuir rutas en BGP.......................................................................122
Configurar una lista de acceso AS-Path ..................................................123
Agregar rutas a BGP...............................................................................124
Notificar ruta condicional ................................................................124
Establecer el peso de la ruta............................................................125
Establecer atributos de ruta.............................................................125
Capacidad de enrutamiento-actualización .............................................126
Solicitar una actualización de la tabla de enrutamiento entrante.....127
Solicitar una actualización de la tabla de enrutamiento saliente ......127
Configuración de la reflexión de rutas ...................................................127
Configurar una confederación ...............................................................130
Comunidades BGP .................................................................................131
Agregar rutas .........................................................................................132
Agregar rutas con diferentes AS-Paths.............................................132
Suprimir las rutas más específicas en actualizaciones .....................133
Seleccionar rutas para el atributo Path ............................................134
Cambiar atributos de una ruta agregada .........................................135
Contenido xxi
Capítulo 6 Enrutamiento multicast 137

Vista general ................................................................................................137
Direcciones multicast ............................................................................138
Reenviar rutas inversas .........................................................................138
Enrutamiento multicast en dispositivos de seguridad...................................139
Tabla de enrutamiento multicast ...........................................................139
Configurar una ruta multicast estática ...................................................140
Listas de acceso .....................................................................................141
Configurar el encapsulado genérico de enrutamiento
en interfaces de túnel......................................................................141
Directivas multicast......................................................................................143
Capítulo 7 Protocolo IGMP 145

Vista general ................................................................................................146
Hosts .....................................................................................................147
Enrutadores multicast............................................................................148
IGMP en dispositivos de seguridad ...............................................................149
Habilitar y deshabilitar IGMP en interfaces ............................................149
Habilitar IGMP en una interfaz ........................................................149
Configurar una lista de accesos para grupos aceptados .........................150
Configurar IGMP ....................................................................................151
Verificar una configuración de IGMP......................................................153
Parámetros operativos de IGMP.............................................................154
Proxy de IGMP .............................................................................................155
Informes de miembros en sentido ascendente hacia el origen ..............156
Datos multicast en sentido descendente a los receptores ......................157
Configurar el proxy de IGMP .................................................................158
Configurar un proxy de IGMP en una interfaz........................................158
Directivas Multicast para configuraciones de IGMP y proxy de IGMP.....160
Crear una directiva de grupo multicast para IGMP ..........................160
Crear una configuración de proxy de IGMP .....................................160
Configurar un proxy del remitente de IGMP ..........................................167
Capítulo 8 Multicast independiente de protocolo (PIM) 173

Vista general ................................................................................................175
PIM-SM ..................................................................................................176
Árboles de distribución multicast ....................................................176
Enrutador designado.......................................................................177
Asignar puntos de encuentro a grupos ............................................177
Reenviar tráfico a través del árbol de distribución...........................178
PIM-SSM ................................................................................................180
Configuración de PIM-SM en dispositivos de seguridad ................................180
Habilitar y eliminar una instancia PIM-SM en un enrutador virtual (VR).181
Habilitar de una instancia PIM-SM...................................................181
Eliminar una instancia PIM-SM........................................................181
Habilitar y deshabilitar PIM-SM en interfaces.........................................182
Habilitar PIM-SM en una interfaz.....................................................182
Inhabilitar PIM-SM en una interfaz ..................................................182
Directivas de grupo multicast ................................................................182
Mensajes Static-RP-BSR...................................................................183
Mensajes Join-Prune........................................................................183
Definir de una directiva de grupo multicast para PIM-SM................183
Ajustar una configuración de PIM-SM básica ................................................184
xxii Contenido
Contenido
Comprobar la configuración.........................................................................189
Configurar puntos de encuentro...................................................................191
Configurar de un punto de encuentro estático .......................................191
Configurar de un punto de encuentro candidato....................................192
Consideraciones sobre seguridad .................................................................193
Restringir grupos multicast ....................................................................193
Restringir orígenes multicast .................................................................194
Restringir puntos de encuentro..............................................................195
Parámetros de la interfaz PIM-SM ................................................................196
Definir una directiva de vecindad ..........................................................196
Definir un borde bootstrap ....................................................................197
Configurar de un punto de encuentro del proxy...........................................198
PIM-SM e IGMPv3 ........................................................................................207
Índice ........................................................................................................................IX-I
Volumen 8:
Traducción de direcciones
Capítulo 1 Traducción de direcciones 1

Introducción a la traducción de direcciones ..................................................... 1
Traducir direcciones de red de origen........................................................ 1
Traducir direcciones de red de destino ......................................................3
Dirección IP asignada.......................................................................... 7
IP virtual ............................................................................................. 7
Opciones de la traducción basada en directivas ............................................... 8
Ejemplo: NAT-Src desde un conjunto DIP con PAT .................................... 8
Ejemplo: NAT-Src desde un conjunto DIP sin PAT ..................................... 9
Ejemplo: NAT-Src desde un conjunto DIP con desplazamiento de
direcciones.......................................................................................... 9
Ejemplo: NAT-Src desde la dirección IP de la interfaz de salida ............... 10
Ejemplo: NAT-Dst a una dirección IP única con asignación de puerto...... 10
Ejemplo: NAT-Dst a una dirección IP única sin asignación de puerto....... 10
Ejemplo: NAT-Dst desde un rango de direcciones IP a una sola
dirección IP....................................................................................... 11
Ejemplo: NAT-Dst entre rangos de direcciones IP .................................... 11
Naturaleza direccional de NAT-Src y NAT-Dst ................................................ 12
Capítulo 2 Traducción de direcciones de red de origen 15

Introducción a NAT-Src .................................................................................. 15
NAT-Src desde un rango DIP con PAT habilitada............................................ 17
Ejemplo: NAT-Src con PAT habilitada ...................................................... 17
NAT-Src desde un rango DIP con PAT inhabilitada......................................... 20
Ejemplo: NAT-Src con PAT inhabilitada ................................................... 20
Contenido xxiii
NAT-Src desde un conjunto de DIP con desplazamiento de direcciones......... 22

Ejemplo: NAT-Src con desplazamiento de direcciones............................. 23
NAT-Src desde la dirección IP de la interfaz de salida .................................... 26
Ejemplo: NAT-Src sin DIP ........................................................................ 26
Capítulo 3 Traducción de direcciones de red de destino 29

Introducción a NAT-Dst.................................................................................. 30
Flujo de paquetes para NAT-Dst............................................................... 31
Enrutamiento para NAT-Dst..................................................................... 34
Ejemplo: Direcciones conectadas a una interfaz................................ 35
Ejemplo: Direcciones separadas por una interfaz .............................. 36
NAT-Dst— Asignación de “1:1” ...................................................................... 37
Ejemplo: Traducción de destinos “1:1”....................................................38
Traducción de una dirección a múltiples direcciones............................... 40
Ejemplo: Traducción de destinos “1:n” ............................................. 40
NAT-Dst—Asignación de “n:1”....................................................................... 43
Ejemplo: Traducción de destinos “n:1”....................................................43
NAT-Dst— Asignación de “n:n”...................................................................... 46
Ejemplo: Traducción de destinos “n:n”....................................................47
NAT-Dst con asignación de puertos................................................................ 49
Ejemplo: NAT-Dst con asignación de puertos .......................................... 49
NAT-Src y NAT-Dst en la misma directiva ...................................................... 52
Ejemplo: NAT-Src y NAT-Dst combinadas................................................ 52
Capítulo 4 Direcciones virtuales y asignadas 65

Direcciones IP asignadas................................................................................ 65
MIP y la zona Global ................................................................................ 66
Ejemplo: MIP en una interfaz de la zona Untrust............................... 67
MIP-Same-as-Untrust ............................................................................... 73
Ejemplo: MIP en la interfaz Untrust................................................... 74
MIP y la interfaz de bucle invertido (loopback) ........................................ 76
Ejemplo: MIP para dos interfaces de túnel ........................................ 76
Agrupamiento de MIP.............................................................................. 82
Ejemplo: Agrupamiento de MIP con directivas de celdas múltiples ... 82
Direcciones IP virtuales.................................................................................. 83
VIP y la zona Global................................................................................. 85
Ejemplo: Configuración de servidores de IP virtuales ........................ 85
Ejemplo: Edición de una configuración de VIP .................................. 87
Ejemplo: Eliminación de una configuración VIP ................................ 87
Índice ........................................................................................................................IX-I
Volumen 9:
Autenticación de usuarios
xxiv Contenido
Contenido
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
Personalizar mensajes de bienvenida............................................................. 11
Ejemplo: Personalización de un mensaje de bienvenida de WebAuth ..... 11
Capítulo 2 Servidores de autenticación 13

Tipos de servidores de autenticación ............................................................. 13
Base de datos local......................................................................................... 16
Ejemplo: Tiempo de espera de la base de datos local .............................. 17
Servidores de autenticación externos............................................................. 17
Propiedades del objeto “servidor de autenticación”................................. 19
Servicio de autenticación remota de usuarios de acceso telefónico.......... 21
Propiedades del objeto servidor de autenticación RADIUS ................ 21
Características y tipos de usuarios admitidos .................................... 22
Archivo de diccionario de ScreenOS.................................................. 22
Contabilidad de RADIUS ................................................................... 25
SecurID ............................................................................................. 27
Propiedades del objeto servidor de autenticación SecurID ................ 28
Protocolo ligero de acceso a directorios................................................... 29
Propiedades del objeto servidor de autenticación LDAP.................... 29
Definir objetos de servidor de autenticación .................................................. 30
Ejemplo: Servidor de autenticación RADIUS ............................................ 30
Ejemplo: Servidor de autenticación LDAP................................................ 34
Definir servidores de autenticación predeterminados .................................... 36
Ejemplo: Cambio de los servidores de autenticación predeterminados.... 36
Capítulo 3 Usuarios de autenticación 39

Referencias a usuarios autenticados en directivas .......................................... 40
Autenticación en tiempo de ejecución ..................................................... 40
Autenticación de comprobación previa a la directiva (WebAuth) ............. 41
Referencias a grupos de usuarios de autenticación en directivas.................... 42
Ejemplo: Autenticación en tiempo de ejecución (usuario local)................ 43
Ejemplo: Autenticación en tiempo de ejecución
(grupo de usuarios locales) ................................................................ 45
Ejemplo: Autenticación en tiempo de ejecución (usuario externo) ........... 47
Ejemplo: Autenticación en tiempo de ejecución
(grupo de usuarios externo) .............................................................. 49
Ejemplo: Usuario de autenticación local en múltiples grupos................... 51
Ejemplo: WebAuth (grupo de usuarios local)............................................ 54
Ejemplo: WebAuth (grupo de usuarios externo)....................................... 55
Ejemplo: WebAuth + SSL sólo (grupo de usuarios externo) .................... 57
Contenido xxv
Capítulo 4 Usuarios IKE, XAuth y L2TP 61

Usuarios y grupos de usuarios IKE .................................................................61
Ejemplo: Definición de usuarios IKE ........................................................ 62
Ejemplo: Creación de un grupo de usuarios IKE ...................................... 64
Referencias a usuarios IKE en puertas de enlace ..................................... 64
Usuarios y grupos de usuarios XAuth ............................................................. 64
Usuarios XAuth en negociaciones IKE ..................................................... 66
Ejemplo: Autenticación XAuth (usuario local) .................................... 68
Ejemplo: Autenticación XAuth (usuario externo) ............................... 71
Cliente XAuth .......................................................................................... 81
Ejemplo: Dispositivo de seguridad como cliente XAuth..................... 81
Usuarios y grupos de usuarios L2TP ............................................................... 82
Ejemplo: Servidores de autenticación L2TP locales y externos ................ 82
Índice ........................................................................................................................IX-I
Volumen 10:
Sistemas virtuales
Capítulo 1 Sistemas virtuales 1

Vista general .................................................................................................... 1
Objetos Vsys .................................................................................................... 3
Crear un objeto Vsys y administrador........................................................ 3
Establecer un enrutador virtual predeterminado para Vsys ....................... 5
Enlazar las zonas a un enrutador virtual compartido ................................. 5
Iniciar sesión como administrador Vsys........................................................... 6
Capítulo 2 Clasificar el tráfico 9

Vista general .................................................................................................... 9
Clasificar el tráfico ..................................................................................... 9
Clasificar el tráfico de tránsito .................................................................10
Interfaces compartidas y dedicadas......................................................... 14
Interfaces dedicadas ......................................................................... 14
Interfaces compartidas...................................................................... 15
Importar y exportar interfaces físicas............................................................. 17
Importar una interfaz física a un sistema virtual...................................... 17
Exportar una interfaz física de un sistema virtual .................................... 18
Capítulo 3 Clasificar el tráfico según VLAN 19

Vista general .................................................................................................. 19
VLAN ....................................................................................................... 20
VLANs con Vsys....................................................................................... 20
Definir subinterfaces y etiquetas VLAN .......................................................... 22
Comunicación entre sistemas virtuales .......................................................... 25
xxvi Contenido
Contenido
Capítulo 4 Clasificar el tráfico según IP 29

Vista general .................................................................................................. 29
Designar un rango IP al sistema raíz .............................................................. 30
Configurar la clasificación del tráfico según IP ............................................... 31
Índice ........................................................................................................................IX-I
Volumen 11:
Alta disponibilidad
Capítulo 1 Protocolo de redundancia de NetScreen 1

Vista general .................................................................................................... 2
Protocolo de redundancia de NetScreen .................................................... 6
Ajustes predeterminados ........................................................................... 7
Clústeres NSRP ................................................................................................8
Crear un clúster NSRP ............................................................................ 10
Objetos en tiempo de ejecución............................................................... 12
Configurar un clúster NSRP activo/pasivo ................................................ 13
Configurar un estado de réplica de RTO .................................................. 17
Grupos de dispositivos de seguridad virtuales ................................................ 18
Opción de prioridad ................................................................................ 18
Estados de los miembros de un grupo VSD ............................................. 19
Mensajes de latido ................................................................................... 20
Crear dos grupos VSD.............................................................................. 21
Rutas estáticas e interfaces de seguridad virtual ...................................... 22
Sincronización ............................................................................................... 25
Sincronizar las configuraciones ............................................................... 25
Sincronizar archivos ................................................................................ 26
Sincronizar objetos en tiempo de ejecución............................................. 26
Resincronización manual de RTOs .......................................................... 26
Agregar un dispositivo a un clúster NSRP activo ...................................... 27
Sincronizar los relojes del sistema ........................................................... 28
Interfaces de alta disponibilidad dobles ......................................................... 28
Mensajes de control................................................................................. 30
Mensajes de datos (reenvío de paquetes)................................................. 31
Advertencia sobre el enrutamiento dinámico .......................................... 31
Sondear conexiones HA duales................................................................ 32
Envío manual de sondeos de conexiones.......................................... 33
Envío automático de sondeos de conexiones .................................... 33
Procedimiento de configuración .................................................................... 34
Cablear una configuración en malla completa ......................................... 34
Configuración de un clúster NSRP activo/activo....................................... 37
Contenido xxvii
Capítulo 2 Redundancia de interfaces 43

Interfaces y zonas redundantes...................................................................... 44
Crear una interfaz redundante.................................................................44
Establecer un tiempo de espera previo a la conmutación por error ......... 44
Crear interfaces redundantes para VSIs ................................................... 45
Configurar interfaces agregadas ..................................................................... 49
Interfaces Dual Untrust .................................................................................. 50
Conmutación por error de interfaces ....................................................... 51
Forzar tráfico a la interfaz de respaldo .............................................. 51
Invertir tráfico a la interfaz principal ................................................. 51
Tráfico conmutado por error automáticamente................................. 51
Definir la conmutación por error de interfaces ........................................ 52
Conmutación por error de interfaces con seguimiento de IP............. 53
Conmutación por error de interfaces ................................................ 53
Túneles activos dobles ...................................................................... 62
Aplicar pesos a la conmutación por error de túnel ............................ 67
Interfaz serie .................................................................................................. 73
Configurar ajustes del módem .................................................................74
Configuración de información ISP ........................................................... 75
Conmutación por error de interfaces serie............................................... 77
Configurar una interfaz de respaldo de acceso telefónico
en el modo Trust-Untrust............................................................ 77
Eliminar una ruta predeterminada de la interfaz serie ...................... 80
Agregar una ruta predeterminada a la interfaz serie ......................... 80
Desactivar una directiva para conmutación por error
de la interfaz serie ...................................................................... 80
Capítulo 3 Conmutación por error 83

Conmutación por error del dispositivo ........................................................... 83
Conmutación por error del grupo VSD (NSRP) ............................................... 84
Supervisar objetos para la conmutación por error del dispositivo
o del grupo VSD....................................................................................... 85
Supervisar un objeto de interfaz física para activar
la conmutación por error .................................................................. 87
Supervisar un objeto de zona para activar la conmutación por error ....... 87
Supervisar un objeto de IP con seguimiento para activar
la conmutación por error .................................................................. 88
Establecer el seguimiento de IP para conmutación por error
del dispositivo ................................................................................... 90
Conmutación por error del sistema virtual ..................................................... 93
Capítulo 4 NSRP-Lite 99
Introducción al protocolo NSRP-Lite.............................................................100
Clústeres y grupos VSD..........................................................................102
Ajustes predeterminados .......................................................................103
Clústeres ......................................................................................................103
Nombres de clúster ...............................................................................105
Autenticación y encriptación .................................................................106
Grupos VSD..................................................................................................106
Estados de los miembros de un grupo VSD ...........................................107
Mensajes de latido .................................................................................108
Opción de prioridad ..............................................................................108
Cablear y configurar el protocolo NSRP-Lite .................................................109
xxviii Contenido
Contenido
Sincronizar la configuración y los archivos...................................................114

Sincronizar las configuraciones .............................................................114
Sincronizar archivos ..............................................................................115
Agregar un dispositivo a un clúster NSRP activo ....................................115
Sincronización automática de la configuración ......................................116
Supervisar rutas ...........................................................................................117
Establecer los umbrales .........................................................................118
Asignar pesos a la direcciones IP sometidas a seguimiento ...................118
Seguimiento de IP para conmutación por error del túnel VPN ...............119
Índice ........................................................................................................................IX-I
Volumen 12:
Métodos de conexión alternos
Capítulo 1 Línea asimétrica de abonado digital 1

Introducción a ADSL ........................................................................................ 1
La interfaz ADSL en un dispositivo de seguridad .............................................. 2
Protocolo punto a punto a través de la capa de adaptación 5 .................... 4
Ejemplos de configuración ............................................................................... 5
Ejemplo 1: (residencial/comercial pequeño) PPPoA en interfaz de ADSL ... 6
Ejemplo 2: (residencial/comercial pequeño) 1483 Bridging en interfaz
de ADSL .............................................................................................. 8
Ejemplo 3: (residencial/comercial pequeño) Respaldo
de acceso telefónico.......................................................................... 10
Ejemplo 4: (residencial/comercial pequeño) Respaldo de ethernet .......... 15
Ejemplo 5: (negocio pequeño) Permitir acceso a los servidores locales.... 17
Ejemplo 6: (sucursal) Túnel VPN a través de ADSL .................................. 20
Ejemplo 7: (sucursal) Túnel VPN secundario ............................................ 24
Ejemplo 8: Enrutamiento 1483 en la interfaz ADSL................................. 30
Capítulo 2 Red de área local inalámbrica 33

Vista general .................................................................................................. 34
Interfaces inalámbricas en dispositivos de seguridad ..................................... 35
Conjunto de servicios básicos .................................................................. 36
Identificador de conjunto de servicios............................................... 37
Modos de funcionamiento WAP ........................................................ 37
Enlace de interfaz inalámbrica ................................................................ 38
Autenticación y encriptación ................................................................... 39
Antena..................................................................................................... 43
Canales y códigos de país ........................................................................ 44
Sondear el sitio........................................................................................ 44
Control de acceso .................................................................................... 45
Modos de funcionamiento con dispositivos WLAN .................................. 46
Contenido xxix
Reactivar la configuración WLAN ............................................................ 47

Ejemplos de configuración ............................................................................. 47
Ejemplo 1: Autenticación y encriptación WEP abiertas............................ 47
Ejemplo 2: Autenticación de WPA-PSK con contraseña larga y
encriptación automática.................................................................... 48
Ejemplo 3: WLAN en modo transparente ................................................ 48
Ejemplo 4: Perfiles múltiples y diferenciados........................................... 52
Capítulo 3 Conmutación por fallo de ISP y recuperación

por acceso telefónico 59
Ajustar la prioridad de ISP para conmutación por fallo................................... 59
Definir condiciones para conmutación por fallo de ISP .................................. 60
Configurar una solución de recuperación por acceso telefónico ..................... 61
Apéndice A Canales autorizados para todos los países A-I
Índice ........................................................................................................................IX-I
Volumen 13:
Servicio general de radio por paquetes
Capítulo 1 GPRS 1
El dispositivo de seguridad como cortafuegos de protocolo
de encapsulamiento de GPRS .................................................................... 3
Interfaces Gp y Gn ..................................................................................... 3
Interfaz Gi.................................................................................................. 4
Modos de funcionamiento ......................................................................... 5
Compatibilidad con el sistema virtual ........................................................ 6
Protocolo de encapsulamiento de GPRS mediante directivas ........................... 6
Ejemplo: Configuración de directivas para habilitar la inspección de GTP.. 7
Objeto de inspección en el protocolo de encapsulamiento de GPRS (GTP) ....... 8
Ejemplo: Creación de un objeto de inspección de GTP .............................. 8
Filtrar mensajes de GTP ................................................................................... 9
Comprobar la coherencia del paquete ....................................................... 9
Filtrar la longitud del mensaje .................................................................10
Filtrar el tipo de mensaje ......................................................................... 10
Ejemplo: Permiso y rechazo de los tipos de mensajes.......................11
Tipos de mensaje admitidos.............................................................. 11
Filtrar el nombre de punto de acceso ...................................................... 13
Ejemplo: Establecimiento de un APN y un Modo de selección .......... 14
Ejemplo: Configuración de un Filtro APN y prefijo
de IMSI combinado..................................................................... 14
Filtrar el prefijo de IMSI ........................................................................... 15
Desactivar el filtrado del prefijo de IMSI............................................ 16
xxx Contenido
Contenido
Ejemplo: Desactivación del filtrado del prefijo de IMSI...................... 16

Limitar velocidad de los mensajes ........................................................... 16
Ejemplo: Establecimiento de un límite de velocidad ......................... 17
Validar el número de secuencia ............................................................... 17
Ejemplo: Habilitación de la validación del número de secuencia....... 18
Fragmentación de IP ............................................................................... 18
Filtrar el paquete de GTP-en-GTP ............................................................. 18
Ejemplo: Habilitación del filtrado de paquetes de GTP-en-GTP .......... 18
Túneles de GTP ..............................................................................................19
Limitar el túnel GTP ................................................................................. 19
Ejemplo: Establecimiento de los límites de túnel GTP .......................19
Inspección de estado ............................................................................... 19
Establecimiento y desmontaje del túnel de GTP ................................ 20
Actualización del área de enrutamiento dentro de SGSN................... 20
Conmutación por error del túnel para alta disponibilidad ........................ 20
Limpieza de túneles de GTP colgados ...................................................... 21
Ejemplo: Establecimiento del tiempo de espera
para los túneles de GTP .............................................................. 21
Redireccionamiento de GSN y GGSN .............................................................. 22
Prevención de ataque de sobrefacturación..................................................... 22
Descripción del ataque de sobrefacturación ............................................ 22
Solución del ataque de sobrefacturación.................................................. 24
Ejemplo: Configuración de la función de prevención
de ataques de sobrefacturación .................................................. 25
Supervisar el tráfico de GTP ........................................................................... 26
Registrar el tráfico ................................................................................... 26
Ejemplo: Habilitación de inicio de sesión del paquete de GTP ........... 28
Contar el tráfico....................................................................................... 28
Ejemplo: Habilitación del recuento de tráfico de GTP........................ 29
Interceptación legal ................................................................................. 30
Ejemplo: Habilitación de la interceptación legal ................................ 30
Índice ........................................................................................................................IX-I
Contenido xxxi
xxxii Contenido
Acerca del Manual de Referencia de
ScreenOS: conceptos y ejemplos
Los dispositivos de seguridad de Juniper Networks son sistemas y dispositivos de

seguridad para Internet basados en ASIC (Application-Specific Integrated Circuit) y
certificados por ICSA (Internet Computer Security Association), que integran
funciones de cortafuegos, redes privadas virtuales (VPN) y asignación de tráfico
para ofrecer una protección flexible para zonas de seguridad, como redes de área
local internas (LAN) o zonas desmilitarizadas (DMZ), cuando se conectan 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.
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).
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 la conformidad de los productos Juniper
Networks con las normas FIPS (Federal Information Processing Standards) y para
acceder a las instrucciones de configuración de un dispositivo de seguridad
conforme a FIPS en modo FIPS, consulte el documento Cryptographic Module
Security Policy del CD de documentación.
xxxiii
Manual de referencia de ScreenOS: conceptos y ejemplos
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 el cortafuegos
enrutamiento, y se comunica e
interactúa con dispositivos de
enrutamiento del entorno.
LAN Enrutamiento dinámico: Dest Utilice
Zona Trust La tabla de enrutamiento se 0.0.0.0/0 1.1.1.250

actualiza automáticamente 1.1.1.0/24 eth3
comunicándose con los
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 operativo ScreenOS ofrece todas las funciones necesarias para configurar
y gestionar 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.
xxxiv
Acerca del Manual de Referencia de ScreenOS: conceptos y ejemplos
Organización del volumen

El manual de referencia de ScreenOS: conceptos y ejemplos consta 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.
El Apéndice A, “Glosario,” contiene definiciones de todos los términos clave

utilizados en todos los volúmenes del manual.
“Índice” es un índice global de todos los volúmenes del manual.
Volumen 2: Fundamentos
En el Capítulo 1, “Arquitectura de ScreenOS,” se describen los elementos

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

túnel y las zonas de función.
En el Capítulo 3, “Interfaces,” se describen las diferentes interfaces físicas,

lógicas y virtuales de los dispositivos de seguridad.
En el Capítulo 4, “Modos de las interfaces,” se explican los conceptos

relacionados con los modos de funcionamiento de interfaz transparente, NAT
(Network Address Translation) y de rutas.
En el Capítulo 5, “Bloques para la construcción de directivas,” 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. También se incluyen diversos ejemplos de configuración
compatibles con el protocolo H.323.
En el Capítulo 6, “Directivas,” se examinan los componentes y las funciones de

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

banda en los niveles de interfaz y directivas y cómo priorizar servicios.
En el Capítulo 8, “Parámetros del sistema,” 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 configuraciones del
sistema y software y el ajuste del reloj del sistema.
Organización del volumen xxxv

En el Volumen 3: Administración
Capítulo 1, “Administración,” 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.
En el Capítulo 2, “Supervisar dispositivos de seguridad,” se explican los

diversos métodos de supervisión y se ofrecen instrucciones para interpretar los
resultados de dicha supervisión.
En el Apéndice A, “Archivos MIB para SNMP,” se enumeran y describen

brevemente los archivos de base de información de administración
(“Management Information Base” o MIB) disponibles para los compiladores
MIB.
Volumen 4: Mecanismos de detección y defensa de ataques
En el Capítulo 1, “Protección de una red,” se resumen las etapas básicas de un

ataque y las opciones de cortafuegos disponibles para combatir al atacante en
cada etapa.
En el Capítulo 2, “Disuasión de reconocimiento,” se describen las opciones

disponibles para bloquear la limpieza de direcciones IP, los análisis de puertos y
los intentos de descubrir el tipo de sistema operativo (OS) del sistema objetivo
del ataque.
En el Capítulo 3, “Defensas contra los ataques de denegación de servicio

(DoS),” se explican los ataques DoS específicos de cada sistema operativo, red
o cortafuegos, y cómo ScreenOS amortigua dichos ataques.
En el Capítulo 4, “Supervisión y filtrado de contenidos,” se describe cómo

proteger a los usuarios del protocolo de transferencia de hipertexto (“Hypertext
Transfer Protocol” o HTTP) frente a los localizadores uniformes de recursos
(“Uniform Resource Locator” o 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.
En el Capítulo 5, “Deep Inspection,” se describe cómo configurar el dispositivo

de seguridad para obtener actualizaciones de Deep Inspection (DI) para objetos
de ataques, cómo crear objetos de ataque y grupos de objetos de ataque
definidos por el usuario, y cómo aplicar IDP a nivel de directivas.
En el Capítulo 6, “Atributos de los paquetes sospechosos,” se explican una serie

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

proporciona una lista y descripciones de los contextos que se pueden
especificar al definir un objeto de ataque de firma completa.
xxxvi Organización del volumen

Volumen 5: Redes privadas virtuales
En el Capítulo 1, “Seguridad del protocolo de Internet,” se 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 la
encapsulación de paquetes IKE y IPSec.
En el Capítulo 2, “Criptografía de claves públicas,” se explica cómo obtener y

cargar certificados digitales y listas de revocación de certificados (CRL).
El Capítulo 3, “Directivas de red privada virtual,” 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.
El Capítulo 4, “Redes privadas virtuales de punto a punto,” ofrece numerosos

ejemplos de configuraciones VPN para interconectar dos redes privadas.
El 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.
El Capítulo 6, “Protocolo de encapsulamiento de la capa 2 (L2TP),” explica el

protocolo de encapsulamiento de la capa 2 (L2TP), su utilización en solitario y
en conjunto con IPSec (L2TP sobre IPSec).
El 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.
Volumen 6: Voz sobre protocolo de Internet (VoIP)
En “Puerta de enlace en la capa de aplicación H.323” se describe el protocolo

H.323 y se proporcionan ejemplos para la configuración de la puerta de enlace
en la capa de aplicación (Aplication Layer Gateway o ALG) en el dispositivo de
seguridad de Juniper Networks.
“Puerta de enlace de la capa de aplicación del protocolo de inicio de sesión”

describe la ALG del Protocolo de inicio de sesión (Session initiation Protocol
SIP).
“Puerta de enlace en la capa de aplicación del Protocolo de control de la puerta

de medios” ofrece una vista general de la ALG del protocolo de control de la
puerta de medios (Media 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.
Organización del volumen xxxvii

Volumen 7: Enrutamiento
El 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.
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, “Protocolo OSPF,” describe cómo configurar el protocolo de

enrutamiento dinámico OSPF en los dispositivos de seguridad.
El 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.
El Capítulo 5, “Protocolo BGP,” describe cómo configurar el protocolo de

enrutamiento dinámico BGP en los dispositivos de seguridad.
El Capítulo 6, “Enrutamiento multicast,” presenta los conceptos básicos sobre

el enrutamiento multicast.
El Capítulo 7, “Protocolo IGMP,” describe cómo configurar el protocolo de

administración del grupo de Internet (“Internet Group Management Protocol” o
IGMP) en los dispositivos de seguridad.
El Capítulo 8, “Multicast independiente de protocolo (PIM),” describe cómo

configurar el protocolo de enrutamiento Protocol Independent Multicast (PIM)
en los dispositivos de seguridad.
Volumen 8: Traducción de direcciones
El 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.
El 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 puertos de red (PAT).
El 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.
El 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).
xxxviii Organización del volumen

Volumen 9: Autenticación de usuarios
El Capítulo 1, “Autenticación,” detalla los distintos usos y métodos de

autenticación que admite ScreenOS.
El 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.
El Capítulo 3, “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.
El Capítulo 4, “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.
Volumen 10: Sistemas virtuales
El Capítulo 1, “Sistemas virtuales,” abarca los sistemas virtuales, objetos y

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

tráfico basado en VLAN para sistemas virtuales.
El Capítulo 4, “Clasificar el tráfico según IP,” explica la clasificación de tráfico

basado en IP para sistemas virtuales.
Volumen 11: Alta disponibilidad
El 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).
El Capítulo 2, “Redundancia de interfaces,” describe las distintas formas en que

los dispositivos de seguridad de Juniper Networks proporcionan redundancia de
interfaces.
El Capítulo 3, “Conmutación por error,” describe la configuración de la

conmutación por error de un dispositivo, un grupo de dispositivos de seguridad
virtual (VSD) o un sistema virtual. También se explica cómo supervisar ciertos
objetos para determinar la conmutación por error de un dispositivo o grupo
VSD.
El Capítulo 4, “NSRP-Lite,” explica cómo configurar dispositivos de seguridad

de Juniper Networks compatibles con NSRP-Lite.
Organización del volumen xxxix

Volumen 12: Métodos de conexión alternos
El Capítulo 1, “Línea asimétrica 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.
El Capítulo 2, “Red de área local inalámbrica,” describe las interfaces

inalámbricas en los dispositivos inalámbricos de Juniper Networks y
proporciona configuraciones de ejemplo.
El Capítulo 3, “Conmutación por fallo 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.
El Apéndice A, “Canales autorizados para todos los países,” 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
El 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.
xl Organización del volumen

Convenciones del documento

Este documento utiliza distintos tipos de convenciones, que se explican en las
siguientes secciones:
“Convenciones de la interfaz de línea de comandos (CLI)” en esta página
“Convenciones para las ilustraciones” en la página xlii
“Convenciones de nomenclatura y conjuntos de caracteres” en la página xliii
“Convenciones de la interfaz gráfica (WebUI)” en la página xliv
Convenciones de la interfaz de línea de comandos (CLI)

Las siguientes convenciones se utilizan para presentar la sintaxis de los comandos
de 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
significa “establecer las opciones de administración de la interfaz ethernet1,

ethernet2 o ethernet3”.
Las variables aparecen en cursiva:
set admin user nombre1 contraseña xyz
En texto:
Los comandos aparecen en negrita.
Las variables aparecen en cursiva.
NOTA: Para escribir palabras clave, basta con introducir los primeros caracteres que
permitan al sistema reconocer de forma inequívoca la palabra que se está
introduciendo. Por ejemplo, es suficiente introducir set adm u kath j12fmt54
para que el sistema reconozca el comando set admin user kathleen j12fmt54.
Aunque este método se puede utilizar para introducir comandos, en la presente
documentación todos ellos se representan con sus palabras completas.
Convenciones del documento xli

Convenciones para las ilustraciones

Las siguientes figuras conforman el conjunto básico de imágenes utilizado en las
ilustraciones de este manual.
Figura 2: Imágenes en las ilustraciones del manual
Red de área local (LAN) con

Sistema autónomo una única subred (ejemplo:
10.1.1.0/24)
Dispositivo de seguridad general

Internet
Dominio de enrutamiento virtual

Rango de direcciones IP
dinámicas (DIP)
Zona de seguridad Equipo de escritorio
Interfaz de la zona de seguridad

Equipo portátil
Blanca = Interfaz de zona protegida
(ejemplo = zona Trust)
Negra = Interfaz de zona externa
(ejemplo = zona Untrust) Dispositivo de red genérico
(ejemplos: servidor NAT,
concentrador de acceso)
Interfaz de túnel
Servidor
Túnel VPN
Concentrador (hub)
Enrutador
Teléfono IP
Conmutador
xlii Convenciones del documento

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 juegos de caracteres
ASCII, europeo y hebreo. Entre los conjuntos MBCS, también conocidos como
conjuntos de caracteres de doble byte (DBCS), se encuentran el chino, el
coreano y el japonés.
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 xliii

Convenciones de la interfaz gráfica (WebUI)

Una comilla angular ( > ) muestra la secuencia de navegación a través de WebUI, a
la que puede llegar mediante un clic en las opciones de menú y vínculos. La
siguiente figura indica la siguiente ruta al cuadro de diálogo de configuración de
direcciones—Objects > Addresses > List > New:
Figura 3: Navegación de WebUI
Para llevar a cabo una tarea en la WebUI, en primer lugar debe acceder al cuadro de
diálogo apropiado, donde podrá definir objetos y establecer parámetros de ajuste.
El conjunto de instrucciones de cada tarea se divide en ruta de navegación y ajustes
de configuración:
La siguiente figura muestra la ruta al cuadro de diálogo de configuración de

direcciones con los siguientes ajustes de configuración de muestra:
Objects > Addresses > List > New: Introduzca los siguientes datos y haga clic
en OK:
Address Name: addr_1
IP Address/Domain Name:
IP/Netmask: (seleccione), 10.2.2.5/32
Zone: Untrust
Figura 4: Ruta de navegación y ajustes de configuración
xliv Convenciones del documento

Documentación de Juniper Networks

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/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

nosotros a través de la siguiente dirección de correo electrónico:
techpubs-comments@juniper.net
Documentación de Juniper Networks xlv

xlvi Documentación de Juniper Networks

Apéndice A
Glosario
100BaseT Otro término para Fast Ethernet, un estándar actualizado para la conexión de
computadores en una LAN. Ethernet 100BaseT funciona igual que Ethernet, pero
puede transferir datos a una velocidad máxima de 100 Mbps. También es más caro
y menos común que su antecesor 10BaseT. Consulte también 10BaseT.
10BaseT También conocido como Par trenzado sin blindaje (UTP), 10BaseT es el cableado
estándar para líneas telefónicas y la forma más común de la conexión de Ethernet.
10BaseT lo que indica una velocidad de transmisión de 10 Megabits por segundo
(Mbps) utilizando un cable de par trenzado de cobre. Ethernet es una norma para la
conexión de equipos a una red de área local (LAN). La distancia de cable máxima
será de 100 metros (325 pies), el número máximo de dispositivos por segmento de
red será 1 y el de dispositivos por red, 1.024. Consulte también 100BaseT.
ABR Consulte Enrutador de borde de área (ABR).
Acceso protegido de Una norma de Wi-Fi diseñada para mejorar las funciones de seguridad de la
Wi-Fi (WPA) privacidad equivalente a cableado (WEP).
Access-challenge Condición adicional necesaria para que un usuario de autenticación inicie una
(desafío de acceso): sesión Telnet correctamente a través de un servidor RADIUS.
ACL Consulte Lista de control de accesos (ACL).
Adaptador virtual Los ajustes TCP/IP [dirección del protocolo de Internet (IP), direcciones del servidor
de sistema de nombre de dominio (DNS) y direcciones de servidor de servicio de
denominación de Internet de Windows (WINS)] que un dispositivo de seguridad
asigna a un usuario remoto XAuth para uso en una conexión VPN.
Administración de El único modo razonable de proteger la integridad y privacidad de la información es

claves confiar en el uso de información secreta en forma de claves privadas para firmar o
encriptar los datos. La gestión y el manejo de estos datos secretos se suele conocer
como administración de claves. Incluye las actividades de selección, intercambio,
almacenamiento, certificación, caducidad, revocación, cambio y transmisión de
claves. La mayor parte del trabajo que supone administrar sistemas de seguridad de
información se centra en la administración de claves. Consulte también Asociación
de seguridad de Internet y protocolo de administración de claves (ISAKMP).
ADSL Consulte Línea asimétrica de abonado digital (ADSL).
A-I
Adyacencias Cuando dos enrutadores pueden intercambiar información de enrutamiento, se

considera que han establecido una relación de adyacencia. Las redes punto a punto,
las cuales sólo tienen dos enrutadores, forman automáticamente una adyacencia.
Las redes punto a multipunto son una serie de varias redes punto a punto. Cuando
los enrutadores se emparejan en esta topología de red más compleja, se considera
que son adyacentes entre sí.
Agregación Proceso de combinar varias rutas de modo que sólo se notifique una. Con esta
técnica se minimiza el tamaño de la tabla de enrutamiento para el enrutador.
Agregado atómico Objeto utilizado por un enrutador de protocolo de puerta de enlace de borde (BGP)
para informar a otros enrutadores BGP de que el sistema ha seleccionado una ruta
general.
Agregador Objeto utilizado para agrupar múltiples rutas bajo una ruta común general de
acuerdo con el valor de la máscara de red.
AH Consulte Protocolo de seguridad de encabezado/Encabezado de la autenticación

(ESP/AH).
ALG Consulte Puerta de enlace en la capa de aplicación (ALG).
Algoritmo Hash Algoritmo que produce un hash de 160 bits a partir de un mensaje de longitud
seguro-1 (SHA-1) arbitraria. (Normalmente, se considera más seguro que MD5 debido al mayor
tamaño del hash que produce).
Alta disponibilidad (HA) Configuración de pares de dispositivos de seguridad con el protocolo de

redundancia de NetScreen (NSRP) para asegurar la continuidad de servicio en el
caso de la salida de red o falla del dispositivo.
Análisis antivirus (AV) Un mecanismo para detectar y bloquear virus en tráfico FTP (“File Transfer
Protocol”), IMAP (“Internet Message Access Protocol”), SMTP (“Simple Mail Transfer
Protocol”), HTTP (“Hypertext Transfer Protocol”), incluyendo el tráfico HTTP
webmail y POP3 (“Post Office Protocol”). ScreenOS ofrece una solución interna de
análisis AV.
Árbol de distribución Un árbol de distribución multicast donde el origen transmite el tráfico multicast al
compartido punto de encuentro (RP), que a continuación reenvía el tráfico en sentido
descendente a los receptores del árbol de distribución.
Árbol de la ruta más Un árbol de distribución multicast donde el origen se encuentra en la raíz del árbol
corta (SPT) y reenvía datos multicast en sentido descendente a cada receptor. Denominado
también como árbol específico del origen.
Área El método de orden más fundamental en el protocolo de enrutamiento de Open

Shortest Path First (OSPF). Un área OSPF divide una red de gran tamaño en
fragmentos menores y más manejables. Con esta técnica se reduce la cantidad de
información acerca de todos los demás enrutadores que cada enrutador debe
almacenar y actualizar. Cuando un enrutador está en un área necesita información
sobre otro dispositivo interno o externo en esa área, éste se comunica con un
enrutador especial, denominado enrutador de borde de área (ABR), que contiene
toda la información esencial sobre el dispositivo. Además, el ABR filtra toda la
información que llega al área, evitando así que otros enrutadores del área se vean
sobrecargados con información innecesaria.
AS Consulte Sistema autónomo (AS).
A-II
Apéndice A: Glosario
Asignación de puertos La traducción del número de puerto de destino original en un paquete a otro
número de puerto predeterminado.
Asociación de Acuerdo unidireccional entre los participantes VPN por lo que respecta a los
seguridad (SA) métodos y parámetros empleados para garantizar la seguridad de un canal de
comunicaciones. Para comunicaciones bidireccionales requiere al menos dos SA,
una para cada dirección. Los participantes VPN negocian y acuerdan SA de fase 1 y
de fase 2 durante una negociación AutoKey IKE. Consulte también Índice de
parámetros de seguridad.
Asociación de Proporciona un marco para la administración de claves de Internet y el soporte de

seguridad de Internet y protocolo específico para la negociación de atributos de seguridad. En sí mismo, no
protocolo de establece claves de sesión, aunque se puede utilizar con varios protocolos de
administración de establecimiento de claves de sesión para ofrecer una solución completa para la
claves (ISAKMP) gestión de claves de Internet.
Autenticación La autenticación garantiza que las transmisiones de datos digitales lleguen al

destinatario previsto. También valida al destinatario la integridad del mensaje y su
fuente (el lugar donde se originó o la persona que lo envió). La forma más simple de
autenticación requiere un nombre de usuario y una contraseña para poder acceder
a una cuenta en particular. Los protocolos de autenticación también se pueden
basar en una encriptación de clave secreta, como DES o 3DES, o en sistemas de
clave pública, que utilizan firmas digitales.
BSS Consulte Conjunto de servicios básicos (BSS).
Cadena de ruta AS Cadena que funciona como identificador de una ruta a un sistema autónomo (AS).
Se configura junto con la ID de lista de acceso AS-path.
Clase de atributo de BGP proporciona cuatro clases de atributos de ruta: discrecionales bien conocidos,
ruta AS opcionales transitivos y opcionales no transitivos.
Clúster Grupo de enrutadores en un sistema autónomo BGP, donde un enrutador se

establece como reflector de rutas y los demás son clientes del reflector. El reflector
es responsable de proporcionar a los clientes la información de rutas y direcciones
que conoce por los dispositivos de otro sistema autónomo. El término clúster tiene
otro significado en relación con la alta disponibilidad (HA). Consulte el protocolo de
redundancia de NetScreen (NSRP) Alta disponibilidad; .
Código de país de móvil Uno de los tres elementos de una Identidad de estación móvil internacional (IMSI);
(MCC) los otros dos son el código de red móvil (MNC) y el número de identificación de
abonado móvil (MSIN). El MCC y el MNC combinados constituyen el prefijo de IMSI
e identifican la red local móvil del abonado o la red móvil terrestre pública (PLMN).
Consulte también Identidad de estación móvil internacional (IMSI); Red móvil terrestre
pública (PLMN).
Código de red de móvil Uno de los tres elementos de una Identidad de estación móvil internacional (IMSI);
(MNC) los otros dos son el código de país móvil (MCC) y el número de identificación de
abonado móvil (MSIN). El MCC y el MNC combinados constituyen el prefijo de IMSI
e identifican la red local móvil del abonado o la red móvil terrestre pública (PLMN).
Consulte también Identidad de estación móvil internacional (IMSI); Red móvil terrestre
pública (PLMN).
A-III
Comparación del Un atributo que se utiliza para determinar una conexión ideal para llegar a un
Discriminador de salida prefijo particular dentro o tras el sistema autónomo (AS) actual. El MED contiene
múltiple (MED) una métrica que expresa el grado de preferencia de entradas en el AS. Puede
establecer prioridad de una conexión sobre el resto configurando un valor MED
para una conexión menor que el del resto de conexiones. Cuando menor sea el
valor MED, mayor será la prioridad de la conexión. Esto sucede porque un AS
establece el valor MED y el otro AS utiliza el valor para elegir una ruta.
Comunidad Una agrupación de destinos de protocolo de puerta de enlace de borde (BGP). Al

actualizar la comunidad, se actualizan automáticamente los destinos de sus
miembros con nuevos atributos.
Concentrador Un dispositivo de hardware utilizado para enlazar equipos (normalmente, a través

de una conexión Ethernet). Se utiliza como punto de cableado común, de modo que
la información puede fluir a través de una ubicación central hacia cualquier otro
equipo de la red. Un concentrador repite las señales en la capa Ethernet física
(normalmente Ethernet). Un concentrador mantiene el comportamiento de una red
de tipo bus estándar (como Thinnet), pero produce una tipología en estrella con el
concentrador en su centro. Esta configuración permite una administración
centralizada.
Conector de interfaz de Tipo de tarjeta modular de interfaz utilizada en ciertos dispositivos de seguridad
gigabit (GBIC) para conectar una red de fibra óptica.
Conexión virtual Ruta lógica desde un área OSPF remota hasta el área troncal.
Confederación Objeto dentro de un sistema autónomo de protocolo de puerta de enlace de borde

(BGP AS) que es un subconjunto de instancias de enrutamiento en AS. Al agrupar
dispositivos en confederaciones dentro de un BGP AS, se reduce la complejidad
asociada a la matriz de conexiones de enrutamiento, conocida como malla, dentro
de AS.
Conjunto de servicios Cuando un punto de acceso (AP) está conectado a una red cableada y un grupo de
básicos (BSS) estaciones inalámbricas, se le conoce como un grupo de servicio básico.
Consultador Un enrutador que envía mensajes de protocolo de administración de grupo de

Internet (IGMP) a todos los hosts de la red para solicitar información de miembros
del grupo. Generalmente, hay un consultador por cada red.
Contexto del protocolo Una sesión de usuario en una red GPRS.

de datos de paquete
(PDP)
Copia segura (SCP) Método de transferencia de archivos entre un cliente remoto y un dispositivo de
seguridad con protocolo SSH. El dispositivo de seguridad actúa como servidor de
SCP, aceptando conexiones de clientes de SCP en hosts remotos.
Cortafuegos Dispositivo que protege y controla la conexión de una red con otra, tanto para el
tráfico entrante como para el saliente. Los cortafuegos se utilizan en empresas que
desean proteger cualquier servidor conectado a la red frente a daños (intencionados
o no) por parte de quienes acceden a él. Puede tratarse de un equipo dedicado,
equipado con medidas de seguridad, o de un tipo de protección basada en
software.
CRL Consulte Lista de revocación de certificados (CRL).
A-IV
Deep Inspection (DI) Mecanismo para filtrar el tráfico permitido por el cortafuegos. Deep Inspection
examina los encabezados de los paquetes de las capas 3 y 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.
DES Consulte la Norma de encriptación de datos (DES).
DES–CBC Consulte Norma de encriptación de datos – Encadenamiento de bloques de cifrado

(DES–CBC).
Desplazamiento de Mecanismo para crear una asignación directa (1:1) entre una dirección original
direcciones cualquiera en un rango de direcciones y una dirección traducida específica en otro
rango.
Detección de DPD permite a un dispositivo IPSec verificar la existencia actual y la disponibilidad

interlocutor muerto de otros dispositivos homólogos de IPSec. El dispositivo realiza la verificación de
(DPD) 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).
DI Consulte Deep Inspection (DI).
Dirección de Control de Dirección que identifica de forma única la tarjeta de interfaz de red, por ejemplo,
acceso de medios un adaptador Ethernet. En el caso de Ethernet, la dirección MAC es una dirección
(MAC) de 6 octetos asignada por IEEE. En una LAN o cualquier otra red, la dirección MAC
es un número de hardware único del equipo (en una LAN Ethernet, la dirección
MAC será la misma que la dirección Ethernet). Cuando se conecte a Internet desde
su equipo (o host, tal y como lo identifica el protocolo de Internet), una tabla de
correspondencias relacionará su dirección IP a la dirección (MAC) física de su
equipo en la LAN. La dirección MAC se utiliza en la subcapa de control de acceso a
medios (MAC) de la capa de control de conexión de datos (DLC) en los protocolos de
comunicación. Existe una subcapa MAC distinta para cada tipo de dispositivo físico.
Dirección IP asignada Una asignación directa uno a uno a una dirección IP del tráfico destinado a otra
(MIP) dirección IP.
Dirección IP virtual Una dirección VIP asigna el tráfico recibido en una dirección IP a otra dirección
(VIP) basándose en el número del puerto de destino que figura en el encabezado del
paquete.
Directivas Las directivas ofrecen el mecanismo de protección inicial para el cortafuegos,

permitiendo determinar qué tráfico puede atravesarlo en función de los detalles de
la sesión IP. Las directivas se pueden utilizar para proteger los recursos de una zona
de seguridad frente a ataques procedentes de otras zonas (directivas interzonales) o
frente a ataques procedentes de la misma zona (directivas intrazonales). También
se pueden utilizar para supervisar el tráfico que intente atravesar el cortafuegos.
Directivas multicast Las directivas multicast permiten que el tráfico de control multicast, como
mensajes Internet Group Management Protocol (IGMP) o Protocol-Independent
Multicast (PIM), cruce los dispositivos de seguridad.
Discriminador de salida Atributo BGP que determina la preferencia relativa de los puntos de entrada a un
múltiple (MED) sistema autónomo (AS).
Dispositivo de Un único dispositivo lógico compuesto por un conjunto de dispositivos de seguridad

seguridad virtual (VSD) físicos.
A-V
DMZ Consulte Zona desmilitarizada (DMZ).
DPD Consulte Detección de interlocutor muerto (DPD).
Encabezado de Consulte Protocolo de seguridad de encabezado/Encabezado de la autenticación

autenticación (AH) (ESP/AH).
Encapsulado genérico Un protocolo que encapsula cualquier tipo de paquete dentro de los paquetes
de enrutamiento (GRE) unicast IPv4. Para obtener información adicional sobre GRE, consulte RFC 1701,
Encapsulado genérico de enrutamiento (GRE).
Encapsulamiento Un método de encapsulación de datos. Con el encapsulamiento de red privada

virtual (VPN), un profesional móvil marca en un punto de presencia (POP) de un
proveedor de servicio de Internet (ISP) local en lugar de marcar directamente en
una red corporativa. Esto implica que, independientemente del lugar en el que se
encuentren los teletrabajadores, siempre pueden acceder a la red de la empresa a
través de un ISP local que admita la tecnología de encapsulamiento VPN, con lo que
los costes generados son sólo los de una llamada telefónica local. Cuando los
usuarios remotos acceden a su red de empresa a través de un ISP que admite el
encapsulamiento VPN, tanto el usuario remoto como la propia organización saben
que se trata de una conexión segura. Todos los usuarios telefónicos remotos se
autentican a través de un servidor de autenticación del sitio del ISP y a través de
otro servidor de autenticación de la red de empresa. Esto implica que sólo los
usuarios remotos autorizados pueden acceder a la red de la empresa, y sólo pueden
acceder a los host que estén autorizados a utilizar.
Encriptación El proceso de cambiar los datos de forma que sólo pueda leerlos el receptor
correspondiente. Para descifrar el mensaje, el receptor de los datos encriptados
debe disponer de la clave de desencriptación adecuada. En esquemas de
encriptación tradicionales, el emisor y el receptor utilizan la misma clave para
encriptar y desencriptar los datos. Los esquemas de encriptación de clave pública
utilizan dos claves: una clave pública, que puede utilizar cualquier usuario, y una
clave privada correspondiente, que sólo tiene la persona que la creó. Con este
método, cualquiera puede enviar un mensaje encriptado con la clave pública del
propietario, pero sólo él podrá desencriptarlo con su clave privada. Norma de
encriptación de datos (DES) y DES triple (3DES) son dos de los esquemas de
encriptación de clave pública más conocidos.
Enrutador Dispositivo virtual o de hardware (de un entorno de seguridad) que distribuye datos
entre todos los demás enrutadores y puntos de recepción situados dentro o fuera
del dominio de enrutamiento local. Los enrutadores también actúan como filtros,
permitiendo que sólo los dispositivos autorizados transmitan datos dentro de la red
local para que la información privada siga siendo segura. Además de dar soporte a
estas conexiones, los enrutadores también gestionan errores, mantienen
estadísticas de utilización de la red y se encargan de cuestiones de seguridad.
Enrutador de borde de Enrutador con al menos una interfaz en el área 0 y al menos una interfaz en otra
área (ABR) área.
Enrutador de límite de Enrutador que conecta un sistema autónomo (AS) ejecutado según un protocolo de
AS enrutamiento con otro AS ejecutado según un protocolo distinto.
Enrutador virtual El componente de ScreenOS que realiza las funciones de enrutamiento. De forma
predeterminada, un dispositivo de seguridad admite dos enrutadores virtuales:
Untrust-VR y Trust-VR.
A-VI
Enrutamiento dinámico Método de enrutamiento que se adapta a las circunstancias cambiantes de la red
analizando los mensajes entrantes de actualización de enrutamiento. Si el mensaje
indica que se ha producido un cambio en la red, el software de enrutamiento
volverá a calcular las rutas y a enviar nuevos mensajes de actualización de
enrutamiento. Estos mensajes alimentan la red, ordenando a los enrutadores que
vuelvan a ejecutar sus algoritmos y que realicen los cambios necesarios en sus
tablas de enrutamiento. Existen dos formas comunes de enrutamiento dinámico,
incluyendo el enrutamiento de vector distancia y el enrutamiento de estado de
conexión.
Enrutamiento estático Rutas definidas por el usuario que fuerzan a los paquetes que se desplazan entre un
origen y un destino a pasar por una ruta especificada. Los algoritmos de
enrutamiento estático son asignaciones de tabla establecidas por el administrador
de red antes de que comience el enrutamiento. Estas asignaciones no cambian
salvo que el administrador de red las modifique manualmente. Los algoritmos que
utilizan rutas estáticas son fáciles de diseñar y funcionan bien en entornos en los
que el tráfico de red es relativamente predecible y el diseño de la red es
relativamente sencillo.
El software recuerda las rutas estáticas hasta que el usuario las elimina. No
obstante, es posible anular rutas estáticas con información de enrutamiento
dinámico a través de la asignación sensata de valores de distancia administrativa.
Para ello, debe asegurarse de que la distancia administrativa de la ruta estática sea
mayor que la del protocolo dinámico.
Enrutamiento multicast Un método de enrutamiento utilizado para enviar secuencias multimedia a un

grupo de receptores. Los enrutadores habilitados para multicast solamente
transmiten tráfico multicast a los hosts que desean recibir el tráfico. Los hosts
deben señalizar su interés por recibir datos multicast y deben unirse a un grupo
multicast para recibir los datos.
Enrutamiento según el Puede configurar un enrutador virtual en un dispositivo de seguridad para que
origen (SBR) reenvíe el tráfico en función de la dirección de origen del paquete de datos en lugar
de en función de la dirección de destino.
Enrutamiento según la SIBR permite al dispositivo de seguridad reenviar tráfico en función de la interfaz
interfaz de origen de origen (la interfaz por la que el paquete de datos llega al dispositivo de
(SIBR) seguridad).
Enrutamiento sin clase Compatibilidad para el enrutamiento entre dominios, independientemente del
tamaño o la clase de la red. Las direcciones de red se dividen en tres clases, pero
éstas son transparentes en BGP, dando así a la red una mayor flexibilidad.
Envejecimiento Mecanismo para acelerar el proceso del tiempo de espera cuando el número de
agresivo sesiones en la tabla de sesiones sobrepasa un umbral superior especificado. Cuando
el número de sesiones en la tabla cae por debajo de un umbral inferior
especificado, el proceso del tiempo de espera vuelve a su estado normal.
Equilibrio de carga La asignación (o reasignación) de trabajo a dos o más procesadores, con la

intención de mejorar la eficacia de su computación simultánea.
A-VII
Establecimiento de Una conexión de protocolo de control de transmisión (TCP) se establece con un

conexión en tres pasos intercambio triple de paquetes denominado establecimiento de conexión en tres
pasos: A envía un paquete de sincronización (SYN) a B, B responde con un paquete
de sincronización/acuse de recibo (SYN/ACK) y A responde con un paquete de acuse
de recibo (ACK).
Estado agregado Un enrutador se encuentra en estado agregado cuando es una de las múltiples
instancias virtuales de enrutamiento BGP agrupadas en una sola dirección. Consulte
también Protocolo de puerta de enlace de borde (BGP).
Estado de conexión Los protocolos de enrutamiento de estado de conexión funcionan utilizando un

algoritmo conocido comúnmente como algoritmo SPF (Shortest Path First). En
lugar de confiar en información no contrastada procedente de los vecinos
directamente conectados, tal y como sucede en los protocolos de vectores distancia,
cada enrutador en un sistema de estado de conexión actualiza una topología
completa de la red y calcula la información SPF de acuerdo con la topología.
Estados de conexión Cuando un paquete enviado desde un enrutador llega a otro, se produce una
negociación entre los enrutadores de origen y destino. La negociación pasa por seis
estados: Idle, Connect, Active, OpenSent, OpenConnect y Establish.
Ethernet Un sistema de mejor intento de entrega de la red de área local (LAN) que utiliza la
tecnología del acceso múltiple de detección de transportador con detección de
colisión (CSMA/CD). Ethernet se puede utilizar con distintos tipos de cable, como
cable coaxial (grueso o fino), cable de par trenzado o cable de fibra óptica. Ethernet
es una norma para la conexión de equipos a una LAN. La forma más común de
ethernet es 10BaseT, lo que se denomina Par trenzado sin blindaje (UTP), que indica
una velocidad de transmisión de 10 Mbps utilizando un cable de par trenzado de
cobre. Consulte también 100BaseT.
Extensión multiuso para Las extensiones que permiten a los usuarios descargar diferentes tipos de medios
correo de internet electrónicos, como vídeo, audio y gráficas.
(MIME)
Extranet Conexión de dos o más intranets. Una intranet es un sitio web interno que permite
a los usuarios de una empresa comunicarse e intercambiar información. Una
extranet conecta ese espacio virtual con la intranet de otra empresa, permitiendo
así que estas dos (o más) empresas compartan recursos y se comuniquen a través
de Internet en su propio espacio virtual. Esta tecnología mejora enormemente las
comunicaciones de empresa a empresa.
Fast Ethernet Consulte 100BaseT.
Filtrado dinámico Servicio IP que se puede utilizar dentro de túneles VPN. Los filtros son un método
que utilizan algunos dispositivos de seguridad para controlar el tráfico de una red a
otra. Cuando TCP/IP envía paquetes de datos al cortafuegos, la función de filtrado
del cortafuegos localiza la información de encabezado de los paquetes y los dirige
de acuerdo con ella. Los filtros funcionan según criterios tales como el rango de
direcciones IP de origen o de destino, puertos de protocolo de control de
transmisión (TCP), protocolo de datagrama de usuario (UDP), el protocolo de
mensaje de control de Internet (ICMP) o las respuestas TCP. Consulte también
Encapsulamiento; red privada virtual (VPN).
A-VIII
Flap Damping de ruta BGP ofrece una técnica, denominada flap damping, para bloquear la notificación de
la ruta en algún punto próximo al origen hasta que la ruta es estable. El flap
damping de ruta permite contener la inestabilidad de enrutamiento en un
enrutador de borde del sistema autónomo (AS) adyacente a la zona en la que se
está produciendo la inestabilidad. El impacto de la limitación de la propagación
innecesaria es mantener un tiempo de convergencia de cambio de ruta razonable a
medida que se desarrolla la topología de enrutamiento.
GGSN Consulte Nodo de soporte de GPRS de puerta de enlace (GGSN).
G-PDU Un mensaje de datos de usuario que consta de un T-PDU más un encabezado de

protocolo de encapsulamiento de GPRS (GTP). Consulte también T-PDU.
GPRS Consulte Servicio general de radio por paquetes (GPRS).
GRX Consulte Intercambio de itinerancia GPRS (GRX).
GSM Consulte Sistema global para comunicaciones móviles (GSM).
GSN Consulte Nodo de soporte de GPRS (GSN).
GTP Consulte Protocolo de encapsulamiento de GPRS (GTP).
HA Consulte Alta disponibilidad (HA).
HLR Consulte Registro de ubicación local (HLR).
Identidad de estación Un nodo de soporte de GPRS (GSN) identifica una estación móvil por su IMSI, el
móvil internacional cual está compuesto de tres elementos: el MCC (Código móvil del país), el código de
(IMSI) red móvil (MNC) y el número de identificación móvil del abonado (MSIN). El MCC y
el MNC combinados constituyen el prefijo de IMSI e identifican la red local móvil
del abonado o la red móvil terrestre pública (PLMN). Consulte también Nodo de
soporte de GPRS (GSN); Red móvil terrestre pública (PLMN).
Identificador de grupo Un identificador único de 32 caracteres adjunto al encabezado de paquetes

de servicio (SSID) enviados sobre una red de área local inalámbrica (WLAN), que actúa como una
contraseña cuando un dispositivo móvil intenta conectar al grupo de servicio básico
(BSS). SSID diferencia una WLAN de otra, para que todos los puntos de acceso y
todos los dispositivos que intentan conectarse a una WLAN específica deban utilizar
los mismos SSID. Un dispositivo no podría incorporarse a un BSS a menos que
pueda proporcionar el SSID único. Consulte también Conjunto de servicios básicos
(BSS).
Identificador de punto Un índice del contexto de protocolo de datos de paquete (PDP) que utiliza los
de acceso de servicio servicios proporcionados por el protocolo de convergencia dependiente de la
de red (NSAPI) subred de capa más baja (SNDCP). Un PDP puede tener varios contextos de PDP y
NSAPI. Consulte también Protocolo de datos de paquete (PDP).
Identificador de punto Identifica de manera única al punto final del túnel en la entidad de protocolo de
final del túnel (TEID) recepción GTP-U o GTP-C. El lado del extremo de recepción de un protocolo de
encapsulamiento de GPRS (GTP) asigna localmente el valor de TEID que el lado de
transmisión debe utilizar. Los valores de TEID se intercambian entre los puntos
finales del túnel utilizando los mensajes GTP-C. Consulte también Protocolo de
encapsulamiento de GPRS (GTP); Mensaje de GTP-Control (GTP-C); Túnel de GTP;
Mensaje de GTP-Usuario (GTP-U).
A-IX
Identificador del túnel Los paquetes que viajan a través del troncal de GPRS están dentro de una capa de
(TID) direccionamiento adicional para formar los paquetes de protocolo de
encapsulamiento de GPRS (GTP). Cada GTP empaqueta y luego transporta un TID.
Consulte también Sistema global para comunicaciones móviles (GSM).
Indicador de fuerza de Los números se expresan en decibeles (dB) que indican la relación de señal y ruido
la señal recibida (RSSI) (SNR).
Índice de parámetro de Un valor hexadecimal que identifica de forma inequívoca cada túnel. También
seguridad (SPI) indica al dispositivo de seguridad qué clave debe utilizar para desencriptar los
paquetes.
Información de Cada sistema autónomo (AS) dispone de un plan de enrutamiento que indica los
accesibilidad de la capa destinos a los que se puede acceder a través de él. Este plan de enrutamiento se
de red (NLRI) conoce como el objeto NLRI. Los enrutadores BGP generan y reciben
periódicamente actualizaciones del objeto NLRI. Cada actualización contiene
información sobre la lista de sistemas autónomos que atraviesan las cápsulas de
información de accesibilidad. Los valores comunes descritos por una actualización
de NLRI incluyen un número de red, una lista de sistemas autónomos que atraviesa
la información y otros atributos de ruta.
Infranet Una red pública que combina la conectividad común de Internet con el rendimiento
asegurado y la seguridad de una red privada.
Intercambio de claves Método para intercambiar claves de encriptación y autenticación en un medio

de Internet (IKE) inseguro, como Internet.
Intercambio de Ya que la interfaz de Gp está basada en IP, debe ser compatible con los protocolos
itinerancia de GPRS de seguridad y enrutamiento apropiados para permitir que un abonado acceda a
(GRX) sus servicios locales desde cualquiera de sus socios de itinerancia locales de PLMN.
Muchos portadores/operadores de GPRS asumen estas funciones a través del
intercambio de itinerancia de GPRS (GRX). Esta función generalmente la
proporciona una red IP de terceros que ofrece los servicios VPN para conectar los
socios de itinerancia. El proveedor de servicio GRX se asegura que todos los
aspectos de enrutamiento y seguridad entre las redes se optimicen para una
operación eficiente. Consulte también Servicio general de radio por paquetes (GPRS).
Interfaz de seguridad Una entidad lógica de capa 3 vinculada a múltiples interfaces físicas de capa 2 en
virtual (VSI) un grupo de dispositivo de seguridad virtual (VSD). La VSI se asocia a la interfaz
física del dispositivo que actúa como maestro del grupo VSD. La VSI se desplaza a la
interfaz física de otro dispositivo del grupo VSD si se produce una conmutación por
error y dicho dispositivo se convierte en el nuevo maestro.
Interfaz de túnel La abertura o la entrada a través de la que pasa el tráfico entrante o saliente de un
túnel VPN. Una interfaz de túnel puede estar numerada (es decir, asignada a una
dirección IP) o sin numerar. Una interfaz de túnel numerada puede encontrarse en
una zona de túnel o en una zona de seguridad. Una interfaz de túnel sin numerar
sólo puede encontrarse en una zona de seguridad que contenga al menos una
interfaz de zona de seguridad. La interfaz de túnel no numerada toma prestada la
dirección IP de la interfaz de la zona de seguridad.
Interfaz Gi La interfaz entre un GSN y una red externa o Internet. Consulte Nodo de soporte de
GPRS (GSN).
Interfaz Gn La interfaz entre dos GSN dentro de la misma red móvil terrestre pública (PLMN).
A-X
Interfaz Gp La interfaz entre dos GSN dentro de diferentes redes móviles terrestres públicas
(PLMN).
Interfaz loopback Una interfaz lógica que emula una interfaz física en el dispositivo de seguridad,
pero que permanece en estado activo siempre que esté activo el dispositivo. Se
debe asignar una dirección IP a una interfaz de bucle invertido y asociarla a una
zona de seguridad.
Interlocutor Consulte Vecino.
Internet Se trata de un sistema de redes de equipos interconectados a nivel internacional,

que facilita los servicios de comunicación de datos, como acceso remoto,
transferencia de archivos, correo electrónico y grupos de noticias. Internet es una
forma de conectar redes de equipos existentes que supera con creces el alcance de
cada uno de los sistemas que lo integran. También conocida como la Red. Diseñada
originalmente por el Departamento de defensa de Estados Unidos para que una
señal de comunicación pudiera sobrevivir a una guerra nuclear y servir a las
instituciones militares mundialmente. En un primer momento, Internet se conoció
como ARPAnet. Consulte también Intranet.
Intervalo de saludo: Tiempo que transcurre entre instancias de paquetes de saludo. Consulte Paquete de
saludo.
Intervalo muerto Tiempo transcurrido antes de que una instancia de enrutamiento determine que
otra instancia de enrutamiento no se está ejecutando.
Intranet Una intranet, término derivado de Internet, es una red de acceso restringido que
funciona como la Web, aunque no se encuentra en ella. Normalmente es propiedad
de una empresa, que también se encarga de su administración, permitiéndole
compartir sus recursos con sus empleados sin que la información confidencial
pueda quedar accesible a cualquier usuario con acceso a Internet.
Línea asimétrica de Una tecnología de línea de abonado digital (DSL) que permite que las líneas
abonado digital (ADSL) telefónicas transmitan servicios de telefonía de voz y transmisión digital de alta
velocidad. Cada vez más proveedores de servicios ofrecen ADSL a clientes
residenciales y comerciales.
Lista de acceso de la Lista de acceso utilizada por una instancia de enrutamiento de protocolo de puerta
ruta AS de enlace de borde (BGP) para permitir o denegar paquetes enviados por instancias
de enrutamiento vecinas a la instancia de enrutamiento virtual actual.
Lista de accesos Una lista de prefijos de red que se comparan con una ruta determinada. Si la ruta
coincide con un prefijo de red definido en la lista de acceso, la ruta se permitirá o
denegará.
Lista de clústeres Lista de rutas registradas a medida que el paquete pasa a través de un clúster
reflector de rutas BGP.
Lista de control de Identifica clientes por medio de sus direcciones MAC y especifica si el dispositivo
accesos (ACL) inalámbrico autoriza o niega el acceso a cada dirección.
Lista de filtrado Lista de direcciones IP que puede enviar paquetes al dominio de enrutamiento
actual.
Lista de redistribución Lista de rutas del dominio de enrutamiento actual importado a partir de otro
dominio de enrutamiento que utiliza un protocolo distinto.
A-XI
Lista de revocación de Una lista de certificados no válidos.

certificados (CRL)
Localizador de recurso Método estándar desarrollado para especificar la ubicación de un recurso disponible
uniforme (URL) de forma electrónica. Una URL, también denominada ubicación o dirección, indica
la ubicación de archivos en servidores. Una URL general presenta la sintaxis
protocolo://dirección. Por ejemplo, http://www.juniper.net/support/manuals.html
indica que el protocolo es HTTP, y la dirección es
www.juniper.net/support/manuals.html.
Mantenimiento de Tiempo en segundos que transcurre entre los paquetes de mantenimiento de

conexión conexión, que garantiza que la conexión TCP entre el enrutador BGP local y un
enrutador vecino permanezca activa. Este valor es igual a un tercio del tiempo de
espera. El intervalo predeterminado es de 60 segundos.
Mapa de rutas Los mapas de rutas se utilizan en BGP para controlar y modificar la información de
enrutamiento y para definir las condiciones según las cuales las rutas se
redistribuyen entre los dominios de enrutamiento. Un mapa de rutas contiene una
lista de entradas de mapa de rutas; cada una de estas entradas contiene un número
de secuencia y un valor de consigna y otro de coincidencia. Las entradas de mapa
de rutas se evalúan por orden ascendente según el número de secuencia. Una vez
que una entrada proporciona una condición de coincidencia, no se evalúa ningún
mapa de rutas más. Una vez que se encuentra una coincidencia, el mapa de rutas
realiza una operación de permiso o denegación de la entrada. Si la entrada del
mapa de rutas no es una coincidencia, se evalúa la siguiente entrada según los
criterios de coincidencia.
Máscara de red Una máscara de red indica qué parte de una dirección IP corresponde a la
identificación de red, y qué parte corresponde a la identificación de host. Por
ejemplo, la dirección IP y máscara de red 10.20.30.1 255.255.255.0 (o
10.20.30.1/24) se refieren a todos los hosts de la subred 10.20.30.0. La dirección IP
y la máscara de red 10.20.30.1 255.255.255.255 (o 10.20.30.1/32) se refieren a un
único host. Consulte también Dirección IP; Máscara de subred.
Máscara de subred En redes de grandes dimensiones, la máscara de subred permite definir subredes.
Por ejemplo, si tiene una red de clase B, una máscara de subred de 255.255.255.0
indica que las dos primeras partes del formato de punto decimal son la ID de red, y
la tercera parte es la ID de subred. La cuarta parte es la ID de host. Si no desea tener
una subred en una red de clase B, deberá utilizar una máscara de subred de
255.255.0.0. Una red se puede dividir en una o más subredes físicas, que forman
un subconjunto dentro de la red principal. La máscara de subred es la parte de la
dirección IP que se utiliza para representar una subred dentro de una red. El uso de
máscaras de subred permite utilizar espacio de direccionamiento de red que
normalmente no está disponible y garantiza que el tráfico de red no se envíe a toda
la red a menos que esa sea la intención del emisor. Consulte también Dirección IP;
Máscara de red.
MCC Consulte Código de país de móvil (MCC).
MED Consulte Discriminador de salida múltiple (MED).
A-XII
Mensaje de GTP-Control Los mensajes de GTP-C se intercambian entre los pares de nodo de soporte de
(GTP-C) GPRS (GSN) en una ruta. Los mensajes de control se utilizan para transferir
información de capacidad de GSN entre los pares de GSN, para crear, actualizar y
eliminar los túneles del protocolo de encapsulamiento de GPRS (GTP) y para la
administración de rutas. Consulte también Protocolo de encapsulamiento de GPRS
(GTP); Túnel de GTP.
Mensaje de Los mensajes de GTP-U se intercambian entre los pares de nodo de soporte de
GTP-Usuario (GTP-U) GPRS (GSN) o pares de GSN/controlador de red de radio (RNC) en una ruta. Los
mensajes de GTP-U se utilizan para llevar los paquetes de datos de usuario y
señalizar los mensajes para una administración de ruta e indicación de error. Los
datos de usuario transportado pueden ser paquetes en cualquier formato de IPv4,
IPv6 o PPP.
Mensaje de Los mensajes del protocolo de encapsulamiento de GPRS (GTP) se intercambian

señalización entre los pares de nodo de soporte de GPRS (GSN) en una ruta. Los mensajes se
utilizan para transferir información de capacidad de GSN entre los pares de GSN,
para crear, actualizar y eliminar los túneles de GTP. Consulte G-PDU.
Metrica Valor asociado a una ruta que utiliza el enrutador virtual para seleccionar la ruta
activa cuando hay varias rutas hacia 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 se puede especificar un valor
diferente cuando se definen estas rutas.
Miembro AS El nombre del sistema autónomo (AS) que se incluye en una confederación de
protocolo de puerta de enlace de borde (BGP).
MIME Consulte Extensión multiuso para correo de internet de varios propósitos (MIME).
MIP Consulte Dirección IP asignada (MIP).
MNC Consulte Código de red de móvil (MNC).
Modo de puerto Función compatible con algunos dispositivos de seguridad Juniper Networks; el
modo de puerto permite seleccionar uno de entre varios conjuntos distintos de
asociaciones de zona, puerto e interfaz en el dispositivo. Cambiar el modo de
puerto elimina cualquier configuración existente en el dispositivo y requiere
reiniciar el sistema.
MSIN Consulte Número de identificación de abonado de móvil (MSIN).
Multicast Un protocolo de enrutamiento multicast que se ejecuta entre enrutadores para

independiente de reenviar el tráfico multicast a los miembros multicast del grupo a través de la red. El
protocolo (PIM) modo PIM-Dense (PIM-DM) inunda toda la red con tráfico multicast y luego corta las
rutas hacia los receptores que no desean recibir tráfico multicast. El modo
PIM-Sparse (PIM-SM) reenvía tráfico multicast solamente a los receptores que lo
soliciten.
Multicast independiente de protocolo – Modo específico de origen (PIM-SSM) es

derivado de PIM-SM, y como PIM-SM, reenvía el tráfico multicast únicamente a los
receptores interesados. A diferencia de PIM-SM, forma inmediatamente un SPT al
origen.
NAT Consulte Traducción de direcciones de red (NAT).
A-XIII
NAT-dst Consulte Traducción de dirección de red de destino (NAT-dst).
NAT-src Consulte Traducción de direcciones de red (NAT).
NAT-Traversal (NAT-T): Método que permite que el tráfico IPSec atraviese los dispositivos NAT situados a lo
largo de la ruta de datos de una red privada virtual (VPN) agregando una capa de
encapsulamiento de protocolo de datagrama de usuario (UDP). En primer lugar, el
método proporciona un medio para detectar dispositivos NAT durante intercambios
IKE de fase 1 y, a continuación, proporciona un medio para atravesarlos una vez
completadas las negociaciones IKE de fase 2.
Nodo de soporte de Un término que se utiliza para incluir tanto el nodo de soporte de GPRS de puerta
GPRS (GSN) de enlace (GGSN) como el nodo de soporte de GPRS de servicio (SGSN). Consulte
también Servicio general de radio por paquetes (GPRS).
Nodo de soporte de Un dispositivo que actúa como una interfaz entre la red troncal de GPRS y las redes
GPRS de puerta de de datos de paquetes externos (radio e IP). Entre otras cosas, una GGSN convierte
enlace (GGSN) los paquetes GPRS que vienen de una SGSN en el formato de protocolo de datos de
paquete (PDP) apropiado y los envía a la PDN correspondiente. Una GGSN también
lleva a cabo las funciones de carga y autenticación. Consulte también Servicio
general de radio por paquetes (GPRS).
Nodo de soporte de Conecta uno o más controladores de estación base (BSC) a la red troncal GPRS,
GPRS de servicio proporcionando la conectividad de IP al nodo de soporte de GPRS de puerta de
(SGSN) enlace (GGSN).
Nombre de punto de Un elemento de información (IE) incluido en el encabezado de un paquete de GTP

acceso (APN) que proporciona información sobre cómo acceder a una red. Está compuesto de un
ID de red y un ID de operador.
Norma de encriptación El texto del mensaje, y si es necesario, las firmas de mensaje se pueden encriptar
de datos – utilizando el algoritmo de Norma de encriptación de datos (DES9 en el modo de
Encadenamiento de operación de Encadenamiento de encriptación de datos (CBC). La cadena de
bloques de cifrado caracteres “DES-CBC” dentro del campo de encabezado de correo mejorado de
(DES-CBC) privacidad (PEM) encapsulado indica el uso de DES–CBC.
Norma de encriptación Algoritmo de encriptación de 40 y 56 bits desarrollado por el National Institute of

de datos (DES) Standards and Technology (NIST). DES es un método de encriptación de bloques
desarrollado originalmente por IBM. Ha sido certificado por el Gobierno de los
Estados Unidos para la transmisión de cualquier información que no esté
clasificada como de “alto secreto”. DES utiliza un algoritmo para la encriptación de
claves privadas. Esta clave está formada por 64 bits de datos, que se transforman y
combinan con los primeros 64 bits del mensaje que se vaya a enviar. Para aplicar la
encriptación, el mensaje se divide en bloques de 64 bits, de forma que cada uno de
ellos se pueda combinar con la clave utilizando un complejo proceso de 16 pasos.
Aunque DES es bastante débil, con sólo una iteración, su repetición utilizando
claves ligeramente distintas puede ofrecer unos excelentes niveles de seguridad.
Notificación Método que utilizan los enrutadores para anunciarse a otros dispositivos en la red
transmitiéndoles información básica, como dirección IP, máscara de red y otros
datos.
A-XIV
Notificación de estado Medio que permite a los enrutadores OSPF poner la información sobre el
de conexiones dispositivo, la red y el enrutamiento a disposición de la base de datos de estado de
conexiones. Cada enrutador recupera información de las LSA enviadas por otros
enrutadores en la red para construir una imagen de toda la red de Internet a partir
de la cual cada instancia de enrutamiento destilará la información de ruta que
utilizará en su tabla de enrutamiento.
NSAPI Consulte Identificador de punto de acceso de servicio de red (NSAPI).
NSGP Consulte Protocolo de equipo selector NetScreen (NSGP).
NSRP Consulte Protocolo de redundancia de NetScreen (NSRP).
Número de AS Número de identificación del sistema autónomo (AS) local asignado a una instancia
de enrutamiento del protocolo de puerta de enlace de borde (BGP). El número de ID
puede ser cualquier número entero válido.
Número de Uno de los tres elementos de una Identidad de estación móvil internacional (IMSI);
identificación de los otros dos son el código de país móvil (MCC) y el código de red móvil (MNC).
abonado de móvil Consulte también Identidad de estación móvil internacional (IMSI).
(MSIN)
Objeto en tiempo de Objeto de código creado de forma dinámica en la memoria durante el

ejecución (RTO) funcionamiento normal. Algunos ejemplos de RTO son: entradas de la tabla de
sesiones, entradas de caché ARP, certificados, concesiones DHCP y asociaciones de
seguridad (SA) IPSec de fase 2.
Objetos de ataque Firmas de estado completo y anomalías de protocolos que un dispositivo de

seguridad con función Deep Inspection (DI) utiliza para detectar los ataques
dirigidos comprometiendo a uno o varios hosts de una red.
Paquete de saludo Paquete que anuncia a la red información, como su presencia y disponibilidad,
acerca del enrutador que generó el paquete.
Par trenzado sin Consulte 10BaseT. Consulte también 100BaseT.

blindaje (UTP)
PDU Consulte Unidad de datos de protocolo.
PIM Consulte Multicast independiente del protocolo (PIM).
PLMN Consulte Red móvil terrestre pública (PLMN).
Preferencia Valor asociado a una ruta que utiliza el enrutador virtual para seleccionar la ruta
activa cuando hay varias rutas hacia la misma red de destino. El valor de
preferencia está determinado por 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.
Preferencia local Para proporcionar una información mejor que la que del valor MED (Multi-Exit
Discriminator) para seleccionar una ruta de paquete, BGP ofrece un atributo
conocido como LOCAL_PREF o valor de preferencia local. Puede configurar el
atributo LOCAL_PREF de modo que los prefijos recibidos desde un enrutador que
proporcione una ruta configurada como superior tengan un valor superior a los
A-XV
prefijos almacenados en el enrutador que ofrezca una ruta menos deseable. Cuanto
mayor sea el valor, más deseable será la ruta. El atributo LOCAL_PREF es la métrica
más utilizada en la práctica para expresar la preferencia de un conjunto de rutas
sobre otro.
Prefijo Dirección IP que representa una ruta.
Primera ruta más corta Protocolo de enrutamiento dinámico concebido para funcionar dentro de un único
abierta (OSPF) sistema autónomo (AS).
Privacidad equivalente Encripta y desencripta los datos a medida que pasan a través del enlace
a cableado (WEP) inalámbrico con el algoritmo de cifrado de secuencia Rivest Cipher 4 (RC4).
Propuesta En ingeniería de seguridad, una propuesta es un “número utilizado una vez”,

generalmente un número aleatorio o seudo-aleatorio emitido en un protocolo de
autenticación para asegurarse que las comunicaciones anteriores no se puedan
volver a utilizar en “ataques de reprocesamiento”. Por ejemplo, las propuestas se
utilizan en la autenticación de acceso de síntesis de HTTP para calcular una síntesis
de MD5 de la contraseña. Las propuestas son diferentes cada vez que se presenta el
código de respuesta al desafío de autenticación 401, por lo tanto el ataque de
reprocesamiento es virtualmente imposible.
Protocolo de Protocolo que se ejecuta entre los hosts y los enrutadores para comunicar la
administración de información de miembros del grupo multicast.
grupos de Internet
(IGMP)
Protocolo de Un conjunto de reglas que permite que equipos con distintos sistemas operativos se
comunicaciones comuniquen entre sí.
Protocolo de Método para asignar automáticamente direcciones IP a hosts en una red. Según el
configuración dinámica modelo de dispositivo específico, los dispositivos de seguridad pueden asignar
de hosts (DHCP) direcciones IP dinámicas a hosts, recibir direcciones IP asignadas dinámicamente o
recibir información DHCP desde un servidor DHCP y reenviar la información a los
hosts.
Protocolo de control de Un grupo de protocolos de comunicación que admiten las funciones de

transmisión/protocolo conectividad de interlocutor a interlocutor para las redes de área local (LAN) y para
de Internet (TCP/IP) las redes de área extensa (WAN). TCP/IP controla el modo en que los datos se
transfieren entre los equipos a través de Internet. Consulte Protocolos de
comunicación .
Protocolo de control del RTCP ofrece información sobre los miembros de una sesión y la calidad de la
transporte en tiempo comunicación. Sincroniza secuencias multimedia asociando marcas de hora y un
real (RTCP) reloj en tiempo real.
Protocolo de Protocolo incluido en el conjunto de protocolos TCP/IP permite que un programa de

datagramas de usuario aplicación envíe datagramas a otros programas de aplicación de un equipo remoto.
(UDP) UDP proporciona un servicio de datagrama confiable y sin conexión en el que no
están garantizadas ni la entrega ni la detección de duplicados. No utiliza acuses de
recibo ni controla el orden de llegada.
Protocolo de datos de Los protocolos principales que se utilizan para las comunicaciones de datos en un
paquete (PDP) PDN, por ejemplo, TCP/IP en Internet.
A-XVI
Protocolo de Las descripciones de sesión SDP aparecen en numerosos mensajes SIP y ofrecen
descripción de la sesión información que puede utilizar un sistema para participar en una sesión
(SDP) multimedia. El protocolo SDP puede proporcionar datos como direcciones IP,
números de puerto, fechas y horas, o información sobre la secuencia multimedia.
Protocolo de Un protocolo basado en IP que se utiliza dentro de las redes del sistema global para
encapsulamiento de comunicaciones móviles (GSM) y sistema de telecomunicaciones móviles
GPRS (GTP) universales (UMTS). GTP está colocada en capas en la parte superior del protocolo
de datagrama de usuario (UDP). Actualmente existen tres protocolos separados:
GTP’, GTP-Control (GTP-C) y GTP User (GTP-U). Consulte también Servicio general de
radio por paquetes (GPRS); Mensaje de GTP-Control (GTP-C) ; Mensaje de GTP-User
(GTP-U).
Protocolo de equipo El protocolo patentado de Juniper Networks que utiliza el protocolo de control de
selector NetScreen transmisión (TCP) y supervisa la conectividad entre el cliente y el servidor al enviar
(NSGP) los mensajes de saludo en intervalos establecidos.
Protocolo de estado de Cuando un dispositivo de seguridad realiza una operación en la que se utiliza un
certificado en línea certificado, suele ser importante verificar su validez. Los certificados pueden
(OCSP) 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.
Protocolo de Protocolo de enrutamiento dinámico utilizado en sistemas autónomos de tamaño

información de moderado.
enrutamiento (RIP)
Protocolo de inicio de SIP es un protocolo conforme a la norma del equipo de ingeniería para el desarrollo
sesión (SIP) 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.
Protocolo de Internet Protocolo estándar de Internet que define una unidad básica de datos denominada
(IP) un datagrama, el cual se utiliza en un sistema sin conexiones de entrega de mejor
esfuerzo. El protocolo IP define el modo en que la información pasa entre sistemas
a través de Internet.
Protocolo de mensajes En ocasiones, las puertas de enlace o los hosts de destino utilizan ICMP para
de control de Internet comunicarse con hosts de origen, por ejemplo, para informar de un error durante el
(ICMP) procesamiento de datagramas. ICMP utiliza el soporte básico del protocolo IP como
si se tratara de un protocolo de nivel superior; aunque en realidad, el protocolo
ICMP forma parte integral de IP, por lo que debe implementarlo cada módulo IP. Los
mensajes ICMP se envían en distintas situaciones: por ejemplo, cuando un
datagrama no puede llegar a su destino, cuando la puerta de enlace no tiene
capacidad de búfer suficiente para reenviar un datagrama o cuando la puerta de
enlace puede hacer que el host envíe tráfico por una ruta más corta. El protocolo de
Internet (IP) no se ha diseñado para que sea absolutamente fiable. El objetivo de
estos mensajes de control es informar sobre problemas en el entorno de
comunicaciones, no hacer de IP un protocolo fiable.
Protocolo de puerta de Protocolo de enrutamiento interno de un sistema autónomo. Los enrutadores BGP y
enlace de borde (BGP) los sistemas autónomos intercambian información de enrutamiento para Internet.
A-XVII
Protocolo de Protocolo patentado que ofrece redundancia de objetos en tiempo real (RTO) y
redundancia de configuración, así como un mecanismo de conmutación por error de dispositivos
NetScreen (NSRP) para unidades de seguridad en un clúster de alta disponibilidad (HA).
Protocolo de seguridad Los protocolos de seguridad en el nivel de IP (AH y ESP), fueron propuestos
de encapsulado/ originalmente por el Network Working Group centrándose en los mecanismos de
Encabezado de la seguridad IP, IPSec. El término IPSec se utiliza libremente para hacer referencia a
autenticación paquetes, claves y enrutadores asociados a estos protocolos. El protocolo IP AH
(ESP/AH) proporciona autenticación. ESP proporciona tanto autenticación como encriptación.
Protocolo de seguridad Consulte Protocolo de seguridad de encabezado/Encabezado de la autenticación

encapsulada (ESP) (ESP/AH).
Protocolo de transporte RTP se utiliza para garantizar la recepción de paquetes en orden cronológico
en tiempo real (RTP) asignando marcas de hora y números de secuencia al encabezado del paquete.
Cada sesión RTP tiene una sesión RTCP correspondiente. Consulte Protocolo de
control de transporte en tiempo real (RTCP).
Protocolo punto a punto Permite que varios usuarios de un sitio compartan la misma línea de abonado
sobre Ethernet (PPPoE) digital, el mismo módem de cable o la misma conexión inalámbrica a Internet. Es
posible configurar instancias de cliente PPPoE, incluyendo nombre de usuario y
contraseña, en una o en todas las interfaces de algunos dispositivos de seguridad.
Proxy de circuito Los servidores de proxy se encuentran disponibles para los servicios comunes de
Internet, por ejemplo, un proxy http se utiliza para acceso de Web, un proxy FTP se
utiliza para la transferencia de archivos. Algunos proxies se denominan proxies a
nivel de de aplicación o puertas de enlace a nivel aplicación, ya que se dedican a un
protocolo y aplicación determinada y conocen el contenido de los paquetes a
enviar. Un proxy genérico, denominado un proxy de circuito, admite varias
aplicaciones. Por ejemplo, SOCKS es un servidor proxy genérico con base en IP que
admite las aplicaciones de TCP y UDP. Consulte también Servidor proxy.
PT Consulte Tipo de protocolo (PT).
Puente Dispositivo que reenvía tráfico entre segmentos de red de acuerdo con la
información de la capa de enlace de datos. Estos segmentos comparten un espacio
de direcciones de capa de red en común.
Puerta de enlace También denominada enrutador, una puerta de enlace es un programa o un

dispositivo con finalidad específica que transfiere datagramas IP de una red a otra
hasta alcanzar su destino final.
Puerta de enlace en la En un dispositivo de seguridad, un componente de software diseñado para

capa de aplicación gestionar protocolos específicos como el protocolo de iniciación de sesión (SIP) o
(ALG) protocolo de transferencia de archivos (FTP). La ALG intercepta y analiza el tráfico
especificado, localiza los recursos y define directivas dinámicas que permitan el
paso seguro del tráfico a través del dispositivo de seguridad.
Puerta de enlace IP También denominada enrutador, una puerta de enlace es un programa o un

dispositivo con finalidad específica que transfiere datagramas IP de una red a otra
hasta alcanzar su destino final.
Puerto troncal Un puerto troncal permite a un conmutador agrupar tráfico de varias VLAN por un
único puerto físico, clasificando los paquetes por la identidad de VLAN (VID) de los
encabezados de las tramas.
A-XVIII
Punto de acceso Conecta una red inalámbrica con una red cableada o conecta redes inalámbricas
inalámbrico (WAP) múltiples entre sí. También se puede referir al dispositivo inalámbrico
NetScreen-5GT como WAP.
Punto de encuentro Un enrutador en la raíz del árbol de distribución multicast. Todos los orígenes de un
(RP) grupo envían sus paquetes al RP, y el RP envía datos en dirección descendente por
el árbol de distribución compartido a todos los receptores de la red.
Rango de áreas Secuencia de direcciones IP definidas por un límite inferior y otro superior que
indica una serie de direcciones de dispositivos existentes dentro de un área.
Red de área local (LAN) Cualquier tecnología de red que interconecta recursos dentro de un entorno de
oficina, normalmente a alta velocidad, como p. ej. Ethernet. Una LAN es una red de
corta distancia utilizada para enlazar un grupo de equipos entre sí dentro de un
edificio. Ethernet 10BaseT es la forma más común de LAN. Un dispositivo de
hardware llamado concentrador (hub) sirve como punto de cableado común,
permitiendo el envío de datos de una máquina a otra dentro de la red. Las LAN
suelen estar limitadas a distancias de menos de 500 metros y ofrecen capacidades
de red de bajo coste y banda ancha dentro de un área geográfica pequeña.
Red de área local Agrupación de dispositivos más lógica que física que constituye un único dominio
virtual (VLAN) de difusión. Los miembros VLAN no se identifican por su ubicación en una subred
física, sino por el uso de etiquetas en los encabezados de las tramas de sus datos
transmitidos. Las VLAN se describen en la norma IEEE 802.1Q.
Red de difusión Una red que admite varios enrutadores con capacidad para comunicarse
directamente entre sí. Ethernet es un ejemplo de red de difusión.
Red móvil terrestre Una red pública dedicada a la operación de comunicaciones de radio móviles.
pública (PLMN)
Red privada virtual Un medio sencillo, rentable y seguro para las empresas que permite ofrecer a los
(VPN) teletrabajadores un acceso telefónico local a la red de la empresa o a otro proveedor
de servicios de Internet (ISP). Las conexiones privadas seguras a través de Internet
son más económicas que las líneas privadas especializadas. Las VPN son posibles
gracias a tecnologías y normas como el encapsulado, el análisis, la encriptación e
IPSec.
Redistribución Proceso de importación de una ruta al dominio de enrutamiento actual de otra

parte de la red que utiliza otro protocolo de enrutamiento. Cuando esto ocurre, el
dominio actual tiene que traducir toda la información, en particular las rutas
conocidas, del otro protocolo. Por ejemplo, si se encuentra en una red OSPF y se
conecta a una red BGP, el dominio OSPF tendrá que importar todas las rutas de la
red BGP para informar a todos sus dispositivos sobre cómo acceder a todos los
dispositivos de la red BGP. El recibo de toda la información de rutas se denomina
redistribución de rutas.
Redistribución de rutas Exportación de las reglas de ruta de un enrutador virtual a otro.
Reenvío por rutas Un método utilizado por los enrutadores multicast para comprobar la validez de los
inversas paquetes multicast. Un enrutador realiza operaciones de búsqueda 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.
A-XIX
Reflector de ruta Enrutador cuya configuración del protocolo de puerta de enlace de borde (BGP)
permite volver a notificar rutas entre vecinos BGP internos (IBGP) o vecinos
ubicados en el mismo sistema autónomo (AS) BGP. Un cliente reflector de rutas es
un dispositivo que utiliza un reflector de rutas para volver a notificar sus rutas a
todo el AS. También depende de dicho reflector de rutas para averiguar información
sobre las rutas del resto de la red.
Registro de ubicación Un túnel GTP se identifica en cada modo con un identificador de punto final de
local (HLR) túnel (TEID), una dirección de IP y un número de puerto UDP.
Reglas de exportación Cuando tenemos dos o más enrutadores virtuales en un dispositivo de seguridad,
podemos configurar reglas de exportación que definirán las rutas de un enrutador
virtual que puede reconocer y memorizar otro enrutador virtual. Consulte también
Reglas de importación.
Reglas de importación Cuando tenemos dos o más enrutadores virtuales en un dispositivo de seguridad,
podemos configurar reglas de importación que definirán las rutas que un enrutador
virtual puede reconocer y memorizar. Si no se configuran reglas de importación
para un enrutador virtual, se aceptarán todos los enrutadores que se exporten a ese
enrutador virtual. Consulte también Reglas de exportación.
Relación de señal y La relación de la amplitud de una señal deseada de datos digitales o análogos a la
ruido (SNR) amplitud de ruido en un canal de transmisión en un punto específico en el tiempo.
SNR se expresa generalmente de manera logarítmica en decibeles (dB).
RJ-45 Semejante a un conector telefónico estándar, un conector RJ-45 tiene el doble de

ancho (con ocho conductores) y se utiliza para conectar equipos a redes de área
local (LAN) o teléfonos con múltiples líneas.
RSSI Consulte Indicador de fuerza de la señal recibida (RSSI).
Ruta AS Lista de todos los sistemas autónomos que una actualización de enrutador ha
atravesado durante la transmisión actual.
Ruta multidireccional ECMP asiste con equilibrio de cargas entre dos a cuatro rutas al mismo destino o
de igual coste (ECMP) aumenta la eficacia de utilización del ancho de banda entre dos o más destinos.
Cuando están habilitados, 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 sde eguridad asigna rutas de
igual coste en el modo de ronda recíproca. Valor predeterminado: desactivado
Ruta predeterminada Una entrada de tabla de enrutamiento comodín que define el reenvío de tráfico
para redes de destino que no están definidas de forma explícita en la tabla de
enrutamiento. La red de destino para la ruta predeterminada se representa con la
dirección de red 0.0.0.0/0.
Seguimiento de IP Mecanismo para supervisar direcciones IP configuradas y comprobar si responden

a peticiones de comando ping o a peticiones ARP. Puede configurar el seguimiento
de IP con NSRP para determinar la conmutación por error de un dispositivo o un
grupo VSD. También puede configurar el seguimiento de IP en una interfaz de
dispositivo para determinar si la interfaz está activa o inactiva.
A-XX
Seguridad IP (IPSec) Norma de seguridad desarrollada por el equipo de ingeniería para el desarrollo de
Internet (IETF). Se trata de un conjunto de protocolos que ofrece autenticación,
integridad y confidencialidad para asegurar las comunicaciones y soportar los
intercambios de claves en redes aún más grandes. Consulte también Norma de
encriptación de datos – Encadenamiento de bloque de cifrado (DES-CBC); Protocolo de
seguridad de encapsulamiento/Encabezado de autenticación (ESP/AH).
Servicio de nombres de Un servicio para asignar direcciones de protocolo de Internet (IP) a nombres de
Internet de Windows equipos NetBIOS en redes basadas en servidores Windows NT. Los servidores WINS
(WINS) asignan un nombre NetBIOS utilizado en un entorno de red Windows a una
dirección IP utilizada en una red basada en IP.
Servicio general de Un servicio de datos móviles disponibles a los usuarios de teléfonos móviles del
radio por paquetes sistema global para comunicaciones móviles (GSM). Generalmente se describe
(GPRS) como 2.5G, quiere decir, una tecnología entre la telefonía móvil de segunda
generación (2G) y tercera generación (3G). GPRS proporciona la transferencia de
datos de velocidad moderada al utilizar los canales de Acceso múltiple de división
de tiempo (TDMA) en la red de GSM.
Servicio general de Una tecnología con base en paquetes que permite Internet inalámbrica de alta
radio por paquetes velocidad y otras comunicaciones de datos. GPRS proporciona de tres a cuatro
(GPRS) veces más velocidad que los sistemas del sistema global para comunicaciones
móviles (GSM) convencionales.
Servidor proxy También denominado proxy, un servidor proxy es una técnica utilizada para captar
información en un servidor Web y actuar como un intermediario entre el cliente
Web y ese servidor Web. Almacena el contenido de Web utilizado más
recientemente y más comúnmente para proporcionar un acceso más rápido y para
aumentar la seguridad del servidor. Esto suele aplicarse a un ISP específicamente si
su conexión a Internet es lenta. Consulte también Proxy de circuito.
Shell seguro (SSH) Protocolo que permite a los administradores del dispositivo gestionar de forma
remota el dispositivo de modo seguro. En el dispositivo de seguridad se puede
ejecutar un servidor SSH de versión 1 o de versión 2.
Siguiente salto En la tabla de enrutamiento, una dirección IP a la que se reenvía el tráfico para la
red de destino. El siguiente salto también puede ser otro enrutador virtual en el
mismo dispositivo de seguridad.
Síntesis de mensaje 5 La síntesis de mensaje [versión] 5, algoritmo que produce una codificación de
(Message Digest, MD5) mensaje de 128 bits (o hash) a partir de un mensaje de longitud arbitraria. El hash
resultante se utiliza a modo de huella dactilar de la entrada, para verificar su
autenticidad.
Sistema autónomo (AS) Un conjunto de enrutadores independientes del resto de la red y gobernados por
una única administración técnica. Este grupo de enrutadores utiliza uno o varios
protocolos de puerta de enlace interior (IGP) y métricas comunes para enrutar
paquetes dentro del grupo. El grupo también utiliza un protocolo de puerta de
enlace exterior (EGP) para enrutar paquetes a otros sistemas autónomos. Cada AS
dispone de un plan de enrutamiento que indica los destinos a los que se puede
acceder a través de él. Este plan se conoce como objeto NLRI (“Network Layer
Reachability Information”). Los enrutadores de protocolo de puerta de enlace de
borde (BGP) generan y reciben periódicamente actualizaciones del objeto NLRI.
A-XXI
Sistema de nombres de Almacena información sobre los nombres de host y los nombres de dominio en un
dominio (DNS) tipo de base de datos distribuidos en redes como Internet. De los muchos tipos de
información que se pueden almacenar, DNS proporciona con más importancia una
ubicación física (dirección IP) para cada nombre de dominio y enumera los
servidores de cambio de correo aceptando el correo electrónico para cada dominio.
DNS permite que se transmita la información técnica en una manera interpretable

por las personas. Aunque las computadoras y el hardware de red trabajan con
direcciones IP (tal como 207.17.137.68) para realizar tareas como el
direccionamiento y enrutamiento, para las personas resulta más fácil trabajar con
nombres de host y nombres de dominio (como www.juniper.com) en URL y
direcciones de correo electrónico. Por lo tanto DNS media entre las necesidades y
preferencias de las personas y del software traduciendo los nombres de dominio a
direcciones IP, como www.juniper.net = 207.17.137.68.
Sistema global para Una norma globalmente aceptaba para la comunicación celular digital. GSM es el
comunicaciones nombre de un grupo de normalización establecido en 1982 para crear una norma
móviles (GSM). de teléfonos móviles de Europa común que formula las especificaciones para un
sistema de radio celular móvil paneuropeo que opera a 900 MHz.
Sistema virtual (vsys) Una subdivisión del sistema principal que para el usuario aparece como una
entidad independiente. Los sistemas virtuales residen de forma independiente
entre sí en el mismo dispositivo de seguridad. Cada uno puede estar gestionado por
su propio administrador de sistema virtual.
SSID Consulte Identificador de grupo de servicios (SSID).
Subinterfaz Una división lógica de una interfaz física que ocupa el ancho de banda que necesita
de la interfaz física de la que procede. Una subinterfaz es un elemento abstracto con
funciones idénticas a las de una interfaz de un puerto con presencia física, de la que
se diferencia por el etiquetado VLAN 802.1Q.
Syslog Protocolo que permite a un dispositivo enviar mensajes de registro a un host donde
se esté ejecutando el demonio syslog (servidor syslog). El servidor syslog recopila y
almacena estos mensajes de registro de forma local.
Tabla de enrutamiento Lista almacenada en la memoria de un enrutador virtual que contiene una vista en
tiempo real de todas las redes conectadas y remotas hacia las que un enrutador está
encaminando paquetes en ese momento.
TEID Consulte Identificador de punto final del túnel (TEID).
TID Consulte Identificador del túnel (TID).
Tiempo de espera En OSPF, tiempo máximo entre instancias para iniciar cálculos SPF (Shortest Path
First, iniciar primero la ruta más corta). En BGP, el tiempo máximo que transcurre
entre transmisiones de mensajes entre un interlocutor BGP y su vecino.
T-PDU La carga que está encapsulada en el túnel de protocolo de encapsulamiento de

GPRS (GTP).
Traducción de Traducción del número de puerto de origen inicial en un paquete a un número de

direcciones de puertos puerto distinto designado al azar.
(PAT)
A-XXII
Traducción de Traducción de la dirección IP de origen de un encabezado de paquete a otra

direcciones de red dirección IP distinta. Las direcciones IP de origen traducidas pueden proceder de un
(NAT) conjunto de direcciones IP dinámicas (DIP) o de la dirección IP de la interfaz de
salida. Cuando del dispositivo de seguridad toma direcciones de un conjunto DIP,
puede hacerlo de forma dinámica o determinista. En el primer caso, toma
arbitrariamente una dirección del conjunto DIP y traduce la dirección IP de origen
inicial a la dirección seleccionada al azar. En el segundo caso, utiliza un
desplazamiento de direcciones para traducir la dirección IP de origen a una
dirección IP predeterminada en el rango de direcciones que constituyen el
conjunto. Cuando el dispositivo de seguridad utiliza la dirección IP de la interfaz de
salida, traduce todas las direcciones IP de origen iniciales a la dirección de la
interfaz de salida.
Cuando la dirección traducida procede de un conjunto DIP con desplazamiento de

direcciones, no es posible realizar la traducción de la dirección del puerto de origen.
Cuando la dirección traducida procede de un conjunto DIP sin desplazamiento de
direcciones, la traducción del puerto es opcional. Cuando la dirección traducida
procede de la interfaz de salida, se requiere la traducción del puerto.
NAT también se denomina NAT-src para distinguirlo de la traducción de direcciones

de red de destino (NAT-dst).
Traducción de Traducción de la dirección IP de destino original en un encabezado de paquete a

direcciones de red de otra dirección de destino. ScreenOS admite la traducción de una o varias
destino (NAT-dst) direcciones IP de destino originales a una sola dirección IP (relaciones uno con uno
o varios con uno). El dispositivo de seguridad también permite la traducción de un
rango de direcciones IP a otro rango (relación varios con varios) utilizando el
desplazamiento de direcciones.
Cuando el dispositivo de seguridad lleva a cabo NAT-dst sin desplazamiento de

direcciones también puede asignar el número de puerto de destino a un número de
puerto predeterminado distinto. Cuando el dispositivo de seguridad lleva a cabo
NAT-dst con desplazamiento de direcciones, no puede realizar también la
asignación de puertos.
Túnel GTP Un túnel de protocolo de encapsulamiento de GPRS (GTP) en el plano de GTP-U se

define para cada contexto de protocolo de datos de paquete (PDP) en los GSN. Un
túnel GTP en el plano GTP-C está definido para todos los contextos de PDP con la
misma dirección PDP y nombre de punto de acceso (APN) para los mensajes de
administración de túnel o para cada estación móvil (MS) para mensajes que no
están relacionados con la administración de túnel. Un túnel GTP se identifica en
cada modo con un identificador de punto final de túnel (TEID), una dirección IP y
un número de puerto UDP. Un túnel GTP es necesario para reenviar paquetes entre
una red externa y un usuario de MS.
Unidad de datos de 1. Información que se entrega como una unidad entre entidades homólogas de una
protocolo (PDU) red y que puede contener información de control, información de dirección o datos.
2. En sistemas en capas, una unidad de datos que está especificada en un protocolo

para una capa determinada y que consta de información de protocolo y control (y
posiblemente datos de usuario) para la capa.
Unidad de datos de Cualquier mensaje GTP-C o GTP-U. Consulte también Protocolo de encapsulamiento
protocolo de GTP de GPRS (GTP).
(GTP-PDU)
A-XXIII
Vecino Para comenzar a configurar una red BGP, primero hay que establecer una conexión
entre el dispositivo actual y otro dispositivo adyacente homólogo denominado
vecino o interlocutor. Aunque este dispositivo homólogo puede parecer información
innecesaria al principio, en realidad es un componente central para el
funcionamiento de BGP. Al contrario que en RIP u OSPF, deberá configurar dos
dispositivos (el enrutador actual y su vecino) para que BGP funcione. Aunque este
método requiere un mayor esfuerzo, permite una conexión en red a gran escala ya
que BGP evita la implementación de las técnicas de notificación limitadas
inherentes a los estándares de red interior.
Hay dos tipos de vecinos BGP: vecinos internos, que se encuentran en el mismo
sistema autónomo (AS), y vecinos externos, que se encuentran en sistemas
autónomos distintos. Entre los vecinos se requiere una conexión fiable, que se
consigue creando una conexión TCP entre los dos dispositivos. El establecimiento
de comunicación que ocurre entre los dos vecinos potenciales pasa por una serie de
fases o estados antes de que sea posible realizar una verdadera conexión. Consulte
también Estados de conexión.
Vecinos externos Dos enrutadores de protocolo de puerta de enlace de borde (BGP) que residen en
dos sistemas autónomos diferentes. Consulte Protocolo de puerta de enlace de borde
(BGP).
Vector distancia Estrategia de enrutamiento basada en un algoritmo que funciona con una serie de
enrutadores que difunden esporádicamente copias enteras de su propia tabla de
enrutamiento a todos los vecinos conectados directamente. Esta actualización
identifica las redes que conoce cada enrutador y la distancia entre cada una de esas
redes. La distancia se mide en número de saltos o en el número de dominios de
enrutamiento que un paquete debe atravesar entre el dispositivo de origen y el
dispositivo al que intenta acceder.
WAP Consulte Punto de acceso inalámbrico (WAP).
WebTrends Producto ofrecido por NetIQ que admite la creación de informes personalizados
basados en los registros generados por un dispositivo de seguridad. WebTrends
permite que la información se visualice gráficamente.
WEP Consulte Privacidad equivalente a cableado (WEP).
WPA Consulte Acceso protegido de Wi-Fi (WPA).
XAuth Un protocolo formado por dos componentes: autenticación de usuarios VPN

remotos (nombre del usuario y contraseña) y asignaciones de direcciones TCP/IP
(dirección IP, máscara de red y asignaciones de servidores DNS y servidores WINS).
Zona 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).
Zona de seguridad Una zona de seguridad es un conjunto de uno o varios segmentos de red, lo que
requiere regular el tráfico entrante y saliente por medio de directivas.
Zona de túnel Una zona de túnel es un segmento lógico que contiene al menos una interfaz de
túnel. Una zona de túnel está asociada a una zona de seguridad que actúa como su
portadora.
A-XXIV
Zona desmilitarizada Término militar que designa un área entre dos oponentes donde se evita la lucha.
(DMZ) Las redes Ethernets de zonas DMZ conectan redes y equipos controlados por
diferentes entidades. Pueden ser externas o internas. Las redes Ethernet DMZ
externas conectan redes regionales con enrutadores.
Zona Trust Una de las dos zonas de seguridad que impide que los paquetes sean visibles para
los dispositivos externos al dominio de seguridad actual.
Zona Untrust Una de las dos zonas de seguridad que permite que los paquetes sean visibles para
los dispositivos externos al dominio de seguridad actual.
A-XXV
A-XXVI
Índice
Numerics ajustes de configuración, requisitos
3DES ............................................................................. 5-6 del explorador ........................................................... 3-2
Ajustes de L2TP, DNS .............................................. 5-211
A alarmas
acciones de ataque .....................................4-130 a 4-137 alerta de correo electrónico ............................... 3-64
close .................................................................... 4-130 comunicar a NetScreen-Security Manager ....... 3-23
close client ......................................................... 4-130 tráfico .........................................................3-64 a 3-67
close server ........................................................ 4-130 umbrales ............................................................... 3-64
drop .................................................................... 4-130 alarmas de tráfico ...........................................3-64 a 3-67
drop packet ........................................................ 4-130 alarmas, umbrales de .............................................. 2-177
ignore.................................................................. 4-131 ALG .................................................................... 4-61, 6-17
none .................................................................... 4-131 MS RPC ............................................................... 2-133
ACL ............................................................................ 12-45 para servicios personalizados .......................... 2-172
adaptadores virtuales ................................................ 9-65 RTSP.................................................................... 2-134
administración SIP ......................................................................... 6-13
Interfaz de línea de comandos (CLI) ................... 3-9 SIP NAT................................................................. 6-24
restringir ............................................................... 3-41 Sun RPC .............................................................. 2-131
WebUI ..................................................................... 3-2 almacenamiento en segundo plano ........................ 3-90
administración, vsys ................................................. 10-6 almacenamiento flash interno ................................. 3-54
administrador fiduciario ......................................... 12-59 alta disponibilidad
administrador raíz, inicio de sesión ........................ 3-41 cableado ................................................11-34 a 11-36
administradores ......................................................... 10-1 conexión de datos ............................................. 11-31
cambiar contraseñas..................................10-3, 10-7 interfaces virtuales ............................................ 11-35
tipos ...................................................................... 10-3 LED...................................................................... 11-20
ADSL mensajes ............................................................ 11-30
acceso del servidor local .................................. 12-17 seguimiento de IP................................ 11-88, 11-117
conexión del cable .............................................. 12-2 sondeo de conexiones ...................................... 11-32
PPPoA ................................................................... 12-6 supervisión de rutas ........................................ 11-117
respaldo de acceso telefónico .......................... 12-10 véase HA
respaldo de ethernet ......................................... 12-15 alta disponibilidad (HA)................................. 13-5, 13-20
Túnel VPN .......................................................... 12-20 análisis antivirus .............................................4-63 a 4-79
túnel VPN secundario ....................................... 12-24 correo web de HTTP ........................................... 4-67
vista general ......................................................... 12-1 descompresión .................................................... 4-82
ADSL 1483 extensiones de archivo ....................................... 4-82
bridging ................................................................ 12-8 FTP ........................................................................ 4-64
enrutamiento ..................................................... 12-30 goteo HTTP .......................................................... 4-78
Advanced Encryption Standard (AES) ....................... 5-7 HTTP ..................................................................... 4-65
AES ................................................................................ 5-7 HTTP “keep-alive” ............................................... 4-77
Agente de NSM .......................................................... 3-21 IMAP ..................................................................... 4-68
comunicar eventos .............................................. 3-23 MIME ..................................................................... 4-66
habilitar ................................................................ 3-22 modo de fallo ....................................................... 4-76
agente zombie ..................................................4-32, 4-34 POP3 ..................................................................... 4-68
AH...........................................................................5-3, 5-6 recursos de AV por cliente ................................. 4-76
AIM ............................................................................ 4-122 SMTP ..................................................................... 4-69
suscripción ........................................................... 4-71
Índice IX-I
análisis de puertos....................................................... 4-8 Teardrop ............................................................... 4-56

análisis FIN ................................................................. 4-14 Terrestres ............................................................. 4-54
ancho de banda ....................................................... 2-178 WinNuke .............................................................. 4-57
administrar ........................................................ 2-197 Ataques de sobrefacturación
garantizado ................................. 2-178, 2-197, 2-203 descripción ......................................................... 13-22
máximo ....................................... 2-178, 2-197, 2-203 prevención ............................................13-22 a 13-26
máximo ilimitado.............................................. 2-198 prevención, configuración ............................... 13-25
anomalías del protocolo ......................................... 4-125 soluciones .......................................................... 13-24
ALG ..................................................................... 4-123 Ataques DoS ....................................................4-32 a 4-58
Aplicaciones de mensajería inmediata ........... 4-122 Ataques Teardrop ....................................................... 4-56
Aplicaciones P2P ............................................... 4-122 Ataques terrestres (land attacks) .............................. 4-54
configurar parámetros ...................................... 4-153 Ataques WinNuke ...................................................... 4-57
protocolos admitidos ........................... 4-120 a 4-123 ATM ............................................................................. 12-2
protocolos básicos de red ................................ 4-120 atributos específicos de cada fabricante ................. 9-22
APN autenticación
filtrado ................................................... 13-13 a 13-14 algoritmos ........................5-6, 5-51, 5-55, 5-58, 5-61
modo de selección ............................................ 13-13 Allow Any ........................................................... 2-176
applets Java, bloquear ............................................. 4-160 directivas ............................................................ 2-174
Archivos de ayuda ....................................................... 3-2 NSRP ................................................................... 11-10
archivos exe, bloquear ............................................ 4-160 NSRP-Lite ......................................................... 11-106
archivos MIB, importación ..................................... 5-252 usuarios .............................................................. 2-174
archivos zip, bloquear ............................................. 4-161 autenticación en tiempo de ejecución .........2-175, 9-40
Áreas OSPF ................................................................ 7-48 Autenticación y encriptación
definición ............................................................. 7-54 acceso protegido a Wi-Fi
interfaces, asignación a ...................................... 7-55 véase WPA
ARP ..................................................................2-84, 11-88 Combinaciones de seguridad SSID WEP ........ 12-40
consulta .............................................................. 11-41 privacidad equivalente a la del cable
difusiones ........................................................... 11-11 véase WEP
supervisión de rutas........................................ 11-117 Varias claves WEP ............................................. 12-41
ARP, dirección IP de entrada .................................... 2-87 autenticación y encriptacion, uso de un
asignación de tráfico ............................................... 2-197 servidor RADIUS ................................................... 12-42
automática ......................................................... 2-198 autenticación, servidores de
prioridades del servicio .................................... 2-202 véase servidores de autenticación
asociaciones de seguridad autenticación, usuarios de
véase SAs véase usuarios de autenticación
Asociaciones de seguridad (SA) ............................... 3-92
ataques B
direcciones MAC desconocidas ......................... 4-45 barrido de direcciones ................................................ 4-7
DOS ........................................................... 4-32 a 4-58 base de datos de objetos de ataque .........4-110 a 4-118
etapas ..................................................................... 4-2 actualización automática .......................4-112, 4-114
Fragmentos de paquetes IP ............................. 4-168 actualización inmediata.........................4-111, 4-113
Fragmentos SYN ............................................... 4-169 actualización manual .............................4-112, 4-116
ICMP cambiar la URL predeterminada ..................... 4-117
fragmentos ................................................... 4-164 notificación automática y
inundaciones .................................................. 4-52 actualización manual ...........................4-112, 4-115
inundaciones de la tabla de sesiones ......4-17, 4-33 base de datos local
Inundaciones SYN .................................... 4-40 a 4-45 tiempo de espera ................................................ 9-17
Inundaciones UDP .............................................. 4-53 tipos de usuarios admitidos ............................... 9-16
objetivos comunes ................................................ 4-1 usuarios IKE ......................................................... 9-62
opciones de detección y defensa ............... 4-2 a 4-4 BGP
paquetes ICMP grandes .................................... 4-165 atributos de ruta ................................................ 7-111
Ping of Death ....................................................... 4-55 comunidades ..................................................... 7-131
protocolos desconocidos .................................. 4-167 confederaciones ................................................ 7-130
repetición ............................................................. 5-12 configuraciones, seguridad .............................. 7-119
IX-II Índice
Índice
configuraciones, verificación ........................... 7-118 circuito virtual

enrutador virtual, creación de una véaseVC
instancia en ..................................................... 7-113 circuitos de demanda, RIP ...................................... 7-101
equilibrio de carga .............................................. 7-38 clasificación del tráfico según IP ............................ 10-29
expresiones regulares ....................................... 7-123 clasificación del tráfico
externos ............................................................. 7-111 según VLAN .................................. 10-18, 10-19 a 10-28
interno ................................................................ 7-111 clave manual
introducción al protocolo ................................. 7-110 administración ....................................................... 5-7
lista de acceso AS-path ..................................... 7-123 clave previamente compartida ................................... 5-8
parámetros ......................................................... 7-121 claves
tipos de mensaje ............................................... 7-110 manuales ................................................ 5-120, 5-126
vecinos, autenticación ...................................... 7-120 previamente compartidas ................................ 5-160
BGP, configuración claves de licencia ..................................................... 2-253
grupos de interlocutores................................... 7-115 actualización del patrón de ataques ................ 4-108
interlocutores ..................................................... 7-115 modo avanzado ................................................. 4-108
pasos ................................................................... 7-112 claves manuales, VPN ..................................... 3-42, 3-74
BGP, habilitación claves previamente compartidas ........................... 5-160
en interfaz .......................................................... 7-114 claves software ......................................................... 10-15
en VR .................................................................. 7-113 claves, licencia.......................................................... 2-253
Bloque de mensajes del servidor claves, vsys ............................................................... 10-15
véase SMB CLI ................................................................................. 3-9
BSS ............................................................................ 12-34 CLI, set arp always-on-dest ............................. 2-76, 2-79
bypass-auth ................................................................ 9-66 CLI, set vip multi-port................................................ 8-84
clientes SecurID
C reintentos ............................................................. 9-28
cables serie ................................................................. 3-19 tiempo de espera................................................. 9-28
canales y códigos de país ....................................... 12-44 clústeres ................ 11-9 a 11-12, 11-37, 11-102 a 11-106
capturas SNMP Clústeres NSRP .................................. 11-9 a 11-12, 11-37
100, problemas de hardware ............................ 3-70 comando clear cluster......................................... 11-9
200, problemas de cortafuegos ......................... 3-70 comando debug cluster ...................................... 11-9
300, problemas de software .............................. 3-70 nombres ............................................... 11-10, 11-105
400, problemas de tráfico .................................. 3-70 código de autenticación basado en hash .................. 5-6
500, problemas de VPN ..................................... 3-70 códigos token ............................................................. 9-27
alarma de tráfico ................................................. 3-70 códigos y canales del país,
alarma del sistema .............................................. 3-70 dominio regulatorio .............................................. 12-44
permitir o denegar .............................................. 3-72 colas de prioridad
tipos ...................................................................... 3-70 de ancho de banda ............................................ 2-202
carga de seguridad encapsulada predeterminadas ............................................... 2-202
véase ESP colas LPR .................................................................. 4-121
certificado local .......................................................... 5-25 comandos
certificados ................................................................... 5-8 clear cluster ...................................................... 11-105
CA.................................................................5-22, 5-25 debug cluster.................................................... 11-105
carga ..................................................................... 5-28 comodines .................................................... 5-186, 13-13
carga de CRL ........................................................ 5-23 CompactFlash............................................................. 3-54
local....................................................................... 5-25 compatibilidad con el sistema virtual ..................... 13-6
petición ................................................................. 5-26 completas
por medio del correo electrónico ...................... 5-25 firmas .................................................................. 4-124
revocación ...................................................5-25, 5-35 comprobación contra reprocesamiento
certificados de CA .............................................5-22, 5-25 de paquetes ................................................... 5-53, 5-59
Challenge Handshake Authentication Protocol comprobación de SYN ......................... 4-15, 4-15 a 4-18
véase CHAP agujero de reconocimiento ................................ 4-17
CHAP .................................................... 5-208, 5-211, 9-77 enrutamiento asimétrico .................................... 4-16
Chargen..................................................................... 4-120 interrupción de sesión ........................................ 4-16
inundaciones de la tabla de sesiones ................ 4-17
Índice IX-III
comunidad SNMP D
privadas ................................................................ 3-72 Datos de NSRP
públicas ................................................................ 3-72 conexión............................................................. 11-31
conexión principal ..................................................... 3-92 mensajes ............................................................ 11-31
confidencialidad directa perfecta DDoS ........................................................................... 4-32
véase PFS Deep Inspection (DI) ..................................4-127 a 4-151
configuración en malla completa .......................... 11-94 acciones de ataque...............................4-130 a 4-137
configuración punto a multipunto anomalías del protocolo ................................... 4-125
OSPF ..................................................................... 7-72 base de datos de objetos
configuraciones de ataque ............................................4-110 a 4-118
ISP para las interfaces serie ............................. 11-75 cambiar gravedad ............................................. 4-126
malla completa .................................................. 11-94 claves de licencia .............................................. 4-108
módem para las interfaces serie ..................... 11-74 contexto .................................................................. 4-I
configurar modo ........................................................ 9-66 desactivar objetos de ataque ........................... 4-129
Conjunto de servicios básicos expresiones regulares ..........................4-147 a 4-148
véase BSS firmas completas ............................................... 4-124
conjuntos de DIP firmas de secuencias ........................................ 4-125
consideraciones sobre direcciones ................... 8-16 firmas personalizadas ..........................4-147 a 4-151
interfaces extendidas ....................................... 5-141 grupos de objetos de ataque ............................ 4-126
NAT para VPNs .................................................. 5-141 negación de objetos de ataque ........................ 4-154
NAT-src ................................................................... 8-1 objetos de ataque .............................................. 4-107
tamaño ................................................................. 8-16 objetos de ataque personalizados ................... 4-146
Conjuntos de direcciones IP paquetes de firmas ........................................... 4-110
véase Conjuntos de DIP registrar grupos de objetos de ataque ............ 4-140
Conjuntos de IP dinámico (DIP) ............................ 2-174 servicios personalizados ......................4-142 a 4-146
Conjuntos de servicios básicos (BSS) .................... 12-34 vista general ....................................................... 4-106
conmutación de disponibilidad alta volver a habilitar objetos de ataque ................ 4-129
activa/activa ......................................................... 11-5 denegación de direcciones ..................................... 2-191
activa/pasiva ........................................................ 11-4 Denegación de servicio
conmutación por error véase DoS
dispositivos ........................................................ 11-83 DES ................................................................................ 5-6
grupos VSD ........................................................ 11-84 descompresión, análisis antivirus............................ 4-82
interfaces Dual Untrust .........................11-51, 11-52 DHCP ....................................... 2-98, 2-102, 2-246, 4-120
interfaces serie .................................................. 11-77 agente de retransmisión .................................. 2-229
sistemas virtuales .............................................. 11-93 cliente ................................................................. 2-229
supervisión de objetos ...................................... 11-85 HA ....................................................................... 2-236
conmutación por error del dispositivo .................. 11-83 servidor .............................................................. 2-229
consola........................................................................ 3-54 Diffie-Hellman ............................................................ 5-10
consulta de rutas DiffServ ..........................................................2-178, 2-204
múltiple VR .......................................................... 7-36 véase también DS Codepoint Marking
secuencia ............................................................. 7-33 DIP...........................................2-101, 2-144 a 2-148, 3-92
contenedores ........................................................... 5-187 conjuntos ............................................................ 2-174
contraseña conjuntos, modificar ......................................... 2-147
administrador raíz .............................................. 3-39 grupos ....................................................2-157 a 2-159
contraseñas PAT ..........................................................2-145, 2-146
olvidada ................................................................ 3-37 puerto fijo ........................................................... 2-147
contraseñas del administrador, cambiar .......10-3, 10-7 dirección IP asignada
controles ActiveX, bloqueo ..................................... 4-160 Véase MIP
Cookies SYN ............................................................... 4-50 direcciones
CRL asignaciones L2TP............................................... 9-82
véase Lista de revocación de certificados definición ........................................................... 2-170
en directivas ...................................................... 2-170
entradas en la libreta
de direcciones ....................................2-106 a 2-110
IX-IV Índice
Índice
ID de IP, de host y de red .................................. 2-55 desactivar ........................................................... 2-194

Periodo de vigencia de IP para usuarios direcciones ......................................................... 2-170
de XAuth ............................................................ 9-66 direcciones en .................................................... 2-170
privadas ................................................................ 2-56 edición ................................................................ 2-194
públicas ................................................................ 2-55 elementos requeridos ....................................... 2-164
Direcciones de protocolo de Internet (IP) eliminar .............................................................. 2-196
véase direcciones IP filtrado de Web .................................................. 4-102
Direcciones IP funciones de ....................................................... 2-163
Administración .................................................... 2-97 globales ........................................2-166, 2-179, 2-189
IP administrativa ................................................. 3-30 grupos de DIP .................................................... 2-158
Servidores de NetScreen-Security Manager ..... 3-23 grupos de direcciones ....................................... 2-170
direcciones IP grupos de servicios............................................ 2-142
extendidas .......................................................... 5-141 grupos de usuarios de acceso telefónico
ID de host ............................................................. 2-55 a VPN ................................................................ 2-170
ID de red .............................................................. 2-55 habilitar .............................................................. 2-194
interfaces, seguimiento de ................................. 2-65 ID ......................................................................... 2-170
privadas ................................................................ 2-55 interzonales .................................2-165, 2-179, 2-183
públicas ................................................................ 2-55 intrazonales .................................2-165, 2-179, 2-187
puertos, definición para cada uno .................. 2-106 L2TP .................................................................... 2-173
rangos de direcciones privadas ......................... 2-56 libro de servicios ............................................... 2-111
secundarias .......................................................... 2-59 límite máximo ................................................... 2-109
secundarias, enrutamiento entre ...................... 2-59 listas de conjuntos de directivas ...................... 2-167
zonas de seguridad L3 .............................2-54 a 2-56 multicast ............................................................. 7-143
direcciones IP de cliente de administración........... 3-41 múltiples elementos por componente ............ 2-190
direcciones IP secundarias ....................................... 2-59 NAT-dst ............................................................... 2-174
Direcciones IP, virtuales ............................................ 8-83 NAT-src ............................................................... 2-174
direcciones privadas .................................................. 2-56 nombre ............................................................... 2-172
direcciones públicas .................................................. 2-55 ocultar ..................................................... 2-194, 2-195
direcciones XAuth orden................................................................... 2-196
asignaciones ........................................................ 9-65 permitir ............................................................... 2-171
autenticación, y ................................................... 9-77 rechazo ............................................................... 2-171
período de vigencia de la recuento.............................................................. 2-177
dirección IP .............................................9-66 a 9-67 registro de tráfico .............................................. 2-176
tiempo de espera ................................................ 9-66 reglas internas ................................................... 2-168
direcciones, denegación de .................................... 2-191 reordenar............................................................ 2-195
direcciones, rangos superpuestos de..........10-23, 10-30 sección central ......................................... 4-17, 4-108
directiva de SA ........................................................... 3-92 secuencia de consulta ....................................... 2-167
directivas .............................................................2-3, 13-6 servicios .............................................................. 2-170
acciones .............................................................. 2-171 servicios en ............................................ 2-111, 2-170
administración................................................... 2-179 sistema raíz ........................................................ 2-168
administrar ancho de banda ............................ 2-197 sistemas virtuales .............................................. 2-168
alarmas ............................................................... 2-177 tareas programadas .......................................... 2-177
aplicación, enlazar explícitamente tipos .......................................................2-165 a 2-166
servicio a .......................................................... 2-172 túnel .................................................................... 2-171
asignación de tráfico ......................................... 2-178 túneles L2TP ...................................................... 2-173
autenticación ..................................................... 2-174 verificar............................................................... 2-194
cambiar .............................................................. 2-194 VPN ..................................................................... 2-172
colocar al principio.................................2-173, 2-195 VPN bidireccionales .............................. 2-172, 5-127
contexto ............................................................. 4-110 zonas de seguridad ........................................... 2-170
contexto de una directiva................................. 2-190 directivas de acceso
copia de seguridad de la sesión HA ................ 2-176 véase directivas
Deep Inspection (DI) ......................................... 2-173 Directivas L2TP ........................................................ 2-173
denegación de direcciones............................... 2-191 directivas, configuración ........................................... 13-7
denegar............................................................... 2-171 Discard ...................................................................... 4-120
Índice IX-V
dispositivos, restablecer a los ajustes redistribución....................................................... 7-83

predeterminados de fábrica .................................. 3-40 resumen, configuración...................................... 7-99
distribución del protocolo, comunicar a enrutadores virtuales
NetScreen-Security Manager ................................. 3-23 véase VR
DMT ............................................................................ 12-3 véase VRs
DN ............................................................................. 5-183 enrutadores virtuales, MIP predeterminada ........... 8-68
DNS ................................................................2-221, 4-120 enrutamiento estático ................................ 7-2, 7-2 a 7-9
búsquedas .......................................................... 2-222 configuración ......................................................... 7-5
consultas de dominios ...................................... 2-227 Interfaz nula, reenvío en .................................... 7-10
división de direcciones ..................................... 2-227 multicast ............................................................. 7-140
encapsulamiento a servidores ......................... 2-227 utilización ............................................................... 7-3
servidores........................................................... 2-247 enrutamiento multicast
tabla de estado .................................................. 2-223 IGMP ................................................................... 7-145
DoS PIM ...................................................................... 7-173
ataque específico del sistema enrutamiento según el origen (SBR) ........................ 7-17
operativo ................................................. 4-55 a 4-58 enrutamiento según la interfaz
cortafuegos ............................................... 4-33 a 4-39 de origen (SIBR) ...................................................... 7-20
inundaciones de la tabla de sesiones ......4-17, 4-33 enrutamiento, multicast.......................................... 7-137
red .............................................................. 4-40 a 4-55 envejecimiento agresivo ................................4-36 a 4-38
drop-no-rpf-route ....................................................... 4-19 equilibrio de cargas según coste
DS Codepoint Marking .................................2-198, 2-204 de cada ruta ....................................................7-38, 7-62
DSL .................................................................2-242, 2-246 error de vector NAT ................................................... 3-92
error in-short .............................................................. 3-90
E ESP .........................................................................5-3, 5-6
Echo .......................................................................... 4-120 encriptación y autenticación.....................5-54, 5-61
ECMP .................................................................7-38, 7-62 sólo autenticación ............................................... 5-54
email alert notification.............................................. 3-69 sólo encriptación ................................................. 5-54
Encabezado de autenticación (AH) ........................... 5-6 establecimientos de comunicación en tres fases ... 4-40
Encapsulaciones de AAL5 ........................................ 12-2 estadísticas, comunicar a NetScreen-Security
Encapsulado genérico de enrutamiento (GRE) .... 7-141 Manager ................................................................... 3-24
encriptación estado............................................................................ 4-3
algoritmos ................................5-6, 5-51, 5-54 a 5-61 inspección .............................................................. 4-3
NSRP ................................................................... 11-10 estándar VLAN IEEE 802.1Q .................................. 10-19
NSRP-Lite ......................................................... 11-106 Etiquetas VLAN ............................................................ 2-4
encriptación, SecurID ............................................... 9-28 etiquetas VLAN ............................................................ 2-4
Enrutadores BGP evasión .............................................................4-14 a 4-26
agregar ....................................................7-124, 7-132 explotación de vulnerabilidad
atributos, configuración ................................... 7-125 véase ataques
notificación condicional ................................... 7-124 expresiones de grupos .....................................9-5 a 9-10
peso, establecimiento ....................................... 7-125 operadores ............................................................. 9-5
predeterminado, rechazo ................................. 7-120 servidores admitidos .......................................... 9-14
redistribución .................................................... 7-122 usuarios .................................................................. 9-6
reflexión ............................................................. 7-128 expresiones regulares.................................4-147 a 4-148
supresión............................................................ 7-133 extensiones de archivo, análisis de AV ................... 4-82
Enrutadores OSPF externo, XAuth
adyacencia ........................................................... 7-50 autenticación de grupo de usuarios .................. 9-73
creación de instancia OSPF en autenticación de usuarios .................................. 9-71
enrutador virtual ............................................... 7-53 consultas del servidor de autenticación ........... 9-65
designado ............................................................. 7-50
designado de respaldo........................................ 7-50 F
tipos ...................................................................... 7-49 Fase 1 ............................................................................ 5-9
Enrutadores RIP propuestas.............................................................. 5-9
alternativa .......................................................... 7-100 propuestas, predefinidas ...................................... 5-9
rechazo predeterminado .................................... 7-94
IX-VI Índice
Índice
Fase 2 .......................................................................... 5-11 G

propuestas ............................................................ 5-11 gatekeeper (equipos selectores) ................................. 6-1
propuestas, predefinidas .................................... 5-11 gestión de colas de prioridades ............................. 2-202
filtrado de contenidos ..................................4-59 a 4-104 Gi, interfaz .................................................................. 13-3
filtrado de paquetes dinámico ................................... 4-3 Gn, interfaz ................................................................. 13-3
filtrado de URL Gopher ...................................................................... 4-120
véase filtrado de web Gp, interfaz ................................................................. 13-3
filtrado de Web gráficos de historial ................................................. 2-177
aplicación en el nivel de directivas ................. 4-102 grupos
aplicar perfiles a directivas ................................ 4-94 direcciones ......................................................... 2-108
caché ..................................................................... 4-96 servicios .............................................................. 2-142
categorías de URL ............................................... 4-90 grupos de direcciones ................................. 2-108, 2-170
enrutamiento ..................................................... 4-103 crear .................................................................... 2-110
estado del servidor ............................................ 4-102 edición ................................................................ 2-110
integrado .............................................................. 4-88 entradas, eliminar ............................................. 2-110
introducir un contexto ........................................ 4-90 opciones ............................................................. 2-108
mensaje de URL bloqueada ............................. 4-101 grupos de dispositivos de seguridad virtuales
nombre del servidor SurfControl..................... 4-100 véase grupos VSD
nombre del servidor Websense....................... 4-100 grupos de objetos de ataque .................................. 4-126
perfiles .................................................................. 4-92 cambiar gravedad ............................................. 4-126
puerto del servidor SurfControl ....................... 4-100 niveles de gravedad .......................................... 4-126
puerto del servidor Websense ......................... 4-100 que se aplican en directivas ............................. 4-119
redirigir ................................................................. 4-97 registro................................................................ 4-140
servidores CPA de SurfControl .......................... 4-88 URL de ayuda..................................................... 4-123
servidores de SurfControl ................................... 4-96 grupos de servicios .....................................2-142 a 2-144
servidores por vsys ............................................. 4-99 crear .................................................................... 2-143
SurfControl SCFP ............................................... 4-100 eliminar .............................................................. 2-144
tiempo de espera de comunicaciones ............ 4-101 modificar ............................................................ 2-143
tipo de mensaje de URL bloqueada ................ 4-101 grupos de servicios (WebUI) ................................... 2-142
filtrado de web .................................. 2-176, 4-97 a 4-104 grupos VSD .....................11-18 a 11-22, 11-106 a 11-109
Filtrado del prefijo de IMSI ..........................13-15, 13-16 conmutación por error ..................................... 11-84
filtrar ruta de origen .................................................. 3-92 estados de los miembros.......11-19, 11-107, 11-117
FIN sin flag ACK ......................................................... 4-12 latidos ........................................11-11, 11-20, 11-108
Finger ........................................................................ 4-120 números de prioridad ....................................... 11-18
firma digital ................................................................ 5-20 tiempo de retención .............................. 11-38, 11-41
firmas GTP
completas ........................................................... 4-124 comprobación de coherencia del paquete ....... 13-9
firmas de secuencias ............................................... 4-125 con base en directivas ........................................ 13-6
flags SYN y FIN activados ......................................... 4-11 estándares .......................................................... 13-10
flujo de paquetes ............................................2-11 a 2-13 Filtrado del nombre de punto
VPN basada en directivas ........................5-69 a 5-70 de acceso (APN) .............................................. 13-13
VPN basada en rutas ................................5-64 a 5-69 filtrado del paquete de GTP-en-GTP ................ 13-18
VPN de entrada ........................................5-67 a 5-69 Filtrado del prefijo de IMSI ............................... 13-15
VPN de salida ....................................................... 5-65 fragmentación de IP.......................................... 13-18
flujo de paquetes, NAT-dst .............................8-31 a 8-33 inspección de estado ........................................ 13-19
Fragmentos SYN ...................................................... 4-169 objetos de inspección ..............................13-6 a 13-8
fuerza bruta protocolo .............................................................. 13-3
acciones de ataque............................................ 4-137 tiempo de espera del túnel............................... 13-21
funcionales básicos, requisitos ................................. 10-3
funcionamiento, modos de H
NAT ....................................................................... 13-5 HA
Ruta....................................................................... 13-5 DHCP .................................................................. 2-236
Transparente........................................................ 13-5 HA virtual, interfaces de ..................................... 2-47
interfaces .............................................................. 2-47
Índice IX-VII
Véase alta disponibilidad puertas de enlace redundantes ..........5-290 a 5-303

véase también NSRP recomendaciones de ID IKE .............................. 5-72
historial, gráficos ..................................................... 2-177 usuario de identificación
HMAC ............................................................................ 5-6 IKE compartida ..................................5-198 a 5-203
HTTP usuario de identificación
“keep-alive” ......................................................... 4-77 IKE de grupo .......................................5-183 a 5-198
bloqueo de componentes.................... 4-159 a 4-161 usuarios
goteo ..................................................................... 4-78 véase usuarios IKE
tiempo de espera de la sesión ........................... 4-37 indicadores LED, HA ............................................... 11-20
HTTP, ID de sesión ...................................................... 3-4 infraestructura de claves públicas
huso horario ............................................................. 2-256 véase PKI
iniciar sesión ...................................................3-53 a 3-64
I CompactFlash (PCMCIA) .................................... 3-54
ICMP ......................................................................... 4-120 consola ................................................................. 3-54
fragmentos ......................................................... 4-164 correo electrónico ............................................... 3-54
paquetes grandes .............................................. 4-165 interno .................................................................. 3-54
ID de fabricante, VSA ................................................ 9-23 registro de eventos.............................................. 3-54
ID de proxy ................................................................ 5-12 registro de recuperación de equipos ................ 3-63
coincidencia ................................................5-64, 5-71 registro propio ..................................................... 3-61
ID de sesión ................................................................. 3-4 SNMP ...........................................................3-54, 3-69
IDENT ....................................................................... 4-121 syslog ...........................................................3-54, 3-67
identificación IKE de grupo WebTrends..................................................3-54, 3-68
certificados ........................................... 5-183 a 5-192 inicio de sesión
claves previamente compartidas ....... 5-192 a 5-198 administrador raíz............................................... 3-41
identificador de canal virtual Telnet .................................................................... 3-10
véase VCI inspecciones ................................................................. 4-3
Identificador de conjunto de servicios intercambio de claves de Internet
véase SSID véase IKE
identificador de ruta virtual interceptación legal ................................................. 13-30
véase VPI interfaces .................................................................... 10-2
Ident-Reset ................................................................. 3-27 activas físicamente.............................................. 2-62
IDs de proxy activas lógicamente ............................................ 2-62
VPNs y NAT .......................................... 5-141 a 5-142 agregadas ..................................................2-46, 11-49
IGMP asociar a zonas .................................................... 2-54
configuración, básica ........................................ 7-151 cambios de estado .............................................. 2-62
configuración, verificación............................... 7-153 compartidas ............................................10-15, 10-29
consultador ........................................................ 7-148 conexiones, supervisión de................................ 2-64
directivas, multicast .......................................... 7-160 de bucle invertido ............................................... 2-60
interfaces, habilitar en...................................... 7-149 dedicadas ................................................10-14, 10-29
listas de accesos, uso ........................................ 7-150 DIP ...................................................................... 2-144
mensajes de host .............................................. 7-147 direccionar ........................................................... 2-54
parámetros .............................................7-153, 7-154 direcciones IP secundarias ................................. 2-59
IKE...................................................5-7, 5-88, 5-97, 5-160 Dual Untrust ....................................................... 11-50
ID de proxy .......................................................... 5-12 extendidas.......................................................... 5-141
ID IKE, Windows 200 ............................5-219, 5-227 física, exportación desde vsys ......................... 10-18
ID local, ASN1-DN ............................................. 5-186 física, importación de vsys .............................. 10-17
ID remota, ASN1-DN ........................................ 5-186 físicas ...................................................................... 2-3
identificación IKE ................ 5-51 a 5-53, 5-58 a 5-59 físicas en zonas de seguridad ............................ 2-45
identificación IKE de grupo, comodines ........ 5-186 gestionables ......................................................... 3-30
identificación IKE de grupo, container ........... 5-187 Gi ........................................................................... 13-3
latidos ................................................................. 5-293 Gn .......................................................................... 13-3
mensajes de saludo .......................................... 5-293 Gp .......................................................................... 13-3
propuestas de fase 1, predefinidas ..................... 5-9 HA ......................................................................... 2-47
propuestas de fase 2, predefinidas ................... 5-11 HA virtual ..................................................2-47, 11-35
IX-VIII Índice
Índice
HA, duales .............................................11-28 a 11-31 bucles .................................................................... 2-71

inactivas físicamente .......................................... 2-62 zonas de seguridad ............................................. 2-75
inactivas lógicamente ......................................... 2-62 Interfaz de línea de comandos
MGT....................................................................... 2-47 véase CLI
MIP ........................................................................ 8-66 interfaz de seguridad virtual
modificar .............................................................. 2-56 véase VSI
nula ....................................................................... 5-87 Interfaz de usuario web
opciones de administración ............................... 3-26 véase WebUI
predeterminadas ................................................. 2-56 Interfaz Gi ................................................................... 13-3
redundantes ..............................................2-46, 11-44 Interfaz MGT, opciones de administración ............. 3-27
seguimiento de IP (véase seguimiento de IP) Interfaz nula, definir rutas con ................................. 7-10
serie .................................................................... 11-73 Internet Group Management Protocol
supervisión ......................................................... 11-11 véase IGMP
tabla de interfaces, visualizar ............................ 2-52 intimidad equivalente al cable
túnel ................................................. 2-48, 2-48 a 2-51 véase WEP
túnel de NAT basada en directivas.................... 2-48 inundaciones
VIP......................................................................... 8-83 ICMP...................................................................... 4-52
visualizar tabla de interfaces ............................. 2-52 SYN .................................................. 4-40 a 4-45, 4-50
VLAN1................................................................... 2-83 tabla de sesiones ................................................. 4-33
VSI ......................................................................... 2-47 UDP ....................................................................... 4-53
VSIs ..................................................................... 11-22 inundaciones de la tabla de sesiones ............ 4-17, 4-33
zona de función ................................................... 2-47 inundaciones del proxy SYN-ACK-ACK.................... 4-38
zona de función de HA ....................................... 2-47 Inundaciones ICMP.................................................... 4-52
zonas de seguridad L3 ........................................ 2-54 Inundaciones SYN ..........................................4-40 a 4-45
zonas, separar de ................................................ 2-54 ataques ................................................................. 4-40
interfaces agregadas .......................................2-46, 11-49 Cookies SYN ......................................................... 4-50
interfaces de alta disponibilidad descartar las direcciones MAC desconocidas... 4-45
agregadas ........................................................... 11-49 tamaño de la cola ................................................ 4-45
Dual Untrust ....................................................... 11-50 tiempo de espera................................................. 4-45
red de cableado como conexiones HA ........... 11-35 umbral .................................................................. 4-41
redundantes ....................................................... 11-44 umbral de alarma ................................................ 4-43
serie .................................................................... 11-73 umbral de ataque ................................................ 4-43
interfaces de bucle invertido .................................... 2-60 umbral de destino ............................................... 4-44
interfaces de HA virtual ............................................ 2-47 umbral de origen ................................................. 4-44
Interfaces de ScreenOS IP
físicas ...................................................................... 2-3 fragmentos de paquetes ................................... 4-168
subinterfaces.......................................................... 2-4 IP administrativa ........................................................ 3-29
zonas de seguridad ............................................... 2-3 IP de administración ................................................. 2-97
interfaces de túnel ..................................................... 2-48 IP de administración, VSD grupo 0 ......................... 11-6
definición ............................................................. 2-48 IP dinámico
NAT basada en directivas ................................... 2-48 véase DIP
interfaces de zonas de función ................................ 2-47 IP virtual
administración..................................................... 2-47 Véase VIP
HA ......................................................................... 2-47 IPSec
interfaces Dual Untrust ........................................... 11-50 AH ........................................................5-2, 5-54, 5-60
interfaces físicas ESP .......................................................5-2, 5-54, 5-60
exportación desde vsys .................................... 10-18 firma digital .......................................................... 5-20
importación de vsys.......................................... 10-17 L2TP sobre IPSec ................................................... 5-4
Interfaces HA virtuales ............................................ 11-35 modo de transporte ........... 5-4, 5-208, 5-213, 5-218
interfaces serie ......................................................... 11-73 Modo de túnel ........................................................ 5-4
configuración de ISP ......................................... 11-75 negociación de túnel ............................................. 5-9
configuración del módem ................................ 11-74 SAs ................................................. 5-2, 5-8, 5-9, 5-11
conmutación por error ..................................... 11-77 SPI ........................................................................... 5-2
interfaces, habilitar IGMP en .................................. 7-149 túnel ........................................................................ 5-2
interfaces, supervisión de ..............................2-70 a 2-75 IRC ............................................................................. 4-122
Índice IX-IX
ISP ............................................................................. 2-227 libretas de direcciones

prioridad ............................................................ 12-59 direcciones, agregar .......................................... 2-107
temporizador del tiempo de espera de direcciones, eliminar ........................................ 2-110
conmutación por error ................................... 12-60 direcciones, modificar ...................................... 2-107
ISP, configuración para interfaces serie ................ 11-75 entradas.............................................................. 2-106
entradas de grupos, editar ............................... 2-110
K grupos ................................................................. 2-108
keepalive véase también direcciones
L2TP .................................................................... 5-216 libro de servicio, grupos de servicios (WebUI) ....... 6-61
libro de servicio, servicios
L agregar................................................................ 2-126
L2TP ................................................... 5-205 a 5-230, 13-4 personalizado (CLI) ........................................... 2-126
asignaciones de direcciones .............................. 9-82 personalizados ................................................... 2-111
autenticación de usuarios .................................. 9-82 preconfigurado .................................................. 2-111
autenticado del túnel libro de servicios
Windows 2000 .....................................5-216, 5-221 entradas, eliminar (CLI) .................................... 2-127
base de datos local.............................................. 9-82 entradas, modificar (CLI) .................................. 2-126
bidireccional ...................................................... 5-208 limitación de velocidad, mensajes GTP-C ............. 13-16
concentrador de accesos límites de sesiones .........................................4-33 a 4-36
véase LAC basadas en su destino ...............................4-34, 4-35
configuración obligatoria ................................. 5-205 basadas en su origen .................................4-33, 4-35
configuración voluntaria .................................. 5-206 Lista de control de acceso
desencapsulado ................................................. 5-209 véase ACL
encapsulado ....................................................... 5-208 Lista de revocación de certificados.................5-23, 5-35
Keep Alive ...............................................5-216, 5-221 carga ..................................................................... 5-23
L2TP en solitario sobre Windows 2000 ......... 5-207 listas de acceso
modo de funcionamiento ................................ 5-208 enrutamiento multicast .................................... 7-141
parámetros predeterminados .......................... 5-211 IGMP ................................................................... 7-150
señal hello ...............................................5-216, 5-221 para rutas ............................................................. 7-42
servidor de autenticación externo .................... 9-82 PIM-SM ............................................................... 7-193
servidor de red LNS ............................................................................ 5-205
véase LNS load-balancing by path cost ..................................... 7-62
servidor RADIUS ............................................... 5-211 locales, bases de datos ...................................9-16 a 9-17
servidor SecurID ................................................ 5-211 los ajustes predeterminados de fábrica,
soporte de ScreenOS ........................................ 5-207 restablecer los dispositivos a ................................. 3-40
túnel .................................................................... 5-213
L2TP sobre IPSec .................................. 5-4, 5-213, 5-218 M
bidireccional ...................................................... 5-208 Management Information Base II
túnel .................................................................... 5-213 véase MIB II
LAC ............................................................................ 5-205 mantenimiento de conexión
NetScreen-Remote 5.0 ..................................... 5-206 frecuencia, NAT-T de ........................................ 5-238
Windows 2000 .................................................. 5-206 manual key (clave manual)....................................... 9-14
latidos manual keys (claves manuales)...................5-120, 5-126
Conexión física HA ........................................... 11-30 máscaras de red..............................................2-55, 2-170
RTO ..................................................................... 11-30 máscaras de red, MIP predeterminada ................... 8-68
VSD ..................................................................... 11-30 MD5............................................................................... 5-6
Layer 2 Tunneling Protocol Mensajería inmediata .............................................. 4-122
véase L2TP AIM...................................................................... 4-122
LDAP .................................................... 4-121, 9-29 a 9-30 IRC ...................................................................... 4-122
estructura ............................................................. 9-29 MSN Messenger ................................................. 4-122
identificadores de nombre común.................... 9-30 Yahoo! Messenger ............................................. 4-122
nombres completos ............................................ 9-30 Mensajería inmediata de America Online
puertos del servidor ............................................ 9-30 véase AIM
tipos de usuarios admitidos ............................... 9-30
IX-X Índice
Índice
mensajes MIP, predeterminada

alerta ............................................................3-54, 3-55 enrutadores virtuales .......................................... 8-68
control ................................................................ 11-28 máscaras de red .................................................. 8-68
críticos .................................................................. 3-54 MIP, sistemas virtuales .............................................. 10-9
datos ................................................................... 11-31 MIP, VPNs ................................................................. 5-141
depurar ................................................................. 3-55 módem, configuración para las
emergencia .......................................................... 3-54 interfaces serie ...................................................... 11-74
error ...................................................................... 3-55 módem, puertos ........................................................ 3-20
HA ....................................................................... 11-30 modo de estación móvil (MS) ................................. 13-13
información ......................................................... 3-55 modo de fallo ............................................................. 4-76
notificación .......................................................... 3-55 modo de prioridad ..................................... 11-18, 11-108
WebTrends........................................................... 3-69 modo de red ............................................................. 13-13
mensajes de bienvenida ........................................... 9-11 modo de ruta ........................... 2-100 a 2-103, 11-6, 13-5
mensajes de control ................................................ 11-28 ajustes de interfaz ............................................. 2-101
HA ....................................................................... 11-30 NAT-src ............................................................... 2-101
latidos de conexión física HA .......................... 11-30 Modo de transferencia asíncrona
latidos RTO ........................................................ 11-30 véase ATM
latidos VSD ......................................................... 11-30 modo de transporte .................. 5-4, 5-208, 5-213, 5-218
mensajes de datos ................................................... 11-31 Modo de túnel .............................................................. 5-4
mensajes GTP ........................................................... 13-11 modo dinámico .......................................................... 5-10
longitud, filtrar por ............................................ 13-10 modo Home-Work para ADSL ................................ 12-10
tipo, filtrar por ................................................... 13-10 modo inalámbrico ................................................... 12-38
tipos .................................................................... 13-11 modo NAT .................................. 2-94 a 2-100, 11-6, 13-5
velocidad, limitación por .................................. 13-16 ajustes de interfaz ............................................... 2-97
versiones 0 y 1 .................................................. 13-11 tráfico a la zona Untrust ........................... 2-81, 2-96
Message Digest versión 5 (MD5)................................ 5-6 Modo principal ........................................................... 5-10
métodos de administración modo transparente ........2-82 a 2-94, 10-20, 10-21, 13-5
consola ................................................................. 3-19 ARP/trace-route ................................................... 2-85
Interfaz de línea de comandos ............................ 3-9 bloquear tráfico no ARP ..................................... 2-84
SSL .......................................................................... 3-5 bloquear tráfico no IP ......................................... 2-84
Telnet ...................................................................... 3-9 descartar las direcciones MAC
WebUI ..................................................................... 3-2 desconocidas ..................................................... 4-45
MGT, interfaz .............................................................. 2-47 inundación ........................................................... 2-85
MIB II..................................................................3-26, 3-69 opciones unicast .................................................. 2-85
Microsoft Network Instant Messenger rutas ...................................................................... 2-84
véase MSN Instant Messenger tráfico broadcast .................................................. 2-83
Microsoft-Remote Procedure Call Modo transparente, opciones
véase MS-RPC de administración ................................................... 3-27
MIME, análisis antivirus ............................................ 4-66 modo Trust/Untrust/DMZ para ADSL ..................... 12-17
MIP .....................................................................2-12, 8-65 modo verificado ....................................................... 13-13
agrupamiento, directivas de celdas modos
múltiples ............................................................ 8-82 Combined ............................................................. 2-37
alcanzable desde otras zonas ............................ 8-69 Criptografía Fase 1 .................................... 5-49, 5-56
definición ............................................................... 8-7 Dinámico .............................................................. 5-10
rangos de direcciones ......................................... 8-68 disponibilidad del modo de puerto ................... 2-34
same-as-untrust, interfaz .........................8-73 a 8-75 Dual DMZ ............................................................. 2-39
traducción bidireccional ....................................... 8-7 Dual Untrust ......................................................... 2-36
zona global ........................................................... 8-66 Home-Work.......................................................... 2-35
MIP, a una zona con NAT basada en interfaces...... 2-96 NAT y Route ......................................................... 11-6
MIP, creación NAT, tráfico a la zona Untrust ........................... 2-81
direcciones ........................................................... 8-67 operativo L2TP................................................... 5-208
en interfaz de túnel ............................................. 8-72 Principal................................................................ 5-10
en interfaz de zona ............................................. 8-67 prioridad ............................................................. 11-18
puerto ................................................................... 2-33
Índice IX-XI
Transparente ....................................................... 2-82 NAT basada en directivas, interfaces de túnel de .. 2-48

Transporte.................. 5-4, 5-60, 5-208, 5-213, 5-218 NAT-dst .............................................................8-30 a 8-63
Trust-Untrust........................................................ 2-34 asignación de puertos ........................ 8-5, 8-30, 8-49
Túnel ..................................................................... 5-60 con MIP o VIP ........................................................ 8-4
túnel ........................................................................ 5-4 consideraciones sobre
modos de funcionamiento las rutas ......................................... 8-31, 8-34 a 8-36
NAT ....................................................................... 13-5 desplazamiento de direcciones ........................... 8-6
Ruta ...................................................................... 13-5 flujo de paquetes ......................................8-31 a 8-33
Transparente ....................................................... 13-5 traducción unidireccional ............................8-8, 8-12
modos de funcionamiento WLAN WAP VPNs ................................................................... 5-141
clientes 802.11b, configuración de................. 12-37 NAT-dst, direcciones
clientes 802.11g, configuración de ................. 12-37 desplazamiento ..........................................8-30, 8-46
modos de puertos...................................................... 2-33 rango a IP única .........................................8-11, 8-43
Ajuste .................................................................... 2-40 rango a rango .............................................8-11, 8-46
Combined ............................................................ 2-37 rangos ..................................................................... 8-5
disponibilidad ...................................................... 2-34 NAT-dst, IP individual
Dual DMZ ............................................................. 2-39 con asignación de puerto ................................... 8-10
Dual Untrust ........................................................ 2-36 sin asignación de puerto .................................... 8-10
Home-Work ......................................................... 2-35 NAT-dst, traducción
Home-Work para ADSL .................................... 12-10 “1:1” ..................................................................... 8-37
inalámbrico ........................................................ 12-38 “1:n” ..................................................................... 8-40
Modo DMZ/Dual Untrust .................................... 2-38 NAT-src ..................................................... 8-1, 8-15 a 8-28
predeterminados ................................................. 2-34 basada en interfaces ............................................. 8-2
Trust/Untrust/DMZ (extendido) ......................... 2-38 interfaz de salida ............................ 8-10, 8-26 a 8-28
Trust/Untrust/DMZ para ADSL ......................... 12-17 puerto fijo ........................................ 8-16, 8-20 a 8-21
Trust-Untrust........................................................ 2-34 VPNs ................................................................... 5-144
modos de selección NAT-src, conjuntos de DIP........................................... 8-1
APN ..................................................................... 13-13 con desplazamiento de direcciones .................... 8-9
Estación móvil (MS) .......................................... 13-13 con PAT ............................................. 8-8, 8-17 a 8-19
red ....................................................................... 13-13 puerto fijo ............................................................... 8-9
Verificado ........................................................... 13-13 NAT-src, direcciones
módulo ....................................................................... 5-11 desplazamiento ........................................8-22 a 8-26
MS RPC ..................................................................... 4-123 desplazamiento, consideraciones
MS RPC ALG, definido ............................................ 2-133 sobre el rango.................................................... 8-22
MSN Messenger ....................................................... 4-122 NAT-src, modo de ruta ............................................. 2-101
multicast NAT-src, traducción
árboles de distribución ..................................... 7-176 direcciones de puerto ........................................... 8-2
direcciones ......................................................... 7-138 unidireccional ...............................................8-8, 8-12
directivas ............................................................ 7-143 NAT-T ............................................................5-232 a 5-240
directivas para IGMP......................................... 7-160 frecuencia de mantenimiento
reenvío por rutas inversas ............................... 7-138 de conexión ..................................................... 5-238
rutas estáticas .................................................... 7-140 habilitar .............................................................. 5-239
tablas de enrutamiento .................................... 7-139 iniciador y respondedor ................................... 5-238
Multitono discreto obstáculos para VPN ......................................... 5-235
véase DMT Paquete IKE ....................................................... 5-235
Paquete IPSec .................................................... 5-236
N sondeos de NAT ...................................5-233 a 5-234
NAT NAT-Traversal
definición ............................................................... 8-1 véase NAT-T
IPSec y NAT ....................................................... 5-232 negación, Deep Inspection (DI) ............................. 4-154
NAT-src con NAT-dst ............................... 8-52 a 8-63 NetBIOS .................................................................... 4-123
servidores NAT .................................................. 5-232 NetInfo ...................................................................... 2-230
NAT basada en directivas
Véase NAT-dst y NAT-src
IX-XII Índice
Índice
NetScreen-Remote ruta secundaria .................................................. 11-11

interlocutor dinámico ............................5-166, 5-173 sincronización de configuraciones .................. 11-25
opción NAT-T ..................................................... 5-232 sincronización NTP ............................... 2-259, 11-28
VPN AutoKey IKE .............................................. 5-160 sistemas virtuales .................................11-93 a 11-98
NetScreen-Security Manager supervisión de interfaces.................................. 11-11
administración del sistema ............. 3-20, 3-21, 3-23 tiempo de retención .............................. 11-38, 11-41
Agente de NSM ...........................................3-21, 3-23 VSI ......................................................................... 2-47
comunicar eventos .....................................3-23, 3-24 VSIs ....................................................................... 11-5
configuración de la conectividad inicial ........... 3-21 VSIs, rutas estáticas............................... 11-22, 11-48
definición ............................................................. 3-20 NSRP HA
habilitación del agente de NSM ......................... 3-22 cableado, interfaces de red .............................. 11-35
interfaz de usuario .............................................. 3-20 copia de seguridad de la sesión ....................... 11-12
opciones de administración ............................... 3-27 interfaces ............................................................ 11-29
registro ................................................................. 3-23 LED...................................................................... 11-20
NFS ............................................................................ 4-121 puertos, interfaces redundantes ...................... 11-44
niveles de prioridad NSRP RTO ....................................................11-12 a 11-17
de ancho de banda ........................................... 2-202 estados ................................................................ 11-17
NNTP ......................................................................... 4-121 sync ..................................................................... 11-26
nombre completo (DN) ........................................... 5-183 NSRP-Lite ...................................................11-99 a 11-116
nombre de clúster, NSRP ...........................11-10, 11-105 cableado ........................................................... 11-109
Nombre de punto de acceso clústeres.............................................11-102 a 11-106
véase APN comunicaciones seguras ................................. 11-106
nombres completos ................................................... 9-30 grupos VSD........................................11-106 a 11-109
nombres comunes ..................................................... 9-30 modo de prioridad .......................................... 11-108
Norma de encriptación de datos (DES) ..................... 5-6 NTP ................................................... 2-257 a 2-260, 4-121
notificación de alerta por correo electrónico ......... 3-66 desfase horario máximo................................... 2-258
NRTP ............................................................11-25, 11-115 múltiples servidores .......................................... 2-257
NSRP ........................................................................... 11-4 servidores ........................................................... 2-257
ajustes predeterminados ................................ 11-103 servidores seguros............................................. 2-260
archivos, sincronización ................................... 11-26 sincronización NSRP ......................................... 2-259
cableado ................................................11-34 a 11-36 tipos de autenticación ....................................... 2-260
comando clear cluster .................................... 11-105 NTP, sincronización de NSRP ................................. 11-28
comando debug cluster .................................. 11-105 Números de sistema autónomo (AS) ..................... 7-113
comunicaciones seguras .................................. 11-10
configuración en malla completa .........11-34, 11-94 O
Consulta de ARP ................................................ 11-41 objetos AV
copia de seguridad de la sesión HA ................ 2-176 tiempo de espera................................................. 4-81
DHCP .................................................................. 2-236 objetos de ataque ............................ 4-107, 4-118 a 4-125
difusiones ARP................................................... 11-11 anomalías del protocolo ....................... 4-125, 4-153
grupos de DIP .......................................2-157 a 2-159 desactivar ........................................................... 4-129
grupos VSD ..................11-18 a 11-22, 11-37, 11-117 firmas completas ............................................... 4-124
interfaces redundantes ....................................... 2-46 firmas de secuencias ......................................... 4-125
IP administrativa ..................................11-88, 11-118 firmas de secuencias TCP................................. 4-151
maestro ................................................................ 11-4 fuerza bruta ............................................ 4-137, 4-138
mensajes de control ...............................11-28, 11-30 negación ............................................................. 4-154
modo de prioridad ............................................ 11-18 volver a habilitar ................................................ 4-129
modos NAT y de rutas ........................................ 11-6 objetos de ataques de fuerza bruta ........................ 4-138
números de prioridad ....................................... 11-18 Objetos en tiempo de ejecución
puertos redundantes ......................................... 11-28 véase RTOs
reenvío de paquetes y enrutamiento objetos, supervisión ................................................. 11-85
dinámico .......................................................... 11-31 OCSP (Online Certificate Status Protocol) ............... 5-35
reparto de carga ................................................ 11-94 cliente ................................................................... 5-35
respaldo ................................................................ 11-4 servidor de respuesta .......................................... 5-35
RTOs ................................................................... 11-37 ojos de aguja............................................................... 6-19
Índice IX-XIII
opción de aplicación, en directivas ....................... 2-172 marca de hora ..................................................... 4-10

opción de marca de tiempo de IP ........................... 4-10 ruta de origen ...................................................... 4-24
opción de reencriptación, supervisión ruta de origen abierta .................... 4-10, 4-24 a 4-26
de VPN ................................................................... 5-241 ruta de origen estricta ................... 4-10, 4-24 a 4-26
opción de seguridad IP ......................................4-9, 4-11 seguridad .......................................................4-9, 4-11
opción IP de grabación de ruta ................................ 4-10 Open Shortest Path First
opción IP de ID de secuencia ..........................4-10, 4-11 Consulte OSPF
opción IP de ruta de origen abierta .... 4-10, 4-24 a 4-26 OSPF
opción IP de ruta de origen estricta ... 4-10, 4-24 a 4-26 área de rutas internas ......................................... 7-49
opciones “unicast” desconocidas ................. 2-84 a 2-89 área no exclusiva de rutas internas .................. 7-49
ARP ............................................................ 2-86 a 2-89 conexiones virtuales ........................................... 7-63
inundación ................................................ 2-85 a 2-86 configuración de seguridad ................................ 7-67
trace-route ............................................................ 2-87 ECMP support ...................................................... 7-62
opciones criptográficas .................................. 5-48 a 5-62 equilibrio de carga .............................................. 7-38
acceso telefónico ...................................... 5-56 a 5-62 interfaces, asignación a áreas ............................ 7-55
algoritmos de autenticación ..5-51, 5-55, 5-58, 5-61 interfaces, túnel ................................................... 7-72
algoritmos de encriptación ........... 5-51 a 5-58, 5-61 inundación, LSA reducida .................................. 7-71
comprobación contra reprocesamiento inundaciones, protección contra ....................... 7-70
de paquetes ..............................................5-53, 5-59 LSA, supresión ..................................................... 7-71
ESP ...............................................................5-54, 5-61 notificaciones de estado de conexiones ........... 7-48
identificación IKE ................ 5-51 a 5-53, 5-58 a 5-59 parámetros de interfaz ....................................... 7-65
longitudes de bits de los certificados .......5-50, 5-57 parámetros globales............................................ 7-61
métodos de administración de claves .............. 5-49 pasos de configuración ....................................... 7-52
modo de transporte ............................................ 5-60 protocolo de saludo ............................................ 7-50
Modo de túnel ..................................................... 5-60 punto a multipunto ............................................. 7-72
modos de fase 1 .........................................5-49, 5-56 red punto a punto ............................................... 7-50
PFS ...............................................................5-53, 5-59 redes de difusión ................................................. 7-50
protocolos IPSec .........................................5-54, 5-60 soporte de ECMP ................................................. 7-62
punto a punto ........................................... 5-48 a 5-55 tipo de conexión, establecimiento .................... 7-72
recomendaciones VPN de acceso vecinos, autenticación ........................................ 7-67
telefónico ........................................................... 5-62 vecinos, filtrado ................................................... 7-68
recomendaciones VPN punto a punto .............. 5-55
tipos de autenticación ...............................5-50, 5-57 P
opciones de administración P2P ............................................................................ 4-122
gestionables ......................................................... 3-30 BitTorrent ........................................................... 4-122
interfaces ............................................................. 3-26 DC ....................................................................... 4-122
MGT, interfaz ....................................................... 3-27 eDonkey ............................................................. 4-122
Modo transparente ............................................. 3-27 FastTrack ............................................................ 4-122
NetScreen-Security Manager ............................. 3-27 Gnutella .............................................................. 4-122
ping ....................................................................... 3-27 KaZaa .................................................................. 4-122
SNMP .................................................................... 3-26 MLdonkey .......................................................... 4-122
SSH ....................................................................... 3-26 Skype .................................................................. 4-123
SSL ........................................................................ 3-26 SMB ..................................................................... 4-123
Telnet.................................................................... 3-26 WinMX................................................................ 4-123
VLAN1 .................................................................. 3-27 PAP .................................................................5-208, 5-211
WebUI .................................................................. 3-26 paquetes ..................................................................... 3-92
Opciones de administración de SSL........................ 3-26 ataque de simulación de dirección ................... 3-91
Opciones de administración de Telnet ................... 3-26 ataque terrestre ................................................... 3-91
Opciones de administración del comando ping .... 3-27 colisión ................................................................. 3-90
opciones IP ........................................................ 4-9 a 4-11 descartados .......................................................... 3-92
atributos ...................................................... 4-9 a 4-10 entrantes .............................................................. 3-90
formateadas incorrectamente ......................... 4-166 fragmentados....................................................... 3-92
grabación de ruta ................................................ 4-10 IPSec ..................................................................... 3-91
ID de secuencia ..........................................4-10, 4-11 no enrutables ....................................................... 3-92
IX-XIV Índice
Índice
Protocolo de encapsulamiento de punto véase RIP

a punto (PPTP) .................................................. 3-91 Protocolo de redundancia de NetScreen
Protocolo de mensajes de control de Internet véase NSRP
(ICMP) ........................................................3-88, 3-91 Protocolo de transferencia de hipertexto (HTTP),
que no se pueden recibir.................................... 3-90 ID de sesión ............................................................... 3-4
rechazados ........................................................... 3-92 protocolo de transporte fiable de NetScreen
recibidos ............................................ 3-90, 3-91, 3-92 véase NRTP
Traducción de direcciones de red (NAT) .......... 3-91 protocolo ligero de acceso a directorios
transmitidos por defecto .................................... 3-90 véase LDAP
transmitidos por defecto (underrun) ................ 3-90 protocolo punto a punto
paquetes de firmas, DI ............................................ 4-110 véase PPP
par de claves pública/privada ................................... 5-23 protocolos
parámetros del sistema .......................................... 2-259 CHAP................................................................... 5-208
Password Authentication Protocol NRTP ..................................................... 11-25, 11-115
véase PAP NSRP ..................................................................... 11-1
PAT ....................................................................2-145, 8-16 PAP...................................................................... 5-208
PCMCIA ....................................................................... 3-54 PPP ...................................................................... 5-206
personalizados, servicios ........................................ 2-125 VRRP ..................................................... 11-88, 11-118
ALG ..................................................................... 2-172 protocolos desconocidos ......................................... 4-167
PFS ........................................................... 5-12, 5-53, 5-59 protocolos, CHAP ....................................................... 9-77
PIM-SM ...................................................................... 7-176 Proveedor de servicios de Internet (ISP) ............... 2-227
configuración de puntos de encuentro ........... 7-191 proveedor de servicios, información del ................. 12-2
configuraciones de seguridad .......................... 7-193 Proxies de IGMP
enrutador designado ......................................... 7-177 emisor ................................................................. 7-167
IGMPv3 ............................................................... 7-207 en interfaces ...................................................... 7-158
instancias, creación .......................................... 7-181 Proxy de IGMP ......................................................... 7-155
parámetros de interfaz ..................................... 7-196 Puerta de enlace en la capa de aplicación
pasos de configuración ..................................... 7-180 véase ALG
proxy RP............................................................. 7-198 puertas de enlace redundantes .................5-290 a 5-303
puntos de encuentro ......................................... 7-177 comprobación de flag TCP SYN ....................... 5-296
tráfico, reenvío .................................................. 7-178 procedimiento de recuperación ...................... 5-295
PIM-SSM.................................................................... 7-180 puerto de módem .................................................... 12-59
Ping of Death ............................................................. 4-55 puerto, modos de
PKI ............................................................................... 5-22 Home-Work para ADSL .................................... 12-10
PKI keys ........................................................................ 3-6 inalámbrico ........................................................ 12-38
Portmapper .............................................................. 4-121 Trust/Untrust/DMZ para ADSL ......................... 12-17
PPP ...................................................................5-206, 12-3 puertos
PPPoA....................................................... 12-3, 12-4, 12-6 asignación .................................................... 8-5, 8-30
PPPoE .......................................................................... 12-3 conmutación por error ..................................... 11-44
propuestas números ............................................................... 8-90
Fase 1 ............................................................5-9, 5-70 principales, fiables y no fiables ....................... 11-44
Fase 2 ..........................................................5-11, 5-70 redundantes ....................................................... 11-28
protección contra reprocesamiento secundarios, fiables y no fiables ...................... 11-44
de paquetes ............................................................. 5-12 supervisión ......................................................... 11-87
protección contra URL maliciosas ................4-60 a 4-63 puertos de módem .................................................... 3-20
protección frente a ataques Puertos NSRP
nivel de directivas ................................................. 4-4 conmutación por error ..................................... 11-44
nivel de zona de seguridad .................................. 4-4 supervisión ......................................................... 11-87
Protocol Independent Multicast puertos troncales ..................................................... 10-20
véase PIM puertos troncales, modo Transparente .................. 10-20
Protocolo de encapsulamiento de GPRS (GTP) Punto a punto
véase GTP véase P2P
Protocolo de encapsulamiento de Punto de acceso inalámbrico
punto a punto (PPTP) ............................................. 3-91 véase WAP
Protocolo de información de enrutamiento
Índice IX-XV
Q 2132, DHCP Options and BOOTP

QoS (calidad del servicio) ....................................... 2-197 Vendor Extensions ...................................... 2-234
2326, Real Time Streaming Protocol
R (RTSP) .............................................2-134, 2-138
RADIUS .......................................3-38, 4-121, 9-21 a 9-23 2474, “Definition of the “Differentiated Services”
archivo de diccionario de ScreenOS ................... 9-2 Field (DS Field) in the IPv4
L2TP .................................................................... 5-211 and IPv6 Headers” ...................................... 2-178
objetos servidor de autenticación ..................... 9-30 791, Internet Protocol ....................................... 4-9
propiedades del objeto ....................................... 9-21 792, Internet Control Messages Protocol ........ 2-130
puertos ................................................................. 9-21 793, Transmission Control Protocol ................. 4-13
secreto compartido ............................................. 9-21 RFC 1777, Lightweight Directory Access
tiempo de espera entre reintentos.................... 9-21 Protocol............................................................. 9-29
Rango IP dinámico(DIP) ......................................... 2-147 RIP
rastreo autenticación de vecinos .................................... 7-92
puertos abiertos .................................................... 4-8 base de datos ..................................................... 7-100
red ........................................................................... 4-7 configuración de circuito de demanda ........... 7-101
sistemas operativos ...................................4-11, 4-14 equilibrio de carga .............................................. 7-38
reconocimiento ................................................. 4-6 a 4-26 filtrado de vecinos ............................................... 7-93
análisis de puertos ................................................ 4-8 instancias, creación en VR ................................. 7-82
análisis FIN .......................................................... 4-14 interfaces, habilitar en ........................................ 7-83
barrido de direcciones .......................................... 4-7 inundaciones, protección contra ....................... 7-95
flags SYN y FIN activados .................................. 4-11 parámetros de interfaz ....................................... 7-91
opciones IP ............................................................ 4-9 parámetros globales............................................ 7-89
paquete TCP sin flags ......................................... 4-13 punto a multipunto ........................................... 7-104
recuperación de acceso telefónico ........................ 12-59 resumen de prefijo .............................................. 7-99
Red de área local inalámbrica versiones .............................................................. 7-97
véase WLAN versiones, protocolo............................................ 7-97
red, ancho de banda ............................................... 2-197 RIP, configuración
redes privadas virtuales circuitos de demanda ....................................... 7-102
véase VPNs pasos ..................................................................... 7-81
reensamblaje de fragmentos ......................... 4-60 a 4-63 seguridad .............................................................. 7-92
registro ...................................................................... 2-176 RIP, visualización
grupos de objetos de ataque ............................ 4-140 base de datos ....................................................... 7-86
NetScreen-Security Manager ............................. 3-23 detalles de interfaz .............................................. 7-88
registro de eventos .................................................... 3-54 detalles de protocolo........................................... 7-86
registro de recuperación de equipos ....................... 3-63 información de vecinos ...................................... 7-87
registro propio ........................................................... 3-61 rlogin ......................................................................... 4-121
registro, tráfico .......................................................... 13-6 rsh.............................................................................. 4-121
reglas, derivadas de directivas ............................... 2-168 RSH ALG ................................................................... 2-131
reloj del sistema.......................................... 2-256 a 2-260 RTOs .............................................................11-12 a 11-17
fecha y hora ....................................................... 2-256 estados de funcionamiento .............................. 11-17
huso horario ...................................................... 2-256 interlocutores ..................................................... 11-19
sincronización con cliente ............................... 2-256 sincronización ................................................... 11-26
reparto de carga....................................................... 11-94 RTSP .......................................................................... 4-121
requisitos del explorador ............................................ 3-2 RTSP ALG
requisitos del explorador web .................................... 3-2 códigos de estado.............................................. 2-137
rexec ......................................................................... 4-121 definido .............................................................. 2-134
RFC métodos de petición ......................................... 2-135
1038, Revised IP Security Option ...................... 4-9 servidor en dominio privado ........................... 2-139
1349, “Type of Service in the Internet servidor en dominio público ............................ 2-140
Protocol Suite”............................................ 2-178 ruta de origen ............................................................. 3-92
1918, Address Allocation for ruta nula...................................................................... 5-87
Private Internets ........................................... 2-56 ruta secundaria ........................................................ 11-11
IX-XVI Índice
Índice
rutas opciones IP incorrectas, descartar .................. 4-166

conmutación por error del túnel ................... 11-119 paquete TCP sin flags, detectar ......................... 4-13
exportación .......................................................... 7-44 paquetes ICMP grandes, bloquear ................... 4-165
filtrado .................................................................. 7-42 Ping of Death ....................................................... 4-55
importar ............................................................... 7-44 protocolos desconocidos, descartar ................ 4-167
mapas ................................................................... 7-40 simulación de IP .......................................4-18 a 4-24
métricas ................................................................ 7-32 Teardrop ............................................................... 4-56
preferencia ........................................................... 7-31 zonas VLAN y MGT................................................ 4-3
redistribución....................................................... 7-39 SCREEN, zona MGT ................................................... 2-28
selección ............................................................... 7-31 ScreenOS
supervisión ....................................................... 11-117 archivos de diccionario ....................................... 9-22
Rutas BGP, agregado directivas ................................................................ 2-3
AS-Path en .......................................................... 7-134 flujo de paquetes ......................................2-11 a 2-13
AS-Set en ............................................................ 7-132 ID de fabricante ................................................... 9-23
atributos de ........................................................ 7-135 sistemas virtuales ................................................ 2-10
Rutas BGP, agregar vista general ........................................................... 2-1
agregar................................................................ 7-132 VR .......................................................................... 10-5
Rutas OSPF zona de seguridad global ...................................... 2-2
predeterminado, rechazo ................................... 7-69 zona global ........................................................... 2-28
redistribución....................................................... 7-59 zonas ................................................ 2-25 a 2-33, 10-5
redistribuido, resumen ....................................... 7-60 zonas de función ................................................. 2-32
restricción route-deny, inhabilitación ............... 7-73 zonas de seguridad ..................................... 2-2, 2-28
zonas de seguridad predefinidas ......................... 2-2
S zonas de túnel...................................................... 2-28
SA inactiva .................................................................. 3-92 ScreenOS, archivo de diccionario de ......................... 9-2
SAs ................................................................ 5-8, 5-9, 5-11 SDP ...................................................................6-18 a 6-19
SCEP (Simple Certificate Enrollment Protocol) ...... 5-30 secuencia de bits ....................................................... 3-90
SCP Secure Copy
ejemplo de comando del cliente ....................... 3-18 Consulte SCP
habilitar ................................................................ 3-18 véase SCP
SCREEN Secure Hash Algorithm-1
análisis de puertos ................................................ 4-8 véase SHA-1
Ataques terrestres (land attacks) ....................... 4-54 Secure Shell
Ataques WinNuke ............................................... 4-57 véase SSH
barrido de direcciones .......................................... 4-7 Secure Sockets Layer
descartar las direcciones MAC véase SSL
desconocidas ..................................................... 4-45 SecurID ....................................................................... 9-27
FIN sin ACK .......................................................... 4-15 autenticador ......................................................... 9-27
FIN sin flag ACK, descarte.................................. 4-12 códigos token ....................................................... 9-27
flags SYN y FIN activados................................... 4-11 L2TP .................................................................... 5-211
fragmentos de paquetes IP, bloquear ............. 4-168 objeto servidor de autenticación ....................... 9-32
fragmentos SYN, detectar ................................ 4-169 Opción Use Duress:............................................. 9-28
ICMP puerto de autenticación ...................................... 9-28
fragmentos, bloquear .................................. 4-164 servidores ACE..................................................... 9-28
inundaciones del proxy SYN-ACK-ACK ............ 4-38 tipos de encriptación .......................................... 9-28
Inundaciones ICMP ............................................. 4-52 usuarios, tipos admitidos ................................... 9-28
Inundaciones SYN ....................................4-40 a 4-45 seguimiento de IP ...........................11-88, 11-117, 12-61
Inundaciones UDP .............................................. 4-53 conmutación por error del túnel ................... 11-119
opción IP de ruta de origen abierta, ejecución del comando ping
detectar .............................................................. 4-26 y ARP .................................................. 11-88, 11-117
opción IP de ruta de origen estricta, interfaces compartidas ....................................... 2-65
detectar .............................................................. 4-26 interfaces compatibles ........................................ 2-65
opción IP de ruta de origen, denegar ............... 4-26 opción “dynamic” ............................................... 2-66
opciones IP............................................................. 4-9 peso....................................................................... 2-67
Índice IX-XVII
pesos................................................................. 11-118 tiempo de espera ................................................ 9-19

redireccionar el tráfico ............................ 2-65 a 2-80 tipos ...................................................................... 9-19
umbral de conmutación por error véase autenticación, servidores
del dispositivo ............................................... 11-118 servidores de autenticación, objetos de
umbral de fallos de la IP supervisada ........... 11-118 nombres ............................................................... 9-19
umbral de fallos del objeto ................................ 2-66 propiedades ......................................................... 9-19
vsys ....................................................................... 2-65 servidores de autenticación, RADIUS ..........9-21 a 9-23
seguimiento de IP, fallo del definición ............................................................. 9-30
interfaz de entrada, en ............................ 2-78 a 2-80 usuarios, tipos admitidos ................................... 9-22
interfaz de salida, en ............................... 2-76 a 2-77 servidores, SecurID ACE ........................................... 9-28
umbral de IP supervisado .................................. 2-66 sesiones multimedia, SIP.......................................... 6-13
seguimiento de ruta ................................................ 12-61 SHA-1 ............................................................................ 5-6
seguimiento de túnel .............................................. 12-61 simulación de IP .............................................4-18 a 4-24
Seguridad IP drop-no-rpf-route ................................................. 4-19
véase IPSec Layer 2.........................................................4-19, 4-23
selección, modos de Layer 3.........................................................4-18, 4-20
APN ..................................................................... 13-13 sincronización
Estación móvil (MS) .......................................... 13-13 archivos .............................................................. 11-26
red ....................................................................... 13-13 configuración ..................................................... 11-25
Verificado ........................................................... 13-13 objetos PKI ......................................................... 11-26
serie, cables ................................................................ 3-19 RTOs ................................................................... 11-26
Servicio de autenticación remota de usuarios Sincronización de NSRP-Lite
de acceso telefónico archivo .............................................................. 11-115
véase RADIUS config ................................................................ 11-115
servicios .................................................................... 2-111 desactivar ......................................................... 11-116
definición ........................................................... 2-170 sincronización NSRP
en directivas ...................................................... 2-170 NTP, NSRP ......................................................... 11-28
ICMP ................................................................... 2-130 PKI ...................................................................... 11-26
lista desplegable ................................................ 2-111 RTOs ................................................................... 11-26
personalizados................................................... 4-142 SIP
umbral del tiempo de espera .......................... 2-127 ALG ..............................................................6-17, 6-21
servicios ICMP ......................................................... 2-130 anuncios de medios ............................................ 6-19
códigos de mensaje .......................................... 2-130 caducidad por inactividad .................................. 6-21
tipos de mensaje ............................................... 2-130 códigos de respuesta .......................................... 6-16
servicios personalizados ......................................... 2-125 definido ................................................................ 6-13
servicios personalizados, en raíz y vsys................ 2-125 información de la conexión ............................... 6-19
Servicios VIP mensajes .............................................................. 6-14
personalizados y multipuerto ................. 8-88 a 8-92 Métodos de petición ........................................... 6-14
personalizados, números de puerto bajos ....... 8-84 ojos de aguja ........................................................ 6-18
servicios, personalizados respuestas ............................................................ 6-16
en vsys ............................................................... 2-125 RTCP ..................................................................... 6-19
servidores de autenticación .......................... 9-13 a 9-37 RTP ....................................................................... 6-19
consultas de XAuth ............................................. 9-65 SDP ............................................................6-18 a 6-19
definición .................................................. 9-30 a 9-37 señalización ......................................................... 6-17
direcciones ........................................................... 9-19 sesiones multimedia ........................................... 6-13
externos ............................................................... 9-17 tiempo de espera por inactividad
LDAP .......................................................... 9-29 a 9-30 de la sesión ........................................................ 6-21
número de identificación ................................... 9-19 tiempo de espera por inactividad
número máximo ................................................. 9-14 de medios .................................................6-22, 6-23
predeterminadas ................................................. 9-36 tiempo de espera por inactividad
proceso de autenticación ................................... 9-17 de señalización .........................................6-22, 6-23
respaldo ................................................................ 9-19 tipos de métodos de petición ............................ 6-14
SecurID ................................................................. 9-27 SIP NAT
SecurID, definición ............................................. 9-32 con VPN de malla completa............................... 6-55
IX-XVIII Índice
Índice
configuración de llamadas ........................6-24, 6-30 SSL, protocolo de saludo

definido ................................................................ 6-24 véase SSLHP
entrante, con MIP.......................................6-37, 6-39 SSLHP ............................................................................ 3-5
proxy en DMZ ...................................................... 6-46 subinterfaces .................................................... 2-4, 10-22
proxy en zona privada........................................ 6-41 configuración (vsys) .......................................... 10-22
proxy en zona pública ........................................ 6-43 creación (vsys) ................................................... 10-22
trust intrazonal .................................................... 6-53 crear (sistema raíz) .............................................. 2-57
untrust intrazonal ................................................ 6-49 eliminar ................................................................ 2-58
utilizar DIP de interfaz ........................................ 6-34 varias por vsys ................................................... 10-22
utilizar DIP entrante ............................................ 6-33 Sun RPC ALG
utilizar un conjunto de DIP ................................ 6-37 definido .............................................................. 2-131
Sistema de nombres de dominio supuestos de llamadas ...................................... 2-131
véase DNS superpuestas, redes ................................................. 10-23
sistema, reloj supervisión de VPN ........................ 5-240 a 5-252, 12-62
véase reloj del sistema cambios de estado ................................ 5-240, 5-244
sistemas operativos, sondeos dirección de destino .............................5-242 a 5-245
de host para..................................................4-11 a 4-14 dirección de destino, XAuth ............................. 5-243
sistemas virtuales ...................................................... 2-10 directivas ............................................................ 5-243
administradores .................................................. 3-33 diseño de rutas .................................................... 5-72
administradores de sólo lectura ........................ 3-32 interfaz de salida ..................................5-242 a 5-245
conmutación por error ..................................... 11-93 opción de reencriptación...................... 5-241, 5-258
manejabilidad y seguridad de.......................... 10-31 peticiones de eco ICMP .................................... 5-252
NSRP ................................................................... 11-93 SNMP .................................................................. 5-252
reparto de carga ................................................ 11-94 Supresión de notificaciones de estado
VIP......................................................................... 10-9 de conexiones (LSA) ............................................... 7-71
SMB SurfControl ....................................................... 4-89, 4-97
NetBIOS .............................................................. 4-123 suscripciones
SMTP server IP ........................................................... 3-67 registro y activación .............................2-254 a 2-256
SNMP .................................................................3-26, 3-69 servicio temporal ............................................... 2-254
archivos MIB, importación ............................... 5-252 SYN, cookies............................................................... 4-50
captura de inicio en frío ..................................... 3-70 syslog............................................................... 3-54, 4-121
configuración ....................................................... 3-72 encriptación ......................................................... 3-74
encriptación ................................................3-72, 3-74 host ....................................................................... 3-67
opciones de administración ............................... 3-26 mensajes .............................................................. 3-67
supervisión de VPN ........................................... 5-252 nombre de host ...................... 3-68, 3-69, 3-77, 3-84
SNMPTRAP ............................................................... 4-121 puerto ................................................3-68, 3-77, 3-84
sobrefacturación, Ataques de ....................13-22 a 13-24 servicio de seguridad .......................3-68, 3-77, 3-84
SSH ....................................................... 3-11 a 3-16, 4-121 utilidad ...............................................3-68, 3-77, 3-84
autenticación mediante contraseña .................. 3-14
autenticación mediante PKA ............................. 3-14 T
cargar claves públicas, CLI ................................. 3-15 tabla NHTB ..................................................5-254 a 5-258
cargar claves públicas, TFTP .....................3-15, 3-17 asignación de rutas a túneles ........................... 5-255
cargar claves públicas, WebUI ........................... 3-15 entradas automáticas ........................................ 5-257
forzar la autenticación mediante PKA entradas manuales ............................................ 5-257
exclusivamente ................................................. 3-16 esquema de direccionamiento ........................ 5-256
inicios de sesión automatizados ........................ 3-17 tablas de enrutamiento ............................................. 7-15
opciones de administración ............................... 3-26 búsqueda en múltiples VR.................................. 7-36
PKA ....................................................................... 3-15 consulta ................................................................ 7-33
prioridad del método de autenticación ............ 3-16 multicast ............................................................. 7-139
procedimiento de conexión ............................... 3-12 selección de rutas ................................................ 7-31
SSID ........................................................................... 12-36 tipos ...................................................................... 7-15
SSL ......................................................................3-5, 4-121 tareas programadas ..................................... 2-160, 2-177
SSL, con WebAuth...................................................... 9-58
Índice IX-XIX
TCP umbral inferior ........................................................... 4-36

comprobación de flag SYN .............................. 5-296 umbral superior ......................................................... 4-36
firmas de secuencias ........................................ 4-151 umbrales
paquete sin flags ................................................. 4-13 umbral inferior .................................................... 4-36
tiempos de espera de la sesión ......................... 4-37 umbral superior ................................................... 4-36
TCP proxy ................................................................... 3-92 usuarios
Telnet .................................................................3-9, 4-121 administrador, tiempo de espera ...................... 9-19
TFTP .......................................................................... 4-121 administradores .................................................... 9-2
tiempo de espera ..................................................... 13-21 de múltiples tipos .................................................. 9-4
usuarios administradores ................................... 9-19 grupos, servidores admitidos ............................ 9-14
usuarios de autenticación .................................. 9-19 identificación IKE compartida ............5-198 a 5-203
tiempo de espera inactivo por sesión ..................... 9-20 identificación IKE de grupo.................5-183 a 5-198
tiempo de espera por sesión inactiva ..................... 9-20 L2TP ...........................................................9-82 a 9-86
tiempo de inactividad de VPN ................................. 9-67 WebAuth .............................................................. 9-14
tiempos de espera de la sesión XAuth .........................................................9-64 a 9-80
HTTP ..................................................................... 4-37 usuarios administradores ........................................... 9-2
TCP ....................................................................... 4-37 privilegios desde RADIUS ..................................... 9-3
UDP....................................................................... 4-37 servidores admitidos .......................................... 9-14
Tipos de atributos VSA .............................................. 9-23 tiempo de espera ................................................ 9-19
trace-route .................................................................. 2-87 usuarios autorizados, autenticación de
traducción de direcciones previa a la directiva............................................. 9-41
Véase NAT, NAT-dst y NAT-src punto de ................................................................. 9-1
Traducción de direcciones de puertos servidores de autenticación, con....................... 9-14
véase PAT usuarios de autenticación ..............................9-39 a 9-60
Traducción de direcciones de red (NAT) ................. 3-91 administradores .................................................... 9-2
tráfico autenticación en tiempo de ejecución ............ 2-175
asignación .......................................................... 2-197 autenticación previa a la directiva .................. 2-175
clasificación ............................................ 10-9 a 10-17 base de datos local ...................................9-16 a 9-17
prioridad ............................................................ 2-178 clave manual ........................................................ 9-14
recuento ....................................................2-177, 13-6 de múltiples tipos .................................................. 9-4
registro ......................................................2-176, 13-6 en directivas ........................................................ 9-40
según IP.............................................................. 10-29 grupos ..........................................................9-39, 9-42
según VLAN .............................. 10-18, 10-19 a 10-28 IKE ...............................................................9-14, 9-61
tráfico de tránsito, clasificación inicio de sesión, con diferentes nombres .......... 9-5
de vsys ................................................ 10-10 a 10-13 L2TP ...................................................................... 9-82
tráfico administrativo ................................................ 3-27 proceso de autenticación en tiempo
tráfico GTP de ejecución..................................................... 2-175
recuento ............................................................. 13-28 servidores admitidos .......................................... 9-14
registro ............................................................... 13-26 tiempo de espera ................................................ 9-19
Transparente, modo ................................................ 10-20 tipos de usuarios ................................................. 9-13
Triple DES tipos y aplicaciones ......................................9-1 a 9-5
véase 3DES véase usuarios de autenticación
troncales, puertos .................................................... 10-20 WebAuth ...................................................2-175, 9-14
túnel de GTP colgado .............................................. 13-21 XAuth .................................................................... 9-65
Túneles GTP usuarios de autenticación, tiempo de ejecución
conmutación por error ..................................... 13-20 autenticación ....................................................... 9-40
límite .................................................................. 13-19 grupo de usuarios externos................................ 9-49
tiempo de espera .............................................. 13-21 locales, grupos de usuarios ................................ 9-45
proceso de autenticación ................................... 9-40
U usuarios externos ................................................ 9-47
UDP usuarios locales ................................................... 9-43
encapsulación NAT-T ........................................ 5-232 usuarios de autenticación, WebAuth ....................... 9-41
suma de comprobación.................................... 5-237 con SSL (externos, grupos de usuarios) ............ 9-57
tiempos de espera de la sesión ......................... 4-37 grupo de usuarios, externos .............................. 9-55
IX-XX Índice
Índice
grupos de usuarios locales ................................. 9-54 VPI ............................................................................... 12-2

usuarios IKE .......................................... 9-14, 9-61 a 9-64 VPN
con otros tipos de usuario .................................... 9-4 a una zona con NAT basada en interfaces ....... 2-96
definición ............................................................. 9-62 AutoKey IKE ........................................3-42, 3-75, 5-7
grupos ................................................................... 9-62 clave manual ........................................................ 3-74
grupos, definir ..................................................... 9-64 claves manuales .................................................. 3-42
grupos, y............................................................... 9-61 consejos de configuración .......................5-70 a 5-72
identificación IKE .......................................9-61, 9-77 Diffie-Hellman, grupos ........................................ 5-10
servidores admitidos .......................................... 9-14 directiva para bidireccionales .......................... 5-127
usuarios L2TP ............................................................. 9-82 directivas ............................................................ 2-172
con XAuth .............................................................. 9-4 Fase 1 ..................................................................... 5-9
servidores admitidos .......................................... 9-14 Fase 2 ................................................................... 5-11
usuarios XAuth flujo de paquetes ......................................5-64 a 5-70
autenticación ....................................................... 9-65 grupos redundantes, procedimiento
autenticación de grupos locales ........................ 9-70 de recuperación............................................... 5-295
autenticación local .............................................. 9-68 grupos VPN ........................................................ 5-291
con L2TP ................................................................ 9-4 ID de proxy, coincidencia .................................. 5-71
servidores admitidos .......................................... 9-14 intercambio Diffie-Hellman................................ 5-10
usuarios, IKE modo dinámico ................................................... 5-10
véase usuarios IKE Modo principal ..................................................... 5-10
usuarios, múltiples administrativos ......................... 3-31 múltiples túneles por interfaz
de túnel ...............................................5-254 a 5-288
V opciones criptográficas ............................5-48 a 5-62
validación del número de secuencia ..................... 13-17 para tráfico administrativo ................................. 3-74
VC ................................................................................ 12-2 protección contra reprocesamiento
VCI ............................................................................... 12-2 de paquetes ....................................................... 5-12
Verisign ....................................................................... 5-35 puertas de enlace redundantes...........5-290 a 5-303
VIP ......................................................................2-12, 10-9 SAs .......................................................................... 5-8
alcanzable desde otras zonas ............................ 8-85 supervisión y reencriptación de VPN .............. 5-241
configuración ....................................................... 8-85 túnel siempre activo ......................................... 5-241
definición ............................................................... 8-7 zonas de túnel...................................................... 2-28
edición .................................................................. 8-87 VPN AutoKey IKE ......................................3-42, 3-75, 5-7
eliminación .......................................................... 8-87 administración ....................................................... 5-7
información necesaria ........................................ 8-84 VPN basada en directivas ......................................... 5-63
zonas globales ..................................................... 8-85 VPN basadas en rutas .....................................5-63 a 5-64
VIP, a una zona con NAT basada en interfaces ...... 2-96 VPNs
VLAN alias FQDN ......................................................... 5-132
clasificación del tráfico basadas en rutas o basadas en directivas ........ 5-63
según VLAN ............................ 10-18, 10-19 a 10-28 FQDN para puertas de enlace .............5-131 a 5-141
comunicación con otra MIP ...................................................................... 5-141
VLAN........................................ 10-17, 10-25 a 10-28 modo de transporte .............................................. 5-4
crear .......................................................10-21 a 10-24 NAT para direcciones
entroncamiento ................................................. 10-20 superpuestas .......................................5-141 a 5-152
etiqueta....................................................10-21, 10-22 NAT-dst ............................................................... 5-141
modo transparente ................................10-20, 10-21 NAT-src ............................................................... 5-144
subinterfaces...................................................... 10-22 VR ................................................................................ 10-5
VLAN1 compartido, crear un ........................................ 10-16
interfaz ........................................................2-83, 2-89 compartidos ....................................................... 10-15
zonas..................................................................... 2-83 introducción ........................................................... 2-4
VLAN1, opciones de administración ....................... 3-27 reenviar tráfico entre dos ..................................... 2-5
VNC ........................................................................... 4-122 VR compartidos ....................................................... 10-15
voz sobre IP VR, rutas
administración del ancho de banda ................. 6-60 exportación .......................................................... 7-44
definición ............................................................... 6-1 filtrado .................................................................. 7-42
Índice IX-XXI
importar ............................................................... 7-44 autenticación y encriptación............................ 12-39

mapas ................................................................... 7-40 canales y códigos de país ................................. 12-44
preferencia ........................................................... 7-31 configuraciones, reactivación .......................... 12-47
redistribución ...................................................... 7-39 Conjuntos de servicios básicos (BSS) .............. 12-34
selección .............................................................. 7-31 lista de control de acceso ................................. 12-45
VR, tablas de enrutamiento modo de ruta ..................................................... 12-46
búsqueda en múltiples VR ................................. 7-36 modo transparente ........................................... 12-46
consulta ................................................................ 7-33 modos de funcionamiento WLAN ................... 12-46
entradas máximas .............................................. 7-30 modos de puertos ............................................. 12-38
VRRP ............................................................11-88, 11-118 sondeo del sitio ................................................. 12-44
VRs ................................................................... 7-39 a 7-44 WLAN, interfaces inalámbricas
BGP ........................................................ 7-112 a 7-119 en dispositivos de seguridad ............................ 12-35
ECMP .................................................................... 7-38 enlace ................................................................. 12-38
en vsys ................................................................. 7-27
ID de enrutador ................................................... 7-23 X
listas de acceso .................................................... 7-42 XAuth
métricas de ruta .................................................. 7-32 adaptadores virtuales.......................................... 9-65
modificar .............................................................. 7-22 asignaciones TCP/IP ............................................ 9-66
OSPF .......................................................... 7-51 a 7-70 autenticación del cliente .................................... 9-81
RIP ............................................................. 7-81 a 7-97 bypass-auth .......................................................... 9-66
SBR ....................................................................... 7-17 consultar ajustes remotos .................................. 9-65
SIBR ...................................................................... 7-20 definición ............................................................. 9-64
uso de dos ............................................................ 7-24 ScreenOS como cliente ...................................... 9-81
VSA .............................................................................. 9-22 supervisión de VPN ........................................... 5-243
VSIs .................................................... 11-5, 11-18, 11-106 tiempo de inactividad de VPN ........................... 9-67
rutas estáticas .................................................... 11-22 XAuth, direcciones
varias VSI por grupo VSD ................................. 11-93 asignaciones ........................................................ 9-65
vsys autenticación, y ................................................... 9-77
administradores .................................................. 10-6 tiempo de espera ................................................ 9-66
claves .................................................................. 10-15 XAuth, usuarios ...............................................9-64 a 9-80
objetos, crear ....................................................... 10-3
Y
W Yahoo! Messenger.................................................... 4-122
WAP ........................................................................... 12-34
WebAuth ............................................................9-14, 9-41 Z
con SSL (externos, grupos de usuarios)............ 9-57 zombie, agentes ................................................4-32, 4-34
grupos de usuarios externos .............................. 9-55 zona VLAN .................................................................. 2-83
locales, grupos de usuarios ................................ 9-54 zonas ...................................................... 2-25 a 2-33, 10-5
proceso de autenticación previo capa 2 ................................................................... 2-83
a directivas ........................................................ 9-41 compartidas ....................................................... 10-15
WebAuth, proceso de autenticación definición ............................................................. 2-30
previo a directivas ................................................ 2-175 edición .................................................................. 2-31
WebTrends.........................................................3-54, 3-68 función ................................................................. 2-32
encriptación ................................................3-68, 3-74 función, interfaz MGT ......................................... 2-47
mensajes .............................................................. 3-69 global .................................................................... 2-28
WebUI ........................................................................... 3-2 interfaces de seguridad ...................................... 2-45
Archivos de ayuda ................................................ 3-2 seguridad global .................................................... 2-2
opciones de administración............................... 3-26 túnel ...................................................................... 2-28
WEP .......................................................................... 12-39 VLAN ............................................................2-33, 2-83
Whois ........................................................................ 4-122 vsys ....................................................................... 10-5
WINS zonas compartidas .................................................. 10-15
ajustes de L2TP ................................................. 5-211 zonas de seguridad .............................................2-2, 2-28
WLAN consulte zonas
antena ................................................................ 12-43 determinación de la zona de destino ............... 2-12
IX-XXII Índice
Índice
determinación de la zona de origen ................. 2-11

global ...................................................................... 2-2
predefinido............................................................. 2-2
zonas de seguridad e interfaces ................................. 2-3
zonas de seguridad, interfaces ................................. 2-45
físicas .................................................................... 2-45
zonas de seguridad, interfaces de
subinterfaces........................................................ 2-46
zonas de, seguridad
interfaces, supervisión de .................................. 2-75
zonas globales ............................................................ 8-85
zonas, global............................................................... 8-85
zonas, ScreenOS .............................................2-25 a 2-33
interfaces de seguridad ........................................ 2-3
predefinido............................................................. 2-2
zonas, seguridad
interfaces, físicas ................................................. 2-45
subinterfaces........................................................ 2-46
Índice IX-XXIII
IX-XXIV Índice
Volumen 2:
Fundamentos

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Copyright Notice
without notice.
FCC Statement
Disclaimer
Writers: Anita Davey, Carrie Nowocin, Jozef Wroblewski

Editor: Lisa Eldridge
ii
Contenido
Convenciones del documento .......................................................................... x
Capítulo 1 Arquitectura de ScreenOS 1

Zonas de seguridad .......................................................................................... 2
Interfaces de zonas de seguridad ..................................................................... 3
Interfaces físicas ........................................................................................ 3
Subinterfaces............................................................................................. 4
Enrutadores virtuales ....................................................................................... 4
Directivas......................................................................................................... 5
Redes privadas virtuales................................................................................... 7
Sistemas virtuales .......................................................................................... 10
Secuencia de flujo de paquetes ...................................................................... 11
Ejemplo: (Parte 1) Empresa con seis zonas.............................................. 14
Ejemplo: (Parte 2) Interfaces para seis zonas........................................... 16
Ejemplo: (Parte 3) Dos dominios de enrutamiento .................................. 18
Ejemplo: (Parte 4) Directivas ................................................................... 20
Capítulo 2 Zonas 25
Visualizar las zonas preconfiguradas .............................................................. 26
Zonas de seguridad ........................................................................................ 28
Zona Global ............................................................................................. 28
Opciones SCREEN ................................................................................... 28
Enlazar una interfaz de túnel a una zona de túnel.......................................... 28
Configurar zonas de seguridad y zonas de túnel ............................................ 30
Crear una zona ........................................................................................ 30
Modificar una zona.................................................................................. 31
Eliminar una zona ................................................................................... 32
Zonas de función ........................................................................................... 32
Zona Null................................................................................................. 32
Zona MGT................................................................................................ 32
Zona HA .................................................................................................. 33
Zona de registro propio (Self) .................................................................. 33
Zona VLAN ..............................................................................................33
Modos de puerto ............................................................................................ 33
Modo Trust-Untrust.................................................................................. 34
Modo Home-Work ................................................................................... 35
Modo Dual Untrust .................................................................................. 36
Contenido iii
Modo combinado (Combined) .................................................................37

Modo Trust/Untrust/DMZ (extendido) ...................................................... 38
Modo DMZ/Dual Untrust .......................................................................... 38
Modo Dual DMZ ...................................................................................... 39
Ajustar los modos de puertos ......................................................................... 40
Ejemplo: Modo de puerto Home-Work.............................................. 40
Zonas en los modos “Home-Work” y “Combined Port” ................................. 41
Ejemplo: Zonas Home-Work ............................................................. 42
Capítulo 3 Interfaces 45
Tipos de interfaces......................................................................................... 45
Interfaces de la zona de seguridad........................................................... 45
Interfaces físicas ............................................................................... 45
Subinterfaces .................................................................................... 46
Interfaces agregadas ......................................................................... 46
Interfaces redundantes...................................................................... 46
Interfaces de seguridad virtuales ....................................................... 47
Interfaces de zonas de función ................................................................ 47
Interfaces de administración ............................................................. 47
Interfaces de alta disponibilidad........................................................ 47
Interfaces de túnel................................................................................... 48
Eliminar interfaces de túnel .............................................................. 51
Visualizar interfaces ....................................................................................... 52
Configurar interfaces de la zona de seguridad................................................ 53
Asociar una interfaz a una zona de seguridad.......................................... 54
Desasociar una interfaz de una zona de seguridad .................................. 54
Direccionar una interfaz de la zona de seguridad L3 ............................... 54
Direcciones IP públicas ..................................................................... 55
Direcciones IP privadas..................................................................... 56
Direccionar una interfaz.................................................................... 56
Modificar los ajustes de la interfaz........................................................... 56
Crear una subinterfaz en el sistema raíz .................................................. 57
Eliminar una subinterfaz ......................................................................... 58
Crear una dirección IP secundaria.................................................................. 59
Interfaces de bucle invertido (loopback)......................................................... 60
Crear una interfaz de bucle invertido....................................................... 60
Ajustar la interfaz de bucle invertido para administración .......................61
Ajustar BGP en una interfaz de bucle invertido ........................................ 61
Ajustar VSI en una interfaz de bucle invertido ......................................... 62
Ajustar la interfaz de bucle invertido como interfaz de origen ................. 62
Cambios de estado de la interfaz ................................................................... 62
Supervisar la conexión física ................................................................... 64
Dar seguimiento a direcciones IP ............................................................ 65
Supervisar interfaces ............................................................................... 70
Supervisar dos interfaces .................................................................. 71
Supervisar un bucle de interfaz ......................................................... 72
Supervisar zonas de seguridad.................................................................75
Interfaces inactivas y flujo de tráfico ....................................................... 75
Fallo en la interfaz de salida.............................................................. 76
Fallo en la interfaz de entrada........................................................... 78
iv Contenido
Contenido
Capítulo 4 Modos de las interfaces 81

Modo transparente......................................................................................... 82
Ajustes de zona ....................................................................................... 83
Zona VLAN........................................................................................ 83
Zonas de capa 2 predefinidas............................................................ 83
Reenviar tráfico ....................................................................................... 83
Opciones “unicast” desconocidas ............................................................ 84
Método de inundación ...................................................................... 85
Método ARP/Trace-Route .................................................................. 86
Configurar la interfaz VLAN1 para administración ............................ 89
Configurar el modo transparente ...................................................... 91
Modo NAT...................................................................................................... 94
Tráfico NAT entrante y saliente ............................................................... 96
Ajustes de interfaz ................................................................................... 97
Configurar el modo NAT .......................................................................... 97
Modo de ruta ...............................................................................................100
Ajustes de interfaz .................................................................................101
Configurar el modo de ruta....................................................................101
Capítulo 5 Bloques para la construcción de directivas 105

Direcciones ..................................................................................................106
Entradas de direcciones.........................................................................106
Modificar una dirección...................................................................107
Eliminar una dirección ....................................................................108
Grupos de direcciones ...........................................................................108
Editar una entrada de grupo de direcciones ....................................110
Eliminar un miembro y un grupo ....................................................110
Servicios ......................................................................................................111
Servicios predefinidos............................................................................111
Protocolo de mensajes de control de Internet .................................112
Servicios de llamadas de procedimiento remoto de Microsoft.........117
Protocolos de enrutamiento dinámico.............................................119
Vídeo de secuencia .........................................................................119
Servicios de llamadas de procedimiento remoto de Sun .................120
Servicios de túnel y seguridad .........................................................121
Servicios relacionados con IP ..........................................................121
Servicios de administración ............................................................122
Servicios de correo..........................................................................123
Servicios varios ...............................................................................124
Servicios personalizados........................................................................125
Agregar un servicio personalizado...................................................126
Modificar un servicio personalizado ................................................126
Eliminar un servicio personalizado..................................................127
Establecer el tiempo de espera de un servicio .......................................127
Buscar y configurar el tiempo de espera de servicio........................127
Ejemplo...........................................................................................130
Definir un servicio de protocolo de mensaje de control de Internet
personalizado..................................................................................130
Puerta de enlace “Remote Shell” en la capa de aplicación ....................131
Puerta de enlace de llamada de procedimiento remoto de Sun
en la capa de aplicación ..................................................................131
Situación típica de llamadas RPC ....................................................131
Personalizar los servicios Sun RPC ..................................................132
Contenido v
Personalizar la puerta de enlace de la capa de aplicaciones del

procedimiento de llamadas remotas de Microsoft ...........................133
Puerta de enlace de la capa de aplicación del protocolo
de secuencias en tiempo real ..........................................................134
Métodos de petición RTSP...............................................................135
Códigos de estado de RTSP .............................................................137
Configurar un servidor de medios en un dominio público...............140
Grupos de servicios................................................................................142
Modificar un grupo de servicios ......................................................143
Eliminar un grupo de servicios ........................................................144
Conjuntos de IP dinámicas...........................................................................144
Traducción de direcciones de puertos....................................................145
Crear un conjunto de DIP con PAT ........................................................146
Modificar un conjunto de DIP ................................................................147
Direcciones DIP “sticky”........................................................................147
Usar DIP en otra subred ........................................................................148
Utilizar una DIP en una interfaz de bucle invertido................................153
Crear un grupo de DIP ...........................................................................157
Configurar una programación recurrente .....................................................160
Capítulo 6 Directivas 163

Elementos básicos .......................................................................................164
Tres tipos de directivas ................................................................................165
Directivas interzonales ..........................................................................165
Directivas intrazonales ..........................................................................165
Directivas globales.................................................................................166
Listas de conjuntos de directivas ..................................................................167
Definición de directivas................................................................................168
Directivas y reglas .................................................................................168
Anatomía de una directiva.....................................................................169
ID....................................................................................................170
Zonas ..............................................................................................170
Direcciones .....................................................................................170
Servicios .........................................................................................170
Nombre...........................................................................................172
Encapsulamiento VPN.....................................................................172
Encapsulamiento L2TP....................................................................173
Deep Inspection ..............................................................................173
Colocación al principio de la lista de directivas ...............................173
Traducción de direcciones de origen ...............................................174
Traducción de direcciones de destino .............................................174
Autenticación de usuarios ...............................................................174
Respaldo HA de la sesión ................................................................176
Filtrado de Web ..............................................................................176
Registro...........................................................................................176
Recuento.........................................................................................177
Umbral de alarma de tráfico ...........................................................177
Tareas programadas........................................................................177
Análisis antivirus .............................................................................177
Asignación de tráfico.......................................................................178
Directivas aplicadas .....................................................................................179
Visualizar directivas ...............................................................................179
Crear directivas .....................................................................................179
Crear servicio de correo de directivas interzonales .........................179
vi Contenido
Contenido
Crear un conjunto de directivas interzonales...................................183

Crear directivas intrazonales ...........................................................187
Crear una directiva global ...............................................................189
Entrar al contexto de una directiva........................................................190
Varios elementos por componente de directiva .....................................190
Ajustar la denegación de direcciones .....................................................191
Modificar y desactivar directivas............................................................194
Verificar directivas.................................................................................194
Reordenar directivas..............................................................................195
Eliminar una directiva ...........................................................................196
Capítulo 7 Asignar tráfico 197

Administrar el ancho de banda a nivel de directivas ....................................197
Ajustar la asignación de tráfico ....................................................................198
Ajustar las prioridades del servicio ...............................................................202
Ajustar las colas de prioridades ....................................................................203
Directivas de entrada ...................................................................................206
Asignar tráfico en interfaces virtuales ..........................................................207
Asignar el tráfico a nivel de interfaz.......................................................207
Asignar el tráfico a nivel de directiva .....................................................209
Flujo de paquetes ..................................................................................210
Ejemplo: VPN basada en rutas con directivas de entrada ......................210
Ejemplo: VPN basada en directivas con directivas de entrada ...............214
Asignar tráfico utilizando una interfaz de bucle invertido.............................217
Asignación y marcado DSCP ........................................................................218
Capítulo 8 Parámetros del sistema 221

Compatibilidad con DNS ..............................................................................221
Consulta DNS ........................................................................................222
Tabla de estado de DNS.........................................................................223
Ajustar el servidor DNS y programar actualizaciones ......................224
Establecer un intervalo de actualización de DNS .............................224
Sistema de nombres de dominio dinámico............................................224
Configurar el DDNS para un servidor DynDNS ................................225
Configurar DDNS para un servidor DDO .........................................226
Dividir direcciones DNS del proxy .........................................................227
Protocolo de configuración dinámica de hosts .............................................229
Configurar un servidor DHCP ................................................................230
Personalizar opciones de servidor DHCP.........................................234
Colocar el servidor DHCP en un clúster de NSRP ............................236
Detectar el servidor DHCP ..............................................................236
Activar la detección del servidor DHCP ...........................................236
Desactivar la detección del servidor DHCP......................................237
Asignar un dispositivo de seguridad como agente
de retransmisión de DHCP..............................................................237
Utilizar un dispositivo de seguridad como cliente DHCP........................241
Propagar ajustes TCP/IP.........................................................................243
Protocolo punto a punto sobre Ethernet.......................................................245
Configurar PPPoE ..................................................................................246
Configurar PPPoE en las interfaces principal y de respaldo de la
zona Untrust ...................................................................................249
Configurar múltiples sesiones de PPPoE a través de una sola interfaz ...250
PPPoE y alta disponibilidad ...................................................................252
Contenido vii
Claves de licencia.........................................................................................253
Registrar y activar los servicios de suscripción .............................................254
Servicio de prueba.................................................................................254
Actualizar claves de suscripción.............................................................255
Agregar antivirus, filtrado web, antispam y DI a un dispositivo .............255
Reloj del sistema ..........................................................................................256
Fecha y hora..........................................................................................256
Huso horario..........................................................................................256
Protocolo de hora de la red....................................................................257
Configurar múltiples servidores NTP ...............................................257
Configurar un servidor de respaldo del protocolo
de hora de la red ......................................................................257
Desfase temporal máximo ..............................................................258
Protocolos NTP y NSRP ...................................................................259
Ajustar un valor de desfase horario máximo en un servidor NTP ....259
Asegurar los servidores NTP............................................................260
Índice ........................................................................................................................IX-I
viii Contenido
Acerca de este volumen
El Volumen 2: Fundamentos describe la arquitectura de ScreenOS y sus elementos,

incluyendo ejemplos de configuración de algunos de ellos. Este volumen contiene
los siguientes capítulos:
En el Capítulo 1, “Arquitectura de ScreenOS,” se describen los elementos

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

túnel y las zonas de función.
En el Capítulo 3, “Interfaces,” se describen las diferentes interfaces físicas,

lógicas y virtuales de los dispositivos de seguridad.
En el Capítulo 4, “Modos de las interfaces,” se explican los conceptos

relacionados con los modos de funcionamiento de interfaz transparente, NAT
(Network Address Translation) y de rutas.
En el Capítulo 5, “Bloques para la construcción de directivas,” 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. También se incluyen diversos ejemplos de configuración
compatibles con el protocolo H.323.
En el Capítulo 6, “Directivas,” se examinan los componentes y las funciones de

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

banda en los niveles de interfaz y directivas y cómo priorizar servicios.
En el Capítulo 8, “Parámetros del sistema,” 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 configuraciones del
sistema y software y el ajuste del reloj del sistema.
ix

“Convenciones para las ilustraciones” en la página xi
“Convenciones de nomenclatura y conjuntos de caracteres” en la página xii
“Convenciones de la interfaz gráfica (WebUI)” en la página xiii

En ejemplos:


En texto:
x Convenciones del documento



10.1.1.0/24)

Internet

dinámicas (DIP)

Equipo portátil
Interfaz de túnel
Servidor
Túnel VPN
Concentrador (hub)
Enrutador
Teléfono IP
Conmutador
Convenciones del documento xi






xii Convenciones del documento


de configuración:

en OK:
Zone: Untrust
Convenciones del documento xiii




xiv Documentación de Juniper Networks

Capítulo 1
Arquitectura de ScreenOS
La arquitectura del sistema ScreenOS de Juniper Networks ofrece una gran

flexibilidad a la hora de diseñar la estructura de seguridad de una 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 zona (tráfico intrazonal) y entre zonas distintas (tráfico interzonal).
Puede enlazar una o varias interfaces a cada zona y habilitar en cada zona un
conjunto distinto de opciones de administración y de vigilancia de ataques al
cortafuegos. Básicamente, ScreenOS permite crear el número de zonas que cada
entorno de red necesita, asignar el número de interfaces que cada zona necesita y
diseñar cada interfaz según las necesidades específicas.
En este capítulo se presenta ScreenOS y se describen los siguientes componentes

principales:
“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 10
Además, para ayudarle a comprender mejor el mecanismo que utiliza ScreenOS

para procesar el tráfico, en la sección “Secuencia de flujo de paquetes” en la
página 11 verá la secuencia de flujo de un paquete entrante.
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 14
“Ejemplo: (Parte 2) Interfaces para seis zonas” en la página 16
“Ejemplo: (Parte 3) Dos dominios de enrutamiento” en la página 18
“Ejemplo: (Parte 4) Directivas” en la página 20
1
Zonas de seguridad
Una zona de seguridad es un conjunto de uno o varios segmentos de red, lo que
requiere regular 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, dependiendo su número exacto 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 4.
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). A
efectos prácticos, se considera que una zona sin interfaces asociadas y sin
entradas de libreta de direcciones no contiene segmentos de red.
Si actualiza una antigua versión de ScreenOS, todas las configuraciones de las

zonas correspondientes 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.
Figura 4: Zonas de seguridad predefinidas
Una red configurada con cinco zonas

de seguridad, tres zonas Finance
predeterminadas (Trust, Untrust, DMZ)
y dos zonas definidas por el usuario. Untrust
(Finance, Eng).
El tráfico pasa de una zona de Trust

seguridad a otra únicamente si Motor de
directivas Dispositivo
lo permite una directiva. 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 pase de una zona a otra, debe asociar una interfaz a la
zona y, en el caso de una interfaz en modo de ruta o en modo NAT (consulte
“Modos de las interfaces” en la página 81), asignar 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 45.
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. En el dispositivo NetScreen-500, por ejemplo, una interfaz
física se identifica por la posición de un módulo de interfaz y un puerto Ethernet en
ese módulo. Por ejemplo, la interfaz ethernet1/2 designa el módulo de interfaz
situado en el primer bastidor (ethernet1/2) y en el segundo puerto (ethernet1/2).
Consulte la Figura 5.
Figura 5: Asignaciones de las interfaces físicas
1/1 1/2 3/1 3/2
2/1 2/2 4/1 4/2
NOTA: Para conocer la convención de nomenclatura de un dispositivo de seguridad

determinado, consulte el manual de usuario de dicho dispositivo.
Interfaces de zonas de seguridad 3

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.1Q. El dispositivo de
seguridad dirige el tráfico desde o hacia una zona con 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.
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. Consulte la
Figura 6.
Figura 6: Asignaciones de subinterfaces
3/1.1 3/2.1
1/1.1 1/2.1 3/1.2 3/2.2
1/1.2 1/2.2 3/1.3 3/2.3
1/1 1/2 3/1 3/2
2/1 2/2 4/1 4/2

2/1.1 2/2.1 4/1.1 4/2.1
2/1.2 2/2.2 4/1.2 4/2.2
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
4 Enrutadores virtuales
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
encubierta de rutas de untrust-vr. Consulte la Figura 7 en la página 5.
Figura 7: Zonas de seguridad del enrutador virtual
Dominio de enrutamiento trust-vr Dominio de enrutamiento 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 reenvía automáticamente entre las zonas que se encuentran en distintos VR,
incluso aunque existan directivas que permitan el tráfico. Si desea intercambiar
tráfico de datos 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 siguiente
salto ("next-hop"). Para más información sobre el uso de enrutadores virtuales,
consulte el Volumen 7: Enrutamiento.
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 de

datos 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 y cuándo. 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 programado.
Consulte la Figura 8 en la página 6.
Directivas 5
NOTA: Ciertos 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 procedente de la zona Untrust y dirigido a la zona Trust.
Figura 8: Directiva predeterminada
Acceso a Internet permisivo: cualquier servicio desde Acceso a Internet restrictivo: servicio SMTP desde un servidor de
cualquier punto de la zona Trust hacia cualquier punto correo en la zona Trust a un servidor de correo en la zona Untrust
de la zona Untrust en cualquier momento de las 7:00 a las 23:00.
Zona Zona
Untrust Untrust
Zona Zona
Trust Trust
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 167). 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.
6 Directivas
Figura 9: Arquitectura de las directivas
Finance
Untrust
Motor de
Trust directivas
Eng DMZ Nota: El icono del castillo

representa una interfaz en una
zona de seguridad.
Reenvío de rutas
NOTA: Para obtener más información sobre las directivas, consulte “Directivas” en la
página 163.
Si configura el enrutamiento multicast en un dispositivo de seguridad, puede 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 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 sobre directivas multicast, consulte “Directivas multicast” en la
página 7-143).

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.
Redes privadas virtuales 7

VPN basada en directivas: mediante una consulta de 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 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 10.
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-to-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 (por ejemplo, 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-to-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 10: Tráfico VPN
Motor de Interfaz
directivas de túnel Túnel VPN Zona de destino
Zona de origen
Tabla de
enrutamiento
tunnel.1 vpn-to-SF
Paquete enviado Llega el paquete
Llegados a este punto, el túnel está listo para el tráfico dirigido a SF. Ahora puede
crear entradas 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 especificado, como “Trust LAN”, y hacia un destino
especificado, como “SF LAN”. Consulte la Figura 11 en la página 9.
8 Redes privadas virtuales

Figura 11: Tráfico VPN procedente de la zona de seguridad Untrust
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á
asociada al túnel VPN “vpn-to-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
10.2.2.0/24
Para llegar a utilice
Zona Untrust
1.1.1.0/24 eth1/2
Interfaz de salida
10.2.2.0/24 tunnel.1 eth1/2, 1.1.1.1/24
0.0.0.0/0 1.1.1.250
Tunnel.1
de la
interfaz
Dispositivo local Puerta de enlace Túnel VPN

predeterminada: vpn-to-SF
1.1.1.250
Dominio de enrutamiento
trust-vr
Zona Trust
Para llegar a utilice eth3/2–10.1.1.1/24
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.
Redes privadas virtuales 9

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 rutas virtuales.
La Figura 12 en la página 10 presenta una vista conceptual de cómo ScreenOS
integra estos componentes en los niveles raíz y de sistema virtual.
Figura 12: Arquitectura de sistemas virtuales
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
vsys1
Subinterfaz
dedicada para vsys2-vr
vsys2 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.
10 Sistemas virtuales
Secuencia de flujo de paquetes

En ScreenOS, la secuencia de flujo de un paquete entrante ocurre según se muestra
en la Figura 13.
Figura 13: Flujo de paquetes a través de las zonas de seguridad
Paquete
entrante
Filtro Consulta MIP/VIP Consulta Consulta NAT-Dst y Crear Realizar

SCREEN sesiones IP de host rutas directivas luego/o NAT-Src sesión operación
Interfaz Si el paquete no coincide Tabla de reenvíos Lista de directivas Tabla de sesiones

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

de origen a la que está asociada.
La determinación de la zona de origen se basa en los criterios siguientes:
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.
Secuencia de flujo de paquetes 11

2. Si las opciones de SCREEN están habilitadas 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 sesión 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 del primer paquete (First Packet
Processing), un procedimiento que implica los pasos del 4 a 9 que se presentan
a continuación.
Si el paquete coincide con una sesión existente, el dispositivo de seguridad

ejecuta el procesamiento rápido (Fast Processing) y utiliza la información
disponible en la entrada de sesiones existente para procesar el paquete. El
procesamiento rápido omite los pasos del 4 al 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. La operación de consulta de la tabla de rutas averigua qué interfaz conduce a la

dirección de destino. Al hacerlo, el módulo de interfaz identifica la zona de
destino a la que está asociada esa interfaz.
La determinación de la zona de destino se basa en los siguientes criterios:
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 intrazonal

está inhabilitado para esa zona, el dispositivo de seguridad omite los pasos
6 y 7 y crea una sesión (paso 8). Si el bloqueo intrazonal está activado, el
dispositivo de seguridad descarta el paquete.
12 Secuencia de flujo de paquetes

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 lo que debe hacer el

cortafuegos de ScreenOS con el paquete:
Si la acción es permit, el dispositivo de seguridad decide remitir el paquete

a su destino.
Si la acción es deny, el dispositivo de seguridad determina descartar el

paquete.
Si la acción es reject, el dispositivo de seguridad decide 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 decide remitir el paquete

al módulo VPN, que encapsula el paquete y lo transmite utilizando los
ajustes del túnel VPN especificado.
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 del 1 al 7.
Para procesar los paquetes subsiguientes de la misma sesión, el dispositivo de

seguridad utiliza la información mantenida 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.

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. Si desea
información sobre esta segunda parte, en la que las interfaces de cada zona están
ya establecidas, consulte “Ejemplo: (Parte 2) Interfaces para seis zonas” en la
página 16. Aquí se configuran las seis zonas siguientes de una empresa:
Finance
Trust
Eng
Mail
Untrust
DMZ
Las zonas Trust, Untrust y DMZ están preconfiguradas. 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. También se deben transferir los enlaces de los
enrutadores virtuales de las zonas DMZ y Untrust de trust-vr a untrust-vr . Consulte
la Figura 14 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 14: Enlaces de enrutador de zona a virtual
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

Zone Name: Mail

Virtual Router Name: untrust-vr
Network > Zones > Edit (para Untrust): Seleccione untrust-vr en la lista
desplegable Virtual Router Name, después haga clic en OK.
Network > Zones > Edit (para DMZ): Seleccione untrust-vr en la lista
desplegable Virtual Router Name, después haga clic en OK.
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 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 14. 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 15.
Figura 15: 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 1/1 1/2 3/1 3/2 Untrust

10.1.1.1/24 2/1 2/2 4/1 4/2 1.1.1.1/24
eth3/2 eth1/2
Eng DMZ
10.1.3.1/24 1.2.2.1/24
eth3/1 eth2/2
WebUI
1. Interfaz ethernet3/2
Network > Interfaces > Edit (para ethernet3/2): Introduzca los siguientes
datos y haga clic en OK:
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:
Interface Name: ethernet1/1.2

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 seis zonas” en la página 16. Si desea ver la parte
siguiente, en la que se establecen las directivas, consulte “Ejemplo: (Parte 4)
Directivas” en la página 20. 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 16 en la página 19.

Figura 16: Dominios de enrutamiento
dominio de enrutamiento dominio 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 > Routing Entries > 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 > Routing Entries > 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 en la página 20 (con excepción de lo que se indica).

Tabla 1: Tabla de rutas para trust-vr
Para llegar a: Utilizar interfaz: Utilizar puerta de enlace/Vrouter: Creado 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
seguridad
10.1.2.0/24 eth3/2.1 0.0.0.0 Dispositivo de
seguridad
Tabla 2: Tabla de rutas para untrust-vr
Para llegar a: Utilizar interfaz: Utilizar puerta de enlace/Vrouter: Creado por:

seguridad
seguridad
1.4.4.0/24 eth1/1.2 0.0.0.0 Dispositivo de
seguridad
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 17.
Figura 17: 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 se 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
Objects > Services > Groups > New: Introduzca los siguientes datos 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

columna “Available Members” a la columna “Group Members”.
Objects > Services > Groups > New: Introduzca los siguientes datos y haga
clic en OK:
Group Name: HTTP-FTPGet
Seleccione HTTP y utilice el botón << para mover el servicio de la

Seleccione FTP-Get y utilice el botón << para mover el servicio de la

2. Directivas
Policies > (From: Finance, To: Mail) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Any
Destination Address:
Service: Mail-Pop3
Action: Permit
Policies > (From: Trust, To: Mail) New: Introduzca los siguientes datos y haga
clic en OK:
Source Address:
Service: Mail-Pop3
Action: Permit

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

Policies > (From: Eng, To: DMZ) New: Introduzca los siguientes datos y haga
clic en OK:
Source Address:
Action: Permit
Policies > (From: Eng, To: DMZ) New: Introduzca los siguientes datos y haga
clic en OK:
Source Address:
Service: FTP-Put
Action: Permit
Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Action: Permit
CLI
1. Grupos de servicios
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, poniendo un especial énfasis
en la zona de seguridad, y describe los modos de puerto. El capítulo incluye las
“Visualizar las zonas preconfiguradas” en la página 26
“Zonas de seguridad” en la página 28
“Zona Global” en la página 28
“Opciones SCREEN” en la página 28
“Enlazar una interfaz de túnel a una zona de túnel” en la página 28
“Configurar zonas de seguridad y zonas de túnel” en la página 30
“Crear una zona” en la página 30
“Modificar una zona” en la página 31
“Eliminar una zona” en la página 32
“Zonas de función” en la página 32
“Zona Null” en la página 32
“Zona MGT” en la página 32
“Zona HA” en la página 33
“Zona de registro propio (Self)” en la página 33
“Zona VLAN” en la página 33
25
“Modos de puerto” en la página 33
“Modo Trust-Untrust” en la página 34
“Modo Home-Work” en la página 35
“Modo Dual Untrust” en la página 36
“Modo combinado (Combined)” en la página 37
“Modo Trust/Untrust/DMZ (extendido)” en la página 38
“Modo DMZ/Dual Untrust” en la página 38
“Modo Dual DMZ” en la página 39
“Ajustar los modos de puertos” en la página 40
“Zonas en los modos “Home-Work” y “Combined Port”” en la página 41
Visualizar las zonas preconfiguradas

La primera vez que se inicia un dispositivo de seguridad pueden 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 18.
Para visualizar estas zonas utilizando la CLI, utilice el comando get zone. Consulte la
Figura 19 en la página 27.
Figura 18: Página Network > Zones en la WebUI
26 Visualizar las zonas preconfiguradas

Capítulo 2: Zonas
La Figura 19 muestra el resultado del comando get zone.
Figura 19: Resultado del comando get zone
ns500> get zone
Total of 13 zones in vsys root

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
Los números de zona 7 a 9 y 15 están reservados para existentes se asocian a la zona Untrust-Tun).
uso futuro.
Las zonas preconfiguradas que se muestran en la Figura 18 y en la Figura 19 se

pueden agrupar en tres tipos diferentes:
Zonas de seguridad: Untrust, Trust, DMZ, Global, V1-Untrust, V1-Trust, V1-DMZ
Zona de túnel: Untrust-Tun
Zonas de función: Null, Self, MGT, HA, VLAN
Visualizar las zonas preconfiguradas 27

Zonas de seguridad
En un solo dispositivo de seguridad se pueden configurar varias zonas de seguridad,
dividiendo la red en segmentos a los que se pueden 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 se pueden definir muchas zonas de
seguridad, lo que refina aún más la granularidad del diseño de seguridad de la red,
evitando la necesidad de distribuir múltiples dispositivos de seguridad para
conseguir el mismo fin.
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 MIP, VIP 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 166).
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 de Juniper Networks asegura una red inspeccionando, y luego
permitiendo o denegando, todo intento de conexión que necesite pasar de una
zona de seguridad a otra. Por cada zona de seguridad y zona MGT, puede habilitar
un conjunto de opciones SCREEN predefinidas que detecten y bloqueen los
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: Mecanismos de detección y defensa de ataques.
Enlazar una interfaz de túnel a una zona de túnel

Una zona del 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”. Las zonas de seguridad que actúan como el
“padre”, que también pueden imaginarse como zonas portadoras, proporcionan
protección de cortafuegos al tráfico encapsulado. La zona del túnel proporciona el
28 Zonas de seguridad
Capítulo 2: Zonas
encapsulado y desencapsulado de paquetes, y también puede proporcionar

servicios NAT basados en directivas, ya que admiten 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 del 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.
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 20 en la página 29.
Figura 20: 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 y una máscara
de red, admite NAT basada en
directivas para el tráfico VPN
pre-encapsulado y
post-desencapsulado.
El tráfico saliente penetra 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.
Enlazar una interfaz de túnel a una zona de túnel 29

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

Netmask: 255.255.255.255
Host IP Address: 10.1.1.5
Host Virtual Router Name: trust-vr
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
Configurar zonas de seguridad y zonas de túnel

El proceso para la creación, modificación y eliminación de zonas de seguridad y
zonas del túnel de la capa 3 o capa 2 son bastante similares.
NOTA: No se pueden eliminar zonas de seguridad predefinidas ni la zona de túnel

predefinida, aunque sí se pueden editar.
Crear una zona

Para crear zonas de seguridad de capa 3 ("Layer 3") o capa 2 ("Layer 2") o una zona
de túnel, utilice WebUI o 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.
30 Configurar zonas de seguridad y zonas de túnel

Capítulo 2: Zonas
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 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”.
CLI
set zone name zone [ l2 vlan_id_num | tunnel sec_zone ]
set zone zone block
set zone zone vrouter name_str
NOTA: Al crear una zona de seguridad de capa 2 ("Layer 2"), el número de identificación
VLAN-ID debe ser 1 (para el VLAN1).
Modificar 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
crearla de nuevo con los cambios. Puede cambiar la opción de bloqueo intrazonal 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 de una zona, primero debe eliminar
todas las interfaces asociadas a ella.
WebUI
1. Modificar el 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,
después haga clic en OK.
Configurar zonas de seguridad y zonas de túnel 31

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 activar, seleccione la casilla de verificación.

Para desactivar la opción, desactive la casilla.
CLI
1. Modificar el nombre de una zona
unset zone zona
set zone name zona [ l2 vlan_id_num | tunnel sec_zone ]
2. Cambiar la opción de bloqueo intrazonal o el enrutador virtual
{ set | unset } zone zone block
set zone zone vrouter name_str
Eliminar una zona

Para eliminar una zona de seguridad o zona de túnel, ejecute 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 zone
NOTA: Antes de poder eliminar una zona, primero debe desasociar todas las interfaces
asociadas a ella. Para desasociar una interfaz de una zona, consulte “Asociar una
interfaz a una zona de seguridad” en la página 54.
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 subsección siguiente.
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 de 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 del cortafuegos, consulte el Volumen 4: Mecanismos
de detección y defensa de ataques.
32 Zonas de función
Capítulo 2: Zonas
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 es
configurable.
Zona de registro propio (Self)

Esta zona contiene la interfaz para las conexiones de administración remotas.
Cuando usted se conecta al dispositivo de seguridad a través de HTTP, SCS o Telnet,
se conecta a la zona de registro propio.
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 del cortafuegos en esta zona para proteger la interfaz
VLAN1 de diversos ataques.
Modos de puerto
Puede seleccionar un modo de puerto para ciertos dispositivos de seguridad de
Juniper Networks. El modo de puerto establece automáticamente diversas
asociaciones de puertos, interfaces y zonas para el dispositivo.
En el contexto de modos de puertos, puerto se refiere a una interfaz física en la

parte posterior del dispositivo. Para hacer referencia a un puerto se utiliza su
etiqueta:
Untrusted
1-4
Console
Modem
El término interfaz se refiere a una interfaz lógica que se puede configurar con
WebUI o CLI. Cada puerto se puede asociar a una sola interfaz, pero a cada interfaz
se le pueden asociar múltiples puertos.
ADVERTENCIA: Cambiar el modo de puerto elimina cualquier configuración

existente en el dispositivo de seguridad y requiere reiniciar el sistema.
La Tabla 3 muestra los modos disponibles en los dos dispositivos de seguridad. Para
visualizar las asociaciones de interfaz inalámbrica a zona, consulte “Red de área
local inalámbrica” en la página 12 -33.
Modos de puerto 33
Tabla 3: Disponibilidad del modo de puerto
Modo de puerto Disponibles en dispositivos

Trust-Untrust (Predeterminado) NetScreen-5GT, NetScreen-5GT ADSL,
NetScreen-5GT Wireless, NetScreen-5GT Wireless
ADSL y NetScreen-5XT
Home-Work NetScreen-5GT, NetScreen-5GT ADSL,
NetScreen-5GT Wireless, NetScreen-5GT Wireless
ADSL y NetScreen-5XT
Dual Untrust NetScreen-5GT, NetScreen-5GT Wireless y
NetScreen-5XT
Combined NetScreen-5GT, NetScreen-5GT Wireless y
NetScreen-5XT
Trust/Untrust/DMZ (extendido) NetScreen-5GT, NetScreen-5GT ADSL,
(Debe contar con la clave de NetScreen-5GT Wireless y NetScreen-5GT Wireless
licencia extendida) ADSL
Modo DMZ/Dual Untrust NetScreen-5GT y NetScreen-5GT Wireless
(Debe contar con la clave de
licencia extendida)
Dual DMZ NetScreen-5GT y NetScreen-5GT Wireless
(Debe contar con la clave de
licencia extendida)
Modo Trust-Untrust
El modo Trust-Untrust es el modo de puerto predeterminado. Consulte la Figura 21.
Figura 21: Enlaces de interfaz a zona del modo de puerto Trust-Untrust
Interfaces Untrust Interfaz Trust
Zona Trust
Zona Untrust
34 Modos de puerto
Capítulo 2: Zonas
La Tabla 4 proporciona los enlaces de interfaz a zona del modo Trust-Untrust.
Tabla 4: Enlaces Trust-Untrust
Puerto Interfaz Zona

Untrusted Untrust Untrust
1 Trust Trust
2 Trust Trust
3 Trust Trust
4 Trust Trust
Modem serial Null
Modo Home-Work
El modo Home-Work asocia interfaces a la zona de seguridad Untrust y a las zonas
de seguridad Home y Work. Las zonas “Work” y “Home” permiten segregar
usuarios y recursos en cada zona. En este modo, las directivas predeterminadas
permiten el flujo de tráfico y conexiones entre las zonas Work y Home pero no
permiten tráfico de la zona Home a la zona Work. Es posible personalizar las
directivas que aplican al tráfico transmitido de la zona Home a la zona Work.
Consulte la Figura 22. De forma predeterminada, no hay ninguna restricción para el
tráfico de la zona Home a la zona Untrust. La zona Home responde a los comandos
ping.
Figura 22: Enlaces de interfaz a zona del modo de puerto Home-Work
ethernet1
ethernet3
ethernet2
Zona Untrust Zona Home Zona Work
La Tabla 5 proporciona los enlaces de interfaz a zona del modo Home-Work.
Tabla 5: Enlaces Home-Work

1 ethernet1 Work
2 ethernet1 Work
3 ethernet2 Home
4 ethernet2 Home
Modem ethernet3 Untrust
Consulte “Zonas en los modos “Home-Work” y “Combined Port”” en la página 41

para obtener información adicional sobre cómo configurar y utilizar el modo
Home-Work.
Modos de puerto 35
Modo Dual Untrust

El modo Dual Untrust asocia dos interfaces a la zona de seguridad Untrust, que
permite que el tráfico se cruce simultáneamente a través de la red interna. Consulte
la Figura 23.
Figura 23: Enlaces de interfaz a zona del modo de puerto Dual Untrust
ethernet3 ethernet2 ethernet1
Zona Untrust Zona Trust
La Tabla 6 proporciona los enlaces de interfaz a zona del modo Dual Untrust.
Tabla 6: Enlaces del Modo Dual Untrust

Untrusted ethernet3 Untrust
1 ethernet1 Trust
2 ethernet1 Trust
3 ethernet1 Trust
4 ethernet2 Untrust
Modem N/D N/D
NOTA: La interfaz serie no está disponible en el modo de puerto Dual Untrust.
Para habilitar la conmutación por fallo, en lugar de entregar tráfico

simultáneamente, utilice el comando set failover enable.
Para obtener información adicional sobre cómo configurar y utilizar el modo Dual
Untrust, consulte el Volumen 11: Alta disponibilidad.
36 Modos de puerto
Capítulo 2: Zonas
Modo combinado (Combined)

El modo combinado asocia una interfaz principal y una de respaldo a Internet y
permite la segregación de usuarios y recursos en las zonas Work y Home. Consulte
la Figura 24.
Figura 24: Enlaces de interfaz a zona del modo de puerto combinado
ethernet2
ethernet4 ethernet3
ethernet1
NOTA: Para el dispositivo NetScreen-5XT, el modo combinado únicamente funciona en la

plataforma NetScreen-5XT Elite (usuarios sin restricción). El modo combinado
(“Combined”) no se puede configurar con el asistente de configuración inicial
(“Initial Configuration Wizard”). Este modo sólo se puede configurar mediante
WebUI o CLI.
La Tabla 7 proporciona los enlaces de interfaz a zona del modo combinado.
Tabla 7: Enlaces combinados

1 ethernet1 Work
2 ethernet2 Home
3 ethernet2 Home
4 ethernet3 Untrust
Modem N/D N/D
NOTA: La interfaz serie no está disponible en el modo de puerto Combined.
Para obtener más información sobre cómo configurar y utilizar el modo Combined,
consulte el Volumen 11: Alta disponibilidad y “Zonas en los modos “Home-Work” y
“Combined Port”” en la página 41.
Modos de puerto 37
Modo Trust/Untrust/DMZ (extendido)

El modo Trust/Untrust/DMZ (extendido) asocia interfaces a las zonas de seguridad
Untrust, Trust y DMZ, permitiendo segregar de la red interna los servidores internos
de web, correo electrónico y otros servidores de aplicaciones. Consulte la Figura 25.
Figura 25: Enlaces de interfaz de modo de puerto extendido a zona
Serie Untrust ethernet2 ethernet1
Zona Untrust Zona DMZ Zona Trust
La Tabla 8 proporciona los enlaces de interfaz de modo extendido a zona.
Tabla 8: Enlaces extendidos

1 ethernet1 Trust
2 ethernet1 Trust
3 ethernet2 DMZ
4 ethernet2 DMZ
Modem serie Untrust
Modo DMZ/Dual Untrust

El modo DMZ/Dual Untrust asocia interfaces a las zonas de seguridad Untrust, Trust
y DMZ, permitiendo entregar tráfico simultáneamente desde la red interna.
Figura 26: Enlaces de interfaz a zona del modo de puerto DMZ/Dual Untrust
ethernet4 ethernet3 ethernet2 ethernet1
Zona Untrust Zona DMZ Zona Trust
38 Modos de puerto
Capítulo 2: Zonas
NOTA: El modo DMZ/Dual Untrust únicamente funciona en las plataformas

NetScreen-5GT y NetScreen-5GT Wireless con una clave de licencia extendida.
La Tabla 9 proporciona los enlaces de interfaz a zona del modo DMZ/Dual Untrust.
Tabla 9: Enlaces DMZ/Dual Untrust

1 ethernet1 Trust
2 ethernet1 Trust
3 ethernet2 DMZ
4 ethernet3 Untrust
Modem N/D N/D
NOTA: La interfaz serie no está disponible en el modo de puerto DMZ/Dual Untrust. Para
habilitar la conmutación por fallo, en lugar de entregar tráfico simultáneamente,
utilice el comando set failover enable.
Modo Dual DMZ

El modo Dual DMZ asocia interfaces a las zonas de seguridad Untrust, Trust, DMZ y
DMZ2, permitiendo entregar tráfico simultáneamente desde la red interna.
Figura 27: Enlaces de interfaz a zona del modo de puerto Dual DMZ
ethernet1
ethernet4
Zona Untrust Zona DMZ2 Zona DMZ Zona Trust
ethernet3 ethernet2
NOTA: El modo Dual DMZ únicamente funciona en las plataformas NetScreen-5GT y

NetScreen-5GT Wireless con una clave de licencia extendida.
Modos de puerto 39
Tabla 10 proporciona los enlaces de interfaz a zona del modo Dual DMZ.
Tabla 10: Enlaces Dual DMZ

1 ethernet1 Trust
2 ethernet2 DMZ
3 ethernet3 DMZ2
4 ethernet4 Untrust
Modem N/D N/D
Ajustar los modos de puertos

El ajuste del modo de puerto del dispositivo de seguridad se puede modificar
mediante WebUI o CLI. Antes de establecer el modo de puerto, observe lo siguiente:
Al cambiar el modo de puerto, se elimina cualquier configuración existente en

el dispositivo y es necesario reiniciar el sistema.
Ejecutar el comando CLI unset all no afecta al ajuste del modo de puerto del
dispositivo. Por ejemplo, si desea cambiar el modo de puerto de Combined al
modo predeterminado Trust-Untrust, ejecutar el comando unset all eliminará
la configuración existente, pero no pondrá el dispositivo en el modo
Trust-Untrust.
Ejemplo: Modo de puerto Home-Work

En este ejemplo establecerá el modo de puerto del dispositivo NetScreen-5XT en
Home-Work.
WebUI
Configuration > Port Mode > Port Mode: Seleccione Home-Work en la lista
desplegable y haga clic en Apply.
Cuando aparezca la pregunta siguiente, haga clic en OK:
Operational mode change will erase current configuration and reset the
device, continue?
CLI
exec port-mode home-work
Cuando aparezca la pregunta siguiente, teclee y (respuesta afirmativa):
Change port mode from <trust-untrust> to <home-work> will erase system

configuration and reboot box
Are you sure y/[n] ?
40 Ajustar los modos de puertos

Capítulo 2: Zonas
Para ver el modo de puerto actual en el dispositivo, ejecute cualquiera de los

WebUI
Configuration > Port Mode
CLI
get system
Zonas en los modos “Home-Work” y “Combined Port”

Pueden presentarse conflictos de seguridad cuando el teletrabajo de los empleados
y las redes domésticas se hagan más comunes. Una red doméstica utilizada tanto
por teletrabajadores como por miembros de sus familias puede crear un peligroso
agujero de seguridad para una red corporativa, por el que se introducen amenazas
(como virus o gusanos) y se permite el acceso a los recursos corporativos (como
servidores y redes) a terceros ajenos a la empresa.
Los modos de puertos Home-Work y Combined asocian las interfaces de ScreenOS

a las zonas especiales Work y Home. Esto permite la segregación de usuarios y
recursos corporativos de los domésticos, permitiendo al mismo tiempo que los
usuarios de las zonas Home y Work puedan acceder a la zona Untrust. Consulte la
Figura 28: Enlaces de zona de los modos de puerto combinados y Home-Work
Home-Work
Combined
El modo de puerto Home-Work también asocia el puerto Modem a una interfaz

serie, que se puede asociar como interfaz de respaldo a la zona de seguridad
Untrust. Para obtener más información sobre cómo utilizar la interfaz serie como
interfaz de respaldo a la zona de seguridad Untrust, consulte el Volumen 11:
Alta disponibilidad.
Zonas en los modos “Home-Work” y “Combined Port” 41

El modo de puertos combinados (“Combined Port”) también asocia el puerto

Ethernet 4 a la zona Untrust para respaldar el puerto de seguridad Untrust. La
interfaz de respaldo solamente se utiliza cuando se produce algún fallo en la
interfaz principal a la zona Untrust. Para obtener más información sobre cómo
utilizar la interfaz ethernet3 como interfaz de respaldo a la zona de seguridad
Untrust, consulte el Volumen 11: Alta disponibilidad.
De forma predeterminada, el dispositivo NetScreen-5XT actúa como un servidor del

protocolo de configuración dinámica de hosts (“Dynamic Host Configuration
Protocol” o “DHCP”), asignando direcciones IP dinámicas a los clientes DHCP en la
zona Work. (Para obtener más información, consulte “Asignar un dispositivo de
seguridad como agente de retransmisión de DHCP” en la página 237).
Puede configurar el dispositivo utilizando una conexión de Telnet o WebUI

solamente desde la zona Work. El dispositivo no se puede configurar desde la zona
Home. No se puede utilizar ningún servicio de administración, incluyendo el
comando “ping”, en la interfaz de la zona Home. La dirección IP predeterminada de
la interfaz de la zona Work (ethernet1) es 192.168.1.1/24.
Las directivas predeterminadas en los modos de puertos del Home-Work y

Combined proporcionan el siguiente control del tráfico entre zonas:
Permitir todo el tráfico desde la zona Work a la zona Untrust.
Permitir todo el tráfico desde la zona Home a la zona Untrust.
Permitir todo el tráfico desde la zona Work a la zona Home.
Bloquear todo el tráfico desde la zona Home a la zona Work (esta directiva no
se puede eliminar)
Puede crear nuevas directivas para el tráfico de la zona Work a la zona Untrust, de
la zona Home a la zona Untrust y de la zona Work a la zona Home. También puede
eliminar las directivas predeterminadas que permiten todo el tráfico desde la zona
Work a la zona Untrust, desde la zona Home a la zona Untrust y desde la zona Work
a la zona Home.
Ejemplo: Zonas Home-Work

En este ejemplo realizará el siguiente procedimiento:
1. Configurar el modo de puerto home-work.
2. Configurar una directiva que permita únicamente el tráfico FTP de la zona

Home a la zona Untrust.
3. Borrar la directiva predeterminada que permite todo el tráfico desde la zona

Home a la zona Untrust.
4. Desactivar la directiva ID 2, que permite el tráfico de cualquier dirección de

origen a cualquier dirección de destino para cualquier servicio.
ADVERTENCIA: Cambiar el modo de puerto elimina cualquier configuración

existente en el dispositivo y requiere reiniciar el sistema.
42 Zonas en los modos “Home-Work” y “Combined Port”

Capítulo 2: Zonas
WebUI
Configuration > Port Mode > Port Mode: Seleccione Home-Work en la lista
desplegable y haga clic en Apply.
Cuando aparezca la pregunta siguiente, haga clic en OK:
Operational mode change will erase current configuration and reset the
device, continue?
En este momento, el sistema se reinicia. Inicie una sesión, después ejecute el

siguiente procedimiento:
Policies > (From: Home, To: Untrust) > New: Introduzca los siguientes datos y
haga clic en OK.
Source Address:
Service: FTP
Action: Permit
Policies: En la lista de directivas “From Home to Untrust”, haga clic en Remove

en la columna “Configure” para la directiva con la ID 2.
CLI
exec port-mode home-work
Cuando aparezca la pregunta siguiente, teclee y (respuesta afirmativa):
Change port mode from trust-untrust to home-work will erase system

configuration and reboot box
Are you sure y/[n] ?
set policy from home to untrust any any ftp permit

unset policy 2
save
Zonas en los modos “Home-Work” y “Combined Port” 43

44 Zonas en los modos “Home-Work” y “Combined Port”

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 contiene las siguientes secciones:
“Tipos de interfaces” en esta página
“Visualizar interfaces” en la página 52
“Configurar interfaces de la zona de seguridad” en la página 53
“Crear una dirección IP secundaria” en la página 59
“Interfaces de bucle invertido (loopback)” en la página 60
“Cambios de estado de la interfaz” en la página 62
Tipos de interfaces
En esta sección se describen la zona de seguridad, la zona de función y las
interfaces de túnel. Para obtener más información sobre cómo visualizar una tabla
de todas estas interfaces, consulte “Visualizar interfaces” en la página 52.
Interfaces de la zona de seguridad

La finalidad de las interfaces y subinterfaces físicas es proporcionar una abertura
por la que el tráfico de red pueda pasar de una zona a otra.
Interfaces físicas
Cada puerto de su dispositivo de seguridad representa una interfaz física, estando el
nombre de la interfaz predefinido. El nombre de una interfaz física se compone del
tipo de medio, número de la ranura (en algunos dispositivos de seguridad) y
número de puerto, por ejemplo, ethernet3/2 o ethernet2 (consulte también
Tipos de interfaces 45
“Interfaces de zonas de seguridad” en la página 3). 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, ningún tráfico puede entrar ni salir
de la zona.
En los dispositivos de seguridad que admiten cambios en las asociaciones

interfaz-a-zona, tres de las interfaces físicas Ethernet están pre-asociadas a zonas de
seguridad específicas de capa 2: V1-Trust, V1-Untrust y V1-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 “Zonas de seguridad” en la
página 2).
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
ethernet2.1. (Consulte “Interfaces de zonas de seguridad” en la página 3).
Una subinterfaz se puede asociar a cualquier zona. 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 “Asociar una interfaz a una zona de seguridad” en la
página 54).
Interfaces agregadas
Los dispositivos de la serie NetScreen-5000 admiten interfaces agregadas. Una
interfaz agregada es la acumulación de dos o más interfaces físicas, entre las que se
reparte 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” 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” en la página 11-43.
46 Tipos de interfaces
Capítulo 3: Interfaces
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 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 alguna conmutación por 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 VSI y cómo funcionan con VSD en un clúster
HA, consulte 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. Separando 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 cómo configurar el 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. Con dispositivos de seguridad equipados con interfaces
especializadas para HA (alta disponibilidad) se pueden asociar dos dispositivos para
formar un grupo redundante o clúster. En un grupo redundante, una unidad actúa
como la principal, realizando las funciones de cortafuegos de la red, VPN y
asignación de tráfico, mientras que la otra unidad actúa como respaldo, esperando
a asumir el control de las funciones de cortafuegos en caso de fallar la unidad
principal. 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 dispositivos de seguridad carentes de una interfaz de HA especializada, una
interfaz de HA virtual proporciona la misma funcionalidad. Al no haber ningún
puerto físico dedicado exclusivamente al tráfico de HA, la interfaz de HA virtual se
debe asociar 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 (consulte “Asociar una interfaz a una zona de
seguridad” en la página 54).
NOTA: Para obtener más información sobre interfaces de HA, consulte “Interfaces de alta
disponibilidad dobles” en la página 11-28.
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.
Un túnel VPN basado en rutas debe asociarse a una interfaz de túnel para que el
dispositivo de seguridad pueda enrutar 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 loopback asociada a la misma zona. Por ejemplo, se pueden asociar todas
las interfaces de túnel no numeradas a una zona 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 la Figura 29 en la página 49.
Figura 29: Asociaciones de interfaz de túnel sin numerar
set vrouter name vpn-vr

set zone name vpn vrouter vpn-vr
set interface loopback.1 zone vpn ethernet1 ethernet3
set interface loopback.1 ip 172.16.1.1/24 10.1.1.1/24 1.1.1.1/24
set interface tunnel.1 zone vpn Zona Trust trust-vr Zona Untrust
set interface tunnel.1 ip unnumbered loopback.1 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 ethernet3
gateway 1.1.1.250
set vrouter vpn-vr route 10.2.2.5 interface tunnel.1
loopback.1
set policy from trust to vpn scr-1 dst-1 any permit tunnel.1 sin 172.16.1.1/24 dst-1
numerar 10.2.2.5
Zona VPN
El dispositivo de seguridad envía el tráfico destinado a 10.2.2.5/32 del
vpn-vr
trust-vr al vpn-vr. Si tunnel.1 se inhabilita por cualquier causa, el
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 ethernet3.
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 de
seguridad en VPN basadas en rutas” en la página 5-72).
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 30 en la página 50.
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 30: Enlaces de interfaz de túnel a zona
Interfaces Interfaces de
de túnel zona de seguridad
Cuando una interfaz de túnel se encuentra en una zona de seguridad, debe asociarse un túnel
Túnel VPN VPN a la interfaz de túnel. Esto permite crear una configuración de VPN basada en rutas. La
Numerada o interfaz de túnel puede estar numerada o no numerada. Si no está numerada, la interfaz de túnel
no numerada Zona toma prestada la dirección IP de la interfaz predeterminada de la zona de seguridad en la que fue
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 de VPN a través de la interfaz de túnel, pero ningún otro tipo de
tráfico.
Cuando una interfaz de túnel está asociada a una zona de túnel, la interfaz de túnel debe tener
Túnel Túnel VPN
Numerada una dirección IP y una máscara de red. Esto permite definir conjuntos de DIP y direcciones MIP
Zona en esa interfaz. Si usted asocia un túnel VPN a una zona de túnel, no puede asociarlo también a
una 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 “Puntos VPN
con direcciones superpuestas” en la página 5-141). Puede crear una interfaz de
túnel con una dirección IP y una máscara de red ya sea 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-159.
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 el encapsulado genérico de enrutamiento en
interfaces de túnel” en la página 7-141.
Eliminar 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
Policies (From: Trust, To: Untrust): Haga clic en Remove para la directiva con ID
10.
2. Eliminar el conjunto de 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

VPN > 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 conjunto de 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
Visualizar 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 a 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 (“Layer 2”), capa 3 (“Layer
3”), túnel (“tunnel”), redundante (“redundant”), agregada (“aggregate”), VSI.
Link: Este campo identifica si la interfaz está activa (“up”) o inactiva (“down”).
Configure: Este campo permite modificar o eliminar interfaces.
Figura 31: Tabla de interfaces de WebUI
52 Visualizar interfaces
Figura 32: Tabla de interfaces de CLI
Configurar 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 separar una interfaz a una zona de seguridad
Asignar una dirección a una interfaz de la zona de seguridad de capa 3 (“Layer

3” o “L3”)
Modificar interfaces y subinterfaces físicas
Crear subinterfaces
Eliminar subinterfaces
NOTA: Para obtener más información sobre cómo establecer el ancho de banda para el
tráfico de una interfaz, consulte “Asignar tráfico” en la página 197. Para obtener
más información sobre las opciones de administración y otras opciones de
servicios disponibles para cada interfaz, consulte “Controlar el tráfico
administrativo” en la página 3-26.
Configurar interfaces de la zona de seguridad 53

Asociar una interfaz a una zona de seguridad

Cualquier interfaz física se puede asociar a una zona de seguridad L2 o L3. Una
subinterfaz sólo se puede asociar a una zona de seguridad L3, porque las
subinterfaces requieren una dirección IP. Solamente se puede asignar una dirección
IP a una interfaz después de haberla asociado a una zona de seguridad L3.
En este ejemplo asociará ethernet5 a la zona Trust.
WebUI
Network > Interfaces > Edit (para ethernet5): Seleccione Trust en la lista
desplegable Zone Name, luego haga clic en OK.
CLI
set interface ethernet5 zone trust
save
Desasociar 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, ethernet3 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
Network > Interfaces > Edit (para ethernet3): Introduzca los siguientes datos y
haga clic en OK:
Zone Name: Null

CLI
set interface ethernet3 ip 0.0.0.0/0
set interface ethernet3 zone null
save
Direccionar una interfaz de la zona de seguridad L3

Al definir una interfaz o subinterfaz de la zona de seguridad de capa 3 (“Layer 3” o
“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 Route. (Si la zona a la que se asocia la interfaz se encuentra en untrust-vr, la
interfaz siempre estará en el modo de ruta).
NOTA: Para ver ejemplos de configuración de los modos NAT y Route, consulte “Modos
de las interfaces” en la página 81.
54 Configurar interfaces de la zona de seguridad

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 su

utilización en una red privada y que pueden ser asignadas por otros
administradores para su utilización también en otras redes privadas
NOTA: Cuando se agrega una dirección IP a una interfaz, el dispositivo de seguridad

comprueba mediante una petición de ARP si la dirección IP no existe ya en la red
local. (El enlace físico debe estar activo 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 modo de ruta, todas las direcciones
de las zonas en trust-vr (para las interfaces y para los hosts) también deben ser
direcciones públicas. Las direcciones IP públicas se dividen en tres clases: A, B, y C,
según se muestra en la Tabla 11.
Tabla 11: 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 (nnn.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 de 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 según la convención se suele 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,
Address Allocation for Private Internets.
Si una 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.
Direccionar una interfaz

En este ejemplo asignará a ethernet5 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, pondrá 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
haga clic en OK:
Manage IP: 210.1.1.5
CLI
set interface ethernet5 manage-ip 210.1.1.5
save
Modificar los ajustes de la 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 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 el trust-vr) Modo de la

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

transmisión máxima (MTU).
(Interfaces L3) Impedir que el tráfico entre y salga por la misma interfaz,
incluyendo el tráfico entre una subred principal y una 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 activo (“up”) o inactivo (“down”). Forzando el estado
físico del vínculo como inactivo, 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 ethernet1, 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 ethernet1): Realice las modificaciones
siguientes; a continuación, haga clic en OK:
Manage IP: 10.1.1.12

Management Services: (seleccione) SSH, SSL; (borre) Telnet, WebUI
CLI
set interface ethernet1 manage ssh
set interface ethernet1 manage ssl
unset interface ethernet1 manage telnet
unset interface ethernet1 manage web
save
Crear 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 VSI. Para ver
un ejemplo que contenga la configuración de una subinterfaz en una interfaz
redundante, consulte “Conmutación por error del sistema virtual” en la
página 11-93.
En este ejemplo creará una subinterfaz para la zona Trust en el sistema raíz.
Configurará la subinterfaz en ethernet1, que está asociada a la zona Trust. Asociará
la subinterfaz a una zona definida por el usuario llamada “accounting”, que se
encuentra en el 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:
Interface Name: ethernet1.3

Zone Name: accounting
VLAN Tag: 3
CLI
set interface ethernet1.3 zone accounting
set interface ethernet1.3 ip 10.2.1.1/24 tag 3
save
Eliminar 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 ethernet1:1.
WebUI
Network > Interfaces: Haga clic en Remove para ethernet1:1.
Un mensaje del sistema le pedirá que confirme la eliminación.
Haga clic en Yes para eliminar la subinterfaz.
CLI
unset interface ethernet1:1
save

Crear 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 puede no desear 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

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

secundaria, la dirección siempre tiene 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.
Tampoco se puede configurar una puerta de enlace para una dirección IP

secundaria.
Siempre que se 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 inhabilita 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

ethernet1, una interfaz con la dirección IP 10.1.1.1/24 asociada a la zona Trust.
WebUI
Network > Interfaces > Edit (para ethernet1) > Secondary IP: Introduzca los
siguientes datos y haga clic en Add:
CLI
set interface ethernet1 ip 192.168.2.1/24 secondary
save
Crear una dirección IP secundaria 59
Interfaces de bucle invertido (loopback)

Una interfaz de bucle invertido 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 estado activo mientras el dispositivo en
el que reside esté activo. Las interfaces de bucle invertido se denominan
loopback.id_num, en donde id_num es un número superior o igual a 1 y denota una
interfaz de bucle invertido única 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 id_num 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 en muchos

aspectos como si fuera una interfaz física:
“Ajustar la interfaz de bucle invertido para administración” en la página 61
“Ajustar BGP en una interfaz de bucle invertido” en la página 61
“Ajustar VSI en una interfaz de bucle invertido” en la página 62
“Ajustar la interfaz de bucle invertido como interfaz de origen” en la página 62
NOTA: No se 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/agregada. En interfaces de bucle invertido no se pueden
configurar las siguientes características: NTP, DNS, VIP, IP secundaria, seguimiento
de IP o WebAuth.
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 MIP, consulte “MIP y la interfaz de bucle invertido
(loopback)” en la página 8-76.
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 asignada a una
interfaz de bucle invertido.
Crear 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.
60 Interfaces de bucle invertido (loopback)

WebUI
Network > Interfaces > New Loopback IF: Introduzca los siguientes datos y
haga clic en OK:
Interface Name: loopback.1

Zone: Untrust (seleccione)
IP Address/Netmask: 1.1.1.27./24
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.
Ajustar la interfaz de bucle invertido para 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; a continuación, haga clic en OK.
CLI
set interface loopback.1 manage
save
Ajustar 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 loopback, 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; a
continuación, haga clic en OK.
CLI
set interface loopback.1 protocol bgp
save
Interfaces de bucle invertido (loopback) 61

Ajustar VSI en una interfaz de bucle invertido

Puede configurar interfaces de seguridad virtuales (VSI) para NSRP en una interfaz
de bucle invertido. El estado físico de la VSI en la interfaz de bucle invertido está
siempre activo. La interfaz puede ser 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
Ajustar 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 utilice la interfaz anteriormente definida loopback.1 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
Cambios de estado de la interfaz

Una interfaz puede estar en uno de los estados siguientes:
Físicamente activa: Para interfaces Ethernet físicas que operan en la capa 2

(modo transparente) o en la capa 3 (modo de ruta) en el modelo de
interconexión de sistemas abiertos (Open Systems Interconnection u OSI). Una
interfaz está físicamente activa cuando está cableada a otro dispositivo de red y
puede establecer un enlace a ese dispositivo.
62 Cambios de estado de la interfaz

Lógicamente activas: Tanto para interfaces físicas como para interfaces lógicas
(subinterfaces, interfaces redundantes e interfaces agregadas). Una interfaz
está lógicamente activa cuando el tráfico que la atraviesa puede alcanzar los
dispositivos especificados (en las direcciones IP supervisadas) de una red.
Físicamente inactivas: Una interfaz está físicamente inactiva cuando no está

cableada a otro 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
inactiva ejecutando el comando CLI siguiente: set interface interface phy
link-down.
Lógicamente inactiva: Una interfaz está lógicamente inactiva cuando el tráfico

que la atraviesa no puede alcanzar los dispositivos especificados (en las
direcciones IP que están sujetas a seguimiento) de una red.
El estado físico de una interfaz tiene prioridad sobre su estado lógico. Una interfaz
puede estar físicamente activa y, al mismo tiempo, lógicamente activa o inactiva.
Cuando una interfaz está físicamente inactiva, su estado lógico es irrelevante.
Cuando el estado de una interfaz es activo, todas las rutas que utilizan esa interfaz
permanecen activas y utilizables. Cuando el estado de una interfaz es inactivo, el
dispositivo de seguridad desactiva todas las rutas que utilizan esa interfaz aunque,
dependiendo de si la interfaz está físicamente o lógicamente inactiva, el tráfico
podría seguir atravesando una interfaz en estado inactivo (consulte “Interfaces
inactivas y flujo de tráfico” en la página 75). 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 activo al inactivo en una
interfaz supervisada puede hacer que la interfaz supervisora cambie su estado de
inactivo a activo. Para configurar este comportamiento, puede utilizar el siguiente
comando CLI:
set interface interface monitor threshold number action up { logically | physically }
Al introducir este comando, el dispositivo de seguridad fuerza automáticamente la

interfaz supervisora al estado inactivo. Si el objeto supervisado (dirección IP,
interfaz o zona supervisada) falla, el estado de la interfaz supervisora se activa
(lógica o físicamente, dependiendo de su configuración).
Una interfaz puede supervisar objetos en cuanto al menos uno de los eventos
siguientes. Consulte la Figura 33 en la página 64. Cada uno de estos eventos,
individual o combinado, puede provocar que el estado de la interfaz supervisora
cambie de activo a inactivo 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
Cambios de estado de la interfaz 63

Figura 33: Supervisión del estado de interfaces
Si un objeto supervisado falla… ...y el peso para ese objeto

el umbral de fallo de
supervisión…
Desconexión
física
...y la acción se establece como
La interfaz se desconecta. desactivar…
Fallo del
seguimiento de IP
…entonces la interfaz
supervisora se desactiva.
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 en la misma zona se

desactivan.
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 retardo de aproximadamente un segundo entre el momento en que el
objeto supervisado tiene éxito y la reactivación de la interfaz supervisora.
Cada uno de los eventos antes indicados se presenta en las secciones siguientes.
Supervisar la conexión física

Las interfaces físicas de un dispositivo de seguridad supervisan el estado de su
conexión física a 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
activo y todas las rutas que utilizan esa interfaz están activas.
Puede consultar 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 activo (“up”) o inactivo (“down”).
Puede consultar el estado de una ruta en el campo de estado del comando get
route id number y en la página “Network > Routing > Routing Entries” de WebUI.
Un asterisco indica que la ruta está activa. Si no hay asterisco, está inactiva.

Dar seguimiento a 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, incluso si la conexión física sigue activa. Una ruta
desactivada vuelve a activarse cuando 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 “Definir la conmutación por error
de interfaces” en la página 11-52).
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
eco ICMP (ping) en la interfaz a un máximo de cuatro direcciones IP de destino a
intervalos definidos por el usuario. El dispositivo de seguridad supervisa estos
objetivos para comprobar 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
redirige 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 (modo

de ruta).
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 “Supervisar interfaces” en la página 70.
Para cada interfaz se puede configurar el seguimiento de hasta cuatro direcciones IP

por parte del dispositivo de seguridad. En un único 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 darle seguimiento a 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 interface 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 ethernet1 está asociada a la zona Trust y tiene

asignada la dirección de red 10.1.1.1/24. Las interfaces ethernet3 y ethernet4 están
asociadas a la zona Untrust. La interfaz ethernet3 tiene asignada la dirección de red
1.1.1.1/24 y está conectada al enrutador en 1.1.1.250. La interfaz ethernet4 tiene
asignada la dirección de red 2.2.2.1/24 y está conectada al enrutador en 2.2.2.250.
Figura 34: Seguimiento de IP de interfaz
Enrutador
1.1.1.250
ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Zona Trust Zona Untrust
10.1.1.0/24 Internet
ethernet4
2.2.2.1/24
Enrutador
2.2.2.250
Hay dos rutas predeterminadas configuradas: en una se utiliza ethernet3 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 ethernet4 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 ethernet3 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 ethernet3 está activa; la ruta predeterminada que pasa por ethernet4 no
está activa, puesto que tiene menos prioridad.

Figura 35: Salida del comando “get route”
ns-> 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 eth3 1.1.1.250 S 20 1 Root
* 2 1.1.1.0/24 eth3 0.0.0.0 C 0 0 Root
3 0.0.0.0/0 eth4 2.2.2.250 S 20 10 Root
* 6 2.2.2.0/24 eth4 0.0.0.0 C 0 1 Root
* 5 10.1.1.0/24 eth1 0.0.0.0 C 20 1 Root
Si la ruta que atraviesa ethernet3 deja de estar disponible, la ruta predeterminada

que pasa por ethernet4 se convertirá en ruta activa. Active y configure el
seguimiento de IP en la interfaz ethernet3 para supervisar la dirección de enrutador
1.1.1.250. Si el seguimiento de IP falla al acceder a 1.1.1.250, todas las rutas
asociadas a la interfaz ethernet3 pasan a ser inactivas en el dispositivo de
seguridad. En consecuencia, la ruta predeterminada que atraviesa ethernet4 se
convierte en activa. Cuando el seguimiento IP pueda acceder a 1.1.1.250 de nuevo,
la ruta predeterminada que pasa por ethernet3 se convertirá en la ruta activa y, al
mismo tiempo, la ruta predeterminada que atraviesa ethernet4 pasará a estado
inactivo, ya que tiene un nivel de prioridad menor que la ruta que pasa por
ethernet3.
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 ethernet3 para
supervisar la dirección IP de enrutador 1.1.1.250, que tiene asignado un peso de
10.
WebUI
Network > Interfaces > Edit (para ethernet3) > 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 ethernet3 monitor track-ip ip 1.1.1.250 weight 10
set interface ethernet3 monitor track-ip threshold 5
set interface ethernet3 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 fallos 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 ethernet3 track-ip tal como se indica en la Figura 36.
Figura 36: Salida del comando “get interface”
ns-> get interface ethernet3 track-ip

ip addressintervalthreshold wei gatewayfail-countsuccess-rate
1.1.1.250 11100.0.0.034346%
threshold: 5, failed: 1 ip(s) failed, weighted sum = 10
El comando get route indica que la ruta predeterminada que atraviesa ethernet4
está activa en estos momentos; todas las rutas que pasan por ethernet3 han dejado
de estar activas.
Figura 37: Salida del comando “get route”
ns-> 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)
---------------------------------------------------------------------
---------------------------------------------------------------------
* 4 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
3 0.0.0.0/0 eth4 2.2.2.250 S 20 10 Root
* 6 2.2.2.0/24 eth4 0.0.0.0 C 0 1 Root
* 5 10.1.1.0/24 eth1 0.0.0.0 C 20 1 Root
Recuerde que aunque las rutas que pasan por ethernet3 no estén activas, el
seguimiento de IP utiliza las rutas asociadas a ethernet3 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 ethernet3 se
vuelve a convertir en la ruta activa del dispositivo de seguridad. Al mismo tiempo,
la ruta predeterminada que pasa por ethernet4 se convierte en ruta inactiva, ya que
su nivel de prioridad es inferior al de la ruta predeterminada que pasa por
ethernet3.

Supervisar 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 38. Por ejemplo, si el estado de una interfaz
supervisada cambia de activo a inactivo, puede ocurrir lo siguiente, según se
muestra en la Tabla 12.
Tabla 12: Interfaz supervisada
Si: Después:
El estado físico de una El cambio de estado puede provocar que otra interfaz que esté
interfaz cambia de activo supervisando a la que acaba de desactivarse también se desactive.
a inactivo Puede especificar si la segunda interfaz debe quedar física o
lógicamente desactivada.
El cambio de estado de la interfaz que se está desactivando
físicamente, o el peso combinado de ambas interfaces desactivándose
físicamente juntas, puede desencadenar un fallo de NSRP. Un fallo del
dispositivo NSRP o de un grupo VSD sólo puede producirse 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 otra interfaz que esté
interfaz cambia de activo supervisando a la que acaba de desactivarse también se desactive.
a inactivo como Aunque la primera interfaz esté lógicamente inactiva, puede
resultado de un fallo de especificar si el estado inactivo de la segunda interfaz debe ser lógico
seguimiento de IP o físico.
Figura 38: Supervisión de interfaces de Ethernet1 and Ethernet2
Una interfaz supervisa a otra interfaz
Utilizando el seguimiento de IP,

ethernet3 supervisa al enrutador
en 1.1.1.250.
Utilizando la supervisión de
interfaces, ethernet2 supervisa a
ethernet3.
ethernet3 ethernet2
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 interface1 monitor interface interface2 [ weight number ]
Si no 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 39.
NOTA: Una interfaz sólo puede pertenecer a un bucle a la vez. No admitimos

configuraciones en las que una interfaz pertenezca a varios bucles.
Figura 39: Supervisión de bucles
Primer cambio de Segundo cambio de

Bucle - Dos interfaces supervisándose estado, si: estado, si:
mutuamente Utilizando el seguimiento de IP, • El número de intentos fracasados • El peso del fallo de la primera
ambas interfaces supervisan de ejecutar un "ping" a cualquiera de interfaz es mayor que o igual al
enrutadores. los enrutadores excede el umbral de umbral de la fallo de
Utilizando la supervisión de fallos de esa dirección IP supervisión de la segunda
interfaces, también se supervisada interfaz
supervisan mutuamente. • El peso del IP de seguimiento de • La acción en caso de fallo es
fallo es mayor que o igual al umbral cambiar de activo a inactivo
de fallo del objeto de seguimiento
• El peso del objeto de seguimiento
es mayor que o igual que el umbral
de fallo de supervisión
• La acción en caso de fallo es
cambiar de activo a inactivo Después:
ethernet3 ethernet2 Después: La segunda interfaz también cambia
IP 1.1.1.1 IP 2.1.1.1 La segunda interfaz también cambia su estado de activo a inactivo.
su estado de activo a inactivo.
Supervisar dos interfaces

En este ejemplo, configurará ethernet3 para supervisar dos interfaces: ethernet1 y
ethernet2. Dado que el peso de cada interfaz supervisada (8 + 8) es igual al umbral
de fallos de supervisión (16), tanto ethernet1 como ethernet deben fallar (y cambiar
su estado de activo a inactivo) simultáneamente para provocar el fallo de ethernet3
(y cambiar su estado de activo a inactivo). Consulte la Figura 40.
NOTA: Este ejemplo omite la configuración del seguimiento de IP en las interfaces ethernet1 y
ethernet2 (consulte “Dar seguimiento a direcciones IP” en la página 65). Sin
seguimiento de IP, la única manera de que ethernet1 y ethernet2 puedan fallar es que
sean desconectadas físicamente de otros dispositivos de la red o que no puedan
mantener enlaces con esos dispositivos.
Si establece el umbral de fallos de supervisión en 8, o lo deja en 16 y establece el peso

de cada interfaz supervisada en 16, el fallo de ethernet1 o de ethernet2 puede hacer
fallar a ethernet3.
Figura 40: Supervisión de interfaz de dos bucles
ethernet3 supervisa a ethernet1 y a ethernet2. Dado que el umbral de fallos

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

Network > Interfaces > Edit (para ethernet3) > Monitor: Escriba 16 en el
campo “Monitor Threshold”; a continuación, haga clic en Apply.
CLI
set interface ethernet3 monitor interface ethernet1 weight 8
set interface ethernet3 monitor threshold 16
save
Supervisar un bucle de interfaz

En este ejemplo, primero configurará el seguimiento de IP para dos interfaces,
ethernet1 y ethernet3. A continuación, configurará estas interfaces para
supervisarse mutuamente de modo que, si una cambia de estado, la otra actúe de
igual modo. Por último, definirá dos conjuntos de rutas. El primer conjunto reenvía
tráfico a través de ethernet1 y ethernet3. El segundo conjunto tiene las mismas
direcciones de destino, pero estas rutas tienen métricas de menor rango y utilizan
otras interfaces de salida (ethernet2 y ethernet4) 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 41: Supervisión de cuatro bucles de interfaz
A los hosts de la A Internet ethernet1 y ethernet3 realizan el seguimiento de

zona Trust IP. ethernet1 supervisa al enrutador interno en
10.1.1.250. ethernet3 supervisa al enrutador
Enrutador Enrutador externo en 1.1.1.250.
interno externo
10.1.1.250 1.1.1.250 Umbral de fallos de la IP supervisada: 10
10.1.2.250 1.1.2.250 Peso de la IP supervisada: 8
1.1.1.1/24 Peso del objeto supervisado: 8
10.1.1.1/24 10.1.2.1/24 Zona Untrust 1.1.2.1/24 Umbral de fallos de supervisión: 8
Zona Trust Zona Trust Zona Untrust
Interfaces de
dispositivo de
seguridad
ethernet1 – ethernet8 1 2 3 4 5 6 7 8
ethernet1 y ethernet3 se Si ethernet1 y ethernet3 se desactivan, las rutas que se refieren a esas
supervisan mutuamente. 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 ethernet2 y ethernet4.
interfaz supervisada es ethernet1 y ethernet3
igual al umbral de fallos de Rutas
supervisión, el fallo de Peso de la interfaz supervisada: 8 set route 10.1.0.0/16 interface ethernet1 gateway 10.1.1.250 metric
cualquier interfaz hace Umbral de fallos de supervisión: 8 set route 10.1.0.0/16 interface ethernet2 gateway 10.1.2.250 metric
set route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250 metric 10
que la otra falle también. set route 0.0.0.0/0 interface ethernet4 gateway 1.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 inactivo (o
activo), debe utilizar el comando CLI set interface interface monitor threshold
number action { down | up } { logically | physically }. Sólo se pueden activar o
desactivar 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

Interface: ethernet1
Metric: 10

Metric: 12

Metric: 10

Metric: 12
CLI
1. Seguimiento de IP
set interface ethernet1 track-ip ip 10.1.1.250 weight 8
set interface ethernet1 track-ip threshold 8
set interface ethernet1 track-ip weight 8
set interface ethernet1 track-ip
set interface ethernet3 track-ip ip 1.1.1.250 weight 8
set interface ethernet3 track-ip threshold 8
set interface ethernet3 track-ip weight 8
set interface ethernet3 track-ip
2. Supervisión de interfaces
set interface ethernet1 monitor threshold 8 action down physically
set interface ethernet3 monitor threshold 8 action down physically

3. Rutas
set vrouter trust-vr route 10.1.0.0/16 interface ethernet1 gateway 10.1.1.250
metric 10
metric 12
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250 metric
10
12
save
Supervisar 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á activa.
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 interface monitor zone zone [ weight number ]
Si no indica un peso, el dispositivo de seguridad aplica el valor predeterminado,

255
Interfaces inactivas 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 fallo de seguimiento de IP, la interfaz puede
continuar físicamente activa 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 fallo
de seguimiento de IP. Asimismo, el dispositivo de seguridad continúa utilizando la
interfaz para enviar peticiones de 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 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 redirija las respuestas de la sesión a otra
interfaz. Si no activa este comando, el dispositivo de seguridad reenviará 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 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 envía una petición ARP para la dirección MAC de
destino y agrega la dirección MAC recibida a su tabla ARP. El dispositivo de
seguridad realiza otra consulta ARP cada vez que se produce un cambio de ruta.
En “Fallo en la interfaz de salida” se describen 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: En “Fallo en la interfaz de salida” se describe cómo el seguimiento de IP dispara

los cambios de rutas y cómo pueden afectar estos cambios al flujo de paquetes de
todos los dispositivos de seguridad de Juniper Networks distintos a NetScreen-5XT
y NetScreen-5GT. En el caso de estos dispositivos, un fallo de seguimiento de IP
dispara una conmutación por error de interfaz. Para obtener más información,
consulte “Interfaces Dual Untrust” en la página 11-50.
Fallo en la interfaz de salida

En el siguiente contexto, vamos a configurar el seguimiento de IP en ethernet2, 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 indica a continuación en la
Figura 42.
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 42: Seguimiento de IP del host A y del host B
Flujo de tráfico del host A al host B: petición (inicio de sesión)

Interfaz de entrada Primera interfaz de salida
ethernet1 ethernet2 Seguimiento de IP
10.1.1.1/24 1.1.1.1/24 activado desde ethernet2
2
Zona Untrust
Zona Trust Consulta de Consulta Consulta de
sesiones de rutas directivas 3
10.1.1.0/24
10.1.1.1/24 Host B
2.2.2.2
4
1
Host A Respondedor
10.1.1.5 Iniciador
Segunda interfaz de salida Puertas de enlace:

ethernet3 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 retorno sigue una ruta de regreso
similar a través del dispositivo de seguridad, como se indica en la Figura 43.
Figura 43: Flujo de tráfico de salida del host B al host A
Flujo de tráfico del host A al host B: respuesta

ethernet1 ethernet2 Seguimiento de IP desde
10.1.1.1/24 1.1.1.1/24 ethernet2 correcto
Zona Untrust
Zona Trust Actualización
de sesión
10.1.1.0/24 Host B
2.2.2.2
Host A Respondedor
10.1.1.5 Iniciador

ethernet3 1.1.1.254
1.1.2.1/24 1.1.2.254
Si falla el seguimiento de IP en ethernet2, el dispositivo de seguridad desactiva las

rutas que utilicen ethernet2 y utiliza ethernet3 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 ethernet2 como a través de ethernet3 y el dispositivo de seguridad las reenvía a
través de ethernet1 al host A. Consulte la Figura 44.

Figura 44: Fallo del seguimiento de IP de salida
Flujo de tráfico del host B al host A: el fallo de seguimiento de IP dispara el redireccionamiento

10.1.1.1/24 1.1.1.1/24 ethernet2 incorrecto
1
Zona Untrust
Zona Trust Cambio Actualización
de ruta de sesión
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:
ethernet3 1.1.1.254
1.1.2.1/24 1.1.2.254
Fallo en la interfaz de entrada

En el siguiente contexto, configurará de nuevo el seguimiento de IP en ethernet2,
pero esta vez ethernet2 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 indica en la Figura 45.
Figura 45: Flujo de tráfico de entrada del host B al host A
Flujo de tráfico del host B al host A: petición (inicio de sesión)

ethernet1 ethernet2 Seguimiento de IP activado
10.1.1.1/24 1.1.1.1/24 desde ethernet2
Zona Untrust
Zona Trust Consulta de Consulta de Consulta de
directivas rutas sesiones
10.1.1.1/24 Host B
10.1.1.0/24
1 2.2.2.2
Host A 3
10.1.1.5
Iniciador
Respondedor Puertas de enlace:
1.1.1.254
Segunda interfaz de salida
1.1.2.254
ethernet3
1.1.2.1/24

Cuando el host A responde al host B, el tráfico de retorno sigue una ruta de regreso
similar a través del dispositivo de seguridad, como se indica en la Figura 46.
Figura 46: Flujo de tráfico de entrada del host A al host B
Flujo de tráfico del host B al host A: respuesta

10.1.1.1/24 1.1.1.1/24 ethernet2 correcto
2 Zona Untrust
Zona Trust Consulta de
sesiones
10.1.1.1/24
10.1.1.0/24
3 Host B
4 2.2.2.2
1
Host A
10.1.1.5 Iniciador
Respondedor

ethernet3 1.1.1.254
1.1.2.1/24 1.1.2.254
1. El host A en 10.1.1.5 envía un paquete de respuesta a ethernet1 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 la relaciona con una sesión existente y
actualiza la entrada en la tabla de la sesión.
3. Utilizando la dirección MAC de la puerta de enlace en 1.1.1.254 guardada en caché o realizando una búsqueda ARP para averiguar la dirección MAC, el
dispositivo reenvía el paquete a la puerta de enlace por medio de ethernet2.
4. Cuando la puerta de enlace en 1.1.1.254 recibe la respuesta, la reenvía al siguiente salto. El enrutamiento continúa hasta que el host B recibe el paquete.
Si falla el seguimiento de IP en ethernet2, el dispositivo de seguridad desactiva las

rutas que utilicen ethernet2 y utiliza ethernet3 para el tráfico saliente destinado al
host B. Sin embargo, las peticiones del host B al host A todavía pueden llegar tanto
a través de ethernet2 y el dispositivo de seguridad las reenvía a través de ethernet1
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, en
función de la aplicación del comando set arp always-on-dest.
Si activa 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 en el caché 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 ethernet2, el dispositivo de seguridad

desactiva primero todas las rutas que utilicen ethernet2 y realiza una búsqueda de
rutas. Encuentra otra ruta para acceder al host B a través de ethernet3 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 está activado el comando set arp always-on-dest, el
dispositivo de seguridad realizará una búsqueda 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
posteriores del host A a través de ethernet3 a la puerta de enlace en 1.1.2.254.
Figura 47: Fallo de seguimiento de IP de entrada con redireccionamiento de tráfico
Flujo de tráfico del host B al host A: el fallo de seguimiento de IP dispara el

redireccionamiento

1 2
Zona Untrust
Zona Trust Cambio Actualización
de ruta de sesión
10.1.1.1/24
10.1.1.0/24 Host B
2.2.2.2
3
Host A
10.1.1.5 Iniciador
Respondedor
Puertas de enlace:
1.1.1.254
Segunda interfaz de salida 1.1.2.254
ethernet3
1.1.2.1/24
Si está 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 ethernet2. En este caso, el fallo de seguimiento de IP no afecta al
flujo de datos a través del dispositivo de seguridad.
Figura 48: Fallo de seguimiento de IP de entrada sin redireccionamiento
Flujo de tráfico del host B al host A: el fallo de seguimiento de IP no dispara el

redireccionamiento
2
Zona Untrust
Zona Trust Búsqueda
de sesión
10.1.1.1/24
10.1.1.0/24 3
4 Host B
2.2.2.2
1
Host A
10.1.1.5 Respondedor Iniciador

ethernet3 1.1.1.254
1.1.2.1/24 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 ruta (“Route”) y modo transparente
(“Transparent”). Si una interfaz asociada a una zona de capa 3 (“Layer 3”) tiene una
dirección IP, el modo de funcionamiento de esa interfaz se puede definir como NAT
o rutas. Una interfaz asociada a una zona de capa 2 (“Layer 2”) (como 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 se puede definir el modo de funcionamiento de una interfaz asociada a

cualquier zona de capa 3 como NAT, el dispositivo de seguridad solamente
aplicará NAT al tráfico que pase por esa interfaz en dirección hacia la zona
Untrust. ScreenOS no aplica NAT al tráfico destinado a ninguna zona que no sea la
zona Untrust. Asimismo, observe que aunque ScreenOS permite poner una
interfaz de la zona Untrust en modo NAT, esto no activa ninguna operación de
NAT.
“Modo transparente” en la página 82
“Ajustes de zona” en la página 83
“Reenviar tráfico” en la página 83
“Opciones “unicast” desconocidas” en la página 84
“Modo NAT” en la página 94
“Tráfico NAT entrante y saliente” en la página 96
“Ajustes de interfaz” en la página 97
“Modo de ruta” en la página 100
“Ajustes de interfaz” en la página 101
81
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 49.
Figura 49: 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.
82 Modo transparente
Capítulo 4: Modos de las interfaces
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, utiliza la interfaz VLAN1 para
administrar el dispositivo y terminar 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.
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 preasociadas a las zonas L2 de cada
plataforma de seguridad de Juniper Networks, consulte el manual del instalador de
cada plataforma.
Reenviar tráfico
Un dispositivo de seguridad que opera en la capa 2 (“Layer 2” o “L2”) no permiten
ningún tráfico interzonal ni intrazonal a menos que haya una directiva configurada
en el dispositivo. Para obtener más información sobre cómo establecer directivas,
consulte “Directivas” en la página 2-163. Una vez configurada en el dispositivo de
seguridad, una directiva 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).
Desde ese momento, el dispositivo de seguridad puede recibir y transmitir
tráfico “broadcast” L2 para el protocolo en árbol.
Modo transparente 83
Continúa bloqueando todo el tráfico “unicast” no IP y no 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,

consistente en bloquear todo el tráfico “unicast” no IP y no ARP, ejecute 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
ejecutó el comando unset interface vlan1 bypass-non-ip-all y ahora desea
que el dispositivo recupere su comportamiento predeterminado, que consiste
en bloquear únicamente el tráfico “unicast” no IP y no ARP, deberá ejecutar
primero el comando set interface vlan1 bypass-non-ip para permitir que todo
el tráfico no IP y no ARP, incluyendo el tráfico “multicast”, “unicast” y
“broadcast” pase por el dispositivo. A continuación, deberá ejecutar el
comando unset interface vlan1 bypass-non-ip para bloquear únicamente el
tráfico unicast no IP y no ARP.
Para permitir que un dispositivo de seguridad transmita tráfico IPSec sin

intentar terminarlo, utilice el comando set interface vlan1
bypass-others-ipsec. El dispositivo de seguridad permitirá entonces que el
tráfico IPSec pase a través de otros puntos terminales de la VPN.
NOTA: Un dispositivo de seguridad con interfaces en modo transparente requiere 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 caché de ARP.
A medida que el tráfico ARP atraviesa un dispositivo de seguridad en modo

transparente, el dispositivo analiza la dirección MAC de origen en cada paquete y
memoriza qué interfaz conduce a esa dirección MAC. De hecho, el dispositivo de
seguridad aprende qué interfaz conduce a qué dirección MAC observando 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

entre zonas a menos que haya una directiva configurada en el dispositivo. Para
obtener más información sobre cómo el dispositivo reenvía tráfico cuando está en
modo transparente, consulte “Reenviar tráfico” en la página 83.
Puede ocurrir que un dispositivo envíe un paquete unicast con una dirección MAC
de destino tomada de su caché ARP, pero que el dispositivo de seguridad no tenga
registrada en su tabla de reenvíos. Por ejemplo, el dispositivo de seguridad borra su
tabla de reenvíos 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
contiene ninguna entrada en su tabla de reenvíos, puede tomar una de estas dos
decisiones:
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 descubrir la dirección MAC de
destino cuando ésta se encuentre en una subred no adyacente.
NOTA: De los dos métodos (“flood” y “ARP/trace-route”), ARP es más seguro porque el
dispositivo de seguridad inunda con preguntas ARP y paquetes trace-route (no el
paquete inicial) saliendo por todas las interfaces.
Método de inundación
El método de inundación reenvía paquetes del mismo modo que la mayoría de
conmutadores (“switches”) de la capa 2. Un conmutador mantiene una tabla de
reenvíos que contiene direcciones MAC y sus puertos asociados para cada dominio
de 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 figura en la tabla de
direcciones MAC del dispositivo de seguridad, inunda el paquete saliendo por todas
las interfaces.
Figura 50: Método de inundación
ethernet1 ethernet4
IP 0.0.0.0/0 IP 0.0.0.0/0
El paquete llega a
ethernet1. Zona
Enrutador V1-DMZ
Zona V1-Trust
Espacio de direcciones común
ethernet2 ethernet3
IP 0.0.0.0/0 IP 0.0.0.0/0
Zona V1-Untrust
Zona
L2-Finance
Enrutador Enrutador Se encontró Untrust

El dispositivo de seguridad inunda el paquete saliendo por ethernet2, sin embargo
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 > Interface > Edit (para VLAN1): Para las opciones de broadcast,
seleccione Flood, después haga clic en OK.
CLI
set interface vlan1 broadcast flood
save
Método ARP/Trace-Route
Cuando se 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 dicha
dirección 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 nota de la
página siguiente).
1. El dispositivo de seguridad detecta la dirección MAC de destino en el paquete

inicial (y, si aún no está, agrega la dirección MAC de origen y su interfaz
correspondiente a la tabla de reenvíos).
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 1 en el campo
“time-to-live” (TTL), e inunda esos paquetes saliendo por todas las interfaces
excepto por 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 mediante “broadcasts”.
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 reenviar el tráfico destinado a esa dirección. (Consulte la
Figura 51, “Método ARP,” en la página 88).
NOTA: La dirección IP de entrada hace referencia a la dirección IP del último dispositivo

que envió 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 situada

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, aún más
importante, indica la interfaz a través de la cual el dispositivo de seguridad
debe reenviar el tráfico destinado a esa dirección MAC. (Consulte la Figura 52,
“Trace-Route,” en la página 89).
NOTA: De hecho, trace-route devuelve las direcciones IP y MAC de todos los enrutadores
en la subred. A continuación, el dispositivo de seguridad compara 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 apuntar, y por lo tanto, qué interfaz utilizar
para alcanzar ese destino.
4. Combinando la dirección MAC de destino obtenida 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 reenvíos.
5. El dispositivo de seguridad reenvía a su destino a través de la interfaz correcta

todos los paquetes que reciba posteriormente.
Para habilitar el método ARP/trace-route para tratar los paquetes unicast

desconocidos, ejecute cualquiera de los siguientes procedimientos:
WebUI
Network > Interface > Edit (para VLAN1): Para las opciones de broadcast,
seleccione ARP, después 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 51 muestra cómo el método ARP puede localizar la dirección MAC de

destino cuando la dirección IP de destino se encuentra en una subred adyacente.
Figura 51: Método ARP
Nota: A continuación solamente se muestran los VLAN1

elementos relevantes del encabezado del paquete y 210.1.1.1/24
los últimos cuatro dígitos en las direcciones MAC. 0010.db15.39ce
PC A ethernet1 ethernet4 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 ethernet1 y la tabla de reenvíos no tiene Zona V1-Trust Enrutador
una entrada para la dirección MAC
00bb.11bb.11bb, el dispositivo de seguridad
inunda el siguiente paquete arp-q: Espacio
Trama Ethernet Mensaje ARM común de
direcciones
ethernet2 ethernet3
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
a ethernet2: Zona
Zona
L2-Finance
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
Podrá asociar la dirección MAC a la interfaz que 00bb.11bb.11bb
conduce hacia ella.
La Figura 52 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 52: Trace-Route
Nota: A continuación solamente se muestran los VLAN1

elementos relevantes del encabezado del paquete y 210.1.1.1/24
los últimos cuatro dígitos en las direcciones MAC. 0010.db15.39ce
PC A ethernet1 ethernet4 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 ethernet1 y la tabla de reenvíos no tiene una Zona V1-Trust
entrada para la dirección MAC 00dd.11dd.11dd, el
dispositivo de seguridad inunda el siguiente paquete
trace-route saliendo de ethernet2, 3 y 4:
Espacio
común de
direcciones
Trama Ethernet Mensaje ICMP ethernet2 ethernet3
0.0.0.0/0 0.0.0.0/0
dst src type src dst TTL 0010.db15.39ce 0010.db15.39ce Se encontró
11dd 11aa 0800 210.1.1.5 195.1.1.5 1 Zona Untrust
V1-Untrust
Cuando el dispositivo recibe la siguiente Zona
respuesta en ethernet3: L2-Finance
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 Time
Exceeded
Ahora se puede asociar la dirección MAC

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

En este ejemplo configurará el dispositivo de seguridad para la administración a su
interfaz VLAN1 como se presenta a continuación:
Asignará a la interfaz VLAN1 la dirección IP 1.1.1.1/24.
Habilitará 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 (“Layer 2”), debe
establecer las mismas opciones de administración para la interfaz VLAN1 que para la zona
de seguridad de capa 2.
Agregará 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 53: VLAN transparente
Subred Enrutador interno Subred Enrutador externo

1.1.2.0/24 1.1.1.251 1.1.1.0/24 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 trabajo Interfaz V1-Trust Interfaz V1-Untrust

admin ethernet1 ethernet3
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
Configurar el 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, cambiará 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. Utilizará la dirección IP de
VLAN1 (1.1.1.1/24) para administrar el dispositivo de seguridad desde la zona de
seguridad V1-Trust. Definirá direcciones para los servidores FTP y de correo.
También configurará 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-152.
Figura 54: Modo transparente básico
FTP_Server Mail_Server 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

ethernet1 ethernet3
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 después 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
haga clic en OK:
Zone Name: V1-Trust

haga clic en OK:
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
en OK:
Address Name: FTP_Server

Zone: V1-Trust
en OK:
Address Name: Mail_Server

Zone: V1-Trust
6. Ruta

Interface: vlan1(trust-vr)
Metric: 1
7. Directivas
Policies > (From: V1-Trust, To: V1-Untrust) New: Introduzca los siguientes
Source Address:
Service: Any
Action: Permit
Policies > (From: V1-Untrust, To: V1-Trust) New: Introduzca los siguientes
Source Address:
Address Book Entry: (seleccione), Mail_Server
Service: Mail
Action: Permit
Policies > (From: V1-Untrust, To: V1-Trust) New: Introduzca los siguientes
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 ethernet1 zone v1-trust
set interface ethernet3 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.
94 Modo NAT
Figura 55: Topología de 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 del 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. El dispositivo de seguridad reenvía el paquete a su destino.
La NAT agrega un nivel de seguridad no disponible con el modo transparente: Las

direcciones de los hosts que envían tráfico a través de una interfaz de entrada en
modo NAT (como una interfaz de la zona Trust) nunca quedan expuestas a los hosts
de la zona de salida (como la zona Untrust), salvo que ambas zonas se encuentren
en el mismo dominio de enrutamiento virtual y el dispositivo de seguridad publique
rutas a interlocutores mediante 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
la NAT basada en interfaces. Las directivas que configure controlarán 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 95
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 situado 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 situado 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 56: Flujo de tráfico NAT
1. NAT basada en interfaces aplicada al tráfico de ethernet3

la zona Trust a la zona Untrust. Zona Untrust 1.1.1.1/24
Modo de ruta
2. NAT basada en interfaces aplicada al tráfico de MIP 1.1.1.10 a 10.1.1.10
la zona definida por el usuario a la zona Untrust. MIP 1.1.1.20 a 10.1.2.20
1 2
(Nota: Esto sólo es posible si las zonas definida
por el usuario y Untrust se encuentran en NAT NAT
diferentes dominios de enrutamiento virtuales).
3. Sin NAT basada en interfaces aplicada al tráfico

entre las zonas Trust y definida por el usuario.
ethernet1 Las MIP son opcionales ethernet2
4 y 5. Puede utilizar MIP, VIP o VPN para que el 10.1.1.1/24 10.1.2.1/24
tráfico de la zona Untrust llegue a la zona Trust Modo NAT 4 5 Modo NAT
o zona definida por el usuario, pero no es
necesario.
3 Sin NAT Zona definida
Zona Trust por el usuario
Las MIP
son 6
opcionales
NOTA: Para obtener más información sobre MIP, consulte “Direcciones IP asignadas” en
la página 8-65. Para obtener más información sobre VIP, consulte “Direcciones IP
virtuales” en la página 8-83.
96 Modo NAT
Ajustes de interfaz
Para el modo NAT, defina los siguientes ajustes de interfaz, donde ip_addr1 y
ip_addr2 representan los números de una dirección IP, mask representa los números
de una máscara de red, vlan_id_num representa el número de una etiqueta VLAN,
zone representa el nombre de una zona y number representa el tamaño del ancho
de banda en kbps:
Interfaces de zona Ajustes Subinterfaces de zona

Zonas Trust, DMZ y definida IP: ip_addr1 IP: ip_addr1
por el usuario que utilizan NAT Máscara de red: mask Máscara de red: mask
IP de administración1: ip_addr2 Etiqueta VLAN: vlan_id_num
Ancho de banda del tráfico2: Nombre de la zona: zone
number NAT†: (seleccione)
NAT3: (seleccione)
Untrust4 IP: ip_addr1 IP: ip_addr1
Máscara de red: mask Máscara de red: mask
IP de administración*: ip_addr2 Etiqueta VLAN: vlan_id_num
Ancho de banda del tráfico†: Nombre de la zona: zone
number
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 ruta.
4.Aunque se puede seleccionar NAT como modo de interfaz en una interfaz asociada a la zona
Untrust, el dispositivo de seguridad no realizará ninguna operación NAT en esa interfaz.
NOTA: En el modo NAT, es posible administrar un dispositivo de seguridad de cualquier

interfaz (y de varias interfaces) utilizando la dirección IP del sistema, direcciones
IP de la interfaz, direcciones IP de administración o la dirección IP MGT.
Configurar el 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 57 con el del modo ruta en la Figura 59, “Dispositivo en modo
de ruta,” en la página 102.
Modo NAT 97
Figura 57: Dispositivo en modo NAT
Enrutador externo
1.1.1.250
Servidor de correo electrónico Internet

VIP 1.1.1.5 ->
10.1.1.5
ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Modo NAT Modo de ruta
WebUI
1. Interfaces
haga clic en Apply:
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.
haga clic en OK:
Zone Name: Untrust

Interface Mode: Ruta
NOTA: Si la dirección IP de la zona Untrust del dispositivo de seguridad es asignada

dinámicamente por un ISP, deje los campos de dirección IP y máscara de red
vacíos y seleccione Obtain IP using DHCP. Si el ISP utiliza el protocolo
“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 ethernet3) > VIP: Introduzca los siguientes
datos y haga clic en Add:
Virtual IP Address (dirección IP virtual o VIP): 1.1.1.5
Network > Interfaces > Edit (para ethernet3) > VIP > New VIP Service:
Virtual Port: 25
Map to Service: Mail
Map to IP: 10.1.1.5
98 Modo NAT
NOTA: Para obtener más información sobre direcciones IP virtuales (VIP), consulte
“Direcciones IP virtuales” en la página 8-83.
3. Ruta

4. Directivas
haga clic en OK:
Source Address:
Service: ANY
Action: Permit
Policies > (From: Untrust, To: Global) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), VIP(1.1.1.5)
Service: MAIL
Action: Permit
CLI
1. Interfaces
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 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 del dispositivo de seguridad es asignada

dinámicamente por un ISP, utilice el comando siguiente: set interface untrust
dhcp. Si el ISP utiliza el protocolo “Point-to-Point Protocol over Ethernet”, utilice
los comandos set pppoe y exec pppoe. Para obtener información adicional,
consulte ScreenOS CLI Reference Guide IPv4 Command Descriptions.
Modo NAT 99
2. VIP
set interface ethernet3 vip 1.1.1.5 25 mail 10.1.1.5
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 ruta
Cuando una interfaz está en modo de ruta (“Route”), el dispositivo de seguridad
enruta el tráfico entre diferentes zonas sin ejecutar 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 invariables 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 tráfico entrante llegue a los hosts cuando la
interfaz de la zona de destino está en modo de ruta. A diferencia del modo
transparente, las interfaces de cada zona se encuentran en subredes diferentes.
Figura 58: Topología de 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
100 Modo de ruta

No es necesario aplicar la traducción de direcciones de red de origen (“NAT-src”) en

el nivel de 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 conjunto 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-15.
Ajustes de interfaz
Para el modo de ruta, defina los siguientes ajustes de interfaz, donde ip_addr1 y
ip_addr2 representan los números de una dirección IP, mask representa los números
de una máscara de red, vlan_id_num representa el número de una etiqueta VLAN,
zone representa el nombre de una zona y number representa el tamaño del ancho
de banda en kbps:
Tabla 13: Ajustes de interfaz

I
Interfaces de zona Ajustes Subinterfaces de zona
Trust, Untrust, DMZ y zonas IP: ip_addr1 IP: ip_addr1
definidas por el usuario Netmask: mask Máscara de red: mask
IP de administración1: ip_addr2 Etiqueta VLAN: vlan_id_num
Ancho de banda del tráfico2: Nombre de la zona: zone
number Route†: (seleccione)
Route3: (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 Route, el modo de la interfaz queda definido como rutas. Al seleccionar NAT, el
modo de la interfaz queda definido como NAT.
Configurar el modo de ruta

En “Configurar el modo NAT” en la página 97, 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 ruta; 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 ruta 101

Figura 59: Dispositivo en modo de ruta
Enrutador externo
1.1.1.250
Servidor de correo electrónico Internet

1.2.2.5
Zona Trust ethernet1 ethernet3 Zona Untrust

1.2.2.1/24 1.1.1.1/24
Modo de ruta Modo de ruta
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: Ruta
haga clic en OK:
Zone Name: Untrust

NOTA: Seleccionando Route se determina que el dispositivo de seguridad funcione en el

modo de ruta, sin aplicar NAT al tráfico entrante o saliente de la zona Trust.
Si la dirección IP de la zona Untrust del dispositivo de seguridad es asignada

dinámicamente por un ISP, deje los campos de dirección IP y máscara de red
vacíos y seleccione Obtain IP using DHCP. Si el ISP utiliza el protocolo
“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. Dirección
en OK:
Address Name: Mail Server

Zone: Trust
102 Modo de ruta

3. Ruta

4. Directivas
haga clic en OK:
Source Address:
Service: ANY
Action: Permit
Policies > (From: Untrust, To: Trust) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Mail Server
Service: MAIL
Action: Permit
CLI
1. Interfaces
NOTA: El comando set interface ethernetnumber route establece que el dispositivo de

seguridad funcione en modo de ruta.
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 ruta 103

104 Modo de ruta

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. Contiene las siguientes secciones:
“Direcciones” en la página 106
“Entradas de direcciones” en la página 106
“Grupos de direcciones” en la página 108
“Servicios” en la página 111
“Servicios predefinidos” en la página 111
“Servicios personalizados” en la página 125
“Establecer el tiempo de espera de un servicio” en la página 127
“Definir un servicio de protocolo de mensaje de control de Internet

personalizado” en la página 130
“Puerta de enlace “Remote Shell” en la capa de aplicación” en la

página 131
“Puerta de enlace de llamada de procedimiento remoto de Sun en la capa

de aplicación” en la página 131
“Personalizar la puerta de enlace de la capa de aplicaciones del

procedimiento de llamadas remotas de Microsoft” en la página 133
“Puerta de enlace de la capa de aplicación del protocolo de secuencias en

tiempo real” en la página 134
“Grupos de servicios” en la página 142
“Conjuntos de IP dinámicas” en la página 144
“Direcciones DIP “sticky”” en la página 147
“Usar DIP en otra subred” en la página 148
105
“Utilizar una DIP en una interfaz de bucle invertido” en la página 153
“Crear un grupo de DIP” en la página 157
“Configurar una programación recurrente” en la página 160
NOTA: Para obtener más información sobre la autenticación de usuario, consulte el

Volumen 9: Autenticación de usuarios.
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, es necesario 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.
Entradas de direcciones
Para poder establecer muchas de las opciones de configuración del cortafuegos de
Juniper, de VPN y de asignación del tráfico, es necesario definir direcciones en unas
o varias listas de direcciones. La lista de direcciones de una zona de seguridad
contiene las direcciones IP o nombres de dominios de los hosts o subredes cuyo
tráfico está permitido, bloqueado, encriptado o autenticado 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 (“Domain Name System” o “DNS”). Para obtener más
información sobre la configuración de DNS, consulte “Compatibilidad con DNS”
en la página 221.
Para obtener más información sobre las convenciones de nomenclatura de

ScreenOS (aplicables a los nombres creados para las direcciones), consulte
“Convenciones de nomenclatura y conjuntos de caracteres” en la página xii.
106 Direcciones
Capítulo 5: Bloques para la construcción de directivas
Agregar 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
en OK:
Address Name: Sunnyvale_Eng

Zone: Trust
en OK:
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
Modificar 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
Objects > Addresses > List > Edit (para Sunnyvale_Eng): Cambie el nombre y
la dirección IP por los siguientes datos y 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.
Direcciones 107
Eliminar una dirección

En este ejemplo eliminará la entrada de la dirección “Sunnyvale_SW_Eng”.
WebUI
Objects > 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 106 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 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.
Figura 60: Grupos de direcciones
1 directiva por dirección 1 directiva por grupo de direcciones
Name Access
Address Policy
Name Access
Name
Access Address
Name Policy
Name Address
Policy Address
Address
Name Access
Address Policy
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.
108 Direcciones
NOTA: Para asegurarse de que un grupo no esté “autocontenido” accidentalmente como

miembro en su propio grupo, el dispositivo de seguridad realiza una
comprobación de coherencia cada vez que se incluye un grupo en otro. Por
ejemplo, si agrega el grupo A como miembro al grupo B, el dispositivo de
seguridad se asegura automáticamente de que A no contenga ya 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 y creando directivas
individuales internas 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).
NOTA: La forma automática en la que el dispositivo de seguridad aplica directivas a cada

miembro del grupo de direcciones ahorra al usuario tener que crearlas una por
una para cada dirección. ScreenOS incluso escribe estas directivas en ASIC, lo cual
acelera considerablemente la ejecución de las consultas.
Cuando se elimina una entrada individual en la libreta de direcciones, 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, se aplica

de forma individual a cada miembro del grupo, y el dispositivo de seguridad
genera una entrada por cada miembro en la lista de control de accesos (ACL). Si
el usuario no está atento, 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 las direcciones predefinidas: “Any”, “All Virtual IP” ni

“Dial-Up VPN” a grupos.
Direcciones 109
Crear un grupo de direcciones

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

dirección de la columna “Available Members” a la columna “Group
Members”.
Seleccione Tech Pubs 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 “HQ 2nd Floor” add “Santa Clara Eng”
set group address trust “HQ 2nd Floor” add “Tech Pubs”
save
Editar una entrada de grupo de direcciones

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

CLI
set group address trust “HQ 2nd Floor” add Support
save
Eliminar un miembro y un grupo

En este ejemplo eliminará el miembro “Support” del grupo de direcciones “HQ 2nd
Floor” y eliminará “Sales”, un grupo de direcciones que previamente habrá creado.
WebUI
Objects > Addresses > Groups > (para la zona: Trust) Edit (“HQ 2nd Floor”):
Mueva la siguiente dirección, luego haga clic en OK:
Seleccione Support y utilice el botón >> para trasladar la dirección de la

columna “Group Members” a la columna “Available Members”.
Objects > Addresses > Groups > (para la zona: Trust): Haga clic en Remove
en la columna “Configure” para “Sales”.
110 Direcciones
CLI
unset group address trust “HQ 2nd Floor” remove Support
unset group address trust Sales
save
NOTA: El dispositivo de seguridad no elimina automáticamente un grupo del que se

hayan eliminado todos los nombres.
Servicios
Los servicios son tipos de tráfico para los que existen normas 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. Para consultar qué
servicio puede utilizar en una directiva, visualice la lista desplegable Service de la
página “Policy Configuration” (WebUI) o ejecute 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:
Objects > Services > Predefined
Objects > Services > Custom
Objects > 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 125.
Esta sección contiene información sobre los siguientes servicios predefinidos:
“Protocolo de mensajes de control de Internet” en la página 112
“Servicios predefinidos relacionados con Internet” en la página 115
“Servicios de llamadas de procedimiento remoto de Microsoft” en la página 117
“Protocolos de enrutamiento dinámico” en la página 119
Servicios 111
“Vídeo de secuencia” en la página 119
“Servicios de llamadas de procedimiento remoto de Sun” en la página 120
“Servicios de túnel y seguridad” en la página 121
“Servicios relacionados con IP” en la página 121
“Servicios de mensajes instantáneos” en la página 122
“Servicios de administración” en la página 122
“Servicios de correo” en la página 123
“Servicios de UNIX” en la página 124
“Servicios varios” en la página 124
Puede encontrar información más detalladas sobre algunos de los enumerados en

las siguientes páginas:
“Definir un servicio de protocolo de mensaje de control de Internet

personalizado” en la página 130
“Puerta de enlace “Remote Shell” en la capa de aplicación” en la página 131
“Puerta de enlace de llamada de procedimiento remoto de Sun en la capa de

aplicación” en la página 131
“Personalizar la puerta de enlace de la capa de aplicaciones del procedimiento

de llamadas remotas de Microsoft” en la página 133
“Puerta de enlace de la capa de aplicación del protocolo de secuencias en

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

El protocolo de mensajes de control de Internet (ICMP) es una parte de IP y
proporciona una manera de consultar una red (mensajes de consulta de ICMP) y
recibir retroalimentación de la red para obtener los patrones de errores (mensajes
de error de ICMP). Sin embargo, ICMP no garantiza el informe o entrega de
mensajes de error de todos los datagramas perdidos y no es un protocolo fiable. El
código de ICMP y los códigos de tipo describen los mensajes de error de ICMP y los
mensajes de consultas de ICMP.
Puede seleccionar permitir o rechazar cualquiera o tipos específicos de los

mensajes de ICMP para mejorar la seguridad de la red. Algunos de los tipos de
mensajes de ICMP pueden usarse para obtener información sobre su red que puede
comprometer la seguridad. Por ejemplo, los paquetes ICMP, TCP o UDP se pueden
construir para devolver los mensajes de error de ICMP que contienen información
sobre una red, como su topología y las características de filtrado de la lista de
accesos. La siguiente tabla enumera los nombres de mensajes de ICMP, la
descripción, el tipo y el código correspondiente.
112 Servicios
Nombre de mensaje de ICMP Código Tipo Descripción

ICMP-ANY todos todos ICMP-ANY afecta a cualquier protocolo que utilice ICMP.
Al denegar ICMP-ANY, perjudica cualquier intento de
ejecutar el comando ping o supervisar una red utilizando
ICMP.
Al permitir ICMP-ANY, permite todos los mensajes de ICMP.
ICMP-ADDRESS-MASK La consulta de máscara de la dirección de ICMP se utiliza
Request (petición) 17 0 para los sistemas que necesitan la máscara de subred local
de un servidor bootstrap.
Reply (respuesta) 18 0
Al denegar los mensajes de petición de máscara de dirección
de ICMP puede afectar de manera desfavorable a los
sistemas sin discos.
Al permitir los mensajes de petición de máscara de dirección
de ICMP puede permitir que otros coloquen su huella dactilar
en el sistema operativo de un host en su red.
ICMP-DEST-UNREACH 3 0 El mensaje de error de destino inalcanzable de ICMP indica
que el host de destino está configurado para rechazar los
paquetes.
Los códigos 0, 1, 4 o 5 pueden ser de una puerta de enlace.
Los códigos 2 o 3 de un host (RFC 792).
Al denegar los mensajes de error de destino inalcanzable de
ICMP se puede eliminar el supuesto de que un host está
activo y ejecutándose detrás de un dispositivo de seguridad.
Al permitir los mensajes de error de destino inalcanzable de
ICMP puede permitir que se puedan deducir determinados
datos, como el filtrado de seguridad, sobre la red.
ICMP Fragment Needed 3 4 El mensaje de error de fragmentación de ICMP indica que
esa fragmentación es necesaria, pero está establecido el flag
de no fragmentación.
Se recomienda denegar estos mensajes de Internet (untrust)
a la red Trust.
ICMP Fragment Reassembly 11 1 El error de tiempo excedido de reensamblaje de fragmentos
de ICMP indica que un host reensambla un mensaje
fragmentado que agotó el tiempo y descartó el paquete. Este
mensaje se envía algunas veces.
a la red Trust.
ICMP-HOST-UNREACH 3 1 Los mensajes de error de host inalcanzable de ICMP indican
que las entradas de la tabla de enrutamiento no enumera o
no enumeran como infinito un host determinado. Algunas
veces este error se envía por puertas de enlace que no se
pueden fragmentar cuando se recibe un paquete que
requiere de fragmentación.
a la red fiable.
El permitir estos mensajes proporciona a otros la capacidad
para determinar sus direcciones de IP de hosts internos por
medio de un proceso de eliminación o deducir datos sobre
las puertas de enlace y la fragmentación.
Servicios 113

ICMP-INFO Los mensajes de consultas de ICMP-INFO permiten a los
Request (petición) 15 0 sistemas de host sin discos consultar la red y configurarse a
sí mismo.
Al denegar los mensajes de petición de máscara de dirección
de ICMP puede afectar de manera desfavorable a los
sistemas sin discos.
El permitir los mensajes de petición de máscara de dirección
de ICMP puede permitir que otros transmitan consultas
sobre información a un segmento de red para determinar el
tipo de computadora.
ICMP-PARAMETER-PROBLEM 12 0 Los mensajes de error de problemas de parámetros de ICMP
le notifican cuando se presentan parámetros de encabezado
incorrectos y ocasionan que se deseche un paquete
a una red fiable.
El permitir los mensajes de error de problemas de
parámetros de ICMP permite a otros deducir datos sobre su
red.
ICMP-PORT-UNREACH 3 3 Los mensajes de error de puerto inalcanzable de ICMP
indican que los datagramas de procesamiento de puertas de
enlace solicitan determinados puertos que no están
disponibles o son incompatibles en la red.
a la red fiable.
El permitir los mensajes de error de puerto inalcanzable de
ICMP puede permitir a otros determinar qué puertos utiliza
para determinados protocolos.
ICMP-PROTOCOL-UNREACH 3 2 Los mensajes de error de protocolo inalcanzable de ICMP
indican que los datagramas de procesamiento de puertas de
enlace solicitan determinados puertos que no están
disponibles o sean incompatibles en la red.
a la red fiable.
El permitir los mensajes de error de protocolo inalcanzable
de ICMP puede permitir a otros determinar qué protocolos
está ejecutando su red.
ICMP-REDIRECT 5 0 Los mensajes de error de red de desvío de ICMP se envían
por medio de los enrutadores.
a la red fiable.
ICMP-REDIRECT-HOST 5 1 Los mensajes de desvío de ICMP indican los datagramas
destinados para que se envíe el host especificado junto con
otra ruta.
ICMP-REDIRECT-TOS-HOST 5 3 El error de host y tipo de servicio (TOS) de desvío de ICMP es
un tipo de mensaje.
ICMP-REDIRECT-TOS-NET 5 2 El error de red y TOS de desvío de ICMP es un tipo de
mensaje.
114 Servicios

ICMP-SOURCE-QUENCH 4 0 El mensaje de error de desconexión de origen de ICMP
indica que un enrutador no tiene el espacio en búfer
disponible para aceptar colocar en cola y enviar los paquetes
en el siguiente salto.
Al denegar estos mensajes no ayudará ni perjudicará el
rendimiento de red interna.
Al permitir estos mensajes puede permitir que otros
conozcan que un enrutador está congestionado, lo que
convierte en posible objetivo de ataque.
ICMP-SOURCE-ROUTE-FAIL 3 5 Mensaje de error de ruta de origen con fallo de ICMP
Se recomienda denegar estos mensajes de Internet (untrust).
ICMP-TIME-EXCEEDED 11 0 El mensaje de error de tiempo de vida (TTL) excedido de
ICMP indica que un ajuste de TTL de un paquete llegó a cero
antes de que el paquete llegase a su destino. Esto asegura
que los paquetes anteriores se descarten antes de que se
procesen los reenviados.
Se recomienda denegar estos mensajes de una red fiable
fuera de Internet.
ICMP-TIMESTAMP El mensaje de consulta de ICMP-TIMESTAMP proporciona el
Request (petición) 13 0 mecanismo para sincronizar el tiempo y coordinar la
distribución de tiempo en una red grande y diversa.
Ping (ICMP ECHO) 8 0 El capturador de paquetes de Internet es una utilidad para
determinar si el host específico está accesible por su
respuesta de eco de dirección IP .0/0.
Al denegar la funcionalidad de ejecución del comando ping
elimina su posibilidad de revisar para ver si un host está
activo.
Al permitir la ejecución del comando ping puede permitir a
otros ejecutar el rechazo de servicio (DoS) o ataque Smurf.
ICMP-ECHO-FRAGMENT- 11 1 El mensaje de error de tiempo expirado de reensamblaje de
ASSEMBLY-EXPIRE eco de fragmento de ICMP indica que el tiempo de
reensamblaje se excedió.
Se recomienda denegar estos mensajes.
Traceroute Traceroute es una utilidad para indicar la ruta para acceder a
Forward (reenvío) 30 0 un host específico.
Se recomienda denegar esta utilidad de Internet (untrust) a
Discard (descartar) 30 1
su red interna (trust).
Servicios predefinidos relacionados con Internet

La tabla siguiente enumera los servicios predefinidos relacionados con Internet.
Dependiendo de los requisitos de su red, puede seleccionar permitir o denegar
alguno o todos estos servicios. Cada entrada enumera el nombre de servicio, puerto
de recepción predeterminado y descripción del servicio.
Nombre del servicio Puertos Descripción del servicio

AOL 5190-5193 El proveedor de servicio de Internet (ISP)
America Online proporciona Internet, chat y
servicios de mensajes instantáneos.
DHCP-Relay 67 (predet.) Configuración de host dinámico.
Servicios 115

DHCP 68 cliente El protocolo de configuración de host dinámico
67 servidor asigna direcciones de red y entrega los
parámetros de configuración del servidor a los
hosts.
DNS 53 El sistema de nombres de dominio convierte los
nombres de dominio en direcciones IP.
FTP El protocolo de transferencia de archivos (FTP)
FTP-Get 20 datos permite el envío y recepción de archivos entre
equipos. Puede optar por denegar o permitir
FTP-Put 21 control ANY (GET o PUT) o permitir o denegar
selectivamente ya sea GET o PUT. GET recibe los
archivos de otro equipo y PUT envía archivos a
otro equipo.
Le recomendamos denegar los servicios de FTP
de las fuentes no fiables (Internet).
Gopher 70 Gopher organiza y muestra los contenidos de los
servidores de Internet como una lista de
archivos estructurada jerárquicamente.
Le recomendamos denegar el acceso de 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 World Wide
Web (WWW).
Al denegar el servicio de HTTP impide que sus
usuarios puedan ver Internet.
Al permitir el servicio de HTTP permite a sus
hosts fiables ver 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.
El denegar HTTPS impide que sus usuarios
puedan realizar compras en Internet y acceder a
determinados recursos en línea que requieren
del intercambio de contraseñas de seguridad.
Al permitir HTTPS permite a sus hosts fiables
participar en el intercambio de contraseñas,
compras en línea y visitar varios recursos en
línea protegidos que requieren el inicio de
sesión del usuario.
Internet Locator Service — El servicio de localizador de Internet incluye
LDAP, servicio de localizador de 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
grupo de protocolos que se utiliza para acceder a
directorios de información.
116 Servicios

PC-Anywhere — PC-Anywhere es un software de transferencia de
archivos y control remoto.
TFTP 69 TFTP es un protocolo para la transferencia
sencilla de archivos.
WAIS — El servidor de información de área extensa es un
programa que encuentra documentos en
Internet.
Servicios de llamadas de procedimiento remoto de Microsoft

Las siguientes tablas enumeran los servicios de Microsoft predefinidos, los
parámetros asociados con cada servicio y una breve descripción de cada servicio.
Los parámetros incluyen los identificadores únicos universales (UUID) y los puertos
de destino y origen de TCP/UDP. Un UUID es un número único de 128 bit generado
de una dirección de hardware, una marca de hora y valores de inicialización.
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 Server 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 Active Directory Replication Service de Microsoft

MS-AD-DSROLE 1cbcad78-df0b-4934-b558-87839ea501c9 Active Directory DSROLE Service de Microsoft
Servicios 117

MS-AD-DSSETUP 3919286a-b10c-11d0-9ba8-00c04fd92ef5 Active Directory Setup Service de Microsoft
MS-DTC 906b0ce0-c70b-1067-b317-00dd010662da Distributed Transaction Coordinator Service de
Microsoft
MS-EXCHANGE-DATABASE 1a190310-bb9c-11cd-90f8-00aa00466520 Database Service de Microsoft Exchange
MS-EXCHANGE-DIRECTORY f5cc5a18-4264-101a-8c59-08002b2f8426 Directory Service de Microsoft Exchange
f5cc5a7c-4264-101a-8c59-08002b2f8426
f5cc59b4-4264-101a-8c59-08002b2f8426
MS-EXCHANGE-INFO-STORE 0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde Exchange Information Store Service de Microsoft
1453c42c-0fa6-11d2-a910-00c04f990f3b
10f24e8e-0fa6-11d2-a910-00c04f990f3b
1544f5e0-613c-11d1-93df-00c04fd7bd09
MS-EXCHANGE-MTA 9e8ee830-4459-11ce-979b-00aa005ffebe Exchange MTA Service de Microsoft
38a94e72-a9bc-11d2-8faf-00c04fa378ff
MS-EXCHANGE-STORE 99e66040-b032-11d0-97a4-00c04fd6551d Store Service 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 System Attendant Service 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 File Replication Service de Microsoft
d049b186-814f-11d1-9a3c-00c04fc9b232
a00c021c-2be2-11d2-b678-0000f87a8f8e
MS-IIS-COM 70b51430-b6ca-11d0-b9b9-00a0c922e750 COM GUID/UUID Service de Microsoft Internet
a9e69612-b80d-11d0-b9b9-00a0c922e70 Information Server
MS-IIS-IMAP4 2465e9e0-a873-11d0-930b-00a0c90ab17c IMAP4 Service de Microsoft Internet Information

Server
MS-IIS-INETINFO 82ad4280-036b-11cf-972c-00aa006887b0 Internet Information Server Administration Service
de Microsoft
MS-IIS-NNTP 4f82f460-0e21-11cf-909e-00805f48a135 Internet Information Server NNTP Service de
Microsoft
MS-IIS-POP3 1be617c0-31a5-11cf-a7d8-00805f48a135 Internet Information Server POP3 Service de
Microsoft
MS-IIS-SMTP 8cfb5d70-31a4-11cf-a7d8-00805f48a135 Internet Information Server STMP Service de
Microsoft
MS-ISMSERV 68dcd486-669e-11d1-ab0c-00c04fc2dcd2 Inter-site Messaging Service de Microsoft
130ceefb-e466-11d1-b78b-00c04fa32883
MS-MESSENGER 17fdd703-1827-4e34-79d4-24a55c53bb37 Microsoft Messenger Service
5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc
118 Servicios

MS-MQQM fdb3a030-065f-11d1-bb9b-00a024ea5525 Windows Message Queue Management Service de
76d12b80-3467-11d3-91ff-0090272f9ea3 Microsoft
1088a980-eae5-11d0-8d9b-00a02453c33
5b5b3580-b0e0-11d1-b92d-0060081e87f0
41208ee0-e970-11d1-9b9e-00e02c064c39
MS-NETLOGON 12345678-1234-abcd-ef00-01234567cffb Microsoft Netlogon Service
MS-SCHEDULER 1ff70682-0a51-30e8-076d-740be8cee98b Microsoft Scheduler Service
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 WINS de Microsoft Service
811109bf-a4e1-11d1-ab54-00a0c91e9b45
Protocolos de enrutamiento dinámico

Dependiendo de los requisitos de su red, puede seleccionar permitir o denegar los
mensajes generados de y los paquetes de estos protocolos de enrutamiento
dinámico. La siguiente tabla enumera cada protocolo de enrutamiento dinámico
compatible por nombre, puerto y descripción.
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 conexiones
de estado común.
BGP 179 BGP es un protocolo de enrutamiento entre
dominios/exterior.
Vídeo de secuencia
La siguiente tabla enumera cada servicio de vídeo de secuencia compatible por
nombre e incluye el puerto predeterminado y la descripción. Dependiendo de los
requisitos de su red, puede seleccionar permitir o denegar alguno o todos estos
servicios.
Servicios 119
Servicio Puerto Descripción

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

La siguiente tabla enumera cada nombre completo, parámetros y nombre del
servicio de Sun Remote Procedure Call Application Layer Gateway (RPC ALG).
Números del
Servicio programa Nombre completo
SUN-RPC-PORTMAPPER 111 Protocolo de asignación de puertos Sun
100000 RPC
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
120 Servicios
Números del
Servicio programa Nombre completo
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 Servicio de asignación de página amarilla
SUN RPC Yellow Page Bind Service
Servicios de túnel y seguridad

La siguiente tabla enumera cada servicio compatible y proporciona los puertos y
una descripción de cada entrada.

IKE UDP origen IKE es un protocolo para obtener el material
1-65535; UDP clave autenticado para el uso con ISAKMP.
destino 500 Cuando configura IKE automático, puede
4500 (se utiliza seleccionar de tres propuestas de fase 1 o fase 2
para NAT ya predefinidas:
trasversal) Estándar: AES y 3DES
Básicas: DES y dos tipos diferentes de
algoritmos de autenticación
Compatible: cuatro algoritmos de
encriptación y autenticación que se utilizan
comúnmente
L2TP 1723 L2TP combina el protocolo de encapsulamiento
de punto a punto (PPTP) con la capa dos de
reenvío (L2F) para el acceso remoto.
PPTP — El protocolo de encapsulamiento de punto a
punto permite a las corporaciones ampliar sus
propias redes privadas a través de los túneles
privados en Internet público.
Servicios relacionados con IP

La siguiente tabla enumera los servicios predefinidos relacionados con IP. Cada
entrada incluye el puerto predeterminado y una descripción del servicio.

Any — Cualquier servicio
TCP-ANY 1-65535 Cualquier protocolo que utilice el protocolo de
control de transporte
TCPMUX puerto 1
UDP-ANY 137 Cualquier protocolo que utilice el protocolo de
datagrama de usuario
Servicios 121
Servicios de mensajes instantáneos

La siguiente tabla enumera los servicios de mensajes predefinidos de Internet. Cada
entrada incluye el nombre del servicio, los puertos asignados o predeterminados y
una descripción del servicio.

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

NBNAME 137 El servicio de nombres NetBIOS muestra todos los
paquetes de nombre de NetBIOS enviados en UDP
puerto 137.
NDBDS 138 El servicio de datagrama de NetBIOS, publicado por
IBM, proporciona servicios sin conexión (datagrama)
a los PC conectados con un medio de difusión para
localizar los recursos, iniciar sesiones y terminar
sesiones. No es fiable y los paquetes no tienen
secuencia.
NFS — El sistema de archivos de red utiliza UDP para
permitir a los usuarios de red acceder a los archivos
compartidos almacenados en las computadoras de
diferentes tipos. SUN RPC es un bloque de
construcción de NFS.
NS Global — NS-Global es el protocolo de administración central
para los dispositivos de VPN/cortafuegos de Juniper
Networks.
NS Global PRO — NS Global-PRO es el sistema de supervisión en escala
para la familia de dispositivos de VPN/cortafuegos de
Juniper Networks.
NSM — Administración de seguridad de NetScreen
122 Servicios

NTP 123 El protocolo de tiempo de red proporciona una
manera para que las computadoras se sincronicen a
un tiempo de referencia.
RLOGIN 513 RLOGIN inicia una sesión de terminal en un host
remoto.
RSH 514 RSH ejecuta un comando shell en un host remoto.
SNMP 161 El protocolo de administración de red sencillo es un
conjunto de protocolos para administrar las redes
complejas.
SQL*Net V1 66 SQL*Net Versión 1 es un lenguaje de base de datos
que permite la creación, acceso, modificación y
protección de datos.
SQL*Net V2 66 SQL*Net Versión 2 es un lenguaje de base de datos
que permite la creación, acceso, modificación y
protección de datos.
MSSQL 1433 (caso Microsoft SQL es una herramienta del servidor de
predet.o) base de datos de propiedad que permite la creación,
acceso, modificación y protección de datos.
SSH 22 Shell seguro es un programa para registrarse en otra
computadora sobre una red a través de la
autenticación sólida y las comunicaciones seguras en
un canal inseguro.
SYSLOG 514 Syslog es un programa de UNIX que envía mensajes
al registrador del sistema.
Talk 517-518 Talk es un programa de comunicación visual que
copia líneas de su terminal a una determinada de
otro usuario.
Telnet 23 Telnet es un programa de UNIX que proporciona un
método estándar de realización de interfaces de
dispositivos de terminal y procesos orientados a
terminales entre sí.
WinFrame — WinFrame es una tecnología que permite que
puedan ejecutar aplicaciones de Windows los
usuarios que se encuentran en equipos que no
cuentan con Windows.
X-Windows — X-Windows es el sistema de gráficos y ventanas en el
que se basan Motif y OpenLook.
Servicios de correo
La siguiente tabla enumera los servicios predefinidos de correo. Cada uno incluye el
nombre del servicio, el número de puerto asignado o predeterminado y una
Servicios 123

IMAP 143 El protocolo de acceso de mensajes de Internet es
un protocolo que se utiliza para recuperar los
mensajes.
Mail (SMTP) 25 El protocolo de transferencia de correo sencillo es
un protocolo para el envío de mensajes entre
servidores.
POP3 110 El protocolo de oficina postal es un protocolo que
se utilizar para recuperar correo electrónico.
Servicios de UNIX
La siguiente tabla enumera los servicios predefinidos de UNIX. Cada entrada
incluye el nombre del servicio, el puerto asignado o predeterminado y una

FINGER 79 Finger es un programa de UNIX que proporciona
información sobre los usuarios.
UUCP 117 El protocolo de copia de Unix a Unix (UUCP) es
una utilidad de UNIX que permite la transferencia
de archivos entre dos computadoras sobre una
conexión directa de módem o serie.
Servicios varios
La siguiente tabla enumera los servicios varios predefinidos. Cada entrada incluye el
nombre del servicio, el puerto asignado o predeterminado y una descripción del
servicio.

CHARGEN 19 El protocolo del generador de caracteres es
una herramienta de medida y depuración con
base en TCP o UDP.
DISCARD 9 El protocolo de descarte es un protocolo de
capas de aplicación que describe un proceso
para descartar los datos de TCP o UDP
enviados al puerto 9.
IDENT 113 El protocolo de identificación es un protocolo
de capa de aplicación de TCP/IP que se utiliza
para la autenticación de clientes de TCP.
LPR 515 listen; El protocolo de demonio de impresora de
721-731 rango línea es un protocolo con base en TCP que se
de origen utiliza para los servicios de impresión.
(inclusive)
RADIUS 1812 El servicio remoto de autentificación de
usuarios de acceso telefónico es un programa
del servidor que se utiliza para propósitos de
autenticación y contabilidad.
124 Servicios

SQLMON 1434 (Puerto de Supervisor de SQL (Microsoft)
supervisión de
SQL)
VNC 5800 La computación de red virtual facilita la
visualización e interacción con otra
computadora en el dispositivo móvil
conectada a Internet.
WHOIS 43 El protocolo de servicio de directorio de red es
una manera de buscar los nombres de
dominio.
IPSEC-NAT — IPSEC-NAT permite la Traducción de
direcciones de red para los paquetes de
ISAKMP y ESP.
SCCP 2000 El protocolo de control de llamadas de
estación de 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 los servicios de voz sobre
Internet e incluye el protocolo de inicio de
sesión (SIP) y H.323.
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
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.
Servicios 125
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 nomenclatura y conjuntos de caracteres” en la
página xii.
Agregar 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 petición 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
Objects > Services > Custom > New: Introduzca los siguientes datos y haga
clic en OK:
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
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.
Modificar un servicio personalizado

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

servicio personalizado sin eliminar el servicio del libro de servicios:
WebUI
Objects > Services > Custom > Edit (para cust-telnet): Introduzca los

CLI
set service cust-telnet clear
set service cust-telnet + tcp src-port 1-65535 dst-port 23230-23230
save
Eliminar un servicio personalizado

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

El valor de tiempo de espera que establece para un servicio determina el tiempo de
sesión. Puede establecer el umbral de tiempo de espera para un servicio
personalizado o predefinido, puede utilizar el tiempo de espera predeterminado de
servicio, especificar un tiempo de espera personalizado o no utilizar tiempo de
espera en absoluto. El comportamiento de tiempo de espera de servicio es idéntico
a los dominios de seguridad (vsys) de los sistemas virtuales como el nivel de raíz.
Buscar y configurar el tiempo de espera de servicio

Los valores de tiempo de espera de servicio se almacenan en la base de datos de
entrada de servicio y en las tablas de tiempo de espera con base en el puerto de
UDP y TCP vsys correspondientes. Cuando establece un valor de tiempo de espera
de servicio, el dispositivo de seguridad actualiza estas tablas con el nuevo valor.
También existen valores de tiempo de espera predeterminados en la base de datos
de entrada de servicio, los cuales se toman de los servicios predefinidos. Puede
establecer un tiempo de espera pero no puede alterar los valores predeterminados.
Los servicios con entradas de reglas múltiples comparten el mismo valor de tiempo
de espera. Si varios servicios comparten el mismo rango de de puerto de destino y
protocolo, todos los servicios comparten el último valor de tiempo de espera
configurado.
Para las entradas de servicio individuales, la búsqueda de tiempo de espera de

servicio se realiza como se muestra a continuación:
Servicios 127
1. El tiempo de espera especificado en la base de datos de entrada del servicio, si

está configurado.
2. El tiempo de espera predeterminado en la base de datos de entrada del

servicio, si está especificado en el servicio predefinido.
3. La tabla de tiempo de espera predeterminada con base en el protocolo.
Figura 61: Tabla de tiempo de espera predeterminado con base en el protocolo
Tiempo de espera
Protocolo predeterminado (minutos)
TCP 30
UDP 1
ICMP 1
OSPF 1
Otros 30
Para los grupos de servicio, incluso los grupos ocultos creados en configuraciones
de directivas de varias celdas y para el servicio predefinido “ANY” (si no está
establecido el tiempo de espera), la búsqueda de tiempo de espera de servicio se
realiza como se muestra a continuación:
1. La tabla de tiempo de espera con base en puerto UDP y TCP de vsys, si está
establecido el tiempo de espera.
2. La tabla de tiempo de espera predeterminado con base en el protocolo.
Contingencias
Cuando se establecen los tiempos de espera, esté al tanto de lo siguiente:
Si un servicio contiene varias entradas de reglas de servicio, todas las entradas

de reglas comparten el mismo tiempo de espera. La tabla de tiempo de espera
se actualiza para cada entrada de regla que concuerda con el protocolo (para
UDP y TCP, otros protocolos utilizan el predeterminado). Necesita definir el
tiempo de espera de servicio únicamente una 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 se configuran varios servicios con el mismo protocolo y los puertos de

destino se solapan, el tiempo de espera de servicio más recientemente
configurado sobrescribe los otros en la tabla con base en puertos. 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 de puerto de destino para telnet-1 (2100-2148) se solapan con los
de ftp-1 (2121) y usted definió telnet-1 después de definir ftp-1.
128 Servicios
Para modificar un tiempo de espera de servicio cuando varios servicios utilizan

el mismo protocolo y un rango de puerto de destino superpuesto, debe
desactivar el servicio y restablecerlo con el nuevo valor de tiempo de espera.
Esto se debe a que, durante el reinicio, los servicios se cargaron de acuerdo con
el tiempo de creación, no con el tiempo de modificación.
Para evitar la aplicación no intencionada del tiempo de espera incorrecto a un

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

base en el protocolo predeterminado en la base de datos de entradas de
servicio y los valores de tiempo de espera tanto en las tablas de tiempo de
espera con base en puerto y de entrada de servicio se actualizan con el valor
predeterminado.
Si el servicio modificado tiene puertos de destino superpuestos con otros

servicios, es posible que el tiempo de espera con base en el protocolo
predeterminado no sea el valor deseado. En ese caso, reinicie el dispositivo de
seguridad o establezca el tiempo de entrega de servicio de nuevo para que el
tiempo de espera deseado tenga vigencia.
Cuando modifica un servicio predefinido y lo reinicia, es posible que el servicio

modificado no sea el último en la configuración. Esto se debe a que los
servicios predefinidos se cargaron antes que los servicios personalizados y
cualquier cambio realizado a un servicio personalizado, incluso si se hubiera
realizado anteriormente, se mostrará como último el cambio de servicio
predefinido cuando reinicialice.
Por ejemplo, si crea el siguiente servicio:
set service my_service protocol tcp dst-port 179-179 timeout 60
y posteriormente modifica el tiempo de espera del servicio predefinido BGP

como se muestra a continuación:
set service bgp timeout 75
el servicio BGP utilizará el valor de tiempo de espera de 75 minutos, ya que

ahora está escrito en la base de datos de la entrada de servicio. Pero el tiempo
de espera para el puerto 179, el puerto que utiliza BGP, también se cambió a 75
en la tabla de tiempo de espera con base en el puerto de TCP. Después de
reiniciar, el servicio de BGP continuará con el uso del tiempo de espera de 75
minutos, como un servicio individual, que obtendrá de la base de datos de
entrada de servicio. Pero el tiempo de espera en la tabla con base en el puerto
TCP para el puerto 179 será ahora de 60. Puede verificar esto introduciendo el
comando get service bgp.
Esto no tiene efecto en los servicios individuales. Pero si agrega BGP o

mi_servicio a un grupo de servicios, el valor del tiempo de espera de 60
minutos se utilizará para el puerto de destino 179. Esto se debe a que el
tiempo de espera del grupo de servicio se toma de la tabla del tiempo de espera
con base en el puerto, si es que hay uno establecido.
Para que no sea impredecible, cuando modifica un tiempo de espera de

servicio predefinido, puede crear un servicio similar, por ejemplo:
set service my-bgp protocol tcp dst-port 179-179 timeout 75

Servicios 129
Ejemplo
En el siguiente ejemplo cambiará el umbral del tiempo de espera para el
servicio predefinido FTP a 75 minutos:
WebUI
Objects > Services > Predefined > Edit (FTP): Introduzca los siguientes datos
y haga clic en OK:
CLI
set service FTP timeout 75
save
Definir un servicio de protocolo de mensaje de control de Internet personalizado

ScreenOS es compatible con el protocolo de mensajes de control de Internet (ICMP)
y admite diversos mensajes ICMP, como los 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”)
NOTA: Para obtener más información sobre los tipos y códigos de ICMP, consulte
RFC 792, Internet Control Message Protocol.
Los tipos de mensajes ICMP también pueden tener un código de mensaje. El código
proporciona información más específica sobre el mensaje, como se muestra en la
Tabla 14.
Tabla 14: Descripciones de mensaje
Tipo de mensaje Código de mensaje

5 = Reenviar 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

excedido
1 = Tiempo de reensamblaje de fragmentos excedido
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.
130 Servicios
WebUI
Objects > 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
Puerta de enlace “Remote Shell” en la capa de aplicación

La puerta de enlace “Remote Shell” en la capa de aplicación (RSH ALG) permite a
los usuarios autenticados ejecutar comandos shell en hosts remotos. Los
dispositivos Juniper Networks admiten el servicio RSH en los modos Transparent
(L2), Route (L3) y NAT, pero los dispositivos no admiten la traducción de puertos en
el tráfico RSH.
Puerta de enlace de llamada de procedimiento remoto de Sun en la capa de aplicación

La llamada de procedimiento remoto de Sun, también conocido como Open
Network Computing Remote Procedure (ONC 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 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, permitiendo y denegando el tráfico según una directiva que usted
configure. La puerta de enlace de la capa de aplicación (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. La 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.
Servicios 131
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.
Personalizar los servicios 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 de servicio de sun rpc 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
denegará 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
Objects > Services > Sun RPC Services > New: Introduzca los siguientes
datos y haga clic en Apply:
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
132 Servicios
Personalizar la puerta de enlace de la capa de aplicaciones del procedimiento de

llamadas remotas de Microsoft
Microsoft Remote Procedure Call (MS RPC) es la implementación de Microsoft del
RPC del entorno de computación distribuida (DCE). Como Sun RPC (consulte
“Puerta de enlace de llamada de procedimiento remoto de Sun en la capa de
aplicación” en la página 131), 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 enlace
Endpoint Mapper está definido para asignar el UUID específico a una dirección de
transporte.
Los dispositivos de seguridad de Juniper Networks admiten MS RPC como servicio

predefinido, permitiendo y denegando el tráfico basándose en una directiva que
usted configure. 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. La ALG también admite el modo de
ruta 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 UUID. El servicio MS Exchange Info Store,
por ejemplo, utiliza los cuatro UUID 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. Basándose en estos cuatro UUID, la ALG asignará los números de programa
a puertos TCP/UDP negociados dinámicamente y permitirá o denegará 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
Objects > Services > MS RPC: Introduzca los siguientes datos y haga clic en
Apply:
Service Name: my-ex-info-store

UUID: 0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde
UUID: 1453c42c-0fa6-11d2-a910-00c04f990f3b
Servicios 133
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
Puerta de enlace de la capa de aplicación del protocolo de secuencias en tiempo real

El protocolo de secuencias en tiempo real (RTSP) es un protocolo a nivel 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 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 (SDP) como medios
para proporcionar información al cliente para el control agregado de una
presentación compuesta por secuencias de unos 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 clips
almacenados.
Los dispositivos de seguridad de Juniper Networks admiten RTSP como servicio y

permiten o deniegan el tráfico RTSP basándose en una directiva que usted
configure. La ALG es necesaria 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. La ALG realiza el seguimiento de los números de puerto
asignados dinámicamente y abre los correspondientes orificios. En el modo NAT,
ALG traduce los puertos y direcciones IP si fuera necesario. Los dispositivos de
seguridad admiten RTSP en el modo de ruta, modo transparente y tanto en el modo
NAT con base en directivas como en interfaces.
La Figura 62 en la página 135 muestra un diagrama de una sesión típica de RTSP. 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 admite 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 14 y 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
134 Servicios
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.
Figura 62: Sesión de RTSP típica
Cliente de RealPlayer Dispositivo de seguridad Servidor RealMedia

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

La tabla siguiente 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
requerido, 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 135
Tabla 15: Métodos de petición RTSP
Método Sentido Objeto Requisito

OPTIONS Cliente a servidor Presentación, secuencia Cliente a servidor
requerido
Servidor a cliente Presentación, secuencia Servidor a cliente
opcional
DESCRIBE Cliente a servidor Presentación, secuencia Recomendado
ANNOUNCE Cliente a servidor Presentación, secuencia Opcional
Servidor a cliente Presentación, secuencia
SETUP Cliente a servidor Secuencia Requerido
GET_PARAMETER Cliente a servidor Presentación, secuencia Opcional
Servidor a cliente
SET_PARAMETER Cliente a servidor Presentación, secuencia Opcional
Servidor a cliente
PLAY Cliente a servidor Presentación, secuencia Requerido
PAUSE Cliente a servidor Presentación, secuencia Recomendado
RECORD Cliente a servidor Presentación, secuencia Opcional
REDIRECT Servidor a cliente Presentación, secuencia Opcional
TEARDOWN Cliente a servidor Presentación, secuencia Requerido
Definición de los métodos:
OPTIONS: El cliente consulta al servidor qué características de audio o vídeo

admite y otros datos como el nombre y la versión del servidor y la
identificación de la sesión.
DESCRIBE: Para el intercambio de los datos de inicialización de 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: El cliente utiliza este método para publicar una descripción de la

presentación o del objeto multimedia identificado por la URL solicitada. El
servidor utiliza este método para actualizar la descripción de la sesión en
tiempo real.
SETUP: El cliente especifica los mecanismos de transporte aceptables, como los

puertos en los que recibirá la secuencia de medios y el protocolo de transporte.
GET_PARAMETER: Recupera el valor de una presentación o el parámetro de la

secuencia especificado en URL. Este método se puede utilizar sin cuerpo de
entidad para verificar la presencia del cliente o del servidor. Para verificar si el
cliente o servidor está “vivo” también se puede utilizar el comando “ping”.
SET_PARAMETER: El cliente utiliza este método para establecer el valor de un

parámetro de la presentación o secuencia especificado por el URI. Por
cuestiones relacionadas con el cortafuegos, este método no se puede utilizar
para establecer parámetros de transporte.
136 Servicios
PLAY: Ordena al servidor que comience a enviar datos usando el mecanismo

especificado en SETUP. El cliente no enviará peticiones PLAY hasta que todas
las peticiones SETUP sean correctas. El servidor pone en una cola las peticiones
PLAY por orden 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
tiempo, 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: Detiene temporalmente la transmisión de una 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 petición PAUSE descarta todas las peticiones PLAY
existentes en la cola.
RECORD: Comienza a grabar el rango de medios definido en la 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: Informa al cliente que debe conectarse a otro 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 para este URL, el
cliente debe generar una petición TEARDOWN para la sesión actual y un SETUP
para la nueva sesión.
TEARDOWN: Detiene la entrega de la secuencia del URL dado y libera 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
están clasificados de la siguiente manera:
Informativo (100 a 199): petición recibida y en proceso
É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 y no se

puede llevar a cabo
Error del servidor (500 a 599): el servidor no pudo cumplir una petición
aparentemente válida
Servicios 137
La tabla siguiente 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 16: 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
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,
Real Time Streaming Protocol (RTSP).
138 Servicios
Configurar 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 ethernet3 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 63: Dominio privado RTSP
ethernet1 ethernet3
10.1.1.1 1.1.1.1

Dispositivo de seguridad
LAN LAN
Servidor de medios Dispositivo virtual

MIP en ethernet3 Client1.1.1.5
10.1.1.3
1.1.1.3 -> 10.1.1.3
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Manage IP: 10.1.1.2
haga clic en Apply:
Zone Name: Untrust

Manage IP: 1.1.1.2
2. Direcciones
en OK:
Address Name: media_server

Zone: Trust
en OK:
Address Name: client

Zone: Untrust
Servicios 139
3. MIP
Network > Interfaces > Edit (para ethernet3) > MIP > New: Introduzca los
Mapped IP: 1.1.1.3

4. Directiva
Policies > (From: Untrust, To: Trust) > New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), cliente
Address Book Entry: (seleccione), MIP(1.1.1.3)
Service: RTSP
Action: Permit
CLI
1. Interfaces
set interface ethernet1 trust
set interface ethernet1 ip 10.1.1.1
set interface ethernet3 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 ethernet3 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
Configurar 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. Usted colocará un conjunto de DIP en la interfaz ethernet3 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 64: Dominio público RTSP
ethernet1 ethernet3
Zona Trust 10.1.1.1 1.1.1.1 Zona Untrust
LAN LAN
Conjunto de DIP
Cliente en ethernet3 Servidor de medios
10.1.1.3 1.1.1.5 a 1.1.1.50 1.1.1.3
140 Servicios
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Manage IP: 10.1.1.2
haga clic en Apply:
Zone Name: Untrust

Manage IP: 1.1.1.2
2. Direcciones
en OK:
Address Name: client

Zone: Trust
en OK:
Address Name: media_server

Zone: Untrust
3. Conjunto de DIP
Network > Interfaces > Edit (para ethernet3) > DIP > New: Introduzca los
ID: 5
IP Address Range: (seleccione) 1.1.1.5 ~ 1.1.1.50
Port Translation: (seleccione)
4. Directiva
Policies > (From: Trust, To: Untrust) > New: Introduzca los siguientes datos y
haga clic en OK:
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:
Servicios 141
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 ethernet3 dip 5 1.1.5 1.1.1.50
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 características:
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.
142 Servicios
Crear un grupo de servicios

En este ejemplo creará un grupo de servicios llamado “grp1” que incluirá los
servicios IKE, FTP y LDAP.
WebUI
Objects > 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

Seleccione FTP y utilice el botón << para mover el servicio de la columna

Seleccione LDAP y utilice el botón << para mover el servicio de la

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 estén autoincluidos en la lista de referencias.
Modificar un grupo de servicios

En este ejemplo cambiará los miembros del grupo de servicios llamado “grp1” que
creó en “Crear un grupo de servicios” en la página 143. Eliminará los servicios IKE,
FTP y LDAP, y agregará HTTP, FINGER e IMAP.
WebUI
Objects > 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 Finger y utilice el botón << para mover el servicio de la

Servicios 143
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
Eliminar un grupo de servicios

En este ejemplo eliminará un grupo de servicios denominado “grp1”.
WebUI
Objects > 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-22). 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 conjunto 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 IP 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.
144 Conjuntos de IP dinámicas

Figura 65: Interfaces de DIP
A la zona DMZ
A la zona Untrust
Túneles VPN
A la zona Trust
Cortafuegos
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
ethernet1 ethernet2 ethernet3 Túnel Túnel
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

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

Utilizando la traducción de direcciones de puertos (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 puerto asignados con el fin de distinguir qué sesión
pertenece a qué host. Con PAT habilitada, puede haber hasta unos 64.500 hosts
compartiendo una misma dirección IP.
Algunas aplicaciones, como la interfaz de usuario extendida para la interfaz de

usuario extendida NetBIOS (NetBEUI) y el servicio de nombres de Internet de
Windows (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) al aplicar 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 145

Crear 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 solapamiento 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.
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 “Puntos VPN con
direcciones superpuestas” en la página 5-141.
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 (for tunnel.1) > DIP > New: Elimine la
selección de la casilla de verificación Port Translation, luego haga clic en OK.
(CLI) set interface tunnel.1 dip 5 10.10.1.2 10.10.1.2 fix-port
Modificar 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 luego 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 (for tunnel.1) > DIP > Edit (for ID 5): Introduzca
los siguientes datos y haga clic en OK:
IP Address Range: 10.20.1.2 ~ 10.20.1.10
CLI
unset interface tunnel.1 dip 5
save
Direcciones DIP “sticky”

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 asigna la misma dirección IP de un

conjunto de DIP a las diferentes sesiones simultáneas de un host, puede habilitar la
característica “sticky” de la dirección DIP ejecutando el comando CLI set dip sticky.
Usar DIP en otra subred

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 de interfaz
extendida. 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 17: Direcciones IP oficiales autorizadas
Dirección IP asignada (de ISP) Dirección IP autorizada (de la sede central)

Utilizada para la interfaz física Utilizada para la DIP de la interfaz extendida
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á ethernet1 a la zona Trust y le asignará la dirección IP 10.1.1.1/24.
Enlazará ethernet3 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 ethernet3:
Oficina A: IP de la interfaz extendida 211.10.1.10/24; conjunto de 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,
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 66: DIP bajo otra subred
Sede 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 punto Línea punto
a punto a punto
Internet
Zona Untrust, ethernet3
Zona Untrust, ethernet3 El ISP asigna 201.1.1.1/24
El ISP asigna 195.1.1.1/24 (interfaz física)
(interfaz física) ISP ISP
HQ autoriza 211.20.1.1/24
HQ autoriza 211.10.1.1/24 (interfaz extendida)
(interfaz extendida)
Puerta de enlace
Puerta de enlace predeterminada 201.1.1.254
predeterminada 195.1.1.254
Zona Trust, ethernet1 Oficina A Oficina B Zona Trust, ethernet1
10.1.1.1/24 Zona Trust Zona Untrust 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
haga clic en OK:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

Interface Mode: Route

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
en OK:
Address Name: HQ
Zone: Untrust
3. Ruta

Gateway IP address: 195.1.1.254
4. Directivas
haga clic en OK:
Source Address:
Service: ANY
Action: Permit
haga clic en OK:
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
haga clic en OK:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
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
en OK:
Address Name: HQ
Zone: Untrust
3. Ruta

4. Directivas
haga clic en OK:
Source Address:
Service: ANY
Action: Permit
haga clic en OK:

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 ethernet3 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 ethernet3 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

Utilizar una DIP en una interfaz de bucle invertido

Una interfaz de bucle invertido (loopback) es una interfaz lógica que siempre se
encuentra en estado activo mientras el dispositivo en el que reside permanezca
encendido. 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 loopback 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 ninguna 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 loopback, consulte “Interfaces de
bucle invertido (loopback)” en la página 60.
La principal aplicación de colocar 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 67: Bucle invertido de DIP
Traducción de direcciones de origen utilizando un

conjunto de DIP en una interfaz de bucle invertido
IP de origen IP de destino IP de origen IP de destino
DATOS DATOS
1.3.3.2 2.2.2.2 1.3.3.2 2.2.2.2
ethernet2 ethernet3
1.1.1.1/24 1.2.2.1/24
Interfaz de bucle Conjunto de DIP

Sea cual sea la interfaz de invertido 1.3.3.2 - 1.3.3.2
loopback 1
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 ethernet1
definido en la interfaz 10.1.1.1/24
loopback.1.
Host A Host B
IP de origen IP de destino 10.1.1.6 IP de origen IP de destino
DATOS 10.1.1.5 DATOS
10.1.1.5 2.2.2.2 10.1.1.6 2.2.2.2
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:
ethernet2, 1.1.1.1/24, ISP-1
ethernet3, 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á ethernet1 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 ethernet1 y ethernet2 miembros del grupo loopback
correspondiente a “loopback.1”.
Definirá una dirección “r-office” con la dirección IP 2.2.2.2/32 para la oficina

remota. También definirá rutas predeterminadas para las interfaces ethernet1 y
ethernet2, 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 cualquiera de las dos rutas.
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 68: Directiva de bucle invertido de DIP
r-office
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
ethernet2, 1.1.1.1/24 ethernet3, 1.2.2.1/24

puerta de enlace puerta de enlace 1.2.2.250
El dispositivo de
1.1.1.250
seguridad traduce Conjunto de DIP con
todas las direcciones ID 10
IP de origen de los (en Loopback.1)
paquetes destinados 1.3.3.2 – 1.3.3.2
a 2.2.2.2 de 10.1.1.X ethernet110.1.1.1/24 Loopback.1
a 1.3.3.2, Modo NAT Zona Untrust
independientemente 1.3.3.1/30
de la interfaz de Zona
salida utilizada. 10.1.1.0/24 Trust
IP de origen IP de destino DATOS

10.1.1.X 2.2.2.2

WebUI
1. Interfaces
haga clic en OK:

Zone: Untrust (trust-vr)
haga clic en OK:
As member of loopback group: loopback.1

Zone Name: Trust
Interface Mode: NAT
haga clic en OK:
As member of loopback group: loopback.1

Zone Name: Untrust
haga clic en OK:
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
en OK:
Address Name: r-office

Zone: Untrust

4. Rutas


5. Directiva
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), r-office
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 ethernet2 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 r-office 2.2.2.2/32
4. Rutas
5. Directiva
set policy from trust to untrust any r-office any nat src dip-id 10 permit
save
Crear un grupo de DIP

Cuando usted agrupa dos dispositivos de seguridad en un clúster redundante para
proporcionar alta disponibilidad (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 (NAT) si se utiliza un rango de IP
dinámico (DIP) situado en una 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 69: 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

ethernet2 ethernet3:1
1.1.1.1/24 1.1.1.2/24
ID de conjunto de DIP
1.1.1.101 – 1.1.1.150
VSD VSD de
maestro 0 Dispositivo ATX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK
respaldo 1
Clúster NSRP Grupo VSD: 0 Grupo VSD: 1
VSD de VSD
respaldo 0 Dispositivo BTX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK
maestro 1
VSI de la zona Trust ethernet1 ethernet1: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 (respaldo del grupo Zona Trust
VSD 1) descarta el tráfico recibido en ethernet1
(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 aunque en la directiva se especifique el grupo de DIP.
Figura 70: Crear dos conjuntos de DIP en un grupo de 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 ID de conjunto de DIP
1.1.1.151 – 210.1.1.200 1.1.1.101 – 1.1.1.150
VSI de la zona Untrust 1.1.1.1/24 1.1.1.2/24
Grupo de DIP 9
VSD VSD de
Dispositivo A respaldo 1
maestro 0
TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK
Clúster NSRP Grupo VSD: 0 Grupo VSD: 1
VSD de VSD
respaldo 0 Dispositivo B TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK TX/RX LINK
maestro 1
VSI de la zona Trust

Combinando los conjuntos de DIP situados en ambas 10.1.1.1/24 10.1.1.2/24
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 que no se hace referencia a un conjunto de DIP Zona Trust
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 ethernet3 y DIP 6

(1.1.1.30 – 1.1.1.39) en ethernet3: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 ethernet3 1.1.1.1/24 (grupo VSD 0)
VSI de la zona Untrust ethernet3:1 1.1.1.2/24 (grupo VSD 1)
VSI de la zona Trust ethernet1 10.1.1.1/24 (grupo VSD 0)
VSI de la zona Trust ethernet1:1 10.1.1.1/24 (grupo VSD 1)

Presuponiendo que ya configuró previamente los dispositivos A y B en un clúster

NSRP, creó el grupo VSD 1 (ScreenOS crea automáticamente el grupo VSD 0 cuando
se coloca un dispositivo en un clúster NSRP), y configuró las interfaces
mencionadas. (Para obtener más información sobre la configuración de dispositivos
de seguridad para NSRP, consulte 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 ethernet3:1) > DIP > New: Introduzca los
ID: 6
IP Address Range: 1.1.1.30 – 1.1.1.39
NOTA: En el momento de publicar esta versión, con CLI solamente se puede definir un
grupo de DIP.
2. Directiva
haga clic en OK:
Source Address:
Service: ANY
Action: Permit
NAT:
DIP On: (seleccione), 7
CLI
1. Conjuntos de DIP
set interface ethernet3 dip 5 1.1.1.20 1.1.1.29
set interface ethernet3: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. Directivas
set policy from trust to untrust any any any nat src dip-id 7 permit
save

Configurar una programación recurrente

Una programación 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 programación, 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 programación. 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 de fin.
Puede especificar hasta dos periodos de un mismo día.
Once: Habilite esta opción cuando desee que la programación se ejecute y

termine una sola vez.
mm/dd/yyyy hh:mm: Debe introducir tanto la fecha y hora de inicio como la

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 programación 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.
WebUI
1. Programación
Objects > Schedules > New: Introduzca los siguientes datos y haga clic en OK:
Schedule Name: After Hours

Comment: For non-business hours
Recurring: (seleccione)
Periodo 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
160 Configurar una programación recurrente

Periodo 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
en OK:
Address Name: Tom

Comment: Temp
Zone: Trust
3. Directiva
haga clic en OK:
Name: No Net
Source Address:
Address Book Entry: (seleccione), Tom
Service: HTTP
Action: Deny
Schedule: After Hours
Configurar una programación recurrente 161

CLI
1. Programación
set schedule “after hours” recurrent sunday start 00:00 stop 23:59
set schedule “after hours” recurrent monday start 00:00 stop 06:00 start 17:00
stop 23:59
set schedule “after hours” recurrent tuesday start 00:00 stop 06:00 start 17:00
stop 23:59
set schedule “after hours” recurrent wednesday start 00:00 stop 06:00 start
17:00 stop 23:59
set schedule “after hours” recurrent thursday start 00:00 stop 06:00 start 17:00
stop 23:59
set schedule “after hours” recurrent friday start 00:00 stop 06:00 start 17:00
stop 23:59
set schedule “after hours” recurrent saturday start 00:00 stop 23:59 comment
“for non-business hours”
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 “after hours”
save
162 Configurar una programación recurrente

Capítulo 6
Directivas
El comportamiento predeterminado de un dispositivo de seguridad es rechazar

todo el tráfico entre zonas de seguridad (tráfico interzonal) y, con excepción del
tráfico dentro de la zona Untrust, permitir todo el tráfico entre interfaces asociadas
a una misma zona (tráfico intrazonal). Para permitir que determinado tráfico
interzonal pase por un dispositivo de seguridad, debe crear directivas interzonales
que tengan preferencia sobre el comportamiento predeterminado. De forma
análoga, para impedir que determinado tráfico intrazonal pueda pasar por un
dispositivo de seguridad, debe crear las correspondientes directivas intrazonales.
NOTA: De forma predeterminada, los dispositivos NetScreen-5XP y NetScreen-5XT

permiten el tráfico desde la zona Trust a la zona Untrust.
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. Contiene las siguientes
secciones:
“Elementos básicos” en la página 164
“Tres tipos de directivas” en la página 165
“Listas de conjuntos de directivas” en la página 167
“Definición de directivas” en la página 168
“Directivas aplicadas” en la página 179
NOTA: Si configura el enrutamiento multicast en un dispositivo de seguridad, puede que

tenga que configurar directivas multicast. Para obtener información sobre
directivas multicast, consulte “Directivas multicast” en la página 7-143.
163
Elementos básicos
Una directiva permite, deniega o canaliza por un túnel 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, son los
siguientes:
NOTA: La acción “tunnel” (túnel VPN o L2TP) contiene implícitamente el concepto

“permit”.
Sentido: La dirección 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 que se inicia el tráfico
Dirección de destino: La zona a la que se envía el tráfico
Servicio: El tipo de tráfico transmitido
Acción: La acción realizada por el dispositivo de seguridad cuando recibe

tráfico que cumple los cuatro primeros criterios: denegar, permitir, rechazar o
encapsular
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 “server1”
en la zona DMZ:
set policy from trust to untrust any server1 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: server1 (una dirección definida por el usuario en la

libreta de direcciones de la zona Untrust)
Servicio: ftp (protocolo de transferencia de archivos o “File Transfer Protocol”)
Acción: permit (el dispositivo de seguridad permite a este tráfico atravesar su

cortafuegos)
164 Elementos básicos

Capítulo 6: Directivas
Tres tipos de directivas

Puede controlar el flujo de tráfico mediante las tres clases de directivas siguientes:
Mediante la creación de directivas intrazonales puede regular el tipo de tráfico

que desee permitir desde una zona de seguridad a otra.
Mediante directivas intrazonales también puede controlar el tipo de tráfico al

que desea permitir cruzar interfaces asociadas a la misma zona.
Creando directivas globales puede regular el tráfico entre direcciones, sin

importar sus 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
encapsular el tráfico desde una zona a otra. Aplicando técnicas de inspección de
estado, un dispositivo de seguridad mantiene una tabla de sesiones TCP activas y
de “pseudosesiones” UDP activas para poder permitir respuestas a las peticiones de
servicio. Por ejemplo, si tiene una directiva que permite enviar peticiones HTTP del
host A de la zona Trust al servidor B de la zona Untrust, cuando el dispositivo de
seguridad recibe respuestas HTTP del servidor B para el host A, el dispositivo de
seguridad comprueba el paquete recibido con el contenido de su tabla. Si detecta
que el paquete es una respuesta a una petición HTTP aprobada, el dispositivo de
seguridad permite al paquete del servidor B de la zona Untrust cruzar el cortafuegos
hacia 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 71: Directiva interzonales
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 se llega a ellas a través de diferentes interfaces
del dispositivo de seguridad. 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 165

Figura 72: Directiva intrazonal
set policy from trust to trust “host A” “servidor B” any permit ethernet1 ethernet4
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 interface 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 MIP, 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, que abarca todas las direcciones de 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.
166 Tres tipos de directivas

Listas de conjuntos de directivas

Un dispositivo de seguridad mantiene tres diferentes listas de conjuntos de
directivas, una por cada una de las siguientes clases de directivas:
Directivas interzonales
Directivas intrazonales
Directivas globales
Cuando el dispositivo de seguridad recibe un paquete de inicio de una nueva

sesión, detecta la interfaz de entrada y averigua a qué zona de origen está asociada
esa interfaz. A continuación, el dispositivo de seguridad realiza una consulta de
rutas para determinar la interfaz de salida y determina a qué zona de destino está
asociada esa interfaz. Utilizando 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 orden siguiente:
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 coincidencias, consulta la lista de conjuntos de
directivas global.
3. Si el dispositivo de seguridad realiza las consultas de directivas interzonales y

globales y no encuentra coincidencias, aplica al paquete la directiva
permitir/denegar predeterminada: unset/set policy default-permit-all.
(o bien)
Si el dispositivo de seguridad realiza las consultas de directivas intrazonales y

globales y no encuentra coincidencias, aplica al paquete el ajuste de bloqueo
intrazonal de esa zona: unset/set zone zone block.
El dispositivo de seguridad consulta cada lista de conjuntos de directivas de arriba a

abajo. 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
directivas, consulte “Reordenar directivas” en la página 195).
Listas de conjuntos de directivas 167

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.
NOTA: Para los dispositivos de seguridad que admiten sistemas virtuales, las directivas
establecidas en el sistema raíz no afectan a las directivas establecidas en 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 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. Permitiendo que múltiples 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
haya. Asimismo, al permitir que un gran número de reglas lógicas comparta un
pequeño conjunto de componentes, ScreenOS 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.
168 Definición de directivas

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)
Servicios
Acción (permitir, denegar, rechazar, tunelizar)
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
Respaldo HA de la sesión
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.
Definición de directivas 169

ID
Cada directiva tiene un número de identificación, tanto si el usuario define uno
como si el dispositivo de seguridad lo asigna 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 number … 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 “Entrar al contexto de una directiva” en la
página 190).
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 interzonales) 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 165 y “Directivas
intrazonales” en la página 165).
Direcciones
Las direcciones son objetos que identifican dispositivos de red tales como hosts y
redes por su ubicación respecto 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 disponibles de
reglas lógicas internas y de componentes que componen 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 168).
Servicios
Los servicios son objetos que identifican los protocolos de aplicación usando
información de la capa 4, como los números de puerto TCP y UDP estándar y
universalmente aceptados 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 TCP y un mensaje de “destino
inalcanzable, puerto inalcanzable” 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 TCP RST después de recibir (y descartar) un

segmento TCP con cualquier bit de código activado salvo otro RST.
Cuando la interfaz de entrada está operando en la capa 2 o 3 y el protocolo es TCP,

la dirección IP de origen en el TCP RST es la dirección IP de destino en el paquete
original (descartado). Cuando la interfaz de entrada está operando en la capa 2 y
el protocolo es UDP, la dirección IP de origen en el mensaje ICMP coincide con la
dirección IP de destino en el paquete original. Sin embargo, si la interfaz de
entrada está operando en la capa 3 y el protocolo es UDP, la dirección IP de origen
en el mensaje 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
(“L2TP-over-IPSec”), especifique un túnel 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 los

criterios presentados 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 apunta al
servicio de capa 4 al que se hace referencia en una directiva. Los servicios
predefinidos ya disponen de una asignación a una aplicación de capa 7. Sin
embargo, para los servicios personalizados es necesario vincular explícitamente el
servicio a una aplicación, especialmente si se desea que la directiva aplique una
puerta de enlace de la capa de aplicación (ALG) o Deep Inspection al servicio
personalizado.
NOTA: ScreenOS admite ALG para numerosos servicios, a saber: DNS, FTP, H.323, HTTP,
RSH, SIP, Telnet y TFTP.
La aplicación de una ALG a un servicio personalizado implica los dos pasos

siguientes:
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 “Asignar servicios personalizados a aplicaciones” en la
página 4-142.
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 nomenclatura y conjuntos de caracteres” en la página xii.
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-159).
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 constituyen un par
coincidente (es decir, 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 propagará a la
otra.
NOTA: Esta opción solamente está disponible a través de WebUI. No puede haber
múltiples entradas para ninguno de los siguientes componentes de directiva:
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 capa 2 (L2TP) que haya configurado. En WebUI, la opción de
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 tunn_str 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 modo transparente no admite L2TP.
Deep Inspection
Deep Inspection (DI) es un mecanismo para filtrar el tráfico permitido en las capas
Network y Transport, al examinar no solamente estas capas, sino las características
de contenido y protocolo en la capa de aplicación. El objetivo de DI es detectar y
prevenir cualquier ataque o comportamiento anómalo que pudiera existir en el
tráfico permitido por el cortafuegos de Juniper Networks.
NOTA: En el modelo OSI (“Open Systems Interconnection”), la capa “Network” es la 3

(“Layer 3”), la capa “Transport” es la 4 (“Layer 4”) y la capa “Application” es la 7
(“Layer 7”). El modelo OSI es un modelo estándar en el sector de la industria de
redes de una arquitectura de protocolos de red. El modelo 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-105).
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 reubicar la directiva, puede utilizar
cualquiera de los métodos de reordenación de directivas explicados en “Reordenar
directivas” en la página 195. 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 IP
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-15.
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 94.
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-29.
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 VPN. El dispositivo de seguridad puede utilizar la base de datos local o un
servidor externo de autenticación RADIUS, SecurID o LDAP 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 múltiples cuentas de usuarios de autenticación (como ocurre

con un host Unix que ejecuta Telnet), una vez que el dispositivo de seguridad ha
autenticado 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
haber heredado los privilegios del primer usuario.
ScreenOS proporciona dos esquemas 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 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 petición 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

petición de inicio de sesión.
3. El usuario de autenticación responde a esta petición 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” (“cualquiera”) 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 llamado “Login” que proporcione los servicios FTP,
NetMeeting y H.323. Luego, cuando cree la directiva, especifique “Login” 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

petición de inicio de sesión.
3. El usuario de autenticación responde a esta petición 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 tráfico a los destinos especificados 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-40.
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
el que 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 NAT que utilice
una sola dirección IP para todas las asignaciones NAT, los usuarios de otros hosts
situados detrás de ese dispositivo NAT recibirán automáticamente los mismos
privilegios.
Respaldo HA de la sesión
Cuando dos dispositivos de seguridad se encuentran en un clúster NSRP para alta
disponibilidad (HA), puede especificar qué sesiones respaldar y cuáles no. Para el
tráfico cuyas sesiones no desee respaldar, 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
NSRP respaldan las sesiones.
Filtrado de Web
El filtrado de Web, denominado también “filtrado de URL”, permite administrar los
accesos a Internet e impedir el acceso a contenidos no apropiados. Para obtener
más información, consulte “Filtrado de Web” en la página 4-88.
Registro
Cuando se habilita el registro en una directiva, el dispositivo de seguridad registra
todas las conexiones a las que esa directiva en particular sea aplicable. Los registros
se pueden visualizar con WebUI o CLI. En la WebUI, haga clic en Reports > Policies
> Logging (para la directiva cuyo registro desee consultar). En CLI, utilice el
comando get log traffic policy id_num.

NOTA: Para obtener más información sobre cómo visualizar registros y gráficos, consulte
“Supervisar dispositivos de seguridad” en la página 3-53.
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 es aplicable y registra
la información en gráficos de historial. Para visualizar los gráficos de historial de
una directiva en la 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-64.
Tareas programadas
Asociando una programación a una directiva, se puede determinar cuándo debe
activarse esa directiva. Puede configurar programaciones repetitivas o 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 sección Objects > 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 Juniper Networks admiten un analizador antivirus interno
que se puede configurar para filtrar 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 2-177.

Asignación de tráfico
Puede establecer los parámetros de control y asignación del tráfico para cada
directiva. Los parámetros de asignación de tráfico son:
Guaranteed Bandwidth: Tasa de transferencia garantizada en kilobits por

segundo (kbps). El tráfico que 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 Bandwidth: Ancho de banda garantizado disponible para el tipo de

conexión en kilobits por 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.
DiffServ Codepoint Marking: “Differentiated Services” (“DiffServ”) es un

sistema para etiquetar (o “marcar”) el tráfico de una posición dentro de una
jerarquía de prioridades. Puede asignar los ocho niveles de prioridad de
ScreenOS al sistema DiffServ. De forma predeterminada, la prioridad más alta
(prioridad 0) del sistema ScreenOS corresponde a los tres primeros bits (111)
del campo “DiffServ” (consulte la RFC 2474), o al campo de precedencia de IP
del byte TOS (consulte la RFC 1349), en el encabezado de paquetes de IP. La
prioridad más baja (prioridad 7) en ScreenOS se asigna a (000) en el sistema
TOS DiffServ. Cuando habilita el DSCP, ScreenOS sobrescribe los primeros 3
bits en el byte ToS con la prioridad de precedencia de IP. Cuando se habilita el
DSCP y establece un valor byte-dscp, ScreenOS sobrescribe los primeros 6 bits
del byte ToS con el valor del DSCP.
NOTA: Para averiguar más sobre la administración y asignación del tráfico, consulte
“Asignar tráfico” en la página 197.
Para cambiar la asignación entre los niveles de prioridad de ScreenOS y el

sistema DiffServ, utilice el siguiente comando CLI:
set traffic-shaping ip_precedence number0 number1 number2 number3

number4 number5 number number7
donde number0 corresponde a la prioridad 0 (la prioridad más alta del

sistema TOS DiffServ), number1 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.
Visualizar directivas
Para visualizar las directivas a través de WebUI, haga clic en Policies. Puede
clasificar las directivas mostradas por zonas de origen y de destino, eligiendo
nombres de zonas en las listas desplegables From y To, y haciendo clic en Go. En
CLI, utilice el comando get policy [ all | from zone to zone | global | id number ].
Crear 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 referidas 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 zonas compartidas en lo referente a sistemas virtuales, consulte
el Volumen 10: Sistemas virtuales.)
Crear servicio de correo de directivas interzonales

En este ejemplo, creará tres directivas para controlar el flujo de tráfico de correo
electrónico.
La primera directiva permitirá 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.
Directivas aplicadas 179

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 ethernet1 a la zona Trust y asígnele la dirección IP 10.1.1.1/24.
Asocie ethernet2 a la zona DMZ y asígnele la dirección IP 1.2.2.1/24.
Asocie ethernet3 a la zona Untrust y asígnele la dirección IP 1.1.1.1/24.
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
ethernet3.
Una vez completados los pasos 1 a 4, podrá 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
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: DMZ

180 Directivas aplicadas

haga clic en OK:
Zone Name: Untrust

2. Direcciones
en OK:
Address Name: corp_net

Zone: Trust
en OK:
Address Name: mail_svr

Zone: DMZ
en OK:
Address Name: r-mail_svr

Zone: Untrust
3. Grupo de servicios
Objects > 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

Seleccione POP3 y utilice el botón << para mover el servicio de la

4. Ruta

5. Directivas
haga clic en OK:

Source Address:
Address Book Entry: (seleccione), corp_net
Address Book Entry: (seleccione), mail_svr
Service: Mail-POP3
Action: Permit
Policies > (From: DMZ, To: Untrust) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), r-mail_svr
Service: MAIL
Action: Permit
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), r-mail_svr
Service: MAIL
Action: Permit
CLI
1. Interfaces
set interface ethernet2 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

Crear 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 “Eng”)
Resto de la empresa (con la dirección definida como “Office”)
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:
“Eng” puede utilizar todos los servicios de tráfico saliente salvo FTP-Put, IMAP,
MAIL y POP3.
Los usuarios de “Office” pueden 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-39).
Cada usuario de la zona Trust puede acceder a los servidores de web y 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 73: Conjunto de directivas interzonales
Zona Untrust
Internet
www.abc.com
mail.abc.com
Enrutador externo
Enrutador interno
Zona DMZ
LAN de “Office” LAN de “Eng”
Zona Trust
Se parte de la base de que ya tiene configuradas las interfaces, direcciones, grupos

de servicios y rutas necesarias. Para obtener más información sobre la
configuración de los elementos anteriores, consulte “Interfaces” en la página 45,
“Direcciones” en la página 106, “Grupos de servicios” en la página 142 y el
Volumen 7: Enrutamiento.
Tabla 18: Directivas configuradas
De la 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 - Eng Untrust - Any Any Permit
Trust - Office 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
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Eng
Service: ANY
Action: Permit
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Office
Service: Internet
Action: Permit
Authentication: (seleccione)
WebAuth: (seleccione)
NOTA: “Internet” es un grupo de servicios con los siguientes miembros: FTP-Get, HTTP y
HTTPS.
haga clic en OK:
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 denegación

predeterminada deniega todo.
2. De Untrust a DMZ
haga clic en OK:
Source Address:

Address Book Entry: (seleccione), mail.abc.com
Service: MAIL
Action: Permit
haga clic en OK:
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
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.
clic en OK:
Source Address:
Address Book Entry: (seleccione), www.abc.com
Service: Internet
Action: Permit
clic en OK:
Source Address:
Address Book Entry: (seleccione), sys-admins
Service: ANY
Action: Permit
4. De DMZ a Untrust
haga clic en OK:

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 office 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
Crear 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á ethernet1 a la zona Trust y le dará la dirección IP 10.1.1.1/24.
Después asociará ethernet2 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
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en Apply:
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
en OK:
Address Name: Hamilton

Zone: Trust
en OK:
Address Name: accounting

Zone: Trust
3. Directiva
Policies > (From: Trust, To: Trust) > New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), accounting
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 accounting 10.1.5.0/24
3. Directiva
set policy from trust to trust accounting Hamilton any permit
save
Crear una directiva global

En este ejemplo, creará una directiva global, de modo que todos los hosts de todas
las zonas puedan tener acceso al sitio web de la compañía: www.juniper.net. El uso
de una directiva global constituye un método abreviado muy práctico cuando
existen muchas zonas de seguridad. 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
en OK:
Address Name: server1

Domain Name: (seleccione), www.juniper.net
Zone: Global
2. Directiva
Policies > (From: Global, To: Global) > New : Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), server1
Service: HTTP
Action: Permit
CLI
1. Dirección global
set address global server1 www.juniper.net
2. Directiva
set policy global any server1 http permit
save

Entrar al contexto de una directiva

Al configurar una directiva mediante CLI, una vez creada una directiva, puede
introducirse en el contexto de ésta para agregar o modificar datos. Por ejemplo,
suponga que primero crea la directiva siguiente:
set policy id 1 from trust to untrust host1 server1 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 ataques, puede
introducirse en el contexto de la directiva 1 y luego ejecutar los comandos
pertinentes:
set policy id 1
ns(policy:1)-> set src-address host2
ns(policy:1)-> set dst-address server2
ns(policy:1)-> set service FTP
ns(policy:1)-> set attack CRITICAL:HTTP:SIGS
También puede eliminar varios elementos de un componente de directiva único,

siempre que no elimine todos. Por ejemplo, puede eliminar server2 de la
configuración anterior, pero no server2 y server1 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 ataques
En versiones anteriores a ScreenOS 5.0.0, la única manera de tener múltiples

direcciones de origen y destino o múltiples servicios era crear primero un grupo de
direcciones o de servicios con múltiples 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 mostrando 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
contiguo al componente al cual 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 number
Ahora utilice uno de los comandos siguientes según convenga:
ns(policy:number)-> set src-address string

ns(policy:number)-> set dst-address string
ns(policy:number)-> set service string
ns(policy:number)-> set attack string
Ajustar la denegació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 “P-T_contractors”. Para lograrlo, puede utilizar la opción de denegació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 a “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 denegació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 asociadas a la misma zona.
En segundo lugar, asociará dos interfaces a la zona Trust y les asignará direcciones
IP:
Asociará ethernet1 a la zona Trust y le asignará la dirección IP 10.1.1.1/24.

Asociará ethernet4 a la zona Trust y le asignará la dirección IP 10.1.2.1/24.
En tercer lugar, 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
alcanzar su servidor FTP, ya que los ingenieros también se encuentran en la
subred 10.1.2.0/24 y no necesitan traspasar el cortafuegos de Juniper Networks
para alcanzar su propio servidor.
Figura 74: Denegación de directivas intrazonales
ethernet1 ethernet4
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 (Ingeniería)
empresa)
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
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT

haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
3. Dirección
en OK:
Address Name: vulcan

Zone: Trust
4. Directiva
Policies > (From: Trust, To: Trust) New: Introduzca los siguientes datos y haga
clic en OK:
Source Address:
Address Book Entry: (seleccione), vulcan
> Haga clic en Multiple, seleccione la casilla de verificación Negate

Following; a continuación, haga clic en OK para regresar a la página de
configuración básica Policy.
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

Modificar y desactivar 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 Policy 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
Policies: 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 id_num disable
save
NOTA: Para volver a habilitar la directiva, seleccione Enable en la columna “Configure”

de la directiva que desee habilitar (WebUI), o escriba en el teclado unset policy id
id_num disable (CLI).
Verificar directivas
ScreenOS ofrece una herramienta para verificar si el orden de las directivas dentro
de la lista de directivas es válido. Una directiva puede eclipsar (“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
Como el dispositivo de seguridad consulta la lista de directivas comenzando por el

principio, deja de buscar tan pronto como encuentra una coincidencia con el tráfico
recibido. En el ejemplo antedicho, el dispositivo de seguridad nunca alcanza la
directiva 2 porque la dirección de destino “any” de la directiva 1 ya incluye en la
directiva 2 la dirección “dst-A”, que es más específica. 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
comando CLI siguiente:
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 ejemplo siguiente,
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 server1 HTTP permit
set policy id 2 from trust to untrust host2 server1 HTTP permit
set policy id 3 from trust to untrust grp1 server1 HTTP deny
Reordenar directivas
El dispositivo de seguridad compara las directivas para ver todos los intentos de
atravesar el cortafuegos, comenzando por la primera directiva que aparece en el
conjunto de directivas de la lista correspondiente (consulte “Listas de conjuntos de
directivas” en la página 167) 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 en la lista 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 Policy de WebUI, active la casilla
de verificación 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

WebUI
Hay dos maneras de reordenar directivas en WebUI: haciendo clic en las flechas
circulares o haciendo clic en la flecha única 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 realizar el traslado.
Si hace clic en la flecha única:
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 trasladada a su nueva

ubicación.
CLI
set policy move id_num { before | after } number
save
Eliminar 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
id_num.

Capítulo 7
Asignar tráfico
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 de cara a todos los usuarios. Contiene las
“Administrar el ancho de banda a nivel de directivas” en esta página
“Ajustar la asignación de tráfico” en la página 198
“Ajustar las prioridades del servicio” en la página 202
“Ajustar las colas de prioridades” en la página 203
“Directivas de entrada” en la página 206
“Asignar tráfico en interfaces virtuales” en la página 207
“Asignación y marcado DSCP” en la página 218
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 tasa de
transmisión apropiados a cada clase de tráfico que pasa por ellos.
Administrar el ancho de banda a nivel de directivas

Para clasificar el tráfico, cree una directiva 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 se basan
estrictamente en directivas, sino que se basan en el ancho de banda de la interfaz
física de salida total y directiva disponible, cuanod hay múltiples interfaces físicas
en la zona de salida. El ancho de banda físico de cada interfaz se asigna al
parámetro de ancho de banda garantizado para todas las directivas. Cualquier
porción de ancho de banda sobrante es compartible por cualquier otro tráfico. Es
decir, cada directiva obtiene su ancho de banda garantizado y comparte la porción
sobrante (no utilizada) basándose en la prioridad (hasta el límite de la
especificación de su ajuste de ancho de banda máximo), con todas las otras
directivas.
Administrar el ancho de banda a nivel de directivas 197

La función de asignación de tráfico es aplicable 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 178.
Si no desea que el sistema aplique esta directiva predeterminada a las directivas

para las que haya desactivado la asignación de tráfico, puede desactivar el sistema
de asignación de tráfico ejecutando el comando CLI: set traffic-shaping mode off.
Utilice el comando CLI: set traffic-shaping mode on para encender la opción de
asignación en una interfaz. O puede poner la asignación de tráfico en modo
automático en la WebUI: Configuration > Advanced > Traffic Shaping. Esto
permite al sistema activar la asignación de tráfico cuando una directiva la requiera y
desactivarla cuando no la requiera.
Ajustar 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 ethernet1 está asociada a la
zona Trust y ethernet3 a la zona Untrust.
Figura 75: Asignación de tráfico

T3–45 Mbps
Marketing: 10 Mbps de entrada,
10 Mbps de salida
Internet
Enrutador Enrutador
Sales: 5 Mbps de entrada,
10 Mbps de salida
DMZ para
servidores Zona DMZ
Soporte: 5 Mbps de entrada,
5 Mbps de salida
198 Ajustar la asignación de tráfico

Capítulo 7: Asignar tráfico
WebUI
1. Ancho de banda en interfaces
haga clic en OK:
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.
haga clic en OK:

2. Ancho de banda en directivas
haga clic en OK:
Name: Marketing Traffic Shaping

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
haga clic en OK:
Name: Sales Traffic Shaping Policy

Source Address:
Address Book Entry: (seleccione), Sales
Service: Any
Action: Permit

Ajustar la asignación de tráfico 199

haga clic en OK:
Name: Support Traffic Shaping Policy

Source Address:
Address Book Entry: (seleccione), Support
Service: Any
Action: Permit

haga clic en OK:
Name: Allow Incoming Access to Marketing

Source Address:
Service: Any
Action: Permit

haga clic en OK:
Name: Allow Incoming Access to Sales

Source Address:
Service: Any
Action: Permit

200 Ajustar la asignación de tráfico

haga clic en OK:
Name: Allow Incoming Access to Support

Source Address:
Service: Any
Action: Permit

CLI
Para habilitar la asignación de tráfico por cada directiva, haga lo siguiente:

set interface ethernet1 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 “Marketing Traffic Shaping” from trust to untrust marketing any
any permit traffic gbw 10000 priority 0 mbw 15000
set policy name “Sales Traffic Shaping Policy” from trust to untrust sales any any
permit traffic gbw 10000 priority 0 mbw 10000
set policy name “Support Traffic Shaping Policy” from trust to untrust support any
set policy name “Allow Incoming Access to Marketing” from untrust to trust any
marketing any permit traffic gbw 10000 priority 0 mbw 10000
set policy name “Allow Incoming Access to Sales” from untrust to trust any sales
set policy name “Allow Incoming Access to Support” from untrust to trust any
support any permit traffic gbw 5000 priority 0 mbw 5000
save
Ajustar la asignación de tráfico 201

Ajustar 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 no
utilizado. 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 al dispositivo de seguridad
canalizar el tráfico por hasta 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 priority (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 (“round robin” o
“ronda recíproca”). 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
peticiones de tráfico. Si las peticiones 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 únicamente después de
haber procesado el resto del tráfico.
202 Ajustar las prioridades del servicio

Ajustar las colas de prioridades

En este ejemplo configurará el ancho de banda garantizado y máximo (en Mbps)
para tres departamentos: Support, Sales y Marketing, como se indica en la Tabla 19:
Tabla 19: Configuración del ancho de banda máximo
Tráfico
Tráfico saliente Tráfico entrante combinado
garantizado garantizado garantizado Prioridad
Support 5 5 10 Alta
Sales 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 por las directivas. La interfaz ethernet1
está asociada a la zona Trust y ethernet3 a la zona Untrust.
Figura 76: Gestionar colas de prioridades

T3–45 Mbps
Support: 5 Mbps de salida, 5 Mbps
de entrada, alta prioridad
Internet
Enrutador Enrutador
Sales: 2,5 Mbps de salida, 3,5 Mbps
de entrada, prioridad 2
DMZ para
servidores Zona DMZ
Marketing: 2,5 Mbps de salida, 1,5 Mbps de entrada,
prioridad 3
WebUI
Interfaces > Edit (para ethernet1): Introduzca los siguientes datos y haga clic
en OK:
en OK:
Ajustar las colas de prioridades 203


haga clic en OK:
Name: Sup-out
Source Address:
Service: Any
Action: Permit
Traffic Priority: High priority
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 178.
haga clic en OK:
Name: Sal-out
Source Address:
Service: Any
Action: Permit
Traffic Priority: 2nd priority
DiffServ Codepoint Marking: Enable
haga clic en OK:
Name: Mar-out
Source Address:
Service: Any
Action: Permit
204 Ajustar las colas de prioridades

Traffic Priority: 3rd priority
haga clic en OK:
Name: Sup-in
Source Address:
Service: Any
Action: Permit
Traffic Priority: High priority
haga clic en OK:
Name: Sal-in
Source Address:
Service: Any
Action: Permit
Traffic Priority: 2nd priority
haga clic en OK:
Name: Mar-in
Source Address:
Service: Any
Action: Permit
Ajustar las colas de prioridades 205


Traffic Priority: 3rd priority
CLI
set policy name sup-out from trust to untrust support any any permit traffic gbw
5000 priority 0 mbw 40000 dscp enable
set policy name sal-out from trust to untrust sales any any permit traffic gbw 2500
priority 2 mbw 40000 dscp enable
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 support any permit traffic gbw
set policy name sal-in from untrust to trust any sales 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
Las directivas de entrada controlan el tráfico en el lado de entrada del dispositivo de
seguridad. Al restringir el flujo de tráfico en el punto de entrada, el tráfico que
supera el ajuste del ancho de banda se descarta mediante un procesamiento
mínimo, conservando los recursos del sistema. Las directivas de entrada se pueden
configurar en el nivel de la interfaz y en las directivas de seguridad.
Las directivas de entrada se configuran en una interfaz ajustando el ancho de banda

máximo (la palabra clave mbw). El siguiente comando, por ejemplo, limita el ancho
de banda en Ethernet1 y la interfaz de entrada a 22 Mbps:
set interface ethernet1 bandwidth ingress mbw 22000
El tráfico entrante en ethernet1 que supera este ancho de banda se descarta. Si

ajusta la asignación de tráfico en la interfaz, también debe activar el comando set
traffic-shaping mode (set traffic-shaping mode on).
Para aplicar las directivas de entrada en una aplicación específica, sin embargo, se
requiere una directiva. El siguiente comando crea una directiva llamada my_ftp que
establece el límite del ancho de banda FTP en el lado de entrada del dispositivo de
seguridad a 10 Mbps:
set policy my_ftp from untrust to trust any any ftp permit traffic pbw 10000
206 Directivas de entrada

Se descarta el tráfico FTP entrante que supera el ancho de banda de las directivas
configuradas (la palabra clave es pbw). También puede ajustar el mbw en la
directiva, pero el nivel de directiva mbw se aplica únicamente en el lado de entrada
de flujo de tráfico, y el tráfico que supera la tasa configurada también se procesa y
se descarta únicamente en el lado de salida (consulte la Figura 78, “Flujo de
paquetes de asignación de tráfico”, en la página 210). En una directiva se puede
configurar mbw o pbw, pero no las dos.
La configuración y el refuerzo de las directivas de entrada en interfaces virtuales es

la misma que se utiliza en las interfaces físicas, con la única excepción que también
puede configurar el ancho de banda garantizado (la palabra clave es gbw) en
interfaces virtuales (consulte Asignar el tráfico a nivel de directiva en la
página 209). En interfaces físicas, el ancho de banda garantizado es el mismo que
el ancho de banda máximo.
NOTA: Las directivas de entrada en interfaces de túnel se refuerza después que el motor
VPN desencripta los paquetes encriptados.
Asignar tráfico en interfaces virtuales

En el contexto de la asignación de tráfico, el término interfaces virtuales se refiere
únicamente a las subinterfaces y a las interfaces de túnel (no a otra clase de
interfaces virtuales, como interfaces de seguridad virtual (VSI) o interfaces
redundantes o agregadas). No se pueden configurar los parámetros de asignación
en directivas que se crearon en un vsys. De forma similar, el ancho de banda no se
puede asignar en las interfaces que son propiedad (que heredó) de un usuario
creado en vsys. Para obtener más información, consulte el Volumen 10:
Sistemas virtuales.
La asignación de tráfico (a diferencia de las políticas de entrada) se relaciona con la

administración de tráfico en el lado de entrada del dispositivo de seguridad. De
igual forma que con las interfaces físicas, el tráfico en interfaces se configura
ajustando los valores del ancho de banda en el nivel de la interfaz y en las
directivas.
Asignar el tráfico a nivel de interfaz

La configuración al nivel de interfaz es el control de la tasa mínima y máxima del
flujo de tráfico en una interfaz específica. El ancho de banda mínimo se controla
especificando un ancho de banda garantizado (gbw). Lo que significa que se
garantiza se garantiza la tasa mínima según el tráfico, independientemente de lo
que suceda en el dispositivo. El ancho de banda máximo (mbw) que se ajustó,
establece la tasa de tráfico que nunca se puede exceder. De forma predeterminada,
el ancho de banda máximo en una interfaz física es la capacidad de transmisión de
la interfaz, por lo tanto, no es posible ajustar el ancho de banda garantizado en la
interfaz física.
Asignar tráfico en interfaces virtuales 207

En el contexto de la asignación de tráfico, una interfaz identifica subinterfaces

asociadas a interfaces físicas y, por extensión, las interfaces de túnel asociadas a
esas subinterfaces (creando de esta forma una jerarquía de interfaces). Una
subinterfaz asociada a una interfaz física se dice que es la hija de la interfaz física,
su padre. En consecuencia, una interfaz de túnel asociada a una interfaz es la hija de
una subinterfaz, la interfaz física como su abuela. La Figura 77 ilustra estas
dependencias.
Figura 77: Jerarquía de interfaces
Ethernet1
mbw 10000
Ethernet1.1 Ethernet 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
Cuando se trabaja con interfaces virtuales, hay que tener presentes las siguientes
reglas sobre jerarquías de interfaces:
El ancho de banda que se asignó a las subinterfaces no puede ser mayor que la
capacidad de transmisión de la interfaz física a la que está asociado. En la
Figura 77, por ejemplo, la combinación de gbw de ethernet1.1 y ethernet1.2 es
9000 Kbps, 1000 Kbps por abajo del mbw de ethernet1. Observe que, sin
embargo, el ancho de banda máximo combinado de estas dos subinterfaces
supera la capacidad de transmisión de la interfaz física a la que se asocian por
2000 Kbps. Lo que es aceptable, ya que la palabra clave mbw se utiliza
únicamente para limitar el tráfico a una tasa máxima. Si el tráfico se encuentra
abajo del ajuste máximo en una subinterfaz, dicho ancho de banda está
disponible para cualquier otra subintefaz asociada a la misma interfaz física.
El ancho de banda que se asignó a las interfaces de túnel no puede ser mayor
que el ancho de banda garantizado de la subinterfaz a la que está asociado.
Si el ancho de banda garantizado no se configura para el “padre” inmediato, el

ancho de banda se toma de la interfaz que actúa como “abuelo”.
El ancho de banda garantizado total de las interfaces que actúan como “hijas”
no pueden 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.
208 Asignar tráfico en interfaces virtuales

Como ya se indicó, no es posible configurar el ancho de banda garantizado en

interfaces físicas debido a que el ancho de banda garantizado es el mismo ancho de
banda máximo, que es la velocidad de los enlaces de la interfaz. En interfaces
virtuales, sin embargo, es posible configurar la salida de gbw y mbw. También es
posible configurar la entrada de mbw, que es la directiva de entrada en el nivel de la
interfaz. El siguiente comando garantiza una tasa saliente mínima de bit de 2000
Kbps en Ethernet4.1 y una tasa máxima, las dos de entrada y salida, de 2000 Kbps:
set interface ethernet4.1 bandwidth egress gbw 1000 mbw 2000 ingress mbw
2000
Se ajusta el ancho de banda en la WebUI en la página Network > Interfaces >

Edit.
Después de ajustar el ancho de banda, se puede utilizar el comando get

traffic-shaping interface para observar el ancho de banda actual que fluye a través
del dispositivo de seguridad. Por ejemplo, es posible que el tráfico entre en
ethernet1 y salga en ethernet3. Si se ajustó el ancho de banda de entrada en
ethernet1, el comando get traffic-shaping interface ethernet3 mostrará el
rendimiento real en el dispositivo.
Si ajusta la asignación de tráfico en la interfaz, también debe activar el comando set

traffic-shaping mode (set traffic-shaping mode on).
Asignar el tráfico a nivel de directiva

Se asigna el tráfico al nivel de directiva para asignar el ancho de banda para tipos
determinados de tráfico. El siguiente comando garantiza un ancho de banda
mínimo de 1Mbps para el tráfico FTP y descarta todo el tráfico que supera los 2
Mbps:
set policy my_ftp from untrust to trust any any ftp permit traffic pbw 1000
Observe que este comando utiliza la palabra clave del ancho de banda de las
directivas (pbw). En una directiva se puede utilizar pbw o mbw, pero no las dos. El
beneficio de utilizar pbw es que el tráfico se descarta en el lado de entrada del
dispositivo de seguridad, reduciendo el gasto de procesamiento y conservando los
recursos del sistema. (Consulte Directivas de entrada en la página 206).
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.
Aunque 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 del tráfico cuando se asigna el
tráfico en las directivas. Esto se debe a que el modo de asignación de tráfico se
ajusta a 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 dicha sesión. Se puede ajustar o no el modo de asignación de tráfico a
auto únicamente en la WebUI: Configuration > Advanced > Traffic Shaping.

Flujo de paquetes
La Figura 78 ilustra la parte del flujo de paquetes a través del dispositivo de
seguridad que afecta a la asignación del tráfico y las directivas. (Consulte
“Secuencia de flujo de paquetes” en la página 11 para obtener una ilustración
completa del flujo de paquetes). Los paquetes que superan el pbw (o el mbw
configurado en la interfaz) se descartan en el paso 9; la asignación y marcado de
DSCP se lleva a cabo en el paso 10 y los paquetes que superan el mbw (configurado
en una directiva) se descarta en el paso 11.
Figura 78: Flujo de paquetes de 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 La asignación y DSCP Continuar con con todas las interfaces
pid -1, did 0, time 180 marcan el paquete, luego de salida del dispositivo y transmitir los
13 (01) 10.10.10.1/1168 -> o bien
lo colocan en cola en la paquetes situados en la cola
211.68.1.2/80, 6, 002be0c0066b,
Directiva interfaz de salida
subif 0, tun 0
Ejemplo: VPN basada en rutas con directivas de entrada

Este ejemplo ilustra cómo reforzar las directivas de entrada en el nivel de interfaz
para el tráfico encriptado. Las directivas de entrada se configuran en la subinterfaz
(e2.1, ancho de banda máximo:1200 Kbps) y en la interfaz de túnel (t.1, ancho de
banda máximo:1000 Kbps). La tasa de directivas en la subinterfaz que se ajustó
debe ser mayor que en la interfaz de túnel asociada a la misma para permitir el
nivel máximo de encriptación (asumiendo, en este ejemplo, que todo el tráfico que
se recibe en la subinterfaz está destinado a la interfaz de túnel). Las directivas en la
subinterfaz se aplican a los paquetes encriptados, mientas las directivas en la
interfaz de túnel se aplican a los paquetes internos desencriptados. Todo el tráfico
encriptado sobre 1200 Kbps en e2.1 se descarta. Y todo el tráfico (texto no cifrado)
desencriptado sobre 1000 Kbps. en la interfaz t.1 se descarta.
Figura 79: VPN basadas en rutas
San Francisco New York

Dispositivo1 Dispositivo2
e2 e2
e2.1, 2.2.2.1/24 e2.1, 2.2.2.2/24
e1, 10.1.1.1/24 e1, 10.2.0.2/24
Subinterfaces
t.1 Interfaces de túnel t.1
Clientes
Servidor
Zona Trust Zona Trust

WebUI (Configuración para el Dispositivo1)

1. Interfaces
haga clic en OK:
Zona: Trust
Network > Interfaces > Sub-IF > New: Introduzca los siguientes datos y haga
clic en Apply:
Interface Name: (Seleccione) ethernet2 y escriba: 1

Zone: Untrust
VLAN Tag: 128
clic en Apply:
Tunnel Interface Name: 1

Zone: Untrust
Unnumbered (seleccione) ethernet2.1
Interface: e2.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: e2.1
VPN > 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 e1 zone trust
set interface e1 ip 10.1.1.1/24
set interface e2.1 tag 128 zone untrust
set interface t.1 zone trust
set interface e2.1 ip 2.2.2.1/24
set interface t.1 ip unnumbered interface e2.1
set route 10.2.0.0/24 int t.1
2. IKE
set ike gateway device1_ike address 2.2.2.2 outgoing-interface e2.1 preshare
sec-level standard
set vpn device1_vpn gateway 208a_ike sec-level standard
set vpn device1_vpn bind interface t.1

1. Interfaces
haga clic en OK:
Zone: Trust
Network > Interfaces > Sub-IF > New: Introduzca los siguientes datos y haga
clic en Apply:
Interface Name: (Seleccione) ethernet2 y escriba: 1

Zone: Untrust
VLAN Tag: 128
Network > Interfaces > Tunnel IF > New: Introduzca los siguientes datos y
haga clic en Apply:
Tunnel Interface Name: 1

Unnumbered: (seleccione) ethernet2.1
Interface: e2.1
Network > Interfaces > Edit (para ethernet2.1): Introduzca los siguientes
Traffic Bandwidth, Ingress: 1200
Network > Interfaces > Edit (para tunnel.1): Introduzca los siguientes datos y
haga clic en OK:
Traffic Bandwidth, Ingress: 1000
3. Ruta

Interface (seleccione): Tunnel.1

4. IKE
y haga clic en OK:

Outgoing Interface: e2.1


Bind to: (Seleccione) Tunnel Interface, (seleccione) tunnel.1

5. Directivas
haga clic en OK:
Service: Any
Action: Permit
haga clic en OK:
Service: Any
Action: Permit

1. Interfaces
set interface e1 zone trust
set interface e1 ip 10.2.0.2/24
set interface e2.1 tag 128 zone untrust
set interface e2.1 ip 2.2.2.2/24
set interface t.1 zone untrust
set interface t.1 ip unnumbered interface e2.1
set route 10.1.1.0/24
set interface e2.1 bandwidth ingress mbw 1200
set interface t.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 t.1
4. Directiva
set policy from untrust to trust any any any permit

Ejemplo: VPN basada en directivas con directivas de entrada

En este ejemplo se ilustra cómo reforzar las directivas de entrada en el nivel de
interfaz y en las directivas. En la interfaz ethernet1 en el dispositivo1, se ajustó el
ancho de banda máximo a 20000 Kbps. Con este ajuste, todo el tráfico sobre 20000
Kbps de los clientes conectados al dispositivo1 en la interfaz ethernet1, se descarta.
Las directivas de entrada en la interfaz se aplican a todo el tráfico que llega a dicha
interfaz. Para obtener una granularidad más fina, se pueden aplicar las directivas de
entrada en el nivel de directivas. En este ejemplo, se pueden crear directivas para
restringir todo el tráfico de entrada de protocolo FTP en el dispositivo1 creando
directivas entre las zonas Trust y Untrust y al ajustar el ancho de banda de las
directivas a 5000 Kbps. Todo el tráfico FTP sobre 5000 Kbps de la zona Trust a la
zona Untrust se descarta.
Figura 80: VPN basadas en directivas
San Francisco Nueva York

Dispositivo1 Dispositivo2
e2, 2.1.1.1 e2, 10.2.2.1

e1, 10.1.1.1.1 e1, 1.1.1.2
Clientes
Servidor

1. Interfaces
haga clic en OK:
Zone: Trust
Interface mode: (seleccione) NAT
haga clic en OK:
Zone: Untrust
Interface Mode: (seleccione) Route
2. VPN IKE
y haga clic en OK:



Outgoing Interface: ethernet2
> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en OK

para regresar a la página de configuración básica de Gateway:
Phase 1 Proposal: pre-g2-3des-sha

3. Directivas basadas en interfaces
haga clic en OK:
Traffic bandwidth, Ingress: 20000
4. Enrutamiento
Network > Routing > Destination > New: Introduzca los siguientes datos y
haga clic en OK:
Network IP Address/Netmask: 10.2.1.0/24

Interface: (seleccione) ethernet2
5. Directivas
haga clic en OK:
Name: 1
Service: FTP
Action: Tunnel
Tunnel VPN: (seleccione), device2_vpn
Modify matching bidirectional VPN policy: (seleccione)

Return para regresar a la página de configuración básica de Policies:
Traffic Shaping (seleccione) Policy Bandwidth: 5000

1. Interfaces
2. VPN IKE
set ike gateway device2_ike address 2.2.2.2 main outgoing interface ethernet2
preshare secret proposal pre-g2-3des-sha
set vpn device2_vpn gateway device2_ike no-replay tunnel idletime 0 sec-level
standard

3. Enrutamiento
set route 10.2.1.0/24 interface ethernet2 gateway 2.2.2.2
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 netscreeen2_vpn pair-policy
1 traffic pbw 5000
5. Directivas basadas en interfaces
set interface ethernet1 bandwidth ingress mbw 20000

1. Interfaces
haga clic en OK:
Zone: Trust
Interface mode: (seleccione) Route
haga clic en OK:
Zone: Untrust
Interface Mode: (seleccione) NAT
2. VPN IKE
y haga clic en OK:


Phase 1 Proposal: pre-g2-3des-sha

3. Enrutamiento
Network > Routing > Destination > New: Introduzca los siguientes datos y
haga clic en OK:

Network IP Address/Netmask: 10.1.1.0/24

Interface: (seleccione) ethernet2
4. Directivas
haga clic en OK:
Name: 1
Service: FTP
Action: Tunnel
Tunnel VPN: (seleccione), device1_vpn

1. Interfaces
set interface ethernet1 1.1.1.2/24
2. VPN IKE
set ike gateway device1_ike address 2.1.1.1 main outgoing interface ethernet2
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
Asignar tráfico utilizando una interfaz de bucle invertido

La asignación de tráfico no se admite en las interfaces de bucle invertido, debido a
que en realidad no se transmite ningún tráfico en una interfaz de bucle invertido.
Sin embargo, una interfaz de bucle invertido se utiliza con frecuencia como un
punto de anclaje (por ejemplo en el caso de una VPN, para derivar la dirección IP de
origen), mientras los datos se transmiten en una interfaz de salida real. Cuando se
utiliza una interfaz de bucle invertido en una VPN, por consiguiente, se configura la
asignación de tráfico en la interfaz de salida. Entonces, ScreenOS asocia la sesión
con la interfaz de salida real, que ésta deduce de la tabla de enrutamiento,
actualizando de forma dinámica la asociación como los cambios de la tabla de
enrutamiento.
Asignar tráfico utilizando una interfaz de bucle invertido 217

Asignación y marcado DSCP

Es posible asignar el tráfico en una directiva que utilice el marcado DSCP o se
puede utilizar el marcado DSCP independiente de la asignación del tráfico. La
asignación del tráfico controla la forma en que el tráfico se procesa en el dispositivo
de seguridad y se puede configurar en el nivel de interfaz o en las directivas. El
marcado DSCP, que se ajustó en el nivel de directivas, controla cómo los
enrutadores descendentes procesan el tráfico.
Si activa el marcado DSCP pero no se ajusta un valor, ScreenOS asigna la prioridad

de directivas a una prioridad de preferencia de IP equivalente en el sistema DSCP.
Lo que se realiza al volver a escribir los primeros tres bits en el byte ToS con la
prioridad de preferencia de IP. Por ejemplo, si se creó una directiva que proporciona
a todo el tráfico una prioridad de, por ejemplo, 2 (0 es la prioridad más alta) y se
activa el marcado DSCP, ScreenOS pone en cola el tráfico de dicha directiva con una
prioridad de nivel 2 en la interfaz de salida y la marca con una prioridad de
preferencia de IP equivalente. El siguiente comando crea una directiva que
proporciona una prioridad 2 a todo el tráfico y activa el marcado DSCP:
set policy from trust to untrust any any any permit traffic priority 2 dscp enable
Pero si a DSCP se le proporciona un byte-dscp de valor de, por ejemplo, 46 (la

prioridad más alta), el dispositivo de seguridad sigue poniendo en cola el tráfico de
la interfaz de salida en la prioridad 2, pero sobrescribe los primeros 6 bits del byte
ToS con el valor DSCP.
set policy from trust to untrust any any any permit traffic priority 2 dscp enable
value 46
El marcado DSCP se admite en todas las plataformas y se pueden configurar por

medio de la asignación de tráfico o de forma independiente. Las tablas que se
presentan a continuación muestran cómo funciona el marcado DSCP con las
diferentes plataformas.
Tabla 20: Marcado DSCP para el tráfico de texto no cifrado
Hardware Security Client

NetScreen-5XT,
NetScreen-5GT, NetScreen
25/50,
NetScreen-204/208, Serie NetScreen-5000, ISG
Descripción NetScreen 500 1000, ISG 2000
Desactivar el paquete sin Sin marcado. Sin marcado.
ningún marcado en las
directivas.
Borrar el paquete con marcado El paquete se marca según las El paquete se marca según las
en las directivas. directivas. directivas.
Paquete marcado previamente Se mantiene el marcado en el Se mantiene el marcado en el
sin ningún marcado en las paquete. paquete.
directivas.
Paquete marcado previamente Se sobrescribe el marcado en Se sobrescribe el marcado en
con marcado en las directivas. el paquete según las directivas. el paquete según las directivas.
218 Asignación y marcado DSCP

Tabla 21: Marcado DSCP para VPN basadas en directivas

NetScreen-5XT,
25/50,
Descripción NetScreen 500 1000, ISG 2000
Borrar el paquete de la VPN Sin marcado. Sin marcado.
según las directivas sin ningún
marcado en las directivas.
Borrar el paquete de la VPN Únicamente el encabezado Únicamente el encabezado
según las directivas con ESP se marca, según las ESP se marca, según las
marcado en las directivas. directivas. directivas.
Marcar primero el paquete de El encabezado ESP se marca, El encabezado ESP no se
la VPN según directivas sin se mantiene el marcado en el marca, se mantiene el
ningún marcado en las paquete interno. marcado en el paquete
directivas. interno.
Marcar primero el paquete de El encabezado ESP se marca, El encabezado ESP se marca,
la VPN según directivas con según las directivas, se según las directivas, se
marcado en las directivas. mantiene el marcado en el mantiene el marcado en el
paquete interno. espacio interno.
Tabla 22: Marcado DSCP para VPN basadas en rutas

NetScreen-5XT,
-25/50,
Descripción NetScreen -500 1000, ISG 2000
Borrar el paquete de la VPN Sin marcado. Sin marcado.
basada en rutas sin ningún
marcado en las directivas.
Borrar el paquete de la VPN El paquete interno y el El paquete interno se marca,
basada en rutas con marcado encabezado ESP se marcan, según las directivas. El
en las directivas. según las directivas. encabezado ESP no se marca.
Marcar primero el paquete de Se copia el marcado del El encabezado ESP no se
la VPN basada en rutas sin paquete interno en el marca, se mantiene el
ningún marcado en las encabezado ESP, se mantiene marcado en el paquete
directivas. el marcado en el paquete interno.
interno.
Marcar primero el paquete de Se sobrescribe el marcado en Se sobrescribe el marcado en
la VPN basada en rutas con el paquete interno según las el paquete interno, según las
marcado en las directivas. directivas y se copia el directivas. El encabezado ESP
marcado del paquete interno no se marca.
en el encabezado ESP.
Asignación y marcado DSCP 219

220 Asignación y marcado DSCP

Capítulo 8
Parámetros del sistema
Este capítulo se centra en los conceptos relativos a la configuración de los

parámetros del sistema que afectan a las siguientes áreas de un dispositivo de
seguridad. Contiene las siguientes secciones:
“Compatibilidad con DNS” en esta página
“Protocolo de configuración dinámica de hosts” en la página 229
“Protocolo punto a punto sobre Ethernet” en la página 245
“Claves de licencia” en la página 253
“Registrar y activar los servicios de suscripción” en la página 254
“Reloj del sistema” en la página 256
Compatibilidad con DNS

El dispositivo de seguridad de Juniper Networks es compatible con el sistema de
nombres de dominio (“Domain Name System” o “DNS”), que le permite utilizar
tanto nombres de dominios como direcciones IP para identificar las ubicaciones de
una red. Un servidor DNS mantiene una tabla de direcciones IP asociadas a los
correspondientes nombres de dominio. 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:
Address Book (libreta de direcciones)
Syslog
Correo electrónico
WebTrends
Websense
LDAP
SecurID
Compatibilidad con DNS 221

RADIUS
NetScreen-Security Manager
Antes de poder utilizar DNS para la resolución de nombres de dominio y

direcciones, deben introducirse las direcciones de los servidores DNS (principal,
secundario y terciario) en el dispositivo de seguridad.
NOTA: Para habilitar el dispositivo de seguridad como servidor del protocolo de

configuración dinámica de hosts (“Dynamic Host Configuration Protocol” o
“DHCP”) (consulte “Protocolo de configuración dinámica de hosts” en la
página 229), también deberá introducir las direcciones IP de los servidores DNS
en la página “DHCP” de WebUI o mediante el comando CLI set interface interface
dhcp.
Consulta DNS
El dispositivo de seguridad actualiza todas las entradas de su tabla DNS y las
comprueba 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: Haga clic en “Refresh DNS cache”.
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 completo (“Fully-Qualified Domain

Name” o “FQDN”), como una dirección o una puerta de enlace IKE, mediante
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 implicados en
una consulta DNS:
Cuando una consulta DNS devuelve varias entradas, la libreta de direcciones

acepta todas. Los otros programas enumerados en la página 221 solamente
aceptan la primera.
El dispositivo de seguridad vuelve a instalar todas las directivas si detecta

cualquier cambio en la tabla de nombres de dominios en el momento en que el
222 Compatibilidad con DNS

Capítulo 8: Parámetros del sistema
usuario actualiza una consulta con el botón Refresh de WebUI o ejecuta el

comando CLI exec dns refresh.
Cuando falla un servidor DNS, el dispositivo de seguridad vuelve a consultar la

tabla entera.
Cuando falla una consulta, el dispositivo de seguridad la elimina de la tabla

caché.
Si la consulta del nombre de dominio falla al 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 cada día, que se puede
programar para que la realice a una hora determinada:
WebUI
Network > DNS: 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 time_str
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.
Figura 81: Tabla de estado de DNS
Nombre Dirección IP Estado Última búsqueda

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 > Show DNS Table
CLI
get dns host report

Ajustar el servidor DNS y programar 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 doméstica. El dispositivo de seguridad se
programa para actualizar los ajustes de DNS almacenados en su tabla de estado de
DNS diariamente a las 23:00 horas.
Figura 82: Actualización de DNS
Servidor DNS
secundario 24.1.64.38
Servidor DNS
Zona Trust 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
Establecer 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 de cada día.
WebUI
DNS Refresh: (seleccione)

Every Day at: 00:01
Interval: 4
CLI
set dns host schedule 00:01:00 interval 4
save
Sistema de nombres de dominio dinámico

El sistema de nombres de dominio dinámico (DDNS) es un mecanismo que permite
a los clientes actualizar dinámicamente las direcciones IP correspondientes a
nombres de dominio registrados. Esta actualización es útil cuando un ISP utiliza
PPP, DHCP o XAuth para modificar dinámicamente la dirección IP de un enrutador

CPE (como un dispositivo de seguridad) que proteja un servidor web. Los clientes
procedentes de Internet pueden acceder el servidor web usando 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
contienen 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 83: DNS dinámico
Cliente Servidor web

www.my_host.com
(enrutador CPE)
Internet Zona Trust
Servidor DDNS
ethernet7
dyndns.org o ddo.jp
En la Figura 83, la dirección IP de la interfaz ethernet7 puede haber cambiado.
Cuando se produce algún cambio, el cliente todavía puede acceder 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
configuraciones diferentes en el dispositivo de seguridad.
Configurar el 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 las direcciones que
hayan cambiado. Para este servidor, especificará el host protegido utilizando el
ajuste del nombre del host, asociado explícitamente a la interfaz DNS (ethernet7).
Cuando el dispositivo envía una actualización al servidor de ddo.jp, asocia el
nombre del host a 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: swordfish
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 sucesivas 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é. Además, si establece el intervalo de actualización mínimo a un valor
muy bajo, puede que el dispositivo de seguridad le bloquee el acceso. Se
recomienda utilizar un valor de al menos 10 minutos.
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 swordfish password ad93lvb
save
Configurar 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 de
nombre de host. 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. Es necesario cerciorarse 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

Dividir direcciones DNS del proxy

La característica 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 túneles VPN múltiples o los enlaces
virtuales PPPoE proporcionan conectividad a redes y es necesario dirigir algunas
consultas DNS a una red y otras a otra red.
Las ventajas de un proxy de DNS son las siguientes:
Las operaciones de búsqueda de dominios son generalmente más eficientes.

Por ejemplo, las consultas de DNS destinadas al dominio corporativo (como
acme.com) podrían dirigirse al servidor DNS corporativo, mientras que todas
las demás irían al servidor DNS del ISP, que reduce la carga en el servidor
corporativo. Esto también evita 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 malévolos puedan acceder a
la configuración interna de la red. Por ejemplo, las consultas de DNS dirigidas al
servidor corporativo pueden atravesar una interfaz de túnel para utilizar
características de seguridad tales como la autenticación, codificación y
antirreprocesamiento.
Los comandos siguientes crean dos entradas DNS por proxy que reenvían
selectivamente las consultas DNS a diferentes servidores.
Figura 84: Dividir peticiones 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
ethernet3
tunnel.1
Servidores DNS
de la empresa
*
acme.com
2.1.1.21
2.1.1.34
acme_eng.com
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. (Se presupone
que el servidor resuelve la consulta devolviendo 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 interfaz de túnel 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. (Se
presupone 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 ethernet3 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 y 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 ethernet3 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 ethernet3 primary-server
1.1.1.23
save

Protocolo de configuración dinámica de hosts

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.
Diferentes dispositivos de seguridad asumen diferentes papeles DHCP:
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 retransmisión de DHCP: Algunos dispositivos de seguridad también

pueden actuar como agentes de retransmisión de DHCP, recibiendo
información de un servidor DHCP y retransmitiéndola a los hosts de cualquier
interfaz física o VLAN en cualquiera zona.
Cliente/servidor/agente de retransmisión DHCP: Algunos dispositivos de

seguridad pueden actuar simultáneamente como cliente, servidor y agente de
retransmisión de DHCP. En una sola interfaz solamente se puede configurar un
papel de DHCP. Por ejemplo, en la 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,
proporciona los siguientes ajustes TCP/IP a cada host cuando éste 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.
Protocolo de configuración dinámica de hosts 229

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): Los servidores del servicio de nombres de Internet de

Windows (“Windows Internet Naming Service” o “WINS”) asignan 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.
NOTA: Si un cliente DHCP al que el dispositivo de seguridad transfiere los parámetros

antedichos dispone de una dirección IP especificada, ésta tiene preferencia sobre
toda la información dinámica recibida del servidor DHCP.
Configurar 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 (Dynamic), el dispositivo de seguridad, actuando como

servidor DHCP, asigna (o “arrienda”) a un cliente DHCP del host una dirección
IP tomada de un conjunto de direcciones. 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).
230 Protocolo de configuración dinámica de hosts

En el modo reservado (Reserved), el dispositivo de seguridad asigna una

dirección IP tomada de un conjunto de direcciones exclusivamente para un
cliente específico cada vez que éste establece una conexión.
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 direcciones DHCP para
asignar. Puede agrupar hasta 255 direcciones IP.
El servidor DHCP admite hasta 64 entradas, entre las que se pueden incluir los
rangos de direcciones de IP y direcciones IP a una sola dirección, para las
direcciones IP dinámicas y reservadas.
El dispositivo de seguridad guarda cada dirección IP asignada mediante DHCP en

su memoria flash. Por lo tanto, reiniciar el dispositivo de seguridad no afecta a las
asignaciones de direcciones.
En este ejemplo, utilizando 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, salvo a dos

estaciones de trabajo con direcciones IP reservadas y a cuatro servidores que tienen
direcciones IP estáticas. La interfaz ethernet1 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 85: Dispositivo como servidor DHCP
Direcciones IP fijas
de servidores DNS
172.16.10.240
Zona Trust 172.16.10.241
ethernet1
172.16.10.1/24 (NAT)
Conjunto de 172.16.10.1/24 Conjunto de

direcciones LAN direcciones
172-16.10.10 – 172-16.10.210 –
172.16.10.19 172.16.10.219
Conjunto de
direcciones
172-16.10.120 –
172.16.10.129
IP reservada
172.16.10.11
MAC: 12:34:ab:cd:56:78
Direcciones IP fijas
de servidores SMTP y POP3
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
en OK:
Address Name: DNS#1

Comment: Servidor DNS principal
Zone: Trust
en OK:
Address Name: DNS#2

Comment: Servidor DNS secundario
Zone: Trust
en OK:
Address Name: SMTP

Comment: Servidor SMTP
Zone: Trust
en OK:
Address Name: POP3

Comment: Servidor POP3
Zone: Trust
2. Servidor DHCP
Network > DHCP > Edit (para ethernet1) > 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 máscara de red establecida para ethernet1 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 reenvíe ajustes de TCP/IP al módulo del
servidor DHCP (consulte “Propagar ajustes TCP/IP” en la página 243), deberá
introducir manualmente 172.16.10.1 y 255.255.255.0 en los campos “Gateway” y
“Netmask”.

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)
IP Address: 172.16.10.11
Ethernet Address: 1234 abcd 5678
Reserved: (seleccione)
IP Address: 172.16.10.112
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 ethernet1 dhcp server option domainname dynamic.com
set interface ethernet1 dhcp server option lease 0
set interface ethernet1 dhcp server option dns1 172.16.10.240
set interface ethernet1 dhcp server option smtp 172.16.10.25
set interface ethernet1 dhcp server option pop3 172.16.10.110

set interface ethernet1 dhcp server ip 172.16.10.10 to 172.16.10.19

set interface ethernet1 dhcp server ip 172.16.10.11 mac 1234abcd5678
set interface ethernet1 dhcp server ip 172.16.10.112 mac abcd1234efgh
set interface ethernet1 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 ethernet1 (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 “Propagar ajustes TCP/IP” en la página 243), deberá
establecer manualmente estas opciones: set interface ethernet1 dhcp server
option gateway 172.16.10.1 y set interface ethernet1 dhcp server option
netmask 255.255.255.0.
Personalizar opciones de servidor DHCP

Al especificar servidores DHCP para una interfaz, posiblemente sea necesario
especificar las 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
arriendamiento (“lease time”) de la dirección IP.
Los siguientes son servicios DHCP predefinidos, según se describe en RFC 2132,
DHCP Options and BOOTP Vendor Extensions.

Tabla 23: Servicios predefinidos DHCP
Terminología de la CLI de
Terminología ScreenOS Código de opción
Máscara de subred netmask 1
Opción del enrutador gateway 3
Servidor del sistema de dns1, dns2, dns3 6
nombre 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 la que las opciones predefinidas del servidor no son las

adecuadas, puede definir las opciones de servidor DHCP personalizadas. Por
ejemplo, para ciertas configuraciones de voz sobre IP (VoIP), es necesario enviar
información adicional de configuración que no es reconocida 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, que contiene la cadena “Server 4”
Código de opción 66, que contiene la dirección IP 1.1.1.1
Código de opción 160, que contiene 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 ethernet1 dhcp server option domainname dynamic.com
set interface ethernet1 dhcp server option custom 444 string “Server 4”
set interface ethernet1 dhcp server option custom 66 ip 1.1.1.1
set interface ethernet1 dhcp server option custom 160 integer 2004

Colocar el 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. En caso de una conmutación por 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.
Detectar el servidor DHCP

Cuando se inicia un servidor DHCP de 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 si hay algún servidor DHCP
presente siempre que arranca. Puede configurar el dispositivo para que no intente
detectar otro servidor DHCP en una interfaz activando 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.
NOTA: “Auto” es el modo predeterminado de detección de servidores DHCP en

dispositivos NetScreen-5XP y NetScreen-5XT. En otros dispositivos de seguridad
de Juniper Networks que admitan el servidor DHCP, el modo “Enable” es el modo
predeterminado de detección de servidores DHCP.
Activar la detección del servidor DHCP

En este ejemplo configurará el servidor DHCP de la interfaz ethernet1 para que,
antes de iniciarse, compruebe si hay algún servidor DHCP en la interfaz.
WebUI
Server Mode: Auto (seleccione)
CLI
set interface ethernet1 dhcp server auto
save

Desactivar la detección del servidor DHCP

En este ejemplo configurará el servidor DHCP de la interfaz ethernet1 para que se
inicie sin comprobar si hay algún servidor DHCP existente en la red.
WebUI
Server Mode: Enable (seleccione)
CLI
set interface ethernet1 dhcp server enable
save
NOTA: El servidor DHCP se puede activar ejecutando el comando CLI set interface
interface dhcp server service. 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 interface dhcp server service se desactiva el servidor
DHCP en el dispositivo NetScreen y también se elimina cualquier configuración
DHCP.
Asignar un dispositivo de seguridad como agente de retransmisión de DHCP

Cuando actúa como agente de retransmisión de DHCP, el dispositivo de seguridad
reenvía peticiones y asignaciones DHCP entre los hosts de una zona y el servidor
DHCP de otra zona. Los mensajes DHCP entre el dispositivo de seguridad y el
servidor DHCP se pueden transmitir en abierto o a través de un túnel VPN.
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 el modo de ruta ("Route") o
transparente ("Transparent"). Para las interfaces en el modo de ruta es necesario
configurar una directiva interzonal para el servicio predefinido DHCP-Relay. Para las
interfaces en el modo transparente, el cliente DHCP debe residir en la zona
V1-Trust, mientras que el servidor DHCP puede residir en la zona V1-Untrust o
V1-DMZ. Para las interfaces en modo transparente no se requiere ninguna directiva.
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 reenvía al cliente la primera respuesta recibida de un
servidor.
NOTA: Cuando un dispositivo de seguridad actúa como agente de retransmisión de

DHCP, 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.

La Figura 86 presenta 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 a su paso por la red no fiable.
Figura 86: Tráfico del agente de retransmisión de DHCP
Zona Trust Agente de retransmisión Túnel VPN en la

zona Untrust
Host DHCP
Servidor
Petición Petición
Host DHCP
Servidor
Asignación Asignación
Host DHCP
Servidor
Petición Petición
En este ejemplo, 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, situado 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 ethernet1 está asociada a la
zona Trust, tiene la dirección IP 180.10.10.1/24 y está en modo de ruta. La interfaz
ethernet3 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 87: Dispositivo como agente de retransmisión de DHCP

ethernet1 ethernet3 Servidor
180.10.10.1/24 1.1.1.1/24 DHCP
194.2.9.10
Agente de retransmisión
de DHCP
Conjunto de direcciones IP
180.10.10.2-
180.10.10.254
WebUI
1. Interfaces
en Apply:
Zone: Trust
en OK:
Zone: Untrust
2. Dirección
en OK:
Address Name: Servidor DHCP

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 (ID Protection)
VPN > 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: None

4. Agente de retransmisión de DHCP
Network > DHCP > Edit (para ethernet1) > DHCP Relay Agent: Introduzca los
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 ilustración de este ejemplo, el concepto aparece representando
como túnel atravesando el enrutador.

6. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), DHCP Server
Service: DHCP-Relay
Action: Tunnel
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 ethernet3
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 ethernet1 dhcp relay server-name 194.2.9.10
set interface ethernet1 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
Utilizar un dispositivo de seguridad como cliente DHCP

Cuando actúa 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 existen varias interfaces asociadas 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 servidor DHCP,
agente de retransmisión de DHCP o cliente DHCP al mismo tiempo, en una
misma interfaz no se puede configurar más de un papel de DHCP.

En este ejemplo, la interfaz asociada a la zona Untrust tiene una dirección IP

asignada dinámicamente. Cuando el dispositivo de seguridad solicita una dirección
IP al proveedor de servicios de Internet, recibe su dirección IP, la máscara de
subred, la dirección IP de la puerta de enlace y el periodo de vigencia de la
dirección arrendada. La dirección IP del servidor DHCP es 2.2.2.5.
Figura 88: Dispositivo como cliente DHCP
Zona Trust
LAN interna
1. Dirección IP solicitada para

ethernet3 (zona Untrust)
2. Dirección IP asignada
ISP
(servidor DHCP)
2.2.2.5
Internet
Zona Untrust
NOTA: Antes de poder configurar un sitio para el servicio DHCP, debe disponer de una
línea de abonado digital (DSL) y una cuenta con un proveedor de servicios de
Internet (ISP).
WebUI
Network > Interfaces > Edit (para ethernet3): Seleccione Obtain IP using
DHCP, después 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 ethernet3 dhcp client
set interface ethernet3 dhcp settings server 2.2.2.5
save

Propagar ajustes TCP/IP

Algunos dispositivos de seguridad pueden actuar como cliente del protocolo de
control dinámico de hosts (“Dynamic Host Control Protocol” o “DHCP”), recibiendo
de un servidor DHCP externo sus ajustes TCP/IP y dirección IP para cualquier
interfaz física en cualquier zona de seguridad. 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 a su
módulo predeterminado de servidor DHCP los ajustes TCP/IP obtenidos de su
módulo de cliente DHCP.
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)
NOTA: Si bien es posible configurar hasta ocho servidores DHCP en cualquier interfaz
física o interfaz VLAN, el servidor DHCP predeterminado del dispositivo reside en
una interfaz específica en cada plataforma. En el dispositivo NetScreen-5XP, el
servidor DHCP predeterminado reside en la interfaz de la zona Trust. En el
dispositivo NetScreen-5XT, el servidor DHCP predeterminado reside en la interfaz
de la zona Trust para el modo de puerto “Trust-Untrust”, en la interfaz ethernet1
para el modo de puerto “Dual-Untrust” y en la interfaz ethernet2 para los modos
de puerto “Home-Work” y “Combined”. Para otros dispositivos, el servidor DHCP
predeterminado reside en la interfaz ethernet1.
En la Figura 89 en la página 244, 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 reenvía como servidor DHCP a los clientes en la zona Trust. La interfaz de la
zona Untrust es el cliente DHCP y recibe las direcciones IP dinámicamente del ISP.

Figura 89: Transmisión del 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 interface 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 ethernet3 y como servidor DHCP en la interfaz
ethernet1. (El servidor DHCP predeterminado se encuentra en la interfaz
ethernet1).
Como cliente DHCP, el dispositivo de seguridad recibe una dirección IP para la

interfaz ethernet3 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 al módulo de servidor DHCP los ajustes TCP/IP que reciba.
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.
Ignorar las direcciones IP de la puerta de enlace predeterminada, la máscara de

red y los servidores SMTP y POP3, dando preferencia a las siguientes:
10.1.1.1 (dirección IP de la interfaz ethernet1)
255.255.255.0 (máscara de red para la interfaz ethernet1)
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 ciertas plataformas), antes de poder cambiar la puerta de
enlace predeterminada y la máscara de red debe eliminarse previamente el
conjunto de direcciones IP.
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: Esta característica solamente se puede establecer mediante CLI.
CLI
1. Cliente DHCP
set interface ethernet3 dhcp-client settings server 211.3.1.6
set interface ethernet3 dhcp-client settings update-dhcpserver
set interface ethernet3 dhcp-client settings autoconfig
set interface ethernet3 dhcp-client enable
2. Servidor DHCP
set interface ethernet1 dhcp server option gateway 10.1.1.1
set interface ethernet1 dhcp server option netmask 255.255.255.0
set interface ethernet1 dhcp server option wins1 10.1.2.42
set interface ethernet1 dhcp server option wins2 10.1.5.90
set interface ethernet1 dhcp server option pop3 211.1.8.172
set interface ethernet1 dhcp server option smtp 211.1.8.150
save
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 accesos, la facturación y el tipo de servicio se gestionan 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 gestionadas por ISP, que utilizan el protocolo PPPoE para el acceso a Internet
de sus clientes.
Protocolo punto a punto sobre Ethernet 245

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, para
después asociar la instancia a una interfaz. Cuando dos interfaces de Ethernet (una
principal y una de respaldo) están asociadas a la zona Untrust, puede configurar
una de ellas o ambas para PPPoE. Por ejemplo, en el modo de puerto “Dual
Untrust”, puede configurar la interfaz principal (ethernet3) para DHCP y la interfaz
de respaldo (ethernet2) para PPPoE o bien puede configurar PPPoE tanto para la
interfaz principal como para la de respaldo.
NOTA: Algunas plataformas, como el dispositivo NetScreen-5XT, admiten los modos de

puerto.
Configurar PPPoE
El ejemplo siguiente ilustra cómo definir la interfaz no fiable de un dispositivo de
seguridad para conexiones de PPPoE, y cómo iniciar el servicio PPPoE.
En este ejemplo, el dispositivo de seguridad recibe del ISP una dirección IP

asignada dinámicamente para su interfaz de la zona Untrust (ethernet3), al tiempo
que el dispositivo de seguridad asigna dinámicamente direcciones IP para 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 90: PPPoE
Untrust (ethernet3): modo DHCP Interfaz Trust: 172.16.30.10/24
Módem DSL
ISP
DSLAM
Concentrador AC Internet
(hub) Línea DSL
Servidor DNS
Principal
Rango de DHCP: Servidor DNS

172.16.30.2 - 172.16.30.5 Zona Trust Zona Untrust
secundario
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 (proporcionada por el ISP)
246 Protocolo punto a punto sobre Ethernet

WebUI
1. Interfaces y PPPoE
haga clic en OK:
Zone: Trust
haga clic en OK:
Zone: Untrust
Obtain IP using PPPoE: (seleccione)
User Name/Password: <name>/<password>
Network > Interfaces > Edit (para ethernet3): Para verificar su conexión
PPPoE, haga clic en Connect.
NOTA: Cuando se inicia una conexión PPPoE, el proveedor de servicios de Internet (ISP)
proporciona automáticamente las direcciones IP para la interfaz de la zona
Untrust y las direcciones IP 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 introducirlos manualmente en el
dispositivo de seguridad y en los hosts de la zona Trust.
2. Servidor DHCP
Network > Interfaces > Edit (para ethernet1) > DHCP: Seleccione DHCP
Server, después haga clic en Apply.
Network > Interfaces > Edit (para ethernet1) > 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 y haga clic en Return:
DNS#2: 0.0.0.0
Domain Name: (dejar en blanco)
Network > Interfaces > DHCP (para ethernet1) > New Address: Introduzca los

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 para sí mismas cuando intenten
establecer una conexión TCP/IP.
NOTA: Cuando se utiliza DHCP para asignar direcciones IP a los hosts de la zona Trust, el
dispositivo de seguridad reenvía 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 ethernet3
set pppoe username name_str password pswd_str
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.
Configurar PPPoE en las interfaces principal y de respaldo de la zona Untrust

En este ejemplo, el dispositivo NetScreen-5XT se encuentra en el modo Dual
Untrust. En el ejemplo siguiente configurará PPPoE para las interfaces principal
(ethernet3) y de respaldo (ethernet2) hacia la zona Untrust.
WebUI
Configuración de PPPoE para la interfaz ethernet3
Network > PPPoE > New: Introduzca los siguientes datos y haga clic en OK:
PPPoE instance: eth3-pppoe

Bound to Interface: ethernet3 (seleccione)
Username: user1
Password: 123456
Authentication: Any (seleccione)
Access Concentrator: ac-11
Configuración de PPPoE para la interfaz ethernet2
Network > PPPoE > New: Introduzca los siguientes datos y haga clic en OK:
PPPoE instance: eth2-pppoe

Bound to Interface: ethernet2 (seleccione)
Username: user2
Password: 654321
Authentication: Any (seleccione)
Access Concentrator: ac-22
CLI
1. Configuración de PPPoE para la interfaz ethernet3
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 ethernet3
2. Configuración de PPPoE para la interfaz ethernet2
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 ethernet2
save

Configurar múltiples sesiones de 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) para 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 usando otro nombre de usuario o nombres de dominio o bien
conectarse simultáneamente a otros ISP.
El número máximo de sesiones de PPPoE simultáneas en una interfaz física está

limitado únicamente por el número de subinterfaces permitidas por 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 no etiquetada no utiliza una etiqueta de LAN virtual para identificar la VLAN
correspondiente a una subinterfaz. La característica “Encap” asocia la subinterfaz a
la encapsulación PPPoE. Al hospedar múltiples subinterfaces, una sola interfaz
física puede hospedar múltiples instancias de PPPoE. Puede configurar cada
instancia de modo que acceda al concentrador de accesos (AC) especificado,
permitiendo que entidades independientes como ISP administren sesiones de
PPPoE a través de una sola interfaz. Para obtener más información sobre VLAN y
etiquetas VLAN, consulte Volumen 10: Sistemas virtuales.
Figura 91: PPPoE con múltiples sesiones
Múltiples subinterfaces Interfaz física única (p. ej. ethernet7)
isp_1 e7 isp_1ac
Tres instancias de PPPoE isp_2 e7.1 isp_2ac
Tres sesiones de 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 de PPPoE, especificará un

concentrador de accesos (AC) para cada una y luego iniciará cada instancia.
Instancia isp_1, nombre de usuario “user1@domain1”, contraseña

“swordfish”, asociada a la interfaz ethernet7. El AC se llama “isp_1ac”.
Instancia isp_2, nombre de usuario “user2@domain2”, contraseña “marlin”,

asociada a la subinterfaz ethernet7.1. El AC se llama “isp_2ac”.
Instancia isp_3, nombre de usuario “user3@domain3”, contraseña “trout”,

asociada a la subinterfaz ethernet7.2. El AC se llama “isp_3ac”.

WebUI
Interfaz y subinterfaces
1. Network > Interfaces > Edit (para ethernet7):
Zone Name: Untrust

2. Network > Interfaces > New (Sub-IF):

Zone Name: Untrust
3. Network > Interfaces > New (Sub-IF):

Zone Name: Untrust
Instancias de PPPoE y AC
4. Network > PPPoE > New:
PPPoE Instance: isp_1

Enable: Enable
Bound to Interface: ethernet7
Username: user1@domain1
Access Concentrator: isp_1ac

Enable: Enable
Bound to Interface: ethernet7.1

Enable: Enable
Bound to Interface: ethernet7.2

Iniciación del protocolo PPPoE

7. Network > PPPoE > Connect (para isp_1)
CLI
1. Interfaz y subinterfaces
set interface ethernet7.1 encap pppoe zone untrust
set interface ethernet7.2 encap pppoe zone untrust
2. Instancias de PPPoE y CAs
set pppoe name isp_1 username user1@domain1 password swordfish
set pppoe name isp_1 interface ethernet7
set pppoe name isp_1 ac isp_1ac
set pppoe name isp_2 username user2@domain2 password marlin
set pppoe name isp_2 interface ethernet7.1
set pppoe name isp_3 username user3@domain3 password trout
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 admitan PPPoE en modo activo/pasivo pueden
asumir el fallo 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.
Dado 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
maestro. Por lo tanto, puede mantener la comunicación con el concentrador de
accesos después del fallo del dispositivo principal. Esto es necesario cuando la
interfaz PPPoE está soportando 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 alta disponibilidad, consulte el Volumen 11: Alta disponibilidad.

Claves de licencia
La característica de la clave de licencia permite ampliar las prestaciones del
dispositivo de seguridad de Juniper Networks sin tener que actualizar a otro
dispositivo o imagen del sistema. Se pueden comprar los siguientes tipos de claves:
Avanzada
Capacidad
Extendido
Virtualización
GTP
Vsys
IDP
Cada dispositivo de seguridad se suministra con un conjunto estándar de

características habilitadas y puede admitir la activación de características
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. Obtenga su código de autorización y el número de serie del dispositivo.
Código de autorización: Una clave de aprobación para generar y activar la

clave de licencia que usted o su empresa adquirió para el dispositivo de
seguridad de Juniper Networks. Nota: El código de autorización se necesita para
generar su clave de licencia (que no es la clave de licencia real).
Número de serie del dispositivo: Es un código de 16 caracteres único que

Juniper Networks utiliza para identificar su dispositivo de seguridad específico
cuando genera las claves de licencia. El número de serie del dispositivo lo
puede encontrar en la parte inferior o trasera del dispositivo. También es
posible encontrar el número de serie en la sección de información del
dispositivo en el GUI o al ejecutar el comando “get system” en CLI.
2. Regístrese en el 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, después siga las instrucciones
que se encuentran en la interfaz del usuario del sistema.
3. El sistema de administración de licencias de Juniper proporciona las claves de

licencia en una de estas dos maneras:
Al descargar la clave de licencia a su computadora.
Al recibir un correo electrónico con su clave de licencia.
Claves de licencia 253

4. Instale la clave de licencia en una de las siguientes maneras:
WebUI
Elija Configuration > Update > ScreenOS/Keys >, seleccione License Key
Update (características) >, haga clic en Browse >, seleccione el archivo con
su clave de licencia y después haga clic en Apply.
CLI
exec license-key key_num
Registrar y activar los servicios de suscripción

Para que su dispositivo de seguridad de Juniper Networks puede recibir el servicio
regular de suscripción para patrones antivirus (AV), firmas DI (Deep Inspection),
antispam o filtrado de Web, debe hacer lo siguiente:
Adquirir una suscripción
Registrar la suscripción
Descargar la clave de suscripción
Al descargar la clave de licencia de suscripción, sus servicios se activan en el

dispositivo por el periodo de tiempo que se adquirió. El proceso específico de
activación de servicios depende de los servicios que adquirió y del método que
utilizó para adquirirlos.
Servicio de prueba
Para que usted pueda utilizar los servicio de AV, DI, antispam o filtrado de web, el
dispositivo de seguridad le otorga un periodo de prueba. Durante este tiempo, el
dispositivo puede obtener servicios temporalmente. Para descargar las claves de
licencia de prueba que se pueden elegir del servidor de autorización, utilice el
comando CLI exec license-key update trials.
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 el botón Retrieve Subscriptions Now en la página
“Configuration > Update > ScreenOS/Keys”. Por medio de esta acción
obtendrá una clave DI única, válida para un solo día.
Si su dispositivo se suministra con el servicio AV incluido en el momento de la

compra, tendrá preinstalado el servicio de prueba. Este servicio de prueba dura
hasta 60 días.
Anti-spam (contra bombardeo de publicidad)
Ningún dispositivo de seguridad de Juniper Networks se suministra con filtrado

web habilitado. Esta característica no tiene un servicio de prueba.
ADVERTENCIA: 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.
254 Registrar y activar los servicios de suscripción

Actualizar claves de suscripción

Si cuenta con un software instalado con fecha de vencimiento en el dispositivo de
seguridad, el dispositivo de seguridad se debe conectar periódicamente al servidor
autorizado para descargar las claves de suscripción. El dispositivo se conecta al
servidor autorizado o sistema de administración de licencias, bajo una de las
siguientes condiciones:
La clave tiene una fecha de caducidad de dos meses
La clave tiene una fecha de caducidad de un mes
La clave tiene una fecha de caducidad de dos semanas
La clave caduca
30 días después de que la clave caduque
NOTA: Para borrar una sola clave de licencia del archivo de claves, utilice el comando CLI
exec license-key delete name_str.
Agregar antivirus, filtrado web, antispam y DI a un dispositivo

Después de adquirir las suscripciones a antivirus, filtrado web, antispam (contra
bombardeo de publicidad) y DI (Deep Inspection) para agregarlas a su dispositivo
de seguridad de Juniper Networks, lleve a cabo los siguientes pasos para activar los
servicios.
1. Después de solicitar las suscripciones, recibirá un código de autorización por

correo electrónico, directamente de Juniper Networks o de su VAR autorizado.
Dicho código es un documento legible que contiene la información que
necesita 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 para el dispositivo.
4. Confirme que su dispositivo puede conectarse a Internet.
5. Descargue la clave de suscripción en el dispositivo. Puede hacerlo de una de

dos maneras:
En la WebUI, haga clic en el botón Retrieve Subscriptions Now desde la

página “Configuration > Update > ScreenOS/Keys”.
Con la interfaz de línea de comandos (CLI), ejecute el comando siguiente:
exec license-key update
6. Debe restablecer (“resetear”) el dispositivo después de cargar la clave.
Registrar y activar los servicios de suscripción 255

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 cómo
configurar su dispositivo de seguridad para estos servicios, consulte las siguientes
secciones:
“Reensamblar fragmentos” en la página 4-60
“Análisis antivirus” en la página 4-63
“Filtrado anti-spam” en la página 4-84
“Filtrado de Web” en la página 4-88
Reloj del sistema

Es importante que su dispositivo de seguridad de Juniper Networks siempre tenga
la hora exacta. Entre otras cosas, la hora de su dispositivo de seguridad afecta a la
configuración de los túneles VPN y a la sincronización de programaciones. Primero,
para asegurarse de que el dispositivo siempre esté a la hora exacta, debe ajustar el
reloj del sistema a la hora actual. A continuación, puede habilitar la opción del
horario de verano (“daylight saving time”) y configurar hasta tres servidores NTP
(uno principal y dos de respaldo) que el dispositivo de seguridad utilizará para
actualizar periódicamente su 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 del horario

de verano en el reloj de su computadora.
2. Haga clic en Yes para sincronizar el reloj del sistema y ajustarlo según el horario
de verano o invierno, o bien en No para sincronizarlo sin el ajuste de horario de
verano.
Con CLI, el reloj se pone en hora manualmente introduciendo la fecha y hora

mediante el comando “set clock mm/dd/yyyy hh:mm:ss”.
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
(“Greenwich Mean Time”, hora media de Greenwich). Por ejemplo, si el huso
horario local del dispositivo es la hora estándar del Pacífico (“Pacific Standard Time”
o “PST”), tendrá un retraso de 8 horas con respecto a GMT. Por lo tanto, deberá
poner el reloj en -8.
256 Reloj del sistema

Para establecer el huso horario mediante WebUI:
Configuration > Date/Time > Set Time Zone_hours_minutes from GMT
Para establecer el huso horario mediante CLI:
ns -> set clock timezone number (número entre -12 y 12)
o bien
ns -> set ntp timezone number (número entre -12 y 12)
Protocolo de hora de la red

Para asegurarse de 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.
Configurar 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 se
configura el dispositivo de seguridad para sincronizar el reloj del sistema de forma
automática, efectúa una consulta en cada servidor NTP configurado, repasando los
tres secuencialmente. 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, etc., hasta obtener una respuesta válida de
alguno de los servidores NTP configurados en el 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 únicamente consultará a ese servidor.
Si no especifica ningún servidor NTP, el dispositivo consultará, uno por uno, a cada
servidor NTP configurado en el dispositivo. Puede especificar un servidor NTP
utilizando su dirección IP o su nombre de dominio.
Configurar un servidor de respaldo del protocolo de hora de la red

Puede especificar una interfaz individual como la dirección de origen para dirigir las
solicitudes del protocolo de hora de la red (NTP) del dispositivo a través de un túnel
VPN al servidor principal NTP o a un servidor de respaldo, según sea necesario.
Entre otros tipos de interfaces, puede elegir una interfaz de bucle invertido para que
realice esta función.
El dispositivo de seguridad envía solicitudes NTP desde una interfaz de origen y

utiliza, si así lo desea, una clave previamente compartida y encriptada cuando envía
las solicitudes NTP al servidor NTP. La clave ofrece autenticación.
En el siguiente ejemplo, puede configurar el servidor NTP principal y dos servidores

NTP de respaldo asignando una dirección IP a cada servidor. A continuación, debe
ajustar cada servidor para que envíe las solicitudes NTP desde la interfaz Trust.
Después de eso, configure el identificador de claves y la clave previamente
compartida a cada uno de los servidores.
Reloj del sistema 257

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 en la lista.
Preshared Key: !2005abc
Backup Server1 IP/Name: 1.1.1.2
Primary server Key ID: 10
Primary server Key ID: 10
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 es la máxima 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 es inferior al valor
máximo de desfase establecido. Por ejemplo, si el valor máximo de desfase horario
es de 3 segundos, la hora en el reloj del sistema del dispositivo son las 4:00:00 y el
servidor NTP envía 4:00:02 como hora actual, la diferencia entre ambos es
aceptable y el dispositivo puede actualizar su reloj. Si el desfase es superior al
máximo establecido, el dispositivo no sincroniza su reloj y procede a intentar
consultar al primer servidor NTP de respaldo configurado en el dispositivo. Si el
dispositivo no recibe una contestación válida después de intentar consultar a todos
los servidores NTP configurados, 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 CLI, el dispositivo de seguridad no comprueba el desfase horario
máximo. En lugar de ello, si recibe una respuesta válida, el dispositivo muestra un
mensaje informando sobre el servidor NTP alcanzado, el desfase horario existente
con él y el método de autenticación 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, genera un mensaje de

vencimiento de tiempo de espera. Este mensaje aparece solamente después de que
el dispositivo haya intentado sin éxito alcanzar a todos los servidores NTP
configurados en el dispositivo.
NOTA: Al enviar consultas mediante CLI, puede cancelar la petición actual presionando
Ctrl-C en el teclado.
Protocolos NTP y NSRP

El protocolo de redundancia de NetScreen (NSRP) contiene un mecanismo para
sincronizar el 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 horaria NSRP, introduzca el
siguiente comando:
set ntp no-ha-sync
Ajustar un valor de desfase horario máximo en un servidor NTP

En el ejemplo siguiente configurará el dispositivo de seguridad para actualizar su
reloj a intervalos de cinco minutos consultando 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
Reloj del sistema 259

Asegurar 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. No impide a los interlocutores
externos ver los datos, pero evita que cualquier usuario pueda manipularlos.
Para habilitar la autenticación del tráfico NTP, debe asignar una identificación de
clave y una clave previamente compartida únicas a cada servidor NTP que
configure en un dispositivo de seguridad. La identificación 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.
Existen dos tipos de autenticación para el tráfico NTP:
Required (requerida)
Preferred (preferida)
Cuando se selecciona la autenticación Required, el dispositivo de seguridad debe

incluir la información de autenticación (identificación 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 una identificación 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.
Al seleccionar la autenticación Preferred, el dispositivo de seguridad primero debe

funcionar como si estuviese en el modo “Required”, intentando autenticar todo el
tráfico NTP. Si todos los intentos de autenticación fallan, el dispositivo de seguridad
pasa a funcionar como si no se hubiese seleccionado ninguna autenticación. Envía
paquetes a un servidor NTP, sin incluir identificación de clave ni suma de
comprobación. En esencia, aunque existe cierta preferencia por la autenticación, si
ésta falla el dispositivo de seguridad sigue permitiendo el tráfico NTP.

Índice
A DIP ...............................................................101, 144 a 148
alarmas, umbrales de ..................................................177 conjuntos ................................................................174
ALG conjuntos, modificar .............................................147
MS RPC ...................................................................133 grupos ...........................................................157 a 159
para servicios personalizados ..............................172 PAT ..................................................................145, 146
RTSP .......................................................................134 puerto fijo ...............................................................147
Sun RPC ..................................................................131 direcciones
alta disponibilidad definición................................................................170
véase HA en directivas ...........................................................170
ancho de banda ...........................................................178 entradas en la libreta de direcciones ........106 a 110
administrar ............................................................197 ID de IP, de host y de red.......................................55
garantizado ............................................178, 197, 203 privadas ....................................................................56
máximo ..................................................178, 197, 203 públicas.....................................................................55
máximo ilimitado ..................................................198 Direcciones IP
ARP..................................................................................84 Administración ........................................................97
ARP, dirección IP de entrada ........................................87 direcciones IP
asignación de tráfico ...................................................197 ID de host .................................................................55
automática .............................................................198 ID de red...................................................................55
prioridades del servicio ........................................202 interfaces, seguimiento de .....................................65
autenticación privadas ....................................................................55
Allow Any ...............................................................176 públicas.....................................................................55
directivas ................................................................174 puertos, definición para cada uno.......................106
usuarios ..................................................................174 rangos de direcciones privadas .............................56
autenticación en tiempo de ejecución ......................175 secundarias ..............................................................59
secundarias, enrutamiento entre ..........................59
C zonas de seguridad L3 ....................................54 a 56
claves de licencia .........................................................253 direcciones IP secundarias ...........................................59
claves, licencia .............................................................253 direcciones privadas ......................................................56
CLI, set arp always-on-dest .....................................76, 79 direcciones públicas ......................................................55
colas de prioridad direcciones, denegación de ........................................191
de ancho de banda ...............................................202 directivas...........................................................................3
predeterminadas ...................................................202 acciones ..................................................................171
Conjuntos de direcciones IP administración .......................................................179
véase Conjuntos de DIP administrar ancho de banda ................................197
Conjuntos de IP dinámico (DIP).................................174 alarmas ...................................................................177
aplicación, enlazar explícitamente servicio a ....172
D asignación de tráfico .............................................178
denegación de direcciones .........................................191 autenticación..........................................................174
DHCP ..............................................................98, 102, 246 cambiar...................................................................194
agente de retransmisión.......................................229 colocar al principio ........................................173, 195
cliente .....................................................................229 contexto de una directiva .....................................190
HA ...........................................................................236 copia de seguridad de la sesión HA ....................176
servidor ..................................................................229 Deep Inspection (DI) .............................................173
DiffServ .................................................................178, 204 denegación de direcciones ...................................191
véase también DS Codepoint Marking denegar ...................................................................171
Índice IX-I
desactivar ............................................................... 194 servidores ...............................................................247

direcciones ............................................................. 170 tabla de estado ......................................................223
direcciones en ....................................................... 170 DS Codepoint Marking ........................................198, 204
edición .................................................................... 194 DSL ........................................................................242, 246
elementos requeridos ........................................... 164
eliminar .................................................................. 196 E
funciones de .......................................................... 163 enrutadores virtuales
globales .................................................. 166, 179, 189 véase VR
grupos de DIP ........................................................ 158 Etiquetas VLAN ................................................................4
grupos de direcciones........................................... 170 etiquetas VLAN ................................................................4
grupos de servicios ............................................... 142
grupos de usuarios de acceso telefónico F
a VPN ................................................................... 170 filtrado de URL
habilitar .................................................................. 194 véase filtrado de web
ID ............................................................................ 170 filtrado de web .............................................................176
interzonales ........................................... 165, 179, 183 flujo de paquetes ................................................... 11 a 13
intrazonales ........................................... 165, 179, 187
L2TP ........................................................................ 173 G
libro de servicios ................................................... 111 gestión de colas de prioridades .................................202
límite máximo ....................................................... 109 gráficos de historial .....................................................177
listas de conjuntos de directivas ......................... 167 grupos
múltiples elementos por componente................ 190 direcciones .............................................................108
NAT-dst................................................................... 174 servicios..................................................................142
NAT-src ................................................................... 174 grupos de direcciones .........................................108, 170
nombre ................................................................... 172 crear ........................................................................110
ocultar ............................................................ 194, 195 edición ....................................................................110
orden ...................................................................... 196 entradas, eliminar .................................................110
permitir .................................................................. 171 opciones .................................................................108
rechazo ................................................................... 171 grupos de servicios ............................................ 142 a 144
recuento ................................................................. 177 crear ........................................................................143
registro de tráfico .................................................. 176 eliminar ..................................................................144
reglas internas ....................................................... 168 modificar ................................................................143
reordenar ............................................................... 195 grupos de servicios (WebUI) .......................................142
secuencia de consulta ........................................... 167
servicios ................................................................. 170 H
servicios en .................................................... 111, 170 HA
sistema raíz ............................................................ 168 DHCP ......................................................................236
sistemas virtuales .................................................. 168 HA virtual, interfaces de .........................................47
tareas programadas .............................................. 177 interfaces ..................................................................47
tipos .............................................................. 165 a 166 véase también NSRP
túnel ........................................................................ 171 historial, gráficos .........................................................177
túneles L2TP .......................................................... 173 huso horario .................................................................256
verificar .................................................................. 194
VPN ......................................................................... 172
VPN bidireccionales .............................................. 172
I
interfaces
zonas de seguridad ............................................... 170
activas físicamente..................................................62
directivas de acceso
activas lógicamente ................................................62
véase directivas
agregadas .................................................................46
Directivas L2TP ............................................................ 173
asociar a zonas ........................................................54
DNS ............................................................................... 221 cambios de estado ..................................................62
búsquedas .............................................................. 222
conexiones, supervisión de....................................64
consultas de dominios .......................................... 227
de bucle invertido ...................................................60
división de direcciones ......................................... 227 DIP ..........................................................................144
encapsulamiento a servidores ............................. 227 direccionar ...............................................................54
IX-II Índice
Índice
direcciones IP secundarias .....................................59 preconfigurado ......................................................111

físicas ..........................................................................3 libro de servicios
físicas en zonas de seguridad ................................45 entradas, eliminar (CLI) ........................................127
HA .............................................................................47 entradas, modificar (CLI) ......................................126
HA virtual .................................................................47
inactivas físicamente ..............................................62 M
inactivas lógicamente .............................................62 máscaras de red .....................................................55, 170
MGT...........................................................................47 MGT, interfaz ..................................................................47
modificar ..................................................................56 MIP ..................................................................................12
predeterminadas .....................................................56 MIP, a una zona con NAT basada en interfaces ..........96
redundantes .............................................................46 modo de ruta ......................................................100 a 103
seguimiento de IP (véase seguimiento de IP) ajustes de interfaz .................................................101
tabla de interfaces, visualizar ................................52 NAT-src ...................................................................101
túnel ............................................................ 48, 48 a 51 modo NAT .............................................................94 a 100
túnel de NAT basada en directivas........................48 ajustes de interfaz ...................................................97
visualizar tabla de interfaces .................................52 tráfico a la zona Untrust ...................................81, 96
VLAN1.......................................................................83 modo transparente ................................................82 a 94
VSI .............................................................................47 ARP/trace-route .......................................................85
zona de función .......................................................47 bloquear tráfico no ARP .........................................84
zona de función de HA ...........................................47 bloquear tráfico no IP .............................................84
zonas de seguridad L3 ............................................54 inundación ...............................................................85
zonas, separar de ....................................................54 opciones unicast ......................................................85
interfaces agregadas ......................................................46 rutas ..........................................................................84
interfaces de bucle invertido ........................................60 tráfico broadcast ......................................................83
interfaces de HA virtual ................................................47 modos
Interfaces de ScreenOS Combined .................................................................37
físicas ..........................................................................3 disponibilidad del modo de puerto .......................34
subinterfaces..............................................................4 Dual DMZ .................................................................39
zonas de seguridad ...................................................3 Dual Untrust .............................................................36
interfaces de túnel .........................................................48 Home-Work..............................................................35
definición .................................................................48 NAT, tráfico a la zona Untrust ...............................81
NAT basada en directivas .......................................48 puerto .......................................................................33
interfaces de zonas de función ....................................47 Transparente ............................................................82
administración.........................................................47 Trust-Untrust ............................................................34
HA .............................................................................47 modos de puertos ..........................................................33
interfaces, supervisión de ..................................... 70 a 75 Ajuste ........................................................................40
bucles ........................................................................71 Combined .................................................................37
zonas de seguridad .................................................75 disponibilidad ..........................................................34
IP de administración .....................................................97 Dual DMZ .................................................................39
ISP .................................................................................227 Dual Untrust .............................................................36
Home-Work..............................................................35
L Modo DMZ/Dual Untrust.........................................38
libretas de direcciones predeterminados .....................................................34
direcciones, agregar ..............................................107 Trust/Untrust/DMZ (extendido) ..............................38
direcciones, eliminar ............................................110 Trust-Untrust ............................................................34
direcciones, modificar ..........................................107 MS RPC ALG, definido .................................................133
entradas..................................................................106
entradas de grupos, editar ...................................110 N
grupos .....................................................................108 NAT basada en directivas, interfaces de túnel de.......48
véase también direcciones NAT-src, modo de ruta .................................................101
libro de servicio, servicios NetInfo ..........................................................................230
agregar....................................................................126 niveles de prioridad
personalizado (CLI) ...............................................126 de ancho de banda ................................................202
personalizados .......................................................111
Índice IX-III
NSRP RTSP ALG

copia de seguridad de la sesión HA .................... 176 códigos de estado..................................................137
DHCP ...................................................................... 236 definido ..................................................................134
grupos de DIP .............................................. 157 a 159 métodos de petición .............................................135
interfaces redundantes ........................................... 46 servidor en dominio privado ...............................139
sincronización NTP ............................................... 259 servidor en dominio público ................................140
VSI ............................................................................. 47
NTP ..................................................................... 257 a 260 S
desfase horario máximo ...................................... 258 SCREEN, zona MGT .......................................................28
múltiples servidores.............................................. 257 ScreenOS
servidores............................................................... 257 directivas ....................................................................3
servidores seguros ................................................ 260 flujo de paquetes ............................................. 11 a 13
sincronización NSRP............................................. 259 sistemas virtuales ....................................................10
tipos de autenticación .......................................... 260 vista general ...............................................................1
zona de seguridad global..........................................2
O zona global ...............................................................28
opción de aplicación, en directivas ........................... 172 zonas ................................................................ 25 a 33
opciones “unicast” desconocidas ........................ 84 a 89 zonas de función .....................................................32
ARP ................................................................... 86 a 89 zonas de seguridad .............................................2, 28
inundación ....................................................... 85 a 86 zonas de seguridad predefinidas .............................2
trace-route ................................................................ 87 zonas de túnel .........................................................28
seguimiento de IP
P interfaces compartidas ...........................................65
parámetros del sistema .............................................. 259 interfaces compatibles............................................65
PAT................................................................................. 145 opción “dynamic” ...................................................66
personalizados, servicios ............................................ 125 peso ..........................................................................67
ALG ......................................................................... 172 redireccionar el tráfico ................................... 65 a 80
Proveedor de servicios de Internet (ISP) .................. 227 umbral de fallos del objeto ....................................66
vsys ...........................................................................65
Q seguimiento de IP, fallo del
QoS (calidad del servicio) ........................................... 197 interfaz de entrada, en ................................... 78 a 80
interfaz de salida, en ...................................... 76 a 77
R umbral de IP supervisado ......................................66
Rango IP dinámico(DIP) ............................................. 147 servicios ........................................................................111
red, ancho de banda ................................................... 197 definición ...............................................................170
registro .......................................................................... 176 en directivas ..........................................................170
reglas, derivadas de directivas ................................... 168 ICMP .......................................................................130
reloj del sistema................................................. 256 a 260 lista desplegable ....................................................111
fecha y hora ........................................................... 256 umbral del tiempo de espera ...............................127
huso horario .......................................................... 256 servicios ICMP..............................................................130
sincronización con cliente ................................... 256 códigos de mensaje ..............................................130
RFC tipos de mensaje ...................................................130
1349, “Type of Service in the Internet servicios personalizados .............................................125
Protocol Suite”................................................178 servicios personalizados, en raíz y vsys ....................125
1918, Address Allocation for Private Internets .....56 servicios, personalizados
2132, DHCP Options and BOOTP en vsys....................................................................125
Vendor Extensions ..........................................234 Sistema de nombres de dominio
2326, Real Time Streaming Protocol véase DNS
(RTSP) ....................................................134, 138 sistema, reloj
2474, “Definition of the “Differentiated Services” véase reloj del sistema
Field (DS Field) in the IPv4 and IPv6 Headers”..178 sistemas virtuales ..........................................................10
792, Internet Control Messages Protocol ............130 subinterfaces ....................................................................4
RSH ALG ....................................................................... 131 crear (sistema raíz) .................................................57
eliminar ....................................................................58
IX-IV Índice
Índice
Sun RPC ALG seguridad global ........................................................2

definido ..................................................................131 túnel ..........................................................................28
supuestos de llamadas ..........................................131 VLAN ...................................................................33, 83
suscripciones zonas de seguridad ....................................................2, 28
registro y activación .................................... 254 a 256 determinación de la zona de destino....................12
servicio temporal...................................................254 determinación de la zona de origen .....................11
global ..........................................................................2
T predefinido .................................................................2
tareas programadas .............................................160, 177 zonas de seguridad e interfaces .....................................3
trace-route ......................................................................87 zonas de seguridad, interfaces .....................................45
Traducción de direcciones de puertos físicas ........................................................................45
véase PAT zonas de seguridad, interfaces de
tráfico subinterfaces ............................................................46
asignación ..............................................................197 zonas de, seguridad
prioridad .................................................................178 interfaces, supervisión de ......................................75
recuento .................................................................177 zonas, ScreenOS ....................................................25 a 33
registro ...................................................................176 interfaces de seguridad.............................................3
predefinido .................................................................2
U zonas, seguridad
usuarios de autenticación interfaces, físicas .....................................................45
autenticación en tiempo de ejecución ................175 subinterfaces ............................................................46
autenticación previa a la directiva ......................175
proceso de autenticación en tiempo
de ejecución.........................................................175
WebAuth ................................................................175
V
VIP ...................................................................................12
VIP, a una zona con NAT basada en interfaces ..........96
VLAN1
interfaz ...............................................................83, 89
zonas.........................................................................83
VPN
a una zona con NAT basada en interfaces ...........96
directivas ................................................................172
zonas de túnel .........................................................28
VR
introducción ...............................................................4
reenviar tráfico entre dos .........................................5
W
WebAuth, proceso de autenticación previo a directivas
175
Z
zona VLAN ......................................................................83
zonas ....................................................................... 25 a 33
capa 2 .......................................................................83
definición .................................................................30
edición ......................................................................31
función .....................................................................32
función, interfaz MGT .............................................47
global ........................................................................28
interfaces de seguridad ..........................................45
Í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
Writers: Anita Davey, Carrie Nowocin

ii
Contenido
Convenciones CLI ................................................................................... viii
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
Copiar los archivos de ayuda en una unidad local ............................... 3
Desvío de WebUI a la nueva ubicación de la ayuda............................. 3
Protocolo de transferencia de hipertexto ................................................... 3
Identificación de sesión ............................................................................. 4
Secure Sockets Layer ................................................................................. 5
Configurar SSL .................................................................................... 7
Reenviar HTTP a SSL........................................................................... 8
Administración a través de la interfaz de línea de comandos........................... 9
Telnet ........................................................................................................ 9
Asegurar las conexiones Telnet ............................................................... 10
Secure Shell ............................................................................................. 11
Requisitos del cliente ........................................................................ 12
Configuración básica de SSH en el dispositivo................................... 12
Autenticación .................................................................................... 14
SSH y Vsys ........................................................................................ 16
Clave del host.................................................................................... 16
Ejemplo: SSHv1 con PKA para inicios de sesión de automatizados ... 17
Secure Copy ............................................................................................ 18
Consola serie ........................................................................................... 19
Puerto de módem.................................................................................... 20
Administración a través de NetScreen-Security Manager................................ 20
Iniciar la conectividad entre el agente de NSM y el sistema MGT............. 21
Habilitar, inhabilitar y desactivar el agente de NSM ................................. 22
Ajustar la dirección IP del servidor principal del sistema
de administración ............................................................................. 23
Ajustar la generación de informes de alarmas y de estadísticas............... 23
Sincronizar la configuración .................................................................... 24
Ejemplo: Visualización del estado de la configuración.......................25
Ejemplo: Consulta del hash de la configuración ................................ 25
Consultar la marca de hora de configuración........................................... 26
Controlar el tráfico administrativo.................................................................. 26
Interfaces MGT y VLAN1.......................................................................... 27
Contenido iii
Ejemplo: Administración a través de la interfaz MGT ........................ 27

Ejemplo: Administración a través de la interfaz VLAN1..................... 28
Ajustar las opciones de la interfaz administrativa .................................... 28
Ajustar las direcciones IP de administración para múltiples interfaces .... 29
Niveles de administración .............................................................................. 31
Administrador raíz................................................................................... 32
Administrador de lectura/escritura........................................................... 32
Administrador de sólo lectura.................................................................. 32
Administrador de sistema virtual............................................................. 33
Administrador de sólo lectura del sistema virtual .................................... 33
Definir usuarios con permisos de administrador ............................................ 33
Ejemplo: Adición de un administrador de sólo lectura ............................. 33
Ejemplo: Modificación de un administrador ............................................ 34
Ejemplo: Eliminación de un administrador.............................................. 34
Ejemplo: Configuración de las cuentas de administrador para las
conexiones de acceso telefónico ....................................................... 34
Ejemplo: Borrado de una sesión de administrador .................................. 35
Asegurar el tráfico administrativo .................................................................. 36
Cambiar el número de puerto.................................................................. 37
Cambiar nombre y contraseña de inicio de sesión del administrador...... 37
Ejemplo: Cambio del nombre de inicio de sesión y la contraseña
de un usuario administrador....................................................... 38
Ejemplo: Cambio de su propia contraseña ........................................ 39
Ajustar la longitud mínima de la contraseña del administrador raíz .. 39
Restablecer el dispositivo con los ajustes predeterminados de fábrica..... 40
Restringir el acceso administrativo .......................................................... 41
de trabajo ................................................................................... 41
Ejemplo: Restricción de la administración a una subred ................... 41
Restringir el acceso del administrador raíz desde la consola ............. 41
Túneles de VPN para tráfico administrativo ............................................. 42
Administración a través de un túnel VPN de clave manual basado
en rutas ...................................................................................... 43
en directivas ............................................................................... 47
Capítulo 2 Supervisar dispositivos de seguridad 53

Almacenar la información del registro ........................................................... 53
Registro de eventos........................................................................................ 54
Ver el registro de eventos según nivel de gravedad y palabra clave ......... 55
Clasificar y filtrar el registro de eventos ................................................... 56
Descargar el registro de eventos.............................................................. 57
Ejemplo: Descarga del registro de eventos completo ........................ 57
Ejemplo: Descarga de los eventos críticos del registro.......................58
Registro de tráfico.......................................................................................... 58
Visualizar el registro de tráfico.................................................................59
Ejemplo: Visualización de las entradas del registro de tráfico............ 59
Clasificar y filtrar el registro de tráfico............................................... 60
Ejemplo: Clasificación del registro de tráfico por horas ..................... 60
Descargar el registro de tráfico ................................................................ 61
Registro propio ..............................................................................................61
Visualizar el registro propio ..................................................................... 62
Clasificar y filtrar el registro propio ................................................... 62
Ejemplo: Filtro del registro propio por horas ..................................... 63
iv Contenido
Contenido
Descargar el registro propio..................................................................... 63

Descargar el registro de recuperación de equipos .......................................... 63
Alarmas de tráfico.......................................................................................... 64
Ejemplo: Detección de intrusiones basada en directivas.......................... 65
Ejemplo: Notificación de sistema en peligro ............................................ 65
Ejemplo: Envío de alertas de correo electrónico ...................................... 66
Syslog ............................................................................................................ 67
Ejemplo: Habilitación de múltiples servidores Syslog............................... 68
Habilitar WebTrends para eventos de notificación................................... 68
Protocolo simple de administración de redes................................................. 69
Vista general de la implementación ......................................................... 71
Definir una comunidad SNMP de lectura/escritura................................... 72
Túneles VPN para tráfico administrativo autogenerado.................................. 73
Ejemplo: Tráfico autogenerado a través de túnel basado en rutas ........... 75
Ejemplo: Tráfico autogenerado a través de túnel basado en directivas .... 82
Visualizar contadores de pantalla ................................................................... 88
Apéndice A Archivos MIB para SNMP A-I

Carpetas de archivos MIB del nivel principal ............................................... A-II
Carpetas de archivos MIB del segundo nivel ............................................... A-IV
netscreenProducts ................................................................................ A-IV
netScreenIds......................................................................................... A-IV
netscreenVpn ....................................................................................... A-IV
netscreenQos ....................................................................................... A-IV
netscreenSetting.................................................................................... A-V
netscreenZone....................................................................................... A-V
netscreenPolicy ..................................................................................... A-V
netscreenNAT ........................................................................................ A-V
netscreenAddr ....................................................................................... A-V
netscreenService ................................................................................... A-V
netscreenSchedule................................................................................ A-VI
netscreenVsys ...................................................................................... A-VI
netscreenResource ............................................................................... A-VI
netscreenIp........................................................................................... A-VI
netscreenVR ......................................................................................... A-VI
Índice ........................................................................................................................IX-I
Contenido v
vi Contenido
Los dispositivos de seguridad de Juniper Networks ofrecen distintas formas de

administrar los equipos, ya sea de forma local o remota. El Volumen 3:
Administración contiene los siguientes capítulos:
En el Capítulo 1, “Administración,” 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.
En el Capítulo 2, “Supervisar dispositivos de seguridad,” se explican los

diversos métodos de supervisión y se ofrecen instrucciones para interpretar los
resultados de dicha supervisión.
En el Apéndice A “Archivos MIB para SNMP,” se enumeran y describen

brevemente los archivos de base de información de administración
(“Management Information Base” o MIB) disponibles para los compiladores
MIB.

“Convenciones CLI” on page viii
“Convenciones para las ilustraciones” on page ix
“Convenciones de nomenclatura y conjuntos de caracteres” on page x
“Convenciones de la interfaz gráfica (WebUI)” on page xi
Convenciones del documento vii

Convenciones CLI
En ejemplos:


En texto:
viii Convenciones del documento



Sistema autónomo una única subred
(ejemplo: 10.1.1.0/24)

Internet

dinámicas (DIP)

Equipo portátil
Negro = interfaz de zona externa
Interfaz de túnel
Servidor
Túnel VPN
Concentrador (hub)
Enrutador
Teléfono IP
Conmutador
Convenciones del documento ix





Caracteres ASCII desde el 32 (0x20 en notación hexadecimal) al 255 (0xff); a

excepción de las comillas dobles ( “ ), que tienen un significado especial para
indicar el inicio y final de una cadena de nombres que contengan espacios.


de configuración:

Objects > Addresses > List > New: Ingrese los siguientes datos y haga clic
en OK:
Zone: Untrust




xii Documentación de Juniper Networks

Capítulo 1
Administración
Este capítulo describe los métodos y herramientas de administración, las formas de

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
contiene 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 9
“Administración a través de NetScreen-Security Manager” en la página 20
“Controlar el tráfico administrativo” en la página 26
“Niveles de administración” en la página 31
“Definir usuarios con permisos de administrador” en la página 33
“Asegurar el tráfico administrativo” en la página 36
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 4 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 4: WebUI
Para utilizar la WebUI, debe disponer de:
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/screenos_version
(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. Puede
guardarlos localmente y hacer que WebUI los busque en la estación de trabajo del
administrador o en un servidor seguro 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
Copiar los archivos de ayuda en 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 en “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 péguelo ahí.
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/screenos_version
por
(para unidad local) file://path…/help
o bien
(para servidor local) http://server_name…/path/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.
Protocolo de transferencia de hipertexto

Con un explorador estándar se puede tener acceso, supervisar y controlar
remotamente las configuraciones de seguridad de la red por medio del protocolo de
transferencia de hipertexto (HTTP, Hypertext Transfer Protocol).
Administración a través de la interfaz de usuario web 3

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 42 e “Interfaces MGT y
VLAN1” en la página 27.
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
Admin-A, extremadamente improbable.
dirección IP
de origen:
10.2.2.5 A continuación se explican dos ventajas que el uso de identificadores de sesión
proporciona a los administradores:
La Figura 5 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 5: ID de sesión con un dispositivo NAT
Traduce todas las direcciones

Dispositivo NAT IP de origen a 10.1.1.2 Dispositivo de seguridad
ORIG DEST ORIG DEST

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
Admin B de la interfaz:
Dirección IP identificación, que
ORIG DEST ORIG DEST 10.1.1.1/24 utiliza para distinguir
de origen:
10.2.2.6 10.2.2.5 10.1.1.1 DATOS 10.2.2.5 10.1.1.1 DATOS una sesión de otra.
La Figura 6 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 6: 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
ORIG DEST El dispositivo asigna a
RAÍZ cada sesión un número
2.2.2.5 1.1.1.1 DATOS único de identificación,
que utiliza para poder
2.2.2.5 1.1.1.1 DATOS VSYS1 distinguir las sesiones
procedentes de un mismo
2.2.2.5 1.1.1.1 DATOS VSYS2 host y dirigidas a 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 OSI (Open Systems
Interconnection):
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 7). 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. ScreenOS 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 7: Cliente a servidor SSL
Alicia (cliente SSL) establece contacto con el dispositivo de seguridad (servidor

de 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 compresión (PKZip o gzip) y un algoritmo hash (SHA-1 o MD5).
NetScreen-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 concertado para
comprimir datos y el algoritmo hash concertado 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 “Reenviar HTTP a SSL” en la página 8. Para obtener información
sobre certificados autofirmados, consulte “Certificados autofirmados” en la
página 5-37). 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.

Configurar 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 compruebe el
valor de “Cipher Strength.” Para obtener el paquete de seguridad avanzada, haga
clic en el enlace 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 acerca de los certificados autofirmados, consulte

“Certificados autofirmados” en la página 5-37. Para obtener los detalles sobre
cómo solicitar y cargar un certificado, consulte “Certificados y CRL” en la
página 5-24.
2. Habilitar 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 la encriptación 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 num
set ssl cert id_num
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. Configurar 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): Active la
casilla de verificación del servicio de administración de SSL, después haga clic
en OK.
CLI
set interface interface manage ssl
save
4. Conectarse al dispositivo de seguridad a través del puerto de 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 al final de la
dirección IP dos puntos, seguidos del número de puerto HTTPS (SSL) si es
diferente al predeterminado, (por ejemplo, https://123.45.67.89:1443).
Reenviar 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 8.
Durante el establecimiento de conexión de 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 concertado (PKZip or gzip) para
comprimir datos y el algoritmo hash concertado (SHA-1 or MD-5) para generar un
hash de los datos y así proporcionar integridad al mensaje.
Figura 8: Redirección de HTTP a SSL
HTTP-Get Puerto de destino 80
Texto puro
Dispositivo
HTTP-Reply de seguridad
Alicia
(NetScreen Instrucciones para reenviar
Admin) de HTTP a HTTPS
Conexión de SSL
HTTP-Get Puerto de destino 443
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 previamente ha asignado
otro certificado para su uso con SSL y ahora desea utilizar el certificado
predeterminado en su lugar, debe desactivar el certificado anterior con el siguiente
comando: unset ssl cert id_num, donde id_num es el número de identificación 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 reenvío de HTTP a SSL, desactive 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 de ScreenOS CLI, consulte
ScreenOS CLI Reference Guide Ipv4 Command Descriptions(Manual de referencia de
la CLI de ScreenOS: descripciones de comandos 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
Administración a través de la interfaz de línea de comandos 9

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 lo siguiente:
Software Telnet en la estación de trabajo de administración
Una conexión Ethernet al dispositivo de seguridad
La Figura 9 ilustra el procedimiento de configuración para establecer una conexión

Telnet.
Figura 9: Establecimiento de una conexión de 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.
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 number
NOTA: Para establecer esta restricción debe utilizarse la CLI.
Asegurar las conexiones Telnet

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 para administrar dispositivos de seguridad mediante
Telnet, puede obligar a tales usuarios a utilizar Telnet exclusivamente a través de un
túnel de red privada virtual (VPN). Una vez establecida esta restricción, el
dispositivo rechazará el acceso a cualquiera que intente ejecutar Telnet sin pasar
por un túnel VPN.
10 Administración a través de la interfaz de línea de comandos

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 seguro para la
administración remota de dispositivos utilizando las aplicaciones basadas en Secure
Shell (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 10 en la página 11 ilustra el flujo de tráfico SSH.
Figura 10: Flujo de tráfico SSH
Tráfico administrativo encriptado ScreenOS
Cliente SSH Internet Servidor SSH
Estación de trabajo Dispositivo de

del administrador seguridad

La Figura 11 ilustra el procedimiento básico de conexión de SSH.
Figura 11: 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 servidor, pública de un par de claves públicas/privadas que se
su cookie y los algoritmos de encriptación y autenticación que admite. utiliza para autenticar el dispositivo de seguridad o
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
5. El dispositivo firma la clave de la sesión con su clave privada y envía vsys).
la clave de la sesión firmada al cliente. El cliente verifica la firma con la
clave de la sesión generada durante el intercambio de claves. De este Session Key (Clave de la sesión): Clave secreta
modo se completa la creación de un canal seguro. temporal (DES o 3DES) que el cliente y el dispositivo
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

6. El dispositivo envía una señal al cliente de SSH para que pida al RSA persistente que reside en el cliente de SSH. La
usuario final la información de autenticación. clave pública del cliente también debe estar cargada en
el dispositivo de seguridad antes de iniciar una
conexión de SSH; la clave PKA debe estar asociada al
usuario con permisos de administrador.
7. El cliente encripta un nombre de usuario y una contraseña o
el componente público de su clave PKA y envía ambos para Nota: Par de claves pública/privada = Conjunto de
su autenticación. claves encriptadas que operan de modo que cualquier
elemento 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

Como se menciona 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 del 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, introduzca el comando CLI get ssh:
ns-> get ssh

SSH V1 is active
SSH is not enabled
SSH is not ready for connections
Maximum sessions: 8
Active sessions: 0
En el resultado 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:
ns-> 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:
ns-> 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.
ns-> 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:
ns-> set ssh enable

Si desea habilitar SSH para un vsys, primero debe entrar en dicho vsys y
habilitar SSH:
ns-> set vsys v1

ns(v1)-> set ssh enable
5. Habilite SSH en la interfaz a la que se conectará el cliente de SSH.
ns-> 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 del host” en la página 16.
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): 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 “Definir
usuarios con permisos de administrador” en la página 33.) 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. Traslade 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 name_str] key key_str (para SSHv1) o
set ssh pka-dsa [ user-name name_str ] key key_str (para SSHv2), pegándolo
donde indique la variable key_str, 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 name ] file-name name_str ip-addr

tftp_ip_addr
Para SSHv2:
exec ssh tftp pka-dsa [ user-name name ] file-name name_str ip-addr

tftp_ip_addr
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
name_str.) 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 del host” en la página 16) 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 del 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

administrador del equipo 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”.
Previamente, habrá utilizado un programa de generación de claves en su equipo

cliente de SSH para generar un par de claves pública/privada RSA, habrá trasladado
el archivo de clave pública, llamado “idnt_cfg.pub”, a un directorio en su servidor
TFTP y habrá ejecutado el programa de 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

Secure Copy
Secure Copy (SCP) 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 con 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 acceso del administrador raíz desde
la consola” en la página 41.
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 una información más detallada sobre el uso de HyperTerminal,
consulte ScreenOS CLI Reference Guide IPv4 Command Descriptions (Manual de
referencia de la CLI de ScreenOS: descripciones de comandos IPv4) o los
documentos 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
NOTA: En un dispositivo NetScreen-5XT, el puerto de módem únicamente se puede

utilizar para conectarse a un módem externo.
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 NetScreen-Security Manager User Interface (UI) 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. Almace estos
datos, principalmente registros de tráfico, en el almacenamiento de datos
locales.
20 Administración a través de NetScreen-Security Manager

NSM Agent 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.
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
Management System
NetScreen-Security
Manager UI
Servidor principal
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 Manager
configuración al dispositivo de seguridad y recibe opera el sistema de
informes operativos y estadísticos del mismo. administración a través del client
El servidor de GUI procesa los cambios de

configuración que recibe de uno o más clientes
del NetScreen-Security Manager.
Para obtener más información sobre éstos y otros componentes de

NetScreen-Security Manager, consulte el NetScreen-Security Manager Administrator’s
Guide.
Iniciar 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 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 NetScreen-Security Manager UI 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í.
Administración a través de NetScreen-Security Manager 21

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 NetScreen-Security Manager UI. 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.
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 NetScreen-Security Manager UI.
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 NetScreen-Security Manager Administrator’s Guide.
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

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:
Alarms, que comunican anomalías o ataques potencialmente peligrosos en el

tráfico, incluyendo los ataques detectados por “Deep Inspection” (inspección
minuciosa).
Log Events, que informan sobre cambios en una configuración del dispositivo y
cambios de escasa relevancia que se producen en el mismo.
Protocol distribution, 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)
Protocolo OPSF (abrir primero la ruta más corta)
Protocolo de control de la transmisión (TCP)
Protocolo de datagramas de usuario (UDP)
Statistics, mensajes que comunican la siguiente información estadística.
Estadísticas de ataques
Estadísticas de Ethernet
Estadísticas del flujo de tráfico
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
Sincronizar 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 NetScreen-Security Manager
Administrator’s Guide.
El ejemplo siguiente muestra el comando que se emplea para visualizar el estado de

la configuración.
Ejemplo: Visualización del 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 utilizar la 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: Consulta del hash de la configuración

NetScreen-Security Manager utiliza el hash de configuración para verificar la
sincronizacoó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 utilizar la CLI para consultar el hash de la configuración actual.
CLI
ns-> enter vsys vsys1
ns(vsys1)-> get config hash
a26a16cd6b8ef40dc79d5b2ec9e1ab4f
ns(vsys1)->
ns(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 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 no está
disponible, se mostrará el mensaje “unknown” (desconocida).
Controlar el 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.
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.
26 Controlar el tráfico administrativo
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 rutas, 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 de 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)
CLI
set interface mgt ip 10.1.1.2/24
set interface mgt manage web
set interface mgt manage ssh
save
Controlar el tráfico administrativo 27

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
Ajustar 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 sin 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, asignará a ethernet3 la dirección IP 1.1.1.1/24 y bloqueará todo el
tráfico administrativo hacia dicha interfaz.
WebUI
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
haga clic en OK:
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 manage web
unset interface ethernet1 manage snmp
set interface ethernet1 manage telnet
unset interface ethernet1 manage ssl
unset interface ethernet1 manage ssh
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.
Ajustar 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 implementación de de HA (alta disponibilidad), se puede
acceder a la unidad y configurarla a través de su dirección (o direcciones) IP de
administración.
Controlar el tráfico administrativo 29

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 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: SNMP
1.1.1.2 Internet
Estación de
administración
Enrutador
1.1.1.250
Administradores
locales Zona DMZ
ethernet2
IP: 1.2.2.1/24
IP gestió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 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.
Niveles de administración 31
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 (VR)
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
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
32 Niveles de administración
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 usuarios 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
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.
Definir 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: Adición de 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)
Definir usuarios con permisos de administrador 33

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: Modificación de 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
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: Eliminación de 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: Configuración de las cuentas de administrador para las conexiones de acceso

telefónico
Los dispositivos NS-5XT y NS-5GT admiten una conexión del módem para
situaciones de recuperación mediante conexión telefónica en caso de desastre.
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
34 Definir usuarios con permisos de administrador

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 estadísticamente 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)
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: Borrado de 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.
Definir usuarios con permisos de administrador 35

WebUI
NOTA: Debe utilizar la interfaz CLI para eliminar las sesiones de administración.
CLI
clear admin name Roger
save
Asegurar el tráfico administrativo

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 37.
2. Cambie el nombre de usuario y la contraseña de acceso administrativo.
Consulte “Cambiar nombre y contraseña de inicio de sesión del administrador”

en la página 37.
3. Defina las direcciones IP que tendrán los usuarios administradores en el equipo

cliente de administración.
Consulte “Restringir el acceso administrativo” en la página 41.
4. Desactive cualquier opción innecesaria de servicios de administración de la

interfaz.
Consulte “Controlar el tráfico administrativo” en la página 26.
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.
36 Asegurar el tráfico administrativo

CLI
unset interface interface manage ping
unset interface interface manage ident-reset
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
Cambiar 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 “Restablecer el
dispositivo con los ajustes predeterminados de fábrica” en la página 40.
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.
Asegurar el tráfico administrativo 37

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. (Consulte “Archivo de
diccionario de ScreenOS” en la página 9-22).
Para obtener más información sobre los niveles de usuarios administradores,

consulte “Niveles de administración” en la página 31. 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.
Ejemplo: Cambio del nombre de inicio de sesión y la contraseña de

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 “Cwb6yooN21”.
Para obtener información sobre los diferentes niveles de administradores,

consulte “Niveles de administración” en la página 31.

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: Cambio de 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
Ajustar la longitud mínima de la contraseña del administrador 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 number

Restablecer el 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 establecer una conexión de consola, descrita
detalladamente en el ScreenOS CLI Reference Guide IPv4 Command Descriptions
(Manual de referencia de la CLI de ScreenOS: descripciones de comandos IPv4) y
los documentos de 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.
!!!! 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.
!! 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.

Restringir el 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.
NOTA: La asignación de una dirección IP de cliente de administración entra en vigor

inmediatamente. Si está administrando el dispositivo a través de una conexión de
red y su estación de trabajo no está incluida en la asignación, el dispositivo de
seguridad termina inmediatamente su sesión actual y, desde ese momento, le
impedirá administrar el dispositivo desde esa estación de trabajo.

de 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: Restricción de 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 acceso del administrador raíz 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 entrada 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 administrativo
autogenerado” en la página 73).
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 (Security Parameters Index o 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

(“Public Key Infrastructure” o “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, le asignará el nombre de “tunnel 1” y la
asociará 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 ir 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 47.
NetScreen-Remote utiliza la dirección IP de ethernet3 (1.1.1.1) como dirección de

destino para ir 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 numerada
(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)
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 (haciendo 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 zone trust
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

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 situado 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 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.
9. Haga clic en Proposal 1 y 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 ir 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 43.
NetScreen-Remote utiliza la dirección IP 1.1.1.1 como la dirección de destino para

ir 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 LAN
10.1.1.56 Internet
(dirección IP VPN de clave manual
estática) 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
en OK:
Address Name: Untrust-IF

Zona: Untrust
en OK:
Address Name: admin

Zona: 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 (haciendo 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

5. Directivas
Directivas > (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
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

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 se ubica a la izquierda del icono de UNIX para
ampliar la directiva de 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”.


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.


Capítulo 2
Supervisar dispositivos de seguridad
Este capítulo trata de los siguientes temas relacionados con la supervisión de

dispositivos de seguridad Juniper Networks:
“Almacenar la información del registro” en esta página
“Registro de eventos” en la página 54
“Registro de tráfico” en la página 58
“Registro propio” en la página 61
“Descargar el registro de recuperación de equipos” en la página 63
“Alarmas de tráfico” en la página 64
“Syslog” en la página 67
“Protocolo simple de administración de redes” en la página 69
“Túneles VPN para tráfico administrativo autogenerado” en la página 73
“Visualizar contadores de pantalla” en la página 88
Almacenar 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.
Almacenar la información del registro 53

La siguiente lista proporciona los posibles destinos de los datos registrados:
Console: 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.
Internal: Permite que almacene un número limitado de entradas de registro.
Email: 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.
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: 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: Mecanismos de detección y defensa de ataques.
Alert: Mensajes sobre condiciones que requieren una atención inmediata,

como ataques al cortafuegos y vencimiento de claves de licencia.
Crítical: Mensajes sobre condiciones que probablemente afectan a la

funcionalidad del dispositivo, como cambios de estado de alta disponibilidad
(HA).
54 Registro de eventos
Capítulo 2: Supervisar dispositivos de seguridad
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: 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: Mensajes sobre eventos normales, incluyendo cambios de

configuración iniciados por un administrador.
Information: Mensajes que ofrecen información general sobre operaciones del

sistema.
Debugging: 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 Notepad o WordPad)
para ver el archivo. Alternativamente, puede enviarlos a un almacenamiento
externo (consulte “Almacenar la información del registro” en la página 53).
NOTA: Para obtener información detallada sobre los mensajes que aparecen en el registro
de eventos, consulte el manual NetScreen Message Log Reference Guide (manual de
consulta del registro de mensajes de NetScreen).
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.
Registro de eventos 55
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
Fecha Hora Nivel de módulo Nivel Tipo Descripción

2003-05-16 15:56:20 system warn 00547 AV scanman is removed.
2003-05-16 09:45:52 system warn 00547 AV test1 is removed.
Total de entradas con coincidencia = 2
Clasificar y filtrar el 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 los 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.
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.
56 Registro de eventos
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.
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 Notepad o WordPad)
para ver el archivo. Alternativamente, puede enviar las entradas del registro a un
almacenamiento externo (consulte “Almacenar la información del registro” en la
página 53). 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: Descarga del 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. El archivo se denominará
“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.
Registro de eventos 57
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, nombre el archivo “evnt07-02.txt”, luego haga

clic en Save.
CLI
get event > tftp 10.1.1.5 evnt07-02.txt
Ejemplo: Descarga de los eventos críticos del registro

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. Nombrará 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
Registro de tráfico
El dispositivo de seguridad Juniper Networks puede supervisar y registrar el tráfico
que autoriza o deniega basándose en 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
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:
58 Registro de tráfico
WebUI
Policies > (From: src_zone, To: dst_zone) New : Seleccione Logging y haga clic
en OK.
CLI
set policy from src_zone to dst_zone src_addr dst_addr service action 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
El número de bytes transmitidos de un origen a un destino
El número de bytes transmitidos de un destino a un origen
Para habilitar la opción de recuento de una directiva, ejecute cualquiera de los

WebUI
Policies > (From: src_zone, To: dst_zone) New > Advanced: Seleccione
Counting, haga clic en Return y luego haga clic en OK.
CLI
set policy from src_zone to dst_zone src_addr dst_addr service action log count
Visualizar el registro de tráfico

Las entradas del registro de tráfico almacenadas en la memoria flash del dispositivo
de seguridad se pueden visualizar a través de CLI o de WebUI:
WebUI
Policies > Logging (para el number de ID de directiva)
o bien
Reports > Policies > (para el number de ID de la directiva)
CLI
get log traffic policy number
Ejemplo: Visualización de 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.
Registro de tráfico 59
Aparece la información siguiente:
Dirección de Dirección de
Dirección de Dirección de origen destino
origen/ destino/ traducida/ traducida/ Bytes Bytes
Fecha/Hora Puerto Puerto Puerto Puerto Servicio Duración enviados recibidos
2003-01-09 1.1.1.1:1046 10.1.1.5:80 1.1.1.1:1046 10.1.1.5:80 HTTP 1800 seg. 326452 289207
21:33:43
CLI
get log traffic policy 3
Clasificar y filtrar el 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: Clasificación del 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 01:00 horas.
WebUI
NOTA: La posibilidad de clasificar el registro de tráfico por tiempo está disponible

únicamente con la CLI.
60 Registro de tráfico
CLI
get log traffic sort-by time start-time 01:00:00
Descargar el 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 Notepad o WordPad) para ver el archivo.
Alternativamente, puede enviar las entradas del registro de tráfico a un

almacenamiento externo (consulte “Almacenar la información del registro” en la
página 53). 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 nombra “traf_log11-21-02.txt”.
WebUI
1. Reports > Policies > Logging (para policy 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
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.
Registro propio 61
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".
Visualizar el 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
CLI
get log self
Clasificar y filtrar el 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.
62 Registro propio
Ejemplo: Filtro del 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 tiempo está disponible

únicamente con la CLI.
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 Notepad 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). El archivo se denominará “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 equipos

Un dispositivo de seguridad Juniper Networks proporciona un registro de
recuperación de equipos para mostrar información sobre cada vez que se
restablecen los ajustes predeterminados del dispositivo mediante el procedimiento
de recuperación de equipos (consulte “Restablecer el dispositivo con los ajustes
Descargar el registro de recuperación de equipos 63

predeterminados de fábrica” en la página 40). Además de ver el registro de

recuperación de equipos 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 Notepad).
En este ejemplo se descarga el registro de recuperación de equipos 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 nombrará “sys_rst.txt”.
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 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.
64 Alarmas de tráfico
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.
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
en OK:
Address Name: web1

Zone: DMZ
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 en peligro

En este ejemplo se utilizan alarmas de tráfico para generar notificaciones cuando el
sistema está en peligro. 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á en peligro,
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.
Alarmas de tráfico 65
WebUI
en OK:
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 any deny count alarm 64 0
save
Ejemplo: Envío de 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.
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)
66 Alarmas de tráfico
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 54) 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 75 y “Ejemplo: Tráfico autogenerado a través de túnel basado en
directivas” en la página 82)
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.
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).
Syslog 67
Ejemplo: Habilitación de 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
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
Habilitar 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 al
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.
En el ejemplo siguiente, enviaremos mensajes de notificación al host WebTrends

(172.10.16.25).
68 Syslog
WebUI
1. Ajustes de WebTrends
Configuration > Report Settings > WebTrends: Introduzca los siguientes datos
y haga clic en Apply:
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)
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. Se incluye una lista de MIB en el
Apéndice A, “Archivos MIB para SNMP.”
Protocolo simple de administración de redes 69

Por lo tanto, 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 -164 y “Alarmas de tráfico” en la página 64).
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 -163).
“Tipos de alarma de captura” en la página 70muestra los posibles tipos de alarmas

y los correspondientes números de captura:
Tabla 1: Tipos de alarma de captura
Captura de ID
corporativa Descripción
100 Problemas de hardware
200 Problemas de 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. Las
aplicaciones shareware y freeware para la administración de SNMP se encuentran
disponibles en Internet.
70 Protocolo simple de administración de redes

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 trabajan 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
completo (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 de tiempo

de vida (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 la 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.
Protocolo simple de administración de redes 71

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.
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 administrativo autogenerado” en la página 73.
Definir una comunidad SNMP de lectura/escritura

En este ejemplo creará una comunidad SNMP llamada MAge11. Le asignará
privilegios de lectura/escritura y habilitará 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.
72 Protocolo simple de administración de redes

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 administrativo 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.
Túneles VPN para tráfico administrativo autogenerado 73

Los dispositivos de seguridad Juniper Networks admiten dos tipos de

configuraciones de túnel 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.
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 de túnel 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 Volumen 7: Enrutamiento).
También puede utilizar la supervisión de VPN con la opción de reencriptación o
latidos 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 -240 y “Mecanismos
de supervisión” en la página 5 -292).
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.
74 Túneles VPN para tráfico administrativo autogenerado

AutoKey IKE con clave compartida: Una o dos claves secretas 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 NetScreen-Remote VPN Client Administrator Guide (manual de
administrador de clientes de VPN de NetScreen-Remote).
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 2:
Tabla 2: 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
Zona Trust local
ethernet1 Gestor de SNMP y

10.1.1.1/24 tunnel.1, sin numerar servidor Syslog
NAT ethernet3, 1.1.1.1/24 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
puerta de enlace, 2.2.2.250

ethernet3, 2.2.2.2/24 ethernet1
10.2.2.1/24
tunnel.1, sin numerar NAT
Ubicación
Zona Untrust remota 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
VPNs > AutoKey IKE > New: Introduzca los siguientes datos y haga clic en OK:
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

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
NetworNetwork Address / Netmask k > Routing > Routing Entries > trust-vr
New: Introduzca los siguientes datos y haga clic en OK:
Network Address / Netmask : 10.2.2.2/32

Interface: tunnel.1

Gateway IP Address: (seleccione) 1.1.1.250
CLI (dispositivo A)
1. Interfaces
set interface tunnel.1 zone untrust
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 bind interface tunnel.1
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
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
en OK:
Address Name: addr1

IP/Netmask: 10.2.2.2/32
Zone: Trust
en OK:
Address Name: ns-a

IP/Netmask: 10.1.1.1/32
Zone: Untrust

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
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 16), 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 puerta 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 Zona Untrust

Zona Trust local
Gestor de SNMP y
ethernet1 servidor Syslog
10.1.1.1/24 ethernet3, 1.1.1.1/24 10.2.2.2
NAT
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
puerta de enlace, 2.2.2.250

10.2.2.1/24
NAT
Zona Untrust Ubicación Zona Trust

remota
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 directivas creadas para el dispositivo B por su parte y por parte de la
administración, los dos dispositivos NetScreen derivarán las siguientes ID de proxy
para vpn1:
Tabla 3: 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
en OK:
Address Name: trust_int

IP/Netmask: 10.1.1.1/32
Zone: Trust
en OK:
Address Name: remote_admin

IP/Netmask: 10.2.2.2/32
Zone: Untrust
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)
1. Interfaces—Zonas de seguridad
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
en OK:
Address Name: addr1

IP/Netmask: 10.2.2.2/32
Zone: Trust
en OK:
Address Name: ns-a

IP/Netmask: 10.1.1.1/32
Zone: Untrust
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 4 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 4: Contadores de pantalla
Contador Descripción
Bad IP Option Protection Número de tramas desechadaos 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
Fragmento ICMP Número de tramas ICMP con el flag de más fragmentos ajustado o con un offset
indicado en el campo de offset.
HTTP Component Blocked Número de paquetes bloqueados con componentes de HTTP
HTTP Component Blocking for .exe files Número de paquetes HTTP bloqueados con archivos .exe
HTTP Component Blocking for .zip files Número de paquetes HTTP bloqueados con archivos .zip
HTTP Component Blocking for ActiveX Número de componentes de ActiveX bloqueados
controls
HTTP Component Blocking for Java Número de componentes Java bloqueados
applets
ICMP Flood Protection Número de paquetes ICMP bloqueados como parte de una inundación ICMP
88 Visualizar contadores de pantalla

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 ruta de origen variable
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 de registro de rutahabilitada
Security IP Option Número de tramas descartadas con la opción de seguridad de IP ajustada
Source Route IP Option Filter Número de rutas de origen IP filtradas
Src IP-based session limiting Número de sesiones descartadas después de alcanzar el umbral de sesión
Stream IP Option Número de paquetes descartados con la opción de identificador de secuencia de
IP ajustada
Strict Src Route IP Option Número de paquetes detectados con la opción de ruta de origen estricta
habilitada
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
SYN-ACK-ACK-Proxy DoS Número de paquetes bloqueados debido a la opción SYN-ACK-ACK-proxy DoS
SCREEN
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
Timestamp IP Option Número de paquetes IP descartados con la opción de marca de fecha y hora de
Internet ajustada
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 89

La Tabla 5 muestra los contadores de hardware para supervisar el funcionamiento

del hardware y los paquetes con errores:
Tabla 5: 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 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 de acceso múltiple/detección de
colisiones de sentido de portadora (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 latido 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 6 muestra los contadores de flujo para la supervisión del número de

paquetes inspeccionados a nivel de flujo.
Tabla 6: 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 de protocolo de encapsulamiento punto a punto (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 protocolo de mensajes de control de Internet (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 invertido a través de un
dispositivo de seguridad. Un ejemplo de sesión de bucle invertido 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 invertido 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
maestro y el módulo procesador
no conn Número de paquetes descartados porque las conexiones de traducción de direcciones de red (NAT)
no estaban disponibles

no dip Número de paquetes descartados porque las direcciones de IP dinámica (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 traducción de direcciones de red (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 puerto
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 cuyas direcciones MAC eran lentas de resolver
src route Número de paquetes descartados debido a la opción de filtro de ruta de origen
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 protección
contra inundación SYN o autenticación de usuario
tear drop Número de paquetes bloqueados como parte de una sospecha de 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 (acceso múltiple/detección de

colisiones de sentido de portadora), 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


Apéndice A
Archivos MIB para SNMP
Juniper Networks proporciona archivos MIB para permitir la comunicación SNMP

entre las aplicaciones de su organización y el agente SNMP en el dispositivo de
seguridad Juniper Networks. Para obtener los archivos MIB más recientes, abra un
explorador y visite www.juniper.net/support. Seleccione un producto de Juniper
Networks y, a continuación, seleccione los archivos MIB para la versión de
ScreenOS cargada en su dispositivo de seguridad.
Los archivos MIB de la versión actual de ScreenOS son completamente compatibles

con los agentes SNMP de las versiones anteriores de ScreenOS. Los archivos MIB de
NetScreen se organizan en una estructura jerárquica de múltiples niveles, tal y
como se describe en las siguientes secciones:
“Carpetas de archivos MIB del nivel principal” en la página A-II
“Carpetas de archivos MIB del segundo nivel” en la página A-IV
“netscreenProducts” en la página A-IV
“netScreenIds” en la página A-IV
“netscreenVpn” en la página A-IV
“netscreenQos” en la página A-IV
“netscreenSetting” en la página A-V
“netscreenZone” en la página A-V
“netscreenPolicy” en la página A-V
“netscreenNAT” en la página A-V
“netscreenAddr” en la página A-V
“netscreenService” en la página A-V
“netscreenSchedule” en la página A-VI
“netscreenVsys” en la página A-VI
“netscreenResource” en la página A-VI
A-I
“netscreenIp” en la página A-VI
“netscreenVR” en la página A-VI
Carpetas de archivos MIB del nivel principal

Los archivos MIB se organizan en una estructura jerárquica de carpetas. A
continuación se muestran las carpetas MIB del nivel principal:
A-II
Apéndice A: Archivos MIB para SNMP
Cada carpeta contiene una categoría de archivos MIB.
netscreenProducts Asigna identificadores de objeto (OID) a las distintas series de productos

NetScreen.
netscreenTrapInfo Define las capturas de empresa enviadas por el dispositivo de seguridad.
netscreenIDS Define la configuración del servicio de detección de intrusión (IDS) del
netscreenVpn Define la configuración de VPN y la información de tiempo de ejecución
del dispositivo de seguridad.
netscreenQos Define la configuración de la calidad de servicio del dispositivo de
seguridad.
netscreenNsrp Define la configuración NSRP del dispositivo de seguridad.
netscreenSetting Define otros ajustes de configuración del dispositivo de seguridad, como
DHCP, correo electrónico, autenticación y el administrador.
netscreenZone Define la información de zona que se encuentra en el dispositivo de
seguridad.
netscreenInterface Define la configuración de interfaz del dispositivo de seguridad, incluida la
interfaz virtual.
netscreenPolicy Define la configuración de directivas de entrada y salida del dispositivo de
seguridad.
netscreenNAT Define la configuración de NAT, incluyendo las direcciones Map IP (IP
asignada), Dynamic IP (IP dinámica) y Virtual IP (IP virtual).
netscreenAddr Representa la tabla de direcciones de una interfaz NetScreen.
netscreenService Describe los servicios (incluyendo los servicios definidos por el usuario)
reconocidos por el dispositivo de seguridad.
netscreenSchedule Define la información de programación de tareas del dispositivo de
seguridad, configurada por el usuario.
netscreenVsys Define la configuración de sistema virtual (VSYS) del dispositivo de
seguridad.
netscreenResource Accede a información sobre la utilización de recursos por parte del
netscreenIp Accede a información sobre la IP privada del dispositivo de seguridad.
netScreen Chassis Marcador de posición vacío para futuras carpetas de archivos MIB.
netscreenVR Define la configuración del enrutador virtual (VR) del dispositivo de
seguridad.
A-III
Carpetas de archivos MIB del segundo nivel

En esta sección se describen los archivos MIB del segundo nivel para los
dispositivos de seguridad Juniper Networks. Cada carpeta de segundo nivel puede
contener archivos MIB o subcarpetas.
netscreenProducts
netscreenGeneric Identificadores de objeto (OID) genéricos para productos de

seguridad Juniper Networks
netscreenNs5 OID de NetScreen-5XP
netscreenNs10 OID de NetScreen-10XP
netscreenNs100 OID de NetScreen-100
netScreenIds
nsldsProtect Servicio IDS en el dispositivo de seguridad

nsldsProtectSetTable Servicio IDS activo en el dispositivo de seguridad
nsldsProtectThreshTable Configuración del umbral del servicio IDS
nsldsAttkMonTable Información estadística sobre intentos de intrusión
netscreenVpn
netscreenVpnMon Muestra información de la dirección de origen del túnel VPN

nsVpnManualKey Configuración de clave manual
nsVpnIke Configuración IKE
nsVpnGateway Configuración de puerta de enlace del túnel de VPN
nsVpnPhaseOneCfg Configuración IPSec de Fase 1
nsVpnPhaseTwoCfg Configuración IPSec de Fase 2
nsVpnCert Configuración de certificado
nsVpnL2TP Configuración de L2TP
nsVpnPool Configuración de rango IP
nsVpnUser Configuración de usuario de VPN
netscreenQos
nsQosPly Configuración de calidad del servicio (QoS) según la

directiva
A-IV
Apéndice A: Archivos MIB para SNMP
netscreenSetting
nsSetGeneral Configuración general del dispositivo NS

nsSetAuth Configuración del método de autenticación
nsSetDNS Ajustes del servidor DNS
nsSetURLFilter Ajuste del filtro de URL
nsSetDHCP Ajustes del servidor DHCP
nsSetSysTime Ajuste de la hora del sistema
nsSetEmail Ajuste de correo electrónico
nsSetLog Ajuste de Syslog
nsSetSNMP Configuración del agente SNMP
nsSetGlbMng Configuración de administración global
nsSetAdminUser Configuración de usuario administrativo
nsSetWebUI Configuración de WebUI
netscreenZone
nsZoneCfg Configuración de zona del dispositivo
netscreenPolicy
NsPlyTable Configuración de directivas

NsPlyMonTable Información estadística sobre cada directiva
netscreenNAT
nsNatMipTable Configuración de dirección IP asignada

nsNatDipTable Configuración de IP dinámico
nsNatVip Configuración de IP virtuales
netscreenAddr
nsAddrTable Tabla de direcciones en una interfaz NetScreen
netscreenService
nsServiceTable Información de servicio

nsServiceGroupTable Información de grupo de servicios
nsServiceGrpMemberTable Información de miembro de grupo de servicios
A-V
netscreenSchedule
nschOnceTable Información de programación puntual

nschRecurTable Información de programa recurrente
netscreenVsys
nsVsysCfg Configuración de sistema virtual (VSYS) del dispositivo de

seguridad
netscreenResource
nsresCPU Utilización de la CPU

nsresMem Utilización de memoria
nsresSession Uso de sesión
NOTA: ScreenOS ya no es compatible con el contador failedSession.
netscreenIp
nslpArp Tabla de ARP
netscreenVR
nsOSPF Información de protocolo OSPF (abrir primero la ruta más

corta)
nsBGP Información de protocolo BGP (protocolo de puerta de
enlace de límite)
nsRIP Información de protocolo RIP (protocolo de información de
rutas)
NOTA: Las MIB netscreenVR se basan en Structure of Management Information version 2

(SMIv2). El resto se basa en SMIv1. Es posible acceder a todos los datos MIB II
independientemente de si se utiliza SNMPv1 o SNMPv2c.
A-VI
Índice
A D
administración DIP ...................................................................................92
Interfaz de línea de comandos (CLI) .......................9 Direcciones IP
restringir ...................................................................41 IP administrativa .....................................................30
WebUI .........................................................................2 Servidores de NetScreen-Security Manager .........23
administrador raíz, inicio de sesión ............................41 direcciones IP de cliente de administración ...............41
Agente de NSM ..............................................................21 directiva de SA ...............................................................92
comunicar eventos ..................................................23 dispositivos, restablecer a los ajustes
habilitar ....................................................................22 predeterminados de fábrica ......................................40
ajustes de configuración, requisitos del distribución del protocolo, comunicar a
explorador .....................................................................2 NetScreen-Security Manager .....................................23
alarmas
alerta de correo electrónico ...................................64 E
comunicar a NetScreen-Security Manager ...........23 email alert notification ..................................................69
tráfico ............................................................... 64 a 67 error de vector NAT .......................................................92
umbrales ..................................................................64 error in-short ..................................................................90
alarmas de tráfico .................................................. 64 a 67 estadísticas, comunicar a NetScreen-Security
almacenamiento en segundo plano ............................90 Manager .......................................................................24
almacenamiento flash interno .....................................54
Archivos de ayuda ...........................................................2 F
Asociaciones de seguridad (SA) ...................................92 filtrar ruta de origen ......................................................92
C H
cables serie .....................................................................19 HTTP, ID de sesión ..........................................................4
capturas SNMP
100, problemas de hardware ................................70
200, problemas de cortafuegos .............................70
I
ID de sesión ......................................................................4
300, problemas de software ..................................70 Ident-Reset......................................................................27
400, problemas de tráfico ......................................70 iniciar sesión ..........................................................53 a 64
500, problemas de VPN .........................................70
CompactFlash (PCMCIA).........................................54
alarma de tráfico .....................................................70
consola......................................................................54
alarma del sistema ..................................................70 correo electrónico ...................................................54
permitir o denegar ..................................................72
interno ......................................................................54
tipos ..........................................................................70
registro de eventos ..................................................54
claves manuales, VPN .............................................42, 74 registro de recuperación de equipos .....................63
CLI .....................................................................................9
registro propio .........................................................61
CompactFlash ................................................................54
SNMP ..................................................................54, 69
comunidad SNMP syslog ..................................................................54, 67
privadas ....................................................................72
WebTrends .........................................................54, 68
públicas ....................................................................72 inicio de sesión
conexión principal .........................................................92 administrador raíz ...................................................41
consola ............................................................................54
Telnet ........................................................................10
contraseña interfaces
administrador raíz ...................................................39 gestionables .............................................................30
contraseñas
opciones de administración ...................................26
olvidada ....................................................................37
Índice IX-I
Interfaz de línea de comandos NetScreen-Security Manager ..................................27

véase CLI ping ...........................................................................27
Interfaz de usuario web SNMP ........................................................................26
véase WebUI SSH............................................................................26
Interfaz MGT, opciones de administración ................. 27 SSL ............................................................................26
IP administrativa ........................................................... 29 Telnet ........................................................................26
IP dinámico VLAN1.......................................................................27
véase DIP WebUI .......................................................................26
Opciones de administración de SSL ............................26
L Opciones de administración de Telnet .......................26
los ajustes predeterminados de fábrica, Opciones de administración del comando ping ........27
restablecer los dispositivos a ..................................... 40
P
M paquetes .........................................................................92
Management Information Base II ataque de simulación de dirección .......................91
véase MIB II ataque terrestre .......................................................91
mensajes colisión .....................................................................90
alerta ................................................................... 54, 55 descartados ..............................................................92
críticos ...................................................................... 54 entrantes ..................................................................90
depurar ..................................................................... 55 fragmentados...........................................................92
emergencia .............................................................. 54 IPSec .........................................................................91
error .......................................................................... 55 no enrutables ...........................................................92
información ............................................................. 55 Protocolo de encapsulamiento de punto
notificación .............................................................. 55 a punto (PPTP) ......................................................91
WebTrends .............................................................. 69 Protocolo de mensajes de control
métodos de administración de Internet (ICMP) ..........................................88, 91
consola ..................................................................... 19 que no se pueden recibir........................................90
Interfaz de línea de comandos ................................ 9 rechazados ...............................................................92
SSL .............................................................................. 5 recibidos .......................................................90, 91, 92
Telnet.......................................................................... 9 Traducción de direcciones de red (NAT) ..............91
WebUI ........................................................................ 2 transmitidos por defecto ........................................90
MIB II ........................................................................ 26, 69 transmitidos por defecto (underrun) ....................90
módem, puertos ............................................................ 20 PCMCIA ...........................................................................54
Modo transparente, opciones de administración ...... 27 PKI keys ............................................................................6
Protocolo de encapsulamiento de punto
N a punto (PPTP) ............................................................91
NetScreen-Security Manager Protocolo de transferencia de hipertexto (HTTP),
administración del sistema ........................ 20, 21, 23 ID de sesión ...................................................................4
Agente de NSM .................................................. 21, 23 puertos de módem ........................................................20
comunicar eventos ........................................... 23, 24
configuración de la conectividad inicial ............... 21 R
definición ................................................................. 20 RADIUS ...........................................................................38
habilitación del agente de NSM ............................. 22 redes privadas virtuales
interfaz de usuario .................................................. 20 véase VPNs
opciones de administración................................... 27 registro
registro ..................................................................... 23 NetScreen-Security Manager ..................................23
notificación de alerta por correo electrónico ............. 66 registro de eventos ........................................................54
registro de recuperación de equipos ...........................63
O registro propio................................................................61
opciones de administración requisitos del explorador ................................................2
gestionables ............................................................. 30 requisitos del explorador web ........................................2
interfaces ................................................................. 26 ruta de origen .................................................................92
MGT, interfaz ........................................................... 27
Modo transparente ................................................. 27
IX-II Índice
Índice
S U
SA inactiva ......................................................................92 usuarios, múltiples administrativos .............................31
SCP
ejemplo de comando del cliente ...........................18 V
habilitar ....................................................................18 VLAN1, opciones de administración ...........................27
secuencia de bits ...........................................................90 VPN
Secure Copy AutoKey IKE .......................................................42, 75
Consulte SCP clave manual ............................................................74
véase SCP claves manuales ......................................................42
Secure Shell para tráfico administrativo .....................................74
véase SSH VPN AutoKey IKE .....................................................42, 75
Secure Sockets Layer
véase SSL W
serie, cables ....................................................................19 WebTrends ................................................................54, 68
sistemas virtuales encriptación .......................................................68, 74
administradores ......................................................33 mensajes ..................................................................69
administradores de sólo lectura ............................32 WebUI................................................................................2
SMTP server IP ...............................................................67 Archivos de ayuda .....................................................2
SNMP ........................................................................26, 69 opciones de administración ...................................26
captura de inicio en frío .........................................70
configuración ...........................................................72
encriptación .......................................................72, 74
SSH .......................................................................... 11 a 16
autenticación mediante contraseña ......................14
autenticación mediante PKA .................................14
cargar claves públicas, CLI .....................................15
cargar claves públicas, TFTP ............................15, 17
cargar claves públicas, WebUI ...............................15
forzar la autenticación mediante PKA
exclusivamente .....................................................16
inicios de sesión automatizados ............................17
PKA ...........................................................................15
prioridad del método de autenticación ................16
procedimiento de conexión ...................................12
SSL .....................................................................................5
SSL, protocolo de saludo
véase SSLHP
SSLHP................................................................................5
syslog ..............................................................................54
encriptación .............................................................74
host ...........................................................................67
mensajes ..................................................................67
nombre de host .....................................68, 69, 77, 84
puerto ...........................................................68, 77, 84
servicio de seguridad ..................................68, 77, 84
utilidad ..........................................................68, 77, 84
T
TCP proxy .......................................................................92
Telnet ................................................................................9
Traducción de direcciones de red (NAT) .....................91
tráfico administrativo ....................................................27
Índice IX-III
IX-IV Índice
Volumen 4:
Mecanismos de detección y defensa de ataques

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Copyright Notice
without notice.
FCC Statement
Disclaimer
Writers: Richard Biegel, Sharmila Kumar, Carrie Nowocin, Jozef Wroblewski

ii
Contenido
Convenciones para las ilustraciones .......................................................... x
Convenciones de nomenclatura y conjuntos de caracteres ....................... xi
Convenciones de la interfaz gráfica (WebUI) ........................................... xii
Documentación de Juniper Networks ............................................................ xiii
Capítulo 1 Protección de una red 1
Etapas de un ataque......................................................................................... 2
Mecanismos de detección y defensa ................................................................ 2
Supervisar explotaciones de vulnerabilidades .................................................. 5
Ejemplo: Supervisión de ataques desde la zona Untrust ...................... 5
Capítulo 2 Disuasión de reconocimiento 6
Barrido de direcciones IP ................................................................................. 7
Análisis de puertos........................................................................................... 8
Reconocimiento de red mediante opciones IP ................................................. 9
Sondeo del sistema operativo ........................................................................ 11
Flags SYN y FIN activados ....................................................................... 11
Flag FIN sin flag ACK ............................................................................... 12
Encabezado TCP sin flags activados ........................................................ 13
Técnicas de evasión ....................................................................................... 14
Análisis FIN ............................................................................................. 14
Flags no SYN ........................................................................................... 15
Simulación de IP...................................................................................... 18
Opciones IP de ruta de origen .................................................................24
Capítulo 3 Defensas contra los ataques de denegación de servicio (DoS) 28
Ataques de DoS contra el cortafuegos ............................................................ 29
Inundación de la tabla de sesiones .......................................................... 29
Límites de sesiones basadas en sus orígenes y destinos.................... 29
Ejemplo: Limitación de sesiones según su origen.............................. 31
Ejemplo: Limitación de sesiones según su destino ............................ 31
Envejecimiento agresivo ................................................................... 32
Ejemplo: Forzar el envejecimiento agresivo de sesiones ................... 33
Inundación proxy SYN-ACK-ACK ............................................................. 34
Ataques DoS contra la red.............................................................................. 36
Inundación SYN....................................................................................... 36
Cookie SYN..............................................................................................46
Inundación ICMP ..................................................................................... 48
Contenido iii
Inundación UDP ...................................................................................... 49

Ataque terrestre (“Land Attack”).............................................................. 50
Ataques de DoS específicos de cada sistema operativo .................................. 51
“Ping of Death” ....................................................................................... 51
Ataque “Teardrop” .................................................................................. 52
WinNuke ................................................................................................. 53
Capítulo 4 Supervisión y filtrado de contenidos 55
Reensamblar fragmentos ............................................................................... 56
Protección contra URL maliciosas............................................................ 56
Puerta de enlace en la capa de aplicación................................................ 57
Ejemplo: Bloqueo de URL maliciosas en paquetes fragmentados ...... 58
Análisis antivirus ............................................................................................ 59
Analizar el tráfico de FTP......................................................................... 60
Analizar el tráfico de HTTP ...................................................................... 61
Extensiones MIME de HTTP .............................................................. 62
Correo web HTTP.............................................................................. 63
Analizar el tráfico de IMAP y POP3.......................................................... 64
Analizar el tráfico de SMTP...................................................................... 65
Actualizar el archivo de patrón de AV ...................................................... 67
Ejemplo: Actualización automática....................................................69
Ejemplo: Actualización manual ......................................................... 69
Protección contra Spyware y Phishing..................................................... 70
Análisis AV basado en directivas.............................................................. 71
Ajustes globales del analizador de AV ...................................................... 72
Asignar recursos de AV ..................................................................... 72
Comportamiento en modo de fallo ................................................... 72
Máximo de mensajes y tamaño máximo del contenido .................... 73
HTTP Keep-Alive (mantenimiento de conexión)................................ 73
Goteo HTTP....................................................................................... 74
Ajustes de perfiles del analizador de AV .................................................. 75
Iniciar un perfil de AV ....................................................................... 76
Ejemplo: Análisis de todos los tipos de tráfico................................... 76
Ejemplo: Análisis de AV únicamente para el tráfico SMTP y HTTP .... 77
Ajustes de perfiles de AV................................................................... 77
Filtrado anti-spam .......................................................................................... 80
Listas blancas y listas negras ................................................................... 81
Configuración básica ............................................................................... 81
Filtrar tráfico Spam ........................................................................... 82
Descartar mensajes de spam ............................................................ 82
Definir una lista negra ............................................................................. 82
Definir una lista blanca............................................................................ 83
Definir una acción predeterminada ......................................................... 83
Definir una lista de bloqueo de spam ...................................................... 84
Filtrado de Web ............................................................................................. 84
Filtrado de Web integrado ....................................................................... 84
Ejemplo: Activación del filtrado de Web............................................ 86
Ejemplo: Categoría de URL................................................................ 87
Ejemplo: Perfil de filtrado de Web..................................................... 89
Servidores de SurfControl .................................................................92
Caché de filtrado de Web .................................................................. 92
Ejemplo: Parámetros de caché .......................................................... 93
Redirigir el filtrado de Web...................................................................... 93
Compatibilidad con sistemas virtuales .............................................. 95
iv Contenido
Contenido
Configurar el redireccionamiento de filtrado de Web ........................ 95

Ejemplo: Configuración del filtrado de Web ...................................... 98
Capítulo 5 Deep Inspection 101
Vista general ................................................................................................102
Servidor de la base de datos de objetos de ataque .......................................106
Paquetes de firmas predefinidos............................................................106
Actualizar paquetes de firmas................................................................107
Antes de empezar las descargas......................................................108
Ejemplo: Actualización inmediata ...................................................109
Ejemplo: Actualizaciones automáticas.............................................110
Ejemplo: Notificación automática y actualización inmediata ...........111
Ejemplo: Actualización manual .......................................................112
Objetos de ataque y grupos..........................................................................114
Protocolos admitidos .............................................................................116
Firmas completas ..................................................................................120
Firmas de secuencias TCP .....................................................................121
Anomalías en el protocolo .....................................................................121
Grupos de objetos de ataque..................................................................122
Cambiar los niveles de gravedad.....................................................122
Ejemplo: Deep Inspection para P2P ................................................123
Desactivar objetos de ataque .................................................................125
Acciones de ataque ......................................................................................126
Ejemplo: Acciones de ataque – Close Server, Close, Close Client.....127
Acciones de ataques de fuerza bruta .....................................................133
Objetos de ataques de fuerza bruta .................................................134
Objetivos de ataques de fuerza bruta ..............................................134
Tiempo de espera de ataques de fuerza bruta .................................135
Ejemplo 1........................................................................................135
Ejemplo 2........................................................................................136
Ejemplo 3........................................................................................136
Registrar ataques .........................................................................................136
Ejemplo: Inhabilitación del registro por grupo de ataque ................136
Asignar servicios personalizados a aplicaciones ...........................................138
Ejemplo: Asignación de una aplicación a un servicio
personalizado ...........................................................................139
Ejemplo: Asignación de aplicaciones a servicios
para ataques HTTP ...................................................................141
Objetos de ataque y grupos personalizados .................................................142
Objetos de ataque de firma completa definidos por el usuario ..............142
Expresiones regulares .....................................................................143
Ejemplo: Objetos de ataque de firma completa definidos
por el usuario ...........................................................................144
Objetos de ataque de la firma de las secuencias TCP.............................147
Ejemplo: Objeto de ataque de firma de secuencia definido
por el usuario ...........................................................................148
Parámetros configurables de anomalías de protocolos ..........................149
Ejemplo: Modificar parámetros .......................................................149
Negación......................................................................................................150
Ejemplo: Negación de objeto de ataque ..........................................150
Bloqueo granular de los componentes de HTTP ...........................................155
Controles ActiveX ..................................................................................156
Applets de Java ......................................................................................156
Archivos EXE.........................................................................................156
Archivos ZIP ..........................................................................................157
Contenido v
Capítulo 6 Atributos de los paquetes sospechosos 159

Fragmentos ICMP ........................................................................................160
Paquetes ICMP grandes................................................................................161
Opciones IP incorrectas ...............................................................................162
Protocolos desconocidos ..............................................................................163
Fragmentos de paquetes IP..........................................................................164
Fragmentos SYN ..........................................................................................165
Apéndice A Contextos para las firmas definidas por el usuario A-I
Índice ........................................................................................................................IX-I
vi Contenido
En el Volumen 4: Mecanismos de detección y defensa de ataques se describen las

opciones de seguridad de Juniper Networks disponibles en ScreenOS. Muchas de
ellas son opciones SCREEN que se pueden activar en el nivel de zona de seguridad.
Las opciones SCREEN se aplican al tráfico que llega al dispositivo de seguridad de
Juniper Networks a través de cualquier interfaz asociada a una zona para la que se
hayan activado dichas opciones. Las opciones SCREEN ofrecen protección contra
análisis de puertos y direcciones IP, ataques de denegación de servicio (DoS) y
cualquier otro tipo de actividad maliciosa. Es posible aplicar otras opciones de
seguridad de red, como el filtrado de 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: El objeto de las directivas sólo se presenta en este volumen de forma periférica, tal
como se aplica a las opciones de seguridad de red que se pueden activar a nivel de
directivas. Para examinar las directivas de forma completa, consulte “Directivas”
en la página 163.
Este volumen contiene los siguientes capítulos:
En el Capítulo 1, “Protección de una red,” se resumen las etapas básicas de un

ataque y las opciones de cortafuegos disponibles para combatir al atacante en
cada etapa.
En el Capítulo 2, “Disuasión de reconocimiento,” 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.
En el Capítulo 3, “Defensas contra los ataques de denegación de servicio

(DoS),” se explican los ataques DoS específicos de cada sistema operativo, red
o cortafuegos, y cómo ScreenOS amortigua estos ataques.
En el Capítulo 4, “Supervisión y filtrado de contenidos,” se describe cómo

proteger a los usuarios del protocolo de transferencia de hipertexto (HTTP) y
del protocolo de transferencia de archivos (FTP) frente a los localizadores de
recursos uniformes (URL) maliciosos y cómo configurar el dispositivo de
seguridad de Juniper Networks para el trabajo con productos de otros
fabricantes con la finalidad de proporcionar análisis antivirus, anti-spam y
filtrado de Web.
vii
En el Capítulo 5, “Deep Inspection,” 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.
En el Capítulo 6, “Atributos de los paquetes sospechosos,” se indican varias

opciones SCREEN que protegen los recursos de red frente a potenciales ataques
indicados por atributos de paquete IP e ICMP inusuales.
En el Apéndice A, “Contextos para las firmas definidas por el usuario,” se

proporcionan descripciones de los contextos que se pueden especificar al
definir un objeto de ataque de firma completa.

“Convenciones para las ilustraciones” en la página x
“Convenciones de nomenclatura y conjuntos de caracteres” en la página xi
“Convenciones de la interfaz gráfica (WebUI)” en la página xii

En ejemplos:


En texto:




10.1.1.0/24)

Internet

dinámicas (DIP)

Equipo portátil

Interfaz de túnel
Servidor
Túnel VPN
Concentrador (hub)
Enrutador
Teléfono IP
Conmutador








de configuración:

Objects > Addresses > List > New: Ingrese los siguientes datos y haga clic en
OK:
Zone: Untrust




Documentación de Juniper Networks xiii


Capítulo 1
Protección de una red
Puede haber numerosos motivos para penetrar en una red protegida. La siguiente
lista contiene algunos objetivos comunes:
Obtener el siguiente tipo de información sobre la red protegida:
Topología
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 lanzar otras explotaciones de 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 por un dispositivo de
seguridad Juniper Networks.
Este capítulo proporciona una vista general de las principales etapas de un ataque y
de los diversos mecanismos de defensa que se pueden emplear para frustrar un
ataque en cualquier etapa:
“Etapas de un ataque” en la página 2
“Mecanismos de detección y defensa” en la página 2
“Supervisar explotaciones de vulnerabilidades” en la página 5
1
Etapas de un ataque
Normalmente, los ataques se desarrollan en dos etapas principales. En la primera
etapa, el atacante recopila información; en la segunda etapa, lanza el ataque
propiamente dicho.
1. Realizar el reconocimiento.
a. Generar 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 el 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

Una explotación de vulnerabilidad 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 un barrido de direcciones IP con el
propósito de desencadenar respuestas de los hosts activos, o como un ataque de
inundación SYN con el objetivo de colapsar una red para impedir su correcto
funcionamiento. Es más, como los hackers normalmente realizan un
reconocimiento del objetivo antes de lanzar el ataque, podemos considerar las
actividades de recopilación de información como precursoras de un ataque
inminente, e interpretar que constituyen la primera etapa de un ataque. Por lo
tanto, el término “explotación de vulnerabilidad” abarca tanto las actividades de
reconocimiento como las de ataque; y la distinción entre ambas no siempre está
clara.
Juniper Networks ofrece diversos métodos de detección y mecanismos de defensa a

nivel de directivas y de zona para combatir explotaciones de 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 (superzonales aquí significa directivas globales,
donde no se hace referencia a las zonas de seguridad).
2 Etapas de un ataque
Capítulo 1: Protección de una red
NOTA: Aunque las zonas VLAN y MGT son zonas de función y no zonas de seguridad, es
posible ajustar opciones SCREEN para ellas. La zona VLAN admite el mismo
conjunto de opciones SCREEN que una zona de seguridad de capa 3. (Las zonas
de seguridad de capa 2 admiten una opción adicional de inundación SYN que las
zonas de capa 3 no admiten: descartar direcciones MAC desconocidas). Como las
siguientes opciones SCREEN no se aplican a la zona MGT, no están disponibles
para dicha zona: protección contra inundaciones SYN, protección contra la
inundación SYN-ACK-ACK del proxy, bloqueo de componentes HTTP y protección
frente a ataques de WinNuke.
Para ofrecer protección contra todos los intentos de conexión, los dispositivos de
seguridad 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 inspeccionando, y luego

permitiendo o rechazando, 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 la detección y prevención de intrusiones (IDP).
Un cortafuegos de Juniper Networks proporciona los siguientes grupos de

mecanismos de defensa:
Disuasión de reconocimiento
Barrido de direcciones IP
Análisis de puertos
Rastreo 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
Deep Inspection
Mecanismos de detección y defensa 3

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
Inundación de la tabla de sesiones
Inundación del proxy SYN-ACK-ACK
Ataques DoS contra la red
Inundación SYN
Inundación ICMP
Inundación 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
Protocolos desconocidos
Fragmentos de paquetes IP
Fragmentos SYN
Los ajustes de protección de red de ScreenOS operan a dos niveles: zona de

seguridad y directiva. El dispositivo de seguridad Juniper Networks ofrece defensas
frente a ataques DoS y medidas de disuasión 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 de
cortafuegos a nivel de zona son opciones SCREEN. Una opción de protección de red
ajustada en una directiva es un componente de dicha directiva.
4 Mecanismos de detección y defensa

Capítulo 1: Protección de una red
Supervisar explotaciones de vulnerabilidades

Aunque normalmente se utiliza el dispositivo de seguridad para bloquear
explotaciones de vulnerabilidades, puede haber ocasiones en las que se desee
obtener información sobre ellos. Es posible que desee estudiar detenidamente una
explotación de vulnerabilidad concreta para descubrir su intención, su nivel de
sofisticación o incluso su origen (si el atacante es descuidado o poco sofisticado).
Si desea obtener información sobre una explotación de vulnerabilidad, 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
una explotación de vulnerabilidad, pero que, en lugar de tomar medidas, permita
que la explotación de vulnerabilidad penetre. En tal caso, podrá estudiar qué ha
ocurrido e intentar comprender el método, la estrategia y los objetivos del atacante.
Cuanto mejor comprenda las amenazas que acechan la red, mejor podrá fortificar
sus defensas. Aunque un hacker astuto puede ocultar su ubicación e identidad, tal
vez sea capaz de averiguar la suficiente información como para determinar dónde
se originó el ataque. Puede que también sea capaz de estimar las habilidades del
atacante. Este tipo de información le permitirá calcular su respuesta.
Ejemplo: Supervisión de ataques desde la zona Untrust

En este ejemplo, se han producido ataques de suplantación de IP desde la zona
Untrust a diario, normalmente entre las 9 de la noche y las 12 de la noche. En lugar
de descartar los paquetes con las direcciones IP de origen suplantadas, desea que el
dispositivo de seguridad notifique su llegada pero les permita el paso, quizás
conduciéndolas a un sistema trampa conectado en la conexión de interfaz DMZ. A
las 8:55 de la noche, se modifica el comportamiento del cortafuegos para que
notifique y acepte los paquetes pertenecientes a un ataque detectado en lugar de
notificar y rechazarlos. Cada vez que se produzca el ataque, podrá utilizar el sistema
trampa para supervisar las actividades del atacante después de atravesar el
cortafuegos. Puede trabajar también en colaboración con el ISP de subida para
comenzar a rastrear la procedencia de los paquetes hasta su punto de origen.
WebUI
Screening > Screen (Zone: Untrust): Introduzca los siguientes datos y haga clic
en Apply:
Generate Alarms without Dropping Packet: (seleccione)

IP Address Spoof Protection: (seleccione)
CLI
set zone untrust screen alarm-without-drop
set zone untrust screen ip-spoofing
save
Supervisar explotaciones de vulnerabilidades 5

Capítulo 2
Disuasión de reconocimiento
Los atacantes pueden planificar mejor sus ataques si antes conocen el diseño de la
red objetivo del ataque (qué direcciones IP tienen los hosts activos), los puntos de
entrada posibles (qué números de puertos están activos en los hosts activos) y la
constitución de sus víctimas (qué sistema operativo se está ejecutando en los hosts
activos). Para obtener esta información, es necesario realizar un reconocimiento.
Juniper Networks ofrece varias opciones SCREEN para frustrar los intentos de
reconocimiento de los atacantes e impedir que obtengan información valiosa sobre
la red y los recursos de red protegidos.
“Barrido de direcciones IP” en la página 7
“Análisis de puertos” en la página 8
“Reconocimiento de red mediante opciones IP” en la página 9
“Sondeo del sistema operativo” en la página 11
“Flags SYN y FIN activados” en la página 11
“Flag FIN sin flag ACK” en la página 12
“Encabezado TCP sin flags activados” en la página 13
“Técnicas de evasión” en la página 14
“Análisis FIN” en la página 14
“Flags no SYN” en la página 15
“Simulación de IP” en la página 18
“Opciones IP de ruta de origen” en la página 24
6
Capítulo 2: Disuasión de reconocimiento
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 5000 microsegundos). El objetivo de este sistema 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 dirigirse. 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 procedentes 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 4: Barrido de direcciones
Origen: 2.2.2.5
(Probablemente una dirección
suplantada o un agente zombie) ethernet3 ethernet2
Untrust 1.1.1.1/24 1.2.2.1/24
DMZ
Paquetes ICMP
El dispositivo de seguridad realiza una
Dir. Dir. entrada en su tabla de sesiones para
origen destino los 10 primeros paquetes ICMP
11 paquetes ICMP 2.2.2.5 1.2.2.5 procedentes de 2.2.2.5 y realiza una
en 0.005 segundos 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
2.2.2.5 1.2.2.211 directiva permite estos paquetes, el
Nota: Después de la recepción 2.2.2.5 1.2.2.10 dispositivo los marca como no válidos
de los 10 paquetes ICMP, el 2.2.2.5 1.2.2.20 y los elimina de la tabla de sesiones
dispositivo de seguridad registra 2.2.2.5 1.2.2.21 en el siguiente “barrido de basura”,
esto como un barrido de 2.2.2.5 1.2.2.240 que se realiza cada dos segundos. A
direcciones de IP y rechaza el 2.2.2.5 1.2.2.17 partir del décimo paquete, el
Rechazado 2.2.2.5 1.2.2.123 dispositivo rechaza todo el tráfico
paquete undécimo.
2.2.2.5 1.2.2.6 ICMP procedente de 2.2.2.5.
Estudie la activación de esta opción SCREEN para una zona de seguridad sólo si
existe una directiva que permita el tráfico ICMP procedente de dicha zona. De lo
contrario, no es necesario activarla. Si no existe tal directiva, se rechaza todo el
tráfico ICMP procedente de la zona, impidiendo a los atacantes que realicen un
barrido de direcciones IP con éxito.
Para bloquear las limpiezas de direcciones IP originadas en una zona de seguridad

en concreto, utilice una de las siguientes soluciones:
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Introduzca los
IP Address Sweep Protection: (seleccione)

Threshold: (introduzca un valor que active la protección contra limpiezas
de direcciones IP)
Barrido de direcciones IP 7
NOTA: El valor se mide en microsegundos. El ajuste predeterminado es 5000

microsegundos.
CLI
set zone zone screen port-scan threshold number
set zone zone screen ip-sweep
Análisis de puertos
Un análisis de puertos se produce cuando una dirección IP de origen envía paquetes
IP con segmentos TCP SYN a 10 puertos distintos en la misma dirección IP de
destino en un intervalo definido (5000 microsegundos es el valor predeterminado).
El objetivo de este esquema es analizar los servicios disponibles con la esperanza
de que al menos un puerto responda, identificando un servicio al que dirigir su
ataque. El dispositivo 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 analiza 10 puertos en 0,005 segundos (5000
microsegundos), el dispositivo lo marcará como un ataque de análisis de puertos y
rechazará todos los paquetes procedentes del origen remoto (independientemente
de la dirección IP de destino) hasta que transcurra el resto del tiempo de espera
especificado. El dispositivo detecta y descarta el décimo paquete que cumple con
los criterios de ataque de análisis de puertos.
Figura 5: Análisis de puertos
Origen: 2.2.2.5
(Probablemente una dirección
suplantada 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 El dispositivo de seguridad

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

concreto, utilice una de las siguientes soluciones:
WebUI
8 Análisis de puertos
Port Scan Protection: (seleccione)

Threshold: (introduzca un valor que active la protección contra análisis
de puertos)
NOTA: El valor se mide en microsegundos. El ajuste predeterminado es 5000

microsegundos.
CLI
set zone zone screen port-scan threshold number
set zone zone screen port-scan
Reconocimiento de red mediante opciones IP

La norma de protocolo de Internet RFC 791, Internet Protocol, especifica una serie
de opciones que ofrecen controles de enrutamiento, herramientas de diagnóstico y
medidas de seguridad especiales. Estas opciones aparecen después de la dirección
de destino en un encabezado de paquetes IP, tal y como se muestra en la Figura 6.
Figura 6: Opciones de enrutamiento
Encabezado IP Longitud de Tipo de servicio

Versión encabezado Tamaño total del paquete (en bytes)
Identificación 0 D M Desplazamiento
Tiempo de vida Protocolo Suma de comprobación
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 Tamaño Uso intencionado Uso pernicioso

End of 01 0 0 Indica el fin de una o más opciones IP. Ninguno.
Options
No Options 0 1 0 Indica que no hay opciones IP en el Ninguno.
encabezado.
Security 0 2 11 bits Ofrece un medio para que los hosts 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 Estados
Unidos. (Esta opción, según se especifica
en RFC 791, Internet Protocol, y RFC 1038,
Revised IP Security Option, está obsoleta).
Reconocimiento de red mediante opciones IP 9

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

Loose Source 0 3 Variable Especifica una lista de rutas parcial que Evasión. El atacante puede utilizar
Route debe tomar un paquete en su trayecto las rutas especificadas para ocultar
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 24).
intermedios.
Record 0 7 Variable Registra las direcciones IP de los Reconocimiento. Si el host de
Route 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 atacante, é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).
Stream ID 0 8 4 bits (Obsoleta) Ofrecía un medio para que el Desconocido. Sin embargo, ya que
identificador de secuencia SATNET de 16 se trata de una opción obsoleta, su
bits se transportara por redes presencia en un encabezado IP
incompatibles con el concepto de resulta sospechosa.
secuencia.
Strict Source 0 9 Variable Especifica la lista de la ruta completa que Evasión. Un atacante puede utilizar
Route debe tomar un paquete en su trayecto las rutas especificadas para ocultar
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 24).
Timestamp 22 4 Registra la hora (en formato de horario Reconocimiento. Si el host de
universal3) en la que cada dispositivo de destino es un equipo
red recibe el paquete durante su itinerario comprometido bajo el control del
desde el punto de origen al de destino. Los atacante, é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.
Las siguientes opciones SCREEN detectan las opciones IP que un atacante puede
utilizar para el reconocimiento o cualquier otro propósito desconocido, pero
sospechoso:
Record Route: El dispositivo de seguridad detecta paquetes en los que la

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

opciones IP incluya la opción 4 (Internet Timestamp) y registra el evento en la
lista de contadores SCREEN para la interfaz de entrada.
10 Reconocimiento de red mediante opciones IP

Security: El dispositivo de seguridad detecta paquetes en los que la opción IP

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

sea 8 (Stream ID) y registra el evento en la lista de contadores SCREEN para la
interfaz de entrada.
Para detectar paquetes con las opciones IP anteriores ajustadas, utilice uno de los
siguientes métodos (la zona de seguridad especificada es la zona en la que se
originó el paquete):
WebUI
IP Record Route Option Detection: (seleccione)

IP Timestamp Option Detection: (seleccione)
IP Security Option Detection: (seleccione)
IP Stream Option Detection: (seleccione)
CLI
set zone zone screen ip-record-route
set zone zone screen ip-timestamp-opt
set zone zone screen ip-security-opt
set zone zone screen ip-stream-opt
Sondeo del sistema operativo

Antes de lanzar una explotación de vulnerabilidad, es posible que un atacante
intente sondear el host al que se dirige el ataque para averiguar qué sistema
operativo (OS) utiliza. Conociendo este dato, puede decidir con mejor criterio qué
ataque lanzar y qué vulnerabilidades aprovechar. Un dispositivo de seguridad
Juniper Networks puede disuadir los sondeos de reconocimiento utilizados
habitualmente para obtener información sobre los tipos de OS.
Flags SYN y FIN activados

Los flags de control SYN y FIN no están activados normalmente en el mismo
encabezado de segmento TCP. El flag SYN sincroniza números de secuencia para el
inicio de una conexión TCP. El flag FIN indica el final de la transmisión de datos
para la terminación de una conexión TCP. Sus propósitos se excluyen mutuamente.
Un encabezado TCP con los flags SYN y FIN activados representa un
comportamiento TCP anómalo y puede provocar varias respuestas del destinatario
en función del OS. Consulte la Figura 7.
Sondeo del sistema operativo 11

Figura 7: Encabezado de TCP con flags SYN y FIN establecidos
Encabezado Número de puerto de origen de 16 bits Número de puerto de destino de 16 bits

TCP
Número de secuencia de 32 bits
Número de reconocimiento de 32 bits

Longitud de Reservado U A P R S F
encabezado de (6 bits) R C S S Y I Tamaño de ventana de 16 bits
4 bits G K H T N N
Suma de comprobación de TCP de 16 bits Puntero urgente de 16 bits
Opciones (si las hay)
Datos (si los hay)
Los flags SYN y FIN están activados.
Un atacante puede enviar un segmento con ambos flags activados para ver qué tipo
de respuesta de sistema se devuelve y determinar de este modo qué tipo de OS se
utiliza en el punto de destino. A continuación, el atacante puede emplear cualquier
vulnerabilidad conocida del sistema para futuros ataques.
Al activar esta opción SCREEN, el dispositivo de seguridad comprueba si los flags

SYN y FIN están activados en encabezados TCP. Si descubre un encabezado de tales
características, descarta el paquete.
Para bloquear paquetes con los flags SYN y FIN activados, utilice uno de los
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione SYN
and FIN Bits Set Protection y haga clic en Apply.
CLI
set zone zone screen syn-fin
Flag FIN sin flag ACK

La Figura 8 muestra los segmentos TCP con el flag 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 flag FIN activado tienen también el flag ACK activado (para
acusar recibo del anterior paquete recibido). Como la existencia de un encabezado
TCP con el flag FIN activado y el flag 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 flag RST activado.
También es posible que lo ignore completamente. La respuesta de la víctima puede
proporcionar información sobre el OS al atacante. (Otros motivos para enviar un
segmento TCP con el flag FIN activado pueden ser evadir la detección durante un
análisis de puertos y direcciones o burlar las defensas destinadas a prevenir
inundaciones SYN provocando una inundación FIN en su lugar. Para obtener más
información sobre los análisis FIN, consulte “Análisis FIN” en la página 14).
12 Sondeo del sistema operativo

NOTA: Los proveedores han interpretado la norma RFC 793, Transmission Control
Protocol de diversas formas a la hora de diseñar las implementaciones TCP/IP.
Cuando se recibe un segmento TCP con el flag FIN activado y el flag ACK sin
activar, determinadas implementaciones envían segmentos RST. Otras descartan
el paquete sin enviar ningún segmento RST.
Figura 8: Encabezado TCP con flag FIN activado
Encabezado Número de puerto de origen de 16 bits Número de puerto de destino de 16 bits

TCP
4 bits G K H T N N
Datos (si los hay)
Sólo está activado el flag FIN.
Al activar esta opción SCREEN, el dispositivo de seguridad comprueba si el flag FIN

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

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

Figura 9: Encabezado TCP sin flags activados
Encabezado TCP Número de puerto de origen de 16 bits Número de puerto de destino de 16 bits
4 bits G K H T N N
Datos (si los hay)
No hay ningún flag activado.
Si el dispositivo de seguridad está habilitado para detectar encabezados de

segmento TCP sin flags activados, el dispositivo descartará todos los paquetes TCP
que carezcan de campo de flags o que tengan un campo de flags mal formado.
Para bloquear los paquetes que no tengan ningún flag activado, utilice uno de los
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione TCP
Packet without Flag Protection y haga clic en Apply.
CLI
set zone zone screen tcp-no-flag
Técnicas de evasión
Ya sea mientras recopila información o lanza un ataque, el atacante normalmente
espera evitar que lo detecten. Aunque ciertos análisis de direcciones IP y puertos
son tan descarados que se pueden detectar fácilmente, algunos atacantes con
mayores recursos utilizar una gran cantidad de medios para ocultar su actividad.
Técnicas tales como la utilización de análisis FIN en lugar de análisis SYN (que los
atacantes saben que la mayoría de cortafuegos y programas de detección de
intrusiones detectan) indican una evolución en las técnicas de reconocimiento y
explotación de vulnerabilidades con el objetivo de eludir la detección y llevar a cabo
sus acciones.
Análisis FIN
Un análisis FIN envía segmentos TCP con el flag FIN activado para intentar provocar
una respuesta (un segmento TCP con el flag RST activado) y así descubrir un host
activo o un puerto activo en un host. El atacante puede utilizar este método no para
realizar un barrido de direcciones con peticiones de eco ICMP o un análisis de
direcciones con segmentos SYN, sino porque sabe que muchos cortafuegos se
defienden contra estos dos últimos, pero no necesariamente contra los segmentos
FIN. Si se utilizan segmentos TCP con el flag FIN activado se puede evadir la
detección, permitiendo así que el atacante tenga éxito en su intento de
reconocimiento.
14 Técnicas de evasión
Para frustrar un análisis FIN, puede ejecutar cualquiera de las siguientes acciones o
ambas:
Habilitar la opción SCREEN que bloquea específicamente segmentos TCP con el

flag FIN activado, pero no el flag ACK, lo que no es normal en un segmento TCP.
WebUI: Screening > Screen: Seleccione la zona a la que desea aplicar esta
opción SCREEN en la lista desplegable “Zone” y seleccione FIN Bit With No
ACK Bit in Flags Protection.
CLI: Escriba set zone name screen fin-no-ack, en el cual name es el

nombre de la zona a la cual desea aplicar esta opción SCREEN.
Cambiar el comportamiento de procesamiento de paquetes para rechazar todos

los paquetes no SYN que no pertenezcan a una sesión existente, mediante el
comando CLI: set flow tcp-syn-check. (Para obtener más información sobre la
comprobación del flag SYN, consulte la siguiente sección, “Flags no SYN” en la
página 15).
NOTA: Cambiando el flujo de paquetes para comprobar que el flag SYN está activado
para los paquetes no pertenecientes a sesiones existentes también se frustran
otros tipos de análisis no SYN, tales como los análisis nulos (“null scan”, es decir,
cuando no hay ningún flag de TCP activo).
Flags no SYN
De forma predeterminada, el dispositivo de seguridad revisa si hay flags SYN en el
primer paquete de una sesión y rechaza cualquier segmento TCP que tenga flags
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 aumente la revisión de flag SYN
antes de crear una sesión. La Figura 10 en la página 16 muestra las secuencias del
flujo de paquetes cuando está activada la revisión del flag SYN y cuando está
desactivada.
NOTA: De forma predeterminada, la revisión del flag TCP SYN en el paquete inicial de
una sesión está activa cuando instala el dispositivo de seguridad Juniper Networks
con ejecución de ScreenOS 5.1.0 o superior. Si 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 independientemente de que la interfaz de

ingreso esté operando en la capa 3 (Layer 3) (modo de ruta o NAT) o en la capa 2
(Layer 2) (modo transparente).
Técnicas de evasión 15
Figura 10: Comprobación de flag YN
Con la comprobación de flag SYN habilitada Con la comprobación de flag SYN inhabilitada
El paquete llega a El paquete llega a

Interfaz de ingreso Interfaz de ingreso
En En
Consulta sesión Consulta sesión
Actualización de Actualización ADELANTE
de ADELANTE
sesiones de sesión sesiones de sesión
No en No en
sesión sesión
Permitir Sí Creación Consulta Permitir Creación

Consulta de Comprobación ADELANTE de ADELANTE
directivas de flag SYN de sesión directivas de sesión
Rechazar No Rechazar
DESCARTAR DESCARTAR DESCARTAR
Cuando el dispositivo de seguridad con la comprobación de flag SYN activada

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, salvo que también sea
RST el bit de código del paquete TCP inicial que no es SYN inicial. En ese caso, el
dispositivo de seguridad sencillamente descarta el paquete.
La comprobación de SYN se puede habilitar e inhabilitar con los siguientes

comandos CLI:
set flow tcp-syn-check

unset flow tcp-syn-check
No comprobar el flag SYN en los primeros paquetes ofrece las siguientes ventajas:
NSRP con enrutamiento asimétrico: En una configuración NSRP activa/activa

en un entorno de enrutamiento dinámico, un host puede enviar el segmento
inicial TCP con el flag SYN activado a un dispositivo 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, que 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 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 ser reiniciadas. 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, active 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 indicadas requieren los siguientes sacrificios
en seguridad:
Agujeros de reconocimiento: Cuando un segmento TCP inicial con un flag no

SYN (como ACK, URG, RST, FIN) llega a un puerto cerrado, muchos sistemas
operativos (Windows, por ejemplo) responden con un segmento TCP cuyo flag
RST está activado. Si el puerto está abierto, el receptor no genera ninguna
respuesta.
Analizando las respuestas o la ausencia de éstas, un recopilador de inteligencia

puede realizar un reconocimiento en la red protegida y también en el conjunto
de directivas de ScreenOS. Si después envía un segmento TCP con un flag no
SYN activado y la directiva le permite el paso, el host de destino del segmento
podría descartarlo y responder con un segmento TCP cuyo flag RST esté
activado. Tal respuesta informa al intruso sobre la presencia de un host activo
en una dirección específica y le indica que el número de puerto de destino está
cerrado. El recopilador de inteligencia también averigua que la directiva del
cortafuegos permite acceder a ese número de puerto en ese host.
Con la comprobación del flag SYN habilitada, el dispositivo de seguridad

descarta los segmentos TCP que no tengan flag SYN siempre que no
pertenezcan a una sesión existente. El dispositivo no devolverá un segmento
TCP RST. Por lo tanto, el escáner no obtendrá ninguna respuesta, sea cual sea el
conjunto de directivas o tanto si el puerto está abierto o cerrado en el host de
destino.
Inundaciones de tablas de sesiones: Si la comprobación de SYN está

inhabilitada, un atacante puede evitar la función de protección contra
inundaciones SYN de ScreenOS inundando una red protegida con una cantidad
ingente de segmentos TCP que tengan flags no SYN activados. Aunque los hosts
atacados descartarán los paquetes (y posiblemente envíen segmentos TCP RST
como respuesta), tal inundación podría llenar la tabla de sesiones del
dispositivo de seguridad. Con la tabla de sesiones llena, el dispositivo no puede
procesar nuevas sesiones de tráfico legítimo.
Habilitando la comprobación de SYN y la protección contra inundaciones SYN

se puede frustrar esta clase de ataques. La comprobación de si el flag SYN está
activado en el paquete inicial de una sesión fuerza a todas las nuevas sesiones a
comenzar con un segmento TCP que tenga el flag SYN activado. A
continuación, la protección contra inundaciones SYN limita el número de
segmentos TCP SYN por segundo para evitar saturaciones en la tabla de
sesiones.
NOTA: Para obtener información sobre las inundaciones de la tabla de sesiones, consulte
“Inundación de la tabla de sesiones” en la página 33. Para obtener más
información sobre inundaciones SYN, consulte “Inundación SYN” en la página 40.
Si no necesita desactivar la comprobación de SYN, Juniper Networks le recomienda

que esté activada (su estado predeterminado para una instalación inicial de
ScreenOS). Puede activarla con el siguiente comando: set flow tcp-syn-check. Con
la comprobación de SYN habilitada, el dispositivo de seguridad rechaza los
segmentos TCP sin flags 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 falsa en el encabezado del paquete para que parezca que
procede de un lugar de origen confiable. 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
de la indicada en el encabezado. El método que utilizará el dispositivo de seguridad
Juniper Networks dependerá de si funciona en la capa 3 (Layer 3) o capa 2 (Layer 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 suplantada y la descarta.
Figura 11: 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á
activada 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 Prefijo IP 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
(donde la zona de seguridad especificada será la zona de donde proceden los
paquetes), puede hacer que el dispositivo de seguridad descarte cualquier
paquete cuya dirección IP de origen no se incluya en la tabla de rutas:
set zone zone screen ip-spoofing drop-no-rpf-route
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 es una
dirección IP de origen suplantada y lo descarta.
Figura 12: 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 está

V1-Untrust. Su dirección IP de origen es activada 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 válida para el paquete que llega de la zona Untrust V1.
10.2.2.5
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
V1-Untrust, el dispositivo serv A ethernet2
rechazará el paquete. 1.2.2.5 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 12, 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:
Ha definido una dirección para 1.2.2.0/24 en la zona V1-Untrust.
Dispone de una directiva que permite el tráfico desde cualquier dirección

de la zona V1-DMZ hacia cualquier dirección de la zona V1-Untrust (set
policy from v1-dmz to v1-untrust any any any permit).
Habilita la comprobación de 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 direcciones IP en las
zonas Trust, DMZ y Untrust para un dispositivo de seguridad 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 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 direcciones 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 13: Ejemplo de la simulación de IP de la capa 3 (Layer 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
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



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 protegeremos la zona V1-DMZ contra la simulación de direcciones
IP en el tráfico originado en la zona V1-Untrust. En primer lugar debemos definir
las siguientes direcciones para los tres servidores web de la zona V1-DMZ:
servA: 1.2.2.10
servB: 1.2.2.20
servC: 1.2.2.30
Ahora puede habilitar la protección contra IP simuladas en la zona V1-Untrust.
Si un atacante en la zona V1-Untrust intenta suplantar la dirección IP utilizando

cualquiera de las tres direcciones de la zona V1-DMZ, el dispositivo de seguridad
comprobará la dirección comparándola con las direcciones de la libreta de
direcciones. Cuando descubra que la dirección IP de origen en un paquete
procedente de la zona V1-Untrust pertenece a una dirección definida en la zona
V1-Untrust. el dispositivo rechazará el paquete.
WebUI
1. Direcciones
en OK:
Address Name: servA

Zone: V1-DMZ
en OK:
Address Name: servB

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

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

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

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

enrutadores ethernet1
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
Atacante
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 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 fuerzan el control de acceso, pero los enrutadores 1 y 2 no lo hacen. Además,
el enrutador 2 no comprueba la posible simulación de IP. El atacante suplanta la
dirección de origen y, al utilizar la opción de ruta de origen abierta, dirige el paquete
a través del enrutador 2 hasta la red 2.2.2.0/24 y, desde allí, al enrutador 1. Éste
reenvía el paquete al enrutador 3, que lo reenvía hasta el dispositivo 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 abiertas o estrictas o para que los detecte y, a
continuación, registre el evento en la lista de contadores para la interfaz de entrada.
A continuación se ofrecen las opciones SCREEN:
Deny IP Source Route Option: Active esta opción para bloquear todo el tráfico
IP que emplee la opción de rutas de origen abierta o estricta. Las opciones de
ruta de origen pueden llegar a permitir a un atacante entrar en una red con una
dirección IP falsa.
Detect IP Loose Source Route Option: El dispositivo de seguridad detecta

paquetes en los que la opción IP sea 3 (Loose Source Routing) y registra el
evento en la lista de contadores SCREEN para la interfaz de entrada. Esta
opción especifica una lista de rutas parcial que debe tomar un paquete en su
trayecto desde el punto de origen al de destino. El paquete debe avanzar en el
orden de direcciones especificado, pero se le permite atravesar otros
enrutadores entremedias.
Detect IP Strict Source Route Option: El dispositivo de seguridad detecta

paquetes en los que la opción IP sea 9 (Strict Source Routing) y registra el
evento en la lista de contadores SCREEN para la interfaz de entrada. Esta
opción especifica la lista de rutas completa que debe tomar un paquete en su
trayecto desde el punto de origen al de destino. La última dirección de la lista
sustituye a la dirección del campo de destino.
(Para obtener más información sobre todas las opciones IP, consulte
“Reconocimiento de red mediante opciones IP” en la página 9).
Para bloquear paquetes con la opción IP de ruta de origen abierta o estricta

ajustada, utilice uno de los siguientes métodos (la zona de seguridad especificada es
la zona en la que se originó el paquete):
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione IP
Source Route Option Filter y haga clic en Apply.
CLI
set zone zone screen ip-filter-src
Para detectar y registrar (pero no bloquear) paquetes con la opción IP de ruta de

origen abierta o estricta ajustada, utilice uno de los siguientes métodos (la zona de
seguridad especificada es la zona en la que se originó el paquete):
WebUI
IP Loose Source Route Option Detection: (seleccione)

IP Strict Source Route Option Detection: (seleccione)
CLI
set zone zone screen ip-loose-src-route
set zone zone screen ip-strict-src-route
Capítulo 3
Defensas contra los ataques de
denegación de servicio (DoS)
La intención de un ataque de denegación de servicio (DoS) es abrumar a la víctima

potencial con tal cantidad de tráfico fantasma que se sature intentando procesar el
tráfico fantasma y no consiga procesar el tráfico legítimo. El destino del ataque
puede ser el cortafuegos de Juniper Networks, los recursos de red cuyos accesos
controla el cortafuegos o la plataforma de hardware o el sistema operativo
específico (OS) de un host determinado.
Si un ataque DoS se origina en múltiples direcciones de origen, se conoce como

ataque distribuido de denegación de servicio (Distributed Denial-of-Service o
DDoS). Normalmente, la dirección de origen de un ataque DoS es una dirección
suplantada (“spoofed”). Las direcciones de origen de un ataque DDoS pueden ser
direcciones suplantadas o bien las direcciones reales de hosts previamente
comprometidos por el atacante y que éste utiliza ahora como “agentes zombie”
para ejecutar el ataque.
El dispositivo de seguridad puede defenderse de ataques DoS y DDoS tanto a sí

mismo como a los recursos que protege. Las siguientes secciones describen las
diversas opciones de defensa disponibles:
“Ataques de DoS contra el cortafuegos” en la página 33
“Inundación de la tabla de sesiones” en la página 33
“Inundación proxy SYN-ACK-ACK” en la página 38
“Ataques DoS contra la red” en la página 40
“Inundación SYN” en la página 40
“Cookie SYN” en la página 50
“Inundación ICMP” en la página 52
“Inundación UDP” en la página 53
“Ataque terrestre (“Land Attack”)” en la página 54
“Ataques de DoS específicos de cada sistema operativo” en la página 55
““Ping of Death”” en la página 55
32
Capítulo 3: Defensas contra los ataques de denegación de servicio (DoS)
“Ataque “Teardrop”” en la página 56
“WinNuke” en la página 57
Ataques de DoS contra el cortafuegos

Si un atacante 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 con éxito
contra la red protegida, frustrando los intentos del tráfico legítimo para atravesar el
cortafuegos. En esta sección se explican dos métodos que un atacante puede
utilizar para llenar la tabla de sesiones de un dispositivo de seguridad de Juniper
Networks y, de ese modo, producir una DoS: Inundación de la tabla de sesiones y
Inundación proxy SYN-ACK-ACK.
Inundación de la tabla de sesiones

Un ataque DoS que tenga éxito abruma 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 (inundación SYN,
inundación SYN-ACK-ACK, inundación UDP, inundación 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 de sesiones basadas en sus orígenes y destinos
Envejecimiento agresivo
Límites de sesiones basadas en sus orígenes y destinos

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

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

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

virus/gusano Nimda, que lo utiliza para simultáneas del servidor infectado
generar 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 una sesión basándose en 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 atacante astuto podría ejecutar un ataque distribuido de denegación
de servicio (DDoS). En un ataque DDoS, el tráfico malévolo puede proceder de
centenares de hosts, conocidos como agentes zombie, que están clandestinamente
bajo el control de un atacante. Además de las opciones de detección de
inundaciones SYN, UDP e ICMP y de prevención SCREEN, estableciendo un límite
de sesión basado en su destino se puede garantizar que el dispositivo de seguridad
admita solamente un número aceptable de peticiones de conexión simultáneas (sin
importar su origen) para alcanzar cualquier host.
Figura 17: Ataque DOS distribuido
Limitación de sesiones según su Limitación de sesiones según su destino:

origen: Ataque de denegación de Ataque de denegación de servicio distribuido
servicio
Atacante Atacante
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 simultáneas procedentes de Cuando el número de sesiones simultáneas al servidor web
6.6.6.6 sobrepasa el límite máximo, el dispositivo de seguridad sobrepasa el límite máximo, el dispositivo de seguridad bloquea
bloquea cualquier conexión subsiguiente de esa dirección IP. cualquier intento de conexión subsiguiente a esa dirección IP.
34 Ataques de DoS contra el cortafuegos

Determinar cuál es el número aceptable de peticiones de conexión requiere un

periodo de observación y análisis para establecer una base de referencia con la que
determinar los flujos de tráfico típicos. También se debe tener en cuenta el número
máximo de sesiones simultáneas requeridas para llenar la tabla de sesiones de la
plataforma 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 en su

destino es de 128 sesiones simultáneas, un valor que puede requerir ajustes para
satisfacer las necesidades específicas de su entorno de red y plataforma.
Ejemplo: Limitación de sesiones según su origen

En este ejemplo, se 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, establecerá el límite de
sesiones de origen en el valor más bajo posible: 1 sesión. Por otra parte, la zona
Trust contiene computadoras personales, servidores, impresoras y otros
dispositivos, muchos de los cuales inician tráfico. Para la zona Trust, establecerá el
límite de sesiones de origen en un máximo de 80 sesiones simultáneas.
WebUI
Screening > Screen (Zone: DMZ): Introduzca los siguientes datos y haga clic en
OK:
Source IP Based Session Limit: (seleccione)

Threshold: 1 Sessions
Screening > Screen (Zone: Trust): Introduzca los siguientes datos y haga clic en
OK:

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, se 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 simultáneas que recibe es 2000. De
acuerdo con esta información, decide establecer el nuevo límite de sesiones en
4000 sesiones simultáneas. Aunque sus observaciones muestran que durante los
picos de tráfico a veces se excede ese límite, opta por garantizar la seguridad del
cortafuegos a costa de alguna inaccesibilidad ocasional del servidor.

WebUI
en OK:
Destination IP Based Session Limit: (seleccione)

CLI
set zone untrust screen limit-session destination-ip-based 4000
set zone untrust screen limit-session destination-ip-based
save
Envejecimiento agresivo
De forma predeterminada, el establecimiento de comunicación inicial en 3 fases de
una sesión TCP tarda 20 segundos en caducar (es decir, 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.
NOTA: Esta función no está disponible en los sistemas de las series NetScreen-5000 o
ISG.
Cuando el número de sesiones cae por debajo de un umbral inferior especificado, el

proceso del tiempo de espera vuelve a su estado normal. Mientras el proceso de
envejecimiento agresivo esté activo, el dispositivo de seguridad forzará primero el
envejecimiento de las sesiones más antiguas, aplicándoles la tasa de
envejecimiento previamente especificada. Estas sesiones de envejecimiento
forzado se marcan como no válidas y se eliminan en la siguiente “limpieza de
basura”, que ocurre cada 2 segundos.
La opción de envejecimiento agresivo reduce los tiempos de espera

predeterminados de las sesiones en la magnitud introducida. Al establecer y
habilitar la opción de envejecimiento agresivo, en la configuración seguirán
apareciendo los valores normales de los tiempos de espera de cada tipo de sesión
(1800 segundos para sesiones TCP, 300 segundos para sesiones HTTP y 60
segundos para sesiones UDP). No obstante, cuando se activa el periodo de
envejecimiento agresivo, estas sesiones caducan antes (aplicando el tiempo
especificado para envejecimientos prematuros en lugar de la cuenta atrás hasta
cero).

El valor de envejecimiento agresivo puede estar entre 2 y 10 unidades, donde cada

unidad representa un intervalo de 10 segundos (es decir, el ajuste de
envejecimiento agresivo puede tener 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 envejecimiento agresivo en 100 segundos, acortará los
tiempos de espera de sesiones HTTP y TCP de la siguiente manera:
TCP: El valor del tiempo de espera de la sesión se acorta de 1800 segundos (30
minutos) a 1700 segundos (28:20 minutos) mientras el proceso de
envejecimiento agresivo está activo. Durante ese periodo, el dispositivo 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 18: Tiempo de espera de la sesión TCP:
Min 30 25 20 15 10 5 0
Tiempo de espera predeterminado de la sesión TCP: 30 min
(1800 seg)
Envejecimiento agresivo = 10 (predeterminado - 100 seg):
28:20 min (1700 seg) Seg 1800 1500 1200 900 600 300 0
HTTP: El valor del tiempo de espera de la sesión se acorta de 300 segundos (5

minutos) a 200 segundos (3:20 minutos) mientras el proceso de envejecimiento
agresivo está activo. Durante ese periodo, el dispositivo 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 19: 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)
Envejecimiento agresivo = 10 (predeterminado - 100 seg):
3:20 min (200 seg)
Seg 300 240 180 120 60 0
UDP: Dado que el tiempo de espera predeterminado de una sesión UDP es de

60 segundos, definiendo un ajuste de envejecimiento prematuro de 100
segundos se provoca que todas las sesiones UDP envejezcan y queden
marcadas para su eliminación en la siguiente “limpieza de basura”.
Ejemplo: Forzar el envejecimiento agresivo de sesiones

En este ejemplo establecerá que el proceso de envejecimiento agresivo comience
cuando el tráfico supere un umbral superior del 80 por ciento y finalice cuando
caiga por debajo de un umbral inferior del 70 por ciento. Especificará 40 segundos
como intervalo de envejecimiento agresivo. Cuando la tabla de sesiones se llena
más del 80 por ciento (el umbral superior), el dispositivo de seguridad reduce en 40
segundos el tiempo de espera de todas las sesiones y comienza a forzar
agresivamente el envejecimiento de las sesiones más antiguas hasta que el número
de sesiones en la tabla cae por debajo del 70 por ciento (el umbral inferior).

Figura 20: Sesiones de envejecimiento forzado
100%
Cuando el número de sesiones supera la capacidad del
80%, se activa el mecanismo de envejecimiento agresivo.
80% Umbral superior
Envejecimiento
agresivo
70% Umbral inferior (- 40 seg de
envejecimiento
Las sesiones envejecen forzadamente hasta
forzado)
que su número cae por debajo del 70%. En
Sesiones ese momento, el mecanismo de
envejecimiento agresivo se detiene.
0%
WebUI
NOTA: Para configurar los ajustes de envejecimiento agresivo debe utilizar la interfaz de
línea de comandos (“CLI”).
CLI
set flow aging low-watermark 70
set flow aging high-watermark 80
set flow aging early-ageout 4
save
Inundación proxy SYN-ACK-ACK

Cuando un usuario de autenticación inicia una conexión Telnet o FTP, envía un
segmento SYN al servidor Telnet o FTP correspondiente. El dispositivo 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 del proxy. El usuario responde entonces con
un segmento ACK. En ese momento se completa el establecimiento inicial de
comunicación en tres fases. El dispositivo envía al usuario un mensaje de petición
de inicio de sesión. Si el usuario malévolo, en lugar de iniciar la sesión, continúa
iniciando sesiones SYN-ACK-ACK, la tabla de sesiones de ScreenOS puede llenarse
hasta el punto en que el dispositivo comience a rechazar peticiones de conexión
legítimas.
Consulte la Figura 21 si desea observar el proceso de forma detallada:
1. El cliente envía un segmento SYN al servidor.
2. El dispositivo seguridad envía un segmento SYN/ACK a través del 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 1 a 4 hasta llenar la tabla de sesiones).
6. Al estar la tabla de sesiones completa, el dispositivo de seguridad debe rechazar

todas las demás peticiones de conexión.

Figura 21: Inundación proxy SYN-ACK-ACK
Cliente Telnet o FTP (usuario

de autenticación) Servidor Telnet
Zona Untrust Zona Trust o FTP
SYN
SYN/ACK Tabla de sesiones de ScreenOS:

Recursos disponibles extensos.
ACK
Nombre: ?
Contraseña: ?
SYN
SYN/ACK
ACK La tabla de sesiones se está llenando.
Nombre: ?
Contraseña: ?
.
.
.
SYN La tabla de sesiones está llena.
Para evitar tal ataque, puede habilitar la opción SCREEN de protección

SYN-ACK-ACK del proxy. Cuando el número de conexiones procedentes de una
misma dirección IP alcanza el umbral de SYN-ACK-ACK del proxy, el dispositivo de
seguridad rechaza las peticiones de conexión subsiguientes de esa dirección IP. De
forma predeterminada, el umbral es de 512 conexiones de una determinada
dirección IP. Puede cambiar este umbral (a cualquier número entre 1 y 250.000)
para que se adapte mejor a los requisitos de su entorno de red.
Para habilitar la protección contra una inundación SYN-ACK-ACK del proxy, ejecute
cualquiera de los siguientes procedimientos, donde la zona especificada es aquélla
en la que se origina el ataque:
WebUI
SYN-ACK-ACK Proxy Protection: (seleccione)

Threshold: (introduzca un valor para activar la protección contra la
inundación 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 zone screen syn-ack-ack-proxy threshold number
set zone zone 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, inunda el destino con una cantidad abrumadora de paquetes SYN, ICMP o UDP,
o de fragmentos SYN. Dependiendo del objetivo del atacante y del nivel y éxito de
los esfuerzos de prevención realizados hasta ese momento, el atacante puede
seleccionar un host específico, como un enrutador o un servidor, o bien seleccionar
hosts de forma aleatoria en la red atacada. Cualquiera de las dos tácticas tiene el
potencial de trastornar el servicio a un solo host o a la red entera, dependiendo de
la importancia del papel desempeñado por la víctima en el contexto de su red.
Inundación SYN
Una inundación SYN ocurre cuando un host resulta tan saturado con segmentos
SYN que inician peticiones de conexión irrealizables que le resulta imposible
procesar peticiones de conexión legítimas.
Dos hosts establecen una conexión TCP con triple intercambio de segmentos TCP,
conocido como un establecimiento de comunicación en tres fases: A envía un
segmento SYN a B; B responde con un segmento SYN; A responde con un
segmento ACK. Un ataque de inundación SYN inunda un sitio con segmentos SYN
que contienen direcciones IP de origen falsificadas (simuladas), es decir,
inexistentes o inalcanzables. B responde enviando segmentos SYN/ACK a estas
direcciones y espera segmentos ACK de respuesta. Como los segmentos SYN/ACK
se envían a direcciones IP inexistentes o inalcanzables, nunca obtienen respuesta y
acaban por superar el tiempo de espera.
Figura 22: Ataque de inundación 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, suplantadas. SYN/ACK a la dirección IP de origen simulada, quedando a la espera
1.2.2.5 de respuesta hasta que los intentos caducan.
Direcciones IP
inexistente 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 comienza a
6.6.6.3 llenarse.
SYN
SYN/ACK
Al inundar un host con conexiones TCP incompletas, el atacante acabará por llenar
el búfer de memoria de la víctima. Cuando este búfer se llena, el host ya no puede
procesar nuevas peticiones de conexión TCP. La inundación puede incluso dañar el
sistema operativo de la víctima. En cualquier caso, el ataque inhabilita a la víctima y
sus operaciones normales.
40 Ataques DoS contra la red

Protección contra inundaciones SYN

Los dispositivos de seguridad de Juniper Networks pueden imponer un límite al
número de segmentos SYN a los que se permite atravesar el cortafuegos cada
segundo. Puede definir el umbral de ataque en función de la dirección de destino y
el puerto, sólo en función de la dirección de destino o sólo en función de la
dirección de origen. Cuando el número de segmentos SYN por segundo supera uno
de estos umbrales, el dispositivo 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 23, se
atravesó el umbral de ataque SYN y el dispositivo ha comenzado a procesar
segmentos SYN mediante el proxy.
Figura 23: Procesar segmentos SYN mediante el proxy
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 direcciones de origen suplantadas.
Direcciones IP
inexistente o
inalcanzables
SYN LAN
7.7.7.11 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 la
3.3.3.25 SYN misma dirección de destino alcanza La cola de conexiones
un umbral especificado, el dispositivo procesada por proxy del
SYN/ACK de seguridad comienza a interceptar dispositivo de seguridad
las peticiones de conexión y a comienza a llenarse.
. procesar los segmentos SYN/ACK
. mediante el proxy.
.
En la Figura 24, la cola de conexiones procesada por 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 establecimientos de
comunicación en tres fases incompletos.
Ataques DoS contra la red 41

Figura 24: Rechazar 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 suplantada 3.3.3.5.
LAN
Direcciones IP protegida
inexistentes o
inalcanzables
3.3.3.5 — Umbral de ataque SYN —
SYN
El dispositivo de seguridad intercepta El búfer de memoria de la
SYN/ACK los segmentos SYN y procesa por víctima recupera su estado
proxy las respuestas SYN/ACK hasta normal.
que la cola de conexiones procesada
SYN por proxy se llena.
La cola de conexiones
SYN/ACK procesada por 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 procesada por 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 por proxy las conexiones SYN incompletas por
encima de un umbral establecido afecta solamente al tráfico permitido por las
directivas existentes. Cualquier tráfico para el que no exista una directiva se
descarta automáticamente.
Para habilitar la opción SCREEN de protección contra inundaciones SYN y definir

sus parámetros, ejecute cualquiera de los siguientes procedimientos, donde la zona
especificada es aquélla en la que puede originarse una inundación:
WebUI
SYN Flood Protection: (seleccione para habilitar)

Threshold: (introduzca el número de segmentos SYN (es decir, de
segmentos TCP con el flag SYN activado) requeridos por segundo para
activar el mecanismo de procesamiento de SYN por proxy).
Alarm Threshold: (introduzca el número de peticiones de conexión TCP

procesadas por proxy requeridas para generar una alarma en el registro
de eventos)

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

procedentes de una determinada dirección IP que se requiere para que el
dispositivo 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 procesada por proxy)
Queue Size: (introduzca el número de peticiones de conexión TCP

procesadas por proxy que se mantienen en la cola de conexiones
procesada por proxy antes de que el dispositivo 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 zone screen syn-flood
Para procesar por proxy las peticiones de conexión TCP inacabadas puede
establecer los siguientes parámetros:
Attack Threshold: El número de segmentos SYN (es decir, segmentos TCP con
el flag SYN activado) dirigidos a la misma dirección de destino y número de
puerto requeridos por segundo para activar el mecanismo de procesamiento de
SYN por proxy. Aunque se puede ajustar el umbral en cualquier número, es
necesario conocer los patrones de tráfico habituales en cada instalación para
establecer un umbral adecuado. Por ejemplo, en un sitio de comercio
electrónico que normalmente recibe 20.000 segmentos SYN por segundo,
conviene establecer un umbral de, por ejemplo, 30.000 por segundo. Si un sitio
más pequeño recibe habitualmente 20 segmentos SYN por segundo, plantéese
establecer el umbral en 40.
set zone zone screen syn-flood attack-threshold number
Alarm Threshold: El número de peticiones de conexión TCP semicompletas

procesadas por proxy por segundo que el dispositivo de seguridad espera para
introducir una alarma en el registro de eventos. El valor establecido para un
umbral de alarma dispara una alarma cuando el número por segundo de
peticiones de conexión semicompletadas y procesadas por proxy dirigidas a la
misma dirección de destino y número de puerto supera ese valor. Por ejemplo,
si se establece el umbral de ataque SYN en 2000 segmentos SYN por segundo y
la alarma en 1000, se requiere un total de 3001 segmentos SYN por segundo
dirigidos a la misma dirección de destino y número de puerto para generar una
entrada de alarma en el registro. Más precisamente:

1. El cortafuegos deja pasar los primeros 2000 segmentos SYN por segundo
que cumplen los requisitos de las directivas.
2. El cortafuegos procesa por proxy los 1000 segmentos SYN siguientes en el

mismo segundo.
3. La 1001ª petición de conexión procesada por proxy (o la 3001ª petición de

conexión en ese mismo segundo) dispara la alarma.
set zone zone screen syn-flood alarm-threshold number
Por cada segmento SYN dirigido a la misma dirección y número de puerto de

destino que sobrepase el umbral de alarma, el módulo de detección de ataques
genera un mensaje. Al final del segundo, el módulo de registro comprime todos
los mensajes similares en una sola entrada del registro que indica cuántos
segmentos SYN dirigidos a la misma dirección y número de puerto de destino
llegaron después de haberse rebasado el umbral de alarma. Si el ataque persiste
más allá del primer segundo, el registro de eventos introduce una alarma cada
segundo hasta que el ataque se detenga.
Source Threshold: Esta opción permite especificar el número de segmentos

SYN que deben recibirse por segundo de una determinada dirección IP de
origen (sin tener en cuenta la dirección IP y el número de puerto de destino)
antes de que el dispositivo de seguridad comience a descartar peticiones de
conexión de ese origen.
set zone zone screen syn-flood source-threshold number
El seguimiento de una inundación SYN por su dirección de origen utiliza otros

parámetros de detección que el seguimiento de una inundación SYN por
dirección y número de puerto de destino. Cuando se establece un umbral de
ataque SYN y un umbral de origen, se activan tanto el mecanismo básico de
protección contra inundaciones SYN como el mecanismo de seguimiento de
inundaciones SYN basado en sus orígenes.
Destination Threshold: Esta opción permite especificar el número de

segmentos SYN por segundo que puede recibir una determinada dirección IP
de destino antes de que el dispositivo 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 zone screen syn-flood destination-threshold number
Cuando se establece un umbral de origen SYN y un umbral de destino, se

activan tanto el mecanismo básico de protección contra inundaciones SYN
como el mecanismo de seguimiento de inundaciones SYN basado en sus
destinos.
El seguimiento de una inundación SYN por su dirección de destino utiliza otros

parámetros de detección que el seguimiento de una inundación SYN por
dirección y número de puerto de destino. Observe el caso siguiente, donde el
dispositivo de seguridad tiene directivas que permiten realizar peticiones FTP
(puerto 21) y peticiones HTTP (puerto 80) al mismo servidor. Si el umbral de
ataque para inundaciones SYN es de 1000 paquetes por segundo (pps) y un
atacante envía 999 paquetes FTP y 999 paquetes HTTP por segundo, ninguno

de ambos conjunto de paquetes (entendiendo por conjunto los paquetes que

comparten la misma dirección y número de puerto de destino) activa el
mecanismo de procesamiento de SYN por proxy. El mecanismo básico de
ataque de inundación SYN realiza el seguimiento de direcciones y números de
puerto de destino, y ninguno de los conjuntos supera el umbral de ataque de
1000 paquetes por segundo. Sin embargo, si el umbral de destino es de 1000
pps, el dispositivo trata los paquetes FTP y HTTP con la misma dirección de
destino que los miembros de un solo conjunto y rechaza el 1001º paquete (FTP
o HTTP) dirigido a ese destino.
Timeout: El tiempo máximo antes de que una conexión semicompleta sea

descartada de la cola. El valor predeterminado es de 20 segundos, pero se
puede establecer entre 0 y 50 segundos. Intente reducir el valor del tiempo de
espera hasta que comience a ver conexiones descartadas en condiciones
normales de tráfico. Veinte segundos representan un tiempo de espera muy
conservador para una respuesta ACK a un establecimiento de comunicación de
tres fases.
set zone zone screen syn-flood timeout number
Queue size: El número de peticiones de conexión procesadas por proxy que se

pueden retener en la cola de conexiones procesada por proxy antes de que el
dispositivo 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
procesada por proxy. Esto puede retardar ligeramente el establecimiento inicial
de la conexión; sin embargo, como el tiempo que debe transcurrir antes de
poder comenzar la transferencia de datos es normalmente muy superior al de
cualquier retraso menor en la configuración inicial de la conexión, los usuarios
no percibirán una diferencia notable.
set zone zone screen syn-flood queue-size number
Drop Unknown MAC: Cuando un dispositivo de seguridad detecta un ataque

SYN, procesa por proxy todas las peticiones de conexión TCP. Sin embargo, un
dispositivo en modo transparente no puede procesar por proxy una petición de
conexión TCP si la dirección MAC de destino no está en su tabla de aprendizaje
de MAC. De forma predeterminada, un dispositivo en modo transparente que
ha detectado un ataque SYN entrega paquetes SYN que contienen direcciones
MAC desconocidas. Puede utilizar esta opción para ordenar al dispositivo que
descarte los paquetes SYN que contienen direcciones MAC de destino
desconocidas en lugar de permitirles el paso.
set zone zone screen syn-flood drop-unknown-mac

Ejemplo: Protección contra inundaciones SYN

En este ejemplo protegerá cuatro servidores web en la zona DMZ contra ataques de
inundación SYN originados en la zona Untrust habilitando la opción SCREEN de
protección contra inundaciones SYN para la zona Untrust.
NOTA: 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 25: Protección contra inundaciones SYN a nivel de dispositivo
Servidores Web
ethernet3 ethernet2
1.1.1.1/24 1.2.2.1/24
Zona Untrust 1.2.2.10
Dispositivo de seguridad 1.2.2.20

Zona DMZ
Internet
HTTP 1.2.2.30
SYN Flood
1.2.2.40
Firewall
Para configurar los parámetros de protección contra inundaciones SYN con los
valores apropiados para su red, primero debe establecer una línea de base de los
flujos de tráfico típicos. Durante una semana, ejecute un 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 red que captura paquetes

en el segmento de red al que está conectado. La mayoría de los programas
rastreadores permiten definir filtros para recopilar solamente el tipo de tráfico que
interese. Después podrá visualizar y evaluar la información acumulada. En este
ejemplo se desea que el programa rastreador recoja todos los paquetes TCP con el
flag SYN activado que lleguen a ethernet3 y estén destinados a uno de los cuatro
servidores web en DMZ.
Siga ejecutando el programa rastreador a intervalos periódicos comprobando si

existen patrones de tráfico basados en la hora, el día de la semana, la fase del mes
o la estación del año. Por ejemplo, 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 Value Motivo para cada valor

Attack 625 paquetes Esto supera en un 25% al promedio de picos de nuevas peticiones de conexión por segundo
Threshold por segundo por servidor, algo inusual para este entorno de red. Cuando el número de paquetes SYN por
(Umbral de (pps) segundo de cualquiera de los cuatro servidores web supera este número, el dispositivo
ataque) comienza a procesar por proxy las nuevas peticiones de conexión dirigidas a ese servidor. (En
otras palabras, comenzando por el 626º paquete SYN dirigido a la misma dirección y número
de puerto de destino en un mismo segundo, el dispositivo comienza a procesar por 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 semicompletas y
Threshold procesadas por proxy1). Cuando el dispositivo procesa por proxy 251 nuevas peticiones de
(Umbral de conexión en un segundo, genera una entrada de alarma en el registro de eventos. Aumentando
alarma) 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 basado en orígenes es independiente del seguimiento de paquetes SYN basado en
origen) la dirección y el número de puerto de destino, que constituye el mecanismo básico de
protección contra inundaciones SYN).
Durante la semana de supervisión, observó que no más de 1/25 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 por
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.
Timeout 20 seconds Dado que el tamaño de la cola es relativamente pequeño (1000 peticiones de conexión
(Tiempo de procesadas por proxy), el valor predeterminado de 20 segundos es un tiempo razonable para
espera) mantener las peticiones de conexión incompletas en cola para esta configuración.
Queue Size 1000 1000 peticiones de conexión semicompletas procesadas por proxy es dos veces el promedio de
(Tamaño de conexiones picos de nuevas peticiones de conexión (500 pps). El dispositivo procesa por proxy hasta 1000
la cola) semicompletas peticiones por segundo antes de descartar nuevas peticiones. Procesar por proxy el doble del
procesadas por promedio de picos de nuevas peticiones de conexión proporciona un “colchón” suficiente
proxy como para que puedan pasar las peticiones de conexión legítimas.
1.Las peticiones de conexión semicompletas son establecimientos de comunicación en tres fases incompletos. Un
establecimiento de comunicación en tres fases es la fase inicial de una conexión TCP. Consiste en un segmento TCP con el
flag SYN activado, una respuesta con los flag SYN y ACK activados y una respuesta a ésta con el flag ACK activado.

WebUI
1. Interfaces
haga clic en OK:
Zone Name: DMZ

haga clic en OK:
Zone Name: Untrust

2. Direcciones
en OK:
Address Name: ws1

Zone: DMZ
en OK:
Address Name: ws2

Zone: DMZ
en OK:
Address Name: ws3

Zone: DMZ
en OK:
Address Name: ws4

Zone: DMZ
Objects > Addresses > Groups > (para la zona: DMZ) New: Introduzca el
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
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 por proxy sin estado,
que se puede utilizar junto con las defensas contra un ataque de inundación SYN,
como el que se describe en “Inundación SYN” en la página 40. Al igual que los
procesamientos de SYN por proxy tradicionales, 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 dependiento de la recepción de un segmento SYN y no mantiene ninguna
cola de petición de conexión. Esto reduce enormente el uso de la CPU y de la
memoria y es el beneficio principal de utilizar cookie SYN en lugar del mecanismo
de procesamiento de SYN por proxy tradicional.
Cuando está habilitada la cookie SYN en el dispositivo de seguridad y se convierte

en el proxy para procesamiento de negociación de TCP para el servidor de destino,
éste responde a cada segmento SYN entrante con un SYN/ACK con 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 conteniendo la 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 del proxy TCP 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 26 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 26: Establecer una conexión con la cookie SYN activa
Host TCP Servidor TCP
1 SYN
1. Consulta de sesiones -- Sin coincidencia
de sesión
2. Cookie SYN activada
3. Calcular ISN
4. Volver a enviar SYN/ACK al host
2 SYN/ACK
Enviar ACK
3 ACK
1. Consulta de sesiones -- Sin coincidencia
de sesión
2. Cookie SYS validada
3. Restablecer MSS
4. Primer paquete aprobado--enrutamiento,
consulta de directivas, configuración de sesión
5. Enviar SYN al servidor
4 SYN
1. Aceptar conexión
2. Enviar SYN/ACK
55 SYN/ACK
Enviar ACK a ambos extremos
7 ACK 6 ACK
Conectado
8 Datos/ACK
Datos/ACK
9
Para habilitar una cookie SYN, establezca un umbral de ataque de inundación SYN
(como se describe en “Inundación SYN” en la página 40), y ejecute uno de los
siguientes pasos:
WebUI
Configuration > Advanced > Flow: Introduzca los siguientes datos y haga clic
en Apply:
TCP SYN-proxy SYN-cookie: (seleccione)
CLI
set flow syn-proxy syn-cookie

Inundación ICMP
Una inundación ICMP normalmente se produce cuando las peticiones de eco ICMP
sobrecargan a su víctima con tantas peticiones que ésta consume todos sus
recursos en responder, hasta que le resulta imposible procesar el tráfico de red
válido. Al habilitar la función de protección contra inundaciones ICMP, puede
establecer un umbral que, al ser excedido, activa la función de protección contra
ataques de inundación ICMP. (El valor predeterminado del umbral es 1000 paquetes
por segundo). Si se excede este umbral, el dispositivo de seguridad ignora otras
peticiones de eco ICMP durante el resto de ese segundo y también durante el
segundo siguiente.
NOTA: Una inundación ICMP puede constar de 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 27: Inundación ICMP
El atacante envía peticiones de eco ICMP El dispositivo de seguridad deja pasar las peticiones
con direcciones de origen simuladas. 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 NetScreen rechaza las
peticiones de eco ICMP subsiguientes de
todas las direcciones de la misma zona
Petición de eco de seguridad durante el resto del
segundo actual y también durante el
segundo siguiente.
Petición de eco ICMP legítima de una
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 puede
originarse una inundación:
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 zone screen icmp-flood threshold number
set zone zone screen icmp-flood
Inundación UDP
De forma parecida a una inundación ICMP, una inundación UDP ocurre cuando un
atacante envía paquetes IP que contienen datagramas UDP con el propósito de
ralentizar a la víctima hasta que le resulta imposible procesar las conexiones
válidas. Después de habilitar la función de protección contra inundaciones UDP,
puede establecer un umbral que, cuando se excede, activa la función de protección
contra ataques de inundación UDP. (El valor predeterminado del umbral es 1000
paquetes por segundo). Si el número de datagramas UDP de uno o más orígenes a
un destino determinado supera este umbral, el dispositivo 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 28: Inundación UDP
El atacante envía datagramas UDP en paquetes El dispositivo de seguridad deja pasar los datagramas
IP con direcciones de origen simuladas. 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 de una Puerto: 53 (UDP)
DNS en 1.2.2.5:53.
variedad de Datagrama UDP
direcciones IP
simuladas
Datagrama UDP
— Límite máximo de datagramas UDP por segundo —
Datagrama UDP Una vez alcanzado el umbral de

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

siguientes procedimientos, donde la zona especificada es aquélla en la que puede
originarse una inundación:

WebUI
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 zone screen udp-flood threshold number
set zone zone screen udp-flood
Ataque terrestre (“Land Attack”)

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

destino son las de la víctima. La dirección
de origen que aparece en el encabezado
IP es simulada, mientras que la dirección La víctima crea conexiones
de origen verdadera permanece oculta. vacías consigo misma.
Origen Destino
1.2.2.5 1.2.2.5 Datos
Los recursos
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
SYN y de la protección contra la suplantación de direcciones IP para detectar y
bloquear cualquier intento de esta naturaleza.
Para habilitar la protección contra ataques terrestres, ejecute cualquiera de los

siguientes procedimientos, donde la zona especificada es aquélla en la que se
origina el ataque:
WebUI
Screening > Screen (Zone: seleccione un nombre de zona): Seleccione Land
Attack Protection, después haga clic en Apply.
CLI
set zone zone screen land
Ataques de DoS específicos de cada sistema operativo

Si un atacante identifica no sólo la dirección IP y los números de puerto accesibles
de un host activo, sino también su sistema operativo (OS), en lugar de utilizar
“ataques de fuerza bruta” (“brute-force attacks”), puede atacar de forma más sutil
“liquidando” uno o dos paquetes. Los ataques presentados en esta sección pueden
inutilizar un sistema con un esfuerzo mínimo. Si su dispositivo 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 es de 20 bytes de largo. Una petición de
eco ICMP es un paquete IP con un encabezado falso, de 8 bytes de largo. Por lo
tanto, el tamaño máximo admisible del área de datos de una petición de echo ICMP
es de 65.507 bytes (65.535 - 20 - 8 = 65.507).
Sin embargo, muchas implementaciones del comando ping permiten al usuario

especificar un tamaño del paquete superior a 65.507 bytes. Un paquete ICMP
sobredimensionado puede desencadenar una variedad de reacciones adversas por
parte del sistema, como la denegación del servicio (DoS), “cuelgues”, bloqueos y
reinicios.
Habilitando la opción SCREEN “Ping of Death”, el dispositivo de seguridad detecta y

rechaza esos paquetes sobredimensionados e irregulares incluso cuando el atacante
oculta el tamaño total del paquete fragmentándolo intencionalmente.
Ataques de DoS específicos de cada sistema operativo 55

NOTA: Para obtener información sobre las especificaciones del protocolo IP, consulte
RFC 791, Internet Protocol.
Para obtener más información sobre las especificaciones de ICMP, consulte

RFC 792, Internet Control Message Protocol.
Para obtener información sobre “Ping of Death”, consulte

http://www.insecure.org/sploits/ping-o-death.html.
Figura 30: 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. Excede el límite de 65.535 bytes prescrito en la
RFC 791, Internet Protocol. Durante la transmisión, el paquete se divide en numerosos
fragmentos. Durante el proceso de reensamblaje, el sistema receptor puede quedarse “colgado”.
Para habilitar la protección contra ataques “Ping of Death”, ejecute cualquiera de los
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 zone screen ping-death
Ataque “Teardrop”
Los ataques Teardrop explotan la función de reensamblaje de paquetes IP
fragmentados. En el encabezado IP, uno de los campos es el de desplazamiento del
fragmento, que indica la posición inicial o desplazamiento, de los datos contenidos
en un paquete fragmentado con respecto a los datos del paquete original sin
fragmentar.
Figura 31: Ataques Teardrop
El dispositivo de seguridad comprueba si existen

Encabezado IP discrepancias en el campo de desplazamiento del fragmento.
Longitud del
Versión Tipo de servicio Tamaño total del paquete (en bytes)
encabezado
Desplazamiento
Identificación x D M del fragmento
Tiempo de vida (TTL) 20
Protocolo Suma de comprobación del encabezado bytes
Carga de datos
56 Ataques de DoS específicos de cada sistema operativo

Cuando la suma de “tamaño de desplazamiento” + “tamaño de un paquete

fragmentado” es distinta a la del siguiente paquete fragmentado, los paquetes se
solapan y el servidor que intenta reensamblarlos puede colgarse, especialmente si
está ejecutando un sistema operativo antiguo que tenga esta vulnerabilidad.
Figura 32: Discrepancia entre fragmentos
20 bytes 800 bytes

Paquete
Encabezado IP Datos
fragmentado nº 1
Desplazamiento (“offset”) = 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 (“offset”) = 800 del fragmento nº 1. Esta discrepancia
Longitud = 620 puede hacer que algunos sistemas se
cuelguen al intentar el reensamblaje.
Más fragmentos = 0
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 zone 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 atacante envía un segmento TCP,
normalmente al puerto 139 de NetBIOS con el flag de urgencia (URG) activado, a un
host con una conexión establecida. Esto induce un solapamiento de fragmentos
NetBIOS, que en muchos equipos Windows provoca la caída del sistema. Al
reiniciar el equipo atacado, aparece el siguiente mensaje para indicar que se ha
producido un ataque:
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 57

Figura 33: Indicadores de un ataque WinNuke
El puerto de destino es el 139.

Encabezado TCP
Número del puerto de origen Puerto de destino: 139
Número correlativo
Número de reconocimiento
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 flag URG está activado.
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 flag URG está
activado en alguno de esos paquetes, lo desactiva, borra el indicador URG, reenvía
el paquete modificado y genera una entrada en el registro de eventos indicando que
ha bloqueado un intento de ataque WinNuke.
Para habilitar la protección contra ataques “WinNuke”, ejecute cualquiera de los

origina el ataque:
WebUI
WinNuke Attack Protection, después haga clic en Apply.
CLI
set zone zone screen winnuke
58 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, Kaspersky Lab y Trend Micro.
Juniper Networks ofrece varias funciones de supervisión y filtrado de contenidos

con la opción SCREEN de protección contra URL maliciosas de ScreenOS. Además,
la función de reensamblaje de fragmentos permite que el dispositivo de Juniper
Networks pueda detectar las URL incluso entre segmentos TCP y paquetes IP
fragmentados.
Para la protección antivirus (AV), puede elegir algunos de los dispositivos de

seguridad para obtener una clave de licencia avanzada y una clave de licencia AV, y
utilizar la función de detección de virus interna. Para filtrado de Web, puede
configurar un dispositivo para trabajar con un motor de filtrado de Web interno o
con uno o más servidores de filtrado de Web externo.
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:
“Reensamblar fragmentos” en la página 60
“Protección contra URL maliciosas” en la página 60
“Puerta de enlace en la capa de aplicación” en la página 61
“Análisis antivirus” en la página 63
“Analizar el tráfico de FTP” en la página 64
“Analizar el tráfico de HTTP” en la página 65
“Analizar el tráfico de IMAP y POP3” en la página 68
“Analizar el tráfico de SMTP” en la página 69
“Actualizar el archivo de patrón de AV” en la página 71
“Protección contra Spyware y Phishing” en la página 74
“Análisis AV basado en directivas” en la página 75
59
“Ajustes globales del analizador de AV” en la página 76
“Ajustes de perfiles del analizador de AV” en la página 79
“Filtrado anti-spam” en la página 84
“Filtrado de Web” en la página 88
“Filtrado de Web integrado” en la página 88
“Redirigir el filtrado de Web” en la página 97
Reensamblar fragmentos
Normalmente, los dispositivos de reenvío por red, como conmutadores o
enrutadores, no reensamblan los paquetes fragmentados que reciben. El
reensamblaje de los paquetes fragmentados es responsabilidad del host de destino
una vez los recibe. Como el objetivo de los dispositivos de reenvío es garantizar un
tráfico eficaz, poniendo en cola los paquetes fragmentados, su reensamblaje,
fragmentación y reenvío resultan innecesarios e ineficaces. Sin embargo, el paso de
paquetes fragmentados a través de un cortafuegos es poco seguro. El atacante
puede romper intencionadamente los paquetes y hacer así que las cadenas de
tráfico resultantes crucen el cortafuegos sin que se las detecte y bloquee.
ScreenOS permite habilitar por zonas el reensamblaje de fragmentos. De esta

forma, el dispositivo de seguridad puede ampliar su habilidad de detectar y
bloquear cadenas de URL maliciosas y mejorar su capacidad de proporcionar una
puerta de enlace en la capa de aplicación (ALG) para comprobar las porciones de
datos de los paquetes.
Protección contra URL maliciosas

Además de la función de filtrado de Web, que se explica más adelante en este
capítulo (consulte “Redirigir el filtrado de Web” en la página 97), es posible definir
hasta 48 patrones de cadenas URL maliciosas por zona, cada uno con una longitud
máxima de 64 caracteres, para la protección contra URL maliciosas en el nivel de
zonas. Si la función de bloqueo de URL maliciosas está habilitada, el dispositivo 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 uno de los patrones definidos, el dispositivo bloqueará el
paquete, impidiendo que traspase la puerta de enlace.
Cualquier atacante con recursos, al darse cuenta de que la cadena es conocida y

que se puede bloquear, puede fragmentar los paquetes IP o los segmentos TCP para
que el patrón no sea identificable durante la inspección. Por ejemplo, si la cadena
URL maliciosa es 120.3.4.5/level/50/exec, ésta se podría fragmentar en las
Primer paquete: 120
Segundo paquete: 3.4.5/level/50
Tercer paquete: /exec
60 Reensamblar fragmentos
Capítulo 4: Supervisión y filtrado de contenidos
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.
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, puede haber dos directivas, una que deniegue FTP-Put
procedente de las zonas Untrust a las zonas DMZ y otra que permita FTP-Get desde
las zonas Untrust a las zonas DMZ.
set policy from untrust to dmz any any ftp-put deny

set policy from untrust to dmz any any ftp-get permit
Para distinguir los dos tipos de tráfico, el cortafuegos de NetScreen examina la

carga del paquete. Si el contenido es RETR filename, el cliente FTP ha enviado una
petición para obtener o recuperar (o “retrieve”) el archivo especificado desde el
servidor FTP y el dispositivo permitirá el paso del paquete. Si el dispositivo de
seguridad encuentra STOR filename, el cliente ha enviado una petición para
almacenar (o “store”) el archivo especificado en el servidor y el dispositivo
bloqueará el paquete.
Reensamblar fragmentos 61
Para burlar este tipo de defensa, un atacante puede fragmentar deliberadamente un

paquete FTP-put en dos paquetes que contengan el siguiente texto en las cargas de
datos correspondientes: paquete 1: ST; paquete 2: OR filename. Cuando el
dispositivo de seguridad inspecciona cada paquete de forma individual, no
encuentra la cadena STOR filename, por lo que permite el paso de ambos paquetes.
No obstante, al reensamblarlos, los fragmentos se combinan formando una cadena

que el dispositivo 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 petición 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 petición FTP-get pero el paquete reensamblado

es demasiado grande para reenviarlo, vuelve a fragmentar el paquete y reenvía
los fragmentos.
Si el dispositivo descubre una petición FTP-get y no es necesario fragmentarla,

reenvía el paquete directamente.
Ejemplo: Bloqueo de URL maliciosas en paquetes fragmentados

En este ejemplo, definiremos tres cadenas de URL maliciosas y habilitaremos la
opción de bloqueo de URL maliciosa:
Primera URL maliciosa
ID: Perl
Pattern: scripts/perl.exe
Length: 14
Segunda URL maliciosa
ID: CMF
Pattern: cgi-bin/phf
Length: 11
Tercera URL maliciosa
ID: DLL
Pattern: 210.1.1.5/msadcs.dll
Length: 18
62 Reensamblar fragmentos
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 la coincidencia
se considere correcta. Observe que en las URL primera y tercera, no es necesario
que coincidan todos los caracteres.
A continuación, habilite el reensamblaje de fragmentos para detectar las URL que

lleguen a una interfaz de zona Untrust en el tráfico de HTTP.
WebUI
Screening > Mal-URL (Zone: Untrust): Introduzca los siguientes datos y haga
clic en OK:
ID: perl
Pattern: /scripts/perl.exe
Length: 14
clic en OK:
ID: cmf
Pattern: cgi-bin/phf
Length: 11
clic en OK:
ID: dll
Pattern: 210.1.1.5/msadcs.dll
Length: 18
Network > Zones > Edit (para Untrust): Seleccione la casilla de verificación
TCP/IP Reassembly for ALG y, a continuación, haga clic en OK.
CLI
set zone untrust screen mal-url perl “scripts/perl.exe” 14
set zone untrust screen mal-url cmf “cgi-bin/phf” 11
set zone untrust screen mal-url dll “210.1.1.5/msadcs.dll” 18
set zone untrust reassembly-for-alg
save
Análisis antivirus
Un virus es un código ejecutable que infecta o adjunta otro código ejecutable que le
permite reproducirse. Algunos virus son maliciosos y borran los archivos o
bloquean los sistemas, mientras que otros virus actúan infectando los archivos y
pueden saturar el host objetivo o la red con datos fantasmas.
Seleccione los dispositivos de seguridad Juniper Networks compatibles con el motor

de búsqueda (analizador AV) de antivirus interno (AV) que proporciona análisis
antivirus. Puede configurar el analizador para examinar el tráfico de red que utiliza
los siguientes protocolos:
Análisis antivirus 63
Protocolos Consulte
Protocolo de transferencia de archivos (FTP) “Analizar el tráfico de FTP” en la página 64
Protocolo de transferencia de hipertexto “Analizar el tráfico de HTTP” en la página 65
(HTTP)
Protocolo de acceso de correo de Internet “Analizar el tráfico de IMAP y POP3” en la
(IMAP) página 68
Protocolo de oficina de correo, versión 3 “Analizar el tráfico de IMAP y POP3” en la
(POP3) página 68
Protocolo de transferencia de correo sencillo “Analizar el tráfico de SMTP” en la página 69
(SMTP)
Para aplicar la protección AV, haga referencia al analizador interno en una directiva
de seguridad. Cuando el dispositivo de seguridad recibe tráfico para el cual una
directiva requiere que aplique el análisis de AV, éste dirige el contenido que recibe a
su analizador interno. Después de verificar que ha recibido el contenido completo
de un objeto de FTP, HTTP, IMAP, POP3 o SMTP, el analizador examina los datos en
busca de virus. Esto lo hace según un patrón de virus que permite identificar las
firmas de virus. Cuando el analizador detecta un virus, el dispositivo descarta el
contenido y envía un mensaje al cliente indicando que el contenido está infectado.
Si el analizador no detecta ningún virus, el dispositivo reenvía el contenido al
destino correspondiente.
NOTA: Para consultar información sobre guardar un archivo de patrón de AV en el

dispositivo de seguridad Juniper Networks y luego actualizarlo periódicamente,
consulte “Actualizar el archivo de patrón de AV” en la página 71.
Analizar el 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 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 el descarte está descarta los datos del canal de datos y envía un mensaje de “file
contenido establecido too large” (archivo demasiado grande) al cliente FTP a través del
canal de control
exceden el tamaño máximo de el descarte no está pasa los datos sin examinar al cliente FTP a través del canal de
contenido establecido datos
no se pueden analizar con éxito el modo de fallo no descarta los datos del canal de datos y envía un mensaje “scan
está establecido error” (error de análisis) al cliente FTP a través del canal de
control
64 Análisis antivirus

no se pueden analizar con éxito el permiso de tráfico pasa los datos al cliente FTP a través del canal de datos
está establecido
exceden los mensajes simultáneos el descarte está descarta los datos del canal de datos y envía un mensaje
máximos establecido “exceeding maximum message setting” (excede el
establecimiento máximo de mensaje) al cliente FTP a través del
canal de control
exceden los mensajes simultáneos el descarte no está pasa los datos al cliente FTP a través del canal de datos
máximos establecido
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 puede tener éxito completamente, el dispositivo sigue un curso de acción diferente
dependiendo de la configuración de modo de fallo.
Analizar el tráfico de HTTP

Para el análisis de tráfico de HTTP, el dispositivo de seguridad analiza tanto las
respuestas de HTTP como las peticiones 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 peticiones HTTP de un
cliente. El analizador AV interno analiza también las cargas, p. ej., cuando un cliente
HTTP completa un cuestionario en un servidor web o cuando un cliente escribe un
mensaje en un correo electrónico ubicado en un servidor web.
Dependiendo de los resultados del análisis y cómo esté configurado el

comportamiento del modo de fallo, el dispositivo de seguridad toma una de las
siguientes acciones:

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 el descarte está descarta los datos y envía un mensaje “file too large” (archivo
contenido establecido demasiado grande) al cliente HTTP
exceden el tamaño máximo de el descarte no está pasa los datos al cliente HTTP
contenido establecido
no se pueden analizar con éxito el modo de fallo no descarta los datos y envía un mensaje “scan error” (error de
está establecido análisis) al cliente HTTP
no se pueden analizar con éxito el permiso de pasa los datos al cliente HTTP
tráfico está
establecido
exceden los mensajes simultáneos el descarte está descarta los datos del canal de datos y envía un mensaje
máximos establecido “exceeding maximum message setting” (excede el establecimiento
máximo de mensaje) al cliente HTTP a través del canal de control
exceden los mensajes simultáneos el descarte no está pasa los datos al cliente HTTP a través del canal de datos
máximos establecido
Figura 35: Análisis de antivirus para el tráfico de HTTP
Servidor Web Cliente FTP

remoto local
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
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 busca las entidades de HTTP
compuestas de alguno de los siguientes tipos de contenido MIME (extensiones
multifunción de correo de Internet) y, cuando va seguido de una diagonal, subtipos:
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 conformadas de los tipos de contenido anteriores, el
análisis de HTTP aplica únicamente a un subgrupo pequeño de entidades de HTTP,
tal como los tipos de contenido application/zip y application/exe, donde muy
probablemente se oculten los virus.
Para cambiar el comportamiento de análisis de HTTP para que el dispositivo de

seguridad analice todos los tipos de tráfico de HTTP sin tomar en cuenta los tipos
de contenido de MIME, introduzca el siguiente comando:
set av profile jnpr-profile

(av:jnpr-profile)-> unset av http skipmime
(av:jnpr-profile)-> exit
save
Correo web HTTP

Para el análisis del tráfico del correo Web de HTTP, el dispositivo de seguridad
redirecciona las respuestas del servidor web (respondiendo a las peticiones del
correo web de HTTP de un cliente) al analizador AV interno antes de reenviar el
tráfico al cliente.
Figura 36: Análisis de antivirus para el tráfico de correo web de HTTP
Servidor Web Cliente HTTP

remoto local
1. Un cliente HTTP local envía una petición de correo web HTTP a un servidor web
remoto. El dispositivo de seguridad permite la petición.
2. El dispositivo intercepta la respuesta HTTP entrante y transmite los datos HTTP a
su analizador AV interno, que los examina en busca de virus.
• Si no hay virus, reenvía el mensaje al cliente.
• Si se detecta la presencia de un virus, éste descarta el mensaje y envía un
mensaje de HTTP donde informa sobre 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. Si se descubre un virus en un elemento de la
página HTML, el contenido del elemento se reemplaza por espacio en blanco.
Analizar el tráfico de IMAP y POP3

Para el análisis de tráfico de IMAP y POP3, el dispositivo de seguridad Juniper
Networks redirige 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 toma una de las siguientes acciones:

no están pasa el mensaje al cliente de IMAP o POP3.
contaminados
contienen un virus la notificación por cambia el tipo de contenido a “text/plain”, reemplaza el cuerpo del mensaje con
correo electrónico la siguiente notificación, la envía al cliente de IMAP o POP3 y notifica al emisor:
está establecida VIRUS WARNING (Advertencia de virus).
Contaminated File (archivo contaminado): filename
Virus Name (nombre del virus): virus_name
exceden el tamaño el descarte está cambia el tipo de contenido a “text/plain”, reemplaza el cuerpo del mensaje con
máximo de establecido la siguiente notificación, la envía al cliente de IMAP o POP3:
contenido Content was not scanned for viruses because reason_text_str (code number) and it
o bien was dropped.
no se pueden el modo de fallo no El valor de reason_text_str puede ser uno de los siguientes:
analizar con éxito está establecido The file was too large.
o bien An error or a constraint was found.
exceden los la notificación de The max. content size was exceeded.
mensajes correo electrónico
simultáneos The max. number of messages was exceeded.
está establecida al
máximos emisor o Notifica los problemas de error de análisis al emisor o destinatario.
destinatario
exceden el tamaño el descarte no está pasa el mensaje original al cliente de IMAP o POP3 con la línea de asunto original
máximo de establecido modificada como se muestra a continuación:
contenido original_subject_text_str (Content was not scanned for viruses because
o bien reason_text_str, code number)
no se pueden Notifica los problemas de error de análisis al emisor o destinatario.
analizar con éxito
el permiso de
o bien tráfico está
exceden los establecido
mensajes
simultáneos
máximos
el descarte no está
establecido
la notificación de
correo electrónico
está establecida al
emisor o
destinatario
Figura 37: 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.
Analizar el tráfico de SMTP

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

no están pasa el mensaje al destinatario de SMTP.
contaminados
contienen un virus la notificación cambia el tipo de contenido a “text/plain”, reemplaza el cuerpo del mensaje con la
por correo siguiente notificación, la envía al destinatario de SMTP y notifica al emisor:
electrónico está VIRUS WARNING (Advertencia de virus).
establecida
Contaminated File (archivo contaminado) filename
Virus Name (nombre del virus) virus_name
exceden el tamaño el descarte está cambia el tipo de contenido a “text/plain”, reemplaza el cuerpo del mensaje con la
máximo de establecido siguiente notificación, la envía al destinatario de SMTP:
contenido Content was not scanned for viruses because reason_text_str (code number) and it was
o bien el modo de fallo dropped.
no se pueden no está El valor de reason_text_str puede ser uno de los siguientes:
analizar con éxito establecido The file was too large.
o bien An error or constraint was found.
exceden los el descarte está The max. content size was exceeded.
mensajes establecido
simultáneos The max. number of messages was exceeded
máximos Notifica los problemas de error de análisis al emisor o destinatario.
la notificación
de correo
electrónico está
establecida al
emisor o
destinatario
exceden el nivel el descarte está pasa el mensaje original al cliente de SMTP con la línea de asunto original modificada
máximo de desactivado como se muestra a continuación:
contenido original_subject_text_str (Content was not scanned for viruses because cadena_motivo,
o bien el permiso de code number)
no se pueden tráfico está Notifica los problemas de error de análisis al emisor o destinatario.
analizar con éxito establecido
o bien
exceden los el descarte no
mensajes está establecido
simultáneos la notificación
máximos de correo
electrónico está
establecida al
emisor o
destinatario
NOTA: Ya que el cliente de SMTP se refiere a la entidad que envía un correo electrónico,
es posible que un cliente, de hecho, sea otro servidor de SMTP.
Figura 38: Análisis de antivirus para el tráfico de SMTP
Zona DMZ
Internet
Servidor de correo remoto Analizador AV interno Cliente SMTP
4. Un servidor de correo remoto reenvía un mensaje de correo A. Un cliente SMTP envía un mensaje de correo electrónico a un
electrónico por SMTP al servidor de correo local. servidor de correo local.
5. El dispositivo de seguridad intercepta el mensaje de correo B. El dispositivo de seguridad intercepta el mensaje de correo
electrónico y transmite los datos al analizador AV interno, que los electrónico y transmite los datos al analizador AV interno, que los
examina en busca de virus. examina en busca de virus.
6. 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 de modo de fallo.
Actualizar el archivo de patrón de AV

El análisis AV interno hace necesario cargar una base de datos de firmas de virus
(patrones) en el dispositivo de seguridad Juniper Networks y actualizar el archivo de
firmas periódicamente. Para ello, debe registrar el dispositivo y adquirir una
suscripción para el servicio de firmas de virus. La suscripción permite cargar la
versión actual de la base de datos y actualizarla cada vez que se publiquen nuevas
versiones mientras dure el periodo de validez de la suscripción. Existen dos
procesos distintos para iniciar el servicio de firmas de antivirus:
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
“Registrar y activar los servicios de suscripción” en la página 2-254.
La Figura 39 y la Figura 40 muestran la manera en la cual se actualiza el archivo de

firmas. A continuación se describe el proceso de actualización del archivo de firmas
de virus:
1. En el dispositivo de seguridad, especifique la dirección URL del servidor de

actualización de firmas.
Dependiendo de su tipo de motor de análisis de AV, utilice una de las siguientes

dos URL de actualización de firmas predeterminada:
Analizador de antivirus Juniper-Kaspersky
http://update.juniper-updates.net/av/5gt
Analizador de antivirus Trend Micro
http://5gt-p.activeupdate.trendmicro.com/activeupdate/server.ini.
Figura 39: Actualizar archivos de firmas, paso 1
Dispositivo de seguridad Servidor de

actualizaciones
Petición de transferencia de archivo
Internet
URL de Trend Micro = http://5gt-t.activeupdate.trendmicro.com/activeupdate/server.ini.

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 firmas sea válido. Éste lo
analiza entonces para obtener información sobre le archivo de firmas
actualizado, incluso la versión de archivo de firmas y el tamaño y la ubicación
del servidor de archivo de firmas.
NOTA: ScreenOS contiene un certificado CA para autenticar la comunicación con el

servidor de archivos de actualización de firmas.
3. Si el archivo de firmas en el 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 firmas de AV continúa siendo válida, el dispositivo
recupera automáticamente un archivo de firmas actualizado del servidor de
archivos de firmas.
Figura 40: Actualizar archivos de firmas, paso 2
Dispositivo de seguridad Servidor de

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 firmas a actualizar y 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 para realizar la actualización periódica
del archivo de firmas 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 15 minutos. (El intervalo de actualización
predeterminado es de 60 minutos). Por ejemplo, si el servidor de actualización de
firmas se encuentra en la dirección URL:
http://5gt-p.activeupdate.trendmicro.com/activeupdate/server.ini, usted configura la
actualización automática como se muestra a continuación:
WebUI
Screening > 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, usted actualizar el archivo de firmas manualmente. El
servidor de actualizaciones 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.
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), el nuevo 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 penetre a su empresa.
Esta solución complementa los productos 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 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 elegir cambiar el nivel de seguridad predeterminado de análisis con las

siguientes dos opciones:
Análisis básico sin intervención. Este nivel de análisis administra un grado

más bajo de seguridad al analizar los virus más prevalentes, aunque
proporciona un rendimiento mejorado.
Análisis extendido. Este nivel de análisis incluye tradicionalmente partes más

ruidosas de spyware/adware al análisis estándar. Éste proporciona más
cobertura de spyware pero potencialmente puede devolver más positivos
falsos.
WebUI
NOTA: Para configurar esta opción debe utilizarse la CLI.
CLI
set av scan-mgr pattern-type standard
La opción estándar es la predeterminada.
Análisis AV basado en directivas

Para mejorar el rendimiento y control del motor de análisis de AV, utilice el análisis
basado en directivas, lo que le permite seleccionar tráfico de datos específicos para
el análisis de AV. Para configurar el análisis basado en directivas, debe configurar los
perfiles de AV para el uso en directivas.
1. Iniciar un contexto de perfil de AV.
2. Configurar el perfil (el perfil predefinido es ns-profile).
Seleccione los datos para el análisis de AV basado en uno o más de los

siguientes:
Protocolos de aplicación (FTP, HTTP, IMAP, POP3 o SMTP) con valores

de tiempo de espera
Extensiones de archivo
Tipo de contenido
Desactive la lista de omisión de mime para permitir que el dispositivo de

seguridad busque todos los tipos de tráfico de HTTP sin tomar en cuenta
los tipos de contenido de MIME.
Notifique los errores de análisis y virus (únicamente para el tráfico de IMAP,

POP3 y SMTP) al emisor o destinatarios
3. Salir del contexto del perfil de AV.
4. Asignar el perfil AV a una directiva existente. (Únicamente un perfil de AV se

puede enlazar a una directiva de cortafuegos).
5. Guardar su perfil.
La Figura 41 muestra cómo funciona el perfil de AV con el analizador de AV.
Figura 41: Cómo funciona el perfil de AV con el analizador de AV
Si no hay virus, los datos Un cliente establece una conexión con un

5 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
El perfil de AV determina si la petición
3 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
electrónico basado en el ajuste del
4 analizados, entonces se envían al motor de perfil de AV.
detección de virus para el análisis.
Ajustes globales del analizador de AV

Modificar los ajustes del analizador de AV para cumplir con las necesidades de su
entorno de red. Las siguientes secciones explican los ajustes globales en su
analizador de AV:
Asignar recursos de AV
Comportamiento en modo de fallo
Máximo de mensajes y tamaño máximo del contenido
HTTP Keep-Alive (mantenimiento de conexión)
Goteo HTTP
Asignar 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, impedir la
disponibilidad de que el analizador de AV analice otro tráfico. Para evitar que esto
suceda, el dispositivo de seguridad Juniper Networks puede imponer un porcentaje
máximo de recursos de AV que puede consumir el tráfico desde una ubicación de
origen determinada. 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 number
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 búsqueda, 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.
WebUI
Screening > 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).
Máximo de mensajes y tamaño máximo del contenido

El analizador AV examina un máximo de dieciséis mensajes y 10 megabytes de
contenido de archivo descomprimido en cualquier momento. Si el número total de
mensajes o el tamaño del contenido recibido al mismo tiempo excede estos límites,
el analizador permitirá de forma predeterminada el descarte del contenido sin
examinarlo.
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, permitirá su paso sin examinar el contenido. Puede
modificar este comportamiento predeterminado para que el analizador pase el
tráfico en lugar de descartarlo.
NOTA: El valor predeterminado para el tamaño máximo del contenido es 10 MB. Sin
embargo, si DI no está habilitado, Juniper Networks recomienda la configuración
de un valor de 6 MB.
WebUI
Screening > Antivirus > Scan Manager: Seleccione pass si el tamaño del
archivo excede de 10.000 KB
o bien
Seleccione pass si el número de archivos excede de 16, luego haga clic en

Apply.
CLI
set av scan-mgr max-content-size drop
set av scan-mgr max-msgs drop
HTTP Keep-Alive (mantenimiento de conexión)

De forma predeterminada, el dispositivo de seguridad utiliza 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”). En este método, cuando el servidor HTTP completa la
transmisión de datos, envía un comando TCP FIN para cerrar la conexión TCP y así
indicar que ha finalizado el envío de datos. Cuando el dispositivo recibe un
comando TCP FIN, contiene todos los datos HTTP del servidor y puede ordenar al
analizador AV que comience el análisis.
Puede cambiar el comportamiento predeterminado del dispositivo de seguridad

para utilizar la opción de conexión HTTP “keep-alive”, en la que no se envía
comando TCP FIN para indicar el final de la transmisión de datos. El servidor HTTP
debe indicar de otra forma que se han enviado todos los datos, ya sea enviando la
longitud de los contenidos en el encabezado HTTP o con alguna otra forma de
codificación. El método que se utilice dependerá del tipo de servidor. Este método
hace que la conexión TCP permanezca abierta mientras se realice el análisis
antivirus, lo que disminuye la latencia y mejora el rendimiento del procesador. Sin
embargo, no resulta tan seguro como el método de conexión “close”. Este
comportamiento se puede modificar si detecta que las conexiones HTTP superan el
tiempo de espera durante el análisis antivirus.
WebUI
Screening > Antivirus > 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
Por 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
Screening > Antivirus > Global: Seleccione la casilla de verificación “Trickling
Default” y haga clic en Apply.
CLI
set av http trickling default
Con los parámetros predeterminados, el dispositivo de seguridad emplea el goteo si

el tamaño de un archivo HTTP supera 3 MB de tamaño. Reenviará 500 bytes de
contenido por cada megabyte enviado a analizar.
Para cambiar los parámetros del goteo HTTP, siga uno de estos pasos:
WebUI
Screening > Antivirus > Global: Introduzca los siguientes datos y haga clic en
Apply:
Trickling:
Custom: (seleccione)
Minimum Length to Start Trickling: Introduzca number1.
Trickle Size: Indique number2.
Trickle for Every MB Sent for Scanning: Indique number3.
CLI
set av http trickling number1 number3 number2
Las tres variables de number tienen los siguientes significados:
number1: tamaño mínimo (en megabytes) de un archivo HTTP para que

comience el goteo
number2: tamaño (en bytes) del tráfico no analizado que reenviará el

number3: tamaño (en megabytes) de un bloqueo de tráfico al que el

dispositivo de seguridad aplicará el goteo
NOTA: Los datos sometidos al proceso de goteo en el disco duro del cliente aparecerán
como un pequeño archivo sin utilidad. Dado que el goteo funciona reenviando
pequeñas cantidades de datos a un cliente sin analizarlos, el código malicioso
podría encontrarse entre los datos que el dispositivo de seguridad ha enviado al
cliente por goteo. Recomendamos a los usuarios que eliminen esos archivos.
Puede inhabilitar el goteo HTTP por medio de la interfaz WebUI (Screening >
Antivirus: Haga clic en Disable en la sección Trickling) o con el comando CLI
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 HTTP, es muy probable
que la ventana del explorador rebase el tiempo de espera.
Ajustes de perfiles del analizador 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.
NOTA: Un perfil de AV predefinido denominado ns-profile existía en su dispositivo de

Debe realizar lo siguiente para enlazar el perfil AV a una directiva de cortafuegos.

Solamente es posible enlazar un perfil de AV a una directiva de cortafuegos.
WebUI
Policies: Haga clic en Edit en la directiva a la cual desea enlazar el perfil de AV y
seleccione el perfil bajo el Perfil de antivirus. Haga clic en OK.
CLI
ns5gt1-> set policy id policy_num av ns-profile
Las siguientes secciones explican cómo iniciar un perfil de AV y configurar los

ajustes de perfil:
Iniciar un perfil de AV
Ejemplo: Análisis de todos los tipos de tráfico
Ejemplo: Análisis de AV únicamente para el tráfico SMTP y HTTP
Ajustes de perfiles de AV
Iniciar un perfil de AV
Los siguientes comandos inician 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
Screening > Antivirus > Profile: Seleccione New e introduzca el nombre del
perfil, jnpr-profile, luego haga clic en OK.
CLI
ns5gt(av:jnpr-profile)->
ns5gt1-> set av profile jnpr-profile

ns5gt(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 de todos los tipos de tráfico

En este ejemplo configuraremos el analizador AV para que examine todo el tráfico
FTP, HTTP, IMAP, POP3 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
Screening > Antivirus > Profile: Introduzca profile_name, luego haga clic en
OK.
De forma predeterminada, se analiza el tráfico para los cinco protocolos, FTP, HTTP,
IMAP, POP3 y SMTP.
NOTA: Para cambiar el valor de tiempo de espera, debe utilizar 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 que recibe
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. Regresa el valor de tiempo de espera para ambos protocolos a sus
valores predeterminados: 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
Screening > 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
unset av http webmail enable
save
Ajustes de perfiles de AV
Las siguientes opciones de análisis están configuradas para cada protocolo de
aplicación:
“Descomprimir los archivos adjuntos” en la página 82
“Análisis AV basado en las extensiones de los archivos” en la página 82
“Análisis de AV basado en el tipo de contenido de HTTP” en la página 83
“Notificar el remitente y destinatario por medio de correo electrónico” en la

página 83
“Ejemplo: Eliminación de archivos de gran tamaño” en la página 84
Descomprimir los archivos adjuntos

Cuando el dispositivo recibe datos, el analizador AV interno descomprime cualquier
archivo comprimido. De forma predeterminada descomprime hasta dos niveles de
archivos comprimidos. Por ejemplo, si el analizador recibe un archivo comprimido
que incluye otro archivo adjunto también comprimido, el analizador los
descomprimirá para detectar cualquier virus. Puede configurar el analizador AV
interno para que descomprima hasta cuatro archivos comprimidos unos dentro de
otros.
WebUI
Screening > Antivirus > Profile: Seleccione New o Edit para editar un perfil
existente. Actualice el nivel de descompresión a 2, luego haga clic en Apply.
CLI
set av http keep-alive
unset av http keep-alive
Análisis AV basado en las extensiones de los archivos

Las listas de extensiones de archivo se utilizan para tomar decisiones sobre qué
archivos deben pasar por el análisis de AV para un protocolo específico. Existe una
lista de extensión de archivo de inclusión y una lista de extensión de archivo de
exclusión para cada protocolo.
Un mensaje se analiza cuando su extensión del archivo que contiene figura en la

lista de extensiones de archivo incluidas. Un mensaje no se analiza si la extensión
de archivo está en la lista de extensiones de archivo excluidas. Si la extensión del
archivo no está ni en la lista de inclusión ni en la de exclusión, entonces la decisión
depende del ajuste de análisis de la extensión del archivo predeterminado. La
extensión del archivo predeterminado está en la base de datos del motor de
análisis, así que es sólo de lectura. No existe una lista de extensión de archivo
predefinido para cada protocolo.
Configure el analizador de AV para analizar el tráfico de IMAP por extensiones y

excluya los archivos con las siguientes extensiones: .ace, .arj y .chm.
WebUI
Screening > Antivirus > Ext-list >New > introduzca el nombre de la lista de
extensión (elist1) e introduzca la lista de extensiones (ace;arj;chm). Haga clic en
OK.
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 decidir qué tráfico de HTTP debe pasar por el análisis de AV.
El tráfico HTTP se categoriza en los tipos de MIME (extensiones multifunción de
correo de Internet) 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.
En este ejemplo, usted configura 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
Screening > Antivirus > Profile >Seleccione el perfil a 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 ScreenOS
CLI Reference Guide IPv4 Command Descriptions.
Notificar el remitente y destinatario por medio de correo electrónico

La opción de notificación de correo electrónico 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
Screening > Antivirus > Profile > Seleccione el perfil a Edit > Seleccione
IMAP y luego haga clic en OK.
Introduzca los siguientes datos y haga clic en OK.
Protocols to be scanned:
Email Notify > Select Virus Sender
Email Notify > Select Virus 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 configuraremos el analizador para que descarte el contenido si los
archivos recibidos simultáneamente son más de cuatro o el tamaño descomprimido
de los contenidos es superior a 12 MB.
WebUI
clic en OK:
Drop: (seleccione) file if it exceeds 3000 KB (20~10000)

Drop: (seleccione) file if the number of files exceeds 4 files (1~16)
Screening > Antivirus > Profile: Seleccione Edit > HTTP: Introduzca los
File decompression: 3 layers (1~4)

CLI
set av scan-mgr max-msgs 4
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
La función de anti-spam examina los mensajes transmitidos y decide cuáles son
spam y cuáles no. 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. Anti-spam utiliza un servicio de bloqueo de spam basado en 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 obligatorio ajustar o configurar listas negras. Sin embargo, el
administrador tiene la opción de agregar dominios específicos e IP a las listas
negras o listas blancas locales, las cuales puede reforzar localmente el dispositivo.
Nota: Esta versión admite anti-spam únicamente para el protocolo SMTP.
84 Filtrado anti-spam
El spam son mensajes de correo electrónico no deseados, generalmente enviados

por entidades comerciales, maliciosas o fraudulentas. Para evitar o reducir el
volumen de los mensajes de spam recibidos, puede configurar un perfil anti-spam.
Puede utilizar el perfil en las directivas para detectar y filtrar los mensajes spam en
sospecha. Un perfil anti-spam 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 puede incluir las listas de los
siguientes tipos:
Listas blancas o negras basadas en listas públicas. Si la conexión es desde un

agente de reenvío de correo, el dispositivo puede filtrar la dirección de IP de
origen de la conexión utilizando las listas de dispositivos que parecieran ser
benignas (lista blanca) o maliciosas (lista negra).
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 anti-spam requiere que el cortafuegos tenga conectividad de Internet
con el servidor de lista de bloqueo de spam (SBL). El cortafuegos realiza las
búsquedas de DNS revertidas 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.
De manera alterna, el usuario puede configurar las listas negras y blancas locales
(que se describen anterior y posteriormente). En este caso, de forma
predeterminada el sistema consulta primero la base de datos local de listas
negras/blancas. Si no encuentra el nombre, 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 anti-spam
básica.
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
Filtrado anti-spam 85
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 “Definir una lista negra” en la página 86 y “Definir una lista blanca” en la
página 87.
Filtrar tráfico Spam

En los siguientes ejemplos, el tráfico de SMTP con spam atraviesa el sistema. Sin
embargo, ScreenOS revisa si hay spam ya sea por el nombre de DNS o dirección IP.
ns5gt1-> 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
Descartar mensajes de spam

Al ejecutar el comando set anti-spam profile name_str sin especificar opciones
posteriores coloca CLI dentro del contexto de un perfil anti-spam nuevo o existente.
Por ejemplo, los siguientes comandos definen un perfil denominado ns-profile y
luego introduce el contexto de ns-profile para indicar al dispositivo denegar los
mensajes de spam en sospecha:
ns-> set anti-spam profile ns-profile

ns(ns-profile)-> set default action drop
Después de introducir un contexto anti-spam, todas las ejecuciones de comando
subsecuentes modifican el perfil anti-spam especificado (ns-profile en este
ejemplo). Para guardar sus cambios, debe salir primero del contexto de anti-spam y
luego introducir el comando save:
ns(ns-profile)-> exit
ns-> save
Definir una lista negra

Utilice los comandos de la lista negra para agregar o eliminar una dirección IP,
correo electrónico, nombre de host o nombre de dominio de la lista negra
anti-spam local. Cada entrada en una lista negra puede identificar una entidad que
envía spam.
Ejemplo: Estos comandos realizan las siguientes tareas:
1. Iniciar un contexto de perfil (ns-profile).
2. Proporcionar al perfil una entrada de lista negra que evite las conexiones con el
nombre de host www.wibwaller.com.
3. Salirdel contexto de spam y aplicar el perfil a una directiva existente (id 2).
ns5gt1-> set anti-spam profile ns-profile
86 Filtrado anti-spam
ns5gt1(anti-spam:ns-profile)-> set blacklist www.wibwaller.com

ns5gt1(anti-spam:ns-profile)-> exit
ns5gt1-> set policy id 2 anti-spam ns-profile
Definir una lista blanca

Utilice los comandos de la lista blanca para agregar o eliminar una dirección IP,
correo electrónico, nombre de host o nombre de dominio de la lista blanca local.
Cada entrada en una lista blanca puede identificar una entidad que no sea un
spammer en sospecha. La siguiente tabla muestra algunas entradas posibles.
2. Proporcionar al perfil una entrada de lista blanca que permita las conexiones
con el nombre de host www.fiddwicket.com.
3. Salir del contexto de spam y aplicar el perfil a una directiva existente (id 2).

ns5gt1(anti-spam:ns-profile)-> set whitelist www.fiddwicket.com
Definir 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 la etiqueta en cualquiera de las dos áreas de mensaje de correo

electrónico.
En el encabezado del mensaje
En el asunto del mensaje
2. Especifique que los mensajes de correo electrónico que parecen ser spam
tengan la cadena “Esto es spam” en el encabezado del mensaje.

ns5gt1(anti-spam:ns-profile)-> set default action tag header "This is spam"
Filtrado anti-spam 87
Definir una 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, correo electrónico, nombre de host o nombre de dominio pertenece a
una entidad conocida por enviar spam.
2. Activar el uso del servicio anti-spam predeterminado.

ns5gt1(anti-spam:ns-profile)-> set sbl default-server-enable
Filtrado de Web
El filtrado de Web le permite administrar el acceso a Internet y evitar el acceso a
contenido de Web inapropiado. ScreenOS proporciona dos soluciones de filtrado de
Web:
El filtrado de web integrado le permite admitir o bloquear el acceso a un sitio

solicitado asociando 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 las define el usuario. Para obtener
más información sobre cómo configurar la función de filtrado de Web, consulte
“Filtrado de Web integrado” en la página 88.
El filtrado de Web redirigido redirige el dispositivo de seguridad para enviar la

primera petición de HTTP en una conexión TCP a un servidor Websense o a un
servidor SurfControl, lo que 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
redirigido, consulte “Redirigir el filtrado de Web” en la página 97.
Filtrado de Web integrado

Para activar el filtrado de Web, primero se asocia un perfil de filtrado de Web a una
directiva. Con el filtrado de Web integrado, el dispositivo de seguridad Juniper
Networks intercepta cada petición http, categoriza la URL de un sitio solicitado para
determinar si permite o bloquea el acceso, y luego compara 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.
88 Filtrado de Web
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. 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 aproximado de 40 categorías. Una
lista parcial de las categorías de URL se muestran en “Definir las categorías de URL
(opcional)” en la página 90 y para obtener una lista completa de las categorías de
URL por SurfControl, visite el sitio Web de SurfControl en
http://www.surfcontrol.com. Además de las categorías de URL predefinidas de
SurfControl, también puede agrupar las URL y crear categorías en función de en sus
necesidades. Para obtener más información sobre cómo crear categorías definidas
por el usuario, consulte “Definir las categorías de URL (opcional)” en la página 90.
A continuación se muestra la secuencia básica de acontecimientos que se producen

cuando un host de la zona Trust intenta establecer una conexión HTTP con un
servidor de la zona Untrust.
1. El dispositivo de seguridad revisa si hay una directiva de cortafuegos que

aplique al tráfico.
Si no existe una directiva de cortafuegos para el tráfico, lo descarta.
Si existe una directiva de cortafuegos y si el filtrado de Web está activo en

esa directiva, el dispositivo intercepta todas las peticiones de HTTP.
2. El dispositivo revisa si existe una asociación del perfil definido por el usuario a
una directiva de cortafuegos. Si no existe, utiliza el perfil predeterminado,
ns-profile.
3. El dispositivo revisa 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 guarda en caché el resultado.
4. Una vez el dispositivo determina la categoría de la URL, revisa si la categoría

está en el perfil de filtrado de Web asociada 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, éste realiza la acción predeterminada y

configurada.
Para configurar un dispositivo de seguridad para una Web, realice los pasos que se
describen en las siguientes secciones:
1. Establecer un servidor del sistema de nombres de dominio en la página 90
2. Activar contexto de filtrado de Web en la página 90
3. Definir las categorías de URL (opcional) en la página 90
4. Definir perfiles de filtrado de Web (Opcional) en la página 92
5. Activar las directivas y perfiles de URL en la página 94
Filtrado de Web 89
1. Establecer un servidor del sistema 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 pueda resolver el nombre del servidor de CPA a una dirección. Para
obtener información sobre DNS, consulte “Compatibilidad con DNS” en la
página 2-221.
2. Activar contexto de filtrado de Web

Puede utilizar los comandos CLI o WebUI para activar el filtrado de Web integrado
en un dispositivo de seguridad. Si utilice la CLI, debe introducir el contexto de
filtrado de Web antes de introducir los comandos específicos al filtrado de Web
integrado. Para introducir el contexto de filtrado de Web, utilice el siguiente
comando CLI:
set url protocol sc-cpa

Después de introducir el comando previo, cambia el mensaje de pantalla.
ns(url:sc-cpa)->
Este cambio indica que introdujo el contexto de filtrado de Web y ahora puede
configurar los parámetros de filtrado de Web integrado.
Ejemplo: Activación del filtrado de Web

En este ejemplo, activará el filtrado de Web integrado en un dispositivo de
WebUI
Screening > 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
ns-> set url protocol sc-cpa
ns(url:sc-cpa)-> set enable
ns(url:sc-cpa)-> exit
ns-> save
3. Definir las categorías de 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. A continuación se incluye una lista
parcial de las categorías de URL. 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 las categorías de URL predefinidas de SurfControl, ejecute el

siguiente comando:
WebUI
Screening > Web Filtering > Profile > Predefine Category
90 Filtrado de Web
CLI
ns(url:sc-cpa)-> get category pre
La lista de categoría visualizada es similar a la siguiente:
Type Code Category Name

-----------------------------------------------------------------------------------------------------
PreDefine 76 Advertisements
PreDefine 50 Arts & Entertainment
PreDefine 3001 Chat
PreDefine 75 Computing & Internet
.
.
.
La lista de categorías predefinidas muestra las categorías y sus códigos internos de
SurfControl. Aunque no puede enumerar las URL dentro de una categoría, puede
determinar la categoría de un sitio Web utilizando una función de “Test A Site” en el
sitio Web SurfControl en www.surfcontrol.com.
Además de las categorías de URL predefinidas de SurfControl, puede agrupar las

URL y crear categorías específicas a 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 revisa la lista captada de
direcciones IP e intenta resolver el nombre de host.
Muchos sitios tienen direcciones IP dinámicas, lo que significa que sus direcciones
IP cambian ocasionalmente. 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 es una categoría
predefinida, el dispositivo compara la URL con la categoría definida por el usuario.
Ejemplo: Categoría de URL

En este ejemplo, usted crea una categoría denominada Competitors y agrega las
URL: www.games1.com y www.games2.com.
WebUI
Screening > Web Filtering > Profile > Custom List > New: Introduzca los
Category Name: Competitors

URL: www.games1.com
URL: www.games2.com
Filtrado de Web 91
CLI
ns(url:sc-cpa)-> set category competitors url www.games1.com
ns(url:sc-cpa)-> set category competitors url www.games2.com
ns-> save
4. Definir perfiles de filtrado de Web (Opcional)

Un perfil de filtrado de Web consta de un grupo de categorías de URL y sus acciones
correspondientes:
Permit: El dispositivo de seguridad permite el acceso al sitio.
Block: El dispositivo de seguridad no permite el acceso al sitio. Cuando el

dispositivo bloquea el acceso a un sitio, éste muestra un mensaje indicando la
categoría de URL.
Black List: El dispositivo de seguridad bloquea siempre el acceso a los sitios de

la lista negra. Puede crear una categoría definida por el usuario o utilizar una
categoría predefinida.
White List: El dispositivo de seguridad permite siempre el acceso a los sitios de

la lista blanca. Puede crear una categoría definida por el usuario o utilizar una
categoría predefinida.
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. No puede editar el
perfil predeterminado o agregar una lista blanca o negra. Para ver el perfil
predefinido, utilice el siguiente comando:
WebUI
Screening > Web Filtering > Profile > Predefined Profile
CLI
ns(url:sc-cpa)-> get profile ns-profile
El dispositivo de seguridad muestra el perfil predefinido como el que se muestra

posteriormente:
Web filtering profile name: ns-profile

black-list category: none
white-list category: none
Category Action
Advertisements block
Art & Entetainment permit
Chat permit
Computing & Internet permit
.
.
.
Violence block
Weapons block
92 Filtrado de Web
Web-based E-mail 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 que sea similar a ns-profile, al clonar ns-profile y editar el
nuevo perfil. Realice el siguiente paso en WebUI para clonar ns-profile.
WebUI
Screening > Web Filtering > Profile > Custom Profile: ns-profile: Seleccione
Clone.
NOTA: Debe utilizar WebUI para clonar el perfil predefinido, 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 o la lista blanca.
Cambiar la acción predeterminada.
Ejemplo: Perfil de filtrado de Web

En este ejemplo, creará un perfil personalizado denominado my-profile con una
acción predeterminada de “permit.” Luego, tomará la categoría que creó en el
ejemplo anterior y la agregará a mi-perfil con una acción de block. Observe que
cuando configura la acción predeterminada utilizando CLI, especifica la acción para
la categoría “Other”.
WebUI
Screening > Web Filtering > Profile > Custom Profile > New: Introduzca los
Profile Name: my-profile

Default Action: Permit
Suscribers identified by:

Category Name: Competitors (seleccione)
Action: Block (seleccione)
Configure: Add (seleccione)
CLI
ns(url:sc-cpa)-> set profile my-profile other permit
ns(url:sc-cpa)-> set profile my-profile competitors block
ns-> save
Filtrado de Web 93
5. Activar las directivas y perfiles de URL

Las directivas de cortafuegos permiten o deniegan los tipos de tráfico especificados
de forma unidireccional entre dos puntos. (Para obtener más información sobre las
directivas de cortafuegos, consulte “Directivas” en la página 2-163.) Puede activar
tanto el análisis de antivirus (AV) como el filtrado de web integrado en una directiva.
(Para obtener información sobre el análisis de AV, consulte “Análisis antivirus” en la
página 63.)
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 en la petición de
HTTP entrante con 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 URL predefinidas de SurfControl
Si el dispositivo no encuentra la categoría de la URL solicitada, bloquea o permite el

acceso a la URL en función de la acción predeterminada que esté configurada.
Figura 42: Diagrama de flujo de directivas y perfiles de URL
Petición de HTML
¿En la N ¿En la N ¿En categoría N ¿En categoría N Acción predeterminada -

lista negra? lista blanca? definida por el usuario? predefinida? Bloquear/Permitir
Y Y Y Y
Bloquear URL Permitir URL Bloquear/Permitir según Bloquear/Permitir según

se defina se defina
Si la URL se permite, el dispositivo de seguridad realiza el análisis de AV en el
contenido de la transacción, si está activado y configurado el análisis de AV. Si la
URL está bloqueada, el dispositivo cierra la conexión de TCP, envía un mensaje al
usuario y no revisa el análisis de AV.
94 Filtrado de Web
Ejemplo: Filtrado de Web integrado

En este ejemplo, realice los siguientes pasos para activar el filtrado de Web
integrado en el dispositivo de seguridad y bloquea el acceso a los sitios de los
competidores.
1. Cree una categoría denominada Competitors.
2. Agregue las siguientes URL a la categoría: www.comp1.com y

www.comp2.com.
3. Cree un perfil denominado my-profile y agregue la categoría Competitors a

my-profile.
4. Aplique my-profile a una directiva de cortafuegos.
WebUI
1. Filtrado de Web
Screening > 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.
2. Categoría de URL
Screening > Web Filtering > Profile > Custom List > New: Introduzca los
Category Name: Competitors

URL: www.comp1.com
URL: www.comp2.com
3. Perfil de filtrado de Web
Screening > Web Filtering > Profile > Custom Profile > New: Introduzca los
Profile Name: my-profile

Default Action: Permit
Category Name: Competitors (seleccione)

Action: Block (seleccione)
Configure: Add (seleccione)
4. Directiva
haga clic en OK:
Source Address:
Service: HTTP
Web Filtering: (seleccione), my-profile
Action: Permit
Filtrado de Web 95
CLI
1. Filtrado de Web
ns(url:sc-cpa)-> set enable
2. Categoría de URL
ns(url:sc-cpa)-> set category competitors url www.comp.com
ns(url:sc-cpa)-> set category competitors url www.comp.com
3. Perfil de filtrado de Web
ns(url:sc-cpa)-> set profile my-profile other permit
ns(url:sc-cpa)-> set profile my-profile competitors block
4. Directiva de cortafuegos
ns-> set policy id 23 from trust to untrust any any http permit url-filter
ns-> set policy id 23
ns(policy:23)-> set url protocol sc-cpa profile my-profile
ns(policy:23)-> exit
ns-> save
Servidores de SurfControl
SurfControl tiene tres ubicaciones de servidor, cada una de las cuales sirve a un área
geográfica específica: América, Asia/Oceanía y Europa/Medio Este/África. El
servidor predeterminado principal es el de América, y el servidor de respaldo
predeterminado es Asia/Oceanía. 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/Oceanía es el respaldo para el
servidor de América, el cual es también respaldo para los otros dos servidores).
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. Puede cambiar este valor
predeterminada para que se ajuste al entorno de su red. También puede actualizar
manualmente la lista de categoría introduciendo el contexto de filtrado de Web y
ejecutar el comando CLI exec cate-list-update. Para actualizar manualmente la lista
de categoría, realice lo siguiente:

ns(url:sc-cpa)-> exec cate-list-update
Caché de filtrado de Web

De forma predeterminada, el dispositivo de seguridad guarda en caché la
categorización 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. Puede configurar el tamaño del
caché y cuántas URL se guardan en caché, de acuerdo con el rendimiento y los
requerimientos de memoria del entorno de su red. El tamaño de caché
predeterminado depende de la plataforma y el tiempo de espera predeterminado
es de 24 horas.
96 Filtrado de Web
Ejemplo: Parámetros de caché

En este ejemplo, cambiará el tamaño de caché a 400 kilobytes (KB) y el valor de
tiempo de espera a 18 horas.
WebUI
Screening > Web Filtering > Protocol Selection > SC-CPA: Introduzca los
Enable Cache: (seleccione)

Cache Size: 400 (K)
Cache Timeout: 18 (Hours)
CLI
ns(url:sc-cpa)-> set cache size 400
ns(url:sc-cpa)-> set cache timeout 18
ns-> save
Redirigir el filtrado de Web

Los dispositivos de seguridad Juniper Networks admiten la redirección de filtrado de
web utilizando el motor de empresa de detección de web o el filtrado de Web de
SurfControl, los cuales le permiten bloquear o admitir el acceso a diferentes sitios
en función de 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 43 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.
Filtrado de Web 97
Figura 43: 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 filtrado Respuesta de filtrado

de Web Servidor HTTP
de Web: “block”

Establecimiento de SYN
comunicación TCP de SYN/ACK
3 fases 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 “block”.
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 blocked URL. Éste
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 la Figura 44.
Figura 44: Una URL permitida de la zona Trust a la zona Untrust
set policy from trust to untrust Servidor de filtrado de

any http permit url-filter URL (en la zona Trust)
Petición de Respuesta de filtrado

Cliente HTTP de URL: “permit” Servidor HTTP
filtrado de URL

Establecimiento SYN
de comunicación SYN/ACK
TCP de 3 fases 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.
Reenvío de la HTTP GET
petición HTTP GET
HTTP PUT
El dispositivo de seguridad reenvía el paquete HTTP almacenado en
búfer a la dirección de destino. También permite el paso de otras
peticiones HTTP GET en la misma sesión sin realizar más filtrados
de URL.
HTTP GET
Otras HTTP PUT
peticiones HTTP GET
HTTP GET sin
filtrado URL HTTP PUT
HTTP GET
98 Filtrado de Web
Compatibilidad con sistemas virtuales

Los dispositivos de seguridad con sistemas virtuales 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 del nivel raíz puede configurar el módulo de filtrado de Web en el
nivel de sistema raíz y el nivel de sistemas virtuales (vsys). Un administrador del
nivel vsys puede configurar el módulo URL de su propio sistema virtual, siempre
que dicho sistema disponga de su propio servidor de filtrado de 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.
Alternativamente, los dispositivos con sistemas virtuales que utilizan los servidores
de filtrado de Web Websense pueden compartir los ocho servidores de Websense,
no únicamente 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 varios 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:
set url account name
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 qué vsys
envió la petición URL.
2. Configure los mismos ajustes del servidor de filtrado de Web y los parámetros
de comportamiento 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.
Configurar el redireccionamiento de filtrado de Web

Para configurar un dispositivo para el redireccionamiento del filtrado de Web, debe
realizar lo siguiente:
1. Establezca la comunicación con un máximo de ocho servidores de filtrado de

Web.
2. Defina ciertos parámetros de comportamiento en el nivel de sistema. Un

conjunto de parámetros se puede aplicar al sistema raíz y a cualquier vsys que
comparta la configuración de filtrado de 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.
3. Active el filtrado de Web a los niveles raíz y vsys.
Filtrado de Web 99
4. Habilite el filtrado de Web en directivas individuales.
Los detalles de estos pasos se proporcionan en las siguientes subsecciones.
1. Comunicaciones de dispositivo a dispositivo

Para configurar el dispositivo de seguridad para comunicarse con un servidor
Websense o SurfControl, seleccione el servidor al cual está conectado el dispositivo.
Seleccione una de las opciones siguientes:
Un servidor Websense.
Un servidor SurfControl que utiliza el protocolo de filtrado de contenido de

SurfControl (SCFP).
Un servidor SurfControl que utiliza el protocolo de autoridad de portal de

contenido (CPA). Utilice esto para la solución de filtrado de Web integrado.
(Para obtener información sobre el filtrado de Web integrado, consulte “Filtrado
de Web integrado” en la página 88.)
Para seleccionar el tipo de servidor, utilice uno de los siguientes:
WebUI
Screening > Web Filtering > Protocol
CLI
set url protocol type { websense | scfp |sc-cpa }
Si un dispositivo se conecta a un servidor Websense y el dispositivo tiene varios

sistemas virtuales, los sistemas virtuales pueden compartir el servidor. Para
configurar varios sistemas virtuales para compartir un servidor Websense, utilice el
siguiente comando CLI para crear un nombre de cuenta para cada vsys:
set url account name_str
Una vez configura los nombres de 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
deben tener los mismos ajustes de filtrado de Web.
Configure los siguientes ajustes de filtrado de Web en el nivel de sistema para las
comunicaciones de dispositivo a dispositivo:
Server Name: La dirección IP o nombre completo de dominio (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.
100 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.
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 la
petición o la permite, según se haya configurado. Para el intervalo de tiempo,
puede introducir un número entre 10 y 240.
Para configurar los ajustes previamente mencionados, utilice lo siguiente:
WebUI
Screening > Web Filtering > Protocol > Haga clic en el hipervínculo
Websense/SurfControl
CLI
set url server { ip_addr | dom_name } port_num timeout_num
2. Parámetros de comportamiento en el nivel de sistema
Después de configurar las comunicaciones del dispositivo, defina los parámetros de
comportamiento que desea que tome el sistema, raíz o vsys, cuando aplique el
filtrado de Web. A continuación se ofrecen las opciones de comportamiento:
Si la conectividad al servidor se pierde: Si el dispositivo de seguridad pierde el

contacto con el servidor de filtrado de Web, puede especificar si desea “Block”
o “Permit” todas las peticiones de HTTP.
Tipo de mensaje de URL bloqueada: El origen del mensaje que el usuario

recibe cuando Websense o SurfControl bloquea un sitio. Si selecciona
NetPartners Websense/SurfControl, el dispositivo de seguridad reenvía el
mensaje recibido en la respuesta de “bloqueo” del servidor Websense o
SurfControl. Si selecciona NetScreen, el dispositivo NetScreen envía el mensaje
previamente introducido en el campo “NetScreen Blocked URL Message”.
NOTA: Si selecciona NetScreen, algunas de las funciones que ofrece Websense, como el
redireccionamiento, quedarán suprimidas.
Mensaje URL bloqueada por NetScreen: Éste es el mensaje que el dispositivo

de seguridad devuelve al usuario tras bloquear un sitio. Puede utilizar el
mensaje enviado desde el servidor Websense o SurfControl o puede crear un
mensaje (de hasta 500 caracteres) para que se envíe desde el dispositivo.
Para configurar los ajustes previamente mencionados, utilice lo siguiente:
WebUI
CLI
set url fail-mode { block | permit }
set url type { NetScreen | server }
set url message string
Filtrado de Web 101

3. Activación en el nivel de sistema

El filtrado de Web debe estar activado 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 activar y desactivar el filtrado de Web en el nivel de sistema, utilice uno de los
siguientes:
WebUI
Screening > Web Filtering > Protocol >
Haga clic en el hipervínculo Websense/SurfControl, luego elimine la

selección de la casilla de verificación Enable Web Filtering.
CLI
set url config { disable | 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 inhabilita 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 “permit”.
4. Aplicación en el nivel de directivas

Configure el dispositivo para que comunique el servidor de filtrado de Web de
directiva en directiva.
Para activar el filtrado de Web en una directiva, utilice uno de los siguientes:
WebUI
En WebUI, diríjase a Policies > Edit (para la directiva en la cual desea aplicar el
filtrado de Web) luego seleccione la casilla de verificación Web Filter.
CLI
set policy from zone to zone src_addr dst_addr service permit url-filter
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:
Ejemplo: Configuración del filtrado de Web

En este ejemplo, usted configura 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.
102 Filtrado de Web

2. Queremos aplicar el filtrado a todo el tráfico HTTP saliente desde hosts situados
en la zona Trust hacia hosts en la zona de seguridad 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: “We’re sorry, but the
requested URL is prohibited. If this prohibition appears to be in error, contact
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 y que
tengan la dirección IP 1.1.1.1/24 y la interfaz para la zona Trust como ethernet1
y dirección 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 agrega una ruta a
ésta a través de ethernet1 y el enrutador interno en 10.1.1.250.
4. Configurar las directivas para activar el filtrado de Web de manera que Trust a
Untrust permita el servicio HTTP de cualquier dirección de origen y cualquier
dirección de destino,
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Servidor de filtrado de Web
Screening > 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 (seconds)
If connectivity to the server is lost … all HTTP requests: Permit
Blocked URL Message Type: NetScreen
NetScreen Blocked URL Message: We’re sorry, but the requested URL is
prohibited. Contact ntwksec@mycompany.com.
Filtrado de Web 103

3. Rutas


4. Directiva
haga clic en OK:
Source Address:
Service: HTTP
Action: Permit
Web Filtering: (seleccione)
CLI
1. Interfaces
ns-> set interface ethernet1 zone trust
ns-> set interface ethernet1 ip 10.1.1.1/24
ns-> set interface ethernet3 zone untrust
ns-> set interface ethernet3 ip 1.1.1.1/24
2. Servidor de filtrado de Web
ns-> set url protocol type scfp
ns-> set url server 10.1.2.5 62252 10
ns-> set url fail-mode permit
ns-> set url type NetScreen
ns-> set url message “We’re sorry, but the requested URL is prohibited. Contact
ntwksec@mycompany.com.”
ns-> set url config enable
3. Rutas
ns-> set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
ns-> set vrouter trust-vr route 10.1.2.0/24 interface ethernet1 gateway
10.1.1.250
4. Directiva
ns-> set policy from trust to untrust any any http permit url-filter
ns-> save
104 Filtrado de Web

Capítulo 5
Deep Inspection
Puede habilitar Deep Inspection (DI) en directivas para examinar el tráfico

permitido y ejecutar las acciones correspondientes si el módulo de DI en ScreenOS
detecta signos de ataque o anomalías en el protocolo. En las secciones siguientes de
este capítulo se presentan los elementos de DI (Deep Inspection) que aparecen en
directivas y se explica cómo configurarlos:
“Vista general” en la página 106
“Servidor de la base de datos de objetos de ataque” en la página 110
“Objetos de ataque y grupos” en la página 118
“Protocolos admitidos” en la página 120
“Firmas completas” en la página 124
“Firmas de secuencias TCP” en la página 125
“Anomalías en el protocolo” en la página 125
“Grupos de objetos de ataque” en la página 126
“Desactivar objetos de ataque” en la página 129
“Acciones de ataque” en la página 130
“Acciones de ataques de fuerza bruta” en la página 137
“Registrar ataques” en la página 140
“Asignar servicios personalizados a aplicaciones” en la página 142
“Objetos de ataque y grupos personalizados” en la página 146
“Objetos de ataque de firma completa definidos por el usuario” en la

página 146
“Objetos de ataque de la firma de las secuencias TCP” en la página 151
“Parámetros configurables de anomalías de protocolos” en la página 153
“Negación” en la página 154
105
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 159
“Controles ActiveX” en la página 160
“Applets de Java” en la página 160
“Archivos EXE” en la página 160
“Archivos ZIP” en la página 161
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
las capas 3 y 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 45 muestra cómo 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 capa 4 (IP y TCP) a través de las opciones SCREEN
establecidas a nivel de zonas, no a nivel de directivas. Algunos ejemplos de
detección de anomalías en el tráfico IP y TCP son “Barrido de direcciones IP” en la
página 7, “Análisis de puertos” en la página 8, así como los diversos ataques de
inundación descritos en “Ataques DoS contra la red” en la página 40.
106 Vista general

Capítulo 5: Deep Inspection
Figura 45: Inspección completa del estado del cortafuegos
Inspección de estado completa del ¿Cumple un paquete inicial de una

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

este paquete?
Descartar
paquete
Sí
Inspección de estado completa de

firmas, anomalías de protocolos y
(en el dispositivo NetScreen-5000) ¿DI? ¿Detectado
secuencia TCP Sí ataque? Sí
Ejecutar acción de
respuesta al
No No ataque
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 capa 3) y tanto los números de puerto de origen y de destino como
el protocolo en el segmento TCP o en el encabezado del datagrama UDP (inspección
de 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, denegar 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. Observe que si

habilita DI en una directiva cuya acción sea encapsular, el dispositivo de seguridad
ejecuta las operaciones DI especificadas antes de encriptar un paquete saliente y
después de desencriptar un paquete entrante.
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
Vista general 107

de ataque o anomalías en el protocolo, que el usuario puede definir o descargar al

dispositivo de seguridad de un servidor de base de datos. (Para obtener más
información, consulte “Objetos de ataque y grupos” en la página 118 y “Objetos de
ataque y grupos personalizados” en la página 146).
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 hace
“avanzado”. En este caso, no se requiere 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
“Registrar y activar los servicios de suscripción” en la página 2-254.
Basándose en los objetos de ataque especificados en la directiva, el dispositivo de

seguridad puede realizar las inspecciones siguientes (consulte la Figura 46).
Examinar los valores del encabezado y los datos transportados en busca de

firmas de ataque completas
Comparar el formato del protocolo transmitido con los estándares

especificados en las normas RFC y en sus extensiones con respecto a ese
protocolo para determinar si ha sido alterado, posiblemente con fines
malévolos
Figura 46: Comparacióin de la inspección del cortafuegos y Deep Inspection (DI)
Primero: Inspección del cortafuegos (capas de red): IP Después: Deep Inspection (capas de red y aplicaciones):
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 Transportados Datos Transportados
Si el dispositivo de seguridad detecta un ataque, ejecuta 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 acciones de ataque, consulte “Acciones de ataque”
en la página 130).
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.
108 Vista general

El componente DI ordena al dispositivo de seguridad examinar el tráfico

permitido por la sección central de la directiva para saber si hay patrones que
coincidan con los objetos de ataque contenidos en uno de los grupos de objetos
de ataque. Si el dispositivo de seguridad detecta un objeto de ataque, después
ejecuta la acción definida por el grupo correspondiente.
NOTA: Opcionalmente, también puede agregar otras extensiones al componente central

de un comando set policy: referencias a túneles VPN y L2TP, referencia a una
tarea programada, especificaciones de la traducción de direcciones,
especificaciones de la autenticación de usuarios y ajustes de comprobación
antivirus, registros, recuentos y administración del tráfico. Mientras que estas
extensiones son opcionales, los elementos que constituyen el núcleo de una
directiva (zonas de origen y de destino, direcciones de origen y de destino,
servicio -o servicios- y la acción) son obligatorios. (Una excepción a esta regla son
las directivas globales, en las que no se especifican zonas de origen ni de destino:
set policy global src_addr dst_addr service action. Para obtener más información
sobre directivas globales, consulte “Directivas globales” en la página 2-166.
El siguiente comando set policy contiene un componente de DI:
Figura 47: Componente 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
Zona de Dirección de Acción si el tráfico cumple seguridad detecta
destino destino los criterios de los un ataque
componentes L3 y L4
El comando antedicho ordena al dispositivo de seguridad permitir el tráfico HTTP

procedente de cualquier dirección de la zona Untrust a la dirección de destino
“websrv1” de la zona DMZ. También ordena al dispositivo examinar todo el tráfico
HTTP permitido por esta directiva. 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 descartando el paquete y enviando notificaciones TCP
RST 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:

ns(policy:1)->
NOTA: El símbolo de la línea de comandos cambia para indicar que el comando siguiente
se ejecutará en un contexto de directiva determinado.
Vista general 109

Introducirse en el contexto de una directiva resulta práctico 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 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:
ns-> set policy id 1 from untrust to dmz any websrv1 http permit attack
CRITICAL:HTTP:ANOM action close
ns(policy:1)-> set dst-address websrv2
ns(policy:1)-> set service https
ns(policy:1)-> set attack CRITICAL:HTTP:SIGS action close-server
ns(policy:1)-> set attack HIGH:HTTP:ANOM action drop
ns(policy:1)-> set attack HIGH:HTTP:SIGS action close-server
ns(policy:1)-> exit
ns-> save
La configuración antedicha permite el tráfico HTTP y HTTPS, pero solamente busca

posibles ataques en el tráfico HTTP. Para poder agregar grupos de objetos de ataque
dentro de un contexto de directiva, primero debe especificar un ataque y una
acción DI en el comando de nivel superior. En el ejemplo antedicho, puede agregar
los grupos de objetos de ataque CRITICAL:HTTP:SIGS, HIGH:HTTP:ANOM y
HIGH:HTTP:SIGS porque anteriormente configuró la directiva para 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 severa, que en el ejemplo anterior es
“close”. Para obtener información sobre las siete acciones de ataque, incluyendo
los niveles de gravedad, consulte “Acciones de ataque” en la página 130.
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 predefinidos

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, básica 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 3 se describe
cada uno de los paquetes de firmas predefinidos y la cobertura de la amenaza.
110 Servidor de la base de datos de objetos de ataque

Tabla 3: Paquetes de firmas predefinidos
Paquete de firmas Descripción Cobertura de la amenaza

Básica1 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
optimizado para sucursales y oficinas remotas servicios que enfrenta Internet, como HTTP, DNS,
así como para pequeñas y medianas empresas. FTP, SMTP, POP3, IMAP, NetBIOS/SMB, MS-RPC, P2P
y IM (AIM, YMSG, MSN y IRC).
Protección del Para pequeñas y medianas empresas y Principalmente, se dedica a 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, Oracle 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 y Se enfoca principalmente en evitar que los usuarios
cliente sucursales y oficinas remotas de empresas reciban malware, Trojans, etc., mientras éste navega
importantes que necesitan el cumplimiento y por Internet. Esto incluye un conjunto integral de
defensa de perímetro para los host (equipos de protocolos orientados a los clientes, como HTTP,
escritorio, portátiles, etc.). 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 enfoca
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 DI de
gravedad crítica en dispositivos NS-5XT/GT.
Actualizar paquetes de firmas

Juniper Networks almacena los paquetes de firmas en un servidor en la dirección
https://services.netscreen.com/restricted/sigupdates. Para utilizar los objetos de
ataque predefinidos, debe descargar los paquetes de firmas de este servidor,
cargarlos en su dispositivo de seguridad y luego establecer referencias a
determinados grupos de objetos de ataque específicos en directivas. Para obtener
acceso al servidor de la base de datos de objetos de ataque, primero debe
suscribirse al servicio de firmas DI para su dispositivo. (Para obtener información
sobre cómo hacerlo, consulte “Registrar y activar los servicios de suscripción” en la
página 2-254).
Existen cuatro maneras de actualizar la base de datos:
NOTA: También se puede utilizar NetScreen-Security Manager para descargar los

paquetes de firmas. Para obtener información, consulte el manual
NetScreen-Security Manager Administration Guide (manual de administración de
NetScreen-Security Manager).
Se puede cargar un certificado de autenticación (imagekey.cer) para verificar la

integridad de la base de datos de objetos de ataque cuando lo descarga.
Immediate Update: Con esta opción se actualiza la base de datos de objetos de

ataque en el dispositivo de seguridad inmediatamente con la base de datos
almacenada en el servidor de base de datos de objetos de ataque. Para que esta
Servidor de la base de datos de objetos de ataque 111

operación funcione, primero debe configurar los ajustes del servidor de la base
de datos de objetos de ataque. (Para ver un ejemplo, consulte “Ejemplo:
Actualización inmediata” en la página 113.)
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.
Automatic Update: Con esta opción, el dispositivo de seguridad descarga la

base de datos de objetos de ataque a las horas programadas por el usuario,
siempre que la base de datos del servidor sea una versión más reciente que la
cargada anteriormente en el dispositivo. Juniper Networks actualiza la base de
datos periódicamente con los nuevos patrones de ataque recién descubiertos.
Por lo tanto, debido a su naturaleza cambiante, también se debe actualizar la
base de datos en el 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. (Para ver un ejemplo, consulte “Ejemplo:
Actualizaciones automáticas” en la página 114.)
Automatic Notification and Immediate Update: Con esta opción, el

dispositivo de seguridad comprueba a las horas programadas por el usuario si
los datos sobre el servidor de la base de datos de objetos de ataque son más
recientes que los del dispositivo. 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 de la
página “Configuration > Update > Attack Signature” de 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.
(Para ver un ejemplo, consulte “Ejemplo: Notificación automática y
actualización inmediata” en la página 115.)
Manual Update: Con esta opción, primero utilizará un explorador para

descargar el paquete de firmas a un directorio local o al directorio del servidor
TFTP. A continuación puede cargar la base de datos en el dispositivo de
seguridad mediante WebUI (desde el directorio local) o mediante CLI (desde el
directorio del servidor TFTP). (Para ver un ejemplo, consulte “Ejemplo:
Actualización manual” en la página 116.)
Antes de empezar las descargas

Antes de empezar a descargar un paquete de firmas utilizando cualquiera de los
cuatro métodos que se describen previamente, debe realizar el siguiente
procedimiento:
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) de su dispositivo son exactos.

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, seguidamente, intenta establecer contacto con el

servidor en la URL predeterminada:
https://services.netscreen.com/restricted/sigupdates o si se introdujo una URL
diferente en el campo Database Server, se intenta establecer contacto con la
URL que introdujo. En la Tabla 4 en la página 113 se incluyen los paquetes de
firmas predefinidos y las URL correspondientes.
Después de unos momentos, aparece un mensaje indicando si la actualización

se efectuó con éxito. Si la actualización se efectuó con éxito, entonces se debe
verificar el registro de eventos para determinar el motivo del error.
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.
Ejemplo: Actualización inmediata

En este ejemplo (consulte la Figura 48), se guarda inmediatamente un paquete de
firmas predefinidas del servidor de la base de datos de objetos de ataque en el
dispositivo de seguridad. En la Tabla 4 se enumeran los paquetes de firmas
predefinidos y las URL correspondientes.
Tabla 4: URL para paquetes de firmas predefinidos
Para guardar Especificar esta URL

Paquete de firmas https://services.netscreen.com/restricted/sigupdates.
básicas (predeterminado) El dispositivo de seguridad utiliza esta URL de forma
predeterminada.
Paquete de firmas de https://services.netscreen.com/restricted/sigupdates/server
protección del servidor
Paquete de firmas de https://services.netscreen.com/restricted/sigupdates/client
protección del cliente
Paquete de firmas de https://services.netscreen.com/restricted/sigupdates/worm
mitigación de gusanos
No necesita establecer una tarea programada para actualizar la base de datos en el

dispositivo de seguridad. En lugar de eso, guardará la base de datos del servidor en
el dispositivo de seguridad inmediatamente.

NOTA: En este ejemplo se presupone que ya dispone de una suscripción activada para el
servicio de firmas de DI para el dispositivo de seguridad. (Para obtener
información sobre suscripciones, consulte “Registrar y activar los servicios de
suscripción” en la página 2-254).
Figura 48: Actualización inmediata de las firmas DI
Servidor de la base de datos de

Dispositivo de seguridad local
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: Haga clic en el botón Update
Now.
CLI
ns-> exec attack-db update
Loading attack database.............
Done.
Done.
Switching attack database...Done
Saving attack database to flash...Done.
ns->
Ejemplo: Actualizaciones automáticas

En este ejemplo (consulte la Figura 49), se establecerá una tarea programada para
actualizar la base de datos en el dispositivo de seguridad cada lunes a las 4:00. 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.
Para actualizar el paquete de firmas básicas, utilice la URL predeterminada:

https://services.netscreen.com/restricted/sigupdates. Consulte la Tabla 4 en la
página 113 para encontrar una lista de paquetes de firmas predefinidos y las URL
correspondientes.

Figura 49: Actualización automática de las firmas DI
Servidor de la base de
Dispositivo de seguridad local datos de objetos de
1. Comprobación automática de la actualización ataque
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:
Database Server: (dejar en blanco)

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 mode update
set attack db schedule weekly monday 04:00
save
Ejemplo: Notificación automática y actualización inmediata

En este ejemplo (consulte la Figura 50), se establecerá una tarea programada para
comprobar diariamente a las 07:00:00 la base de datos en el dispositivo de
seguridad.
Cuando reciba un aviso de que la base de datos del servidor se ha actualizado, haga
clic en el botón Update Now de la página “Configuration > Update > Attack
Signature” de WebUI o ejecute el comando exec attack-db update para guardar la
base de datos del servidor en el dispositivo.

página 113 para encontrar una lista de paquetes de firmas predefinidos y las URL
correspondientes.

Figura 50: Notificación de actualizaciones de firmas
Servidor de la base
Dispositivo de seguridad local de datos de objetos
1. Comprobación automática de la actualización de ataque
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:
Database Server: (dejar en blanco)

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

En este ejemplo (consulte la Figura 51), 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 la nueva URL en el campo “Database Server” de la página
“Configuration > Update > Attack Signature” o utilizar el comando CLI siguiente:
set attack db server url_string.
Para una actualización automática, el dispositivo de seguridad agregará

automáticamente los siguientes elementos a la 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 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.3 y la plataforma es NetScreen-208 (ns200). Por lo tanto, la URL
resultante es:
https://services.netscreen.com/restricted/sigupdates/5.3/ns200/attacks.bin?s
n=0043012001000213
Figura 51: Actualización manual de firmas DI
Servidor de la base de
datos de objetos de ataque
Dispositivo de seguridad local 1. Descarga manual de la base de datos
Internet
2. Base de
datos de URL = https://services.netscreen.com/
Base de datos de objetos de Base de datos de /restricted/sigupdates/5.3/ns200/attacks
objetos de ataque ataque objetos de ataque .bin?sn=0043012001000213
Admin: 10.1.1.5 C:\netscreen\attacks-db
C:\Archivos de programa\TFTP Server
1. Descargar el paquete de firmas

página 113 para encontrar una lista de paquetes de firmas predefinidos y las
URL correspondientes.

Introduzca la URL siguiente en el campo de dirección de su explorador:
https://services.netscreen.com/restricted/sigupdates/5.3/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. Actualizar el 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.
118 Objetos de ataque y grupos

Figura 52: Grupos y objetos de ataque
set policy from untrust to dmz any Grupo de ataque: 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 TCP RST al origen y al destino.
RST RST
Los grupos de objetos de ataque a los que se haga referencia en el componente DI

de una directiva, deben apuntar al mismo tipo de servicio que la directiva permite.
Por ejemplo, si la directiva permite tráfico SMTP, el grupo de objetos de ataque debe
tener como objetivo los ataques contra el tráfico SMTP. La directiva siguiente
muestra una configuración válida:
set policy id 2 from trust to untrust any any smtp permit attack CRIT:SMTP:SIGS action
close
La siguiente directiva es incorrecta porque permite el tráfico SMTP, pero el grupo de

objetos de ataque se refiere al tráfico POP3:
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 implementase, haría que

el dispositivo de seguridad consumiera recursos innecesariamente, ya que
examinaría el tráfico SMTP en busca de objetos de ataque POP3 que nunca
encontraría. Si la directiva 2 permite tanto el tráfico SMTP como el POP3, puede
configurar el componente DI para que busque objetos de ataque SMTP, objetos de
ataque POP3 o ambos.
set group service grp1

set group service grp1 add smtp
set group service grp1 add pop3
Objetos de ataque y grupos 119

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 5: Protocolos básicos de red
Anomalía
Firma en el
Protocolo completa protocolo Definición
DNS Sí Sí Domain Name System (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 que los usuarios puedan descargar sus
correos electrónicos o dejarlos en el servidor IMAP.
NetBIOS Sí Sí NetBIOS (Network Basic Input Output System) 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í El 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
DHCP Sí Sí El protocolo de configuración dinámica de hosts se utiliza para controlar los
parámetros de redes vitales de hosts (ejecutando clientes) con la ayuda de un
servidor. DHCP es compatible con versiones anteriores de BOOTP.
Discard Sí Sí El protocolo Discard es una herramienta útil de medición y depuración. Es un
servicio que simplemente elimina todos los datos para así descartarlos.
Echo Sí Sí El protocolo Echo 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 ECHO, en un puerto 7 TCP o UDP. Seguidamente, 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 ICMP, entregados en paquetes IP,
se utilizan para mensajes fuera de banda que están relacionados con el
funcionamiento de la red.

Anomalía
Firma en el
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í Sistema de colas 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 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, utilizando
una transmisión de noticias confiable 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 hora 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 de autenticación remota 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 con
propiedades en tiempo real. Establece y controla secuencias sincronizadas en una
sola hora o en varias horas de medios continuos, como audio y video.
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 utilizando 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 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.

Anomalía
Firma en el
VNC Sí Sí La informática de red virtual (Virtual Network Computing) 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 TCP basada en un
servidor de consulta/respuesta que proporciona un servicio de directorio de todos
los usuarios de Internet.
Tabla 6: Aplicaciones de mensajería inmediata
Anomalía
Firma en el
AIM Sí Sí Mensajería inmediata de America Online (America Online Instant Messaging 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! Sí Sí Yahoo! Messenger es el servicio de mensajería inmediata que proporciona Yahoo!
Messenger
IRC Sí Sí El chat de retransmisión de Internet (Internet Relay Chat) 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 7: Aplicaciones de redes Punto a punto (P2P)
Anomalía
Firma en el
BitTorrent Sí No BitTorrent es una herramienta de distribución de archivos 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 P2P. Una red DC
(Direct connect) 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 hubs ofrecen áreas de interés especiales, creando comunidades
pequeñas para usuarios conectados.
eDonkey Sí No eDonkey es una aplicación de reparto de archivos P2P descentralizada que utiliza
el protocolo de transferencia de archivos de múltiples fuentes (MFTP). La red
eDonkey admite dos clases de aplicaciones: clientes y servidores. Los clientes se
conectan a la red y comparten archivos. Los servidores actúan como
concentradores (hubs) de reunión para los clientes.
Gnutella Sí Sí Gnutella es una aplicación y protocolo de reparto de archivos P2P 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 de reparto de archivos P2P descentralizada que utiliza el
protocolo FastTrack. KaZaa se utiliza principalmente para compartir archivos
MP3.
MLdonkey Sí No MLdonkey es una aplicación de cliente P2P que se puede ejecutar en múltiples
plataformas y puede obtener acceso a múltiples redes P2P, como BitTorrent, DC,
eDonkey, FastTrack (KaZaa, entre otros), así como Gnutella y Gnutella2.

Anomalía
Firma en el
Skype Sí No Skype es un servicio telefónico gratis de Internet P2P que le permite a los
usuarios hablar entre ellos a través de una red TCP/IP como Internet.
SMB Sí Sí SMB (Server Message Block) 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 de reparto de archivos P2P que le permite al cliente
conectarse a varios servidores simultáneamente.
NOTA: Varias de las aplicaciones P2P enumeradas, utilizan sus propios protocolos
patentados.
Tabla 8: Puertas de enlace en la capa de aplicación (ALG)
Anomalía
Firma en el
MSRPC Sí Sí MSRPC (Microsoft-Remote Procedure Call) 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 una de las URL antedichas está vinculada a una página HTML que contiene
una lista de todos los objetos de ataque predefinidos (agrupados por gravedad) para
un protocolo determinado. Para consultar la descripción de un objeto de ataque,
haga clic en su nombre.

Firmas completas
Una firma de ataque es un patrón que aparece cuando se está produciendo la
explotación de una determinada vulnerabilidad. La firma puede ser un patrón de
tráfico de capa 3 o 4, como cuando una dirección envía muchos paquetes a
diversos números de puerto de otra dirección (consulte “Análisis de puertos” en la
página 8), o un patrón textual, como cuando aparece una cadena de URL maliciosa
en los datos transportados de un único paquete HTTP o FTP. La cadena también
puede ser un segmento de código específico o un valor determinado en el
encabezado del paquete. Sin embargo, cuando el módulo Deep Inspection (DI) de
un dispositivo 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 147.
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 atacantes utilizan el patrón. La utilización de información contextual
para refinar el análisis de paquetes reduce significativamente las falsas alarmas (o
“falsos positivos”) y evita el procesamiento innecesario. El término “firmas
completas” destaca este concepto de buscar firmas en los contextos de los papeles
de los participantes y en el estado de la sesión.
Para averiguar qué ventaja tiene considerar el contexto en el que se produce una
firma, observe cómo el módulo DI examina los paquetes cuando está habilitado
para detectar el ataque “EXPN Root”. Los atacantes utilizan el ataque “EXPN Root”
para ampliar y exponer las listas de distribución de un servidor de correo. Para
detectar el ataque “EXPN Root”, el dispositivo de seguridad busca la firma “expn
root” en la porción de control de una sesión del protocolo simple de transferencia
de correo (“Simple Mail Transfer Protocol” o “SMTP”). El dispositivo 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.
Aplicando una técnica textual simple de detección de firmas en los paquetes, la

firma “expn root” dispara una alarma incluso aunque aparezca en la porción de
datos de la conexión SMTP; es decir, en el cuerpo de un mensaje de correo
electrónico. Si, por ejemplo, estuviese escribiendo a un colega un mensaje sobre
ataques EXPN Root, un detector simple de firmas en paquetes lo consideraría como
un ataque. Utilizando firmas completas, el módulo 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 120.

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 las secuencias
TCP” en la página 151).
NOTA: Las firmas de secuencias TCP sólo se pueden definir en sistemas de la serie
NetScreen-5000.
Las firmas de secuencias son independientes de los protocolos y son, por

consiguiente, más flexibles a la hora de 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 el rendimiento y el consumo
de los recursos.
Las firmas de secuencias consumen los recursos y afectan el rendimiento, de modo

que deben utilizarse con moderación. No obstante, las firmas de secuencia 256
(Stream256) funcionan de la misma manera, pero en lugar de hacer las
comparaciones a través de toda la secuencia, únicamente lo hacen en los primeros
256 bytes de la secuencia. Por lo tanto, consumen menos recursos y afectan menos
al rendimiento.
Anomalías en el protocolo
Los objetos de ataque que buscan anomalías de protocolos detectan el tráfico que
incumple los estándares definidos en las normas RFC y extensiones comunes de
RFC. Con los objetos de ataque de firma se debe utilizar un patrón predefinido o
crear uno nuevo; por lo tanto, sólo se pueden detectar ataques conocidos. La
detección de anomalías en los protocolos es particularmente útil para detectar
nuevos ataques o aquéllos que no se pueden definir con un patrón textual.
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 120.

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 de forma aproximada por
gravedad. Los tres niveles de gravedad del grupo de objetos de ataque son crítica,
alta y media:
Critical (Crítico): Contiene objetos de ataque coincidentes con explotaciones

de vulnerabilidad que intentan evadir la detección, provocan la caída de
dispositivos de red u obtienen privilegios a nivel del sistema.
High (Alto): Contiene objetos de ataque que coinciden con explotaciones de

vulnerabilidades que intentan interrumpir algún servicio, obtener acceso a
nivel de usuario a un dispositivo de la red o activar un caballo de Troya cargado
previamente en un dispositivo.
Medium (Medio): Contiene objetos de ataque que coinciden con explotaciones

de vulnerabilidades que detectan intentos de reconocimiento para acceder a
información vital mediante navegación de directorios (“directory traversal”) o
filtraciones de información.
Low (Bajo): 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 públicas de comunidad
SNMP y parámetros punto a punto (P2P). También se pueden utilizan los
objetos de ataque de información para obtener información sobre su red.
Cambiar los niveles de gravedad

Aunque los grupos de objetos de ataque están clasificados por protocolo y nivel de
gravedad (critical, high, medium), cada objeto de ataque tiene su propio nivel de
gravedad específico: critical, high, medium, low, info. Estos niveles de gravedad de
objetos de ataque se corresponden del siguiente modo con los niveles de gravedad
para las entradas del registro de eventos:
Tabla 9: Niveles de gravedad de objetos de ataque
Nivel de gravedad de
Nivel de gravedad de entrada de registro de
objetos de ataque – Se asigna a – 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" (medio), la entrada correspondiente que aparecerá en el
registro de eventos tendrá el nivel de gravedad "Warning" (advertencia).

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, entrando en el contexto de una
directiva existente y asignando un nuevo nivel de gravedad a todos los grupos de
objetos de ataque a los que haga referencia la directiva.
A continuación se muestra cómo cambiar mediante WebUI y CLI el nivel de

gravedad de los grupos de objetos de ataque a los que se hace referencia en una
directiva:
WebUI
Policies > Edit (para una directiva existente): Ejecute el siguiente
procedimiento y 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
ns-> set policy id number
ns(policy:number)-> set di-severity { info | low | medium | high | critical }
Para restablecer el ajuste original de nivel de gravedad de cada objeto de ataque,

entre de nuevo en el contexto de una directiva y ejecute 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
ns-> set policy id number
ns(policy:number)-> unset di-severity
Ejemplo: Deep Inspection para P2P

En este ejemplo, se permite que todos los hosts en 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:
INFO:DNS: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 TCP RST 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 varias acciones de ataque que el dispositivo de
seguridad puede ejecutar, consulte “Acciones de ataque” en la página 130. Para
obtener información sobre el registro de ataques detectados, consulte “Registrar
ataques” en la página 140.
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: INFO:DNS: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
INFO:DNS:SIGS action close-client
set policy id 1
ns(policy:1)-> set service gnutella
ns(policy:1)-> set service http
ns(policy:1)-> set attack INFO:GNUTELLA:ANOM action close-client
ns(policy:1)-> set attack INFO:HTTP:SIGS action close-client
ns(policy:1)-> exit
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.
Desactivar 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, simplemente se debe
retirarlo 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 opción es inhabilitar el objeto.
Observe que un objeto de ataque predefinido se inhabilita únicamente en el

sistema raíz o sistema virtual (vsys) en el cual se inhabilita. Por ejemplo, al
inhabilitar un objeto de ataque predefinido en el sistema raíz, dicho objeto no se
inhabilita automáticamente en ningún sistema virtual. De la misma forma, al
inhabilitar un objeto de ataque en un vsys no afecta a dicho objeto en ningún otro
vsys.
NOTA: Inhabilitar objetos de ataque no mejora el rendimiento general.
Para inhabilitar 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 attack_object_name
Para volver a habilitar un objeto de ataque que se inhabilitó 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 attack_object_name

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 TCP RST sólo al servidor para que borre sus recursos mientras el cliente
queda a la espera.
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 TCP RST.
Drop Packet (descarta un paquete determinado pero no interrumpe la

conexión)
Esta opción descarta el paquete en el que se detecta una firma de ataque o una
anomalía de protocolo, pero no termina la sesión propiamente dicha. Utilice
esta opción para 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.
130 Acciones de ataque

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 no 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 en sí. 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.
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 HTTP, HTTPS, PING y FTP-GET procedente

de cualquier dirección de la zona Untrust y dirigido a los servidores web
(websrv1 y websrv2) de la zona DMZ.
Ajuste de ataque para la 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
Logging: Enabled (ajuste predeterminado)
Decide interrumpir la conexión y enviar una notificación TCP RST únicamente

a los servidores web protegidos para que puedan terminar sus sesiones y borrar
sus recursos. Usted prevé recibir ataques de la zona Untrust.
Acciones de ataque 131

Directiva con ID 2: Permitir tráfico HTTP, HTTPS, PING y FTP procedente de

cualquier dirección de la zona Trust y dirigido a los servidores web (websrv1 y
websrv2) de la zona DMZ.
CRITICAL:FTP:SIGS
Acción para todos los grupos de objetos de ataque: Close
Decide interrumpir la conexión y enviar una notificación TCP RST tanto a los
clientes como a los servidores protegidos para que ambos puedan terminar sus
sesiones y borrar sus recursos sin importar el nivel de gravedad del ataque.
Directiva con ID 3: Permitir el tráfico FTP-GET, HTTP, HTTPS, PING desde

cualquier dirección de la zona Trust a cualquier dirección de la zona Untrust.
CRITICAL:FTP:SIGS
Acción para todos los grupos de objetos de ataque: Close Client
Usted elige interrumpir la conexión y enviar una notificación TCP RST a los
clientes protegidos para que ambos puedan terminar sus sesiones y borrar sus
recursos. En este caso, usted prevé un ataque procedente de un servidor HTTP
o FTP no fiable.
Aunque las directivas permiten HTTP, HTTPS, Ping, FTP-Get o FTP, el dispositivo de
seguridad activa la DI únicamente para el tráfico HTTP y FTP. Todas las zonas se
encuentran en el dominio de enrutamiento trust-vr.

Figura 53: 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; Action: Close
Zona Trust
WebUI
1. Interfaces
haga clic en Apply:
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
en OK:

Address Name: websrv1

Zone: DMZ
en OK:
Address Name: websrv2

Zone: DMZ
3. Ruta

4. Directiva con ID 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)
Group: HIGH:HTTP:SIGS
Log: (seleccione)
Group: MEDIUM:HTTP:ANOM


Log: (seleccione)
Group: MEDIUM:HTTP:SIGS
Log: (seleccione)
Group: CRITICAL:FTP:SIGS
Log: (seleccione)
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)
Directivas > (From: Trust, To: Untrust) New: Introduzca los siguientes datos y
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
ns(policy:1)-> set service ftp-get
ns(policy:1)-> set service ping
ns(policy:1)-> set attack HIGH:HTTP:ANOM action close-server
ns(policy:1)-> set attack MEDIUM:HTTP:ANOM action close-server
ns(policy:1)-> set attack MEDIUM:HTTP:SIGS action close-server
ns(policy:1)-> set attack CRITICAL:FTP:SIGS action close-server
ns(policy:1)-> exit
set policy id 2 from trust to dmz any websrv1 http permit attack
CRITICAL:HTTP:ANOM action close
set policy id 2
ns(policy:2)-> set service ftp
ns(policy:2)-> set attack CRITICAL:HTTP:SIGS action close
ns(policy:2)-> set attack HIGH:HTTP:ANOM action close
ns(policy:2)-> set attack HIGH:HTTP:SIGS action close
ns(policy:2)-> set attack MEDIUM:HTTP:ANOM action close
ns(policy:2)-> set attack MEDIUM:HTTP:SIGS action close
ns(policy:2)-> set attack CRITICAL:FTP:SIGS action close
ns(policy:2)-> exit
set policy id 3 from trust to untrust any any http permit attack
CRITICAL:HTTP:ANOM action close-client
set policy id 3
ns(policy:3)-> set service ftp-get
ns(policy:3)-> set attack CRITICAL:HTTP:SIGS action close-client
ns(policy:3)-> set attack HIGH:HTTP:ANOM action close-client
ns(policy:3)-> set attack HIGH:HTTP:SIGS action close-client
ns(policy:3)-> set attack MEDIUM:HTTP:ANOM action close-client
ns(policy:3)-> set attack MEDIUM:HTTP:SIGS action close-client
ns(policy:3)-> set attack CRITICAL:FTP:SIGS action close-client
ns(policy:3)-> exit
save
Acciones de ataques de fuerza bruta

Un ataque de fuerza bruta se lleva a cabo al enviar cantidades grandes de tráfico
con IP o puertos de origen variable en un intento por obtener acceso a la red. Para
evitar de forma efectiva intentos futuros, ScreenOS le permite asociar una acción IP
con cada grupo de ataque en una directiva.
El ataque de fuerza bruta se detecta basándose en los valores del umbral

establecidos para los protocolos admitidos por DI. Por ejemplo:
set di service protocol_name value

Aparte de una acción DI, las acciones de ataque de fuerza bruta se configuran por
medio del comando IP action por 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:
Notificar: 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.
Bloquear: 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.
Cerrar: 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 TCP a las direcciones de destino y de
origen.
Objetos de ataques de fuerza bruta

En la Tabla 10 se enumeran los objetos de ataque de fuerza bruta de ScreenOS 5.3 y
los parámetros del umbral que se pueden utilizar con las acciones IP.
Tabla 10: Objetos de ataques de fuerza bruta
Nombre de los ataques de fuerza bruta Parámetro

Intento de inicio de sesión de fuerza bruta HTTP failed_logins
Intento de búsqueda bruta HTTP brute_search
Intento de inicio de sesión de fuerza bruta IMAP failed_logins
Intento de inicio de sesión de fuerza bruta LDAP failed_logins
Inundación de petición MS-RPC IsSystemActive No se puede configurar—32 intentos
Intento de sesión de fuerza bruta MS-SQL No se puede configurar—4 intentos
Intento de inicio de sesión de fuerza bruta POP3 failed_login
Intento de autenticación de fuerza bruta failed_auth
RADIUS
Crear/borrar directorios de fuerza bruta SMB No se puede configurar—200 intentos
Intento de inicio de sesión de fuerza bruta SMB failed_login
Intento de inicio de sesión de fuerza bruta FTP failed_login
Intento de inicio de sesión de fuerza bruta failed_login
Telnet
Intento de inicio de sesión de fuerza bruta VNC failed_login
Objetivos 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 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 Tabla 11.
Tabla 11: 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 desde 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ámetro 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 DI existente
para cada grupo en una directiva. Los siguientes comandos CLI bloquean el objeto
de ataques de fuerza bruta (intentos de inicio de sesión de fuerza bruta HTTP o
búsquedas de fuerza bruta HTTP durante 45 segundos). Todos los otros ataques en
el grupo de ataque HIGH:HTTP:ANOM se configuran con la acción DI de close.
CLI
ns> get attack group HIGH:HTTP:ANOM
GROUP "HIGH:HTTP:ANOM" is pre-defined. It has the following members
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
ns> set policy id 1 from Untrust to DMZ Any Any Any permit attack
MEDIUM:HTTP:ANOM action none
ns> set policy id 1
ns(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 del protocolo de ataque de

fuerza bruta, no se aplica la acción IP.

Ejemplo 2
En este ejemplo, se asocia una acción IP para cada uno de los grupos de ataque por
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 atacante ejecuta ocho intentos de inicio de
sesión FTP en un minuto.
Si se configura una acción IP para “bloquear” el destino de “serv” con un valor de

120, 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 IP pueden afectar a la comparación del

tráfico con otra directiva.
Registrar 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.
De forma predeterminada, el registro está habilitado. Quizás le interese inhabilitar

el registro de ataques que son de prioridad inferior para usted y a los cuales no
presta mucha atención. Al inhabilitar el registro para dichos ataques, se ayuda a
evitar que el registro de eventos se desordene con entradas que no planea ver en
ningún caso.
Ejemplo: Inhabilitació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
140 Registrar ataques

La directiva se aplica al tráfico 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
en OK:
Address Name: mail1

Zone: DMZ
2. Directiva
Directivas > (From: Trust, To: DMZ) New: Introduzca los siguientes datos y
haga 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
Registrar ataques 141

2. Directiva
ns-> set policy id 1 from trust to dmz any mail1 imap permit attack
HIGH:IMAP:ANOM action close
ns(policy:1)-> set attack HIGH:IMAP:SIGS action close
ns(policy:1)-> set attack MEDIUM:IMAP:ANOM action close
ns(policy:1)-> unset attack MEDIUM:IMAP:ANOM logging
ns(policy:1)-> set attack LOW:IMAP:ANOM action close
ns(policy:1)-> unset attack LOW:IMAP:ANOM logging
ns(policy:1)-> set attack INFO:IMAP:ANOM action close
ns(policy:1)-> unset attack INFO:IMAP:ANOM logging
ns(policy:1)-> exit
ns-> save
Asignar servicios personalizados a aplicaciones

Cuando utilice un servicio personalizado en una directiva con un componente Deep
Inspection (DI), deberá especificar explícitamente qué aplicación se está ejecutando
sobre ese servicio para que el módulo DI pueda funcionar correctamente. Por
ejemplo, si crea un servicio personalizado para FTP para que se ejecute en un
número de puerto no estándar como 2121 (consulte la Figura 54), puede hacer
referencia a ese servicio personalizado en una directiva de la siguiente forma:
set service ftp-custom protocol tcp src-port 0-65535 dst-port 2121-2121

set policy id 1 from untrust to trust any ftp-srv1 custom-ftp permit
Sin embargo, si incluye un componente de DI en una directiva que haga referencia

al servicio personalizado, el módulo de DI no podrá reconocer la aplicación porque
estará utilizando un número de puerto no estándar.
set policy id 1 from untrust to trust any ftp-srv1 custom-ftp permit attack
CRITICAL:FTP:SIGS action close-server
Figura 54: 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á siendo utilizado.
Para evitar este problema, debe informar al módulo DI de que la aplicación FTP se
está ejecutando en el puerto 2121 (consulte la Figura 55). Esencialmente, debe
asignar el protocolo de la capa de aplicación en un número de puerto específico en
la capa de transporte. Esta asociación se puede realizar a nivel de directivas:
set policy id 1 application ftp
142 Asignar 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 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 55: Asignación del servicio personalizado en el 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 HTTP1 desde cualquier dirección de la
zona Untrust a un servidor web llamado “server1” en la zona DMZ. Posteriormente
se aplica Deep Inspection (DI) en el tráfico HTTP permitido que se ejecuta en el
puerto 8080. A continuación se muestran los ajustes 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
clic en OK:
Service Name: HTTP1

Source Port Low: 0
Asignar servicios personalizados a aplicaciones 143

2. Dirección
en OK:
Address Name: server1

IP/Netmask: 1.2.2.5/32
Zone: DMZ
3. Directiva
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), server1
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 server1 1.2.2.5/32
144 Asignar servicios personalizados a aplicaciones

3. Directiva
ns-> set policy id 1 from untrust to dmz any server1 HTTP1 permit attack
CRITICAL:HTTP:ANOM action close-server
ns(policy:1)-> set attack HIGH:HTTP:ANOM action close-server
ns(policy:1)-> set attack MEDIUM:HTTP:ANOM action close-server
ns(policy:1)-> set attack MEDIUM:HTTP:SIGS action close-server
ns(policy:1)-> exit
ns-> set policy id 1 application http
save
Ejemplo: Asignación de aplicaciones a servicios para ataques

HTTP
Algunos ataques HTTP conocidos utilizan el puerto 8000 de TCP. En el momento de
escribir este manual, 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 (in the attack object group

MEDIUM:HTTP:SIGS)
3638, App: HP Web JetAdmin WriteToFile Vulnerability,
DOS:NETDEV:WEBJET-WRITETOFILE (in the attack object group

CRITICAL:HTTP:SIGS)
Sin embargo, de forma predeterminada, ScreenOS considera únicamente el tráfico

TCP en el puerto 80 como HTTP. Por lo tanto, si el dispositivo de seguridad recibe
tráfico TCP utilizando el puerto 8000, éste no lo reconoce como HTTP. Por lo tanto,
el motor DI no analiza tal tráfico HTTP en búsqueda de estos ataques y no puede
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 el motor DI para analizar dicho tráfico, se debe asociar el
número de puerto no estándar al servicio.
WebUI
clic en OK:
Service Name: HTTP2

Source Port Low: 0
Asignar servicios personalizados a aplicaciones 145


2. Directiva
Directivas > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y
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
ns-> set policy id 1 from untrust to dmz any any HTTP2 permit attack
CRITICAL:HTTP:SIGS action close
ns(policy:1)-> set attack MEDIUM:HTTP:SIGS action close
ns(policy:1)-> exit
ns-> 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 atender 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 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 definidos por el usuario

Se puede crear un objeto de ataque de firma completa para FTP, HTTP y SMTP. Para
crear un objeto de ataque, realice los pasos siguientes:
Asigne un nombre el objeto de ataque. (Todos los objetos de ataque definidos

por el usuario deben comenzar con “CS:”).
146 Objetos de ataque y grupos personalizados

Establezca el contexto para la búsqueda DI. (Para obtener una lista completa de
todos los contextos que puede utilizar cuando se crean objetos de ataque,
consulte “Contextos para las firmas definidas por el usuario” en la página I)
Defina la firma. (En la sección “Expresiones regulares” en la página 147 se

examinan las expresiones regulares que puede utilizar para definir firmas).
Asigne un nivel de gravedad al objeto de ataque. (Para obtener información

sobre niveles de gravedad, consulte “Cambiar los niveles de gravedad” en la
página 126.)
A continuación deberá colocar un objeto de ataque definido por el usuario en un

grupo de objetos de ataque definido por el usuario para su utilización en directivas.
NOTA: Un grupo de objetos de ataque definido por el usuario sólo puede contener objetos
de ataque definidos por el usuario. En el mismo grupo de objetos de ataque no se
pueden mezclar objetos de ataque predefinidos y objetos definidos por 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
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 12.
Tabla 12: Expresiones regulares admitidas por ScreenOS
Finalidad Caracteres Meta Ejemplo Significado

Coincidencia binaria directa \O octal_number \0162 Coincidir exactamente con
(octal)1 Coincide con: este número octal: 162
162
Coincidencia binaria directa \X hexadecimal_number\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 \[characters\] \[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 147

Finalidad Caracteres Meta 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 seguida. bc
una o más ocurrencias de b y
seguidas por una ocurrencia
bbc de c.
abc
aaabbbbc
Buscar una o más ocurrencias + a+b+c Buscar una o más ocurrencias

del carácter anterior. Coincide con: de a, seguidas por una o más
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. Se suele usar con ( ) Coincide con:
drop
packet
Rango de caracteres [start-end] [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 [^character] [^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 0-7.
2.Hexadecimal es un sistema numérico en base 16 que utiliza los dígitos 0–9 habituales más las letras A–F, que representan
dígitos hexadecimales equivalentes a los valores decimales 10–15.
Ejemplo: Objetos de ataque de firma completa definidos por el

usuario
En este ejemplo, tendrá un servidor FTP, un servidor web y un servidor de correo
en la zona DMZ. Se definirán los siguientes objetos de ataque para los objetos de
firmas definidas por el usuario, como se muestra en la Tabla 13.

Tabla 13: Objetos de ataque de firma completa definidos por el usuario
Object name Uso

cs:ftp-stor Impedir que alguien pueda colocar archivos en un servidor FTP
cs:ftp-user-dm Denegar el acceso FTP al usuario con el nombre de inicio de sesión
dmartin
cs:url-index Bloquear los paquetes HTTP con una URL definida en cualquier petición
HTTP
cs:spammer Bloquear el correo electrónico procedente de cualquier cuenta del
dominio “spam.com”
A continuación los organizará en un grupo de objetos de ataque definido por el

usuario llamado “DMZ DI”, al que hará referencia en una directiva que permita el
tráfico de la zona Untrust a los servidores en la zona DMZ.
WebUI
1. Objeto de ataque 1: ftp-stor
Objects > Attacks > Custom > New: Introduzca los siguientes datos y haga
clic en OK:
Attack Name: cs:ftp-stor

Attack Context: FTP Command
Attack Severity: Medium
Attack Pattern: STOR
2. Objeto de ataque 2: ftp-user-dm
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
ns(policy:1)-> set service ftp
ns(policy:1)-> exit
save
Objetos de ataque de la firma de las secuencias 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
las secuencias TCP buscan patrones en cualquier lugar y en cualquier tipo de tráfico
TCP sin importar el protocolo de aplicación utilizado.
NOTA: Las firmas de secuencias TCP sólo se pueden definir en sistemas de la serie
NetScreen-5000.
Dado que no hay objetos de ataque de firma de las secuencias 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 56: Ejemplo de un objeto de ataque de firma de secuencia TCP
set attack "CS:A1" stream ".*satori.*" severity critical
Nombre Tipo Definición Nivel de gravedad
Ejemplo: Objeto de ataque de firma de secuencia definido por el

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

Se pueden modificar ciertos parámetros de un objeto de ataques de anomalías de
protocolos. A pesar de que Juniper define los objetos de ataque de anomalías de
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: Para obtener una lista completa de todos los parámetros configurables, consulte el
comando DI en ScreenOS CLI Reference Guide IPv4 Command Descriptions.
Ejemplo: Modificar 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.
Parámetro del protocolo Predet. 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 tiempo de vida 8 saltos 10 saltos
(TTL)
Para los siguientes parámetros, usted establece valores inferiores para detectar
comportamientos anómalos que el dispositivo de seguridad pasó por alto con los
ajustes predeterminados:

Parámetro del protocolo Predet. 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 comunicación en tiempo
real, el protocolo que utilizan los clientes AIM.
AOL Instant Messenger—Máxima longitud de una trama 10.000 bytes 5.000 bytes
FLAP (encabezado FLAP, que siempre son de 6 bytes más los
datos).
OSCAR utiliza el protocolo FLAP para establecer conexiones
y abrir los canales entre los clientes AIM.
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 hacer coincidir 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 57), se definen dos objetos de ataque: uno
especificando el nombre de 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 ataques, para que así el dispositivo de seguridad
bloquee todos los intentos de inicio de sesión a dicho servidor que utilicen cualquier
otro nombre de usuario o contraseña que no sea la que se define en los objetos de
ataque.
En el ejemplo se utilizan los siguientes ajustes:
El nombre de usuario y contraseña correcta son admin1 y pass1.
154 Negación
El servidor FTP se encuentra en 1.2.2.5 de la zona DMZ. Su nombre de

dirección es ftp1.
Se aplica la DI en el tráfico 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 nº 1:
Name: CS:FTP1_USR_OK
Negation: habilitada
Context: ftp-username
Pattern: admin1
Severity: alta
Objeto de ataque nº 2:
Name: CS:FTP1_PASS_OK
Negation: habilitada
Context: ftp-password
Pattern: pass1
Severity: alta
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 FTP desde las zonas Trust y Untrust hacia ftp1 en
la zona DMZ.
Negación 155
Figura 57: Negación de objeto de ataque
Nota: Por simplicidad, el enrutador externo en la

zona Untrust no se muestra. Su dirección es
Untrust 1.1.1.250.
Intento de inicio de
Intento de inicio de Internet
sesión:
sesión: Usuario: admin1
Contraseña: 123456 Contraseña: pass1
Nombre de usuario:
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
haga clic en Apply:
Zone Name: Trust

haga clic en OK:
Zone Name: DMZ

haga clic en OK:
Zone Name: Untrust

156 Negación
2. Dirección
en OK:
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”.
Negación 157
6. Ruta

7. Directivas
Directivas > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Service: FTP
Action: Permit
Group: CS:FTP1_LOGIN
Action: Drop
Log: (seleccione)
Directivas > (From: Trust, To: DMZ) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Service: FTP
Action: Permit
Group: CS:FTP1_LOGIN
Action: Descartar
Log: (seleccione)
158 Negación
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
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 asociada a esa zona. Comprueba si el tipo de contenido detallado en el
encabezado indica que cualquiera de los componentes de destino se encuentra en
la carga del paquete. Si el tipo de contenido es Java, .exe, o .zip y el dispositivo de
seguridad está configurado para bloquear esos tipos de componentes HTTP, el
dispositivo bloquea el paquete. Si el tipo de contenido sólo detalla que es una
secuencia de octetos (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).
Bloqueo granular de los componentes de HTTP 159

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 a los diseñadores Web una
herramienta para crear páginas web dinámicas e interactivas. Los controles ActiveX
son componentes que permiten a diversos programas interactuar entre sí. Por
ejemplo, ActiveX permite a su explorador abrir una hoja de cálculo o mostrar su
cuenta personal desde una base de datos. 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.
Si descarga un control ActiveX a su equipo, a continuación podrá hacer con él lo

que su creador haya previsto. Si es código malévolo, podrá volver a formatear su
disco duro, eliminar todos sus archivos, enviar todo su correo electrónico personal a
su jefe, etcétera.
Applets de Java
Con una finalidad 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 atacante puede programar los applets de Java para
funcionar fuera de la VM, plantean la misma amenaza a la seguridad que los
controles de ActiveX.
Archivos EXE
En los archivos ejecutables (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.
160 Bloqueo granular de los componentes de HTTP

Archivos ZIP
Un archivo ZIP (es decir, un archivo con la extensión .zip), es un tipo de archivo que
contiene unos o más archivos comprimidos. El peligro de descargar un archivo
“.exe” como el presentado en la sección anterior que trata sobre archivos “.exe”
también puede aplicarse a los archivos “.zip”, ya que éstos pueden contener
archivos “.exe”.
Ejemplo: Bloquear applets de Java y archivos “.exe”

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

162 Bloqueo granular de los componentes de HTTP

Capítulo 6
Atributos de los paquetes sospechosos
Según lo mostrado en los demás capítulos de este volumen, un atacante puede

manipular los paquetes para que realicen tareas de reconocimiento o ataques de
denegación de servicio (“Denial of Service” o “DoS”). A veces resulta difícil
determinar la intención de un paquete manipulado, pero el mismo hecho de que
esté manipulado induce a sospechar que incluye algún fin insidioso. Todas las
opciones SCREEN presentadas en este capítulo bloquean los paquetes sospechosos
que pueden contener amenazas ocultas:
“Fragmentos ICMP” en la página 164
“Paquetes ICMP grandes” en la página 165
“Opciones IP incorrectas” en la página 166
“Protocolos desconocidos” en la página 167
“Fragmentos de paquetes IP” en la página 168
“Fragmentos SYN” en la página 169
163
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 ICMP Fragment Protection SCREEN, el
dispositivo de seguridad bloquea cualquier paquete ICMP que tenga el flag de más
fragmentos (“More Fragments”) activado o que contenga algún valor en el campo
de desplazamiento (“offset”).
Figura 58: Bloquear fragmentos de ICMP
Si el tipo de protocolo y el flag de More o hay un valor distinto de cero en el

es 1 para ICMP... Fragments está activado... campo de Fragment Offset...
Encabezado IP Longitud de Tamaño total del paquete (en bytes)

Versión Tipo de servicio
encabezado
Identificación 0 D M Fragment Offset
Tiempo de vida (TTL) Protocolo (ICMP = 1) Suma de comprobación del encabezado
Opciones
Encabezado Tipo Código Suma de comprobación

ICMP
(Carga de Identificador Número de secuencia
datos
del paquete IP)
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 zone screen icmp-fragment
164 Fragmentos ICMP

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

Como se establece en “Fragmentos ICMP” en la página 164, 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, hay algún problema. Por ejemplo, el programa Loki utiliza
ICMP como canal para transmitir mensajes secretos. La presencia de paquetes
ICMP grandes podría dejar al descubierto a un equipo que esté actuando como
agente de Loki. También podría indicar algún otro tipo de actividad cuestionable.
Figura 59: Bloqueo de paquetes ICMP grandes
Cuando el tipo de protocolo es 1 para ICMP… y este valor es >1024…
Encabezado IP Longitud de
Versión Tipo de servicio Tamaño total del paquete (en bytes)
encabezado
Identificación 0 D M Desplazamiento del fragmento
Tiempo de vida (TTL) Protocolo (ICMP = 1) Suma de comprobación del encabezado
Opciones
Encabezado Tipo Código Suma de comprobación

ICMP
(Carga de datos Identificador Número de secuencia
del paquete IP)
Datos
Cuando se habilita la opción Large Size ICMP Packet Protection SCREEN, 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 zone screen icmp-large
Paquetes ICMP grandes 165

Opciones IP incorrectas
La norma de protocolo de Internet RFC 791, Internet Protocol, especifica una serie
de opciones que ofrecen controles de enrutamiento, herramientas de diagnóstico y
medidas de seguridad especiales. Aunque la finalidad original prevista para estas
opciones era legítima, algunas personas han hallado la forma de explotarlas para
lograr objetivos menos loables. (Para ver un resumen de las vulnerabilidades de las
opciones IP que los atacantes pueden explotar, consulte “Reconocimiento de red
mediante opciones IP” en la página 9).
Ya sea intencional o accidentalmente, en ocasiones los atacantes configuran las

opciones IP de manera incorrecta, generando campos incompletos o mal formados.
Con independencia 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.
Figura 60: Opciones IP formateadas incorrectamente
Tamaño de
Encabezado IP Versión Tipo de servicio Tamaño total del paquete (en bytes)
encabezado
Tiempo de vida (TTL) Protocolo Suma de comprobación del 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 se habilita la opción Bad IP Option Protection SCREEN, 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 zone screen ip-bad-option
166 Opciones IP incorrectas

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

el dispositivo de seguridad bloquea el paquete.
Encabezado IP Versión Tamaño de Tipo de servicio Tamaño 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 se habilita la opción Unknown Protocol Protection SCREEN, 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 zone screen unknown-protocol
Protocolos desconocidos 167

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 atacante puede intentar explotar las vulnerabilidades existentes en el código
de reensamblaje de paquetes de determinadas implementaciones de pilas IP (“IP
stacks”). Cuando la víctima recibe estos paquetes, los resultados pueden variar
desde un procesamiento incorrecto de los paquetes hasta la caída total del sistema.
Figura 62: Fragmentos de paquetes IP
Si el flag de More Fragments o hay un valor distinto de cero en el campo

está activado... de Fragment Offset...
Tamaño de
Encabezado IP Versión Tipo de servicio Tamaño total del paquete (en bytes)
encabezado
Opciones
Carga de datos
Cuando se habilita el dispositivo de seguridad para rechazar fragmentos IP en una

zona de seguridad, el dispositivo bloquea todos los fragmentos de paquetes IP que
reciba en las interfaces asociadas a esa zona.
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 zone screen block-frag
168 Fragmentos de paquetes IP

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 se 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 flag 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.
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 ICMP
Fragment Protection, luego haga clic en Apply.
CLI
set zone zone screen syn-frag
Fragmentos SYN 169

Figura 63: Fragmentos SYN
Si el flag de More Fragments está o hay un valor distinto de cero en el campo

activado... de Fragment Offset...
Encabezado IP Versión Tamaño del Tipo de servicio Tamaño total del paquete (en bytes)
encabezado
Encabezado ICMP Número de puerto de origen de 16 bits Número de puerto de destino de 16 bits

encabezado 4 bits (6 bits) R C S S Y I Tamaño de ventana de 16 bits
G K H T N N
Datos (si los hay)
…y el flag SYN está activado… ...el dispositivo descarta el paquete.
170 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 completa, puede especificar cualquiera
de los contextos en las siguientes listas. Después de definir un objeto de ataque,
deberá colocar un objeto de ataque definido por el usuario en un grupo de objetos
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 objetos definidos por 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 TCP buscan
patrones en cualquier lugar y en cualquier tipo de tráfico TCP sin importar el
protocolo de aplicación utilizado. Las firmas de secuencias solo se pueden definir
en sistemas de serie NetScreen-5000 y 2000. Sin embargo, Stream256 busca
patrones en los primeros 256 bytes de datos.
Tabla 14: 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 un chat room en una sesión de America Online Instant Messenger
(AIM) o ICQ (I Seek You).
aim-chat-room-name El nombre de un chat room en una sesión AIM o ICQ.
aim-get-file El nombre de un archivo que un usuario transfiere de un homólogo.
aim-nick-name El apodo de un usuario de AIM o ICQ.
aim-put-file El nombre de un archivo que un usuario transfiere a un homólogo.
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
de dominio (DNS), según se define en RFC 1035, Domain Names, Implementation and
Specification).
FTP ftp-command Uno de los comandos de FTP especificado en RFC 959, File Transfer Protocol (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.
ftp-username El nombre que un usuario introduce cuando inicia una sesión en un servidor de FTP.
A-I

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 contraseña decodificado de una autorización: encabezado
básico en una petición de potocolo de transferencia de hipertexto (HTTP), según se
especifica en RFC 1945, HyperText Transfer Protocol, HTTP/1.0.
http-header-user-agent El campo de usuario-agente 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” decodificada 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 de AUTENTICACIÓN del protocolo de acceso de
correo de Internet (IMAP9. 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, Generic Security Service Application
Program Interface) y SKEY.
Para obtener información sobre IMAP, consulte RFC 1730, Internet Message
Protocol — Version 4 y RFC 1731, IMAP4 Authentication Mechanisms.
imap-login Ya sea el nombre de usuario o la contraseña de 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 Instant Messaging de
Messenger Microsoft Network (MSN).
msn-get-file El nombre de un archivo que un cliente descarga de un homólogo.
msn-put-file El nombre de un archivo que un cliente envía a un homólogo.
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 RFC 1939, Post Office Protocol
— Version 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
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
content-filename multiuso para correo de Internet (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 un 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,
Simple Mail Transfer Protocol.
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
content-filename multiuso para correo de Internet (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 un chat en los mensajes instantáneos de
message Yahoo!
ymsg-chatroom- El nombre de un chat de mensajes instantáneos de Yahoo!
name
ymsg-nickname El sobrenombre de un usuario de mensajes instantáneos de Yahoo!
ymsg-p2p-get- La ubicación de un archivo en una máquina del interlocutor de mensajes
filename-url instantáneos de Yahoo! desde el cual se pueden descargar archivos.
ymsg-p2p-put- La ubicación de un archivo en una máquina del interlocutor de mensajes
filename-url instantáneos de Yahoo! al cual se pueden cargar archivos.
A-III
A-IV
Índice
A ICMP
acciones de ataque ..............................................126–133 fragmentos ........................................................160
close ........................................................................126 inundaciones ......................................................48
close client .............................................................126 inundaciones de la tabla de sesiones ..............17, 29
close server ............................................................126 Inundaciones SYN .............................................36–41
drop ........................................................................126 Inundaciones UDP ...................................................49
drop packet ............................................................126 objetivos comunes ....................................................1
ignore......................................................................127 opciones de detección y defensa ........................2–4
none ........................................................................127 paquetes ICMP grandes ........................................161
agente zombie .........................................................28, 30 Ping of Death ...........................................................51
AIM ................................................................................118 protocolos desconocidos ......................................163
ALG ..................................................................................57 Teardrop ...................................................................52
análisis antivirus ......................................................59–75 Terrestres .................................................................50
correo web de HTTP ...............................................63 WinNuke ...................................................................53
descompresión ........................................................78 Ataques DoS .............................................................28–54
extensiones de archivo ...........................................78 Ataques Teardrop ...........................................................52
FTP ............................................................................60 Ataques terrestres (land attacks) ..................................50
goteo HTTP ..............................................................74 Ataques WinNuke ..........................................................53
HTTP .........................................................................61
HTTP “keep-alive” ...................................................73 B
IMAP .........................................................................64 barrido de direcciones ....................................................7
MIME.........................................................................62 base de datos de objetos de ataque...................106–114
modo de fallo ...........................................................72 actualización automática ..............................108, 110
POP3 .........................................................................64 actualización inmediata ................................107, 109
recursos de AV por cliente .....................................72 actualización manual ....................................108, 112
SMTP .........................................................................65 cambiar la URL predeterminada .........................113
suscripción ...............................................................67 notificación automática y actualización
análisis de puertos ...........................................................8 manual .........................................................108, 111
análisis FIN .....................................................................14 Bloque de mensajes del servidor
anomalías del protocolo..............................................121 véase SMB
ALG .........................................................................119
Aplicaciones de mensajería inmediata ...............118 C
Aplicaciones P2P ...................................................118 Chargen .........................................................................116
configurar parámetros ..........................................149 claves de licencia
protocolos admitidos ....................................116–119 actualización del patrón de ataques ....................104
protocolos básicos de red.....................................116 modo avanzado .....................................................104
applets Java, bloquear .................................................156 colas LPR ......................................................................117
archivos exe, bloquear ................................................156 completas
archivos zip, bloquear .................................................157 firmas ......................................................................120
ataques comprobación de SYN ......................................15, 15–18
direcciones MAC desconocidas .............................41 agujero de reconocimiento ....................................17
DOS .....................................................................28–54 enrutamiento asimétrico ........................................16
etapas .........................................................................2 interrupción de sesión ............................................16
Fragmentos de paquetes IP .................................164 inundaciones de la tabla de sesiones ....................17
Fragmentos SYN....................................................165 controles ActiveX, bloqueo .........................................156
Cookies SYN ...................................................................46
Índice IX-I
D filtrado de Web
DDoS ............................................................................... 28 aplicación en el nivel de directivas .......................98
Deep Inspection (DI) ........................................... 123–147 aplicar perfiles a directivas ....................................90
acciones de ataque ....................................... 126–133 caché.........................................................................92
anomalías del protocolo ....................................... 121 categorías de URL ...................................................86
base de datos de objetos de ataque ............ 106–114 enrutamiento ...........................................................99
cambiar gravedad ................................................. 122 estado del servidor ..................................................98
claves de licencia .................................................. 104 integrado ..................................................................84
contexto ...................................................................... I introducir un contexto ............................................86
desactivar objetos de ataque ............................... 125 mensaje de URL bloqueada ...................................97
expresiones regulares ................................... 143–144 nombre del servidor SurfControl ..........................96
firmas completas .................................................. 120 nombre del servidor Websense ............................96
firmas de secuencias ............................................ 121 perfiles ......................................................................88
firmas personalizadas................................... 143–147 puerto del servidor SurfControl .............................96
grupos de objetos de ataque ................................ 122 puerto del servidor Websense ...............................96
negación de objetos de ataque ............................ 150 redirigir .....................................................................93
objetos de ataque .................................................. 103 servidores CPA de SurfControl ..............................84
objetos de ataque personalizados ....................... 142 servidores de SurfControl.......................................92
paquetes de firmas ............................................... 106 servidores por vsys .................................................95
registrar grupos de objetos de ataque ................ 136 SurfControl SCFP .....................................................96
servicios personalizados .............................. 138–142 tiempo de espera de comunicaciones ..................97
vista general .......................................................... 102 tipo de mensaje de URL bloqueada ......................97
volver a habilitar objetos de ataque .................... 125 filtrado de web .......................................................93–100
Denegación de servicio FIN sin flag ACK .............................................................12
véase DoS Finger ............................................................................116
descompresión, análisis antivirus ............................... 78 firmas
DHCP ............................................................................ 116 completas ...............................................................120
directivas firmas de secuencias ...................................................121
contexto ................................................................. 106 flags SYN y FIN activados .............................................11
filtrado de Web........................................................ 98 Fragmentos SYN ..........................................................165
sección central ................................................ 17, 104 fuerza bruta
Discard .......................................................................... 116 acciones de ataque................................................133
DNS ............................................................................... 116
DoS G
ataque específico del sistema operativo ........ 51–54 Gopher ..........................................................................116
cortafuegos ........................................................ 29–35 grupos de objetos de ataque ......................................122
inundaciones de la tabla de sesiones ............. 17, 29 cambiar gravedad .................................................122
red ....................................................................... 36–51 niveles de gravedad ..............................................122
drop-no-rpf-route ........................................................... 19 que se aplican en directivas .................................115
registro ...................................................................136
E URL de ayuda ........................................................119
Echo .............................................................................. 116
envejecimiento agresivo ......................................... 32–34 H
establecimientos de comunicación en tres fases....... 36 HTTP
estado ............................................................................... 3 “keep-alive”..............................................................73
inspección .................................................................. 3 bloqueo de componentes .............................155–157
evasión ...................................................................... 14–26 goteo .........................................................................74
explotación de vulnerabilidad tiempo de espera de la sesión ...............................33
véase ataques
expresiones regulares ......................................... 143–144 I
extensiones de archivo, análisis de AV ....................... 78 ICMP ..............................................................................116
fragmentos .............................................................160
F paquetes grandes ..................................................161
filtrado de contenidos ........................................... 55–100 IDENT............................................................................117
filtrado de paquetes dinámico ....................................... 3 inspecciones .....................................................................3
IX-II Índice
Índice
inundaciones O
ICMP .........................................................................48 objetos AV
SYN ...............................................................36–41, 46 tiempo de espera.....................................................77
tabla de sesiones .....................................................29 objetos de ataque .........................................103, 114–121
UDP ...........................................................................49 anomalías del protocolo ...............................121, 149
inundaciones de la tabla de sesiones ....................17, 29 desactivar ...............................................................125
inundaciones del proxy SYN-ACK-ACK .......................34 firmas completas ...................................................120
Inundaciones ICMP .......................................................48 firmas de secuencias .............................................121
Inundaciones SYN ...................................................36–41 firmas de secuencias TCP.....................................147
ataques .....................................................................36 fuerza bruta ....................................................133, 134
Cookies SYN.............................................................46 negación .................................................................150
descartar las direcciones MAC desconocidas ......41 volver a habilitar ....................................................125
tamaño de la cola ....................................................41 objetos de ataques de fuerza bruta ............................134
tiempo de espera ....................................................41 opción de marca de tiempo de IP ...............................10
umbral ......................................................................37 opción de seguridad IP .............................................9, 11
umbral de alarma ....................................................39 opción IP de grabación de ruta ....................................10
umbral de ataque ....................................................39 opción IP de ID de secuencia .................................10, 11
umbral de destino ...................................................40 opción IP de ruta de origen abierta .................10, 24–26
umbral de origen .....................................................40 opción IP de ruta de origen estricta ................10, 24–26
IP opciones IP .................................................................9–11
fragmentos de paquetes .......................................164 atributos ...............................................................9–10
IRC .................................................................................118 formateadas incorrectamente .............................162
grabación de ruta ....................................................10
L ID de secuencia .................................................10, 11
LDAP .............................................................................117 marca de hora .........................................................10
límites de sesiones ..................................................29–32 ruta de origen ..........................................................24
basadas en su destino.......................................30, 31 ruta de origen abierta .................................10, 24–26
basadas en su origen ........................................29, 31 ruta de origen estricta .................................10, 24–26
seguridad ..............................................................9, 11
M
Mensajería inmediata ..................................................118 P
AIM..........................................................................118 P2P ................................................................................118
IRC ..........................................................................118 BitTorrent ...............................................................118
MSN Messenger .....................................................118 DC ...........................................................................118
Yahoo! Messenger .................................................118 eDonkey .................................................................118
Mensajería inmediata de America Online FastTrack ................................................................118
véase AIM Gnutella...................................................................118
Microsoft Network Instant Messenger KaZaa ......................................................................118
véase MSN Instant Messenger MLdonkey...............................................................118
Microsoft-Remote Procedure Call Skype ......................................................................119
véase MS-RPC SMB .........................................................................119
MIME, análisis antivirus ................................................62 WinMX ....................................................................119
modo de fallo .................................................................72 paquetes de firmas, DI ................................................106
modo transparente Ping of Death .................................................................51
descartar las direcciones MAC desconocidas ......41 Portmapper...................................................................117
MS RPC .........................................................................119 protección contra URL maliciosas .........................56–59
MSN Messenger ...........................................................118 protección frente a ataques
nivel de directivas .....................................................4
N nivel de zona de seguridad ......................................4
negación, Deep Inspection (DI) .................................150 protocolos desconocidos .............................................163
NetBIOS ........................................................................119 Puerta de enlace en la capa de aplicación
NFS ................................................................................117 véase ALG
NNTP .............................................................................117 Punto a punto
NTP................................................................................117 véase P2P
Índice IX-III
R servicios
RADIUS ......................................................................... 117 personalizados .......................................................138
rastreo simulación de IP ......................................................18–24
puertos abiertos ........................................................ 8 drop-no-rpf-route .....................................................19
red ............................................................................... 7 Layer 2................................................................19, 23
sistemas operativos .......................................... 11, 14 Layer 3................................................................18, 20
reconocimiento .......................................................... 6–26 sistemas operativos, sondeos de host para ..........11–14
análisis de puertos .................................................... 8 SMB
análisis FIN .............................................................. 14 NetBIOS ..................................................................119
barrido de direcciones .............................................. 7 SNMPTRAP ...................................................................117
flags SYN y FIN activados ...................................... 11 SSH ................................................................................117
opciones IP ................................................................ 9 SSL .................................................................................117
paquete TCP sin flags ............................................. 13 SurfControl ...............................................................85, 93
reensamblaje de fragmentos .................................. 56–59 SYN, cookies ..................................................................46
registro syslog ............................................................................117
grupos de objetos de ataque ................................ 136
rexec ............................................................................. 117 T
RFC TCP
1038, Revised IP Security Option ..........................9 firmas de secuencias ............................................147
791, Internet Protocol...........................................9 paquete sin flags .....................................................13
793, Transmission Control Protocol.....................13 tiempos de espera de la sesión .............................33
rlogin ............................................................................. 117 Telnet ............................................................................117
rsh ................................................................................. 117 TFTP ..............................................................................117
RTSP .............................................................................. 117 tiempos de espera de la sesión
HTTP .........................................................................33
S TCP............................................................................33
SCREEN UDP ...........................................................................33
análisis de puertos .................................................... 8
Ataques terrestres (land attacks) ........................... 50 U
Ataques WinNuke ................................................... 53 UDP
barrido de direcciones .............................................. 7 tiempos de espera de la sesión .............................33
descartar las direcciones MAC desconocidas ...... 41 umbral inferior ...............................................................32
FIN sin ACK ............................................................. 15 umbral superior .............................................................32
FIN sin flag ACK, descarte ..................................... 12 umbrales
flags SYN y FIN activados ...................................... 11 umbral inferior ........................................................32
fragmentos de paquetes IP, bloquear ................. 164 umbral superior .......................................................32
fragmentos SYN, detectar .................................... 165
ICMP V
fragmentos, bloquear ...................................... 160 VNC ...............................................................................118
inundaciones del proxy SYN-ACK-ACK ................ 34
Inundaciones ICMP ................................................. 48
W
Whois ............................................................................118
Inundaciones SYN ............................................. 36–41
Inundaciones UDP .................................................. 49 Y
opción IP de ruta de origen abierta, detectar ...... 26 Yahoo! Messenger........................................................118
opción IP de ruta de origen estricta, detectar ..... 26
opción IP de ruta de origen, denegar ................... 26 Z
opciones IP ................................................................ 9 zombie, agentes .......................................................28, 30
opciones IP incorrectas, descartar ...................... 162
paquete TCP sin flags, detectar ............................. 13
paquetes ICMP grandes, bloquear ...................... 161
Ping of Death ........................................................... 51
protocolos desconocidos, descartar .................... 163
simulación de IP ................................................ 18–24
Teardrop................................................................... 52
zonas VLAN y MGT ................................................... 3
IX-IV Índice
Volumen 5:

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Copyright Notice
without notice.
FCC Statement
Disclaimer
Writers: Richard Biegel, Kristine Conley, Sharmila Kumar, Jozef Wroblewski

ii
Contenido
Capítulo 1 Seguridad del protocolo de Internet 1

Introducción a las redes privadas virtuales (VPN) ............................................. 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
Administrar 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............................................................... 10
Fase 2...................................................................................................... 11
Confidencialidad directa perfecta ...................................................... 12
Protección antirreprocesamiento ...................................................... 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
Firmar un certificado ............................................................................... 20
Verificar una firma digital ........................................................................ 20
Infraestructura de claves públicas .................................................................. 22
Certificados y CRL.......................................................................................... 24
Petición manual de un certificado ........................................................... 26
Cargar certificados y listas de revocación de certificados......................... 28
Configurar ajustes de CRL........................................................................ 29
Obtención automática de un certificado local .......................................... 30
Contenido iii
Renovación automática de certificado ..................................................... 34

Generar pares de claves........................................................................... 34
Protocolo OCSP..............................................................................................35
Especificar un método de comprobación de revocación de certificados .. 36
Visualizar los atributos de comprobación de estado ................................ 36
Especificar un URL del servidor de respuesta del protocolo OCSP ........... 36
Eliminar atributos de comprobación de estado........................................ 37
Certificados autofirmados .............................................................................. 37
Validar certificados .................................................................................. 38
Crear manualmente certificados autofirmados ........................................ 39
Establecer un certificado autofirmado y definido por el administrador.... 40
Autogenerar certificados.......................................................................... 44
Eliminar certificados autofirmados .......................................................... 45
Capítulo 3 Directivas de red privada virtual 47

Opciones criptográficas.................................................................................. 48
Opciones criptográficas punto a punto ....................................................48
Opciones VPN de acceso telefónico ......................................................... 56
Túneles basados en directivas y en rutas ....................................................... 63
Flujo de paquetes: VPN punto a punto ........................................................... 64
Directrices para la configuración de un túnel ................................................. 70
Consideraciones de seguridad en VPN basadas en rutas ................................ 72
Ruta nula ................................................................................................. 73
Línea de acceso telefónico o arrendada ................................................... 75
Conmutación por error de la VPN hacia la línea arrendada o la
ruta nula ........................................................................................... 75
Interfaz de túnel ficticia ........................................................................... 78
Enrutador virtual para interfaces de túnel................................................ 79
Reencaminar a otro túnel ........................................................................ 79
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, AutoKey IKE............................ 97
VPN punto a punto basada en rutas, interlocutor dinámico ...................103
VPN punto a punto basada en directivas, interlocutor dinámico............111
VPN punto a punto basada en rutas, clave manual ................................120
VPN punto a punto basada en directivas, clave manual.........................126
Puertas de enlace IKE dinámicas con FQDN ................................................131
Alias ......................................................................................................132
Ajuste del interlocutor AutoKey IKE con FQDN......................................132
Puntos VPN con direcciones superpuestas ...................................................141
VPN en modo transparente..........................................................................152
Capítulo 5 Redes privadas virtuales de acceso telefónico 159

Acceso telefónico .........................................................................................160
VPN de acceso telefónico basada en directivas, AutoKey IKE ................160
VPN de acceso telefónico basada en rutas, interlocutor dinámico .........166
VPN de acceso telefónico basada en directivas, interlocutor dinámico ..173
Directivas bidireccionales para usuarios de VPN de acceso telefónico ...178
Identificación IKE de grupo ..........................................................................183
Identificación IKE de grupo con certificados ..........................................183
Tipos de identificación IKE ASN1-DN Wildcard y Container ..................185
iv Contenido
Contenido
Creación de una identificación IKE de grupo (certificados) ....................188

Configuración de una ID IKE de grupo con claves previamente
compartidas ....................................................................................192
Identificación IKE compartida ......................................................................198
Capítulo 6 Protocolo de encapsulamiento de la capa 2 (L2TP) 205

Introducción al L2TP ....................................................................................205
Encapsular y desencapsular paquetes ..........................................................208
Encapsular.............................................................................................208
Desencapsular .......................................................................................209
Ajuste de los parámetros L2TP .....................................................................211
L2TP y L2TP sobre IPSec..............................................................................213
Configurar L2TP ....................................................................................213
Configurar L2TP sobre IPSec .................................................................218
L2TP bidireccional sobre IPSec ..............................................................225
Capítulo 7 Funciones avanzadas de redes privadas virtuales 231

NAT-Traversal ..............................................................................................232
Sondeos de NAT ....................................................................................233
Atravesar un dispositivo NAT.................................................................235
Suma de comprobación de UDP ............................................................237
Paquetes de mantenimiento de conexión..............................................238
Simetría iniciador/respondedor .............................................................238
Habilitación de NAT-Traversal ...............................................................239
Supervisión de VPN......................................................................................240
Opciones de reencriptación y optimización ...........................................241
Interfaz de origen y dirección de destino...............................................242
Consideraciones sobre directivas...........................................................243
Configuración de la función de supervisión de VPN...............................244
Objetos y capturas SNMP para la supervisión de VPN............................252
Múltiples túneles por interfaz de túnel .........................................................254
Asignación de rutas a túneles ................................................................255
Direcciones de interlocutores remotos...................................................256
Entradas de tabla manuales y automáticas ............................................257
Entradas manuales en la tabla ........................................................257
Entradas automáticas en la tabla.....................................................257
superpuestas ............................................................................259
Asociar entradas automáticas en la tabla de rutas y en la
tabla NHTB ...............................................................................278
Uso de OSPF para entradas automáticas en la tabla de rutas ..........289
Puertas de enlace VPN redundantes.............................................................290
Grupos VPN ...........................................................................................291
Mecanismos de supervisión...................................................................292
Latidos de IKE .................................................................................293
Detección de interlocutor muerto (DPD) .........................................293
Procedimiento de recuperación IKE ................................................295
Comprobar flag TCP SYN.......................................................................296
Crear puertas de enlace VPN redundantes ......................................297
Crear VPN adosadas.....................................................................................303
Crear VPN radiales .......................................................................................310
Índice ........................................................................................................................IX-I
Contenido v
vi Contenido
El Volumen 5: Redes privadas virtuales describe los conceptos y de la red privada

virtual (VPN) y las características específicas de la VPN de ScreenOS.
Capítulo 1, “Seguridad del protocolo de Internet,” 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,” 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 (CLR) en el marco de la infraestructura de claves
públicas (PKI).
Capítulo 3, “Directivas de red privada virtual,” explica el encapsulamiento de

VPN.
Capítulo 4, “Redes privadas virtuales de punto a punto,” 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,” explica cómo

configurar una VPN de acceso telefónico.
Capítulo 6, “Protocolo de encapsulamiento de la capa 2 (L2TP),” explica 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,” 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.
vii

“Convenciones para las ilustraciones” en la página ix
“Convenciones de nomenclatura y conjuntos de caracteres” en la página x
“Convenciones de la interfaz gráfica (WebUI)” en la página xi

En ejemplos:


En texto:



10.1.1.0/24)

Internet

dinámicas (DIP)

Equipo portátil
Interfaz de túnel
Servidor
Túnel VPN
Concentrador (hub)
Enrutador
Teléfono IP
Conmutador






excepción de las comillas dobles ( “ ), que tienen un significado especial como


de configuración:

en OK:
Zone: Untrust




xii Documentación de Juniper Networks

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 (VPN)” 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
“Administrar 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 (VPN)

Una red privada virtual (VPN) proporciona un medio de comunicación seguro 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) función sin 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 (VPN)

Capítulo 1: Seguridad del protocolo de Internet
Conceptos de IPSec
Seguridad IP (IPSec) es un conjunto de protocolos relacionados utilizados para
garantizar la seguridad de las comunicaciones en la capa de paquete IP mediante
encriptación. IPSec está compuesto por 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 4: Arquitectura IPSec
Modo de transporte Modo de túnel
Nota: ScreenOS no
admite el modo de
transporte
con AH.
Protocolo AH
Protocolo ESP
Algoritmo de autenticación Algoritmo de

(MD5, SHA-1) encriptación
(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
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 5. 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 5: 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 6.
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 6: Modos de túnel
Paquetes IP
El paquete original está encapsulado.
Modo de túnel, AH Nuevo Encabezado Encabezado
encabezado AH original Carga de datos
Autenticado
Modo de túnel, ESP Nuevo Encabezado Encabezado

encabezado ESP original Carga de datos
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 7: 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 8: 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
mediante 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:
Data Encryption Standard (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.
Advanced Encryption Standard (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.
Administrar 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 SAs; 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 de una 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 la 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: diná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 10).
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.
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:
10 Negociación de túnel
Grupo DH 1: módulo de 768 bits
NOTA: Las ventajas 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 antirreprocesamiento” en la página 12).
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.
Negociación de túnel 11
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 antirreprocesamiento
Se produce un ataque de reprocesamiento 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 (SAs), que definen los parámetros para asegurar el
tráfico entre ellos. Los administradores de cada extremo pueden definir los SAs
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.
Seguridad aplicada: IPSec protege el tráfico enviado entre los dos puntos
terminales del túnel usando los parámetros de seguridad definidos en los SAs
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 o
Encapsulating Security Payload) y encabezado de autenticación (AH o
Authentication Header).
Para obtener una explicación del procesamiento de paquetes que se produce

durante las etapas IKE y IPSec de un túnel VPN, consulte “Paquetes IKE” en esta
página y “Paquetes IPSec” en la página 16. Dichas secciones muestran los
encabezados de los paquetes para IKE e IPSec, respectivamente.
12 Paquetes IKE e IPSec

Paquetes IKE
Cuando un paquete de texto puro 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. En la carga de datos del paquete IP hay un
segmento UDP que encapsula un paquete ISAKMP (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 9: Paquete IKE para las fases 1 y 2
Encabezado Encabezado Encabezado

IP UDP ISAKMP Carga de datos
Nota: ISAKMP es el formato de paquetes utilizado por IKE.

Encabezado IP
Longitud de
Versión encabezado Tipo de servicio Longitud total del paquete (en bytes)
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)
Tamaño 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 Versión mayor Versión menor Tipo de intercambio Flags
ID del mensaje
Longitud del mensaje
Carga de datos ISAKMP
El campo “Next Payload” 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 Key Exchange (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 determinada 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 10.
Figura 10: Encabezado genérico de la carga de datos ISAKMP
Encabezado siguiente 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 de siguiente encabezado. Un
valor de 0000 indica la última carga de datos ISAKMP. Consulte la Figura 11 en la
página 16 para obtener un ejemplo.

Figura 11: 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
Versión mayor Versión menor Tipo de intercambio Indicadores 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
de la
Carga de datos de la 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 (SAs),
el dispositivo NetScreen aplica la protección IPSec a los paquetes IP de texto puro
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
de encapsulamiento (ESP o Encapsulating Security Protocol) en modo de túnel, el
paquete se parecerá al que se muestra a continuación. 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 12: Paquete IPSec: 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 12, 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 13: Encabezado IP externo (IP2) y encabezado ESP
Encabezado IP externo (IP2)

Longitud de
Versión encabezado Tipo de servicio Longitud total del paquete (en bytes)
Tiempo de vida (TTL) Protocolo (17 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 (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** Encab. siguiente (4 para IP)**
Datos de autenticación (variables)
* = secciones autenticadas del paquete

** = secciones encriptadas del paquete
El campo de siguiente encabezado 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 14: 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
Identificación 0 D M Desplazamiento
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 correlativo
Número de reconocimiento
Encabezado U A P R S F
Tamaño Reservado R C S S S I Tamaño de la ventana
G K H D 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
“Firmar un certificado” en la página 20
“Verificar 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
“Cargar certificados y listas de revocación de certificados” en la página 28
“Configurar ajustes de CRL” en la página 29
“Obtención automática de un certificado local” en la página 30
“Renovación automática de certificado” en la página 34
“Protocolo OCSP” en la página 35
“Generar pares de claves” en la página 34
“Especificar un método de comprobación de revocación de certificados” en

la página 36
“Especificar un URL del servidor de respuesta del protocolo OCSP” en la

página 36
“Certificados autofirmados” en la página 37
“Eliminar atributos de comprobación de estado” en la página 37
“Crear manualmente certificados autofirmados” en la página 39
“Establecer un certificado autofirmado y definido por el administrador” en

la página 40
“Eliminar certificados autofirmados” en la página 45
19
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:
Firmar 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ó.
Verificar 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 15: 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.
2. Con su clave privada, la CA encripta la codificación A. El Algoritmo hash

(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 Codificación Cert.

SHA-1. A
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.
Codificación
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 vez 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 16: Jerarquía de confianza de una PKI—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 17: 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 nº. 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 nº. 7, lo que significa que el

dispositivo de seguridad puede aceptar certificados X.509 y CRL empaquetadas
según la norma PKCS nº. 7. La compatibilidad con PKCS nº. 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 usted 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 por sí 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-63. 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-110.
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 CA 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 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. Rellenar 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 los ajustes predeterminados del servidor para la
URL de la CRL en el dispositivo de seguridad, tal y como se explica en “Configurar
ajustes de CRL” en la página 29.
Cuando reciba estos archivos (los archivos de certificado suelen tener la extensión
.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 el archivo PKCS nº. 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 en 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=Engineering, DC=NewYork".
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 “Crear un clúster NSRP” en la página 11-10).
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: Ciertas 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_dominio }.
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 instrucciones 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).
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_dominio }.
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).
Cargar 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.
Se cargará el archivo local.cer.
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
Configurar 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 determinada no acompaña al certificado de CA correspondiente
y no está cargada en la base de datos de ScreenOS, el dispositivo de seguridad
intentará recuperarla mediante la URL de LDAP o HTTP definida en el propio
certificado. Si no hay ninguna dirección URL definida en el certificado de CA, el
dispositivo de seguridad utiliza la URL del servidor definido para ese certificado de
CA. Si no define ninguna URL de CRL para un certificado de CA determinado, el
dispositivo de seguridad utilizará el servidor CRL de la dirección URL de CRL
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” en la

página 2-221).
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 “Crear un clúster NSRP” en la página 11-10).
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 CGI
de la CA.
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
los siguientes datos y haga clic en OK:
X509 certificate path validation level: Full

SCEP Settings:
RA CGI: http://ipsec.verisigncom/cgi-bin/pkiclient.exe
CA CGI: http://ipsec.verisigncom/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
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 CGI de la CA.
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 de inscripción en certificados 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.
Generar 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 a medida 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 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, u “Online
Certificate Status Protocol”) 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.
NOTA: También hemos evaluado satisfactoriamente con el servidor de respuesta OCSP

Valicert durante un examen exhaustivo en el pasado.
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 id_num1 cert-status ocsp cert-verify id id_num2
id_num1 identifica el certificado de CA que emitió el certificado que se va a

verificar; id_num2 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
Protocolo OCSP 35
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.
Especificar 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 id_num cert-status revocation-check { CRL | OCSP | none }
donde id_num 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.
Visualizar 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 id_num cert-status
donde id_num 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
Especificar un URL del servidor de respuesta del protocolo OCSP

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 id_num cert-status ocsp url url_str
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
36 Protocolo OCSP
Eliminar 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 id_num cert-status
Para eliminar todos los atributos de revocación relativos al certificado 1:
unset pki authority 1 cert-status
Certificados autofirmados
Un certificado autofirmado es un certificado firmado y publicado 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
“Crear manualmente certificados autofirmados” en la página 39).
Aunque no se pueden exportar certificados autofirmados y autogenerados, puede

copiar su nombre de sujeto y huella digital. 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 “Validar certificados” en la página 38).
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.
Certificados autofirmados 37
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.
NOTA: Para averiguar cómo crear otro certificado autofirmado, consulte “Crear
manualmente certificados autofirmados” en la página 39. Para averiguar cómo
eliminar un certificado autofirmado y autogenerado, consulte “Eliminar
certificados autofirmados” en la página 45.
Validar 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 18, pidiendo al administrador que acepte o rechace el certificado.
Figura 18: 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 ver 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
38 Certificados autofirmados
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.
Para consultar el nombre del sujeto y la huella digital de un certificado autofirmado

y autogenerado, utilice el comando siguiente:
ns-> 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.
Crear manualmente 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 = dev_serial_num, 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.
Establecer un certificado autofirmado y definido por el administrador

En este ejemplo, definirá los siguientes componentes de un certificado autofirmado
para su uso con SSL:
Nombre distinguido/nombre del sujeto (“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
Generate:
Información del sujeto del certificado:

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 del certificado aparece, como se muestra en la Figura 19.
Figura 19: Detalles del certificado
Puede copiar el nombre del sujeto y la huella digital desde esta página y
comunicarlo 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 visualizar 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): (vacio)
fqdn(2): (www.juniper.net)
ipaddr(7): (vacio)
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 comunicarlo 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.
Autogenerar 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 20 muestra la ruta de decisiones que el dispositivo de seguridad toma al

encenderse para la generación de certificados.
Figura 20: 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
¿Existe Cert automáticamente un
para Sí certificado 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 no asignarle ningún
certificado 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 automática o manualmente,
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 id_num es el número de identificación del certificado
que desea eliminar:
delete pki object-id id_num
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 hacia SSL el tráfico HTTP (puerto

predeterminado 80) enviado al dispositivo (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
“Reenviar HTTP a SSL” en la página 3-8.
Capítulo 3
Directivas de red privada virtual
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 48
“Opciones criptográficas punto a punto” en la página 48
“Opciones VPN de acceso telefónico” en la página 56
“Túneles basados en directivas y en rutas” en la página 63
“Flujo de paquetes: VPN punto a punto” en la página 64
“Directrices para la configuración de un túnel” en la página 70
“Consideraciones de seguridad en VPN basadas en rutas” en la página 72
“Ruta nula” en la página 73
“Línea de acceso telefónico o arrendada” en la página 75
“Conmutación por error de la VPN hacia la línea arrendada o la ruta nula”

en la página 75
“Interfaz de túnel ficticia” en la página 78
“Enrutador virtual para interfaces de túnel” en la página 79
“Reencaminar a otro túnel” en la página 79
47
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” se explica en la Figura 21, “Opciones

criptográficas para un túnel VPN punto a punto,” en la página 49.
“Opciones VPN de acceso telefónico” se explica en la Figura 22, “Opciones

criptográficas para un túnel VPN de acceso telefónico,” en la página 56.
Cuando haya decidido qué tipo de túnel desea configurar (de acceso telefónico o
punto a punto), consulte la Figura 21 o la Figura 22 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 21. A continuación
de la figura, se indican las ventajas de cada opción.
NOTA: La Figura 21 en la página 49 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.
48 Opciones criptográficas
Capítulo 3: Directivas de red privada virtual
Figura 21: 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: 7. Encriptación IKE y Túnel o transporte
RSA o DSA Algoritmos de autenticación:
AES, DES o 3DES 15. Opciones ESP:
5. Longitud de bits: y
512 ó 768 Encriptación, autenticación y encriptación o
MD5 o SHA-1
ó 1024 ó 2048
16. Algoritmos de 17. Algoritmos de autenticación:
encriptación: AES, MD5 o SHA-1
8. ID IKE local: 9. ID IKE remota: DES ó 3DES
Dirección IP o U-FQDN Dirección IP o U-FQDN 10. Comprobación
o FQDN o ASN1-DN o FQDN o ASN1-DN antirreprocesamiento:
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 49
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 nivel máximo de procesamiento es el más bajo.
768
Ofrece más seguridad que la opción de 512 bits.
Su nivel máximo 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 nivel máximo 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 Diffie-Hellman 1
Su nivel máximo 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 nivel máximo de procesamiento es inferior al del grupo Diffie-Hellman 5.
Ofrece más seguridad que el grupo Diffie-Hellman 1.

Juniper Networks
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 nivel máximo 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 nivel máximo 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), 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), 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
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 rechazo 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

y 5.

Juniper Networks
Recomendado

Juniper Networks
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 nivel máximo 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
3DES

Juniper Networks
17. 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

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 22. A
continuación de la figura, se indican las ventajas de cada opción.
NOTA: La Figura 22 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.
Figura 22: 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. Grupo Diffie-Hellman 12. Protocolo IPSec:

Certificados o clave previamente Group: 1, 2 ó 5 ESP. . . . . . . . o bien . . . . . . . . AH
compartida
3. Tipo de certificado: 13. Modo:
RSA o DSA Túnel o transporte
6. Encriptación IKE y
Algoritmos de autenticación: 14. Opciones ESP:
4. Longitud de bits: AES, DES o 3DES Encriptación, encriptación
512 ó 768 y y autorización o autorización
ó 1024 ó 2048 MD5 o SHA-1
15. Algoritmos de 16. Algoritmos de
encriptación: autenticación:
7. ID IKE local: 8. ID IKE remota: AES, DES ó 3DES MD5 o SHA-1
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 nivel máximo de procesamiento es el más bajo.
768
Ofrece más seguridad que la opción de 512 bits.
Su nivel máximo 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 nivel máximo de procesamiento es inferior al de la opción de 2048 bits.
2048
5. Grupo Diffie-Hellman IKE: 1, 2 ó 5
y 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
3DES

Juniper Networks
MD5
SHA-1
Recomendado
7. ID IKE local: dirección IP (valor predeterminado), 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

FQDN
SubjectAltName.
ASN1-DN

emite.
8. ID IKE remota: dirección IP (valor predeterminado), 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

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 rechazo de servicio (DoS)
provocados cuando un atacante vuelve a enviar 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

y 5.

Juniper Networks
Recomendado

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 nivel máximo 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
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 de túnel, que estará asociada a un túnel
VPN específico.
NOTA: Normalmente, una interfaz de túnel está asociada a un solo túnel. No obstante,
también es posible asociar una interfaz de túnel a varios túneles. Para obtener
más información, consulte “Múltiples túneles por interfaz de túnel” en la
página 254.
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.
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 de túnel 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 el enfoque 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.
Túneles basados en directivas y en rutas 63

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 de túnel 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 de túnel 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 de 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 “Crear VPN radiales” en la página 310).
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.
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 166.
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
64 Flujo de paquetes: VPN punto a punto

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 son las que se muestran en la
Figura 23: 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 LAN de
LAN de
Tokio VPN1 París
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.
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.

Flujo de paquetes: VPN punto a punto 65

Si no ha habilitado ninguna opción de SCREEN para la zona Trust, el dispositivo

de seguridad procede inmediatamente al paso siguiente.

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

ejecuta los pasos restantes con el procedimiento de procesamiento del primer
paquete (First Packet Processing).

ejecuta el procedimiento de procesamiento rápido (Fast Processing), utilizando
la información disponible en la entrada de sesiones existente para procesar el
paquete. El procesamiento 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. 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 de túnel
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.



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.

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



paquete coincide con una sesión existente. A continuación, aplica el
procedimiento de procesamiento del primer paquete o de procesamiento
rápido.

ejecuta el procesamiento rápido, utilizando la información disponible en la
entrada de sesiones existente para procesar el paquete. El procesamiento
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
de túnel, 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.
Seguidamente, el dispositivo de seguridad reenvía el paquete a su destino.
Directrices para la configuración de un túnel

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 el Capítulo 2, “Criptografía de
claves públicas”.
70 Directrices para la configuración de un túnel

Para una VPN basada en directivas básica:
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.
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:
Directrices para la configuración de un túnel 71

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 “Puntos VPN con direcciones superpuestas” en la página 141.
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 o un 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.
Consideraciones de seguridad en VPN 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 de túnel 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 activo (up) a
inactivo (down). Cuando esto ocurre, todas las entradas de la tabla de rutas que
hacen referencia a la interfaz de túnel 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 de túnel, no tendrá en cuenta la ruta relativa a la interfaz de túnel y
72 Consideraciones de seguridad en VPN basadas en rutas

buscará la siguiente ruta con mayor coincidencia. La ruta que encontrará podría ser
la ruta predeterminada. Con esta ruta, el dispositivo de seguridad enviaría fuera el
tráfico desencriptado (es decir, en texto puro o sin formato) a través de una interfaz
sin túnel a la WAN pública.
Para evitar reencaminar el tráfico previsto originalmente para un túnel VPN a la

WAN pública como texto puro, puede configurar el dispositivo de seguridad para
que desvíe dicho tráfico a otro túnel, reencaminarlo a una línea arrendada o
simplemente descartarlo, utilizando una de las siguientes soluciones:
“Ruta nula” en esta página (descarta el tráfico cuando la ruta a la interfaz de

túnel se desactiva)
“Línea de acceso telefónico o arrendada” en la página 75 (reencamina el tráfico

a otra ruta segura cuando la ruta a la interfaz de túnel se desactiva)
“Interfaz de túnel ficticia” en la página 78 (descarta el tráfico cuando la ruta a la

interfaz de túnel se desactiva)
“Enrutador virtual para interfaces de túnel” en la página 79 (descarta el tráfico

cuando la ruta a la interfaz de túnel se desactiva)
“Reencaminar a otro túnel” en la página 79 (reencamina el tráfico a un túnel

VPN alternativo cuando la ruta a la interfaz de túnel se desactiva)
Ruta nula
Si el estado de un túnel VPN cambia a “inactivo”, el dispositivo de seguridad
cambia cualquier ruta que haga referencia a esa interfaz de túnel a “inactiva”. Si la
ruta a la interfaz de túnel 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 nula. Una ruta nula apunta a la
misma dirección de destino que la ruta a través de la interfaz de túnel, pero dirige el
tráfico hacia la interfaz nula. La interfaz nula es una interfaz lógica que descarta el
tráfico enviado hacia ella. Asigne a la ruta nula una métrica más elevada (más
alejada de cero) que la ruta que utiliza la interfaz de túnel para que la ruta nula
tenga una prioridad inferior.
NOTA: Las versiones anteriores a ScreenOS 5.1.0 no admiten interfaces nulas. Sin
embargo, puede utilizar una interfaz de túnel ficticia para lograr el mismo
objetivo. Para obtener información, consulte“Interfaz de túnel ficticia” en la
página 78.
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)
Consideraciones de seguridad en VPN basadas en rutas 73


* 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 tiene 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 nula 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 nula. 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
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 nula, 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 puro 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
reencaminarí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 nula en la tercera opción (consulte “Ruta
nula” en la página 73). La Figura 24 muestra cómo estas opciones de tratamiento
de un fallo de enrutamiento pueden funcionar en conjunto.
Figura 24: 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
LAN
local tunnel.1 Internet Interlocutor remoto
LAN remota
Segunda opción: Una ruta estática Túnel VPN
sobre una línea de acceso telefónico o ethernet4
arrendada hacia el interlocutor de la VPN. 1.2.2.1/24
Su métrica es mayor que la de la ruta que
Línea de acceso telefónico o arrendada
utiliza el túnel VPN. Esta opción de Interfaz
enrutamiento reenvía el tráfico como nula
texto puro a través de la línea protegida
al interlocutor. Descartar
Tercera opción: Una ruta nula con una métrica tráfico
superior 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 nula

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 puro.
Creará tres rutas en el dispositivo A para alcanzar a 10.2.2.0/24 y asignará a cada

ruta una métrica distinta:
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: utilizar la interfaz nula 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 25 en la página 76).
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 NULA 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 25: Fallo de enrutamiento hacia una línea arrendada y después a la ruta nula
El tráfico fluye desde la sucursal a

la oficina corporativa.
Preferencias de rutas:
1. tunnel.1 -> vpn1
2. ethernet4 -> línea arrendada
Puerta de enlace ethernet3
3. interfaz nula -> descartar ethernet3 1.1.1.250
1.1.1.1/24 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 NULA
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)
2
save

Puede verificar la presencia de las nuevas rutas ejecutando el comando get route.
isg2000-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 nula, que después lo descarta.
Interfaz de túnel ficticia

Cuando se produce un error, en lugar de conmutar el tráfico de un túnel VPN a una
interfaz nula (donde se descarta), se puede utilizar una interfaz de túnel inoperativa
para lograr el mismo objetivo.
NOTA: Las versiones anteriores a ScreenOS 5.1.0 no admiten interfaces nulas (consulte
“Ruta nula” en la página 73). Sin embargo, puede utilizar una interfaz de túnel
ficticia para lograr el mismo objetivo.
Para configurar una interfaz de túnel ficticia, haga lo siguiente:
1. Cree una segunda interfaz de túnel, pero no la asocie a un túnel VPN. En su

lugar, asóciela a una zona de túnel que se encuentre en el mismo dominio de
enrutamiento virtual que la primera interfaz de túnel.
NOTA: Si una interfaz de túnel 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 de túnel 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 de túnel en funcionamiento pase de activo a

inactivo y la entrada de la tabla de rutas relativa a esa interfaz quede inactiva,
las búsquedas de rutas encontrarán esta segunda ruta a la interfaz de túnel no
operativa. El dispositivo de seguridad reenviará el tráfico a la segunda interfaz
de túnel y como no está asociada a un túnel VPN, el dispositivo descartará el
tráfico.
Enrutador virtual para interfaces de túnel

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, sea conmutado a causa del 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 de túnel 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 de túnel 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 de túnel pasa de activo a inactivo, 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.
Reencaminar a otro túnel

Puede configurar dos o más túneles VPN hacia el mismo interlocutor remoto. Si uno
de los túneles se desactiva, el dispositivo de seguridad puede reencaminar 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:
“Interfaces Dual Untrust” en la página 11-50
“Conmutación por error del túnel de activo a respaldo” en la página 11-57
“Túneles activos dobles” en la página 11-62
“Aplicar pesos a la conmutación por error de túnel” en la página 11-67


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, AutoKey IKE” 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 111
“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 126
“Puertas de enlace IKE dinámicas con FQDN” en la página 131
“Alias” en la página 132
“Ajuste del interlocutor AutoKey IKE con FQDN” en la página 132
“Puntos VPN con direcciones superpuestas” en la página 141
“VPN en modo transparente” en la página 152
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 “Directivas de red privada virtual” en
la página 47.
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 26: Configuración de túneles VPN punto a punto
Oficina Zona Untrust

Zona Trust de Tokio
tunnel.1, sin numerar

ethernet1
10.1.1.1/24 ethernet3, 1.1.1.1/24
NAT
enrutador externo, 1.1.1.250
de Tokio
LAN Internet 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 27: 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
de París
ethernet1
Eth3, 2.2.2.2/24 10.2.2.1/24
NAT
Oficina
Zona Untrust de París Zona Trust
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 27.
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 28: 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 seguridad
Trust, 10.1.1.0/24 NAT
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 Tokio
10.2.2.1/24
Oficina de
Zona Untrust 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 28. 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 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 IDs 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 29: Configuración de túneles punto a punto: Túnel VPN

de
Tokio
Tunnel.1, sin numerar
ethernet1 ethernet3, 1.1.1.1/24
Trust_LAN NAT seguridad Trust_LAN
Trust, 10.1.1.0/24 de Tokio Internet Trust 10.2.2.0/24
LAN LAN
Tokio París
Untrust 10.1.1.0/24 Túnel: vpn1 Dispositivo de Untrust, 10.2.2.0/24
seguridad
de París
10.2.2.1/24
Oficina
Zona Untrust de Zona Trust
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 30: Configuración de túneles punto a punto: Rutas
trust-vr
Dst 10.2.2.0/24 Zona Trust Oficina Zona Untrust
Utilizar tunnel. 1 de Tokio
tunnel.1, sin numerar Trust_LAN
Dst 10.2.2.0/24 Trust, 10.2.2.0/24
Utilizar NULA ethernet1 ethernet3, 1.1.1.1/24
10.1.1.1/24 París
Métrica: 50 Enrutador externo, 1.1.1.250 Untrust,
NAT Interfaz nula
10.2.2.0/24
Dest 0.0.0.0/0 Internet trust-vr
Utilizar eth3 LAN LAN
Tunnel:vpn1 Dst 10.1.1.0/24
puerta de enlace: Utilizar tunnel. 1
1.1.1.250
Trust_LAN enrutador externo, 2.2.2.250 Interfaz nula
Dst 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 Métrica: 50
Tokio tunnel.1, sin numerar NAT
Untrust, 10.1.1.0/24 Oficina Dest 0.0.0.0/0
Zona Untrust de 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 nula, de modo que si en algún momento el estado cambia de tunnel.1
a “inactivo” 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
nula utiliza la LAN remota como dirección de destino, pero envía tráfico a la
interfaz nula, una interfaz lógica que descarta todo el tráfico que recibe. Asigne
a la ruta nula una métrica superior (más alejada de cero) que la ruta a la LAN
remota que utiliza tunnel.1, haciendo la ruta nula menos preferente que la ruta
que hace referencia a la interfaz de tunnel.1.

Figura 31: Configuración de túneles punto a punto: Directivas
trust-vr trust-vr
Dst 10.2.2.0/24 Oficina Dest 10.1.1.0/24
Utilizar tunnel. 1 Zona Trust Zona Untrust
de Tokio Utilice tunnel. 1
Dest 0.0.0.0/0 Dest 0.0.0.0/0
Utilizar eth1 tunnel.1, sin numerar Utilice eth3
puerta de enlace: ethernet1 ethernet3, 1.1.1.1/24 puerta de enlace:
1.1.1.250 10.1.1.1/24 Interfaz nula Enrutador externo, 1.1.1.250 2.2.2.250
NAT
Trust_LAN Internet Trust_LAN
Trust, 10.1.1.0/24 LAN LAN Trust, 10.2.2.0/24
Tunnel: vpn1
Tokio París
Untrust, enrutador externo, 2.2.2.250 Interfaz nula
10.1.1.0/24 ethernet1 Untrust,
ethernet3, 2.2.2.2/24 10.2.2.1/24 10.2.2.0/24
Trust -> Untrust tunnel.1, sin numerar NAT Trust -> Untrust
Trust_LAN -> París Oficina Trust_LAN ->
ANY (cualquiera), de París París
Permit (permitir) Zona Untrust Zona Trust ANY (cualquiera),
Permit (permitir)
Untrust -> Trust
París-> Trust_LAN Untrust -> Trust
ANY (cualquiera), París->
Permit (permitir) Trust_LAN
ANY (cualquiera),
Permit (permitir)
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 (ya sea 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 32: VPN punto a punto basada en rutas, AutoKey IKE
Topología de las zonas Topología de las zonas

configuradas en el configuradas en el
dispositivo de seguridad dispositivo de seguridad
de Tokio de París
Tokio París Tokio París
Zona Zona Zona Zona

Trust Untrust Untrust Trust
Interfaz de salida Interfaz de salida

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 nula al destino. Asigne una
métrica más alta (más alejada de cero) a la ruta nula 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 “inactivo” y la ruta que hace referencia a esa interfaz también se
inactiva, el dispositivo de seguridad utiliza la ruta nula, 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
en OK:
Address Name: Trust_LAN

Zone: Trust
en OK:
Address Name: Paris_Office

Zone: Untrust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Introduzca los siguientes datos
y haga clic en OK:
Gateway Name: To_Paris



Preshared Key: h1p8A24nG5

Return para regresar a la página de configuración básica de Gateway:

Phase 1 Proposal (for Custom Security Level): pre-g2-3des-sha
(o bien)
Certificados

Return para regresar a la página de configuración básica de puerta de
enlace:

Phase 1 Proposal (for Custom Security Level): rsa-g2-3des-sha
Preferred certificate (optional)
Peer CA: Entrust
Peer Type: X509-SIG
VPN Name: Tokyo_Paris

Remote Gateway:
Predefined: (seleccione), To_Paris


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
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
en OK:
Zone: Trust
en OK:
Address Name: Tokyo_Office
Zone: Untrust
3. VPN
y haga clic en OK:
Gateway Name: To_Tokyo

(o bien)
Certificados
Peer CA: Entrust
Peer Type: X509-SIG

Name: Paris_Tokyo
Remote Gateway:
Predefined: (seleccione), To_Tokyo


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, AutoKey IKE

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 la fases 1 y fase 2, debe especificar una propuesta de fase 1 (ya sea
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 33: VPN punto a punto basada en directivas, AutoKey IKE

configuradas en el configuradas en el
dispositivo de seguridad dispositivo de seguridad
de Tokio de París
Trust Zona Untrust Untrust Zona Trust

Zona Untrust-Tun Zona Zona Untrust-Tun 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
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
en OK:

Zone: Trust
en OK:

Zone: Untrust
3. VPN
y haga clic en OK:



(o bien)

Certificados


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: Tunnel
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
en OK:

Zone: Trust
en OK:

Zone: Untrust
3. VPN
y haga clic en OK:



(o bien)
Certificados


Peer CA: Entrust
Peer Type: X509-SIG

VPN Name: Paris_Tokyo

Remote Gateway: Predefined: (seleccione), To_Tokyo
4. Ruta

5. Directivas
haga clic en OK:
Name: To/From Tokyo

Source Address:
Service: ANY
Action: Tunnel
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 34: VPN punto a punto basada en rutas, interlocutor dinámico

configuradas en el dispositivo de configuradas en el dispositivo
seguridad de Tokio de seguridad de París
Zona Zona Zona Zona


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 (ya sea 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 nula al destino. Asigne una métrica más alta (más alejada de cero) a la
ruta nula 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 “inactivo” y la ruta
que hace referencia a esa interfaz también se inactiva, el dispositivo de

seguridad utiliza la ruta nula, 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
en OK:

Zone: Trust
en OK:

Zone: Untrust

3. VPN
y haga clic en OK:

Local ID: pmason@abc.com


Mode (Initiator): Aggressive
(o bien)
Certificados
NOTA: El U-FQDN “pmason@abc.com” debe aparecer en el campo SubjectAltName del

certificado.


Preferred Certificate (optional):
Peer CA: Verisign
Peer Type: X509-SIG

Remote Gateway:


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
en OK:

Zone: Trust
en OK:

Zone: Untrust
3. VPN
y haga clic en OK:

Dynamic IP Address: (seleccione), Peer ID: pmason@abc.com




(o bien)
Certificados


Peer CA: Verisign
Peer Type: X509-SIG
VPN Name: Paris_Tokyo

Remote Gateway:


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 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 35: 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

Sucursal eth3 y puerta de enlace eth3, 2.2.2.2/24 Oficina corporativa
Zona Trust asignados dinámicamente Puerta de enlace Zona DMZ
eth1, 10.1.1.1/24 por el ISP 2.2.2.250 eth2, 3.3.3.3/24
Servidor de
Internet correo
electrónico
Dispositivo A Túnel VPN Dispositivo B Petición 3.3.3.5
Petición IDENT
SMTP o POP3 Servidor
DHCP
Authentication
2.1.1.5
ID
User
User Name: pmason
Password: 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 las fases 1 y 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
en OK:
Address Name: Trusted network

Zone: Trust
en OK:

Zone: Untrust

4. Servicios
clic en OK:
Service Name: Ident

Service Timeout:
Use protocol default: (seleccione)
Source Port: Low 0, High 65535
Destination Port: Low 113, High 113
Objects > 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



(o bien)
Certificados


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: (seleccione), Trusted network
Service: Remote_Mail
Action: Tunnel
VPN Tunnel: branch_corp

Return para regresar a la página de configuración básica de Policy:
Authentication: (seleccione)
Auth Server: Local
User: (seleccione), Local Auth User - pmason
1. Interfaces
haga clic en OK:
Zone Name: DMZ

haga clic en OK:
Zone Name: Untrust


2. Direcciones
en OK:

Zone: DMZ
en OK:
Address Name: branch office

Zone: Untrust
3. Servicios
clic en OK:
Service Name: Ident

Service Timeout:
los siguientes servicios; finalmente, haga clic en OK:

Ident
MAIL
POP3
4. VPN
y haga clic en OK:
Gateway Name: To_branch

Dynamic IP Address: (seleccione), Peer ID: pmason@abc.com


(o bien)

Certificados


Peer CA: Verisign
Peer Type: X509-SIG
VPN Name: corp_branch

Remote Gateway:
Predefined: (seleccione), To_branch
5. Ruta

6. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), branch office
Action: Tunnel
VPN Tunnel: corp_branch
CLI (Dispositivo A)
1. Interfaces
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 36: VPN punto a punto basada en rutas, clave manual

configuradas en el dispositivo configuradas en el dispositivo
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 Puerta de enlace Puerta de enlace París
Zona Trust 1.1.1.250 2.2.2.250 Zona Trust
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 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.


no encriptado.
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
en OK:

Zone: Trust
en OK:

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 Manual Key:

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
en OK:

Zone: Trust
en OK:

Zone: Untrust

3. VPN
VPN Tunnel Name: Paris_Tokyo

Gateway IP: 1.1.1.1
> 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
Manual Key:

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 37: 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
Tokio 1.1.1.250 París
2.2.2.250
Internet
Túnel VPN

Para configurar el túnel, lleve a cabo los siguientes pasos en los dispositivos de
seguridad 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
en OK:

Zone: Trust
en OK:

Zone: Untrust

3. VPN
VPN Tunnel Name: Tokyo_Paris

Gateway IP: 2.2.2.2
Manual Key:
Bind to: Tunnel Zone, Untrust-Tun

4. Ruta

5. Directivas
haga clic en OK:
Name: To/From Paris

Source Address:
Service: ANY
Action: Tunnel
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
en OK:

Zone: Trust
en OK:

Zone: Untrust
3. VPN
VPN Tunnel Name: Paris_Tokyo

Gateway IP: 1.1.1.1
Security Index (HEX Number): 3030 (Local), 3020 (Remote)
Manual Key:

4. Ruta

5. Directivas
haga clic en OK:

Name: To/From Tokyo

Source Address:
Service: ANY
Action: Tunnel
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 de
FQDN a 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 de FQDN a 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 de FQDN a dirección IP que avise al
servidor DNS de los cambios de dirección.
Figura 38: 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 y la asigna al interlocutor IKE. direcciones IP
2. El interlocutor IKE notifica al servidor DNS la nueva dirección

para que éste pueda actualizar su tabla de asignación de FQDN
a dirección IP.
1.1.1.10 – Servidor DHCP Servidor DNS
1.1.7.9
Sin que sea necesario 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.
Puertas de enlace IKE dinámicas con FQDN 131

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 39: 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
Si el interlocutor IKE remoto se encuentra

Dispositivo de seguridad local en 1.1.1.202, las negociaciones IKE se Interlocutor IKE remoto
desarrollan con éxito.
Si el interlocutor IKE
remoto se encuentra en
Dispositivo de seguridad local 1.1.1.114 Interlocutor IKE remoto
o bien
1.1.1.20, las negociaciones
IKE fracasan.
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 40 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.
132 Puertas de enlace IKE dinámicas con FQDN

Figura 40: Interlocutor AutoKey IKE con FQDN

de seguridad de Tokio de seguridad de París
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
1.1.1.250 Zona Trust
Zona Trust
Internet
Túnel VPN
Interfaz de túnel: tunnel.1 Interfaz de túnel: tunnel.1

Puerta de enlace remota: Puerta de enlace remota: 1.1.1.1
www.nspar.com
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.

no encriptado.
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
en OK:

Zone: Trust
en OK:

Zone: Untrust
3. VPN
y haga clic en OK:

Static IP Address: (seleccione), IP Address/Hostname: www.nspar.com




(o bien)
Certificados


Peer CA: Entrust
Peer Type: X509-SIG

Remote Gateway:


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
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
en OK:

Zone: Trust
en OK:

Zone: Untrust
4. VPN
y haga clic en OK:



(o bien)

Certificados


Peer CA: Entrust
Peer Type: X509-SIG
Name: Paris_Tokyo
Remote Gateway:


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
NOTA: El número 1 es el número de ID de la CA. Para consultar los números ID de CAs,


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
Puntos 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.
Para NAT-src, las interfaces situadas a ambos extremos del túnel deben poseer
direcciones IP en subredes únicas mutuamente, 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 “Usar DIP
en otra subred” en la página 2-148.
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 de la que el dispositivo de seguridad tenga una entrada en su
tabla de rutas. (Para obtener información sobre el enrutamiento a la hora de
configurar NAT-dst, consulte “Enrutamiento para NAT-Dst” en la página 8-34).
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 obtener
información sobre las MIP, consulte “Direcciones IP asignadas” en la
página 8-65).
Puntos VPN con direcciones superpuestas 141

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.
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 41, en la que se ejemplifica un túnel VPN entre
dos puntos con espacios de direcciones superpuestas.
Figura 41: Superposición de direcciones en ubicaciones de interlocutores
Dispositivo A Túnel VPN Dispositivo B

Espacio de Espacio de
direcciones direcciones
internas tunnel.1 tunnel.2 internas
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
142 Puntos VPN con direcciones superpuestas

Si los dispositivos de seguridad de la Figura 41 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 42: Interfaz de túnel con NAT-Src y NAT-Dst

configuradas en dispositivo A configuradas en dispositivo B
en la sucursal. en la sucursal 1.
A B B A
Zona Trust Zona Untrust Zona Untrust Zona Trust
Puerta de enlace ServidorB

Puerta de enlace 10.1.1.5
1.1.1.250 2.2.2.250
Red A Internet Red B
10.1.1.0/24 Dispositivo A 10.1.1.0/24
Dispositivo B
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
ServidorA 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
en OK:
Address Name: corp

Zone: Trust
en OK:
Address Name: virtualA

Zone: Trust
en OK:
Address Name: branch1

Zone: Untrust
en OK:
Address Name: serverB

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.



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), serverB
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
en OK:

Address Name: branch1

Zone: Trust
en OK:
Address Name: virtualB

Zone: Trust
en OK:
Address Name: corp

Zone: Untrust
en OK:
Address Name: serverA

Zone: Untrust
4. VPN
VPN Name: vpn1

Gateway Name: corp


Service: ANY
5. Rutas



Interface: tunnel.1

Interface: Null
Metric: 10
6. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), serverA
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

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 serverB 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 serverB 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 serverA 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 serverA 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 sobre el modo transparente, consulte “Modo
transparente” en la página 2-82.
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.
152 VPN 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.
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 local_lan: 1.1.1.0/24 en V1-Untrust local_lan: 2.2.2.0/24 en V1-Trust
peer_lan: 2.2.2.0/24 en V1-Untrust peer_lan: 1.1.1.0/24 en V1-Untrust
Puerta de enlace IKE gw1, 2.2.2.2, preshared key h1p8A24nG5, gw1, 1.1.1.1, preshared key h1p8A24nG5,
seguridad: compatible seguridad: compatible
Túnel VPN seguridad: compatible seguridad: compatible
Directivas local_lan -> peer_lan, cualquier servicio, local_lan -> peer_lan, cualquier servicio,
vpn1 vpn1
peer_lan -> local_lan, cualquier servicio, peer_lan -> local_lan, cualquier servicio,
vpn1 vpn1
Enrutador externo Dirección IP: 1.1.1.250 Dirección IP: 2.2.2.250
Ruta 0.0.0.0/0, use VLAN1 interface 0.0.0.0/0, use VLAN1 interface
to gateway 1.1.1.250 to gateway 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 153

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
en OK:
Address Name: local_lan

Zone: V1-Trust

en OK:
Address Name: peer_lan

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), local_lan
Address Book Entry: (seleccione), peer_lan
Service: ANY
Action: Tunnel
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.
Network>Interfaces > Edit (para ethernet1): Introduzca los siguientes datos y

haga clic en Apply:

Zone Name: V1-Trust

haga clic en OK:

2. Direcciones
en OK:

Zone: V1-Trust
en OK:

Address Name: peer_lan

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), peer_lan
Service: ANY
Action: Tunnel
Tunnel VPN: vpn1
CLI (Dispositivo A)
1. Interfaces y zonas
unset interface ethernet1 ip
unset interface ethernet1 zone


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 local_lan 1.1.1.0/24
set address v1-untrust peer_lan 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 local_lan peer_lan any tunnel vpn vpn1
set policy top from v1-untrust to v1-trust peer_lan local_lan any tunnel vpn vpn1
save
CLI (Dispositivo B)
set zone v1-trust manage
set interface vlan1 manage-ip 2.2.2.3
set interface vlan1 manage
2. Direcciones
set address v1-trust local_lan 2.2.2.0/24
set address v1-untrust peer_lan 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 local_lan peer_lan any tunnel vpn vpn1
set policy top from v1-untrust to v1-trust peer_lan local_lan 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 160
“VPN de acceso telefónico basada en directivas, AutoKey IKE” en la

página 160
“VPN de acceso telefónico basada en rutas, interlocutor dinámico” en la

página 166
“VPN de acceso telefónico basada en directivas, interlocutor dinámico” en

la página 173
“Directivas bidireccionales para usuarios de VPN de acceso telefónico” en

la página 178
“Identificación IKE de grupo” en la página 183
“Identificación IKE de grupo con certificados” en la página 183
“Tipos de identificación IKE ASN1-DN Wildcard y Container” en la

página 185
“Creación de una identificación IKE de grupo (certificados)” en la

página 188
“Configuración de una ID IKE de grupo con claves previamente

compartidas” en la página 192
“Identificación IKE compartida” en la página 198
159
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-61. 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 183.
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 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 “Directivas de red privada virtual” en
la página 47.
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 dicho interlocutor.
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.
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, nuevamente, utiliza ESP con encriptación 3DES y autenticación SHA-1.
160 Acceso telefónico

Capítulo 5: Redes privadas virtuales de acceso telefónico
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 43: 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
Internet 10.1.1.5
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 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 la propuesta de fase 1 (ya sea 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.
WebUI
1. Interfaces
haga clic en Apply:
Acceso telefónico 161

Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Dirección
en OK:
Address Name: UNIX

Zone: Trust
3. Usuario
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


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



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 utilizar 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

2. Haga clic en Add a new connection y escriba UNIX junto al icono de nueva
conexión que aparecerá en pantalla.


Protocol: All
ampliar la directiva de la conexión.
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 en la lista desplegable Select Certificate.
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 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 a través de él

puede originarse desde el otro extremo. Todas las zonas del dispositivo de
seguridad se encuentran en el dominio de enrutamiento Trust-vr.

Figura 44: 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 correo
Zona DMZ 1.2.2.5
Zona Untrust Puerta de enlace
Petición
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
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 la fase 1 y fase 2, se debe
especificar la propuesta de fase 1 (ya sea pre-g2-3des-sha para el método de clave
previamente compartida o rsa-g2-3des-sha para certificados) y seleccionar el
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 nula al destino. Asigne una métrica más alta (más alejada de cero) a la
ruta nula 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 “inactivo” y la ruta
que hace referencia a esa interfaz también se inactiva, el dispositivo de
seguridad utiliza la ruta nula, que descarta todo tráfico enviado hacia él, en
lugar de la ruta predeterminada, que reenvía tráfico no encriptado.
Finalmente, creará directivas permitiendo que el 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
en OK:

Zone: DMZ
en OK:
Address Name: Phil

Zone: Untrust
3. Servicios
clic en OK:
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


(o bien)
Certificados


Peer CA: Verisign
Peer Type: X509-SIG
VPN Name: corp_Phil

Remote Gateway:
Predefined: (seleccione), To_Phil

Bind to: Interfaz de túnel: (seleccione), tunnel.1

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 lleve a cabo una de estas dos acciones:
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 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 cualquiera de los extremos indistintamente.
Figura 45: VPN de acceso telefónico basada en directivas, interlocutor dinámico
Usuario remoto: Phil Interfaz de salida Oficina corporativa

NetScreen-Remote Zona Untrust Zona DMZ
Puerta de enlace 1.1.1.250 Servidor de correo
Petición 1.2.2.5
SMTP
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 la fase 1 y fase 2, se debe
especificar la propuesta de fase 1 (ya sea pre-g2-3des-sha para el método de clave
previamente compartida o rsa-g2-3des-sha para certificados) y seleccionar el
WebUI
1. Interfaces
haga clic en OK:
Zone Name: DMZ

haga clic en OK:
Zone Name: Untrust

2. Direcciones
en OK:

Zone: DMZ
en OK:
Address Name: Phil

Zone: Untrust
3. Servicios
clic en OK:
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


(o bien)
Certificados


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. Haga clic en My Identity y lleve a cabo una de estas dos acciones:
Haga clic en Pre-shared Key > Enter Key: Escriba h1p8A24nG5, después haga
clic en OK.

(o bien)
Seleccione el certificado que contiene la dirección de correo electrónico

“pmason@email.com” 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
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 173). 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
en OK:
Address Name: trust_net

Zone: Trust
OK:
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


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
Subnet: 10.1.1.0
Mask: 255.255.255.0
Protocol: All
5. Haga clic en My Identity: Siga uno de estos dos pasos:
Haga clic en 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.
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
Identificación IKE de grupo 183

seguridad si la configuración de VPN en su cliente VPN especifica un certificado que

contenga elementos de nombre completo que 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.
Figura 46: Identificación IKE de grupo con certificados
ID IKE de grupo con Grupo de usuarios de acceso telefónico

claves previamente
Usuarios IKE de compartidas
acceso telefónico (Distinguished Name)
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
---------- distinguished name (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.
184 Identificación IKE de grupo

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 continuación, 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án 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, frecuentemente pero no siempre, desde lo más general a lo más
específico. Consulte la Figura 47 para obtener un ejemplo.
Figura 47: Nombre distinguido ASN1-DN
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 del 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 del 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 hace que coincidan las dos ID IKE,
aunque el orden de los valores en las dos ID difiere.
Figura 48: Autenticación satisfactoria de comodines ASN1-DN
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 especificados en el ASN1-DN E= E=
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 del 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 IDs del usuario IKE de acceso telefónico
y del usuario IKE de grupo. Si hay valores múltiples, su orden en los campos
correspondientes también deberá ser igual.
Figura 49: Éxito y fallo de la autenticación utilizando las ID de tipo Container del ASN1-DN
ID IKE del 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
C=us C=us
telefónico contiene valores
exactamente iguales a los ST=ca Autenticación ST=
de ASN1-DN ASN1-DN. El satisfactoria
orden de las entradas L= sf L=
múltiples en el campo de
identificación OU también O=juniper O=juniper
es idéntico.
OU=mkt,OU=dom,OU=west OU=mkt,OU=dom,OU=west
CN=rick CN=
ID IKE del ASN1-DN del usuario IKE ID IKE Container del ASN1-DN
de acceso telefónico del usuario IKE de grupo
E= E=
El segundo ASN1-DN de
C=us C=us
usuario IKE de acceso
telefónico contiene valores Fallo de
ST=ca ST=
exactamente iguales a los de autenticación
ASN1-DN ASN1-DN. Sin L= la L=
embargo,,el orden de las
entradas múltiples en el O=juniper O=juniper
campo de identificación OU
OU=mkt,OU=west,OU=dom OU=mkt,OU=dom,OU=west
no es igual.
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
User1. 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á office_1.
Figura 50: 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 de acceso Internet LAN
telefónico con ID IKE: web1
o=juniper Túnel VPN 10.1.1.5
ou=marketing Perfil de usuario de
identificación IKE de grupo
Nombre de usuario: User1
Puerta de enlace 1.1.1.250 Grupo de usuarios: office_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 web 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
en OK:
Address Name: web1
Zone: Trust
3. Usuarios
OK:
User Name: User1
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 office_1 en el campo Group
Name, realice la acción que se indica a continuación y después haga clic en OK:
Seleccione User1 y utilice el botón << para mover esta definición de la
columna Available Members a la columna Group Members.
4. VPN
y haga clic en OK:
Gateway Name: Corp_GW
Remote Gateway Type: Dialup User Group: (seleccione), Group: office_1

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 User1 ike-id asn1-dn wildcard o=juniper,ou=marketing share-limit 10
set user-group office_1 user User1
4. VPN
set ike gateway Corp_GW dialup office_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
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 parte de la base de 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 parte situada más a la derecha 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 51: ID IKE de grupo con claves previamente compartidas
ID IKE de grupo con claves

Usuarios IKE de previamente compartidas
acceso telefónico +
Clave previamente compartida Grupo de usuarios de acceso telefónico
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 completa.
carol.jnpr.net
(Clave previamente compartida de cada usuario IKE = valor inicial
+ de clave previamente compartida x ID IKE completa).
834a2bbd32adc4e9 Nota: Ya que la identificación de IKE
para Carol no es carol.eng.jnpr.net, el Para autenticar el usuario, el dispositivo de seguridad compara
dispositivo de seguridad rechaza la su clave generada con la clave previamente compartida que
petición de conexión. acompaña al paquete inicial de la fase 1.

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 name_str usr_name_str

(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.
Posteriormente, 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

User2. 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á office_2.

Figura 52: 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
Nombre de usuario: User2
puerta de enlace 1.1.1.250 Grupo de usuarios: office_2
ID simple: juniper.net
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
WebUI
1. Interfaces
haga clic en OK:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Dirección
en OK:
Address Name: web1

Zone: Trust
3. Usuarios
OK:
User Name: User2

Status: Enable
IKE Identity: juniper.net

Objects > User Groups > Local > New: Escriba office_2 en el campo Group
Name, realice la acción que se indica a continuación y después haga clic en OK:
Seleccione User2 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 User2 ike-id u-fqdn juniper.net share-limit 10
set user-group office_2 user User2
4. VPN
set ike gateway Corp_GW dialup office_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 name_str usr_name_str
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: Haga clic en Pre-shared Key > Enter Key: Escriba
11ccce1d396f8f29ffa93d11257f691af96916f2, después haga clic en OK.
ID Type: (seleccione E-mail Address) y escriba heidi@juniper.net.



Hash Alg: SHA-1
9. Haga clic en Authentication (Phase 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.
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:
198 Identificación IKE compartida

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. Seguidamente, é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 Remote_Sales. 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á R_S. 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
Figura 53: 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

Nombre de usuario: Remote_Sales
Usuario de acceso telefónico con Grupo de usuarios: R_S
ID IKE: mike@ns.com ID simple: sales@ns.com
Contraseña XAuth: 5678
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

Identificación IKE compartida 199

2. Dirección
en OK:
Address Name: web1

Zone: Trust
3. Usuarios
OK:
User Name: Remote_Sales

Status: Enable
IKE Identity: sales@ns.com
Objects > User Groups > Local > New: Escriba R_S en el campo Group Name,
realice la acción que se indica a continuación y después haga clic en OK:
Seleccione Remote_sales y utilice el botón << para moverlo de la columna

OK:
User Name: Joe

Status: Enable
XAuth User: (seleccione)
Password: 1234
Confirm Password: 1234
OK:
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), R_S
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


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 Remote_Sales ike-id sales@ns.com share-limit 250
set user-group R_S user Remote_Sales
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 R_S 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
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
Dirección IP: 10.1.1.5
ID Type: IP Address; 1.1.1.1

6. Haga clic en My Identity: Haga clic en Pre-shared Key > Enter Key: Escriba
abcd1234, después haga clic en OK.
ID Type: (seleccione E-mail Address) y escriba sales@ns.com.

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 (L2TP)
Este capítulo proporciona una introducción al 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. Contiene las siguientes secciones:
“Introducción al L2TP” en esta página
“Encapsular y desencapsular paquetes” en la página 208
“Encapsular” en la página 208
“Desencapsular” en la página 209
“Ajuste de los parámetros L2TP” en la página 211
“L2TP y L2TP sobre IPSec” en la página 213
“Configurar L2TP” en la página 213
“Configurar L2TP sobre IPSec” en la página 218
“L2TP bidireccional sobre IPSec” en la página 225
Introducción al L2TP
El protocolo L2TP (protocolo de encapsulamiento de la capa 2 o Layer 2 Tunneling
Protocol) 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. El protocolo L2TP envía tramas
PPP por un túnel entre un concentrador de acceso L2TP (LAC) y el LNS.
En origen, 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 205

Figura 54: Túnel L2TP entre ISP (LAC) y el dispositivo de seguridad (LNS)
Usuario de Conexión de
acceso acceso telefónico
telefónico Internet Dispositivo de seguridad
ISP
LAN
corporativa
Concentrador Túnel L2TP Concentrador

de acceso (reenvío de sesiones PPP de acceso
L2TP (LAC) del LAC al LNS) L2TP (LNS)
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 55: 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, bien 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.
206 Introducción al L2TP

Capítulo 6: Protocolo de encapsulamiento de la capa 2 (L2TP)
Figura 56: Asignaciones IP y DNS del ISP
En primer lugar, el ISP asigna al ISP

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 utilizables en
Internet. Ésta se convierte en la dirección IP interna del túnel L2TP.
Figura 57: 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 forzarlo
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).
Introducción al L2TP 207

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 bidireccional).
Autenticación de usuario utilizando 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)
NOTA: La base de datos local y los servidores RADIUS son ambos compatibles con PAP y
CHAP SecurID y los servidores LDAP sólo son compatibles con PAP.
Asignación de las direcciones IP de los usuarios, los servidores DNS (Domain

Name System), y los servidores WINS (Windows Internet Naming Service)
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 L2TP, el dispositivo de seguridad debe operar en la capa 3, con
interfaces de la zona de seguridad en modo NAT o de ruta. 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.
Encapsular y desencapsular paquetes

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.
Encapsular
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 58 en la página 209.
208 Encapsular y desencapsular paquetes

Figura 58: 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 datos 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.
Desencapsular
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 59 en la página 210.
Encapsular y desencapsular paquetes 209

Figura 59: 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 de datos 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 de datos 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 de datos 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.
210 Encapsular y desencapsular 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 name_str
remote-settings. Los ajustes específicos de usuario L2TP reemplazan a los ajustes
predeterminados L2TP.
Ajuste de los parámetros L2TP 211

Como se muestra en Figura 60 en la página 212, 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 60: Conjunto de direcciones IP y ajustes predeterminados L2TP
RADIUS
10.1.1.245
Zona Trust Zona Untrust DNS 1
1.1.1.2
Nota: El conjunto de direcciones Internet DNS 2

L2TP debe pertenecer a una subred 1.1.1.3
distinta de la de la zona Trust.
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
212 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 en claro. (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 207).
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.
Configurar L2TP
En este ejemplo, como se muestra en la Figura 61 en la página 214, 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 213

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 61: Configuración de L2TP
Grupo de usuarios de acceso

telefónico autenticados/L2TP: fs
Zona de Conjunto de direcciones

acceso DNS1: 1.1.1.2 IP: global 10.10.2.100 –
Adam telefónico 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 utilizan 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

214 L2TP y L2TP sobre IPSec

2. Usuarios L2TP
OK:
User Name: Adam

Status: Enable
L2TP User: (seleccione)
User Password: AJbioJ15
Confirm Password: AJbioJ15
OK:
User Name: Betty

Status: Enable
User Password: BviPsoJ1
Confirm Password: BviPsoJ1
OK:
User Name: Carol

Status: Enable
User Password: Cs10kdD3
Confirm Password: Cs10kdD3
3. Grupo de usuarios L2TP
Objects > User Groups > Local > New: Escriba fs en el campo Group Name,
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
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 Nuevo y luego seleccione Valor de cadena.
6. Escriba Contraseña.
7. Haga doble clic en Contraseña. 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
Configurar L2TP sobre IPSec

Este ejemplo utiliza el túnel L2TP creado en el ejemplo anterior (“Configurar L2TP”
en la página 213). 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 del
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 62: Configuración de L2TP sobre IPSec
IKE-L2TP
Grupo de usuarios de acceso telefónico: fs
Zona de
acceso Conjunto de direcciones
Adam telefónico DNS1: 1.1.1.2 IP: global 10.10.2.100 – Red
10.10.2.180 corporativa
DNS2: 1.1.1.3
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
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.
OK:
User Name: Betty

Status: Enable
IKE Identity: bdavis@abc.com

User Password: BviPsoJ1

Confirm Password: BviPsoJ1
OK:
User Name: Carol

Status: Enable
IKE Identity: cburnet@abc.com
User Password: Cs10kdD3
Confirm Password: Cs10kdD3
4. Grupo de usuarios IKE/L2TP
Objects > User Groups > Local > New: Escriba fs en el campo Group Name,
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
Apply:

7. Túnel L2TP
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 Nuevo y luego seleccione Valor de cadena.
6. Escriba Contraseña.
7. Haga doble clic en Contraseña. 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 puede que sean desconocidos. 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

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


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


Remote Party ID Type: IP Address
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:
Seleccione el certificado con la dirección de correo electrónico especificada

como ID IKE del usuario en el dispositivo de seguridad en la lista desplegable
Select Certificate:
ID Type: E-Mail Address

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
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 la conexión y reciba una petición de nombre de usuario y
contraseña, teclee adam, AJbioJ15. Para más información, consulte la
documentación de Microsoft Windows 2000.
L2TP bidireccional sobre IPSec

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. Usted 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 63 en la
página 226.
Figura 63: L2TP bidireccional sobre IPSec
ethernet3 ethernet3
1.1.1.1/24 10.1.1.1/24
Zona de acceso telefónico
Zona Trust
Internet
LAN
Cliente de Túnel L2TP sobre Enrutador Servidor UNIX

NetScreen-Remote 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
en OK:
Address Name: trust_net

Zone: Trust

3. Usuario L2TP/IKE
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
OK:
Name: tun1
Use Default Settings: (seleccione)
Secret: netscreen
Keepalive (mantenimiento de conexión): 60
5. VPN
y haga clic en OK:

Security Level: Standard (seleccione)
Remote Gateway Type: Dialup User; (seleccione), dialup-j
Preshared Key: n3TsCr33N
Outgoing Interface: (seleccione) ethernet3
> Advanced: Introduzca los siguientes datos y haga clic en Return para
regresar a la página de configuración básica de la Gateway 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 (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
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

Remote Party ID Type: IP Address
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:
Seleccione el certificado con la dirección de correo electrónico especificada

como ID IKE del usuario en el dispositivo de seguridad en la lista desplegable
Select Certificate.
ID Type: E-Mail Address

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
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 232
“Sondeos de NAT” en la página 233
“Atravesar un dispositivo NAT” en la página 235
“Suma de comprobación de UDP” en la página 237
“Paquetes de mantenimiento de conexión” en la página 238
“Simetría iniciador/respondedor” en la página 238
“Habilitación de NAT-Traversal” en la página 239
“Supervisión de VPN” en la página 240
“Opciones de reencriptación y optimización” en la página 241
“Interfaz de origen y dirección de destino” en la página 242
“Consideraciones sobre directivas” en la página 243
“Configuración de la función de supervisión de VPN” en la página 244
“Objetos y capturas SNMP para la supervisión de VPN” en la página 252
“Múltiples túneles por interfaz de túnel” en la página 254
“Asignación de rutas a túneles” en la página 255
“Direcciones de interlocutores remotos” en la página 256
“Entradas de tabla manuales y automáticas” en la página 257
231
“Puertas de enlace VPN redundantes” en la página 290
“Grupos VPN” en la página 291
“Mecanismos de supervisión” en la página 292
“Comprobar flag TCP SYN” en la página 296
“Crear VPN adosadas” en la página 303
“Crear VPN radiales” en la página 310
NAT-Traversal
Las normas de Internet NAT (traducción de direcciones de red o Network Address
Translation) y NAPT (traducción de puertos de direcciones de red o 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 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 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 de 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.
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
232 NAT-Traversal
Capítulo 7: Funciones avanzadas de redes privadas virtuales
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).
NOTA: La carga de datos de descubrimiento NAT (“Nat-Discovery” o NAT-D) es un tipo de

carga de datos IKE para NAT-T recientemente introducido. 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.
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
NAT-Traversal 233
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 de
salida.
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
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 238.
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.
234 NAT-Traversal
Atravesar un dispositivo NAT

En la Figura 64, 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 64: NAT-Traversal
Empresa
Hotel
Dispositivo NAT
Internet
Túnel VPN
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.
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 de 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 65 en la página 236, 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
NAT-Traversal 235
distinguir el paquete ISAKMP encapsulado de un paquete ESP y para

desmultiplexarlo correctamente.
Figura 65: 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
Longitud Suma de comprobación
Carga de datos
Segmento UDP después de detectar un dispositivo NAT
Marcador no ESP (0000)
Carga de datos
La Figura 66 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.
236 NAT-Traversal
Figura 66: Paquete IPSec ESP antes y después de la detección de NAT
Paquete IPSec ESP antes de detectar un dispositivo NAT

Paquete IPSec
Enviado por la puerta de Paquete original
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.
Paquete IPSec ESP después de detectar un dispositivo NAT

Paquete IPSec Paquete original Callouts
Enviado por la puerta de enlace IKE Enviado por el host iniciador
Encabezado Encabezado Encabezado Encabezado Encabezado
IP2 UDP ESP IP1 TCP Carga de datos
La puerta de enlace local agrega estos

encabezados al paquete.
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.
WebUI
VPNs > 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 159; introduzca los siguientes datos y, finalmente, haga clic en OK:


UDP Checksum: Enable
CLI
set ike gateway name nat-traversal udp-checksum
unset ike gateway name nat-traversal udp-checksum
NAT-Traversal 237
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 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 (SAs) 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.
Figura 67: 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
Túnel 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 direcciones IP paquetes que recibe del dispositivo B, utilizando direcciones
1.2.1.2 - 1.2.1.50 que toma de su conjunto de direcciones IP.
En la Figura 67, 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 única 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.
238 NAT-Traversal
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, este
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.
Habilitación de NAT-Traversal
En la Figura 68, 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
Michael Smith, un comercial que está participando en una convención. Para que
Michael Smith 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
“msmith”, 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 68: Habilitación de NAT-Traversal
Hotel Empresa
Dispositivo NAT
Internet
Túnel VPN
WebUI
VPNs > 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:
NAT-Traversal 239


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 msmith nat-traversal
set ike gateway msmith nat-traversal udp-checksum
set ike gateway msmith nat-traversal keepalive-frequency 8
save
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 number. 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á activo (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 inactivo (down).
Down to Up: Cuando el estado de la supervisión de VPN es inactivo (down),

pero la petición de eco ICMP obtiene una sola respuesta, el estado pasa a activo
(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 252.
240 Supervisión de VPN

Usted aplica la supervisión de VPN 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 241.
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 para el túnel sea activo (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
activo a inactivo, 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 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 254.
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 241

De forma predeterminada, la optimización de la supervisión de VPN está

inhabilitada. Si la habilita (set vpn name 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 69: 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
de eco desde su interfaz de Interfaz de salida puerta de enlace remota
salida a la puerta de enlace
remota; es decir, desde la Dispositivo A
interfaz de zona Untrust en Túnel VPN Dispositivo B
Dispositivo A a la interfaz de LAN LAN
zona Untrust en el dispositivo B.
(comportamiento Zona Trust Zona Untrust
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 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, desde Zona Trust Zona Untrust
más allá de la interfaz de zona
Untrust de Dispositivo A. Nota: El dispositivo A precisa de una directiva que permita el tráfico de peticiones de eco
Dispositivo A –> Terminador de VPN de de la zona Trust a la zona Untrust.
terceras partes
Dirección de origen: Dirección de destino:
Dispositivo A envía peticiones de Servidor FTP
eco desde la interfaz de zona Interfaz de la zona Trust
Trust a un dispositivo ubicado más Terminador de VPN
allá de la puerta de enlace remota. Dispositivo A
Esto podría ser necesario si el Túnel VPN de terceras partes
interlocutor remoto no responde a LAN
peticiones de eco pero admite
directivas que permitan el tráfico Zona Trust Zona Untrust
entrante de estas peticiones.
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.
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-64.
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 a 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 a 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 terceras partes 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
VPNs > 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 la 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 activo a inactivo. 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 activo a inactivo. 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
activo a inactivo.
(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 number
set vpnmonitor threshold number
set vpn name_str monitor [ source-interface interface [ destination-ip ip_addr ] ]
[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 umbral 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 Zona: 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 Zona: 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: src = ethernet1; dst Supervisión de VPN: src = ethernet1; dst
= 10.2.1.1 = 10.1.1.5
Unido a la interfaz: tunnel.1 Unido 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 nula: para derivar el tráfico a 10.2.1.0/24 (Ruta nula: para derivar el tráfico a 10.1.1.0/24
si tunnel.1 se desactiva) A 10.2.1.0/24, utilizar si tunnel.1 se desactiva) A 10.1.1.0/24, utilizar
interfaz nula, métrica: 10 interfaz nula, 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 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
en OK:

Zone: Trust
en OK:
Address Name: Remote_LAN

Zone: Untrust
3. VPN
VPN Name: vpn1

Remote Gateway:

Gateway Name: gw1

Type:
Preshared Key: Ti82g4aX


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
en OK:

Zone: Trust
en OK:
Address Name: Remote_LAN

Zone: Untrust

3. VPN
VPN Name: vpn1

Remote Gateway:
Gateway Name: gw1
Type:
Preshared Key: Ti82g4aX


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 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 (SA) 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 (activo o inactivo)
Estado de túnel (activo o inactivo)
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 encabezados 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 varios túneles
VPN. (Consulte “Asignación de rutas a túneles” en la página 255).
Figura 70: 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.
Dispositivo de seguridad local
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 el número
máximo de túneles VPN dedicados admitido (lo 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.
254 Múltiples túneles por interfaz de túnel

Asignación de rutas a túneles

Para ordenar el tráfico a través de túneles VPN enlazados 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 71, 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.
Figura 71: 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 a externas asignadas dinámicamente y direcciones IP de
la interfaz tunnel.1 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
vpn3
10.2.0.0/16
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 Flag

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 BGP para Durante las negociaciones de fase 2, los dos interlocutores IKE intercambian
rellenar la tabla de rutas automáticamente, o bien introducir direcciones de interfaz de túnel e introducen automáticamente estas
manualmente estas rutas. La dirección IP de la puerta de enlace es la asociaciones de túnel a salto siguiente. De forma opcional también se
dirección de la interfaz de túnel en la ubicación del interlocutor remoto. pueden introducir manualmente. La 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.
Múltiples túneles por interfaz de túnel 255

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 del
local de rutas Interfaz de túnel 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 a una sola
interfaz de túnel con traducción de direcciones, consulte “Ajustar una VPN en una
interfaz de túnel para subredes superpuestas” en la página 259.
Figura 72: Múltiples túneles asociados a una única interfaz de túnel con traducción de dirección
El dispositivo de seguridad local 10.0.4.1/24

y todos sus interlocutores NAT-dst 10.0.5.1 -> 10.0.6.1/24
ejecutan la traducción de direcciones IP internas NAT-dst 10.0.7.1 ->
direcciones de destino (NAT-dst) direcciones IP internas
con desplazamiento de IP en el IF 10.0.2.1/24
tráfico VPN entrante y NAT-dst 10.0.3.1 -> vpn2
direcciones IP internas vpn3
traducción de direcciones de
origen (NAT-src) desde la vpn1 10.1.1.1/24
dirección IP de interfaz de túnel NAT-dst 10.1.2.1 ->
de salida con traducción de IF 10.0.2.1/24 direcciones IP
internas
puertos en el tráfico VPN NAT-dst 10.0.3.1 -> vpn251
saliente. direcciones IP internas
10.6.2.1/24
NAT-dst 10.6.3.1->
Dispositivo de direcciones IP
seguridad local vpn751
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 peer’s_tunnel_interface_addr vpn name_str
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 name_str route dst_addr interface tunnel.1 gateway

peer’s_tunnel_interface_addr
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.
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 latidos 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 240).
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 latidos 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 latidos 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 completo (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 activo a inactivo.
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 pueden 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 un 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 “Asociar entradas automáticas en la
tabla de rutas y en la tabla NHTB” en la página 278.

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: peer1, peer2 y peer3. 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 “Asociar entradas automáticas en la
tabla de rutas y en la tabla NHTB” en la página 278.
Figura 73: Interfaz Tunnel.1 asociada con tres túneles VPN
vpn1
Puerta de enlace IKE: peer1, 2.2.2.2
La zona Trust para el dispositivo A no se muestra. Zona Untrust Interfaz de túnel del interlocutor remoto:
10.0.2.1
peer1
LAN vpn2
vpn1
Dispositivo A Puerta de enlace IKE:
vpn2 peer2
LAN peer2, 3.3.3.3
vpn3 Interfaz de túnel del
peer3 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: peer3, 4.4.4.4
10.1.1.1/24 Conjunto de DIP 5: external router
1.1.1.1/24 Interfaz de túnel del interlocutor remoto:
10.0.0.2 - 10.0.0.2 1.1.1.250
Enrutador 10.0.6.1
externo
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:
peer1 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
en OK:
Address Name: corp

Zone: Trust
en OK:
Address Name: oda1

Zone: Trust
en OK:
Address Name: peers

Zone: Untrust
3. VPN
VPN Name: vpn1

Gateway Name: peer1


Service: ANY
VPN Name: vpn2

Gateway Name: peer2




Service: ANY
VPN Name: vpn3

Gateway Name: peer3


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 peer1 address 2.2.2.2 outgoing-interface ethernet3 preshare
set vpn vpn1 gateway peer1 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
Peer1
La siguiente configuración, según se ilustra en la Figura 74, es la que el
administrador remoto del dispositivo de seguridad en la ubicación peer1 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. Peer1
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. Peer1 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

Figura 74: Peer1 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 Peer1 direcciones
Zona Trust
vpn1 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 (Peer1)
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
en OK:

Address Name: lan

Zone: Trust
en OK:
Address Name: oda2

Zone: Trust
en OK:
Address Name: to_corp

Zone: Untrust
en OK:
Address Name: fr_corp

Zone: Untrust
3. VPN
VPN Name: vpn1

Gateway Name: corp


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 (Peer1)
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
Peer2
Dispositivo A. Peer2 lleva a cabo NAT-dst en el tráfico VPN enviado desde el

Figura 75: Peer2
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
Peer2
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 (Peer2)
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
en OK:
Address Name: lan

Zone: Trust
en OK:
Address Name: oda3

Zone: Trust
en OK:

Zone: Untrust
en OK:

Zone: Untrust
3. VPN
VPN Name: vpn2

Gateway Name: corp


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 (Peer2)
1. Interfaces
2. Direcciones
3. VPN
4. Rutas
metric 1
5. Directivas
permit
save

Peer3
dispositivo A. Peer3 lleva a cabo NAT-dst en el tráfico VPN enviado desde el
Figura 76: Peer3
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
Zona Untrust ethernet1 10.1.1.0 – 10.1.1.255
10.1.1.1/24 con desplazamiento
Peer3 de direcciones
Zona Trust
vpn2 desde
dispositivo A
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 (Peer3)
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
en OK:
Address Name: lan

Zone: Trust
en OK:
Address Name: oda4

Zone: Trust
en OK:

Zone: Untrust
en OK:

Zone: Untrust
3. VPN
VPN Name: vpn3

Gateway Name: corp



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 (Peer3)
1. Interfaces
2. Direcciones
3. VPN
4. Rutas
1

5. Directivas
permit
save
Asociar entradas automáticas en la tabla de rutas y en la tabla

NHTB
En la Figura 77 en la página 278, 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. Al utilizar BGP (Border Gateway Protocol), los
interlocutores comunican sus rutas al dispositivo A. Este ejemplo permite el tráfico
VPN desde la ubicación corporativa situada detrás del 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 289 para ver las configuraciones de OSPF.
Figura 77: 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
peer1
vpn1
Dispositivo A
peer2
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 (peer1: “netscreen1”,
peer2: “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 Dispositivo A para
rellenar 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
latidos 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 latidos 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 latidos de IKE.
Si las interfaces de túnel se ejecutan con BGP, el tráfico generado por BGP 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 latidos 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 latidos 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, aunque 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

Gateway Name: peer1
> 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 240.
VPN Name: vpn2

Gateway Name: peer2



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 240.
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
ns-> set vrouter trust-vr protocol bgp 99
ns-> set vrouter trust-vr protocol bgp enable
ns-> set interface tunnel.1 protocol bgp
ns-> set vrouter trust-vr
ns(trust-vr)-> set protocol bgp
ns(trust-vr/bgp)-> set neighbor 2.3.3.1 remote-as 99 outgoing interface tunnel.1
ns(trust-vr/bgp)-> set neighbor 2.3.3.1 enable
ns(trust-vr/bgp)-> set neighbor 3.4.4.1 remote-as 99 outgoing interface tunnel.1
ns(trust-vr/bgp)-> exit
ns(trust-vr)-> exit
5. Directiva
save
Peer1
La siguiente configuración, según se ilustra en la Figura 78 en la página 283, es la
que el administrador remoto del dispositivo de seguridad en la ubicación peer1
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.
Figura 78: Peer1
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.
vpn2 desde Peer1
dispositivo A
2.3.4.0/24
2.3.
WebUI (Peer1)
1. Interfaces
haga clic en OK:
Zone Name: Trust

haga clic en OK:
Zone Name: Untrust

clic en OK:


2. Dirección
en OK:
Address Name: corp

Zone: Untrust
3. VPN
VPN Name: vpn1

Gateway Name: corp


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 (Peer1)
1. Interfaces
2. Dirección
3. VPN
4. Rutas estáticas
metric 1
ns(trust-vr/bgp)-> set neighbor 10.0.0.1 remote-as 99 outgoing interface
tunnel.10
ns(trust-vr)-> exit
6. Directiva
set policy from untrust to trust corp any any permit
save

Peer2
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.
Figura 79: Peer2

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.
Peer2
3.4.5.0/24
Zona Untrust
3.4.
WebUI (Peer2)
1. Interfaces
haga clic en OK:
Zone Name: Trust

haga clic en OK:
Zone Name: Untrust

clic en OK:

2. Dirección
en OK:
Address Name: corp

Zone: Untrust

3. VPN
VPN Name: vpn2

Gateway Name: corp


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 (Peer2)
1. Interfaces
2. Dirección
3. VPN
4. Rutas estáticas
metric 1
ns(trust-vr/bgp)-> set neighbor 10.0.0.1 remote-as 99 outgoing interface
tunnel.20
ns(trust-vr)-> exit
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)
ns-> set vrouter trust-vr protocol ospf
ns-> set vrouter trust-vr protocol ospf enable
ns-> set interface tunnel.1 protocol ospf area 0
ns-> set interface tunnel.1 protocol ospf link-type p2mp
ns-> set interface tunnel.1 protocol ospf enable
ns-> save
WebUI (Peer1)


CLI (Peer1)
ns-> save
WebUI (Peer2)

CLI (Peer2)
ns-> 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.
290 Puertas de enlace VPN redundantes

NOTA: Los grupos VPN no admiten L2TP, L2TP sobre IPSec, acceso telefónico, clave
manual ni tipos de 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, mientas
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 80: 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)
= Latidos 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 81 en la
página 292, 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.
Puertas de enlace VPN redundantes 291

Figura 81: 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:
Latidos 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 292.
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:
Latidos 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 “Comprobar flag TCP SYN” en la página 296), 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.

Latidos de IKE
Los latidos 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 device_m (el “supervisor”) no recibe un determinado número de latidos
(el valor predeterminado es 5) de device_t (el “destino”), device_m llega a la
conclusión de que device_t está inactivo. Device_m 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 295). Device_t también elimina sus SA.
NOTA: La función de latidos 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
device_m pero no en device_t, device_m suprime la transmisión de latidos de IKE
y genera el siguiente mensaje en el registro de eventos: “Heartbeats have been
disabled because the peer is not sending them” (los latidos se han desactivado
porque el interlocutor no los está enviando).
Figura 82: Flujo de latidos IKE en ambos sentidos
Los latidos de IKE deben fluir en ambos sentidos a través del túnel VPN.
Para definir el intervalo de latidos de IKE y el umbral para un túnel VPN específico
(el valor predeterminado es 5), realice los siguientes pasos:
WebUI
VPNs > AutoKey Advanced > Gateway > Edit (para la puerta de enlace
cuyo umbral de latidos 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 name_str heartbeat hello number
set ike gateway name_str heartbeat threshold number
Detección de interlocutor muerto (DPD)

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 latidos IKE (que se
describe anteriormente). No obstante, no se pueden utilizar ambas funciones
simultáneamente. Además, el latido IKE puede utilizarse como un ajuste global, que
afecta a todas las puertas de enlace IKE configuradas en el dispositivo. El ajuste de
latido 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 mediante el envío de 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, únicamente 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 SAs 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 latido de IKE, el número predeterminado
de transmisiones es 5 veces, con un rango permitido de 1-128 reintentos. Un
ajuste ‘cero’ desactiva el DPD.
En el ejemplo siguiente, se crea una puerta de enlace que utiliza un intervalo de
DPD de cinco segundos.
WebUI
VPNs > AutoKey Advanced > Gateway > Edit: Cree una puerta de enlace al
introducir 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
VPNs > 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á inactivo, el supervisor deja de enviar latidos 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 83: Intentos repetidos de negociación de fase 1 IKE
Intentos de
negociación de fase 1
Supervis 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
VPNs > 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 name_str heartbeat reconnect number
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 84 en la página 296 muestra el proceso al que se somete un miembro de

un grupo VPN cuando la ausencia de latidos de una puerta de enlace de destino
sobrepasa el umbral de fallo.

Figura 84: Conmutación por error y luego recuperación
Supervisor Destino
Latidos IKE en ambos sentidos
El destino deja de enviar latidos 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 latidos IKE habilitados.
Las negociaciones de fase 1 y fase 2 IKE tienen éxito, el túnel se vuelve

a activar y se realiza una conmutación por recuperación de la VPN (si
su peso da preferencia a otros miembros del grupo VPN).
Comprobar flag TCP SYN

Para que se produzca una conmutación por error VPN gradual, es necesario
ocuparse de 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 flag SYN está activado en el encabezado
del paquete. Como este paquete en realidad forma parte de una sesión existente, no
tiene el flag SYN activado. En consecuencia, la nueva puerta de enlace rechaza el
paquete. Con la comprobación de flag 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 flag SYN para las
sesiones TCP en túneles VPN del siguiente modo:
WebUI
No es posible inhabilitar la comprobación de flag SYN mediante la WebUI.
CLI
unset flow tcp-syn-check-in-tunnel

NOTA: De forma predeterminada, la comprobación de flag SYN está habilitada.
Crear 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 y peso de
dispositivo dispositivo (zona Trust) (zona Untrust) grupo VPN
Empresa Monitor1 ethernet1, 10.10.1.1/24 ethernet3, 1.1.1.1/24, (GW) 1.1.1.2 ––
Centro de datos Target1 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 Target2 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 85: Puertas de enlace VPN redundantes
Untrust, ethernet3 Trust, ethernet1

2.2.2.1/24 10.1.1.1/16
Destino1
Ubicación del centro
10.1.0.0/16 de datos primario
Sitio corporativo Línea punto a punto

para la réplica de
Monitor1 datos del sitio primario
10.10.1.0/24 Internet 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
en OK:
Address Name: in_trust
Zone: Trust
en OK:
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

Heartbeat:
Hello: 3 Seconds
Reconnect: 60 seconds
Threshold: 5

VPN Name: to_target1

Remote Gateway: Predefined: (seleccione), target1

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

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 (Target1)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Direcciones
en OK:
Address Name: in_trust

Zone: Trust
en OK:
Address Name: corp

Zone: Untrust
3. VPN
y haga clic en OK:
Gateway Name: monitor1


Preshared Key: SLi1yoo129



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: Tunnel
Tunnel VPN: monitor1
WebUI (Target2)
NOTA: Siga los pasos de configuración de Target1 para configurar Target2, 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 (Target1)
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 (Target2)
NOTA: Siga los pasos de configuración de Target1 para configurar Target2, 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.
Crear 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.
Figura 86: VPN adosadas
Zona
X1 Zona
X2
Radio A Radio B
VPN1 VPN2
Consulta
de
directivas
Concentrador (hub)
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 de VPN.
El administrador del dispositivo concentrador puede controlar completamente

el tráfico VPN entre los puntos de perímetro. Por ejemplo:
Crear VPN adosadas 303

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.
Puede permitir el acceso a C del tráfico procedente de A, pero denegar el

acceso a A del tráfico procedente de C.
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 name_str (donde name_str 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.
El ejemplo siguiente es parecido al de “Crear VPN radiales” en la página 310,

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 87, 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.
304 Crear VPN adosadas

Figura 87: 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
Zona Untrust Dominio de
ethernet3, IP 123.1.1.1/24 VPN1 enrutamiento
Trust-VR Interfaz: Untrust-VR
Dominio de enrutamiento 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: Tokyo

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: Paris

Service: ANY
5. Rutas

Next Hop Virtual Router Name: (seleccione), untrust-vr

6. Direcciones
en OK:
Address Name: Tokyo LAN

Zone: X1
en OK:
Address Name: Paris LAN

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), Tokyo 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), Tokyo 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 Tokyo address 110.1.1.1 outgoing-interface ethernet3 preshare
set vpn VPN1 gateway Tokyo 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 “Tokyo 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 “Tokyo LAN” “Paris LAN” any permit
set policy top from x2 to x1 “Paris LAN” “Tokyo 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 zone_name zone are in NAT

mode. Traffic might not pass through them!

Crear 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 88: 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.
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.
310 Crear VPN radiales

Figura 89: 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

clic en OK:

Zone (VR): Untrust (untrust-vr)
Interface: ethernet3 (untrust-vr)
Crear VPN radiales 311

clic en OK:

VPN Name: VPN1

Gateway Name: Tokyo

Service: ANY
VPN Name: VPN2

Gateway Name: Paris

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
en OK:
Address Name: Paris

Zone: Untrust
4. VPN
VPN Name: VPN1

Gateway Name: New York

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
en OK:
Address Name: Tokyo

Zone: Untrust
4. VPN
VPN Name: VPN2

Gateway Name: New York

Service: ANY
5. Rutas



Interface: tunnel.1

6. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Tokyo
Service: ANY
Action: Permit
CLI (Nueva York)

unset zone untrust block
2. Interfaces
set ike gateway Tokyo address 2.2.2.2 outgoing-interface ethernet3 preshare
set vpn VPN1 gateway Tokyo 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 “New York” address 1.1.1.1 outgoing-interface ethernet3 preshare
set vpn VPN1 gateway “New 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 Tokyo 10.2.2.0/24
4. VPN
set ike gateway “New York” address 1.1.1.1 outgoing-interface ethernet3 preshare
set vpn VPN2 gateway “New York” sec-level compatible
5. Rutas
6. Directivas
set policy from trust to untrust any Tokyo any permit
set policy from untrust to trust Tokyo any any permit
save

Índice
Números conjuntos de DIP
3DES .................................................................................6 interfaces extendidas ............................................141
NAT para VPNs ......................................................141
A contenedores ................................................................187
Advanced Encryption Standard (AES) ...........................7 CRL
AES ....................................................................................7 véase Lista de revocación de certificados
AH..................................................................................3, 6
Ajustes de L2TP, DNS ..................................................211 D
archivos MIB, importación .........................................252 DES ....................................................................................6
asociaciones de seguridad Diffie-Hellman ................................................................10
véase SAs Direcciones de protocolo de Internet (IP)
ataques véase direcciones IP
repetición .................................................................12 direcciones IP
autenticación extendidas ..............................................................141
algoritmos ..........................................6, 51, 55, 58, 61 directivas
VPN bidireccionales ..............................................127
C DN .................................................................................183
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, 51, 54 a 61
carga .........................................................................28 ESP ................................................................................3, 6
carga de CRL ............................................................23 encriptación y autenticación ............................54, 61
local...........................................................................25 sólo autenticación ...................................................54
petición .....................................................................26 sólo encriptación .....................................................54
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 .....................................................................208, 211 Fase 2 ..............................................................................11
clave manual propuestas ................................................................11
administración...........................................................7 propuestas, predefinidas ........................................11
clave previamente compartida ......................................8 firma digital ....................................................................20
claves flujo de paquetes
manuales ........................................................120, 126 VPN basada en directivas ...............................69 a 70
previamente compartidas ....................................160 VPN basada en rutas .......................................64 a 69
claves previamente compartidas ...............................160 VPN de entrada ...............................................67 a 69
código de autenticación basado en hash ......................6 VPN de salida ...........................................................65
comodines ....................................................................186
comprobación contra reprocesamiento H
de paquetes ...........................................................53, 59 HMAC ................................................................................6
confidencialidad directa perfecta
véase PFS
Índice IX-I
I configuración voluntaria.......................................206
ID de proxy .................................................................... 12 desencapsulado .....................................................209
coincidencia ....................................................... 64, 71 encapsulado ...........................................................208
identificación IKE de grupo Keep Alive ......................................................216, 221
certificados .................................................. 183 a 192 L2TP en solitario sobre Windows 2000 .............207
claves previamente compartidas .............. 192 a 198 modo de funcionamiento .....................................208
IDs de proxy parámetros predeterminados ..............................211
VPNs y NAT ................................................. 141 a 142 señal hello ......................................................216, 221
IKE................................................................. 7, 88, 97, 160 servidor de red
ID de proxy .............................................................. 12 véase LNS
ID IKE, Windows 200 ................................... 219, 227 servidor RADIUS....................................................211
ID local, ASN1-DN ................................................. 186 servidor SecurID ....................................................211
ID remota, ASN1-DN ............................................ 186 soporte de ScreenOS ............................................207
identificación IKE .............................. 51 a 53, 58 a 59 túnel ........................................................................213
identificación IKE de grupo, comodines ............ 186 L2TP sobre IPSec .............................................4, 213, 218
identificación IKE de grupo, container ............... 187 bidireccional ..........................................................208
latidos ..................................................................... 293 túnel ........................................................................213
mensajes de saludo .............................................. 293 LAC ................................................................................205
propuestas de fase 1, predefinidas ......................... 9 NetScreen-Remote 5.0..........................................206
propuestas de fase 2, predefinidas ....................... 11 Windows 2000 ......................................................206
puertas de enlace redundantes ................. 290 a 303 Layer 2 Tunneling Protocol
recomendaciones de ID IKE .................................. 72 véase L2TP
usuario de identificación IKE Lista de revocación de certificados........................23, 35
compartida ................................................ 198 a 203 carga .........................................................................23
usuario de identificación IKE de grupo .... 183 a 198 LNS ................................................................................205
infraestructura de claves públicas
véase PKI M
intercambio de claves de Internet mantenimiento de conexión
véase IKE frecuencia, NAT-T de ............................................238
interfaces manual keys (claves manuales)..........................120, 126
extendidas ............................................................. 141 MD5...................................................................................6
nula ........................................................................... 87 Message Digest versión 5 (MD5)....................................6
IPSec MIP, VPNs .....................................................................141
AH ................................................................... 2, 54, 60 modo de transporte.................................4, 208, 213, 218
ESP .................................................................. 2, 54, 60 Modo de túnel ..................................................................4
firma digital ............................................................. 20 modo dinámico..............................................................10
L2TP sobre IPSec ...................................................... 4 Modo principal ...............................................................10
modo de transporte .......................... 4, 208, 213, 218 modos
Modo de túnel ........................................................... 4 Criptografía Fase 1 ............................................49, 56
negociación de túnel................................................. 9 Dinámico ..................................................................10
SAs ................................................................ 2, 8, 9, 11 operativo L2TP ......................................................208
SPI ............................................................................... 2 Principal ...................................................................10
túnel ............................................................................ 2 Transporte ....................................4, 60, 208, 213, 218
Túnel .........................................................................60
K túnel ............................................................................4
keepalive módulo ............................................................................11
L2TP ........................................................................ 216
N
L NAT
L2TP .................................................................... 205 a 230 IPSec y NAT ...........................................................232
autenticado del túnel Windows 2000 ......... 216, 221 servidores NAT ......................................................232
bidireccional .......................................................... 208 NAT-dst
concentrador de accesos VPNs .......................................................................141
véase LAC NAT-src
configuración obligatoria ..................................... 205 VPNs .......................................................................144
IX-II Índice
Índice
NAT-T ................................................................... 232 a 240 protocolos

frecuencia de mantenimiento de conexión .......238 CHAP.......................................................................208
habilitar ..................................................................239 PAP..........................................................................208
iniciador y respondedor .......................................238 PPP ..........................................................................206
obstáculos para VPN .............................................235 puertas de enlace redundantes ........................290 a 303
Paquete IKE ...........................................................235 comprobación de flag TCP SYN ...........................296
Paquete IPSec ........................................................236 procedimiento de recuperación ..........................295
sondeos de NAT .......................................... 233 a 234
NAT-Traversal R
véase NAT-T RADIUS
NetScreen-Remote L2TP ........................................................................211
interlocutor dinámico ...................................166, 173 ruta nula ..........................................................................87
opción NAT-T .........................................................232
VPN AutoKey IKE ..................................................160
S
SAs ...........................................................................8, 9, 11
nombre completo (DN) ...............................................183
SCEP (Simple Certificate Enrollment Protocol) ..........30
Norma de encriptación de datos (DES) .........................6
Secure Hash Algorithm-1
O véase SHA-1
OCSP (Online Certificate Status Protocol)...................35 SecurID
cliente .......................................................................35 L2TP ........................................................................211
servidor de respuesta .............................................35 Seguridad IP
opción de reencriptación, supervisión de VPN ........241 véase IPSec
opciones criptográficas ......................................... 48 a 62 SHA-1 ................................................................................6
acceso telefónico ............................................. 56 a 62 SNMP
algoritmos de autenticación.................51, 55, 58, 61 archivos MIB, importación ...................................252
algoritmos de encriptación ...................... 51 a 58, 61 supervisión de VPN ...............................................252
comprobación contra reprocesamiento de supervisión de VPN ...........................................240 a 252
paquetes ...........................................................53, 59 cambios de estado ........................................240, 244
ESP ......................................................................54, 61 dirección de destino ....................................242 a 245
identificación IKE .............................. 51 a 53, 58 a 59 dirección de destino, XAuth .................................243
longitudes de bits de los certificados ..............50, 57 directivas ................................................................243
métodos de administración de claves ..................49 diseño de rutas ........................................................72
modo de transporte ................................................60 interfaz de salida .........................................242 a 245
Modo de túnel ..........................................................60 opción de reencriptación..............................241, 258
modos de fase 1 ................................................49, 56 peticiones de eco ICMP ........................................252
PFS ......................................................................53, 59 SNMP ......................................................................252
protocolos IPSec ................................................54, 60
punto a punto .................................................. 48 a 55 T
recomendaciones VPN de acceso telefónico .......62 tabla NHTB .........................................................254 a 258
asignación de rutas a túneles ...............................255
recomendaciones VPN punto a punto ..................55
entradas automáticas ............................................257
tipos de autenticación.......................................50, 57
entradas manuales ................................................257
P esquema de direccionamiento ............................256
PAP ........................................................................208, 211 TCP
par de claves pública/privada .......................................23 comprobación de flag SYN ...................................296
Password Authentication Protocol Triple DES
véase PAP véase 3DES
PFS ......................................................................12, 53, 59
PKI ...................................................................................22 U
PPP ................................................................................206 UDP
propuestas encapsulación NAT-T ............................................232
Fase 1 ...................................................................9, 70 suma de comprobación ........................................237
Fase 2 .................................................................11, 70 usuarios
protección contra reprocesamiento de paquetes.......12 identificación IKE compartida ...................198 a 203
protocolo punto a punto identificación IKE de grupo ........................183 a 198
véase PPP
Índice IX-III
V
Verisign ........................................................................... 35
VPN
AutoKey IKE .............................................................. 7
consejos de configuración.............................. 70 a 72
Diffie-Hellman, grupos ........................................... 10
directiva para bidireccionales .............................. 127
Fase 1 ......................................................................... 9
Fase 2 ....................................................................... 11
flujo de paquetes ............................................. 64 a 70
grupos redundantes, procedimiento de
recuperación........................................................ 295
grupos VPN ............................................................ 291
ID de proxy, coincidencia ...................................... 71
intercambio Diffie-Hellman ................................... 10
modo dinámico ....................................................... 10
Modo principal ........................................................ 10
múltiples túneles por interfaz de túnel ..... 254 a 288
opciones criptográficas .................................. 48 a 62
protección contra reprocesamiento
de paquetes ........................................................... 12
puertas de enlace redundantes ................. 290 a 303
SAs .............................................................................. 8
supervisión y reencriptación de VPN ................. 241
túnel siempre activo ............................................. 241
VPN AutoKey IKE ............................................................. 7
administración .......................................................... 7
VPN basada en directivas ............................................. 63
VPN basadas en rutas ........................................... 63 a 64
VPNs
alias FQDN ............................................................. 132
basadas en rutas o basadas en directivas ............ 63
FQDN para puertas de enlace ................... 131 a 141
MIP.......................................................................... 141
modo de transporte .................................................. 4
NAT para direcciones superpuestas.......... 141 a 152
NAT-dst................................................................... 141
NAT-src ................................................................... 144
W
WINS
ajustes de L2TP ..................................................... 211
X
XAuth
supervisión de VPN ............................................... 243
IX-IV Índice
Volumen 6:
Voz sobre protocolo de Internet (VoIP)

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Copyright Notice
without notice.
FCC Statement
Disclaimer
Writers: Anita Davey, Jozef Wroblewski

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 ....................................................... 4
Ejemplo: Llamadas entrantes con NAT ......................................................7
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
ALG: puerta de enlace en la capa de aplicación ....................................... 17
SDP ......................................................................................................... 18
Crear ojos de aguja .................................................................................. 19
Tiempo de espera por inactividad de la sesión ........................................ 21
Protección contra ataques SIP .................................................................22
Ejemplo: SIP Protect Deny ................................................................ 22
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
Terminar la llamada ................................................................................ 26
Mensajes de llamada Re-INVITE .............................................................. 26
Temporizadores de sesiones de llamadas ................................................ 26
Cancelar la llamada ................................................................................. 27
Bifurcación ..............................................................................................27
Mensajes SIP ........................................................................................... 27
Encabezados SIP ..................................................................................... 27
Contenido iii
Cuerpo SIP............................................................................................... 29
Supuesto de NAT con el protocolo SIP ..................................................... 30
Ejemplos ........................................................................................................ 32
Admisión de llamadas SIP entrantes utilizando el registrador SIP............ 33
Ejemplo: Llamada entrante (DIP de interfaz)..................................... 34
Ejemplo: Llamada entrante (conjunto de DIP) ................................... 37
Ejemplo: Llamada entrante con MIP ................................................. 39
Ejemplo: Proxy en la zona privada....................................................41
Ejemplo: Proxy en la zona pública ....................................................43
Ejemplo: Zona triple, proxy en DMZ ................................................. 46
Ejemplo: Untrust intrazonal .............................................................. 49
Ejemplo: Trust intrazonal .................................................................. 53
Ejemplo: VPN de malla completa para SIP ........................................ 55
Administrar el ancho de banda para servicios de VoIP ............................ 60
Capítulo 3 Puerta de enlace en la capa de aplicación del Protocolo

de control de la puerta de medios 63
Vista general .................................................................................................. 63
Seguridad de MGCP........................................................................................ 64
Protocolo MGCP ............................................................................................. 64
Entidades en MGCP ................................................................................. 64
Punto final ........................................................................................ 65
Conexión .......................................................................................... 65
Llamada ............................................................................................ 65
Agente de llamada ............................................................................ 65
Comandos ............................................................................................... 66
Códigos de respuesta............................................................................... 69
Ejemplos ........................................................................................................ 70
Puerta de enlace en el domicilio de los abonados:
agente de llamada en el ISP .............................................................. 70
Servicio alojado en el ISP......................................................................... 73
Índice ........................................................................................................................IX-I
iv Contenido
El Volumen 6: Voz sobre protocolo de Internet (VoIP) describe las puertas de enlace de
la capa de aplicación (ALG) de VoIP admitidas e incluye los siguientes capítulos:
En “Puerta de enlace en la capa de aplicación H.323” se describe el protocolo

H.323 y proporciona ejemplos para la configuración de la puerta de enlace en
la capa de aplicación (Aplication Layer Gateway o ALG) en el dispositivo de
“Puerta de enlace de la capa de aplicación del protocolo de inicio de sesión”

describe la ALG del protocolo de inicio de sesión (Session Initiation Protocol
SIP).
“Puerta de enlace en la capa de aplicación del Protocolo de control de la puerta

de medios” ofrece una vista general de la ALG del protocolo de control de la
puerta de medios (Media 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.

“Convenciones de la interfaz de línea de comandos (CLI)” en la página vi
“Convenciones para las ilustraciones” en la página vii
“Convenciones de nomenclatura y conjuntos de caracteres” en la página viii
“Convenciones de la interfaz gráfica (WebUI)” en la página ix
Convenciones del documento v


En ejemplos:


set admin user name1 password xyz
En texto:
vi Convenciones del documento



10.1.1.0/24)

Internet

dinámicas (DIP)

Equipo portátil
Interfaz de túnel
Servidor
Túnel VPN
Concentrador (hub)
Enrutador
Teléfono IP
Conmutador








de configuración:

en OK:
Zone: Untrust




x Documentación de Juniper Networks

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 el dispositivo de seguridad de Juniper Networks. Contiene las
“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) del protocolo H.323, permite
asegurar la comunicación de voz sobre IP (“Voice-over-IP” o VoIP) entre equipos
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 4: Protocolo H.323
Equipo selector Equipo selector

Permitir
Zona Trust Internet

Permitir
Punto final Punto final Zona Untrust
NOTA: En la ilustración de este capítulo se utilizan teléfonos IP con fines ilustrativos,

aunque pueden configurarse otros equipos que utilicen el protocolo VoIP, como
dispositivos multimedia de NetMeeting.
Vista general 1
Ejemplos
Esta sección contiene los siguientes escenarios 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 4
“Ejemplo: Llamadas entrantes con NAT” en la página 7
“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 ruta
(Route). Las dos zonas de seguridad Trust y Untrust se encuentran en el dominio de
Figura 5: Equipo selector H.323 en la zona Trust
Equipo Internet
selector
Teléfonos IP de Teléfono IP de
punto final punto final
2.2.2.5
WebUI
1. Dirección
en OK:
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 ruta 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 ruta. Las dos zonas de seguridad Trust y Untrust se
Figura 6: Equipo selector H.323 en la zona Untrust
LAN Internet
IP_Phone
IP_Phones 2.2.2.5/32
WebUI
1. Direcciones
en OK:
Address Name: IP_Phone

Zone: Untrust
en OK:
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
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.
4 Ejemplos
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 7: 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
MIP 1.1.1.25 -> 10.1.1.25 Puerta de
IP_Phone1 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
en OK:
Address Name: IP_Phone1

Zone: Trust
en OK:

Zone: Trust
en OK:
Ejemplos 5

Zone: Untrust
3. Direcciones IP asignadas
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
haga clic en OK:
Source Address:
Service: H.323
Action: Permit
haga clic en OK:
Source Address:
6 Ejemplos

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
Ejemplo: Llamadas entrantes con NAT

En este ejemplo configurará el dispositivo de seguridad para aceptar llamadas
entrantes sobre 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.
Ejemplos 7
Figura 8: 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(id_num) 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

2. DIP con NAT entrante
Network > Interface > Edit (para ethernet3) > DIP > New: Introduzca los
ID: 5
Incoming NAT: (seleccione)
3. Direcciones
Objects > Addresses > List > New (para Trust): Introduzca los siguientes datos
y haga clic en OK:
8 Ejemplos
Address Name: IP_Phones1

Zone: Trust
Objects > Addresses > List > New (para Untrust): Introduzca los siguientes

Zone: Untrust
4. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), IP_Phones1
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
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
Ejemplos 9
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 9: Equipo selector en la zona Untrust
ethernet1 ethernet3 Equipo selector

10.1.1.1/24 1.1.1.1/24 2.2.2.25
Modo NAT Puerta de 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

2. Direcciones
en OK:

Zone: Trust
en OK:

Zone: Untrust
10 Ejemplos
en OK:

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
haga clic en OK:
Source Address:
Service: H.323
Action: Permit
haga clic en OK:
Source Address:
Service: H.323
Action: Permit
Ejemplos 11
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 conforme al estándar 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.
Esencialmente, SIP se utiliza para distribuir la descripción de la sesión y, durante

ésta, para negociar y modificar sus parámetros. SIP también se utiliza para terminar
una sesión multimedia.
El usuario incluye la descripción de la sesión en una petición INVITE o ACK. La

descripción de la sesión indica el tipo de multimedia de la sesión, por ejemplo, voz
o vídeo. Para describir la sesión, SIP puede utilizar diversos protocolos de
descripción; NetScreen sólo admite el protocolo de descripción de la sesión (SDP).
SDP proporciona la información necesaria para que un sistema pueda unirse 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
Vista general 13
recibir las secuencias multimedia (“streams”), 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 “SDP” 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 (“User Agent Client” o UAC), que envía
peticiones SIP de parte del usuario, y un servidor del agente del usuario (“User
Agent Server” o 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 29.
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 invitació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
encabezado Via:, From:, To:, Call-ID:, Contact:, Route:, y Record-Route: se
modifican según consta en la Tabla 2 en la página 29.
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 SIP traduce los
campos From:, Via: y Call-ID: según se muestra en la Tabla 2 en la página 29.
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 29.
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 29.
14 Vista general
Capítulo 2: Puerta de enlace de la capa de aplicación del protocolo de inicio de sesión
REGISTER: Un usuario envía una petición REGISTER a un servidor de registro

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 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 SIP recibe la petición REGISTER saliente, traduce
las direcciones IP de los campos To:, From:, Via:, Call-ID: y Contact:.
campos de encabezado. 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
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 29.
Notify: Se envía para informar a los abonados sobre los cambios en el estado al
que están abonados. En el modo NAT, la dirección IP en el campo de
encabezado Request-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 encabezado Via:, From:, To:, Call-ID:, Contact:, Route:, y
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 29.
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 SIP asigna 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
puertos se almacena en la tabla ALG NAT y se reutiliza para realizar la
traducción.
Vista general 15
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 29.
1xx, 202, 2xx, 3xx, 4xx, 5xx, 6xx Response Codes: 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 29.
Clases de respuestas SIP

Las respuestas SIP proporcionan la información de estado sobre las transacciones
de SIP e incluyen un código de respuesta y una explicación. Las respuestas SIP se
agrupan en las siguientes clases:
Informativos (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 de SIP actuales, las que se
encuentran en los dispositivos de seguridad NetScreen compatibles.
Tabla 1: Respuestas de SIP
Código de Código de Código de

Clase respuesta-Explicación respuesta-Explicación respuesta-Explicación
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
Código de Código de Código de

Clase respuesta-Explicación respuesta-Explicación respuesta-Explicación
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)
ALG: puerta de enlace en la capa de aplicación

Existen dos tipos de tráfico SIP, el de señalización y 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 UDP o TCP. La secuencia multimedia transporta los datos (por
ejemplo, de audio), y utiliza protocolos de la capa de aplicación tales como
protocolo de transporte en tiempo real (“Real-time Transport Protocol” o “RTP”)
sobre UDP.
Los dispositivos de seguridad 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 de direcciones estáticas para controlar el tráfico multimedia. En
este caso, el dispositivo de seguridad invoca la ALG de SIP. la ALG de 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 pequeños “ojos de aguja” por los
que permitir 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
determinado tráfico exclusivo.
La ALG 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. La
ALG SIP NetScreen 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 NetScreen 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 SIP para abrir “ojos de aguja” por los que entregar la secuencia multimedia. La
ALG 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 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 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 SIP registra en
una tabla de ojos de aguja. La ALG 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 SIP
permite de todos modos que pase a través del cortafuegos, pero genera un
mensaje para el registro informando al usuario que no puede procesar el paquete.
Si SDP está encriptado, la ALG 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.
SDP
Protocolo de descripción de la sesión (“Session Description Protocol”). 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=”.
De los muchos campos presentes en la descripción SDP, dos son particularmente

útiles para la ALG SIP porque contienen la información de la capa de transporte.
Ambos campos son los siguientes:
18 Vista general
c= 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 (unicast) como dirección IP de destino
(conexión).
NOTA: Generalmente, la dirección IP de destino también puede ser una dirección IP

multicast, pero por el momento NetScreen no admite multicast con SIP.
Si la dirección IP de destino es una dirección IP unicast, la ALG 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= 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 multimedia (y no su origen).
La lista de formatos 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 RTCP (“Real-time
Transport Control Protocol” o protocolo de control del transporte en tiempo
real) correspondiente. Por lo tanto, siempre que una secuencia multimedia
utilice RTP, la ALG SIP debe reservar puertos (crear ojos de aguja) tanto para el
tráfico RTP como 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

multicast, pero por el momento ScreenOS no admite multicast con SIP.
Crear 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):
Vista general 19
En primer lugar, el analizador sintáctico de la ALG 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 SIP la utiliza para crear un ojo de aguja para
el medio.
Si no hay ningún campo “c=” a nivel de medio, el analizador sintáctico de la

ALG SIP extrae la dirección IP del campo “c=” en el nivel de sesión y la ALG SIP
la utiliza para crear un ojo de aguja para el medio. 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 siguientes muestra la información que la ALG 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 esta fórmula: número de puerto RTP
+ uno.
Tiempo de vida: 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 SIP elimina el ojo de aguja.
Cuando un paquete atraviesa el ojo de aguja dentro del periodo de vigencia,

inmediatamente después la ALG SIP elimina el ojo de aguja para el sentido de
procedencia del paquete.
La Figura 10 describe una configuración de llamada entre dos clientes SIP y

cómo la ALG SIP crea ojos de aguja para permitir el tráfico RTP y RTCP. La
ilustración presupone 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 10: Ajuste de llamada de ALG de 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 al proxy SIP
una petición INVITE destinada al Cliente B
2. Por SDP, la ALG SIP
a través del puerto 5060 en el dispositivo
crea un ojo de aguja para
de seguridad (SDP 1.1.1.1:2000) 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 a través 4. El Cliente B contesta al proxy SIP con una
del puerto 5060 en el dispositivo de respuesta "Ringing" (llamando)
seguridad
6. El Cliente B envía una respuesta 200 OK al
7. Por SDP, la ALG SIP
proxy SIP en respuesta a la petición INVITE
8. El proxy SIP transmite una respuesta 200 crea un ojo de aguja para
(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 seguridad 10. El proxy SIP transmite la respuesta 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 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 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.
Vista general 21
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.
Existen dos tipos de tiempo de espera por inactividad que determinan la duración
de un grupo:
Signaling Inactivity Timeout: 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).
Media Inactivity Timeout: 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 SIP, tanto malévolas como por error
del cliente o del servidor, denegado 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 compara
posteriormente todas las peticiones INVITE realizadas con el contenido de esta
tabla y, durante un número configurable de segundos (el predeterminado es tres),
descarta cualquier paquete que coincida con entradas de 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 solo
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 cinco segundos,
transcurridos los cuales el dispositivo de seguridad reanuda el reenvío de peticiones
INVITE procedentes de esos orígenes.
WebUI
Para proteger servidores proxy SIP contra inundaciones causadas por peticiones
INVITE, debe utilizar la CLI.
22 Vista general
CLI
set sip protect deny dst-ip 1.1.1.3/24
set sip protect deny timeout 5
save
Ejemplo: Tiempos de espera por inactividad de señalización o de

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 sip signaling-inactivity-timeout 30000
set 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 80000 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. Para obtener más información sobre la protección contra
inundaciones de UDP y cómo determinar los ajustes más eficaces, consulte
“Inundación UDP” en la página 4-53.
WebUI
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 de
sesiones basadas en sus orígenes y destinos” en la página 4-33.
WebUI
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 SIP contiene la información del protocolo de descripción de sesión (“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 de 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 de la pared de fuego 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 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 un nuevo
mensaje, por ejemplo un ACK o 200 OK, 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 de 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 NetScreen. Via:, Contact:, Route:, y Record-Route: los
campos de encabezado de SIP, si están presentes, también se vinculan a la
dirección IP de la pared de fuego. ALG almacena estas asignaciones para utilizarlas
en retransmisiones y para los mensajes de respuesta SIP.
A continuación, la ALG 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 de SDP y de
los campos de encabezado Via:, Contact: y Record- Route: Los ojos de aguja
también permiten que los paquetes entrantes alcancen Contact:, Via: y
Record-Route:. direcciones IP y puertos. Al procesar el tráfico de retorno, 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 32). 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 SIP.
El ALG examina el mensaje de petición SIP (inicialmente un INVITE) y, basándose

en la información de SDP, abre las puertas para los medios salientes. Cuando llega
un mensaje de respuesta OK 200, la ALG 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 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 SIP. Si el mensaje
contiene información de SDP, la ALG 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. ALG supervise 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 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.
Terminar 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 desmontaje 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

El ALG SIP utiliza el valor Session-Expires para caducar una sesión si no se recibe
ningún mensaje Re-INVITE o UPDATE. la 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 SIP utiliza valores de tiempo de espera restrictivos
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 un ALG de SIP.
Implementaciones pobres del proxy SIP no pueden procesar Record-Route y

nunca envían un mensaje BYE.
Fallos de red impiden la recepción de un mensaje BYE.
Cancelar la llamada
Cualquier interlocutor puede cancelar una llamada enviando un mensaje CANCEL.
En el momento de recibir un mensaje CANCEL, la ALG 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 una 200.
Bifurcación
La bifurcación permite a un proxy SIP enviar un solo mensaje INVITE a múltiples
destinos simultáneamente. Cuando llegan los diferentes mensajes de respuesta 200
OK para esa única llamada, la ALG 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 siguiente 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/D
Contact: Reemplazar dirección local por dirección ALG
Record-Route: Reemplazar dirección local por dirección ALG
Route: Ninguna
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/D
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 “SDP” en la página 18.
Supuesto de NAT con el protocolo SIP

En la Figura 11, 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 negrilla.
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 11: 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
6.6.6.1 IP
52002/52003 Cualquier
45002/45003 puerto
Ojo de aguja Via/Contact
5.5.5.1 Cualquier
6.6.6.1 IP
1234 Cualquier
5060 puerto

Figura 12: 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 6.6.6.2
Cualquier 5060
puerto
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:
“Admisión de llamadas SIP entrantes utilizando el registrador SIP” en la

página 33
“Ejemplo: Llamada entrante con MIP” en la página 39
“Ejemplo: Proxy en la zona privada” en la página 41
“Ejemplo: Proxy en la zona pública” en la página 43
“Ejemplo: Zona triple, proxy en DMZ” en la página 46
“Ejemplo: Untrust intrazonal” en la página 49
“Ejemplo: Trust intrazonal” en la página 53
“Ejemplo: VPN de malla completa para SIP” en la página 55
32 Ejemplos
Admisión 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:
del mensaje REGISTER contienen la URI de la dirección del registro y al menos una
URI de contacto, según muestra la ilustración siguiente. 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
conjuntos de 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 conjuntos de DIP se recomienda para redes más
grandes o entornos empresariales.
NOTA: La admisión de llamadas entrantes usando DIP de interfaz o un conjunto de DIP

sólo se permite en los servicios SIP y H.323.
Para llamadas entrantes, actualmente los dispositivos de seguridad sólo admiten

UDP y TCP. En la actualidad, tampoco se admite la resolución de nombres de
dominio, por lo que las URI deben contener direcciones IP, según muestra la
Figura 13.
Ejemplos 33
Figura 13: 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 a
To: ph1@5.5.5.1 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 CSeq 1 INVITE
To: ph1@5.5.5.1 valor del tiempo 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. Usted
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 32.
34 Ejemplos
Figura 14: 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
en OK:
Address Name: phone1

Zone: Trust
en OK:

Zone: Untrust
en OK:
Address Name: proxy

Ejemplos 35

Zone: Untrust
Network > Interface > Edit (para ethernet3) > DIP > New: Seleccione la
opción Incoming NAT 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
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
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
36 Ejemplos
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. Usted configurará un conjunto de 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
conjunto de 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 32.
Figura 15: 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
phone1 1.1.1.20 ->1.1.1.40 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

2. Direcciones
en OK:

Zone: Trust
Ejemplos 37
en OK:

Zone: Untrust
en OK:
Address Name: proxy

Zone: Untrust
3. Conjunto de DIP con NAT entrante
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
haga clic en OK:
Source Address
Destination Address
Address Book Entry: (seleccione), DIP(5)
Service: SIP
Action: Permit
38 Ejemplos
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. Usted
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 34
y “Ejemplo: Llamada entrante (conjunto de DIP)” en la página 37), 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.
Figura 16: Llamada entrante con MIP
ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Trust Untrust
LAN Internet
Servidor proxy
Dispositivo
phone1 virtual MIP en
ethernet3 phone2
10.1.1.3 1.1.1.4
1.1.1.1/24
Ejemplos 39
WebUI
1. Interfaces
haga clic en Apply:
Zone: Trust
Interface Mode: NAT
haga clic en OK:
Zone: Untrust
2. Direcciones
en OK:

Zone: Trust
en OK:

Zone: Untrust
en OK:
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:
Address Book Entry: (seleccione), any
40 Ejemplos
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.
Figura 17: 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:
Ejemplos 41
Zone: Trust
Interface Mode: NAT
haga clic en OK:
Zone: Untrust
2. Direcciones
en OK:

Zone: Trust
en OK:

Zone: Untrust
en OK:
Address Name: proxy

Zone: Trust
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:
Address Book Entry: (seleccione) any
Address Book Entry: (seleccione) phone2
Service: SIP
Action: Permit
42 Ejemplos
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
Ejemplo: Proxy en la zona pública

phone2 y el servidor proxy en la interfaz ethernet3 de la zona (pública) Untrust.
Usted 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 37 y “Ejemplo:
Llamada entrante con MIP” en la página 39 y, como en esos ejemplos, puede
utilizar la DIP o MIP en la interfaz Untrust.
Ejemplos 43
Figura 18: 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
phone1 ethernet3 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
en OK:

Zone: Trust
en OK:

Zone: Untrust
en OK:
Address Name: proxy

Zone: Untrust
44 Ejemplos
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:
Service: SIP
Action: Permit
NAT:
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), DIP(ethernet3)
Service: SIP
Action: Permit
CLI
1. Interfaces
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
Ejemplos 45
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. Usted 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 19
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 19: Proxy en DMZ
Untrust
Internet
phone2
1.1.1.4
ethernet3
1.1.1.1/24
ethernet2
2.2.2.2/24 DMZ
Dispositivo
NetScreen 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
WebUI
1. Interfaces
haga clic en Apply:
Zone: Trust
Interface Mode: NAT
46 Ejemplos
haga clic en OK:
Zone Name: DMZ

haga clic en OK:
Zone Name: Untrust

2. Dirección
en OK:

Zone: Trust
en OK:

Zone: Untrust
en OK:
Address Name: proxy

Zone: DMZ
3. MIP
Mapped IP: 2.2.2.3

Netmask: 255.255.255.255
4. Directivas
clic en OK:
Source Address:
Address Book Entry: (seleccione), proxy
Service: SIP
Action: Permit
Ejemplos 47
> 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
haga clic en OK:
Source Address:
Service: SIP
Action: Permit
48 Ejemplos
> 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
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. Para obtener más
información sobre la utilización de interfaces de bucle invertido, consulte “MIP y la
interfaz de bucle invertido (loopback)” en la página 8-76.
Ejemplos 49
Figura 20: Untrust intrazonal
Untrust
phone1 phone2
1.1.1.4 1.1.2.4
Internet
ethernet4 ethernet3
1.1.1.1/24 1.1.1.1/24
Bucle invertido 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
WebUI
1. Interfaces
haga clic en Apply:
Zone: Trust
Interface Mode: NAT
haga clic en OK:
Zone: Untrust
50 Ejemplos
haga clic en OK:
Zone: Untrust
haga clic en OK:

2. Direcciones
en OK:
Address Name: proxy

Zone: Trust
en OK:

Zone: Untrust
en OK:

Zone: Untrust
3. Grupo Loopback
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
Ejemplos 51

5. Bloqueo
clic en OK:
Block Intra-Zone Traffic: (anule la selección)

6. 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
set interface loopback.1 route
2. Direcciones
52 Ejemplos
3. Grupo Loopback
4. MIP
set interface loopback.1 mip 1.1.4.5 host 10.1.1.5
5. Bloqueo
unset zone untrust block
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 interfaz Untrust. Para permitir que ambos teléfonos de
la zona Trust se comuniquen entre sí, usted 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).
Figura 21: 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
phone2 ethernet2 interfaz en
10.1.2.2 10.1.2.1/24 ethernet3
WebUI
1. Interfaces
haga clic en Apply:
Zone: Trust
Interface Mode: NAT
haga clic en Apply:
Zone: Trust
Ejemplos 53
Interface Mode: NAT
haga clic en OK:
Zone: Untrust
2. Direcciones
en OK:

Zone: Trust
en OK:

Zone: Trust
en OK:
Address Name: proxy

Zone: Untrust

4. Directivas
haga clic en OK:
Source Address:
Service: SIP
Action: Permit
NAT:
54 Ejemplos

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:
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.
Ejemplos 55
NOTA: Los dispositivos de seguridad utilizados en este ejemplo deben tener disponibles
cuatro interfaces configurables independientemente.
Figura 22: VPN de malla completa para SIP
Proxy
Nota: La zona Untrust de Oficina central 10.1.3.3
cada dispositivo no se Zona Trust
muestra
Trust
eth2/8-10.1.3.1
túnel 1 túnel 2
6.6.6.6 Central 7.7.7.7
Untrust Untrust
eth2/1-1.1.1.1 eth2/2-1.1.2.1
Enrutador de puerta de Enrutador de puerta

enlace a central: 1.1.1.1 de enlace a central:
A sucursal-1.3.3.3.3 1.1.2.1
VPN 1 VPN 2 A sucursal-2.2.2.2
Untrust Untrust
eth3-3-3.3.3.3 eth3-2.2.2.2.
interfaz del tunnel.1 VPN 3 interfaz del tunnel.2

Sucursal-1 Sucursal-1
sin numerar sin numerar
Untrust Untrust
Trust eth4-4.4.4.4 eth4-5.5.5.5 Trust
eth1-10.1.1.1 eth1-10.1.2.1
Enrutador de puerta
Zona Trust de enlace Zona Trust
A sucursal-1: 4.4.4.4
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
NOTA: En este ejemplo, cada sección de la WebUI enumera solamente rutas de

navegación que conducen a las páginas necesarias para configurar el dispositivo.
Para consultar los parámetros y valores específicos que necesita establecer para
cualquier sección del WebUI, consulte la sección de CLI que le sigue.
WebUI (para la central)

1. Interfaces
Network > Interfaces > Edit (para ethernet2/1)
Network > Interfaces > New Tunnel IF
56 Ejemplos
2. Dirección
Objects > Addresses > List > New
3. VPN
VPNs > AutoKey IKE > New: > Advanced
4. Enrutamiento
Network > Routing > Routing Entries > New
5. Directivas
Policies > (From: Untrust, To: Trust) New
Policies > (From: Trust, To: Untrust) New
CLI (para la central)

1. Interfaces
set interface ethernet2/8 zone trust
set interface ethernet2/8 nat
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 ike gateway to-branch-2 address 2.2.2.2 main outgoing-interface ethernet2/2
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
set vpn vpn-branch-2 id 2 bind interface tunnel.2
4. Enrutamiento
set route 10.1.2.0/24 interface tunnel.2
5. Directivas
set policy from untrust to trust any proxy sip permit
set policy from trust to untrust proxy any sip permit
save
Ejemplos 57
WebUI (sucursal 2)
1. Interfaces
Network > Interfaces > Edit (para ethernet1)
2. Dirección
3. VPN
4. Enrutamiento
5. Directivas
CLI (sucursal 2)
1. Interfaces
2. Dirección
3. VPN
set ike gateway to-central address 1.1.1.1 Main outgoing-interface ethernet3
preshare "netscreen" sec-level standard
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 id 4 bind interface tunnel.1
set vpn vpn-ns50 gateway to-ns50 no-replay tunnel idletime 0 sec-level standard
set vpn vpn-ns50 id 5 bind interface tunnel.3
4. Rutas
58 Ejemplos
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 1)
1. Interfaces
2. Dirección
3. VPN
4. Enrutamiento
5. Directivas
CLI (sucursal 1)
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.4 main outgoing-interface ethernet4
set vpn vpncentral gateway to-central no-replay tunnel idletime 0 sec-level standard
set vpn vpncentral bind interface tunnel.2
set vpn vpn-ns50 gateway to-ns50 no-replay tunnel idletime 0 sec-level standard
set vpn vpn-ns50 bind interface tunnel.3
Ejemplos 59
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
Administrar el ancho de banda para servicios de VoIP

Juniper Networks recomienda 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 es 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
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 no esté siendo utilizado por VoIP.
Limitar el ancho de banda para el tráfico que no sea VoIP: Estableciendo un

ancho de banda máximo para el tráfico que no es 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 no VoIP no puede utilizar ancho de banda adicional
aunque no esté siendo utilizado por el tráfico VoIP.
Utilizar una cola de prioridades y el marcado Differentiated Services Codepoint

(DSCP): Garantizando el ancho de banda para el tráfico VoIP y limitando el
ancho de banda para el tráfico que no es VoIP se puede 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,
típicamente el enrutador LAN o WAN “fronterizo”, pueda hacer cumplir la
calidad del servicio (“Quality of Service” o 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 178.
La Figura 23 en la página 61 muestra cómo los ajustes de niveles de prioridad

pueden 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 presupone que usted 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
60 Ejemplos
y 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 un solapamiento
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.
El lado izquierdo de la Figura 23 muestra la utilización del ancho de banda con esos
ajustes y un elevado tráfico de oficina atravesando la interfaz, así como uso un nivel
de utilización bajo de VoIP. Si VoIP necesitase repentinamente más ancho de banda,
a menos que su prioridad fuese superior a la de los servicios del tráfico de la
oficina, no podría conseguirla. El lado derecho de la ilustración muestra el grado de
utilización del ancho de banda en las mismas circunstancias que cuando VoIP tiene
alta prioridad 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 “Asignar tráfico” en la página 197.
Figura 23: Ajustes de nivel de prioridad
Garantizado y de ancho Ajustes de nivel de prioridad agregado

de banda máximo
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
Ejemplos 61
62 Ejemplos
Capítulo 3
Puerta de enlace en la capa de
aplicación del 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 (Media 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 64
“Protocolo MGCP” en la página 64
Vista general
El protocolo de control de la puerta de medios (MGCP) es admitido 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 la inteligencia de control de las llamadas, mientras las puertas de medios
siguen las instrucciones del agente de llamadas.
La ALG de 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 con base en los RFC relacionados y los estándares del
propietario. 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

de la trama del paquete de señalización MGCP entrante se inspecciona
completamente de acuerdo con RFC 3435. Si se descubre algún ataque de
paquetes malformados, la ALG los bloquea.
Vista general 63
Ofrece procesamiento del estado. Las máquinas de estado basadas en el

protocolo VoIP se invocan 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 según 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.
Gestiona los 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 en forma dinámica cualquier ojo de aguja que sea
necesario y lo cierra durante el establecimiento de la llamada.
Seguridad de MGCP
La ALG de MGCP incluye las siguientes características de seguridad:
Protección contra ataques de denegación de servicio (DoS). La 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 (directivas de

medios).
Control de inundaciones de mensajes MGCP por puerta. Una puerta que esté
pirateada o averiada no interrumpirá la red completa de VoIP. Al combinarla
con el control de inundación por puerta de enlace, el daño se reduce a la puerta
afectada.
Control de inundaciones de conexión MGCP por puerta.
La conmutación por fallo/conmutación gradual, incluyendo llamadas en

progreso, se conmuta al cortafuegos en espera en caso de fallo del sistema.
Protocolo MGCP
MGCP es un protocolo de la capa de aplicación basado en texto que se utiliza para
establecer llamadas y controlar. 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.
Entidades en MGCP
Hay cuatro entidades básicas en MGCP:
64 Seguridad de MGCP
Capítulo 3: Puerta de enlace en la capa de aplicación del Protocolo de control de la puerta de medios
“Punto final” en la página 65
“Conexión” en la página 65
“Llamada” en la página 65
“Agente de llamada” en la página 65
Punto final
Una puerta de medios (MG) es una recopilació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@mired.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 identificación de la conexión se
presenta como una cadena hexadecimal y su longitud máxima es de 32 caracteres.
Llamada
La identificación de la llamada representa la llamada. El 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.
Agente de llamada
Uno o más agentes de llamada (también llamados controladores de la puerta de
medios) son admitidos en MGCP para mejorar la confiabilidad en la red VoIP. A
continuación se incluyen dos ejemplos de nombres de agentes de llamada:
AgenteLlamada@CAvoip.mired.com
CAvoip.mired.com
Protocolo MGCP 65
Varias 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 alternas de la red, se logra la conmutación y la conmutación por
error en MGCP.
El concepto de entidad notificada es esencial en MGCP. La entidad notificada para un

punto final es el agente de llamada que 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.
Cero o varias líneas de 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 la norma RFC 2234 para obtener
una explicación completa de la sintaxis del comando.
66 Protocolo MGCP
Tabla 3: Comandos MGCP
Verbo del
comando Descripción Sintaxis del comando Ejemplos
EPCF EndpointConfiguration: ReturnCode EPCF 2012 wxx/T2@mired.com MGCP 1.0
utilizado por un agente de [PackageList] B: e:mu
llamada para informar EndpointConfiguration (EndpointId,
sobre una puerta de [BearerInformation])
características de
codificación (ley a o ley
mu) que espera el lado de
la línea del 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
SecondEndpoindId}],
[encapsulated RQNT],
[encapsulated RQNT],
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 RQNT], 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 RQNT], 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 67
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 determinados [RequestedEvents,] D: (0T|00T|xx|91xxxxxxxxxx|9011x.T)
eventos o señales para un RequestIdentifier, S:
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 determinaos RequestIdentifier, D/2,D/6,D/6
eventos o señales ObservedEvents)
solicitados.
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])
68 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 que RestartInProgress (EndpointId,
uno o más puntos finales RestartMethod,
entran en servicio o dejan [RestartDelay,]
de estar en servicio. [ReasonCode])
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 de

un 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).
400 – 499: indica un error transitorio (respuesta final).
Protocolo MGCP 69
500 – 599: indica un error permanente (respuesta final).
Consulte la norma 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 el domicilio de los abonados: agente de llamada en el ISP”

en esta página
“Servicio alojado en el ISP” en la página 73
Puerta de enlace en el domicilio de los abonados: agente de llamada en el ISP

En este ejemplo, (consulte la Figura 24) se configura un dispositivo de seguridad en
un proveedor de servicio de cable para que los abonados domésticos de su red
puedan admitir MGCP. El dispositivo de seguridad y el agente de llamada se
encuentran en las instalaciones del proveedor de servicios de cable. En cada una de
las residencias de los abonados se encuentra un dispositivo de acceso integrado
(IAD) o una casilla 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 servicios) se deben configurar las direcciones y después las
directivas. Aunque las puertas de enlace suelen residir 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.
70 Ejemplos
Figura 24: Puerta de enlace en la el domicilio de los abonados
Untrust
IAD
Teléfono IP
IAD
Ethernet 3 Teléfono IP
2.2.2.0/24 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
en OK:
Address Name: SubscriberSubNet

Comment: Our subscribers’ network
Zone: untrust-subscriber
en OK:
Address Name: call_agent1

Comment: Our No. 1 call agent
Zone: trust_ca
Ejemplos 71
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”
72 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 el ISP

En este ejemplo, (consulte la Figura 25) 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 de rutas para el flujo directo de los medios 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 una 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 73
Figura 25: Servicio alojado en el ISP
MIP de dispositivo
DMZ virtual en Ethernet6 -
3.3.3.101 - 10.1.1.101
west_ca
10.1.1.101
Eth5 - 10.1.1.2 Dispositivo de seguridad Zona Untrust
Red ISP asia_gw

Eth6 - 3.3.3.10 3.3.3.110
Eth4 - 2.2.2.10
Teléfono IP
Zona Trust
sf_gw
2.2.2.201 Teléfono IP
WebUI
1. Direcciones
en OK:
Address Name: sf_gw

Comment: gateway in Asia
Zone: Trust
en OK:
Address Name: asia_gw

Comment: gateway in Asia
Zone: Untrust
en OK:
Address Name: west_ca

Comment: ca in west coast
Zone: DMZ
74 Ejemplos
2. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: route
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 75
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:
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


76 Ejemplos
set interface ethernet6 mip 3.3.3.101 host 10.1.1.101 netmask
255.255.255.255 vrouter trust-vr
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 77
78 Ejemplos
Índice
A proxy en zona privada ............................................41
ALG ..................................................................................17 proxy en zona pública ............................................43
SIP .............................................................................13 trust intrazonal ........................................................53
SIP NAT ....................................................................24 untrust intrazonal ....................................................49
utilizar DIP de interfaz ............................................34
G utilizar DIP entrante ................................................33
gatekeeper (equipos selectores) .....................................1 utilizar un conjunto de DIP ....................................37
L V
libro de servicio, grupos de servicios (WebUI) ...........61 voz sobre IP
administración del ancho de banda ......................60
O definición....................................................................1
ojos de aguja ..................................................................19
S
SDP .......................................................................... 18 a 19
sesiones multimedia, SIP ..............................................13
SIP
ALG .....................................................................17, 21
anuncios de medios ................................................19
caducidad por inactividad ......................................21
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
respuestas ................................................................16
RTCP .........................................................................19
RTP ...........................................................................19
SDP ................................................................... 18 a 19
señalización .............................................................17
sesiones multimedia ...............................................13
tiempo de espera por inactividad de la sesión ....21
tiempo de espera por inactividad
de medios ........................................................22, 23
tiempo de espera por inactividad
de señalización ................................................22, 23
tipos de métodos de petición ................................14
SIP NAT
con VPN de malla completa...................................55
configuración de llamadas ...............................24, 30
definido ....................................................................24
entrante, con MIP..............................................37, 39
proxy en DMZ ..........................................................46
Índice IX-I
IX-II Índice
Manual de referencia de ScreenOS
Volumen 7:
Enrutamiento

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Copyright Notice
without notice.
FCC Statement
Disclaimer
Writer: Kristine Conley

ii
Contenido
Convenciones del documento ......................................................................... ix
Capítulo 1 Enrutamiento estático 1

Vista general .................................................................................................... 2
Cómo funciona el enrutamiento estático ................................................... 2
Cuándo configurar rutas estáticas .............................................................. 3
Configurar rutas estáticas .......................................................................... 5
Ajustar rutas estáticas ......................................................................... 5
Establecer una ruta estática para una interfaz de túnel ....................... 8
Habilitar el seguimiento de las puertas de enlace ...................................... 9
Reenviar tráfico a la interfaz nula................................................................... 10
Impedir búsqueda 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
Impedir la creación de bucles por las rutas resumidas............................. 11
Rutas permanentemente activas .................................................................... 11
Cambiar la preferencia de enrutamiento con rutas múltiples
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 ............................................. 17
Tabla de enrutamiento basada en la interfaz de origen ........................... 20
Crear y modificar enrutadores virtuales ......................................................... 22
Modificar enrutadores virtuales ............................................................... 22
Asignar una ID del enrutador virtual ........................................................ 23
Reenviar tráfico entre enrutadores virtuales ............................................ 23
Configurar dos enrutadores virtuales ....................................................... 24
Crear y eliminar enrutadores virtuales..................................................... 26
Crear un enrutador virtual personalizado .......................................... 27
Eliminar un enrutador virtual personalizado ..................................... 27
Enrutadores virtuales y sistemas virtuales ............................................... 27
Crear un enrutador virtual en un Vsys............................................... 28
Compartir rutas entre enrutadores virtuales...................................... 29
Limitar el número máximo de entradas de la tabla de enrutamiento ...... 30
Contenido iii
Conceptos y ejemplos, Manual de Referencia de ScreenOS
Ejemplos y características del enrutamiento .................................................. 31

Seleccionar rutas ..................................................................................... 31
Establecer una preferencia de ruta ....................................................31
Métricas de ruta ................................................................................ 32
Cambiar la secuencia predeterminada de consulta de rutas .............. 33
Consultar rutas en múltiples enrutadores virtuales ............................ 36
Configurar el enrutamiento de rutas múltiples de igual coste................... 37
Configurar un mapa de rutas............................................................. 40
Filtrar rutas ....................................................................................... 42
Configurar una lista de acceso........................................................... 42
Redistribuir rutas en OSPF ................................................................ 43
Exportar e importar rutas entre enrutadores virtuales ............................. 44
Configurar una regla de exportación ................................................. 45
Configurar la exportación automática ............................................... 46
Capítulo 3 Protocolo OSPF 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
Crear y eliminar una instancia de enrutamiento de OSPF........................ 53
Crear una instancia de OSPF............................................................. 53
Eliminar una instancia de OSPF ........................................................ 53
Crear y eliminar un área OSPF ................................................................ 54
Crear un área OSPF........................................................................... 54
Eliminar un área OSPF...................................................................... 55
Asignar interfaces a un área OSPF........................................................... 55
Asignar interfaces a áreas .................................................................55
Configurar un rango de áreas............................................................ 56
Habilitar OSPF en interfaces .................................................................... 56
Habilitar OSPF en interfaces ............................................................. 56
Inhabilitar OSPF en una interfaz ....................................................... 57
Comprobar la configuración .................................................................... 58
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
Notificar la ruta predeterminada.............................................................. 62
Conexiones virtuales ............................................................................... 63
Crear una conexión virtual ................................................................ 63
Crear una conexión virtual automática.............................................. 65
Ajustar parámetros de interfaz OSPF ............................................................. 65
Autenticar vecinos ................................................................................... 67
Configurar una contraseña de texto no cifrado ................................. 68
Configurar una contraseña MD5 ....................................................... 68
Configurar una lista de vecinos de OSPF ................................................. 68
iv Contenido
Contenido

Configurar un límite de saludo .......................................................... 70
Configurar un límite de LSAs............................................................. 70
Habilitar la inundación reducida ....................................................... 71
Crear un circuito de demanda OSPF en una interfaz de túnel ........................ 71
Interfaz de túnel punto a multipunto.............................................................. 72
Establecer el tipo de conexión OSPF ....................................................... 72
Inhabilitar la restricción Route-Deny........................................................ 72
Crear 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
Crear y eliminar una instancia RIP .......................................................... 82
Crear una instancia RIP..................................................................... 82
Eliminar una instancia RIP ................................................................ 82
Habilitar y deshabilitar RIP en interfaces ................................................. 83
Habilitar RIP en una interfaz ............................................................. 83
Inhabilitación de RIP en una interfaz ................................................ 83
Visualizar la información de RIP .................................................................... 85
Visualizar la base de datos RIP ................................................................ 85
Visualizar los detalles de RIP ................................................................... 86
Visualizar información de vecino RIP ...................................................... 87
Visualizar detalles de RIP para una interfaz específica ............................. 88
Parámetros globales de RIP............................................................................ 89
Notificar la ruta predeterminada .................................................................... 90
Configurar los parámetros de interfaz de RIP................................................. 91
Autenticar vecinos mediante una contraseña .......................................... 92
Configurar vecinos fiables........................................................................ 93
Configurar un umbral de actualización.............................................. 95
Habilitar RIP en interfaces de túnel ................................................... 95
Configuraciones opcionales de RIP ................................................................ 97
Configurar la versión de RIP .................................................................... 97
Habilitar y deshabilitar un resumen de prefijo ......................................... 99
Habilitar un resumen de prefijo......................................................... 99
Inhabilitar un resumen de prefijo ....................................................100
Ajustar rutas alternas.............................................................................100
Circuitos de demanda en interfaces de túnel .........................................101
Configurar un vecino estático ................................................................103
Configurar una interfaz de túnel punto a multipunto....................................103
Capítulo 5 Protocolo BGP 109

Vista general ................................................................................................110
Tipos de mensajes BGP..........................................................................110
Atributos de ruta....................................................................................111
BGP externo e interno ...........................................................................111
Configuración básica de BGP........................................................................112
Crear y habilitar una instancia de BGP...................................................113
Contenido v
Crear una instancia BGP..................................................................113

Eliminar una instancia de BGP ........................................................114
Habilitar y deshabilitar BGP en interfaces ..............................................114
Habilitar BGP en interfaces .............................................................114
Inhabilitar BGP en interfaces...........................................................114
Configurar grupos de interlocutores e interlocutores BGP ......................115
Configurar un interlocutor BGP .......................................................116
Configurar un grupo de interlocutores IBGP ....................................117
Comprobar la configuración BGP...........................................................118
Configuración de seguridad..........................................................................119
Autenticar vecinos BGP..........................................................................120
Rechazar rutas predeterminadas ...........................................................120
Configuraciones opcionales de BGP .............................................................121
Redistribuir rutas en BGP.......................................................................122
Configurar una lista de acceso AS-Path ..................................................123
Agregar rutas a BGP...............................................................................124
Notificar ruta condicional ................................................................124
Establecer el peso de la ruta............................................................125
Establecer atributos de ruta.............................................................125
Capacidad de enrutamiento-actualización .............................................126
Solicitar una actualización de la tabla de enrutamiento entrante.....127
Solicitar una actualización de la tabla de enrutamiento saliente ......127
Configuración de la reflexión de rutas ...................................................127
Configurar una confederación ...............................................................130
Comunidades BGP .................................................................................131
Agregar rutas .........................................................................................132
Agregar rutas con diferentes AS-Paths.............................................132
Suprimir las rutas más específicas en actualizaciones .....................133
Seleccionar rutas para el atributo Path ............................................134
Cambiar atributos de una ruta agregada .........................................135
Capítulo 6 Enrutamiento multicast 137

Vista general ................................................................................................137
Direcciones multicast ............................................................................138
Reenviar rutas inversas .........................................................................138
Enrutamiento multicast en dispositivos de seguridad...................................139
Tabla de enrutamiento multicast ...........................................................139
Configurar una ruta multicast estática ...................................................140
Listas de acceso .....................................................................................141
Configurar el encapsulado genérico de enrutamiento
en interfaces de túnel......................................................................141
Directivas multicast......................................................................................143
Capítulo 7 Protocolo IGMP 145

Vista general ................................................................................................146
Hosts .....................................................................................................147
Enrutadores multicast............................................................................148
IGMP en dispositivos de seguridad ...............................................................149
Habilitar y deshabilitar IGMP en interfaces ............................................149
Habilitar IGMP en una interfaz ........................................................149
Inhabilitar IGMP en una interfaz......................................................150
Configurar una lista de accesos para grupos aceptados .........................150
Configurar IGMP ....................................................................................151
vi Contenido
Contenido
Verificar una configuración de IGMP......................................................153

Parámetros operativos de IGMP.............................................................154
Proxy de IGMP .............................................................................................155
Informes de miembros en sentido ascendente hacia el origen ..............156
Datos multicast en sentido descendente a los receptores ......................157
Configurar el proxy de IGMP .................................................................158
Configurar un proxy de IGMP en una interfaz........................................158
Directivas Multicast para configuraciones de IGMP y proxy de IGMP.....160
Crear una directiva de grupo multicast para IGMP ..........................160
Crear una configuración de proxy de IGMP .....................................160
Configurar un proxy del remitente de IGMP ..........................................167
Capítulo 8 Multicast independiente de protocolo (PIM) 173

Vista general ................................................................................................175
PIM-SM ..................................................................................................176
Árboles de distribución multicast ....................................................176
Enrutador designado.......................................................................177
Asignar puntos de encuentro a grupos ............................................177
Reenviar tráfico a través del árbol de distribución...........................178
PIM-SSM ................................................................................................180
Configuración de PIM-SM en dispositivos de seguridad ................................180
Habilitar y eliminar una instancia PIM-SM
en un enrutador virtual (VR)............................................................181
Habilitar de una instancia PIM-SM...................................................181
Eliminar una instancia PIM-SM........................................................181
Habilitar y deshabilitar PIM-SM en interfaces.........................................182
Habilitar PIM-SM en una interfaz.....................................................182
Inhabilitar PIM-SM en una interfaz ..................................................182
Directivas de grupo multicast ................................................................182
Mensajes Static-RP-BSR...................................................................183
Mensajes Join-Prune........................................................................183
Definir de una directiva de grupo multicast para PIM-SM................183
Ajustar una configuración de PIM-SM básica ................................................184
Comprobar la configuración.........................................................................189
Configurar puntos de encuentro...................................................................191
Configurar de un punto de encuentro estático .......................................191
Configurar de un punto de encuentro candidato....................................192
Consideraciones sobre seguridad .................................................................193
Restringir grupos multicast ....................................................................193
Restringir orígenes multicast .................................................................194
Restringir puntos de encuentro..............................................................195
Parámetros de la interfaz PIM-SM ................................................................196
Definir una directiva de vecindad ..........................................................196
Definir un borde bootstrap ....................................................................197
Configurar de un punto de encuentro del proxy...........................................198
PIM-SM e IGMPv3 ........................................................................................207
Índice ........................................................................................................................IX-I
Contenido vii
viii Contenido
El Volumen 7: Enrutamiento incluye los siguientes capítulos:
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.
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, “Protocolo OSPF,” explica cómo configurar Open Shortest Path First
(OSPF).
Capítulo 4, “Protocolo de información de enrutamiento,” explica cómo

configurar Routing Information Protocol (RIP).
Capítulo 5, “Protocolo BGP,” explica cómo configurar Border Gateway Protocol

(BGP).
Capítulo 6, “Enrutamiento multicast,” explica los fundamentos del

enrutamiento multicast, incluyendo cómo configurar rutas multicast estáticas.
Capítulo 7, “Protocolo IGMP,” explica cómo configurar Internet Group

Management Protocol (IGMP).
Capítulo 8, “Multicast independiente de protocolo (PIM),” explica cómo

configurar Protocol Independent Multicast - Sparse Mode (PIM-SM) y Protocol
Independent Multicast - Source Specific Multicast (PIM-SSM).

“Convenciones de la interfaz de línea de comandos (CLI)” en la página x
“Convenciones para las ilustraciones” en la página xi
“Convenciones de nomenclatura y conjuntos de caracteres” en la página xii
“Convenciones de la interfaz gráfica (WebUI)” en la página xiii


En ejemplos:


ethernet2, o ethernet3”.
Las variables aparecen en tipo cursiva.
set admin user nombre1 password xyz
En texto:
Los comandos aparecen en tipo negrita.
Las variables aparecen en tipo cursiva .
NOTA: Para escribir palabras clave, basta con escribir los primeros caracteres que
introduciendo. Por ejemplo, es suficiente escribir set adm u kath j12fmt54 para
que el sistema reconozca el comando set admin user kathleen j12fmt54.



10.1.1.0/24)

Internet

dinámicas (DIP)

Equipo portátil
Interfaz de túnel
Servidor
Túnel VPN
Concentrador (hub)
Enrutador
Teléfono IP
Conmutador


de enlace IKE, sistemas virtuales, túneles de VPN y zonas) definidas en las
Si una cadena de nombres incluye uno o más espacios, la cadena completa

deberá entrecomillarse mediante comillas dobles ( “ ); por ejemplo:

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



excepción de las comillas dobles ( “ ), que tienen un significado especial como


siguiente figura muestra la siguiente ruta para abrir el cuadro de diálogo de
configuración de direcciones—Objects > Addresses > List > New:
de configuración:

en OK:
Zone: Untrust
Convenciones del documento xiii



“Case Manager” en la página Web http://www.juniper.net/support/ o llame al


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. Contiene 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
“Configurar rutas estáticas” en la página 5
“Habilitar el seguimiento de las puertas de enlace” en la página 9
“Reenviar tráfico a la interfaz nula” en la página 10
“Impedir búsqueda 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
“Impedir la creación de bucles por las rutas resumidas” en la página 11
“Rutas permanentemente activas” en la página 11
“Cambiar la preferencia de enrutamiento con rutas múltiples de igual coste” en

la página 12
1
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 se 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.
Puede ver rutas estáticas en la tabla de enrutamiento ScreenOS. Para forzar el

equilibrio de cargas, puede configurar Equal Cost Multi-Path (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 4 representa una red que utiliza enrutamiento estático y un paquete IP de

muestra. 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 destino
Carga (mensaje)
2 Vista general
Capítulo 1: Enrutamiento estático
Figura 4: 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

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

Puerto de Puerto de Puerto de
Red enlace Red enlace Red enlace
Red A Conectado Red A Enrutador X Red A Enrutador X
Red B Conectado Red B Conectado Red B Conectado
Red C Enrutador Y Red C Conectado Red C Conectado
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 conoce 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.
Vista general 3
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.
Si está utilizando dos VRs 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 trabaja 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.
4 Vista general
Configurar 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.
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 nula para determinadas aplicaciones. Consulte “Reenviar tráfico a la
interfaz nula” 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:
“Ajustar rutas estáticas” en esta página
“Establecer una ruta estática para una interfaz de túnel” en la página 8
Ajustar rutas estáticas

En la Figura 5 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.
Vista general 5
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
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 5: 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 de
10.1.1.0/24 enrutador = Conmutador/Hub
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
siguientes datos para crear la puerta de enlace predeterminada untrust y haga
clic en OK:

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
Establecer una ruta estática para una interfaz de túnel

En la Figura 6, un host fiable reside en una subred diferente de la interfaz fiable. Un
servidor del Protocolo de transferencia de archivos (FTP) recibe tráfico entrante 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 6: Ruta estática para una interfaz de túnel
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
WebUI
8 Vista general
Interface: tunnel.1
NOTA: Para que tunnel.1 aparezca en la lista desplegable “Interface”, primero debe crear
la interfaz tunnel.1.

CLI
save
Habilitar el seguimiento de las 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 usted puede
configurar un dispositivo de seguridad para dar seguimiento a la accesibilidad de las
rutas de las puertas de enlace. El dispositivo registra las rutas seguidas ya sea
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 vuelva a activarse también.
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 al ingresar la
dirección IP de la puerta de enlace pero no establezca la interfaz.
WebUI
Network > Routing > Routing Entries: Haga clic en New e ingrese lo siguiente:
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
Vista general 9
Reenviar tráfico a la interfaz nula

Puede configurar rutas estáticas usando la interfaz nula como interfaz de salida. La
interfaz nula siempre se considera activa y el tráfico destinado a la interfaz nula
siempre se descarta. Para convertir la ruta a la interfaz nula en una ruta de último
recurso, defínala con una métrica más alta que la de las demás rutas. Los tres
propósitos para utilizar rutas estáticas que reenvían tráfico a la interfaz nula son los
siguientes:
Impedir búsqueda 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 búsqueda 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 búsqueda 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 basada en 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 búsqueda de ruta 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 búsqueda de la ruta en la tabla de
enrutamiento basada en los destinos. Si desea evitar las operaciones de búsqueda
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 nula 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 nula 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 nula se activa y el tráfico para el destino del
túnel se descarta.
10 Reenviar tráfico a la interfaz nula

Impedir la creación de bucles 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 nula 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. Aun
cuando 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 rutas múltiples de igual coste

También puede cambiar la preferencia de enrutamiento de las rutas estáticas con
Equal Cost Multipath (ECMP). Para obtener más información, consulte “Configurar
el enrutamiento de rutas múltiples de igual coste” en la página 37.
12 Cambiar la preferencia de enrutamiento con rutas múltiples de igual coste

Capítulo 2
Enrutamiento
Este capítulo describe la administración del enrutamiento y del enrutador virtual

(VR). Contiene 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 17
“Tabla de enrutamiento basada en la interfaz de origen” en la página 20
“Crear y modificar enrutadores virtuales” en la página 22
“Modificar enrutadores virtuales” en la página 22
“Asignar una ID del enrutador virtual” en la página 23
“Reenviar tráfico entre enrutadores virtuales” en la página 23
“Configurar dos enrutadores virtuales” en la página 24
“Crear y eliminar enrutadores virtuales” en la página 26
“Enrutadores virtuales y sistemas virtuales” en la página 27
“Limitar el número máximo de entradas de la tabla de enrutamiento” en la

página 30
“Ejemplos y características del enrutamiento” en la página 31
“Seleccionar rutas” en la página 31
“Configurar el enrutamiento de rutas múltiples de igual coste” en la

página 37
“Redistribuir rutas” en la página 39
“Exportar e importar rutas entre enrutadores virtuales” en la página 44
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 enrutarse a través de un

proceso llamado enrutador virtual (VR). Un dispositivo de seguridad divide sus
componentes de enrutamiento en dos o más VRs 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 VRs 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 se pueden 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 “Crear y
eliminar enrutadores virtuales” en la página 7-26.
Algunos dispositivos de seguridad permiten crear otros VRs personalizados. Al

separar la información de enrutamiento en varios VRs, podrá controlar cuánta
información sobre enrutamiento puede verse en otros dominios de enrutamiento.
Por ejemplo, se 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. Se puede mantener la información sobre enrutamiento de
redes internas separada de las fuentes no fiables fuera 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 se
procesa un dispositivo de seguridad en un paquete entrante, éste realiza una
consulta en la tabla de enrutamiento para buscar la interfaz apropiada 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

asignada a una interfaz en el modo de ruta)
Protocolos de enrutamiento dinámico, como Open Shortest Path First (OSPF),

Border Gateway Protocol (BGP) o Routing Information Protocol (RIP)
Otros enrutadores o enrutadores virtuales en forma de rutas importadas
Rutas configuradas estáticamente
Rutas host
NOTA: Cuando se 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 17.
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 basada en 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 tablas de enrutamiento basadas en orígenes o en
interfaces de origen, o bien ambas, en un VR. A continuación se incluye un ejemplo
de tablas de enrutamiento basadas en destino de ScreenOS:
ns-> 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> (11 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
* 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)
De exportación automática (A)
16 Tablas de enrutamiento del enrutador virtual

Importada (I)
Los protocolos de enrutamiento dinámico, como RIP (R), Open Shortest

Path First u OSPF (O), tipo externo 1 y 2 de OSPF (E1 o E2,
respectivamente), Border Gateway Protocol interno o externo (iB o eB,
respectivamente)
Permanente (P)
Host (H)
Una entrada de ruta host con una máscara de 32 bits aparece cuando
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 cambios configurados,
como por ejemplo la eliminación de la dirección IP de interfaz y éstas
nunca se redistribuyen ni se exportan. Las rutas host descartan la
posibilidad de que exista tráfico errante 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 de que esa ruta se seleccione como ruta activa.
Este valor de preferencia se puede modificar en cada enrutador virtual para

cada protocolo u origen de ruta. Para obtener más información, consulte
“Seleccionar rutas” en la página 31.
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 se 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 “Configurar

rutas estáticas” en la página 5.
Tabla de enrutamiento basada en el origen

Se 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 sea
reenviado 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.
Las rutas basadas en el origen se definen como rutas configuradas estáticamente en

VRs especificados. Las rutas basadas en orígenes son aplicables al VR en el que se
les configura; sin embargo, puede especificar otro VR como siguiente salto para una
ruta basada en orígenes. Tampoco se pueden 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 búsqueda 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

se ha especificado una puerta de enlace predeterminada para la interfaz
con el comando CLI set interface interfaz 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 el origen. También puede especificar otro VR como siguiente
salto para la ruta basada en el origen con el comando set vrouter vrouter
route source dir_ip/máscara_red vrouter salto-siguiente_vrouter).
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 7, 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 7: 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, y 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 basada en 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.
Define las rutas basadas en la interfaz origen como rutas estáticas para las
interfaces de origen especificadas. Las rutas basadas en la interfaz de origen son
aplicables 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 se pueden exportar rutas basadas en la interfaz de origen a
otros VRs 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 se ha especificado una puerta de enlace predeterminada
para la interfaz con el comando CLI set interface interfaz 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 vrouter route source dir_ip/máscara_red vrouter
salto-siguiente_vrouter).
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 8, 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 para reenvíos y
ethernet4 como interfaz de reenvío, y el enrutador del ISP 2 (2.2.2.2) como
siguiente salto.
Figura 8: 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, y 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

Crear y modificar enrutadores virtuales

Esta sección incluye varios ejemplos y procedimientos para modificar enrutadores
virtuales (VRs) existentes y para crear o eliminar VRs personalizados.
Modificar enrutadores virtuales

Se 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
set vrouter trust-vr
Se pueden modificar los siguientes parámetros de los VRs:
Identificador de enrutador virtual (consulte “Limitar el 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 “Establecer

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 17.)
Habilitar o inhabilitar la exportación automática de rutas 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 MIBs 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 VRs).
Hacer que el VR ignore las direcciones de subredes superpuestas para

interfaces (de forma predeterminada, no se pueden configurar direcciones IP
de subredes superpuestas para interfaces en el mismo VR).
Permitir que el VR sincronice su configuración con el VR de su interlocutor del

NetScreen Redundancy Protocol (NSRP).
22 Crear y modificar enrutadores virtuales

Asignar una ID del enrutador virtual

Con los protocolos de enrutamiento dinámico, cada dispositivo de enrutamiento
utiliza una única identidad de enrutador para comunicar 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 se 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 se 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 VRs de seguridad con
la misma ID de VR en un dominio de enrutamiento. Por lo tanto, recomendamos
que siempre se asigne una ID de VR explícita que sea única en la red. Se puede
establecer la ID del VR a 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, se asigna 0.0.0.10 como ID de enrutador para el trust-vr.
NOTA: En la WebUI se debe introducir la ID del enrutador en notación decimal de puntos.

En la CLI, se 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
NOTA: No se puede asignar o cambiar una ID de enrutador si ya se ha habilitado un

protocolo de enrutamiento dinámico en el VR. Si es necesario cambiar la ID del
enrutador, se debe primero desactivar el protocolo de enrutamiento dinámico en
el VR. Para más información sobre la desactivación del protocolo de enrutamiento
dinámico en el VR, consulte el capítulo correspondiente en este volumen.
Reenviar 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 VRs, tiene que
realizar uno de estos procedimientos:
Crear y modificar enrutadores virtuales 23

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, se 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 “Configurar rutas estáticas” en la página 5.
Exportar rutas de la tabla de enrutamiento de un VR a la tabla de enrutamiento

de otro VR. Se pueden exportar e importar rutas concretas. También se pueden
exportar todas las rutas de la tabla de enrutamiento del trust-vr a la tabla del
untrust-vr. Esto posibilita el reenvío de paquetes recibidos en el untrust-vr a
destinos del trust-vr. Para obtener información, consulte “Exportar e importar
rutas entre enrutadores virtuales” en la página 44.
Configurar dos enrutadores virtuales

Cuando hay varios VRs 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.
Se puede asociar una zona de seguridad a un sólo VR. Se pueden 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. Se puede cambiar el vínculo 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 vincular y desvincular una interfaz de una zona de
seguridad, consulte “Protocolo OSPF” en la página 7-47.)
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 se quiera asociar al untrust-vr. No

se puede modificar el vínculo de zona a VR si hay una interfaz asignada a la
zona. Si se ha asignado una dirección IP a una interfaz, es necesario eliminar la
asignación de dirección antes de quitar la interfaz de la zona.
2. Asignar la zona al VR untrust-vr.
3. Asignar de nuevo 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 se 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 en la lista
desplegable Virtual Router Name, luego haga clic en OK.
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.
ns-> 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.
ns-> 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
---------------------------------------------------------------
Crear y eliminar enrutadores virtuales

Algunos dispositivos de seguridad permiten crear VRs personalizados además de
los dos predefinidos. Se pueden 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 determinados dispositivos de seguridad son compatibles con VRs

personalizados. Para crear VRs personalizados, es necesaria una clave de licencia
de software.

Crear un enrutador virtual personalizado

En este ejemplo, se crea un VR personalizado denominado trust2-vr y se habilita
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
Eliminar un enrutador virtual personalizado

En este ejemplo, se elimina 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 se pueden eliminar los VRs 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, se debe primero eliminar 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 VRs 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. Se puede configurar otro VR de nivel raíz como compartido.
Un VR de nivel vsys. Cuando se crea un vsys, se crea automáticamente un VR

de nivel vsys que mantiene la tabla de enrutamiento de la zona Trust-vsysname.
Se puede elegir nombrar el VR como vsysname-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, es
necesaria una clave de licencia de software.
Se pueden definir uno o más VRs personalizados para un vsys. Para obtener más
información sobre sistemas virtuales, consulte el Volumen 10: Sistemas virtuales. En
la Figura 9, cada uno de los tres vsys tiene dos VR asociados con éste: un VR de
nivel vsys llamado vsysname-vr y el untrust-vr.
Figura 9: Enrutadores virtuales dentro de un Vsys
trust-vr
untrust-vr Finance
(enrutador virtual
a nivel de raíz DMZ
compartido)
Mail Trust Eng
sistema raíz vsys1-vr

Trust-vsys1
Untrust vsys1
vsys2-vr Automáticamente
vsys2 creados cuando
Trust-vsys2 se crea vsys
vsys3
vsys3-vr
Trust-vsys3
Crear un enrutador virtual en un Vsys

En este ejemplo, se define un VR personalizado vr-1a con la ID de VR 10.1.1.9 para
el vsys my-vsys1.
WebUI
Vsys > Enter (para my-vsys1) > Network > Routing > Virtual Routers >
New: Introduzca los siguientes datos y haga clic en Apply:
Virtual Router Name: vr-1a

En el cuadro de texto, introduzca 10.1.1.9

CLI
set vsys my-vsys1
(my-vsys1) set vrouter name vr-1a
(my-vsys1/vr-1a) set router-id 10.1.1.9
(my-vsys1/vr-1a) exit
(my-vsys1) exit
Teclee Y cuando aparezca la siguiente pregunta:
Configuration modified, save? [y]/n
El VR de nivel vsys que se crea al crear el vsys es el VR predeterminado para un

vsys. Se 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 my-vsys1:
WebUI
Vsys > Enter (para my-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 my-vsys1
(my-vsys1) set vrouter vr-1a
(my-vsys1/vr-1a) set default-vrouter
(my-vsys1/vr-1a) exit
(my-vsys1) exit

La zona de seguridad predefinida Trust-vsysname está asociada de forma

predeterminada al VR de nivel vsys que se crea al crear el vsys. No obstante, se
puede asociar la zona de seguridad predefinida Trust-vsysname 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 VRs
de nivel vsys no se pueden compartir, se puede definir cualquier VR de nivel raíz
para ser compartido por el vsys. Esto permite definir rutas en un VR de nivel vsys
que utilizan un VR de nivel raíz como siguiente salto. Se 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 my-router contiene las entradas de la tabla de
enrutamiento para la red 4.0.0.0/8. Si se configura el VR de nivel raíz my-router
como compartible por el vsys, se puede definir una ruta en un VR de nivel vsys para
el destino 4.0.0.0/8 con my-router como siguiente salto. En este ejemplo, el vsys es
my-vsys1 y el VR de nivel vsys es my-vsys1-vr.

WebUI
Network > Routing > Virtual Routers > New: Introduzca los siguientes datos y
haga clic en OK:
Virtual Router Name: my-router

Shared and accessible by other vsys (seleccione)
Vsys > Enter (para my-vsys1) > Network > Routing > Routing Entries > New
(para my-vsys1-vr): Introduzca los siguientes datos y haga clic en OK:

Next Hop Virtual Router Name: (seleccione) my-router
CLI
set vrouter name my-router sharable
set vsys my-vsys1
(my-vsys1) set vrouter my-vsys1-vr route 40.0.0.0/8 vrouter my-router
(my-vsys1) exit
Limitar el 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 un
conjunto del sistema. El número máximo de entradas disponibles depende del
dispositivo de seguridad y del número de VRs configurados en el dispositivo. Se
puede limitar el número máximo de entradas de la tabla de enrutamiento que
pueden asignarse a 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
En este ejemplo, se ajusta 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 características del enrutamiento

Después de configurar los VRs requeridos para su red, puede determinar cuáles
características de enrutamiento desea emplear. Estas características afectan al
comportamiento del enrutamiento y a los datos de la tabla de enrutamiento. Estas
características se aplican a protocolos de enrutamiento estático y dinámico.
Esta sección contiene los siguientes temas:
“Seleccionar rutas” en la página 31
“Configurar el enrutamiento de rutas múltiples de igual coste” en la página 37
“Exportar e importar rutas entre enrutadores virtuales” en la página 44
Seleccionar 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.
Establecer 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.
Ejemplos y características del enrutamiento 31

Tabla 2: Valores de preferencia predeterminados de las rutas
Protocolo Preferencia predeterminada

Connected 0
Static 20
Auto-Exported 30
EBGP 40
OSPF 60
RIP 100
Imported 140
OSPF External Type 2 200
IBGP 250
También se puede ajustar el valor de preferencia de la ruta para dirigir el tráfico por
el camino preferido.
En este ejemplo, se 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.
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.
32 Ejemplos y características del enrutamiento

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 económico de los enlaces 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.
Cambiar la secuencia predeterminada de consulta de rutas

Si activa tanto el enrutamiento basado en el origen como el enrutamiento basado
en interfaz de origen en un VR, el VR realiza búsquedas de la ruta, comprobando el
paquete entrante con las tablas de enrutamiento en un orden específico. Esta
sección describe la secuencia de búsqueda de la ruta predeterminada y cómo se
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 el procedimiento First Packet Processing. La
Figura 10 en la página 34 muestra la secuencia predeterminada de consulta de rutas.

Figura 10: Secuencia predeterminada de consulta de rutas
paquete entrante
¿SIBR Sí ¿La ruta se

activado? encontró
en tabla
SIBR?
No No
¿SIBR Sí ¿La ruta se Sí

encontró Reenviar el paquete en la
activado? interfaz de salida especificada
en tabla
SIBR? o de siguiente salto
No No
¿Se encontró Sí
la ruta en
DRT?
No
Descartar paquete
1. Si el enrutamiento basado en la interfaz de origen se activa en el VR, el

dispositivo de seguridad primero comprueba la tabla de enrutamiento basada
en la interfaz de origen para 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 se habilita en el VR.
2. Si el enrutamiento basado en el origen se activa en el VR, el dispositivo de

seguridad comprueba la tabla de enrutamiento basada en el origen para 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 búsqueda 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 búsqueda 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 búsqueda 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
búsqueda 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

Consultar rutas en múltiples enrutadores virtuales

Sólo puede especificar otro VR como el salto siguiente para una entrada de
enrutamiento basada en destinos solamente 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 búsqueda de rutas en un VR da lugar a búsquedas de rutas en otro VR, el
dispositivo de seguridad siempre lleva a cabo las segundas operaciones de
búsqueda 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 del 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 del reenvío, y el enrutador en 2.2.2.2 como el
siguiente salto.
Una ruta predeterminada, con ethernet3 como la interfaz del reenvío y el

enrutador en 1.1.1.1 como el siguiente salto.
La Figura 11 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 11: Consulta de rutas en múltiples VRs
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 búsquedas 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 para que el untrust-vr 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 búsquedas 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.
Configurar el enrutamiento de rutas múltiples de igual coste

Los dispositivos de seguridad de Juniper Networks admiten el enrutamiento de
rutas múltiples de igual coste (ECMP) por 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
sesión y puede que el tráfico no pueda pasar.
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 actualmente deje de estarlo.

NOTA: Al usar ECMP, si tiene dos dispositivos de seguridad en una relación de vecindad y
nota la pérdida de un paquete y un equilibrio de cargas incorrecto, compruebe la
configuración del protocolo de resolución de direcciones (Address Resolution
Protocol, ARP) del dispositivo vecino para asegurarse de que la característica arp
always-on-dest está desactivada (predeterminado). Para obtener más información
acerca de comandos relacionados con ARP, consulte “Interfaces inactivas y flujo
de tráfico” en la página 2-75.
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 desactivado, 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 activando ECMP. Con
ECMP activado, 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 activa 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 búsqueda de ruta. Con las rutas indicadas
anteriormente, el dispositivo de seguridad alterna entre ethernet3 y ethernet2 para
reenviar 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 se desactiva de forma predeterminada (el número máximo de rutas es 1).

Para activar 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 esté
establecido 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, se establece el número máximo de rutas ECMP en el

trust-vr en 2. Aunque pueda 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
reenvían 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
Redistribuir 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.
Se pueden 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: Se puede definir sólo 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.
Configurar 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 “Filtrar
rutas” en la página 42.
BGP Community Compara con una lista de comunidades determinada. Consulte “Filtrar
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 “Filtrar rutas”
en la página 42.
Metric Compara con un valor de métrica de ruta determinado
Next-hop Compara con una lista de acceso determinada. Consulte la “Filtrar rutas”
en la página 42.
Tag Compara con una dirección IP o etiqueta de ruta determinada.
Para cada condición de comparación, se especifica si una ruta que cumple la

condición es aceptada (“permitted”) o rechazada (“denied”). Si una ruta cumple
la condición y es aceptada, se 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
Conjunto de atributos Descripción

BGP AS Path Añade una lista de acceso AS path determinada al principio de lista de
atributos de camino de la ruta coincidente.
BGP Community Fija el atributo de comunidad de la ruta coincidente a la lista de
comunidades especificada.
BGP local preference Fija 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, se puede aplicar el incremento tanto a las rutas notificadas
(route-map out) o a las rutas aprendidas (route-map in). Para otras
rutas, puede aplicar el incremento a las rutas que se exportan a
otro VR.
OSPF metric type Fija el tipo de métrica OSPF de la ruta coincidente a externo tipo 1 o
externo tipo 2.
Metric Fija la métrica de la ruta coincidente al valor especificado.
Next-hop of route Fija 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 Fija la etiqueta de la ruta coincidente al valor especificado o la
dirección IP.

Filtrar rutas
El filtrado de rutas permite controlar qué rutas se admiten en una VR, cuáles se
notifican a los interlocutores y cuáles se redistribuyen de un protocolo de
enrutamiento a otro. Se pueden 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. Se pueden utilizar los siguientes mecanismos de
filtrado:
Lista de acceso: Consulte ”Configurar 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 ASs específicos. Se puede utilizar una lista de acceso
AS-path para filtrar las rutas según el AS por el que ha pasado la ruta. Consulte
“Configurar una lista de acceso AS-Path” en la página 123 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 se puede utilizar
para filtrar las rutas según las comunidades a las que pertenecen. Consulte
“Comunidades BGP” en la página 131 para obtener información sobre la
configuración de la lista de comunidades BGP.
Configurar una lista de acceso

Una lista de acceso es una lista 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). 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 en 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. Se deben 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 141.
En este ejemplo, se crea una lista de acceso en el trust-vr. La lista de acceso tiene las
siguientes características:
Identifier: 2 (se 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
Action: Permit
CLI
set vrouter trust-vr access-list 2 permit ip 1.1.1.1/24 10
save
Redistribuir rutas en OSPF

En este ejemplo, se redistribuyen determinadas rutas BGP que han pasado por el
sistema autónomo 65000 en OSPF. Primero se 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
“Configurar una lista de acceso AS-Path” en la página 123). A continuación, se
configura un mapa de rutas “rtmap1” que selecciona las rutas de la lista de acceso
AS-path. Por último, en OSPF se especifica una regla de redistribución que utiliza el
mapa de rutas “rtmap1” y luego especifica 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: rtmap1

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: rtmap1

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
ns(trust-vr)-> set route-map name rtmap1 permit 10
ns(trust-vr/rtmap1-10)-> set match as-path 1
ns(trust-vr/rtmap1-10)-> exit
ns(trust-vr)-> exit
3. Regla de redistribución
set vrouter trust-vr protocol ospf redistribute route-map rtmap1 protocol bgp
save
Exportar e importar rutas entre enrutadores virtuales

Si tenemos dos VRs configurados en un dispositivo de seguridad, se puede permitir
que rutas especificadas en un VR sean reconocidas por el otro VR. Para hacerlo, se
deben 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, se pueden 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. Definir una regla de exportación en el VR origen.
2. Definir una regla de importación en el VR destino (opcional). Aunque este paso

es opcional, una regla de importación 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. Se configura un mapa de rutas para especificar qué rutas van
a ser exportadas/importadas y los atributos de las mismas.
Se puede configurar la exportación automática de todas las entradas de la tabla de

rutas del trust-vr al untrust-vr. Se 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.

Configurar 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 se crea una lista de
acceso para el prefijo de red 1.1.1.1/24, que luego se utiliza en el mapa de rutas
“rtmap1” para filtrar las rutas de la red 1.1.1.1/24. En segundo lugar, se crea una
regla de exportación de ruta 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: rtmap1

Sequence No.: 10
Action: permit (seleccione)
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: rtmap1
Protocol: OSPF
CLI
trust-vr
1. Lista de accesos
ns(trust-vr)-> set access-list 2 permit ip 1.1.1.1/24 10
2. Mapa de rutas
ns(trust-vr)-> set route-map name rtmap1 permit 10
ns(trust-vr/rtmap1-10)-> set match ip 2
ns(trust-vr/rtmap1-10)-> exit
3. Regla de exportación
ns(trust-vr)-> set export-to vrouter untrust-vr route-map rtmap1 protocol ospf
ns(trust-vr)-> exit
save

Configurar la exportación automática

Se puede configurar la exportación automática de todas las rutas del trust-vr al
untrust-vr.
PRECAUCIÓN: Esta característica puede anular el aislamiento entre trust-vr y

untrust-vr, ya que hace que todas las rutas fiables sean visibles en la red no fiable.
Si se definen 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
Action: permit (seleccione)
Route Type: internal-ospf (seleccione)
CLI
trust-vr
set vrouter trust-vr auto-route-export
untrust-vr
set vrouter untrust-vr
ns(untrust-vr)-> set route-map name from-ospf-trust permit 10
ns(untrust-vr/from-ospf-trust-10)-> set match route-type internal-ospf
ns(untrust-vr/from-ospf-trust-10)-> exit
ns(untrust-vr)-> set import-from vrouter trust-vr route-map from-ospf-trust protocol
ospf
ns(untrust-vr)-> exit
save

Capítulo 3
Protocolo OSPF
En este capítulo se describe el protocolo de enrutamiento OSPF (Open Shortest Path

First) en los dispositivos de seguridad. Contiene 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
“Crear y eliminar una instancia de enrutamiento de OSPF” en la página 53
“Crear y eliminar un área OSPF” en la página 54
“Asignar interfaces a un área OSPF” en la página 55
“Habilitar OSPF en interfaces” en la página 56
“Comprobar la configuración” en la página 58
“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
“Notificar la ruta predeterminada” en la página 62
“Conexiones virtuales” en la página 63
“Ajustar parámetros de interfaz OSPF” en la página 65
47
“Configuración de seguridad” en la página 67
“Autenticar vecinos” en la página 67
“Configurar una lista de vecinos de OSPF” en la página 68
“Rechazar rutas predeterminadas” en la página 69
“Proteger contra inundaciones” en la página 70
“Crear 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 72
“Establecer el tipo de conexión OSPF” en la página 72
“Inhabilitar la restricción Route-Deny” en la página 72
“Crear 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 (AS). 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 LSAs 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 LSAs 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, cada
enrutador tiene su propio árbol de rutas más cortas, ya que cada uno genera su
árbol y se coloca en su parte superior..
Á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: Protocolo OSPF
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 63.
Las notificaciones externas de AS describen rutas a destinos en otros sistemas AS e

inundan 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 NSSAs (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 borde 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 borde 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 LSAs 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 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 de no 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 72.
Notificaciones de estado de conexiones

Cada enrutador OSPF envía notificaciones de estado de conexiones (LSAs) 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, donde se abarca cada tipo y el contenido de cada
tipo de LSA.
Tabla 5: Resumen del contenido y tipos de LSA
Distribuido
Tipo de LSA Enviado por por 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 borde de área Área Describe una ruta a un destino fuera del área, pero dentro
resumen del sistema autónomo. Hay dos tipos:
Las LSAs de resumen de tipo 3 describen rutas a redes.
Las LSAs 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 de 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 borde
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

borde 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 12.
Figura 12: Ejemplo de configuración de OSPF
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 “Ajustar parámetros de interfaz OSPF” en la
página 65).
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

Crear y eliminar una instancia de enrutamiento de OSPF

Es posible crear y habilitar una instancia de enrutamiento de OSPF en un VR
específico ubicado en un dispositivo de seguridad. Para eliminar una instancia de
enrutamiento de OSPF, desactive la instancia OSPF y luego elimínela. Al crear la
instancia de enrutamiento de OSPF se crea automáticamente el área troncal OSPF.
Si crea y habilita una instancia de enrutamiento de OSPF en un enrutador virtual,
OSPF podrá transmitir y recibir paquetes en todas las interfaces habilitadas para
OSPF del enrutador.
Crear 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 de OSPF en él. (Para
obtener más información sobre enrutadores virtuales y su configuración en
dispositivos de seguridad, consulte el Capítulo 2, “Enrutamiento.”)
WebUI
1. ID de enrutador

2. Instancia de enrutamiento de 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 de 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 de

OSPF antes de poder habilitarla. Por lo tanto, tendrá que ejecutar dos comandos
CLI para habilitar una instancia de enrutamiento de OSPF.
Eliminar una instancia de OSPF

En este ejemplo inhabilitará la instancia de enrutamiento de 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] y
save
NOTA: En CLI, confirme la eliminación de la instancia OSPF.
Crear y eliminar 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 LSAs de
que las LSAs 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 LSAs de
resumen, y si éstas se notificarán o no.
Crear 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
Eliminar 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:
Anule la selección de 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
Asignar interfaces a un área OSPF

Una vez se ha creado un área, es posible asignarle una o varias interfaces, ya sea
utilizando la WebUI o el comando CLI set interface.
Asignar interfaces a áreas

En el siguiente ejemplo asignará la interfaz ethernet1 al área OSPF 10 y la interfaz
ethernet3 al área 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

Configurar un rango de áreas

De forma predeterminada, un enrutador de borde 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
Habilitar 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 de OSPF en el enrutador virtual

(consulte “Eliminar 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.
Habilitar OSPF en interfaces

En este ejemplo habilitará la instancia de enrutamiento de 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 de 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 de OSPF en el enrutador virtual, OSPF

dejará de transmitir y procesar paquetes en todas las interfaces del enrutador que
tengan este protocolo habilitado (consulte “Eliminar una instancia de OSPF” en la
página 53).

Comprobar la configuración
Puede ver la configuración introducida para trust-vr ejecutando el siguiente
comando CLI:
ns-> 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.
ns-> get vrouter trust-vr protocol ospf

----------------------------------
OSPF enabled
Supports only single TOS(TOS0) route
Internal Router
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 más información sobre cómo configurar una
ID de enrutador, consulte el Capítulo 2, “Enrutamiento.”

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.
ns-> 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 del estado (State) enumerar la prioridad del
enrutador virtual.
Puede verificar si la instancia de enrutamiento de OSPF en el dispositivo de

seguridad ha establecido adyacencias con los vecinos OSPF ejecutando el
comando get vrouter trust-vr protocol ospf neighbor.
ns-> 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 de 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.”
Redistribución de rutas en protocolos de enrutamiento 59

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
Resumen de rutas redistribuidas

En las grandes redes, donde pueden coexistir miles de direcciones de red, ciertos
enrutadores podrían llegar a congestionarse por la gran cantidad de información de
rutas. 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 LSAs se propaguen por otras
áreas cuando una de las redes incluidas en el resumen desaparece (por un fallo) o
reaparece. 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.
60 Resumen de rutas redistribuidas

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
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 predeterminada no
virtual se notifica en todas las áreas OSPF. También se notifica.
es 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 predeterminada
de 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 10.
packets saludo OSPF que el VR puede recibir en un intervalo
de saludo.
Parámetros globales de OSPF 61

Parámetros Valor
globales de OSPF Descripción predeterminado
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 de OSPF OSPF versión 2, tal
compatibility es compatible con la norma RFC 1583, una versión y como se define
anterior de OSPF. en RFC 2328.
Equal cost Especifica el número máximo de rutas (1-4) a utilizar Desactivado (1).
multipath routing para equilibrar cargas con los destinos que tengan
(ECMP) múltiples rutas de igual coste. Consulte “Configurar el
enrutamiento de rutas múltiples de igual coste” en la
página 37.
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 muerto del interlocutor
para la conexión virtual.
Notificar 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 ingresarse 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
62 Parámetros globales de OSPF

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 10 segundos
saludos OSPF.
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.
Crear 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 IDs 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 13 muestra el ejemplo de configuración de red para una conexión virtual.
Parámetros globales de OSPF 63

Figura 13: Creación de una conexión virtual
Área 0
Área 10 Dispositivo-B
ethernet1 ethernet2
ID de Internet
enrutador
10.1.1.250
Dispositivo-A ethernet 1
Enrutador
10.1.1.250 El Dispositivo-A y el Dispositivo-B
ethernet 2 tienen una conexión virtual entre sí
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.
WebUI (Dispositivo-A)
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.
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.
WebUI (Dispositivo-B)
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.
64 Parámetros globales de OSPF

CLI (Dispositivo-B)
transit-delay 10
save
Crear 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
Ajustar parámetros de interfaz OSPF

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.
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 de
interfaz OSPF 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 100MB 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, 10MB
menor será el valor del coste (preferible). 100 para una conexión
de 1MB
Ajustar parámetros de interfaz OSPF 65

Parámetro de
interfaz OSPF Descripción Valor predeterminado
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 “Interfaz de túnel punto a multipunto” en de difusión.
la página 72. 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 y
como ruta externa, pero que la interfaz no 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.
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 “Crear un circuito de demanda OSPF en
una interfaz de túnel” en la página 71.
Reduce flood Especifica la reducción de inundaciones LSA en un Desactivado.
circuito de demanda.
Ignore MTU Especifica que cualquier incoherencia en los valores Desactivado.
Maximum Transmission Unit (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 el MTU de la interfaz local sea más lento
que el 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.
66 Ajustar parámetros de interfaz OSPF

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
Configuración de seguridad
En esta sección se describen posibles problemas de seguridad en el dominio de
enrutamiento OSPF y ciertos 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 inservible todo el domino de
enrutamiento OSPF.
Autenticar 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. Se descartarán
todos los paquetes OSPF recibidos en la interfaz que no se autentiquen. 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 seguridad 67
Configurar 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
Configurar 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 tenga que
especificar el identificador de clave para la primera clave MD5 que introduzca.
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
Configurar 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 de OSPF
definiendo una lista de subredes que contengan vecinos OSPF que se puedan elegir.
68 Configuración de seguridad
Sólo los hosts o enrutadores que se encuentren en la subredes definidas podrán

formar adyacencias con la instancia de enrutamiento de 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
CLI
set vrouter trust-vr access-list 4
set interface ethernet1 protocol ospf neighbor-list 4
save
Rechazar 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
Proteger contra inundaciones

Un enrutador peligroso o que no funcione correctamente puede inundar a sus
vecinos con paquetes de saludo OSPF o con LSAs. Cada enrutador capta la
información de las LSAs 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 LSAs que entrarán en el
enrutador virtual (VR). Si éste recibe demasiadas LSAs, el enrutador fallará por una
inundación LSA. Los ataques por LSAs se producen cuando un enrutador genera
un número excesivo de LSAs 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
LSAs 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 LSAs predefinido; si no impone un
límite de LSAs, se aceptarán todas.
Configurar un límite de saludo

En el siguiente ejemplo configuraremos un límite 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
Configurar un límite de LSAs

En este ejemplo estableceremos un límite OSPF de 10 paquetes LSA cada 20
segundos para evitar ataques por inundación de LSAs.
WebUI
LSA Packet Threshold Time: 20

Maximum LSAs: 10
CLI
set vrouter trust-vr protocol ospf lsa-threshold 20 10
save
Habilitar 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 interfaz 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
Reduce Flooding: (seleccione)
CLI
set interface tunnel.1 protocol ospf reduce-flooding
save
Crear un circuito de demanda OSPF en una interfaz de túnel

Los circuitos de demanda de OSPF, según lo definido en RFC 1793, son segmentos
de red en los que el tiempo de conexión o de utilización afecta al coste de utilizar
tales conexiones. En un circuito de demanda, el tráfico generado por OSPF necesita
ser limitado 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 de 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 comoos 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 LSAs del enrutador y
de la red reflejan a todos los vecinos adyacentes), el dispositivo de seguridad
suprime los paquetes de saludo periódicos y LSA se actualiza. El dispositivo de
seguridad inunda solamente LSAs 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 y haga
clic en Apply:
Demand Circuit: (seleccione)

CLI
set interface tunnel.1 protocol ospf demand-circuit
save
Crear un circuito de demanda OSPF en una interfaz de túnel 71

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.
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
“Crear un circuito de demanda OSPF en una interfaz de túnel” en la página 71).
Sin embargo, puede configurar la interfaz para la inundación LSA reducida.
Para ver un ejemplo de asociación de múltiples túneles a una interfaz de túnel,

consulte “Asociar entradas automáticas en la tabla de rutas y en la tabla NHTB” en
la página 5-278. Las siguientes secciones incluyen ejemplos para:
Establecer el tipo de conexión (consulte “Establecer el tipo de conexión OSPF”

en esta página)
Establecer la característica route-deny (consulte “Inhabilitar la restricción

Route-Deny” en esta página)
Configurar una red con una interfaz de túnel de punto a multipunto (consulte
“Crear 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” en la
lista de botones de opción “Link Type”.
CLI
set interface tunnel.1 protocol ospf link-type p2mp
save
Inhabilitar la restricción Route-Deny

De forma predeterminada, potencialmente 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 ni 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.
72 Interfaz de túnel punto a multipunto

WebUI
NOTA: Para establecer la restricción route-deny debe utilizarse la CLI.
CLI
unset interface tunnel.1 route-deny
save
Crear una red punto a multipunto

La Figura 14 muestra una empresa de tamaño mediano con su oficina central (CO)
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 CO:
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 VPNs 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, a

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 14 muestra el escenario descrito
de la red.
Interfaz de túnel punto a multipunto 73

Figura 14: 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 (CO)

ethernet3 1.1.1.1
tunnel.1 10.0.0.1
4 VPNs asociadas a
tunnel.1
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 CO:
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. Directivas

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 a 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” en 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
set interface tunnel.1 protocol ospf enable
set interface tunnel.1 protocol ospf link-type p2mp
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 LSAs.
Para completar la configuración mostrada en la Figura 14 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. Directivas
Policies (from All zones to All zones) > 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
set interface tunnel.1 protocol ospf enable

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 vrouter 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. Contiene
las siguientes secciones:
“Configuración básica de RIP” en la página 81
“Crear y eliminar una instancia RIP” en la página 82
“Habilitar y deshabilitar RIP en interfaces” en la página 83
“Visualizar la información de RIP” en la página 85
“Visualizar la base de datos RIP” en la página 85
“Visualizar los detalles de RIP” en la página 86
“Visualizar información de vecino RIP” en la página 87
“Visualizar detalles de RIP para una interfaz específica” en la página 88
“Parámetros globales de RIP” en la página 89
“Notificar la ruta predeterminada” en la página 90
“Configurar los parámetros de interfaz de RIP” en la página 91
“Autenticar vecinos mediante una contraseña” en la página 92
“Configurar vecinos fiables” en la página 93
“Proteger contra inundaciones” en la página 95
79
“Configuraciones opcionales de RIP” en la página 97
“Configurar la versión de RIP” en la página 97
“Habilitar y deshabilitar un resumen de prefijo” en la página 99
“Ajustar rutas alternas” en la página 100
“Circuitos de demanda en interfaces de túnel” en la página 101
“Configurar un vecino estático” en la página 103
“Configurar una interfaz de túnel punto a multipunto” en la página 103
Vista general
El protocolo 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: 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 error impredecible en
el enrutamiento.
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. RIP admite redes punto a punto (utilizadas con VPNs) y redes
Ethernet de difusión/multidifusión (broadcast/multicast). 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.
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 a la dirección 224.0.0.9 del puerto RIP.
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:
80 Vista general
Capítulo 4: Protocolo de información de enrutamiento
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.

Capítulo 2, “Enrutamiento”.
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.
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 “Configurar los
parámetros de interfaz de RIP” en la página 91)
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)
Configuración básica de RIP 81

Crear y eliminar 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).
Crear 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
identificación de enrutador virtual 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.
Eliminar 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
82 Configuración básica de RIP

Habilitar y deshabilitar RIP en interfaces

De forma predeterminada, 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 “Eliminar una instancia RIP” en la página 82), 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.
CLI
unset interface trust protocol rip enable
unset interface trust protocol rip
save
Redistribuir 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
Configuración básica de RIP 83

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 Capítulo 2, “Enrutamiento”.
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 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)
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
84 Configuración básica de RIP

Visualizar 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)
Vecino
Visualizar 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
Después de introducir el siguiente comando CLI, puede visualizar la entrada de la

base de datos RIP:
ns-> 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)
Visualizar la información de RIP 85

Ifp, el tipo de conexión (Ethernet o túnel)
La métrica de coste asignada para indicar la distancia desde el origen
Flags, pueden ser uno o varios de lo siguiente: multipath (M), RIP (R), Redistributed
(I), Advertised default (D), Permanent (P), Summary (S), Unreachable (U) o Hold (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 flags son M y R e indican que esta ruta es multidireccional y usa RIP.
Visualizar 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
Este comando produce resultados similares al siguiente resultado:
ns-> 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.
86 Visualizar la información de RIP

Visualizar 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
ns-> 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
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
Flags: static (S), demand circuit (T), NHTB (N), down (D), up (U), poll (P) o
demand circuit init (I)
Visualizar la información de RIP 87

Visualizar 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
ns-> 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
Desde este resumen de información puede visualizar el número de paquetes

incorrectos o de rutas incorrectas presentes, verificar cualquier sobrecarga que RIP
añada a la conexión y ver la configuración de la autenticación.
88 Visualizar la información de RIP

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 Valor(es)
global de RIP Descripción predeterminado(s)
Default metric Valor métrico predeterminado para rutas importadas 10
en RIP a partir de otros protocolos, como OSPF y BGP.
Update timer Indica (en segundos) cuándo enviar actualizaciones de 30 segundos
rutas RIP a los dispositivos vecinos.
Maximum Indica el número máximo de paquetes recibidos por Sin máximo
packets per actualización.
update
Invalid timer Indica el tiempo (en segundos) que tiene que 180 segundos
transcurrir para que una ruta deje 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 120 segundos
transcurrir para que se elimine una ruta desde el
momento de su invalidación.
Maximum Indica el número máximo de vecinos RIP permitidos. Depende de la
neighbors plataforma
Trusted Indica una lista de acceso en la que se definen los Todos los vecinos
neighbors vecinos RIP. Si no se especifica ningún vecino, RIP son fiables
utiliza la difusión o la multidifusión para detectar
vecinos en una interfaz. Consulte “Configurar vecinos
fiables” en la página 93.
Allow neighbors Indica que se admiten vecinos RIP de otras subredes. Desactivado
on different
subnet
Advertise default Indica si se notifica la ruta predeterminada (0.0.0.0/0). Desactivado
route
Reject default Indica si RIP debe rechazar una ruta predeterminada Desactivado
routes reconocida de otro protocolo. Consulte “Rechazar rutas
predeterminadas” en la página 94.
Incoming route Indica el filtro para las rutas que RIP debe reconocer. Ninguna
map
Outgoing route Indica el filtro para las rutas que RIP debe notificar. Ninguna
map
Maximum Especifica el número máximo de rutas RIP para el 0
alternate routes mismo prefijo que se puede añadir a la base de datos
de la ruta RIP. Consulte “Ajustar rutas alternas” en la
página 100.
Parámetros globales de RIP 89

Parámetro Valor(es)
global de RIP Descripción predeterminado(s)
Summarize Especifica la notificación de una ruta de resumen que Ninguna
advertised routes corresponde a todas las rutas incluidas dentro de un
rango de resumen. Consulte “Habilitar y deshabilitar un
resumen de prefijo” en la página 99.
RIP protocol Especifica la versión de RIP que utiliza el VR. Puede Versión 2
version ignorar la versión interfaz a interfaz. Consulte
“Configurar la versión de RIP” en la página 97.
Hold-timer Evita el “flapping” (rechazo) de una ruta a la tabla de 90 segundos
rutas. Puede especificar un 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 5 segundos
respuestas desencadenadas en un circuito de demanda. 10 reintentos
Puede establecer el temporizador de retransmisión y
asignar una cuenta de reintentos que se ajuste a sus
necesidades de red.
Poll-timer Comprueba el vecino remoto del circuito de demanda 180 segundos
para ver si está activa la conexión con ese vecino. 0 reintentos
Puede configurar el temporizador de retransmisión en
minutos y asignar una cuenta de reintentos que se
ajuste a sus necesidades de red. Una cuenta de
reintentos de cero (0) supone un sondeo interminable.
Notificar 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 adv-default-route metric number 5
save
NOTA: Consulte el manual ScreenOS CLI Reference Guide para obtener más información
sobre los parámetros globales que se pueden configurar en el contexto del
protocolo de enrutamiento RIP.
90 Notificar la ruta predeterminada

Configurar 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.
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
Valor
Parámetro RIP de interfaz Descripción predeterminado
Split-horizon Indica si está habilitada la opción de La opción de
horizonte dividido (no notificar rutas horizonte dividido
reconocidas de una interfaz en está habilitada. Las
actualizaciones enviadas a dicha interfaz, rutas inalcanzables
“split horizon”). Si está habilitada la opción están inhabilitadas.
de 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
Autenticación Especifica la autenticación por contraseña No se utiliza
de texto no encriptado o la autenticación autenticación.
MD5. Consulte “Autenticar vecinos
mediante una contraseña” en la página 92.
Passive mode Indica que la interfaz puede recibir, pero no No
transmitir paquetes RIP.
Incoming route map Indica el filtro para las rutas que RIP debe Ninguna.
reconocer.
Outgoing route map Indica el filtro para las rutas que RIP debe Ninguna.
notificar.
RIP version for sending or Especifica la versión de protocolo RIP Versión configurada
receiving updates utilizada para enviar o recibir para el enrutador
actualizaciones en la interfaz. La versión de virtual.
la interfaz utilizada para enviar
actualizaciones no necesita ser la misma
que la versión para recibir las
actualizaciones. Consulte “Configurar la
versión de RIP” en la página 97.
Route Summarization Especifica si los resúmenes de rutas están Desactivado.
habilitados en la interfaz. Consulte
“Habilitar y deshabilitar un resumen de
prefijo” en la página 99.
Demand-circuit Especifica el circuito de demanda en una Ninguna.
interfaz de 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 Ninguna.
asignado manualmente.
Configurar los parámetros de interfaz de RIP 91

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 “Configurar
un mapa de rutas” en la página 40.
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.
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 ciertos métodos de prevención de ataques.
NOTA: Para que RIP sea más seguro, todos los enrutadores de un dominio RIP deben
configurarse con el mismo nivel de seguridad. De lo contrario, un solo enrutador
RIP comprometido podría llegar a dejar inservible todo el domino de
enrutamiento RIP.
Autenticar vecinos mediante 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 a 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
Configurar 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
ns(trust-vr)-> set access-list 10 permit ip 10.1.1.1/32 1
ns(trust-vr)-> set protocol rip
ns(trust-vr/rip)-> set max-neighbor-count 1
ns(trust-vr/rip)-> set trusted-neighbors 10
ns(trust-vr/rip)-> exit
ns(trust-vr)-> exit
save

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
Proteger 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.
Configurar 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
Habilitar 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 15 muestra el escenario de la red que se describe.
Figura 15: Ejemplo de interfaz de túnel con RIP
Zona Untrust
Zona Trust
10.20.0.0/16 Dispositivo-A (RIP) Dispositivo-B (RIP) 1.1.1.1/16

Internet
Túnel VPN 2.2.2.2/16

10.10.0.0/16
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 datos
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.
Configurar 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.
Configuraciones opcionales de RIP 97

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 para Version, luego haga clic en Apply.
Network > Interfaces > Edit (para ethernet3) > RIP: Seleccione V2 para
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.
ns-> 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.
98 Configuraciones opcionales de RIP

Habilitar y deshabilitar un resumen de prefijo

Puede configurar una ruta de resumen que englobe el rango de prefijos de ruta al
que RIP deberá notificar. Entonces, el dispositivo de seguridad notifica solamente la
ruta que corresponde al rango de resumen en lugar de notificar individualmente
cada ruta incluida en el rango de 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 establecer una interfaz NULL, consulte“Impedir la
creación de bucles por las rutas resumidas” en la página 11.
Habilitar un resumen de prefijo

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 (para 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 > Interface 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
Ajustar rutas alternas

El dispositivo de seguridad mantiene una base de datos RIP para las rutas que ha
reconocido 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 rápida en caso de error.
NOTA: Recomendamos el uso de rutas alternativas con los circuitos 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.
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
vrouter 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.

ns-> 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

“Configurar el enrutamiento de rutas múltiples de igual coste” en la página 37) y
existen rutas múltiples de igual coste en la base de datos RIP para un prefijo dado,
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 > Edit (for 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. Sobrecarga mínima de red en términos del paso de mensajes entre los
puntos extremo del circuito de demanda. Los circuitos de demanda de RIP,
definidos por 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 evitar la sobrecarga, el dispositivo de
seguridad envía la información 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 reconoce los vecinos RIP mediante la configuración de
vecinos estática; y si se desactiva el túnel VPN, el RIP limpia las rutas reconocidas
desde la dirección IP del vecino.
Las rutas reconocidas 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 antes accesible cambia a inalcanzable en una respuesta entrante
El túnel VPN se desactiva o el circuito de demanda está desactivado 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
pueden reconocerse mutuamente.
Debe configurar la supervisión de VPN con reencriptación en los túneles VPN para
reconocer 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ágina104.
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 vrouter 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 POLL.
Configurar 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 reconozca 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
Configurar una interfaz de túnel punto a multipunto

RIP punto a multipunto se admite en interfaces de túnel numeradas para las
versiones 1 y 2 de RIP.
PRECAUCIÓN: 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
error impredecible en el enrutamiento.
Configurar una interfaz de túnel punto a multipunto 103

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 reconoce dinámicamente a los vecinos. 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 discutimos 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 (CO) 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 CO:
1. Configurar el VR para que ejecute una instancia de RIP, habilitar RIP y, a

2. Configurar las cuatro VPNs y asociarlas a la interfaz tunnel.1.
3. Configurar vecinos estáticos RIP en el dispositivo de seguridad de la oficina

central (CO).
4. No cambiar 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. Configurar el VR para que ejecute una instancia de RIP, habilitar RIP y, a

2. Configurar la VPN y asociarla a la interfaz tunnel.1.
3. No configurar 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.
NOTA: No es necesario cambiar los valores predeterminados del temporizador en

este ejemplo.
104 Configurar una interfaz de túnel punto a multipunto

Figura 16: 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

Untrust 1.1.1.3 Untrust 1.1.1.4
Nueva York Chicago
tunnel.1 10.0.0.2 tunnel.1 10.0.0.5

Untrust 1.1.1.2 Untrust 1.1.1.5
Internet
VPN 1 VPN 2 VPN 3 VPN 4
San Francisco (CO)

ethernet3 1.1.1.1
tunnel.1 10.0.0.1
4 VPNs asociadas a tunnel.1
En el diagrama de red que se muestra en la Figura 16, 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 CO:
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

CO, 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
configuración.
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 en RIP, luego 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 reconoce 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ágina105, 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)

configuración.
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 en RIP, luego 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 vrouter 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 vrouter protocol rip database. P de
permanent aparece junto a las entradas de los circuitos de demanda.

Capítulo 5
Protocolo BGP
En este capítulo se describe el protocolo BGP (protocolo de puerta de enlace de
borde, o Border Gateway Protocol) en los dispositivos de seguridad de Juniper
Networks. Contiene 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 111
“Configuración básica de BGP” en la página 112
“Crear y habilitar una instancia de BGP” en la página 113
“Habilitar y deshabilitar BGP en interfaces” en la página 114
“Configurar grupos de interlocutores e interlocutores BGP” en la página 115
“Comprobar la configuración BGP” en la página 118
“Autenticar vecinos BGP” en la página 120
“Redistribuir rutas en BGP” en la página 122
“Configurar una lista de acceso AS-Path” en la página 123
“Agregar rutas a BGP” en la página 124
“Capacidad de enrutamiento-actualización” en la página 126
“Configuración de la reflexión de rutas” en la página 127
“Configurar una confederación” en la página 130
“Comunidades BGP” en la página 131
“Agregar rutas” en la página 132
109
Vista general
El protocolo BGP (Border Gateway Protocol) 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.
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.
110 Vista general

Capítulo 5: Protocolo BGP
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.
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).
Ciertos atributos de ruta sólo son aplicables a EBGP o 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.
Vista general 111

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.

Capítulo 2, “Enrutamiento”.
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 17 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.
Figura 17: Ejemplo de configuración BGP
Número del Número del

sistema sistema
autónomo autónomo
Sistemas autónomos
AS 65000 AS 65500
Dispositivo de seguridad local Enrutador remoto
ID del enrutador Dirección IP de Dirección IP de

1.1.1.250 interfaz 1.1.1.1/24 interfaz 2.2.2.2/24 ID de enrutador
BGP habilitado BGP habilitado 2.2.2.250
Interlocutores BGP
112 Configuración básica de BGP

Crear y habilitar 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 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 exclusivos en todo el
mundo 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.
Crear 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).
WebUI
1. ID de enrutador

En el cuadro de texto, escriba 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
Configuración básica de BGP 113

Eliminar 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
Habilitar y deshabilitar 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).
Habilitar BGP en interfaces

En este ejemplo habilitará BGP en la interfaz ethernet4.
WebUI
Network > Interface Edit > BGP: Marque la habilitación de Protocol BGP,
luego haga clic en OK.
CLI
set interface ethernet4 protocol bgp
save
Inhabilitar 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): Desactive Protocol BGP,
luego haga clic en OK.
CLI
unset interface ethernet4 protocol bgp
save

Configurar 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
Parámetro Grupo de
BGP Interlocutor interlocutores Descripción Valor predeterminado
Advertise X Notifica la ruta predeterminada en el enrutador La ruta predeterminada
default route virtual a interlocutores BGP. no se notifica.
EBGP multihop X X Número de nodos entre el BGP local y el vecino. 0 (desactivado)
Force connect X X Hace que la instancia de BGP descarte una conexión N/D
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 falla y, a continuación, reaparece 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 de 180 segundos
un interlocutor antes de que se considere fuera
de servicio.
Keepalive X X Tiempo entre transmisiones de mantenimiento de 1/3 del tiempo de
conexión (keepalive). espera (hold-time)
MD5 X X Configura la autenticación MD-5. Sólo se comprueba
authentication el identificador de
interlocutor y el
número de AS.
MED X Configura el valor de atributo MED. 0

Parámetro Grupo de
BGP Interlocutor interlocutores Descripción Valor predeterminado
Next-hop self X X En las rutas enviadas al interlocutor, el atributo de Atributo de salto
ruta al salto siguiente se ajusta en la dirección IP de siguiente no cambiado
la interfaz del enrutador virtual local.
Reflector client X X El interlocutor es un cliente de reflexión cuando el Ninguna
protocolo BGP local se configura como el reflector
de rutas.
Reject default X No tiene en cuenta las notificaciones de ruta Las rutas
route predeterminada procedentes de los predeterminadas de los
interlocutores BGP. interlocutores se
agregan a la tabla de
enrutamiento
Retry time X X Tras un intento fallido de inicio de sesión, tiempo 120 segundos
que se tarda en reintentar iniciar la sesión BGP.
Send X X Transmite el atributo de comunidad al interlocutor. Atributo de comunidad
community no enviado a los
interlocutores.
Weight X X Prioridad de ruta entre el BGP local y el interlocutor. 100
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 ciertos parámetros en el nivel de interlocutores y en el de

protocolo (consulte “Configurar una confederación” en la página 130). 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.
Configurar 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
Configurar 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
y luego haga clic en OK.
Instance > Neighbors > Configure (para 10.1.3.250): Seleccione Peer Enabled
y luego haga clic en OK.
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
Comprobar la configuración BGP

Puede revisar la configuración introducida a través de WebUI o CLI ejecutando el
comando get vrouter vrouter protocol bgp config.
ns-> 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 vrouter protocol bgp.
ns-> get vrouter trust-vr protocol bgp

Admin State: enable
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: 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 el Capítulo 2, “Enrutamiento”.
Para verificar si un interlocutor o grupo de interlocutores BGP está habilitado y

ver el estado de la sesión de BGP, ejecute el comando get vrouter vrouter protocol
bgp neighbor.
ns-> 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
configurarse con el mismo nivel de seguridad. De lo contrario, un solo enrutador BGP
comprometido podría llegar a dejar inservible todo el domino de enrutamiento BGP.

Autenticar 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

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. En esta sección también se muestran algunas 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 “Agregar Desactivado
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 131.
AS confederation Crea confederaciones. Consulte —
“Configurar una confederación” en la
página 130.
Equal cost multipath Se pueden agregar rutas múltiples de igual Desactivado
(ECMP) coste para proporcionar equilibrio de (predeterminado = 1)
cargas. Consulte “Configurar el
enrutamiento de rutas múltiples de igual
coste” en la página 37.
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 servicio.
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
Configuraciones opcionales de BGP 121

Parámetro del protocolo

BGP Descripción Valor predeterminado
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 124.
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 127.
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.
Redistribuir 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
Capítulo 2, “Enrutamiento.”
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.
122 Configuraciones opcionales de BGP

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
Configurar 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
bajos 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 notifique 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 notificará 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 “Configurar un mapa de rutas” en la página 40). El BGP anuncia la
ruta con los atributos de ruta especificados en el mapa de rutas.
Notificar 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 18.

Figura 18: 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 está accesible.
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
Establecer el 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
Establecer atributos de ruta

En el ejemplo siguiente configurará un comando 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 la ruta. (No es necesario
establecer el mapa de la ruta de forma que coincida con el prefijo de red de
la entrada de la ruta).

WebUI
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 enrutamiento-actualización
La característica de enrutamiento-actualización de BGP definida en RFC 2918 ofrece
un mecanismo de restablecimiento liviano 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 a 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 al efectuar un restablecimiento liviano o abrupto.
NOTA: Un restablecimiento abrupto es perjudicial porque las sesiones BGP activas se

interrumpen y seguidamente vuelven a restablecerse.
Un restablecimiento liviano permite que se aplique una directiva nueva

o modificada sin borrar una sesión BGP activa. La característica de
enrutamiento-actualización permite que se realice un restablecimiento liviano
por vecino y no requiere configuración previa o memoria adicional.
Un restablecimiento liviano entrante y dinámico se utiliza para generar

actualizaciones entrantes de un vecino. Un restablecimiento liviano 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 el soporte de la característica de enrutamiento-actualización en el
mensaje de apertura (OPEN). Si el método de enrutamiento-actualización se
negocia satisfactoriamente, cualquier interlocutor BGP puede utilizar la
característica de enrutamiento-actualización para solicitar información
completa sobre el enrutamiento desde el otro extremo.
NOTA: Los administradores utilizan el comando get neighbor dir_ip para verificar si se
negoció la capacidad de enrutamiento-actualización. El comando también
muestra contadores, como el número de veces en que se envió o recibió la
solicitud de enrutamiento-actualización.
Solicitar 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 enrutamiento-actualización 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
Solicitar 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 111),
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
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 Figura 19.

Figura 19: Ejemplo de reflexión de rutas BGP
Número del Número del

sistema sistema
autónomo Sistemas autónomos autónomo
AS 65000 AS 65500
ID del enrutador
Cliente 1 2.2.2.250
ID del enrutador
1.1.3.250
Dispositivo-A
ID del enrutador Cliente 3 Ruta de
del reflector de ID del enrutador notificación de
Cliente 2 rutas 1.1.1.250 1.1.1.250 interlocutor EBGP
ID del enrutador a 5.5.5.0/24
1.1.4.250
WebUI
Instance: Introduzca los siguientes datos y 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 remota IP 1.1.3.250): Seleccione Reflector Client, luego

haga clic OK.
> Configure (para remota 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 127), 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 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 20
ilustra las confederaciones BGP.
Figura 20: 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.
La Figura 21 muestra 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 21: 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 y 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 confederation id 65000
set vrouter trust-vr protocol bgp confederation peer 65001
set vrouter trust-vr protocol bgp confederation peer 65002
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 ISPs vecinos. Las rutas de otros ISP recibirán otros números de
comunidad y no se notificarán a los ISPc vecinos.
Agregar 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.
Agregar 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 y 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.
Suprimir 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
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
Access List ID: 1

Sequence No.: 777
Map Name: noadvert

Sequence No.: 2
Match Properties:
Access List (seleccione), 1 (seleccione)
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
Seleccionar 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 notificará

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)
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 notificará con la métrica 1111 en las actualizaciones salientes.
WebUI
Map Name: aggmetric

Sequence No.: 5
Set Properties: (seleccione)
Metric: 1111

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 multicast
Este capítulo presenta los conceptos básicos sobre el enrutamiento multicast.

Contiene las siguientes secciones:
“Direcciones multicast” en la página 138
“Reenviar rutas inversas” en la página 138
“Enrutamiento multicast en dispositivos de seguridad” en la página 139
“Tabla de enrutamiento multicast” en la página 139
“Configurar una ruta multicast estática” en la página 140
“Listas de acceso” en la página 141
“Configurar el encapsulado genérico de enrutamiento en interfaces de

túnel” en la página 141
“Directivas multicast” en la página 143
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
señalizar 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 tráfico
multicast solamente a los receptores interesados en recibirlo.
Vista general 137

Los entornos de enrutamiento multicast requieren los siguientes elementos para

reenviar información multicast:
Un mecanismo entre hosts y enrutadores para comunicar información de

miembros del grupo multicast. Los dispositivos de seguridad admiten las
versiones 1, 2 y 3 de IGMP (Internet Group Management Protocol). 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 el Capítulo 7, “Protocolo IGMP”).
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 Protocol Independent Multicast -
Sparse Mode (PIM-SM) y Protocol Independent Multicast - Source Specific
Multicast (PIM-SSM). (Para obtener información sobre PIM-SM y PIM-SSM,
consulte el Capítulo 8, “Multicast independiente de protocolo (PIM)”).
Alternativamente, puede utilizar la característica IGMP Proxy para reenviar

tráfico multicast sin sobrecargar la CPU con la ejecución de un protocolo de
enrutamiento multicast. (Para obtener información sobre IGMP Proxy, consulte
“Proxy de IGMP” en la página 155).
Las siguientes secciones presentan los conceptos básicos utilizados en el

enrutamiento multicast.
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.
Reenviar 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 búsqueda 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.
138 Vista general

Capítulo 6: Enrutamiento multicast
Figura 22: Reenvío por rutas inversas
1. El paquete multicast
procedente de 1.1.1.250 ethernet3
llega a ethernet1. 10.1.1.1
Origen enrutador ethernet1 2. El dispositivo de

3.3.3.6 externo 1.1.1.1 seguridad comprueba 3a. En caso afirmativo,
1.1.1.250 si la interfaz de enviar los paquetes
entrada coincide con multicast al destino.
la de salida para los
paquetes destinados
al remitente.
3b. En caso negativo, descartar el paquete.

Consulta en la tabla de rutas
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 (VRs): 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 el
Capítulo 1, “Enrutamiento estático”). Cuando el dispositivo de seguridad recibe
un paquete multicast entrante, realiza una consulta de rutas a través de la tabla
de rutas multicast.
Tabla de enrutamiento multicast

La tabla de rutas multicast se alimentan con las rutas estáticas multicast o las rutas
aprendidas a través de 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 139

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 00: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
Downstream :
ethernet1/2 00:06:24/- Join 236.1.1.1 20.20.20.200 FC
Configurar 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 “IGMP router
proxy” a los enrutadores en sentido ascendente de las interfaces en el modo host
de IGMP. (Para obtener información sobre IGMP Proxy, consulte “Proxy de IGMP”
en la página 155). 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
140 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 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 accesos para permitir tráfico multicast a
determinados grupos o hosts multicast. Por lo tanto, el estado de la acción o del
reenvío es siempre Permit. No se pueden crear listas de accesos para denegar
ciertos grupos o hosts. (Para obtener información adicional sobre listas de accesos,
consulte “Configurar una lista de acceso” en la página 42).
Configurar el encapsulado genérico de enrutamiento 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 GRE (encapsulado genérico
de enrutamiento, Generic Routing Encapsulation) 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, Generic Routing Encapsulation (GRE).
En los dispositivos de seguridad, la encapsulación GRE se habilita 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 más información sobre interfaces de
bucle invertido, consulte “Interfaces de bucle invertido (loopback)” en la
página 2-60.
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 creando 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 141

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 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 transmitir paquetes multicast, Enrutador-A 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
Dispositivo A
Túneles VPN
con GRE
Dispositivo-1 Dispositivo-2
Receptores Receptores
En este ejemplo, configurará la interfaz de túnel en Dispositivo-1. Ejecutará 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 VPN, consulte el Volumen 5:
Redes privadas virtuales.)
142 Enrutamiento multicast en dispositivos de seguridad

WebUI
clic en Apply:

Interfaz: ethernet3 (trust-vr)
Network > Interfaces > Tunnel (tunnel.1): Introduzca los siguientes datos y
haga clic en Apply:
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
dispositivos de seguridad. Para permitir tráfico de control multicast entre 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 al grupo (o grupos) multicast a los que los
hosts puedan 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 el
Capítulo 7, “Enrutamiento multicast”. Para obtener información sobre PIM,
consulte el Capítulo 8, “Enrutamiento multicast”).
Directivas multicast 143

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
multicast. Para permitir el tráfico de datos (tanto unicast como multicast) entre
zonas, debe configurar directivas de cortafuegos. (Para obtener información sobre
directivas, consulte el Volumen 2: Fundamentos.)
Las directivas multicast no se ordenan como 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
búsqueda, utilizará esa directiva.
NOTA: Para ver un ejemplo de configuración de una directiva multicast para mensajes
IGMP, consulte “Crear una directiva de grupo multicast para IGMP” en la
página 160. Para ver un ejemplo de configuración de una directiva multicast para
mensajes PIM, consulte “Definir de una directiva de grupo multicast para PIM-SM”
en la página 183.
144 Directivas multicast

Capítulo 7
Protocolo IGMP
Este capítulo describe el protocolo multicast Internet Group Management

Protocol (IGMP) en dispositivos de seguridad de Juniper Networks. Contiene
las siguientes secciones:
“Hosts” en la página 147
“Enrutadores multicast” en la página 148
“IGMP en dispositivos de seguridad” en la página 149
“Habilitar y deshabilitar IGMP en interfaces” en la página 149
“Configurar una lista de accesos para grupos aceptados” en la página 150
“Configurar IGMP” en la página 151
“Verificar una configuración de IGMP” en la página 153
“Parámetros operativos de IGMP” en la página 154
“Proxy de IGMP” en la página 155
“Configurar el proxy de IGMP” en la página 158
“Configurar un proxy de IGMP en una interfaz” en la página 158
“Directivas Multicast para configuraciones de IGMP y proxy de IGMP” en la

página 160
“Configurar un proxy del remitente de IGMP” en la página 167
145
Vista general
El protocolo multicast Internet Group Management Protocol (IGMP) se utiliza entre
hosts y enrutadores para establecer y mantener miembros de grupos multicast en
una red. Los dispositivos de seguridad son compatibles con las siguientes versiones
de IGMP:
IGMPv1, según lo definido en RFC 1112, Host Extensions for IP Multicasting,

define las operaciones básicas para miembros de grupos multicast.
IGMPv2, según lo definido en RFC 2236, Internet Group Management Protocol,

Versión 2, amplía la funcionalidad de IGMPv1.
IGMPv3, según lo definido en RFC 3376, Internet Group Management Protocol,

Versión 3, permite el filtrado 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 se requiere cuando “Protocol Independent
Multicast” se ejecuta en el modo “Source-Specific Multicast” (PIM-SSM). (Para
obtener información sobre PIM-SSM, consulte “PIM-SSM” en la página 180).
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 tráfico multicast a los hosts a través de la red.
146 Vista general

Capítulo 7: Protocolo IGMP
Figure 24: Ejemplo de IGMP
Origen
Los protocolos de
enrutamiento multicast,
tales como PIM-SM,
alimentan la tabla de
rutas multicast y
reenvían datos a los
Internet hosts de toda la red.
Hosts y enrutadores
utilizan IGMP para
intercambiar información
de miembros del grupo
multicast.
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 convivir 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 cuáles hosts son miembros de
grupos multicast al escuchar estos mensajes IGMP en sus redes locales. La Tabla 15
describe los mensajes de IGMP que los hosts envían y el destino de los mensajes.
Vista general 147

Tabla 15: 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 Dirección IP del
une a un grupo multicast y periódicamente, una vez que ya grupo multicast al
es miembro del grupo. El informe de miembros indica a qué que el host desea
grupo multicast desea unirse el host. unirse
IGMPv3 Un host envía un informe de miembro la primera vez que se 224.0.0.22
une a un grupo 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 filtrado, que es
“include” o “exclude”, y una lista de orígenes. Si el modo de
filtrado es include, los paquetes procedentes de las
direcciones en la lista de origen se aceptan. Si el modo de
filtrado es exclude, los paquetes procedentes de orígenes
distintos de los de la lista son aceptados.
IGMPv2 Un host envía un mensaje “Leave Group” cuando desea dejar “all routers group”
el grupo multicast y dejar de recibir datos para ese grupo. (224.0.0.2)
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” por 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 en cada interfaz. Los enrutadores IGMPv3 mantienen una lista
que incluye la dirección del grupo multicast, el modo de filtrado (include o exclude)
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 16 describe los mensajes que un contestador envía y los destinos.
148 Vista general

Tabla 16: Mensajes del consultador IGMP
Versión
de IGMP Mensaje de IGMP Destino
IGMPv1, El consultador envía periódicamente consultas generales grupo “all hosts”
v2 y v3 para solicitar la información de miembros de grupos. (224.0.0.1)
IGMPv2 y El consultador envía una consulta específica de grupo El grupo multicast que el
v3 cuando recibe un mensaje Leave Group de IGMPv2 o un host está abandonando.
informe de miembros IGMPv3 que 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 tráfico multicast a ese grupo.
IGMPv3 El consultador envía una consulta group-and-source para El grupo multicast que el
verificar si hay algún receptor para ese grupo y origen host está abandonando.
concretos.
IGMP en dispositivos de seguridad

En algunos enrutadores, IGMP se habilita automáticamente cuando se habilita un
protocolo de enrutamiento multicast. En dispositivos de seguridad de Juniper
Networks, debe habilitar explícitamente IGMP y un protocolo de enrutamiento
multicast.
Habilitar y deshabilitar IGMP en interfaces

De forma predeterminada, IGMP está inhabilitado en todas las interfaces. Debe
habilitar IGMP en el modo 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.
Habilitar IGMP en una interfaz

En este ejemplo, habilitará 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
IGMP en dispositivos de seguridad 149

Inhabilitar IGMP en una interfaz

En este ejemplo, inhabilitará IGMP en la interfaz ethernet1. El dispositivo de
seguridad mantiene la configuración de IGMP, pero la inhabilita.
WebUI
Network > Interfaces > Edit (para ethernet1) > IGMP: Desactive Protocol
IGMP Enable, luego haga clic en Apply.
CLI
unset interface ethernet1 protocol igmp enable
save
Para borrar la configuración de IGMP ejecute el comando unset interface interfaz

protocol igmp router.
Configurar una lista de accesos para grupos aceptados

Hay algunos aspectos de seguridad que debe considerar al ejecutar IGMP. Los
usuarios malévolos pueden ejecutar 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 creando listas
de accesos y aplicándolas a una interfaz.
Una lista de accesos es una lista secuencial de instrucciones que especifican una
dirección IP y un estado de reenvío (permitir o denegar). 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 pueden unirse
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
Después de crear una lista de accesos, aplíquela a una interfaz. Una vez aplicada
una lista de accesos a una interfaz, ésta acepta tráfico solamente de los indicados
en su 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
“Configurar una lista de acceso” en la página 42).
En este ejemplo, se crea 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 instrucción es 1
Después de crear la lista de accesos, permita que los hosts en ethernet1 se unan al
grupo multicast especificado en la lista de accesos.
150 IGMP en dispositivos de seguridad

WebUI
Network > Routing > Virtual Routers > Access List: > New (para trust-vr):
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
Configurar 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 con 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 25, 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 con 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 con
los hosts:
1. Asigne direcciones IP a las interfaces y asócielas 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) a recibir mensajes IGMP para el

grupo multicast 224.4.4.1/32.

Figura 25: 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 tráfico multicast.
(Para obtener información sobre PIM, consulte el Capítulo 8, “Multicast
independiente de protocolo (PIM)”).
Verificar 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.
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:
exec igmp interface ethernet2 query
Para enviar una consulta específica de grupo desde ethernet2 al grupo multicast
224.4.4.1, introduzca:
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 miembros desde ethernet2 introduzca:
exec igmp interface ethernet2 report 224.4.4.1
Puede revisar los parámetros IGMP de una interfaz ejecutando el comando

siguiente:
ns-> 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 seconds
query-max-response-time 10 seconds
leave-interval 1 seconds
last-member-query-interval 1 seconds
Este resultado detalla la siguiente información:
Versión de IGMP (2)
Estado del consultador (I am the querier).
Parámetros Set y unset
Para mostrar información sobre grupos multicast, ejecute el siguiente comando CLI:
ns-> 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

Al habilitar IGMP en modo de enrutador en una interfaz, la interfaz se inicia como
consultador. Como consultador, la interfaz utiliza ciertos ajustes predeterminados
que usted puede modificar. Cuando establece parámetros en este nivel, esto afecta
únicamente la interfaz que especifica. La Tabla 17 detalla los parámetros de interfaz
del contestador de IGMP y sus valores predeterminados.
Tabla 17: Parámetros de la interfaz del consultador de IGMP y valores predeterminados
Parámetros de
la interfaz Valor
IGMP Descripción predeterminado
General query El intervalo en el cual la interfaz consultadora envía 125 segundos
interval consultas generales al grupo “all hosts” (224.0.0.1).
Maximum El tiempo máximo entre una consulta general y la 10 segundos
response time respuesta procedente del host.
Last Member El intervalo en el que la interfaz envía una consulta 1 segundo
Query Interval específica de grupo. Si no 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
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.
Al ejecutar IGMP proxy en un dispositivo de seguridad, las interfaces conectadas

con los hosts funcionan como enrutadores y las conectadas con enrutadores de
niveles superiores funcionan como hosts.Típicamente, las interfaces de hosts y
enrutadores están en zonas diferentes. Para permitir que los mensajes de IGMP
pasen entre zonas, debe configurar una directiva multicast. A continuación, para
permitir que el tráfico de datos multicast pase entre zonas, también debe configurar
una directiva del cortafuegos.
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 acerca de los
sistemas virtuales, consulte el Volumen 5: Redes privadas 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 las interfaces,
construyendo 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.
Proxy de IGMP 155

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
recién unido, 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(s) 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.
156 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 26 muestra un ejemplo de una configuración de host proxy de IGMP.
Figura 26: Configuración del host proxy de IGMP
Origen 4. El origen envía datos multicast en

sentido descendente hacia el receptor.
3. La interfaz del host proxy de IGMP 5. La interfaz del host proxy de IGMP
comprueba si tiene una entrada (*, G) Enrutador comprueba si existe alguna sesión
para el grupo multicast: designado para el grupo:
• En caso afirmativo, agrega la interfaz del de origen • En caso afirmativo, reenvía los datos
enrutador a las interfaces salientes en multicast.
una entrada multicast de la tabla de • En caso negativo, comprueba si hay
rutas. alguna entrada (S, G) para el grupo:
• En caso negativo, crea la entrada y Internet • En caso afirmativo, reenvía los datos
reenvía el informe de miembros al multicast.
enrutador en sentido ascendente. • En caso negativo, compruebe si hay
alguna entrada (*, G):
• En caso negativo, descarta los
Interfaz del datos.
Zona host proxy de
Untrust • En caso afirmativo, crea una
IGMP entrada (S, G) y reenvía datos
utilizando la interfaz de entrada y
2. La interfaz del enrutador proxy de GMP de salida desde la entrada (*, G).
comprueba si hay alguna entrada para el
grupo multicast: Zona
• En caso afirmativo, ignora el informe de Trust
miembros. Interfaz del 6. La interfaz del enrutador proxy de
• En caso negativo y si no hay ninguna enrutador proxy IGMP reenvía datos a los receptores.
directiva multicast para el grupo, de IGMP
descarta el informe de miembros.
• 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 hacia la interfaz
del host en la zona especificada en la
directiva multicast.
1. Los hosts envían informes de miembros
en sentido ascendente. Receptores
Proxy de IGMP 157

Configurar el 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.
Configurar un proxy de IGMP en una interfaz

Al ejecutar 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
tráfico multicast, debe ser el consultador en la red local. Para permitir que una
interfaz no consultadora reenvíe tráfico multicast, debe especificar la palabra clave
always al habilitar IGMP on 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 al ejecutar 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:
Habilitar IGMP en el modo host
Permitir 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 con los

hosts. Configure lo siguiente en ethernet3:
Habilitar IGMP en el modo enrutador
Permitir que reenvíe tráfico multicast aunque no sea un consultador.
Permitir que acepte mensajes IGMP procedentes de orígenes de otras subredes.
158 Proxy de IGMP

WebUI
haga clic en OK:
Zone Name: Trust

haga clic en Apply:
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 159

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 pueden necesitar
enviar mensajes IGMP a un host o a un enrutador en otra zona. Para permitir el
envío interzonal de mensajes IGMP, debe configurar una directiva multicast que lo
permita específicamente. Al crear 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.
Crear 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. La palabra clave bi-directional se utiliza 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
Crear una configuración de proxy de IGMP

Como se indica en la Figura 27, usted configurará 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 ambos lugares:
1. Asignar direcciones IP a las interfaces físicas asociadas a las zonas

de seguridad.
2. Crear los objetos de direcciones.
160 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. Especifique la palabra clave always en ethernet1 de NS1 para permitir que

reenvíe tráfico multicast incluso aunque no sea un 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. Al habilitar 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 27: Configuración de IGMP Proxy entre dos dispositivos
Elementos relacionados con NSI
ethernet3
10.2.2.1/24
Enrutador Interfaz de túnel
tunnel.1 Receptores
designado
NS1 Internet
Origen
Túnel VPN NS2
Interfaz de túnel ethernet1
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
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
Proxy de IGMP 161

haga clic en OK:
Zone Name: Untrust

clic en OK:

2. Direcciones
en OK:
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)
162 Proxy de IGMP

5. VPN
y haga clic en OK:
Gateway Name: To_Branch

Preshared Key: fg2g4h5j
>> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en

enlace:

Phase 1 Proposal (para Compatible Security Level): pre-g2-3des-sha
Mode (Initiator): Main (Protección de la identificación)
6. Directivas
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

Proxy de IGMP 163

clic en Apply:

2. Direcciones
en OK:
Address Name: mgroup1

Zone: Trust
en OK:
Address Name: source-dr

Zone: Untrust
3. IGMP

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)
164 Proxy de IGMP

5. VPN
y haga clic en OK:
Gateway Name: To_Corp
Preshared Key: fg2g4hvj


6. Directivas
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

CLI (NS1)
1. Interfaces
2. Direcciones
set address untrust branch1 10.3.1.0/24
3. IGMP
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
Proxy de IGMP 165

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
7. Directivas multicast
save
CLI (NS2)
1. Interfaces
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 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. Directivas
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
166 Proxy de IGMP

Configurar un proxy del 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
seguridad comprueba si hay lo siguiente:
Una directiva del grupo multicast permitiendo el tráfico desde la zona de origen
a la zona de la interfaz del host IGMP proxy
Una lista de accesos de los orígenes aceptables
Si no hay ninguna directiva multicast entre la zona de origen y la zona de la interfaz

IGMP proxy o si el origen no se encuentra en la lista de orígenes aceptables, el
dispositivo de seguridad descarta el tráfico. Si existe una directiva multicast entre la
zona de origen y la zona de la interfaz IGMP proxy, y el origen aparece en la lista de
orígenes aceptables, el dispositivo crea una entrada (S, G) para esa interfaz en la
tabla de rutas multicast; la interfaz entrante es la interfaz a la que el origen está
conectado y la interfaz saliente es la interfaz del host IGMP proxy. A continuación,
el dispositivo de seguridad envía los datos en sentido ascendente a la interfaz del
host IGMP proxy, que envía los datos a todas sus interfaces conectadas, salvo a la
interfaz conectada con el origen.
La Figura 28 muestra un ejemplo del proxy del remitente de IGMP.
Figura 28: Proxy del remitente de IGMP
La interfaz del IGMP proxy de ethernet3

envía tráfico multicast a todas las
interfaces de enrutador proxy
ethernet1
Receptores Internet
ethernet2
Receptores
tráfico multicast
Tabla de rutas multicast

iff = ethernet2
oif = ethernet3 Origen
En la Figura 29, el origen está conectado a la interfaz ethernet2, asociada a la zona

DMZ en NS2. Está enviando tráfico multicast al grupo multicast 224.4.4.1/32. Hay
receptores conectados a la interfaz ethernet1 asociada a la zona Trust en NS2. Tanto
ethernet1 como ethernet2 son interfaces de enrutador IGMP proxy. La interfaz
ethernet3 asociada a la zona Untrust de NS2 es una interfaz de host de IGMP proxy.
También hay receptores conectados con la interfaz ethernet1 asociada a la zona
Trust en NS1. Realice los pasos siguientes en NS2:
Proxy de IGMP 167

1. Asignar direcciones IP a las interfaces físicas asociadas a las zonas

de seguridad.
2. Cree los objetos de direcciones.
3. En ethernet1 y ethernet2:
a. Habilite IGMP en el modo enrutador y habilite IGMP proxy.
b. Especifique la palabra clave always para permitir que las interfaces

reenvíen tráfico multicast incluso aunque no sean consultadores.
4. Habilite IGMP en modo host en ethernet3.
5. Configure la ruta predeterminada.
6. Configure las directivas de cortafuegos entre las zonas.
7. Configure las directivas multicast entre las zonas.
NOTA: Este ejemplo sólo contiene la configuración de NS2, no la de NS1.
Figura 29: Ejemplo de red de proxy del remitente de IGMP
ethernet 3
2.2.2.2/24
Host del proxy
ethernet1 ethernet3 ethernet1, 10.2.2.1
1.1.1.1/24 IGMP de la
10.2.2.1/24 Proxy del enrutador
Zona Untrust zona Untrust Receptores
Zona Trust IGMP de zona Trust
Receptores
NS1 NS2
Internet
Origen
3.2.2.5
Nota: Las zonas de seguridad no
se muestran en esta ilustración.
ethernet2, 3.2.2.1/24
zona DMZ, Proxy del
enrutador IGMP
WebUI (NS2)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
168 Proxy de IGMP

haga clic en OK:
Zone Name: DMZ

haga clic en OK:
Zone Name: Untrust

2. Direcciones
en OK:

Zone: Trust
en OK:

Zone: DMZ
en OK:
Address Name: proxy-host

Zone: Untrust
3. IGMP


Proxy de IGMP 169


4. Ruta

5. Directivas
Policies > (From: DMZ, To: Trust) > New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: source-dr
Service: ANY
Action: Permit
Policies > (From: DMZ, To: Untrust) > New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Service: ANY
Action: Permit
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), proxy-host
Service: ANY
Action: Permit
MCast Policies > (From: DMZ, To: Untrust) > New: Introduzca los siguientes

170 Proxy de IGMP

MCast Policies > (From: DMZ, To: Trust) > New: Introduzca los siguientes

MCast Policies > (From: Untrust, To: Trust) > New: Introduzca los siguientes

CLI (NS2)
1. Interfaces
2. Direcciones
set address dmz source-dr 3.2.2.5/32
set address untrust proxy-host 2.2.2.2/32
3. IGMP
4. Ruta
5. Directivas
set policy from dmz to trust source-dr mgroup1 any permit
set policy from dmz to untrust source-dr mgroup1 any permit
set policy from untrust to trust proxy-host mgroup1 any permit
6. Directivas multicast
set multicast-group-policy from dmz mgroup 224.4.4.1/32 to untrust
set multicast-group-policy from dmz mgroup 224.4.4.1/32 to trust igmp-message
bi-directional
save
Proxy de IGMP 171

172 Proxy de IGMP

Capítulo 8
Multicast independiente de protocolo
(PIM)
En este capítulo se describe el Protocol Independent Multicast (PIM) en los

dispositivos de seguridad de Juniper Networks. Contiene las siguientes secciones:
“PIM-SM” en la página 176
“Árboles de distribución multicast” en la página 176
“Enrutador designado” en la página 177
“Asignar puntos de encuentro a grupos” en la página 177
“Reenviar tráfico a través del árbol de distribución” en la página 178
“Configuración de PIM-SM en dispositivos de seguridad” en la página 180
“Habilitar y eliminar una instancia PIM-SM en un enrutador virtual (VR)” en

la página 181
“Habilitar y deshabilitar PIM-SM en interfaces” en la página 182
“Directivas de grupo multicast” en la página 182
“Ajustar una configuración de PIM-SM básica” en la página 184
“Comprobar la configuración” en la página 189
“Configurar puntos de encuentro” en la página 191
“Configurar de un punto de encuentro estático” en la página 191
“Configurar de un punto de encuentro candidato” en la página 192
“Consideraciones sobre seguridad” en la página 193
“Restringir grupos multicast” en la página 193
“Restringir orígenes multicast” en la página 194
“Restringir puntos de encuentro” en la página 195
173
“Parámetros de la interfaz PIM-SM” en la página 196
“Definir una directiva de vecindad” en la página 196
“Definir un borde bootstrap” en la página 197
“Configurar de un punto de encuentro del proxy” en la página 198
“PIM-SM e IGMPv3” en la página 207
174
Capítulo 8: Multicast independiente de protocolo (PIM)
Vista general
El protocolo PIM es un protocolo de enrutamiento multicast que se ejecuta entre
enrutadores. Mientras que el protocolo Internet Group Management Protocol (IGMP)
se ejecuta entre equipos y enrutadores para intercambiar información de miembros
del grupo multicast, PIM se ejecuta entre enrutadores para reenviar tráfico multicast
a los miembros del grupo multicast de toda la red. (Para obtener información sobre
IGMP, consulte “Protocolo IGMP” en la página 145).
Figura 30: IGMP
Origen
Los protocolos de
enrutamiento multicast,
tales como PIM-SM,
alimentan la tabla de
rutas multicast y
reenvían datos a los
Internet hosts de toda la red.
Hosts y enrutadores
utilizan IGMP para
intercambiar información
de miembros del grupo
multicast.
Para ejecutar PIM, también debe configurar o bien rutas estáticas o un protocolo de
enrutamiento dinámico. PIM se llama independiente del protocolo porque utiliza la
tabla de rutas del protocolo de enrutamiento unicast subyacente para realizar sus
comprobaciones RPF (reenvío por rutas inversas), pero no depende de la
funcionalidad del protocolo de enrutamiento unicast. (Para obtener información
sobre RPF, consulte “Reenviar rutas inversas” en la página 138).
PIM puede funcionar de los modos siguientes:
El modo PIM-Dense (PIM-DM) inunda toda la red con tráfico multicast y luego
corta las rutas a hacia los receptores que no desean recibir tráfico multicast.
El modo PIM-Sparse (PIM-SM) reenvia tráfico multicast solamente a los
receptores que lo soliciten. Los enrutadores que ejecuten PIM-SM pueden
utilizar el árbol de ruta compartida o el árbol de ruta más corta (SPT) para
reenviar la información multicast. (Para obtener información sobre árboles de
distribución multicast, consulte “Árboles de distribución multicast” en la
página 176).
Vista general 175

El modo multicast específico del origen PIM (“PIM-Source Specific Multicast

Mode” o PIM-SSM) está derivado del PIM-SM. Igual que PIM-SM, reenvía tráfico
multicast sólo a los receptores interesados. A diferencia de PIM-SM, forma
inmediatamente un SPT al origen.
Los dispositivos de seguridad de Juniper Networks admiten PIM-SM, según la

definición draft-ietf-pim-sm-v2-new-06, así como PIM-SSM según la definición
RFC 3569, An Overview of Source-Specific Multicast (SSM). Para obtener
información sobre PIM-SM, consulte “PIM-SM.” Para obtener información sobre
PIM-SSM, consulte “PIM-SSM” en la página 180.
PIM-SM
PIM-SM es un protocolo de enrutamiento multicast que reenvía tráfico multicast
sólo a los receptores interesados. Puede utilizar un árbol de distribución compartido
o el árbol de ruta más corta (SPT) para reenviar tráfico multicast a través de la red.
(Para obtener información sobre árboles de distribución multicast, consulte
“Árboles de distribución multicast” en la página 176). De forma predeterminada,
PIM-SM utiliza el árbol de distribución compartido con un punto de encuentro (RP)
en la raíz del árbol. Todos los orígenes de un grupo envían sus paquetes al RP, y el
RP envía datos en dirección descendente por el árbol de distribución compartido a
todos los receptores de la red. Cuando se alcanza un umbral configurado, los
receptores pueden formar un SPT al origen, reduciendo el tiempo que lleva a los
receptores recibir los datos multicast.
NOTA: De forma predeterminada, los dispositivos de seguridad de Juniper Networks

conmutan al SPT en el momento de recibir el primer byte.
Con independencia del árbol utilizado para distribuir el tráfico, sólo los receptores
que explícitamente se unan a un grupo multicast pueden recibir el tráfico enviado a
ese grupo. PIM-SM utiliza la tabla de enrutamiento unicast para realizar sus
operaciones de reenvío por rutas inversas (RPF) al recibir mensajes de control
multicast y utiliza la tabla de enrutamiento multicast para enviar tráfico de datos
multicast a los receptores.
Árboles de distribución multicast

Los enrutadores multicast reenvían el tráfico multicast en sentido descendente
desde el origen a los receptores a través de un árbol de distribución multicast. Hay
dos tipos de árboles de distribución multicast:
El árbol de la ruta más corta (SPT): El origen se encuentra en la raíz del árbol y
reenvía los datos multicast en sentido descendente a cada receptor.
Denominada también árbol específico del origen o “source-specific tree”.
Árbol de distribución compartido: El origen transmite el tráfico multicast al

punto de encuentro (“rendezvous point” o RP), que típicamente es un
enrutador en el núcleo de la red. A continuación, el RP reenvía el tráfico en
sentido descendente a los receptores del árbol de distribución.
176 Vista general

Figura 31: PIM
Árbol de la ruta más corta

Árbol de distribución compartido
Árbol de distribución compartido
Árbol de la ruta más corta 2. El origen envía tráfico multicast en sentido

descendente hacia el punto de encuentro (RP).
1. El origen envía tráfico multicast en
sentido descendente a los receptores. 3. El RP reenvía tráfico multicast en sentido
descendente a los receptores.
RP
Enrutador designado
Cuando en una red de área local (LAN) multiacceso hay varios enrutadores
multicast, los enrutadores eligen un enrutador designado (DR). El DR en la LAN del
origen es responsable de enviar los paquetes multicast desde el origen al RP y a los
receptores que están en el árbol de distribución específico del origen. El DR en la
LAN de los receptores es responsable de reenviar mensajes join-prune desde los
receptores al RP, y de enviar el tráfico de datos multicast a los receptores de la LAN.
Los receptores envían mensajes join-prune cuando desean unirse a un grupo
multicast o salir de él.
El DR se selecciona a través de un proceso de selección. Cada enrutador PIM-SM de

una LAN tiene una prioridad DR configurable por el usuario. Los enrutadores de
PIM-SM anuncian sus prioridades DR mediante mensajes de saludo (“hello”) que
envían periódicamente a sus vecinos. Cuando los enrutadores reciben los mensajes
de saludo, seleccionan el enrutador con la prioridad DR más alta como DR para la
LAN. Si varios enrutadores coinciden en tener la prioridad DR más alta, el enrutador
con la dirección IP más alta se convertirá en el DR de la LAN.
Asignar puntos de encuentro a grupos

Un punto de encuentro (“rendezvous point” o RP) envía paquetes multicast para
determinados grupos multicast. Un dominio PIM-SM es un grupo de enrutadores
PIM-SM con las mismas asignaciones de grupo RP. Hay dos maneras de asignar
grupos multicast a un RP: estáticamente y dinámicamente.
Asignación de RP estática
Para crear una asignación estática entre un RP y un grupo multicast, debe
configurar el RP para el grupo multicast en cada enrutador de la red. Cada vez que
cambie la dirección del RP, deberá volver a configurar la dirección del RP.
Vista general 177

Asignación de RP dinámica
PIM-SM también proporciona un mecanismo de asignación dinámica de RPs a
grupos multicast. En primer lugar, configure los puntos de encuentro de candidatos
(C-RPs) para cada grupo multicast. A continuación, los C-RPs envían notificaciones
Candidate-RP a un enrutador de la LAN, denominado enrutador “bootstrap” (BSR).
Las notificaciones contienen el grupo multicast para el cual el enrutador actúa como
RP y la prioridad del C-RP.
El BSR recoge estas notificaciones C-RP y las emite en un mensaje BSR a todos los
enrutadores del dominio. Los enrutadores recogen estos mensajes BSR y utilizan un
algoritmo hash bien conocido para seleccionar un RP activo por cada grupo
multicast. Si el RP seleccionado falla, el enrutador selecciona una nueva asignación
de grupo RP entre los RPs candidatos. Para obtener información sobre el proceso de
selección de BSR, consulte draft-ietf-pim-sm-bsr-03.txt.
Reenviar tráfico a través del árbol de distribución

Esta sección describe cómo los enrutadores PIM-SM envían mensajes “join” al
punto de encuentro (RP) de un grupo multicast y cómo el RP envía datos multicast
a los receptores de la red. En un entorno de red multicast, un dispositivo de
seguridad puede funcionar como RP, como enrutador designado en la red del
origen o en la red de los receptores, o como enrutador intermedio.
El origen envía datos a un grupo
Cuando un origen comienza a enviar paquetes multicast, transmite esos paquetes a
través de la red. Cuando el enrutador designado (DR) en esa red de área local (LAN)
recibe los paquetes multicast, consulta la interfaz saliente y la dirección IP del salto
siguiente hacia el RP en la tabla de rutas unicast. A continuación, el DR encapsula
los paquetes multicast en paquetes unicast, denominados mensajes REGISTER, y
los reenvía a la dirección IP del siguiente salto. Cuando el RP recibe los mensajes
REGISTER, desencapsula los paquetes y envía los paquetes multicast en sentido
descendente por el árbol de distribución hacia los receptores.
Figura 32: Datos de envío origen
1. El origen envía los paquetes Origen

multicast en sentido
descendente.
2. El DR encapsula los Punto de encuentro (RP)

paquetes y envía mensajes
REGISTER al RP.
Enrutador designado (DR)
3. El RP desencapsula los mensajes

REGISTER y envía paquetes
multicast a los receptores.
Si la velocidad de transmisión de los datos del DR de origen alcanza un umbral

configurado, el RP envía un mensaje PIM-SM adjunto hacia el DR de origen, de
modo que el RP pueda recibir datos multicast nativos, en lugar de los mensajes
REGISTER. Cuando el DR de origen recibe el mensaje adjunto, envía los paquetes
178 Vista general

multicast y los mensajes REGISTER hacia el RP. Cuando el RP recibe los paquetes
multicast del DR, envía al DR un mensaje register-stop. Cuando el DR recibe el
mensaje register-stop, deja de enviar los mensajes REGISTER y envía los datos
multicast nativos, que el RP envía en sentido descendente a los receptores.
El host se une a un grupo

Cuando un host se une a un grupo multicast, envía un mensaje IGMP adjunto a ese
grupo multicast. Cuando el DR de la LAN del host recibe el mensaje IGMP adjunto,
consulta el grupo en el RP. Crea una entrada (*, G) en la tabla de rutas multicast y
envía un mensaje PIM-SM adjunto a su RPF vecino en sentido ascendente hacia el
RP. Cuando el enrutador de sentido ascendente recibe los mensajes PIM-SM
adjuntos, realiza el mismo proceso de consulta RP y también comprueba si el
mensaje adjunto viene de un RPF vecino. Si es así, remite el mensaje PIM-SM
adjunto hacia el RP. Este proceso se repite hasta que el mensaje PIM-SM adjunto
alcanza el RP. Cuando el RP recibe el mensaje adjunto, envía los datos multicast en
sentido descendente hacia el receptor.
Figura 33: El host se une a un grupo
Origen
Enrutador designado (DR) 2. DR envía los mensajes

adjuntos IGMP al RP.
3. RP envía datos multicast

en sentido descendente
a los receptores.
Puento de
Encuentro (RP)
1. Hosts envía los mensaje
adjuntos de IGMP para el
grupo multicast.
Hosts/Receptores Hosts/Receptores
Cada enrutador en sentido descendente realiza una comprobación del RPF cuando
recibe los datos multicast. Cada enrutador comprueba si recibió los paquetes
multicast de la interfaz que utiliza para enviar tráfico de datos hacia el RP. Si la
comprobación del RPF es correcta, el enrutador busca una entrada de reenvío (*, G)
coincidente en la tabla de rutas multicast. Si encuentra la entrada (*, G), coloca el
origen en la entrada, que se convierte en una entrada (S, G) y reenvía los paquetes
multicast en sentido descendente. Este proceso continúa en sentido descendente a
lo largo del árbol de distribución hasta que el host recibe los datos multicast.
Cuando la velocidad de transmisión de datos alcanza un umbral configurado, el DR

de la LAN del host puede formar el árbol de ruta más corta directamente al origen
multicast. Cuando el DR comienza a recibir tráfico de datos directamente del
origen, envía un mensaje prune específico del origen en sentido ascendente hacia
el RP. Cada enrutador intermedio “corta” del árbol de distribución la conexión con
el host, hasta que el mensaje prune alcanza el RP, que en ese momento deja de
enviar tráfico de datos multicast en sentido descendente hacia esa rama en
particular del árbol de distribución.
Vista general 179

PIM-SSM
Además de PIM-SM, los dispositivos de seguridad también admiten
PIM-Source-Specific Multicast (SSM). PIM-SSM sigue el modelo source-specific (SSM)
donde el tráfico multicast se transmite a los canales, no sólo a los grupos multicast.
Un canal consiste en un origen y un grupo multicast. Un receptor se suscribe a un
canal con un origen conocido y un grupo multicast. Los receptores proporcionan
información sobre el origen a través de IGMPv3. El enrutador designado en la LAN
envía mensajes al origen y no a un punto de encuentro (RP).
El IANA ha reservado el rango de direcciones multicast 232/8 para el servicio SSM

en IPv4. Si IGMPv3 se ejecuta en un dispositivo junto con PIM-SM, las operaciones
PIM-SSM están garantizadas dentro de este rango de direcciones. El dispositivo de
seguridad manipula los informes de miembros IGMPv3 para los grupos multicast
dentro del rango de direcciones 232/8 tal y como sigue:
Si el informe contiene un modo de filtro include, el dispositivo envía el informe

directamente a los orígenes de la lista de origen.
Si el informe contiene un modo de filtro exclude, el dispositivo descarta el

informe. No procesa informes (*, G) para los grupos multicast del rango de
direcciones 232/8.
Los pasos para configurar PIM-SSM en un dispositivo de seguridad son iguales a los
necesarios para configurar PIM-SM pero con las siguientes diferencias:
Debe configurar IGMPv3 en interfaces conectadas con receptores. (IGMPv2 está

habilitado de forma predeterminada en los dispositivos de seguridad).
Cuando configure una directiva de grupo multicast, autorice los mensajes

join-prune. (Los mensajes bootstrap no se utilizan).
No configure un punto de encuentro.
Las siguientes secciones explican cómo configurar PIM-SM en dispositivos

de seguridad.
Configuración de PIM-SM en dispositivos de seguridad

Los dispositivos de seguridad de Juniper Networks tienen dos enrutadores virtuales
predefinidos (VRs): trust-vr y untrust-vr. Cada enrutador virtual es un componente
de enrutamiento independiente con sus propias tablas de rutas. Protocol
Independent Multicast - Sparse Mode (PIM-SM) utiliza la tabla de rutas del enrutador
virtual en el cual está configurado para consultar la interfaz de reenvío por rutas
inversas (PIM-SM) y la dirección IP siguiente. Por lo tanto, para ejecutar PIM-SM en
un dispositivo de seguridad, primero debe configurar rutas estáticas o un protocolo
de enrutamiento dinámico en un enrutador virtual, y luego tiene que configurar el
PIM-SM en el mismo enrutador virtual. (Para obtener información sobre
enrutadores virtuales, consulte el Capítulo 2, “Enrutamiento”, en la página 13).
Los dispositivos de seguridad admiten los siguientes protocolos de enrutamiento
dinámico:
Open Shortest Path First (OSPF): Para obtener más información acerca de
OSPF, consulte el Capítulo 3, “Protocolo OSPF”, en la página 47.
180 Configuración de PIM-SM en dispositivos de seguridad

Routing Information Protocol (RIP): Para obtener más información acerca de

RIP, consulte el Capítulo 4, “Protocolo de información de enrutamiento”, en la
página 79.
Border Gateway Protocol (BGP):Para obtener más información acerca de BGP,
consulte el Capítulo 5, “Protocolo BGP”, en la página 109.
Las secciones siguientes describen los pasos básicos necesarios para configurar un
PIM-SM en un dispositivo de seguridad:
Crear y habilitar una instancia PIM-SM en un enrutador virtual (VR).

Habilitar PIM-SM en las interfaces.
Configurar una directiva multicast para permitir que los mensajes PIM-SM
pasen por el dispositivo de seguridad.
Habilitar y eliminar una instancia PIM-SM en un enrutador virtual (VR)

Puede configurar una instancia PIM-SM para cada enrutador virtual. PIM-SM utiliza
la tabla de rutas unicast del enrutador virtual para realizar su comprobación del
RPF. Después de crear y habilitar una instancia de enrutamiento PIM-SM en un
enrutador virtual, puede habilitar el PIM-SM en las interfaces del enrutador virtual.
Habilitar de una instancia PIM-SM

En este ejemplo, creará y habilitará una instancia PIM-SM para el enrutador virtual
trust-vr.
WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Create PIM
Instance: Seleccione Protocol PIM: Enable, luego haga clic en Apply.
CLI
ns(trust-vr)-> set protocol pim
ns(trust.vr/pim)-> set enable
ns(trust.vr/pim)-> exit
ns(trust-vr)-> exit
save
Eliminar una instancia PIM-SM

En este ejemplo eliminará la instancia PIM-SM del enrutador virtual trust-vr. Cuando
elimine la instancia PIM-SM de un enrutador virtual, el dispositivo de seguridad
inhabilita el PIM-SM en las interfaces y borra todos los parámetros de la interfaz
PIM-SM.
WebUI
Network > Routing > Virtual Router (trust-vr) > Edit > Delete PIM Instance,
luego haga clic en OK en el mensaje de confirmación.
CLI
unset vrouter trust-vr protocol pim
deleting PIM instance, are you sure? y/[n] y
save
Configuración de PIM-SM en dispositivos de seguridad 181

Habilitar y deshabilitar PIM-SM en interfaces

De forma predeterminada, PIM-SM está inhabilitado en todas las interfaces.
Después de crear y habilitar el PIM-SM en un enrutador virtual, debe habilitar el
PIM-SM en las interfaces de ese enrutador virtual que transmiten tráfico de datos
multicast. Si una interfaz está conectada con un receptor, también debe configurar
IGMP en modo enrutador en esa interfaz. (Para obtener información sobre IGMP,
consulte “Protocolo IGMP” en la página 145).
Cuando habilita el PIM-SM en una interfaz que está asociada a una zona, el PIM-SM
se habilita automáticamente en la zona a la que pertenece dicha interfaz. A
continuación, puede configurar los parámetros PIM-SM para dicha zona. De forma
similar, cuando se inhabilitan parámetros PIM-SM de interfaces en una zona, todos
los parámetros PIM-SM relacionados con dicha zona se eliminan automáticamente.
Habilitar PIM-SM en una interfaz

En este ejemplo habilitará PIM-SM en la interfaz ethernet1.
WebUI
Network > Interfaces > Edit (para ethernet1) > PIM: Introduzca los siguientes
PIM Instance: (seleccione)

Protocol PIM: Enable (seleccione)
CLI
set interface ethernet1 protocol pim
set interface ethernet1 protocol pim enable
save
Inhabilitar PIM-SM en una interfaz

En este ejemplo deshabilitará PIM-SM en la interfaz ethernet1. Recuerde que
cualquier otra interfaz en la que haya habilitado PIM-SM todavía sigue
transmitiendo y procesando los paquetes PIM-SM.
WebUI
Network > Interfaces > Edit (para ethernet1) > PIM: Desactive Protocol PIM
Enable, luego haga clic en Apply.
CLI
unset interface ethernet1 protocol pim enable
save
Directivas de grupo multicast

De forma predeterminada, los dispositivos de seguridad no permiten que los
mensajes de tráfico de control multicast, como por ejemplo mensajes PIM-SM,
pasen de una zona a otra. Debe configurar una directiva de grupo multicast para
permitir que los mensajes PIM-SM pasen de una zona a otra. Las directivas de grupo
multicast controlan dos tipos de mensajes PIM-SM: los mensajes static-RP-BSR y
mensajes join-prune.
182 Configuración de PIM-SM en dispositivos de seguridad

Mensajes Static-RP-BSR
Los mensajes Static-RP-BSR contienen información sobre los puntos de encuentro
estáticos (RP) y las asignaciones de grupo RP dinámicas. La configuración de una
directiva multicast, que permita asignaciones estáticas de RP y mensajes bootstrap
(BSR) de una zona a otra, habilita el dispositivo de seguridad para que comparta las
asignaciones de grupo RP de una zona a otra dentro de un enrutador virtual o entre
dos enrutadores virtuales. Los enrutadores son capaces de memorizar las
asignaciones de grupos RP de otras zonas, de modo que no tenga que configurar los
RP en todas las zonas.
Cuando el dispositivo de seguridad recibe un mensaje BSR, comprueba que venga
de su vecino de reenvío por rutas inversas (RPF). A continuación comprueba si hay
directivas multicast para los grupos multicast del mensaje BSR. Filtra los grupos que
no estén autorizados en la directiva multicast y envía el mensaje BSR a los grupos
permitidos en todas las zonas de destino que están autorizadas por la directiva.
Mensajes Join-Prune
Las directivas de grupo multicast también controlan los mensajes join-prune.
Cuando el dispositivo de seguridad recibe un mensaje join-prune para un origen y
grupo o un origen y RP en su interfaz de sentido descendente, consulta en el RPF
vecino y la interfaz de la tabla de enrutamiento unicast.
Si la interfaz RPF se encuentra en la misma zona que la interfaz en sentido
descendente, la validación de la directiva multicast no es necesaria.
Si la interfaz RPF se encuentra en otra zona, el dispositivo de seguridad
comprueba si hay una directiva multicast que permita mensajes join-prune
para el grupo entre la zona de interfaz en sentido descendente y la zona de
la interfaz RPF.
Si hay una directiva multicast que permite mensajes join-prune entre las
dos zonas, el dispositivo de seguridad reenvía el mensaje a la interfaz
del RPF.
Si no hay directiva multicast que permita mensajes join-prune entre las
dos zonas, se descarta el mensaje join-prune.
Definir de una directiva de grupo multicast para PIM-SM

En este ejemplo, definirá una directiva de grupo multicast bidireccional que permita
todos los mensajes PIM-SM entre las zonas Trust y Untrust para el grupo 224.4.4.1.
WebUI
Policies (From: Trust, To: Untrust) > New: Introduzca los siguientes datos y
haga clic en OK:

PIM Message: (seleccione)
BSR-Static RP: (seleccione)
Join/Prune: (seleccione)
CLI
pim-message bsr-static-rp join-prune bi-directional
save
Configuración de PIM-SM en dispositivos de seguridad 183

Ajustar una configuración de PIM-SM básica

Un dispositivo de seguridad puede funcionar como un punto de encuentro (RP),
como un enrutador designado de origen (DR), como un receptor DR y como un
enrutador intermedio. No puede funcionar como un enrutador bootstrap.
Puede configurar PIM-SM en un enrutador virtual (VR) o a través de dos

enrutadores virtuales. Realice los siguientes pasos para configurar PIM-SM en
un enrutador virtual:
1. Configure las zonas y las interfaces.
2. Configure rutas estáticas o un protocolo de enrutamiento dinámico, como por

ejemplo Routing Information Protocol (RIP), Border Gateway Protocol (BGP) o
Open Shortest Path First (OSPF), en un enrutador virtual específico del
3. Cree una directiva de cortafuegos para que el tráfico de datos unicast y

multicast pase de una zona a otra.
4. Cree y habilite una instancia de enrutamiento PIM-SM en el mismo enrutador

virtual en el que haya configurado las rutas estáticas o un protocolo del
enrutamiento dinámico.
5. Habilite PIM-SM en interfaces que reenvíen el tráfico en sentido ascendente

hacia el origen o el RP, y en sentido descendente hacia los receptores.
6. Habilite IGMP en las interfaces conectadas a los hosts.
7. Configure una directiva multicast para permitir que los mensajes de PIM-SM
pasen de una zona a otra.
Cuando configure PIM-SM entre dos enrutadores virtuales, debe configurar el RP en

la zona del enrutador virtual en la que se encuentre el RP. A continuación, configure
una directiva de grupo multicast que permita los mensajes join-prune y los
mensajes BSR-static-RP entre las zonas en cada enrutador virtual. También debe
exportar las rutas unicast entre los dos enrutadores virtuales para asegurar la
exactitud de la información de reenvío por rutas inversas (RPF). Para obtener
información acerca de la exportación de rutas, consulte “Exportar e importar rutas
entre enrutadores virtuales” en la página 44.
NOTA: Si un dispositivo de seguridad se configura con múltiples enrutadores virtuales,

todos los enrutadores virtuales deben tener las mismas opciones PIM-SM.
Algunos dispositivos de seguridad de Juniper Networks admiten varios sistemas

virtuales. (Para obtener más información acerca de los sistemas virtuales, consulte
el Volumen 10: Sistemas virtuales). La configuración de PIM-SM en un sistema virtual
es igual que la configuración de PIM-SM en el sistema raíz. Si va a configurar
PIM-SM en dos enrutadores virtuales que se encuentran en sistemas virtuales
diferentes, debe configurar un proxy RP. (Para obtener información sobre la
configuración de un proxy RP, consulte “Configurar de un punto de encuentro del
proxy” en la página 198).
184 Ajustar una configuración de PIM-SM básica

En este ejemplo, configurará PIM-SM en un enrutador trust-vr. Desea que los hosts
de la zona Trust reciban tráfico de datos multicast para el grupo multicast
224.4.4.1/32. Configurará el RIP como el protocolo de enrutamiento unicast en el
enrutador trust-vr y cree una directiva de cortafuegos para permitir el tráfico de
datos entre las zonas Trust y Untrust. Creará una instancia PIM-SM en el enrutador
trust-vr y habilitará PIM-SM en ethernet1 y ethernet2 en la zona Trust, y en
ethernet3 en la zona Untrust. Todas las interfaces están en modo de ruta. A
continuación, configurará IGMP en ethernet1 y ethernet2, que están conectados
con los receptores. Finalmente, creará una directiva multicast que permita los
mensajes static-RP-BSR y join-prune entre las zonas.
Figura 34: Configuración PIM-SM básica
Zona Untrust
Origen
Enrutador
designado
Enrutador
bootstrap
Punto de
encuentro
ethernet3 Receptores
1.1.1.1/24
ethernet1 Zona Trust ethernet2

10.1.1.1/24 10.1.2.1/24
Receptores
Ajustar una configuración de PIM-SM básica 185

WebUI
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Direcciones
en OK:

Zone: Trust
en OK:

Zone: Untrust
3. IGMP



4. RIP
Network > Routing > Virtual Router (trust-vr) > Edit > Create RIP Instance:
Seleccione Enable RIP y haga clic en OK.
Network > Interfaces > Edit (para ethernet3) > RIP: Introduzca los siguientes
RIP Instance: (seleccione)

Protocol RIP: Enable (seleccione)
5. PIM-SM
Network > Routing > Virtual Router (trust-vr) > Edit > Create PIM Instance:
Seleccione los siguientes datos, luego haga clic en OK.



6. Directivas
haga clic en OK:
Source Address:
Service: any
Action: Permit

BSR Static RP: (seleccione)
Ajustar una configuración de PIM-SM básica 187

CLI
2. Direcciones
set address untrust source-dr 6.6.6.1/24
3. IGMP
4. RIP
set interface ethernet3 protocol rip enable
5. PIM-SM
set vrouter trust-vr protocol pim
set vrouter trust-vr protocol pim enable
6. Directivas
set policy from untrust to trust source-dr mgroup1 any permit
set multicast-group-policy from trust mgroup 224.4.4.1/32 any to untrust
pim-message bsr-static-rp join bi-directional
save

Comprobar la configuración
Para verificar la configuración de PIM-SM, ejecute el comando siguiente:
ns-> get vrouter trust protocol pim

PIM-SM enabled
Number of interfaces : 1
SPT threshold : 1 Bps
PIM-SM Pending Register Entries Count : 0
Multicast group accept policy list: 1
Virtual Router trust-vr - PIM RP policy
--------------------------------------------------
Group Address RP access-list
Virtual Router trust-vr - PIM source policy
--------------------------------------------------
Group Address Source access-list
Para visualizar las entradas de la ruta multicast, ejecute el comando siguiente:
ns-> get igmp group

total groups matched: 1
multicast group interface last reporter expire ver
*224.4.4.1 trust 0.0.0.0 ------ v2
ns->get vrouter trust protocol pim mroute

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 01:54:20/- Flags: LF

Zone : Untrust
Downstream :
ethernet1/2 01:54:20/- Join 0.0.0.0 FC
(10.10.10.1/24, 238.1.1.1) 01:56:35/00:00:42 Flags: TLF Register Prune

Zone : Trust
Downstream :
ethernet1/2 01:54:20/- Join 236.1.1.1 20.20.20.200 FC
Comprobar la configuración 189

En cada entrada de la ruta puede verificar lo siguiente:
El estado (S, G) o estado de reenvío (*, G)
Si el estado de reenvío es (*, G), la dirección IP del RP; si el estado de reenvío es

(S, G), la dirección IP de origen
Zona que posee la ruta
El estado de “conexión” y las interfaces entrantes y salientes
Valores del temporizador
Para visualizar los puntos de encuentro en cada zona, ejecute el comando siguiente:
ns-> get vrouter trust protocol pim rp

Flags: I - Imported, A - Always(override BSR mapping)
C - Static Config, P - Static Proxy
-----------------------------------------------------------------------------
Trust
238.1.1.1/32 RP: 10.10.10.10 192 Static - C
Registering : 0
Active Groups : 1
238.1.1.1
Untrust
236.1.1.1/32 RP: 20.20.20.10 192 Static - P
Registering : 0
Active Groups : 1
236.1.1.1
Para verificar que hay un vecino de reenvío por rutas inversas, ejecute el comando
siguiente:
ns-> get vrouter trust protocol pim rpf

Flags: RP address - R, Source address - S
Address RPF Interface RPF Neighbor Flags
-------------------------------------------------------
10.10.11.51 ethernet3 10.10.11.51 R
10.150.43.133 ethernet3 10.10.11.51 S
Para visualizar el estado de los mensajes join-prune que el dispositivo de seguridad

envía a cada vecino de un enrutador virtual, ejecute el comando siguiente:
ns-> get vrouter untrust protocol pim join

Neighbor Interface J/P Group Source
---------------------------------------------------------------------
1.1.1.1 ethernet4:1 (S,G) J 224.11.1.1 60.60.0.1
(S,G) J 224.11.1.1 60.60.0.1
190 Comprobar la configuración

Configurar puntos de encuentro

Puede configurar un punto de encuentro (RP) estático si desea asociar un RP
específico a uno o más grupos multicast. Puede configurar múltiples RP estáticos
con cada RP asignado a un grupo multicast diferente.
Debe configurar un RP estático cuando en la red no haya enrutador bootstrap.
Aunque un dispositivo de seguridad puede recibir y procesar mensajes bootstrap,
no realiza funciones de enrutador bootstrap.
Puede configurar un enrutador virtual como RP candidato (C-RP) cuando desee
asignar RP a grupos multicast de forma dinámica. Puede crear un C-RP para
cada zona.
Configurar de un punto de encuentro estático

Cuando configure un RP estático, debe especifica lo siguiente:
La zona del RP estático

La dirección IP del RP estático
Una lista de accesos que define los grupos multicast del RP estático (Para
obtener información sobre las listas de accesos, consulte “Listas de acceso” en
la página 141).
Para asegurarse de que los grupos multicast de la lista de acceso siempre utilicen el
mismo RP, incluya la palabra clave always. Si no incluye esta palabra clave, y el
dispositivo de seguridad descubre que hay otro RP asignado dinámicamente a los
mismos grupos multicast, utilizará el RP dinámico.
En este ejemplo, creará una lista de accesos para el grupo multicast 224.4.4.1, y a
continuación creará un RP estático para dicho grupo. La dirección IP del RP estático
es 1.1.1.5/24. Especifique la palabra clave always para asegurarse de que el
dispositivo de seguridad utilice siempre el mismo RP para eso.
WebUI
Access List ID: 2
Sequence No.: 1
IP/Netmask: 224.4.4.1/32
Action: Permit
Network > Routing > Virtual Router (trust-vr) > Edit > Edit PIM Instance >
RP Address > New: Introduzca los siguientes datos y haga clic en OK:
Zone: Trust (seleccione)
Address:1.1.1.5
Access List: 2
Always: (seleccione)
CLI
set vrouter trust-vr protocol pim zone trust rp address 1.1.1.5 mgroup-list 2 always
save
Configurar puntos de encuentro 191

Configurar de un punto de encuentro candidato

Cuando configura un enrutador virtual como RP candidato, debe especificar
lo siguiente:
La zona en la que se configura el C-RP
La dirección IP de la interfaz que se notifica como C-RP
Una lista de acceso que define los grupos multicast del C-RP
La prioridad de C-RP notificada
En este ejemplo, habilitará PIM-SM en la interfaz ethernet1 que está asocidad a la

zona Trust. Creará una lista de acceso que defina los grupos multicast del C-RP. A
continuación creará un C-RP en la zona Trust del enrutador trust-vr. Establecerá la
prioridad del C-RP a 200.
WebUI

Access List ID: 1

Sequence No.: 1
IP/Netmask: 224.2.2.1/32
Action: Permit
Select Add No Seq: Introduzca los siguientes datos y haga clic en OK:
Sequence No.: 2
IP/Netmask: 224.3.3.1/32
Action: Permit
RP Candidate > Edit (Trust Zone): Seleccione los siguientes datos, luego haga
clic en OK.

Access List: 1 (seleccione)
Priority: 200
CLI
setinterface ethernet1 protocol pim
setinterface ethernet1 protocol pim enable
setvrouter trust-vr access-list 1 permit ip 224.2.2.1/32 1
setvrouter trust-vr access-list 1 permit ip 224.3.3.1/32 2
setvrouter trust-vr protocol pim zone trust rp candidate interface ethernet1
mgroup-list 1 priority 200
save
192 Configurar puntos de encuentro

Consideraciones sobre seguridad

Al ejecutar PIM-SM, hay algunas opciones que se pueden configurar en un
enrutador virtual (VR) para controlar el tráfico hacia y desde el enrutador virtual.
Los ajustes definidos en el enrutador virtual afectan a todas las interfaces PIM-SM
habilitadas en el enrutador virtual.
Cuando una interfaz recibe mensajes de tráfico de control multicast (mensajes

IGMP o PIM-SM) de otras zonas, del dispositivo de seguridad comprueba primero si
hay una directiva multicast que permita dicho tráfico. Si el dispositivo de seguridad
encuentra una directiva multicast que permita el tráfico, comprueba las opciones
del enrutador virtual que se pudieran aplicar al tráfico. Por ejemplo, si configura el
enrutador virtual para aceptar mensajes join-prune desde grupos multicast
especificados en una lista de acceso, el dispositivo de seguridad comprueba si dicho
tráfico es para un grupo multicast de la lista. Si es así, el dispositivo permite el
tráfico. Si no lo es, el dispositivo descarta el tráfico.
Restringir grupos multicast

Puede restringir un VR para que sólo reenvíe mensajes join-prune de PIM-SM de un
conjunto de grupos multicast determinado. Indique los grupos multicast
autorizados en una lista de accesos. Cuando utilice esta característica, el VR
descarta los mensajes join-prune que son para los grupos que no están en la lista de
acceso.
En este ejemplo, creará una lista de acceso con en número de identificación 1 que
autoriza a los siguientes grupos: 224.2.2.1/32 y 224.3.3.1/32. A continuación,
configure el enrutador trust-vr para aceptar mensajes join-prune de los grupos
multicast que se encuentran en la lista de acceso.
Consideraciones sobre seguridad 193

WebUI
Access List ID: 1

Sequence No.: 1
IP/Netmask: 224.2.2.1/32
Action: Permit
Sequence No.: 2
IP/Netmask: 224.3.3.1/32
Action: Permit
Network > Routing > Virtual Router (trust-vr) > Edit > Edit PIM Instance:
Seleccione los siguientes datos y haga clic en Apply:
Access Group: 1 (seleccione)
CLI
set vrouter trust-vr protocol pim accept-group 1
save
Restringir orígenes multicast

Puede controlar los orígenes desde los que un grupo multicast recibe datos.
Identifique el origen, u orígenes, permitido en una lista de acceso, a continuación
vincule la lista de acceso a los grupos multicast. Esto evita que orígenes no
autorizados envíen datos a su red. Si utiliza esta característica, el dispositivo de
seguridad descarta datos multicast de los orígenes que no se encuentran en la
lista. Si el enrutador virtual es el punto de encuentra de la zona, comprobará la
lista de acceso antes de aceptar un mensaje REGISTER de un origen. El
dispositivo de seguridad descarta los mensajes REGISTER que no provienen
de un origen autorizado.
En este ejemplo, primero creará una lista de acceso con el número de identificación
5, que especifica el origen autorizado 1.1.1.1/32. A continuación configurará el
enrutador trust-vr para que acepte datos multicast para el grupo multicast
224.4.4.1/32 desde el origen especificado en la lista de acceso.
WebUI
Access List ID: 5

Sequence No.: 1
Action: Permit
MGroup: Seleccione los siguientes datos y haga clic en Add:
MGroup: 224.4.4.1/32
Accept Source: 5 (seleccione)
194 Consideraciones sobre seguridad

CLI
set vrouter trust-vr protocol pim mgroup 224.4.4.1/32 accept-source 5
save
Restringir puntos de encuentro

Puede controlar que puntos de encuentro (RPS) están asignados a un grupo
multicast. Identifique los RP autorizados en una lista de acceso, a continuación
vincule la lista de acceso a los grupos multicast. Cuando el enrutador virtual (VR)
recibe un mensaje bootstrap para un determinado grupo, comprueba la lista de la
RP autorizados para dicho grupo. Si no encuentra una coincidencia, no selecciona
ningún RP para el grupo multicast.
En este ejemplo, creará una lista de accesos con el número de identificación 6, que
especifica el RP autorizado, 2.1.1.1/32. A continuación, configurará el enrutador
trust-vr para que acepte el RP de la lista de acceso para el grupo multicast
224.4.4.1/32.
WebUI
Access List ID: 6

Sequence No.: 1
Action: Permit
MGroup: Seleccione los siguientes datos y haga clic en Add:
MGroup: 224.4.4.1/32
Accept RP: 6 (seleccione)
CLI
set vrouter trust-vr protocol pim mgroup 224.4.4.1/32 accept-rp 6
save
Consideraciones sobre seguridad 195

Parámetros de la interfaz PIM-SM

Puede cambiar ciertos elementos predeterminados de cada interfaz en la que
habilite PIM-SM. Cuando ajuste los parámetros en este nivel, únicamente afectará
a la interfaz que usted especifique.
La Tabla 18 describe los parámetros de la interfaz PIM-SM y sus valores

predeterminados:
Tabla 18: Parámetros PIM-SIM
Parámetros de la interfaz Valor

PIM-SIM Descripción predeterminado
Neighbor policy Controla adyacencias vecinas. Para Desactivado
obtener información adicional, consulte
“Definir una directiva de vecindad” en la
página 196.
Hello interval Especifica el intervalo en el que la 30 segundos
interfaz envía mensajes de saludo a sus
enrutadores vecinos.
Designates route priority Especifica la prioridad de la interfaz 1
para la elección del enrutador
designado.
Join-Prune Interval Especifica el intervalo, en segundos, en 60 segundos
el que la interfaz envía mensajes
join-prune.
Bootstrap border Especifica que la interfaz es un borde Desactivado
bootstrap. Para obtener información
adicional, consulte “Definir un borde
bootstrap” en la página 197.
Definir una directiva de vecindad

Puede controlar los elementos vecinos con los que una interfaz puede formar una
adyacencia. Los enrutadores PIM-SM envían periódicamente mensajes de saludo
para anunciarse como enrutadores PIM-SM. Si utiliza esta característica, la interfaz
comprueba su lista de vecinos autorizados o rechazados y forma adyacencias con
aquellos que estén autorizados.
En este ejemplo, se creará una lista de acceso que especifique lo siguiente:
El número de identificación es 1.
La primera instrucción permite 2.1.1.1/24.
La segunda instrucción permite 2.1.1.3/24.
A continuación, especificará que ethernet1 puede formar una adyacencia con los
vecinos de la lista de acceso.
196 Parámetros de la interfaz PIM-SM

WebUI
Access List ID: 1

Sequence No.: 1
Action: Permit
Sequence No.: 2
Action: Permit
Accepted Neighbors: 1
CLI
set interface ethernet1 protocol pim neighbor-policy 1
save
Definir un borde bootstrap

Una interfaz que es un borde bootstrap (BSR) recibe y procesa mensajes BSR, pero
no los reenvía a otras interfaces aunque tengan una directiva de grupo multicast
que autorice mensajes BSR de una zona a otra. Así se asegura que las asignaciones
RP-a-grupo permanezcan siempre dentro de una zona.
En este ejemplo, configurará ethernet1 como borde bootstrap.
WebUI
Network > Interfaces > Edit (para ethernet1) > PIM: Seleccione Bootstrap
Border, luego haga clic en Apply.
CLI
set interface ethernet1 protocol pim boot-strap-border
save
Parámetros de la interfaz PIM-SM 197

Configurar de un punto de encuentro del proxy

Un dominio PIM-SM es un grupo de enrutadores PIM-SM que poseen las mismas
asignaciones de punto de encuentro (RP) a grupo. En un dominio PIM-SM con
asignaciones RP-group dinámicas, los enrutadores PIM-SM de un dominio escuchan
los mensajes del mismo enrutador bootstrap (BSR) para seleccionar sus
asignaciones RP-group. En un dominio PIM-SM con asignaciones RP-group
estáticas, debe configurar el RP estático en cada enrutador en el dominio. (Para
obtener información sobre asignaciones RP-group, consulte “Configurar puntos de
encuentro” en la página 191).
En los dispositivos de seguridad de Juniper Networks, las interfaces asociadas a

zonas de capa 3 se pueden ejecutar en modo NAT o en modo de ruta. Para ejecutar
PIM-SM en un dispositivo con interfaces que funcionan en modos diferentes, cada
zona deben encontrarse en un dominio PIM-SM diferente. Por ejemplo, si las
interfaces de la zona Trust están en modo NAT y las interfaces de la zona Untrust
están en modo de ruta, cada zona deben encontrarse en un dominio PIM-SM
diferente. Además, al configurar PIM-SM a través de dos enrutadores virtuales que
se encuentran en dos sistemas virtuales diferentes, cada enrutador virtual debe
estar en un dominio PIM-SM independiente.
Puede notificar grupos multicast desde un dominio PIM-SM a otro configurando un

RP proxy. Un RP proxy actúa como un RP para grupos multicast memorizado de
otro dominio PIM-SM, ya sea a través de un RP estático o a través de mensajes
bootstrap autorizados por la directiva de grupo multicast. Para los receptores de su
dominio, funciona como la raíz del árbol de distribución compartido y puede
formar el árbol de ruta más corta al origen.
Puede configurar un RP proxy por cada zona en un enrutador virtual. Para

configurar un RP proxy en una zona, debe configurar un RP candidato(C-RP) en
dicha zona. A continuación, el dispositivo de seguridad notifica la dirección IP del
C-RP como la dirección IP del RP proxy. Cuando configure el C-RP, no especifique
ningún grupo multicast en la lista de grupo multicast. Esto permite que el C-RP
actúe como el RP proxy de cualquier grupo importado de otra zona. Si especifica
grupos multicast, el C-RP funciona como el RP verdadero para los grupos
especificados en la lista.
Si hay un BSR en la zona, el RP proxy se notifica a si mismo como el RP para los

grupos multicast importados de otras zonas. Si no hay BSR en la zona del RP proxy,
éste funciona como el RP estático para los grupos multicast importados de otras
zonas. A continuación debe configurar la dirección IP del C-RP como el RP estático
en todos los demás enrutadores de la zona.
El RP proxy admite el uso de IPs asignadas (MIP) para la traducción de la dirección

de origen. Una MIP es una asignación directa (“1:1”) de una dirección IP a otra.
Puede configurar una MIP cuando desee que el dispositivo de seguridad traduzca a
otra dirección una dirección privada de una zona cuyas interfaces estén en modo
NAT. Cuando un host de la MIP en la zona de un proxy RP envía un mensaje
REGISTER, el dispositivo de seguridad traduce el origen IP a dirección MIP y envía
un nuevo mensaje REGISTER al RP verdadero. Cuando el dispositivo de seguridad
recibe el mensaje join-prune para una dirección MIP, el dispositivo asigna la MIP a la
dirección origen inicial y la envía al origen.
198 Configurar de un punto de encuentro del proxy

El RP proxy también admite la traducción de direcciones de grupos multicast entre

las zonas. Puede configurar una directiva multicast que especifique la dirección
original del grupo multicast y la dirección del grupo multicast traducida. Cuando el
dispositivo de seguridad recibe un mensaje join-prune en una interfaz de la zona del
RP proxy, traduce el grupo multicast, si es necesario, y envía el mensaje adjunto al
RP verdadero.
Considere el caso siguiente:
ethernet1 en la zona Trust está en modo NAT, y ethernet3 en la zona Untrust

está en modo de ruta.
Hay una MIP para el origen en la zona Trust.
El origen en la zona Trust envía tráfico multicast al grupo multicast

224.4.4.1/32.
Hay receptores tanto en la zona Trust como en la zona Untrust.
Hay una directiva multicast que permite el paso de mensajes PIM-SM entre las
zonas Trust y Untrust.
La zona Trust se configura como el RP proxy.
El RP y el BSR están en la zona Untrust.
Figura 35: Ejemplo de punto de encuentro del proxy
ethernet1 ethernet3
modo NAT modo de ruta
Enrutador Punto de
designado (DR) encuentro (RP)
Origen Enrutador
bootstrap
(BSR)
Receptores
Receptores
A continuación se indica el flujo de datos:
1. El origen envía datos al grupo multicast 224.4.4.1/32.
2. El enrutador designado (DR) encapsula los datos y envía mensajes REGISTER

hacia el RP.
3. El proxy del RP de la zona Trust recibe el mensaje REGISTER, y cambia a

dirección IP del origen inicial a la dirección IP de la MIP. A continuación reenvía
el mensaje hacia el RP para el grupo multicast.
Configurar de un punto de encuentro del proxy 199

4. El proxy RP envía entradas (*, G) al RP real.
5. Los receptores de la zona Trust envían mensajes adjuntos al RP proxy.
6. El RP proxy envía los paquetes multicast a los receptores de la zona Trust.
Para configurar un RP proxy, debe hacer el siguiente:
1. Cree una instancia PIM-SM en un enrutador virtual específico.
2. Habilite PIM-SM en las interfaces apropiadas.
3. Configure el RP candidato en la zona del proxy RP.
4. Configure el RP proxy.
En este ejemplo, los dispositivos de seguridad NS1 y el NS2 están conectados a

través de un túnel VPN. Ambos dispositivos ejecutan el protocolo de enrutamiento
dinámico, BGP. Configure PIM-SM en ethernet1 y tunnel.1 en NS1 y en NS2. A
continuación, en NS2, configure ethernet1 como RP estático, y cree un RP proxy en
la zona Trust del enrutador trust-vr.
Figura 36: Ejemplo de configuración del RP proxy
Interfaz de túnel
tunnel.1 ethernet1
10.4.1.1/24
Origen ethernet3 Punto de
4.1.1.1/24 encuentro
NS2 del proxy
VPN
NS1
ethernet3
Enrutador 2.2.2.2/24
bootstrap ethernet1
10.2.2.1/24
Interfaz de túnel
Punto de tunnel.1
encuentro
real
Receptores
Receptores

WebUI (NS1)
1. Interfaces
haga clic en OK:
Zone Name: Trust

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

clic en OK:

2. Direcciones
en OK:

Zone: Trust
en OK:
Address Name: branch

Zone: Untrust
3. PIM-SM
Seleccione Protocol PIM: Enable, luego haga clic enOK.


Network > Interfaces > Edit (para tunnel.1) > PIM: Introduzca los siguientes

4. VPN
y haga clic en OK.
Gateway Name: To_Branch


Gateway:

Phase 1 Proposal (For Compatible Security Level): pre-g2-3des-sha
5. BGP

Network > Routing > Virtual Router (trust-vr) > Edit: Seleccione Create BGP
Instance.

Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance >
Neighbors: Introduzca los siguientes datos y haga clic en Add:
AS Number: 65000
Remote IP: 4.1.1.1
Neighbors > Configure (para el interlocutor que acabe de agregar): Seleccione
Peer Enabled y luego haga clic en OK.
Networks: Escriba 2.2.2.0/24 en el campo IP/Netmask, luego haga clic en Add.
A continuación, introduzca 10.2.2.0/24 en el campo IP/Netmask, y haga clic en
Add de nuevo.
Network > Interfaces > Edit (para ethernet3) > BGP: Introduzca los siguientes
Protocol BGP: Enable (seleccione)

6. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), branch
Service: any
Action: Permit
MGroup Address: IP/Netmask (seleccione), 224.4.4.1/32

BSR Static IP: (seleccione)
WebUI (NS2)
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Seleccione NAT y luego haga clic en Apply.
> IGMP: Introduzca los siguientes datos y haga clic en Apply:
IGMP Mode: Router

haga clic en OK:
Zone Name: Untrust

clic en OK:


2. Direcciones
en OK:

Zone: Trust
en OK:
Address Name: corp

Zone: Untrust
3. PIM-SM
Seleccione Protocol PIM: Enable, luego haga clic enOK.

Network > Interfaces > Edit (para tunnel.1) > PIM: Introduzca los siguientes

RP Address > New: Introduzca los siguientes datos y haga clic en OK:
Zone: Trust (seleccione)

Address: 10.4.1.1/24
4. VPN
y haga clic en OK:
Gateway Name: To_Corp




5. BGP

Network > Routing > Virtual Router (trust-vr) > Edit: Seleccione Create BGP
Instance.

Neighbors: Introduzca los siguientes datos y haga clic en Add:
AS Number: 65000
Remote IP: 2.2.2.2
Neighbors > Configure (para el interlocutor que acabe de agregar): Seleccione
Peer Enabled y luego haga clic en OK.
Networks:
En el campo IP/Netmask, introduzca 4.1.1.0/24 y luego haga clic en Add.
En el campo IP/Netmask, introduzca 10.4.1.0/24, luego haga clic en Add.
Network > Interfaces > Edit (para ethernet3) > BGP: Seleccione Protocol
BGP: Enable, luego haga clic en Apply.
6. Directivas
haga clic en OK:
Source Address:
Service: any
Action: Permit
MGroup Address: IP/Netmask (seleccione), 224.4.4.1/32

BSR Static IP: (seleccione)

CLI (NS1)
1. Interfaces
2. Direcciones
set address untrust branch 10.4.1.0/24
3. PIM-SM
set vrouter trust-vr protocol pim enable
set interface tunnel.1 protocol pim
set interface tunnel.1 protocol pim enable
4. Túnel VPN
set ike gateway To_Branch address 4.1.1.1 main outgoing-interface ethernet3
set vpn Corp_Branch gateway To-Branch3 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.4.1.0/24
5. BGP
set vrouter trust-vr protocol bgp neighbor 4.1.1.1
set vrouter trust-vr protocol bgp network 2.2.2.0/24
set interface ethernet3 protocol bgp enable
set interface ethernet3 protocol bgp neighbor 4.1.1.1
6. Directivas
set policy name To-Branch from untrust to trust branch any any permit
save
CLI (NS2)
1. Interfaces

2. Direcciones
3. PIM-SM
set vrouter trust protocol pim
set interface tunnel.1 protocol pim
set interface tunnel.1 protocol pim enable
set vrouter trust protocol pim zone trust rp proxy
set vrouter trust protocol pim zone trust rp candidate interface ethernet1
set vrouter trust protocol pim enable
4. Túnel VPN
set ike gateway To_Corp address 2.2.2.2 main outgoing-interface ethernet3
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.4.1.0/24 remote-ip 10.2.2.0/24
5. BGP
set vrouter trust-vr protocol bgp neighbor 2.2.2.2
set interface ethernet3 protocol bgp neighbor 2.2.2.2
6. Directivas
set policy name To-Corp from untrust to trust corp any any permit
save
PIM-SM e IGMPv3
Los dispositivos NetScreen admiten las versiones 1, 2 y 3 de IGMP (Internet Group
Management Protocol). Si ejecuta PIM-SM con interfaces en IGMP v1 o v2, los hosts
que reciben los datos para un grupo multicast pueden recibir datos desde cualquier
origen que envíe datos al grupo multicast. Los informes de miembros de IGMP v1 y
v2 sólo indican con qué grupos multicast desean unirse los hosts. No contienen
información sobre los orígenes del tráfico de datos multicast. Cuando PIM-SM
recibe informes de miembros IGMP v1 y v2, crea entradas (*, G) en la tabla de rutas
multicast, permitiendo que cualquier origen realice envíos al grupo multicast. A
esto se le llama modelo any-source-multicast (ASM), donde los receptores se unen a
un grupo multicast sin conocer del origen que envía datos al grupo. La red cuenta
con la información sobre el origen.
Los hosts que ejecutan IGMPv3 indican a qué grupos multicast desean unirse y
desde qué orígenes esperan recibir tráfico multicast. El informe de miembro
IGMPv3 contiene la dirección del grupo multicast, el modo de filtrado, que es
“include” o “exclude”, y una lista de orígenes.
PIM-SM e IGMPv3 207

Si el modo de filtrado es include, los receptores aceptan tráfico multicast solamente

de las direcciones de la lista de origen. Cuando PIM-SM recibe un informe de
miembros IGMPv3 con una lista de origen y un modo de filtro include, crea
entradas (S, G) en la tabla de rutas multicast para todos los orígenes de la lista
de origen.
Si es el modo de filtro es exclude, los receptores no aceptan tráfico multicast de

los orígenes que se encuentran en la lista; aceptan tráfico multicast del resto de
orígenes. Cuando PIM-SM recibe un informe miembros IGMPv3 con la lista de
origen y un modo de filtro exclude, crea una entrada (*, G) para el grupo y envía un
mensaje prune para los orígenes de la lista de origen. En este caso, puede ser que
necesite configurar un punto de encuentro si los receptores no conocen la
dirección del origen.
208 PIM-SM e IGMPv3

Índice
A Enrutadores BGP
Áreas OSPF .....................................................................48 agregar ............................................................124, 132
definición .................................................................54 atributos, configuración ........................................125
interfaces, asignación a ..........................................55 notificación condicional........................................124
peso, establecimiento ...........................................125
B predeterminado, rechazo .....................................120
BGP redistribución .........................................................122
atributos de ruta ....................................................111 reflexión .................................................................128
comunidades .........................................................131 supresión ................................................................133
confederaciones ....................................................130 Enrutadores OSPF
configuraciones, seguridad ..................................119 adyacencia ...............................................................50
configuraciones, verificación ...............................118 creación de instancia OSPF en enrutador
enrutador virtual, creación de una virtual .....................................................................53
instancia en .........................................................113 designado .................................................................50
equilibrio de carga ..................................................38 designado de respaldo ............................................50
expresiones regulares ...........................................123 tipos ..........................................................................49
externos .................................................................111 Enrutadores RIP
interno ....................................................................111 alternativa ..............................................................100
introducción al protocolo .....................................110 rechazo predeterminado ........................................94
lista de acceso AS-path .........................................123 redistribución ...........................................................83
parámetros .............................................................121 resumen, configuración ..........................................99
tipos de mensaje ...................................................110 enrutadores virtuales
vecinos, autenticación ..........................................120 véase VRs
BGP, configuración enrutamiento estático ...........................................2, 2 a 9
grupos de interlocutores.......................................115 configuración .............................................................5
interlocutores .........................................................115 Interfaz nula, reenvío en ........................................10
pasos .......................................................................112 multicast .................................................................140
BGP, habilitación utilización ...................................................................3
en interfaz ..............................................................114 enrutamiento multicast
en VR ......................................................................113 IGMP .......................................................................145
PIM ..........................................................................173
C enrutamiento según el origen (SBR) ............................17
circuitos de demanda, RIP..........................................101
enrutamiento según la interfaz de origen (SIBR) .......20
configuración punto a multipunto
enrutamiento, multicast ..............................................137
OSPF .........................................................................72
equilibrio de cargas según coste de cada ruta......38, 62
consulta de rutas
múltiple VR ..............................................................36 I
secuencia ..................................................................33 IGMP
configuración, básica ............................................151
D configuración, verificación ...................................153
directivas
consultador ............................................................148
multicast .................................................................143
directivas, multicast ..............................................160
E interfaces, habilitar en ..........................................149
ECMP.........................................................................38, 62 listas de accesos, uso ............................................150
Encapsulado genérico de enrutamiento (GRE) ........141 mensajes de host ...................................................147
parámetros .....................................................153, 154
Índice IX-I
interfaces, habilitar IGMP en ...................................... 149 P

Interfaz nula, definir rutas con .................................... 10 PIM-SM ..........................................................................176
Internet Group Management Protocol configuración de puntos de encuentro ...............191
véase IGMP configuraciones de seguridad ..............................193
enrutador designado .............................................177
L IGMPv3 ...................................................................207
listas de acceso instancias, creación ..............................................181
enrutamiento multicast ........................................ 141 parámetros de interfaz .........................................196
IGMP ....................................................................... 150 pasos de configuración .........................................180
para rutas ................................................................. 42 proxy RP ................................................................198
PIM-SM ................................................................... 193 puntos de encuentro .............................................177
load-balancing by path cost ......................................... 62 tráfico, reenvío ......................................................178
PIM-SSM........................................................................180
M Protocol Independent Multicast
multicast
véase PIM
árboles de distribución ......................................... 176
Protocolo de información de enrutamiento
direcciones ............................................................. 138
véase RIP
directivas ................................................................ 143
Proxies de IGMP
directivas para IGMP............................................. 160
emisor.....................................................................167
reenvío por rutas inversas ................................... 138
en interfaces ..........................................................158
rutas estáticas ........................................................ 140
tablas de enrutamiento ........................................ 139 Proxy de IGMP .............................................................155
N R
Números de sistema autónomo (AS) ........................ 113 RIP
autenticación de vecinos ........................................92
O base de datos .........................................................100
Open Shortest Path First configuración de circuito de demanda ...............101
Consulte OSPF equilibrio de carga ..................................................38
OSPF filtrado de vecinos ...................................................93
área de rutas internas ............................................. 49 instancias, creación en VR .....................................82
área no exclusiva de rutas internas ...................... 49 interfaces, habilitar en ............................................83
conexiones virtuales ............................................... 63 inundaciones, protección contra ...........................95
configuración de seguridad.................................... 67 parámetros de interfaz ...........................................91
ECMP support .......................................................... 62 parámetros globales................................................89
equilibrio de carga .................................................. 38 punto a multipunto ...............................................104
interfaces, asignación a áreas ............................... 55 resumen de prefijo ..................................................99
interfaces, túnel....................................................... 72 versiones ..................................................................97
inundación, LSA reducida ...................................... 71 versiones, protocolo................................................97
inundaciones, protección contra ........................... 70 RIP, configuración
LSA, supresión ......................................................... 71 circuitos de demanda ...........................................102
notificaciones de estado de conexiones............... 48 pasos .........................................................................81
parámetros de interfaz ........................................... 65 seguridad ..................................................................92
parámetros globales ............................................... 61 RIP, visualización
pasos de configuración........................................... 52 base de datos ...........................................................86
protocolo de saludo ................................................ 50 detalles de interfaz ..................................................88
punto a multipunto ................................................. 72 detalles de protocolo...............................................86
red punto a punto ................................................... 50 información de vecinos ..........................................87
redes de difusión ..................................................... 50 rutas
soporte de ECMP ..................................................... 62 exportación ..............................................................44
tipo de conexión, establecimiento ........................ 72 filtrado ......................................................................42
vecinos, autenticación ............................................ 67 importar ...................................................................44
vecinos, filtrado ....................................................... 68 mapas .......................................................................40
métricas ....................................................................32
preferencia ...............................................................31
redistribución...........................................................39
selección ...................................................................31
IX-II Índice
Índice
Rutas BGP, agregado

AS-Path en ..............................................................134
AS-Set en ................................................................132
atributos de ............................................................135
Rutas BGP, agregar
agregar....................................................................132
Rutas OSPF
predeterminado, rechazo .......................................69
redistribución...........................................................59
redistribuido, resumen ...........................................60
restricción route-deny, inhabilitación ...................73
S
Supresión de notificaciones de estado de
conexiones (LSA).........................................................71
T
tablas de enrutamiento .................................................15
búsqueda en múltiples VR .....................................36
consulta ....................................................................33
multicast .................................................................139
selección de rutas ....................................................31
tipos ..........................................................................15
V
VR, rutas
exportación ..............................................................44
filtrado ......................................................................42
importar ...................................................................44
mapas .......................................................................40
preferencia ...............................................................31
redistribución...........................................................39
selección ...................................................................31
VR, tablas de enrutamiento
búsqueda en múltiples VR .....................................36
consulta ....................................................................33
entradas máximas ..................................................30
VRs .......................................................................... 39 a 44
BGP ............................................................... 112 a 119
ECMP ........................................................................38
en vsys ......................................................................27
ID de enrutador .......................................................23
listas de acceso ........................................................42
métricas de ruta ......................................................32
modificar ..................................................................22
OSPF ................................................................. 51 a 70
RIP..................................................................... 81 a 97
SBR............................................................................17
SIBR ..........................................................................20
uso de dos ................................................................24
Índice IX-III
IX-IV Índice
Volumen 8:

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Copyright Notice
without notice.
FCC Statement
Disclaimer
Writer: Richard Biegel, Sharmila Kumar

ii
Contenido
Capítulo 1 Traducción de direcciones 1

Introducción a la traducción de direcciones ..................................................... 1
Traducir direcciones de red de origen........................................................ 1
Traducir direcciones de red de destino ......................................................3
NAT-Dst basada en directivas.............................................................. 5
Dirección IP asignada.......................................................................... 7
IP virtual ............................................................................................. 7
Opciones de la traducción basada en directivas ............................................... 8
Ejemplo: NAT-Src desde un conjunto DIP con PAT .................................... 8
Ejemplo: NAT-Src desde un conjunto DIP sin PAT ..................................... 9
Ejemplo: NAT-Src desde un conjunto DIP con desplazamiento de
direcciones.......................................................................................... 9
Ejemplo: NAT-Src desde la dirección IP de la interfaz de salida ............... 10
Ejemplo: NAT-Dst a una dirección IP única con asignación de puerto...... 10
Ejemplo: NAT-Dst a una dirección IP única sin asignación de puerto....... 10
Ejemplo: NAT-Dst desde un rango de direcciones IP a una
sola dirección IP................................................................................ 11
Ejemplo: NAT-Dst entre rangos de direcciones IP .................................... 11
Naturaleza direccional de NAT-Src y NAT-Dst ................................................ 12
Capítulo 2 Traducción de direcciones de red de origen 15

Introducción a NAT-Src .................................................................................. 15
NAT-Src desde un rango DIP con PAT habilitada............................................ 17
Ejemplo: NAT-Src con PAT habilitada ...................................................... 17
NAT-Src desde un rango DIP con PAT inhabilitada......................................... 20
Ejemplo: NAT-Src con PAT inhabilitada ................................................... 20
NAT-Src desde un conjunto de DIP con desplazamiento de direcciones......... 22
Ejemplo: NAT-Src con desplazamiento de direcciones............................. 23
NAT-Src desde la dirección IP de la interfaz de salida .................................... 26
Ejemplo: NAT-Src sin DIP ........................................................................ 26
Capítulo 3 Traducción de direcciones de red de destino 29

Introducción a NAT-Dst.................................................................................. 30
Flujo de paquetes para NAT-Dst............................................................... 31
Contenido iii
Enrutamiento para NAT-Dst..................................................................... 34

Ejemplo: Direcciones conectadas a una interfaz................................ 35
Ejemplo: Direcciones conectadas a una interfaz
pero separadas por un enrutador................................................ 36
Ejemplo: Direcciones separadas por una interfaz .............................. 36
NAT-Dst— Asignación de “1:1” ...................................................................... 37
Ejemplo: Traducción de destinos “1:1”....................................................38
Traducción de una dirección a múltiples direcciones............................... 40
Ejemplo: Traducción de destinos “1:n” ............................................. 40
NAT-Dst—Asignación de “n:1”....................................................................... 43
Ejemplo: Traducción de destinos “n:1”....................................................43
NAT-Dst— Asignación de “n:n”...................................................................... 46
Ejemplo: Traducción de destinos “n:n”....................................................47
NAT-Dst con asignación de puertos................................................................ 49
Ejemplo: NAT-Dst con asignación de puertos .......................................... 49
NAT-Src y NAT-Dst en la misma directiva ...................................................... 52
Ejemplo: NAT-Src y NAT-Dst combinadas................................................ 52
Capítulo 4 Direcciones virtuales y asignadas 65

Direcciones IP asignadas................................................................................ 65
MIP y la zona Global ................................................................................ 66
Ejemplo: MIP en una interfaz de la zona Untrust............................... 67
Ejemplo: Alcanzar una MIP desde diferentes zonas........................... 69
Ejemplo: Adición de una MIP a una interfaz de túnel ........................ 72
MIP-Same-as-Untrust ............................................................................... 73
Ejemplo: MIP en la interfaz Untrust................................................... 74
MIP y la interfaz de bucle invertido (loopback) ........................................ 76
Ejemplo: MIP para dos interfaces de túnel ........................................ 76
Agrupamiento de MIP.............................................................................. 82
Ejemplo: Agrupamiento de MIP con directivas de celdas múltiples ... 82
Direcciones IP virtuales.................................................................................. 83
VIP y la zona Global................................................................................. 85
Ejemplo: Configuración de servidores de IP virtuales ........................ 85
Ejemplo: Edición de una configuración de VIP .................................. 87
Ejemplo: Eliminación de una configuración VIP ................................ 87
Ejemplo: VIP con servicios personalizados y de múltiples puertos .... 88
Índice ........................................................................................................................IX-I
iv
El Volumen 8: Traducción de direcciones se enfoca en varios métodos disponibles en

ScreenOS para realizar la traducción de direcciones. Este volumen contiene los
siguientes capítulos, los cuales describen cómo configurar el dispositivo de
seguridad de Juniper Networks para realizar los siguientes tipos de traducción:
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, o Port Address Translation).
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-Src, 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).
NOTA: Para conocer la cobertura de la traducción de dirección de origen de red con base
en la interfaz, sencillamente consulte “Modo NAT” en la página 2 -94.



En ejemplos:


ethernet2, o ethernet3”.
En texto:
Los comandos aparecen en tiponegrita.



10.1.1.0/24)

Internet

dinámicas (DIP)

Equipo portátil
Interfaz de túnel
Servidor
Túnel VPN
Concentrador (hub)
Enrutador
Teléfono IP
Conmutador


Si una cadena de nombres incluye uno o más espacios, la cadena completa

deberá entrecomillarse mediante comillas dobles ( “ ); por ejemplo:

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


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.


de configuración:

en OK:
Zone: Untrust





Capítulo 1
ScreenOS proporciona varios métodos para realizar la traducción de dirección de

puerto e IP de destino y origen. Este capítulo describe los diversos métodos de
traducción de direcciones disponibles y contiene las siguientes secciones:
“Introducción a la traducción de direcciones” en esta página
“Traducir direcciones de red de origen” en esta página
“Traducir direcciones de red de destino” en la página 3
“Opciones de la traducción basada en directivas” en la página 8
“Naturaleza direccional de NAT-Src y NAT-Dst” en la página 12
Introducción a la traducción de direcciones

ScreenOS proporciona varios mecanismos para aplicar la traducción de direcciones
de red (NAT). NAT incluye la traducción de la dirección de Protocolo de Internet (IP)
en un encabezado de paquetes de IP y, opcionalmente, la traducción del número de
puerto en el segmento del Protocolo de control de transmisión (TCP) o el
encabezado del datagrama del Protocolo de datagrama del usuario (UDP). La
traducción puede implicar la dirección de origen (y opcionalmente el número del
puerto de origen), la dirección de destino (y opcionalmente el número de puerto de
destino), o una combinación de elementos traducidos.
Traducir direcciones de red de origen

Al realizar la traducción de direcciones de red de origen (NAT-Src), el dispositivo de
seguridad traduce la dirección IP de origen original a otra dirección. La dirección
traducida puede proceder de un conjunto de direcciones IP dinámicas (DIP) o de la
interfaz de salida del dispositivo de seguridad. Si el dispositivo de seguridad toma la
dirección traducida de un conjunto DIP, puede hacerlo de forma arbitraria o
determinista; es decir, puede tomar cualquier dirección del conjunto DIP al azar o
puede tomar una y otra vez una dirección específica relacionada con la dirección IP
original de origen.
Introducción a la traducción de direcciones 1

NOTA: La traducción de direcciones determinista utiliza una técnica llamada

“desplazamiento de direcciones”, que se explica más adelante en este capítulo.
Para obtener más información sobre el desplazamiento de direcciones que aplican
a NAT-Src, consulte “NAT-Src desde un conjunto de DIP con desplazamiento de
direcciones” en la página 22. Para obtener más información sobre el
desplazamiento de direcciones que aplica a NAT-Dst, consulte “NAT-Src y NAT-Dst
en la misma directiva” en la página 52.
Si la dirección traducida procede de la interfaz de salida, el dispositivo de seguridad

traduce la dirección IP de origen en todos los paquetes a la dirección IP de esa
interfaz. Puede configurar el dispositivo de seguridad para aplicar NAT-Src a nivel de
interfaz o a nivel de directiva. Si configura una directiva para aplicar NAT-Src y la
interfaz de ingreso se encuentra en modo NAT, los ajustes de NAT-Src basada en
directivas tienen preferencia sobre la NAT basada en interfaz. (Este capítulo se
centra en NAT-scr basada en directivas). Para obtener detalles sobre NAT-Src basada
en interfaz o NAT en solitario, consulte “Modo NAT” en la página 2-94. Para obtener
más información sobre conjuntos de DIP, consulte “Conjuntos de IP dinámicas” en
la página 2-144.)
NOTA: Puede utilizar NAT-Src basada en directivas cuando la interfaz de ingreso se

encuentra en el modo de ruta o NAT. Si se encuentra en modo NAT, los
parámetros de NAT-Src a nivel de directivas reemplazan a los parámetros de NAT
a nivel de interfaz.
Figura 4: Traducción de la dirección IP de origen
Direcciones IP de origen originales Direcciones IP de origen traducidas
IP ORIG IP DEST IP ORIG IP DEST
Paquete IP 10.1.1.5 2.2.2.2 Carga

1.1.1.5 2.2.2.2 Carga
de datos de datos
Con NAT-Src basada en directivas, puede elegir opcionalmente que el dispositivo de

seguridad realice la traducción de direcciones del puerto (PAT) del número original
del puerto de origen. Con PAT habilitada, el dispositivo de seguridad puede traducir
hasta unas 64.500 direcciones IP diferentes a una sola dirección IP con hasta unos
64.500 puertos diferentes. El dispositivo de seguridad utiliza el número traducido
de puerto único para mantener la información del estado de la sesión
correspondiente al tráfico entrante y saliente de la misma dirección IP única. Para
NAT-Src basada en interfaces (o conocida simplemente como NAT), PAT está
habilitada automáticamente. Dado que el dispositivo de seguridad traduce todas las
direcciones IP originales a la misma dirección IP traducida (la de la interfaz de
salida), el dispositivo de seguridad utiliza el número de puerto traducido para
identificar a qué sesión corresponde cada paquete. De forma similar, si un conjunto
DIP consta solamente de una dirección IP y se desea que el dispositivo de seguridad
aplique NAT-Src a varios hosts utilizando esa dirección, entonces se requiere PAT por
la misma razón.
2 Introducción a la traducción de direcciones

NOTA: Con PAT habilitada, el dispositivo de seguridad mantiene un conjunto de números
de puerto libres para asignar junto con direcciones del conjunto DIP. La cifra de
unos 64.500 se calcula restando 1023 (los números reservados para los puertos
conocidos) del número máximo de puertos, que es 65.535. Por lo tanto, cuando el
dispositivo de seguridad realiza NAT-Src con un conjunto DIP que contiene una
sola dirección IP y la traducción PAT está habilitada, el dispositivo de seguridad
puede traducir las direcciones IP originales de hasta unos 64.500 hosts a una sola
dirección IP y cada número de puerto original a un número de puerto único.
Figura 5: Traducción de dirección de puerto de origen e IP de origen
Direcciones originales de puertos e IPs de origen Direcciones traducidas de puertos e IPs de origen
Paquete IP Carga Carga

10.1.1.5 2.2.2.2 de datos
1.1.1.5 2.2.2.2 de datos
Segmento TCP Puerto Puerto Puerto Puerto

o datagrama origen destino origen destino
UDP
30777 53 Carga 44235 53 Carga
de datos de datos
En aplicaciones personalizadas que requieran un número específico de puerto de

origen para funcionar correctamente, la ejecución de PAT provoca que esas
aplicaciones fallen. Para prevenir tales casos, puede desactivar PAT.
NOTA: Para obtener más información sobre NAT-Src, consulte “Traducción de direcciones
de red de origen” en la página 15.
Traducir direcciones de red de destino

ScreenOS ofrece los tres mecanismos siguientes para realizar la traducción de
direcciones de red de destino (NAT-Dst):
NAT-Dst basada en directivas: consulte “NAT-Dst basada en directivas” en la

página 5
MIP: consulte “Dirección IP asignada” en la página 7
VIP: consulte “IP virtual” en la página 7
Las tres opciones traducen la dirección IP original de destino del encabezado de

paquetes IP a otra dirección. Con NAT-Dst basada en directivas y VIP, también tiene
la opción de habilitar la asignación de puertos.

NOTA: Para obtener información sobre la asignación de puertos, consulte “NAT-Dst

basada en directivas” en la página 5 y “Traducción de direcciones de red de
destino” en la página 29.
ScreenOS no admite el uso de NAT-Dst basada en directivas en combinación con

MIP y VIP. Si tiene configurada una MIP o VIP, el dispositivo de seguridad la
aplicará a cualquier tráfico al que también sea aplicable una configuración NAT-Dst
basada en directivas. En otras palabras, las MIP y VIP desactivan NAT-Dst basada
en directivas si el dispositivo de seguridad está casualmente configurado para
aplicar ambas al mismo tráfico.

NAT-Dst basada en directivas
Puede configurar una directiva para traducir una dirección IP de destino a otra
dirección, un conjunto de direcciones IP a una sola dirección IP, o un conjunto de
direcciones IP a otro conjunto. Cuando una sola dirección IP de destino se traduce a
otra dirección IP o un conjunto de direcciones IP se traduce a una sola dirección IP,
ScreenOS puede admitir NAT-Dst con o sin asignación de puertos. La asignación de
puertos es la traducción determinista de un número de puerto de destino original a
otro número específico, a diferencia de PAT, que traduce cualquier número de
puerto de origen original asignado aleatoriamente por el equipo iniciador a otro
número asignado aleatoriamente por el dispositivo de seguridad.
Figura 6: Traducción de direcciones IP de destino
Traducción de direcciones IP de destino sin asignación de puertos de destino

Dirección IP y destino original Dirección IP de destino traducida
Puerto Puerto
IP ORIG IP DEST origen destino
Paquete IP Carga Carga

1.1.1.5 2.2.2.2 de datos 1.1.1.5 10.3.1.6 de datos
Destination IP Address Translation without

Traducción de direcciones IP de destino con asignación de puertos de destino
Destination Port Mapping
Direcciones IP y puerto y de destino originales Direcciones IP y puerto y de destino originales
Puerto Puerto Puerto Puerto

origen destino origen destino
Paquete IP 1.1.1.5 2.2.2.2 Carga 1.1.1.5 10.3.1.6 Carga

de datos de datos
Segmento TCP
o Datagrama
UDP 44235 6055 Carga 44235 53 Carga
de datos de datos
Cuando se configura una directiva para ejecutar NAT-Dst con el fin de traducir un
conjunto de direcciones a una sola dirección, el dispositivo de seguridad traduce
cualquier dirección IP de destino del conjunto de direcciones de destino originales
definido por el usuario a una sola dirección. También puede habilitar la asignación
de puertos.

Figura 7: NAT-Dst desde un rango de direcciones IP a una sola dirección IP
Traducción de las direcciones IP de destino de un rango de direcciones IP a una dirección IP única

Dirección IP y destino original Dirección IP de destino traducida
Carga Carga
1.1.1.5 2.2.2.2 de datos 1.1.1.5 10.3.1.6 de datos
Paquetes IP
Carga Carga
1.1.1.5 2.2.2.3 de datos 1.1.1.5 10.3.1.6 de datos
Traducción de direcciones IP de destino de un rango de direcciones IP a una dirección IP única con asignación de puertos de destino
Direcciones IP y puerto y de destino original Direcciones IP de destino y de puertos traducidas
Carga Carga
Paquete IP 1 1.1.1.5 2.2.2.2 de datos 1.1.1.5 10.3.1.6 de datos
Puerto Puerto Puerto Puerto

origen destino origen destino
Carga Carga
Segmento TCP 1 44235 8000 de datos 44235 80 de datos
Paquete IP 2 1.1.1.5 2.2.2.3 Carga 1.1.1.5 10.3.1.6 Carga

de datos de datos
Segmento TCP 2 Carga Carga

28560 8000 28560 80
de datos de datos
Al configurar una directiva para realizar NAT-Dst en un rango de direcciones, el

dispositivo de seguridad utiliza el desplazamiento de direcciones para traducir una
dirección IP de destino de un rango de direcciones de destino originales a una
dirección conocida de otro rango de direcciones.

Figura 8: NAT-Dst con desplazamiento de direcciones
Direcciones IP de destino originales Direcciones IP de destino traducidas
IP IP IP IP
ORIG DEST ORIG DEST
Paquetes 1.1.1.5 2.2.2.2 Carga de 1.1.1.5 10.3.1.6 Carga de

IP datos datos
1.1.1.5 2.2.2.3 Carga de 1.1.1.5 10.3.1.7 Carga de

datos datos
1.1.1.5 2.2.2.4 Carga de 1.1.1.5 10.3.1.8 Carga de

datos datos
Al realizar NAT-Dst en un rango de direcciones IP, el dispositivo de seguridad mantiene una correspondencia entre cada
dirección IP de un rango de direcciones y la dirección IP correspondiente en otro rango de direcciones.
NOTA: NAT-Src y NAT-Dst se pueden combinar en la misma directiva. Cada mecanismo

de traducción funciona de forma independiente y unidireccional. Es decir, si
habilita NAT-Dst para el tráfico de zone1 a zone2, el dispositivo de seguridad no
aplicará NAT-Src al tráfico originado en zone2 y destinado a zone1 salvo que lo
configure específicamente para hacerlo. Para obtener más información, consulte
“Naturaleza direccional de NAT-Src y NAT-Dst” en la página 12. Para obtener más
información sobre NAT-Dst, consulte “Traducción de direcciones de red de
destino” en la página 29.
Dirección IP asignada
Un Protocolo de internet asignado (MIP) es una asignación de una dirección IP a
otra dirección IP. Una de las direcciones debe definirse en la misma subred que una
dirección IP de interfaz. La otra dirección pertenece al host al que se desea dirigir el
tráfico. La traducción de direcciones para un MIP se comporta de forma
bidireccional, de modo que el dispositivo de seguridad traduce la dirección IP de
destino de todo el tráfico dirigido a una MIP a la dirección IP del host, y la dirección
IP de origen de todo el tráfico procedente de la dirección IP del host a la dirección
MIP. Los MIP no admiten asignaciones de puertos. Para obtener más información
sobre MIP, consulte “Direcciones IP asignadas” en la página 65.
IP virtual
Un Protocolo de Internet virtual (VIP) es una asignación de una dirección IP a otra
dirección IP basada en el número de puerto de destino. Una sola dirección IP
definida en la misma subred que una interfaz puede contener asignaciones de
varios servicios (identificados por los diferentes números de puertos de destino) a
otros tantos hosts. VIP también admiten asignaciones de puertos. A diferencia de
los MIP, la traducción de direcciones para una VIP ocurre de forma unidireccional.
El dispositivo de seguridad traduce la dirección IP de destino de todo el tráfico que
viene de VIP hacia una dirección IP del host. (El dispositivo de seguridad revisa
únicamente si la dirección IP de destino está ligada a VIP en paquetes que llegan en
una interfaz unida a la zona Untrust). El dispositivo de seguridad no traduce la
dirección IP original de origen en tráfico saliente de un host VIP a la dirección VIP.
En lugar de eso, el dispositivo de seguridad aplica la NAT-scr basada en directivas o

basada en interfaz, si usted lo configuró así previamente. De otra manera, el

dispositivo de seguridad no realiza ninguna NAT-Src en el tráfico que se origina de
un host VIP. Para obtener más información sobre VIP, consulte “Direcciones IP
virtuales” en la página 83.
NOTA: En algunos dispositivos de seguridad de Juniper Networks, se puede definir una

VIP para actuar del mismo modo que una dirección IP de interfaz. Esta posibilidad
resulta muy útil cuando el dispositivo de seguridad solamente tiene asignada una
dirección IP, y cuando ésta se asigna dinámicamente.
Mientras que los mecanismos de traducción de direcciones para MIPs y VIPs son
bidireccionales, la funcionalidad proporcionada por NAT-Src y NAT-Dst basados en
directivas mantienen separada la traducción de direcciones de los tráficos entrante
y saliente, aumentando las posibilidades de control y la seguridad. Por ejemplo, si
utiliza una asignación MIP a un servidor Web, siempre que ese servidor inicie un
tráfico saliente para obtener una actualización o parche, su actividad quedará
expuesta, siendo susceptible de que un posible atacante la utilice. Los métodos de
traducción de direcciones basada en directivas permiten definir una asignación de
direcciones cuando el servidor web recibe tráfico (mediante NAT-Dst) y otra
asignación cuando inicia tráfico (mediante NAT-Src). Manteniendo sus actividades
ocultas, puede proteger mejor el servidor contra cualquiera que intente recopilar
información para preparar un ataque. En esta versión de ScreenOS, NAT-Src y
NAT-Dst basadas en directivas ofrecen una estrategia común que puede duplicar y
sobrepasar la funcionalidad de MIP y VIP basadas en interfaces.
Opciones de la traducción basada en directivas

ScreenOS proporciona las siguientes maneras de aplicar la Traducción de
direcciones de red de origen (NAT-Src) y la Traducción de direcciones de red de
destino (NAT-Dst). Observe que NAT-Src y NAT-Dst se pueden combinar dentro de
una misma directiva.
Ejemplo: NAT-Src desde un conjunto DIP con PAT

El dispositivo de seguridad traduce la dirección IP original de origen a una dirección
tomada de un conjunto de IP dinámica (DIP). El dispositivo de seguridad también
aplica la traducción de direcciones de origen de los puertos (PAT). Para obtener más
información, consulte “NAT-Src desde un rango DIP con PAT habilitada” en la
página 17.
8 Opciones de la traducción basada en directivas

Figura 9: NAT-Src con traducción de dirección de puerto
Conjunto DIP ID 5
1.1.1.10 – 1.1.1.40
1.1.1.20
10.1.1.1/24 1.1.1.1/24
10.1.1.5:25611 1.1.1.20:41834 2.2.2.2:80
(Dispositivo virtual)
Origen original Origen traducido Destino
NOTA: En la Figura 9 y en las siguientes figuras se utiliza un “dispositivo virtual” para

indicar una dirección de origen o de destino traducida cuando dicha dirección no
pertenece a un dispositivo real.
Ejemplo: NAT-Src desde un conjunto DIP sin PAT

tomada de un conjunto de IP dinámica (DIP). El dispositivo de seguridad no aplica
PAT de origen. Para obtener más información, consulte “NAT-Src desde un rango
DIP con PAT inhabilitada” en la página 20.
Figura 10: NAT-Src sin traducción de dirección de puerto
Conjunto DIP ID 5
1.1.1.10 – 1.1.1.40
1.1.1.25
10.1.1.1/24 1.1.1.1/24
10.1.1.6:35030 1.1.1.25:35030 2.2.2.2:80
Ejemplo: NAT-Src desde un conjunto DIP con desplazamiento de direcciones

tomada de un conjunto de IP dinámica (DIP) y asigna consistentemente cada
dirección original a una dirección determinada traducida. El dispositivo de
seguridad no aplica la traducción de direcciones de los puertos de origen (PAT). Para
obtener más información, consulte “NAT-Src desde un conjunto de DIP con
desplazamiento de direcciones” en la página 22.
Opciones de la traducción basada en directivas 9

Figura 11: NAT-Src con desplazamiento de direcciones
Conjunto DIP ID 5
1.1.1.10 – 1.1.1.40
1.1.1.20
Zona Trust 1.1.1.21
ethernet1 ethernet3 Zona Untrust
10.1.1.20:25611 10.1.1.1/24 1.1.1.1/24 1.1.1.20:25611
2.2.2.2:80
10.1.1.21:35030
1.1.1.21:35030
(Dispositivos
10.1.1.20 siempre se traduce a 1.1.1.20. virtuales)
10.1.1.21 siempre se traduce a 1.1.1.21. Destino
Origen original Origen traducido
Ejemplo: NAT-Src desde la dirección IP de la interfaz de salida

El dispositivo de seguridad traduce la dirección IP original de origen a la dirección
de la interfaz de salida. El dispositivo de seguridad también aplica PAT de origen.
Para obtener más información, consulte “NAT-Src desde la dirección IP de la
interfaz de salida” en la página 26.
Figura 12: NAT-Src con la dirección IP de la interfaz de salida

10.1.1.1/24 1.1.1.1/24
10.1.1.20:25611 1.1.1.25:35030 2.2.2.2:80
1.1.1.1
Ejemplo: NAT-Dst a una dirección IP única con asignación de puerto

El dispositivo de seguridad realiza la Traducción de dirección de red de destino
(NAT-Dst) y la asignación de puerto de destino. Para obtener más información,
consulte “NAT-Dst con asignación de puertos” en la página 49.
Figura 13: NAT-Dst con asignación de puertos
2.2.2.8:7777
ethernet3 ethernet1 Zona Trust
Zona Untrust 1.1.1.1/24 10.2.2.1/24
1.1.1.5
10.2.2.8:80
Origen Destino Destino

original traducido
Ejemplo: NAT-Dst a una dirección IP única sin asignación de puerto

El dispositivo de seguridad realiza NAT-Dst pero no cambia el número de puerto de
destino original. Para obtener más información, consulte “Traducción de
direcciones de red de destino” en la página 29.
10 Opciones de la traducción basada en directivas

Figura 14: NAT-Dst sin asignación de puertos
2.2.2.8:80
ethernet3 ethernet1 Zona Trust
Zona Untrust 1.1.1.1/24 10.2.2.1/24
1.1.1.5 10.2.2.8:80
(Dispositivo
virtual)
Origen
Destino Destino
original traducido
Ejemplo: NAT-Dst desde un rango de direcciones IP a una sola dirección IP

El dispositivo de seguridad realiza NAT-Dst para traducir un rango de direcciones IP
a una sola dirección IP. Si también habilita la asignación de puertos, el dispositivo
de seguridad traducirá el número de puerto de destino original a otro número. Para
obtener más información, consulte “NAT-Dst—Asignación de “n:1”” en la
página 43.
Figura 15: NAT-Dst desde un rango de direcciones a una sola dirección IP
2.2.2.8:80
1.1.1.5:25611 Zona Untrust ethernet3 Zona DMZ

1.1.1.1/24 ethernet2
10.2.2.1/24
10.2.2.8:80
2.2.2.9:80
10.2.2.8:80
2.2.2.8 y 2.2.2.9 se traducen

1.1.1.6:40365 siempre a 10.2.2.8. Destino
traducido
Orígenes (Dispositivos virtuales)
Destinos originales
Ejemplo: NAT-Dst entre rangos de direcciones IP

Cuando se aplica NAT-Dst a un rango de direcciones IP, el dispositivo de seguridad
mantiene una asignación constante de una dirección de destino original a una
dirección traducida del rango especificado usando una técnica denominada
desplazamiento de direcciones. Observe que el desplazamiento de direcciones no
admite asignaciones de puertos. Para obtener más información, consulte
“NAT-Dst— Asignación de “n:n”” en la página 46.
Opciones de la traducción basada en directivas 11

Figura 16: NAT-Dst entre rangos de direcciones
2.2.2.8:80 10.2.2.8:80
Zona Untrust ethernet3 ethernet1
1.1.1.1/24 10.2.2.1/24
Zona Trust
1.1.1.5
2.2.2.9:80 10.2.2.9:80
1.1.1.6 2.2.2.8 se traduce siempre a 10.2.2.8 y

2.2.2.9 se traduce siempre a 10.2.2.9.
Orígenes
(Dispositivos virtuales) Destinos
Destinos traducidos
originales
Naturaleza direccional de NAT-Src y NAT-Dst

La aplicación de NAT-Src es independiente de la de NAT-Dst. Usted determina su
aplicación al tráfico por el sentido indicado en una directiva. Por ejemplo, si el
dispositivo de seguridad aplica una directiva que requiere NAT-Dst al tráfico enviado
del host A al host virtual B, el dispositivo de seguridad traduce la dirección IP de
destino original de 2.2.2.2 a 3.3.3.3. (También traduce la dirección IP de origen de
3.3.3.3 a 2.2.2.2 en el tráfico de respuesta).
Figura 17: Flujo de paquetes para NAT-Dst
set policy from “zona A” to “zona B” “host A” “virtual host B” any nat dst ip 3.3.3.3 permit set
vrouter trust-vr route 2.2.2.2/32 interface ethernet1.
Host virtual B Host B

Host A 2.2.2.2 3.3.3.3
1.1.1.1 ethernet3 ethernet1
1.1.1.10/24 3.3.3.10/24
Zona A Zona B
ORG DEST Carga
1.1.1.1 2.2.2.2 de datos
El dispositivo de seguridad traduce la dirección

IP de destino de 2.2.2.2 a 3.3.3.3. Almacena la
información de IP y dirección del puerto en su
tabla de la sesión.
ORG DEST Carga

1.1.1.1 3.3.3.3 de datos
ORG DEST Carga

3.3.3.3 1.1.1.1 de datos
El dispositivo de seguridad compara la

información de IP y puerto contenida en el
paquete con la información almacenada en su
tabla de la sesión. Luego traduce la dirección IP
de origen de 3.3.3.3 a 2.2.2.2.
ORG DEST Carga

2.2.2.2 1.1.1.1 de datos
12 Naturaleza direccional de NAT-Src y NAT-Dst

NOTA: Para que el dispositivo de seguridad pueda realizar una consulta de rutas para
determinar las zonas de destino, es necesario establecer una ruta a 2.2.2.2/32
(host virtual B). Para obtener más información sobre cuestiones de enrutamiento
de NAT-Dst, consulte “Enrutamiento para NAT-Dst” en la página 34.
Sin embargo, si crea la directiva antedicha especificando solamente NAT-Dst desde

el host A al host B, el dispositivo de seguridad no traducirá la dirección IP de origen
original del host B si éste inicia tráfico hacia el host A, en lugar de responder al
tráfico procedente del host A. Para que el dispositivo de seguridad traduzca la
dirección IP de origen del host B cuando éste inicia tráfico al host A, debe
configurar una segunda directiva en la que se especifique NAT-Src desde el host B al
host A. (Este comportamiento es distinto al de los MIP. Consulte “Direcciones IP
asignadas” en la página 65.)
NOTA: Para no distraer la atención de los mecanismos de traducción de direcciones IP, no

se muestra la traducción de direcciones de puertos (PAT). Si especifica números de
puerto fijos para un conjunto de DIP consistente en una sola dirección IP,
solamente un host podrá utilizar ese conjunto en un momento dado. La directiva
anterior especifica solamente el “host B” como dirección de origen. Si el “host B”
es el único host que utiliza el conjunto DIP 7, es innecesario habilitar PAT.
Figura 18: Flujo de paquetes para la traducción de direcciones IP de origen
set interface ethernet1 dip-id 7 1.1.1.3 1.1.1.3

set policy from “zona B” to “zona A” “host B”
“host A” any nat src dip-id 7 permit
Host A Conjunto de DIP 7

1.1.1.1 1.1.1.3 -1.1.1.3 ethernet3 ethernet1 Host B
1.1.1.10/24 3.3.3.10/24 3.3.3.3
Zona A Zona B
ORG DEST Carga

3.3.3.3 1.1.1.1 de datos

IP de destino de 3.3.3.3 a 1.1.1.3. Almacena la
información de IP y dirección del puerto en su
tabla de la sesión.
ORG DEST Carga

1.1.1.3 1.1.1.1 de datos
ORG DEST Carga

1.1.1.1 1.1.1.3 de datos

tabla de la sesión. A continuación traduce la
dirección IP de destino de 1.1.1.3 a 3.3.3.3.
ORG DEST Carga

1.1.1.1 3.3.3.3 de datos
Naturaleza direccional de NAT-Src y NAT-Dst 13

14 Naturaleza direccional de NAT-Src y NAT-Dst

Capítulo 2
Traducción de direcciones de red de
origen
ScreenOS proporciona muchos métodos para la realización de la Traducción de

dirección de red de origen (NAT-Src) y la traducción de dirección de puerto (PAT) de
origen. Este capítulo describe los diversos métodos de traducción de direcciones
disponibles y está organizado en las siguientes secciones:
“Introducción a NAT-Src” en esta página
“NAT-Src desde un rango DIP con PAT habilitada” en la página 17
“NAT-Src desde un rango DIP con PAT inhabilitada” en la página 20
“NAT-Src desde un conjunto de DIP con desplazamiento de direcciones” en la

página 22
“NAT-Src desde la dirección IP de la interfaz de salida” en la página 26
Introducción a NAT-Src
A veces es necesario que el dispositivo de seguridad traduzca la dirección IP de
origen original de un encabezado de paquete IP a otra dirección. Por ejemplo,
cuando algún host con una dirección IP privada envía tráfico a un espacio de
direcciones público, el dispositivo de seguridad debe traducir la dirección IP de
origen privada a una dirección pública. Asimismo, al enviar tráfico desde un
espacio de direcciones privado a través de una VPN a un sitio que utilice las mismas
direcciones, los dispositivos de seguridad situados en ambos extremos del túnel
deben traducir las direcciones IP de origen y de destino a direcciones que no se
interfieran mutuamente.
NOTA: Para obtener más información sobre direcciones IP públicas y privadas, consulte
“Direcciones IP públicas” en la página 2-55 y “Direcciones IP privadas” en la
página 2-56.
Un conjunto de direcciones IP dinámicas (DIP) proporciona al dispositivo de

seguridad una fuente de direcciones que utiliza para realizar la traducción de
direcciones de red de origen (NAT-Src). Cuando una directiva requiere NAT-Src y
hace referencia a un conjunto de DIP específico, el dispositivo de seguridad toma
direcciones de ese conjunto al realizar la traducción.
Introducción a NAT-Src 15
NOTA: El conjunto de DIP debe utilizar direcciones de la misma subred que la interfaz
predeterminada de la zona de destino a la que se hace referencia en la directiva. Si
desea utilizar un conjunto de DIP con direcciones que se encuentran fuera de la
subred de la interfaz de la zona de destino, debe definir un conjunto de DIP en
una interfaz extendida. Para obtener más información, consulte “Usar DIP en otra
subred” en la página 148.
El conjunto DIP puede ser tan pequeño como una sola dirección IP, la cual puede
atender a unos 64.500 hosts simultáneamente si se habilita la traducción de
direcciones de puertos (PAT). Aunque a todos los paquetes que reciben una nueva
dirección IP de origen de ese conjunto se les asigna la misma dirección, cada uno
obtiene un número de puerto diferente. Manteniendo una entrada en la tabla de la
sesión con la correspondencia entre las direcciones original y traducida y los
números de puerto original y traducido, el dispositivo de seguridad puede
determinar qué paquetes pertenecen a qué sesión, y qué sesiones pertenecen a qué
hosts.
NOTA: Con PAT habilitada, el dispositivo de seguridad también mantiene un conjunto de

números de puerto libres para asignar junto con direcciones del conjunto de DIP.
La cifra de unos 64.500 se calcula restando 1023 (los números reservados para los
puertos bien conocidos) del número máximo de puertos, que es 65.535.
Si utiliza NAT-Src pero no especifica un conjunto de DIP en la directiva, el dispositivo

de seguridad traduce la dirección de origen a la dirección de la interfaz de salida de
la zona de destino. En estos casos se requiere PAT, que se habilita automáticamente.
Para las aplicaciones que requieran trabajar con un número de puerto de origen
invariable, debe desactivar PAT y definir un rango DIP con un rango de direcciones
IP suficientemente grande para que cada host activo simultáneamente reciba una
dirección traducida diferente. Para trabajar con direcciones dinámicas (DIP) de
puerto fijo, el dispositivo de seguridad asigna una dirección de origen traducida al
mismo host para todas sus sesiones simultáneas. Por el contrario, cuando el rango
DIP tiene habilitada PAT, el dispositivo de seguridad puede asignar a un solo host
diferentes direcciones para otras tantas sesiones simultáneas, salvo que la DIP se
defina como “sticky” (consulte “Direcciones DIP “sticky”” en la página 147).
16 Introducción a NAT-Src
NAT-Src desde un rango DIP con PAT habilitada
Al aplicar la traducción de direcciones de red de origen (NAT-Src) con traducción de
direcciones de puertos (PAT), el dispositivo de seguridad traduce direcciones IP y
números de puertos y realiza una inspección del estado según se muestra en la
Figura 19 (sólo se muestran los elementos de los encabezados del paquete IP y del
segmento TCP relevantes para NAT-Src).
Figura 19: NAT-Src utilizando un rango DIP con PAT habilitada
set policy from trust to untrust any http net src dip-ip 5 permit
Dispositivo de seguridad ID de conjunto de DIP 5

Host local ethernet1 10.1.1.1/24 1.1.1.30 - 1.1.1.30
(PAT activo) Servidor Web remoto
10.1.1.5.25611 ethernet3 1.1.1.1/24 2.2.2.2:80
IP ORIG IP DEST PTO ORIG PTO DEST PROTO

10.1.1.5 2.2.2.2 25611 80 HTTP
El dispositivo de seguridad traduce la dirección IP de

origen de 10.1.1.5 a 1.1.1.30 y el puerto de origen de
25611 a 41834. Almacena la información de IP y de
dirección del puerto en su tabla de la sesión.

1.1.1.30 2.2.2.2 41834 80 HTTP

2.2.2.2 1.1.1.30 80 41834 HTTP
El dispositivo de seguridad compara la información de

IP y puerto contenida en el paquete con la información
almacenada en su tabla de la sesión. Entonces
traduce la dirección IP de destino de 1.1.1.30 a
10.1.1.5 y el puerto de destino de 41834 a 25611.

2.2.2.2 10.1.1.5 80 25611 HTTP
Ejemplo: NAT-Src con PAT habilitada

En este ejemplo definirá un conjunto de DIP 5 en ethernet3, una interfaz asociada a
la zona Untrust. El conjunto de DIP contiene una sola dirección IP (1.1.1.30) y tiene
PAT habilitada de forma predeterminada.
NOTA: Cuando defina un conjunto de DIP, el dispositivo de seguridad habilitará PAT de

forma predeterminada. Para desactivar PAT, deberá agregar la palabra clave
“fix-port” al final del comando CLI, o bien borrar la opción “Port Translation” en la
página de configuración de DIP en WebUI. Por ejemplo, set interface ethernet3
dip 5 1.1.1.30 1.1.1.30 fix-port, o bien Network > Interfaces > Edit (para
ethernet3) > DIP: ID: 5; Start: 1.1.1.30; End: 1.1.1.30; Port Translation: (anule la
selección).
NAT-Src desde un rango DIP con PAT habilitada 17

A continuación, establecerá una directiva que ordene al dispositivo de seguridad

realizar las siguientes tareas:
Permitir el tráfico HTTP desde cualquier dirección de la zona Trust a cualquier

dirección de la zona Untrust
Traducir la dirección IP de origen en el encabezado de paquetes IP a 1.1.1.30,

que es la entrada única en el rango DIP 5
Traducir el número original del puerto de origen en el encabezado del

segmento TCP o el encabezado del datagrama UDP a un número nuevo y único
Enviar el tráfico HTTP con la dirección IP de origen y el número de puerto

traducidos a través de ethernet3 a la zona Untrust
Figura 20: NAT-Src con PAT habilitada
Traducción de dirección de la red de origen (NAT-Src) ID de conjunto de DIP 5

(Traduce la dirección IP de origen a un conjunto de DIP de una 1.1.1.30 - 1.1.1.30
dirección - 1.1.1.30. PAT está habilitada).
1.1.1.30
10.1.1.1/24 1.1.1.1/24
10.1.1.5:25611 1.1.1.30:41834 2.2.2.2:80

10.1.1.5 2.2.2.2 25611 80 HTTP 1.1.1.30 2.2.2.2 41834 80 HTTP
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

18 NAT-Src desde un rango DIP con PAT habilitada

2. DIP
ID: 5
3. Directivas
haga clic en OK:
Source Address:
Service: HTTP
Action: Permit
NAT:
(DIP on): 5 (1.1.1.30 - 1.1.1.30)/X-late
CLI
1. Interfaces
2. DIP
set interface ethernet3 dip 5 1.1.1.30 1.1.1.30
3. Directivas
set policy from trust to untrust any any http nat src dip-id 5 permit
save
NAT-Src desde un rango DIP con PAT habilitada 19

NAT-Src desde un rango DIP con PAT inhabilitada

Pueden presentarse determinadas configuraciones o situaciones que necesiten la
realización de la traducción de direcciones de red de origen (NAT-Src) para la
dirección IP sin la realización de la traducción de direcciones de puertos (PAT) del
número de puerto de origen. Por ejemplo, una aplicación personalizada puede
necesitar un número específico para la dirección de puerto de origen. En tal caso,
puede definir una directiva que ordene al dispositivo de seguridad realizar NAT-Src
sin PAT.
Ejemplo: NAT-Src con PAT inhabilitada

En este ejemplo definirá un conjunto de DIP 6 en ethernet3, una interfaz asociada a
la zona Untrust. El rango DIP contiene un rango de direcciones IP de 1.1.1.50 a
1.1.1.150. Usted desactivará PAT. A continuación, establecerá una directiva que
ordene al dispositivo de seguridad realizar las siguientes tareas:
Permitir el tráfico para un servicio definido por el usuario llamado “e-stock”

desde cualquier dirección de la zona Trust a cualquier dirección de la zona
Untrust
NOTA: Se asume que previamente habrá configurado el servicio definido por el usuario
“e-stock”. Este servicio ficticio requiere que todas las transacciones de e-stock se
originen en números de puerto de origen específicos. Por esta razón, deberá
desactivar PAT para el conjunto de DIP 6.
Traducir la dirección IP de origen en el encabezado de paquetes IP a cualquier

dirección disponible en el rango DIP 6
Conservar el número del puerto de origen original en el encabezado del

segmento TCP o en el encabezado del datagrama UDP
Enviar tráfico e-stock con la dirección IP de origen traducida y el número de

puerto original a través de ethernet3 a la zona Untrust
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

20 NAT-Src desde un rango DIP con PAT inhabilitada

2. DIP
ID: 6
Port Translation: (anule la selección)
3. Directivas
haga clic en OK:
Source Address:
Service: e-stock
Action: Permit
NAT:
DIP on: (seleccione), 6 (1.1.1.50 - 1.1.1.150)
CLI
1. Interfaces
2. DIP
set interface ethernet3 dip 6 1.1.1.50 1.1.1.150 fix-port
3. Directivas
set policy from trust to untrust any any e-stock nat src dip-id 6 permit
save
NAT-Src desde un rango DIP con PAT inhabilitada 21

NAT-Src desde un conjunto de DIP con desplazamiento de direcciones

Puede definir una asignación “uno a uno” de una dirección IP de origen original a
una dirección IP de origen traducida para un rango de direcciones IP. Tal asignación
asegura que el dispositivo de seguridad traduzca siempre una determinada
dirección IP de origen dentro de ese rango a la misma dirección traducida dentro de
un rango DIP. Puede haber cualquier número de direcciones en el rango. Puede
incluso asignar una subred a otra subred, estableciendo una asignación “uno a uno”
permanente de cada dirección original de una subred a su contrapartida traducida
en la otra subred.
Un posible uso para realizar NAT-Src con desplazamiento de direcciones es

proporcionar mayor granularidad a las directivas en otro dispositivo de seguridad
que reciba tráfico del primero. Por ejemplo, el administrador de Dispositivo-A en el
sitio A define una directiva que traduce las direcciones de origen de sus hosts al
comunicarse con el Dispositivo-B en el sitio B a través de un túnel VPN punto a
punto. Si el Dispositivo-A aplica NAT-Src utilizando direcciones de un conjunto de
DIP sin desplazamiento de direcciones, el administrador del Dispositivo-B
solamente puede configurar directivas genéricas para el tráfico que puede permitir
desde el sitio A. Salvo que el administrador del Dispositivo-B conozca las
direcciones IP traducidas específicas, solamente podrá establecer directivas de
tráfico entrante para el rango de direcciones de origen tomadas del conjunto de DIP
del Dispositivo-A. Por otra parte, si el administrador del Dispositivo-B conoce cuáles
son las direcciones de origen traducidas (gracias al desplazamiento de direcciones),
ahora el Dispositivo-B puede ser más selectivo y restrictivo con las directivas que
establezca para el tráfico entrante desde el sitio A.
Recuerde que es posible utilizar un conjunto de DIP con desplazamiento de

direcciones habilitado en una directiva aplicable a las direcciones de origen más allá
del rango especificado en el conjunto. En tales casos, el dispositivo de seguridad
deja pasar el tráfico procedente de todas las direcciones de origen permitidas en la
directiva, aplicando NAT-Src con desplazamiento de direcciones a las direcciones
que se encuentren dentro del rango DIP, pero dejando intactas las direcciones que
queden fuera de ese rango. Si desea que el dispositivo de seguridad aplique NAT-Src
a todas las direcciones de origen, asegúrese de que el rango de direcciones de
origen tenga un tamaño inferior o igual que el rango DIP.
NOTA: El dispositivo de seguridad no admite la traducción de direcciones de puertos de

origen (PAT) con desplazamiento de direcciones.
22 NAT-Src desde un conjunto de DIP con desplazamiento de direcciones

Ejemplo: NAT-Src con desplazamiento de direcciones
En este ejemplo definirá el conjunto de DIP 10 en ethernet3, una interfaz asociada
a la zona Untrust. Desea traducir cinco direcciones entre 10.1.1.11 y 10.1.1.15 a
cinco direcciones entre 1.1.1.101 y 1.1.1.105, y desea que la relación entre cada
dirección original y traducida sea constante:
Tabla 1: NAT-Src con desplazamiento de direcciones
Dirección IP de origen original Dirección IP de origen traducida

10.1.1.11 1.1.1.101
10.1.1.12 1.1.1.102
10.1.1.13 1.1.1.103
10.1.1.14 1.1.1.104
10.1.1.15 1.1.1.105
Definirá las direcciones de cinco hosts en la zona Trust y las agregará a un grupo de
direcciones llamado “group1”. Las direcciones de estos hosts son 10.1.1.11,
10.1.1.12, 10.1.1.13, 10.1.1.14 y 10.1.1.15. Configurará una directiva para el
tráfico de la zona Trust a la zona Untrust que haga referencia a ese grupo de
direcciones en una directiva a la que aplicará NAT-Src con el conjunto de DIP 10. La
directiva ordenará al dispositivo de seguridad aplicar NAT-Src siempre que un
miembro de “group1” inicie tráfico HTTP hacia una dirección en la zona Untrust.
Además, el dispositivo de seguridad aplicará siempre NAT-Src desde una dirección
IP determinada, como 10.1.1.13 a la misma dirección IP traducida, 1.1.1.103.
A continuación, establecerá una directiva que ordene al dispositivo de seguridad

Permitir el tráfico HTTP desde “group1” en la zona Trust a cualquier dirección

en la zona Untrust
Traducir la dirección IP de origen en el encabezado de paquetes IP a su

correspondiente dirección en el conjunto de DIP 10
Enviar el tráfico HTTP con la dirección IP de origen y el número de puerto

traducidos a través de ethernet3 a la zona Untrust
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
NAT-Src desde un conjunto de DIP con desplazamiento de direcciones 23

haga clic en OK:
Zone Name: Untrust

2. DIP
ID: 10
IP Shift: (seleccione)
From: 10.1.1.11
To: 1.1.1.101 ~ 1.1.1.105
3. Direcciones
en OK:
Address Name: host1

Zone: Trust
en OK:
Address Name: host2

Zone: Trust
en OK:
Address Name: host3

Zone: Trust
en OK:
Address Name: host4

Zone: Trust
en OK:
Address Name: host5

Zone: Trust
24 NAT-Src desde un conjunto de DIP con desplazamiento de direcciones

Objects > Addresses > Groups > (para Zone: Trust) New: Introduzca el
Group Name: group1
Seleccione host1 y utilice el botón << para trasladar la dirección de la





4. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), group1
Service: HTTP
Action: Permit
NAT:
(DIP on): 10 (1.1.1.101 - 1.1.1.105)
CLI
1. Interfaces
2. DIP
set interface ethernet3 dip 10 shift-from 10.1.1.11 to 1.1.1.101 1.1.1.105
NAT-Src desde un conjunto de DIP con desplazamiento de direcciones 25

3. Direcciones
set address trust host1 10.1.1.11/32
set group address trust group1 add host1
4. Directivas
set policy from trust to untrust group1 any http nat src dip-id 10 permit
save
NAT-Src desde la dirección IP de la interfaz de salida

Si aplica NAT-Src a una directiva pero no especifica un conjunto de DIP, el
dispositivo de seguridad traduce la dirección IP de origen a la dirección de la
interfaz de salida. En tales casos, el dispositivo de seguridad siempre aplica PAT.
Ejemplo: NAT-Src sin DIP

En este ejemplo definirá una directiva que ordene al dispositivo de seguridad
Permitir el tráfico HTTP desde cualquier dirección de la zona Trust a cualquier

dirección de la zona Untrust
Traducir la dirección IP de origen en el encabezado de los paquetes IP a 1.1.1.1,

que es la dirección IP de ethernet3 (la interfaz asociada a la zona Untrust) y, por
tanto, de la interfaz de salida del tráfico enviado a cualquier dirección en la
zona Untrust
Traducir el número original del puerto de origen en el encabezado del

segmento TCP o el encabezado del datagrama UDP a un número nuevo y único
Enviar tráfico con la dirección IP de origen y el número de puerto traducidos a

través de ethernet3 a la zona Untrust
26 NAT-Src desde la dirección IP de la interfaz de salida

Figura 21: NAT-Src sin DIP
Traducción de dirección de red de origen (NAT-Src) (Traduce la dirección IP de origen a la

dirección IP de interfaz de salida - 1.1.1.1 – en la zona de destino. PAT está habilitada).

10.1.1.1/24 1.1.1.1/24
10.1.1.5:25611 1.1.1.30:41834 2.2.2.2:80
1.1.1.1 (Dispositivo virtual)

10.1.1.5 2.2.2.2 25611 80 HTTP 1.1.1.1 2.2.2.2 41834 80 HTTP
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Directivas
haga clic en OK:
Source Address:
Service: HTTP
Action: Permit
NAT:
(DIP on): None (Use Egress Interface IP)
NAT-Src desde la dirección IP de la interfaz de salida 27

CLI
1. Interfaces
2. Directivas
set policy from trust to untrust any any http nat src permit
save
28 NAT-Src desde la dirección IP de la interfaz de salida

Capítulo 3
Traducción de direcciones de red de
destino
ScreenOS proporciona muchos métodos para la realización de la Traducción de

dirección de red de destino (NAT-Dst) y la asignación de dirección del puerto de
destino. Este capítulo describe los diversos métodos de traducción de direcciones
disponibles y contiene las siguientes secciones:
“Introducción a NAT-Dst” en la página 30
“Flujo de paquetes para NAT-Dst” en la página 31
“Enrutamiento para NAT-Dst” en la página 34
“NAT-Dst— Asignación de “1:1”” en la página 37
“Traducción de una dirección a múltiples direcciones” en la página 40
“NAT-Dst—Asignación de “n:1”” en la página 43
“NAT-Dst— Asignación de “n:n”” en la página 46
“NAT-Dst con asignación de puertos” en la página 49
“NAT-Src y NAT-Dst en la misma directiva” en la página 52
NOTA: Para obtener información sobre la traducción de la dirección de destino utilizando

una dirección IP asignada (MIP) dirección IP virtual IP (VIP), consulte “Direcciones
virtuales y asignadas” en la página 65.
29
Introducción a NAT-Dst
Puede definir directivas para traducir la dirección de destino de una dirección IP a
otra. Puede necesitar que el dispositivo de seguridad traduzca una o varias
direcciones IP públicas a una o varias direcciones privadas. La relación de la
dirección de destino original con la dirección de destino traducida puede ser de
“1:1” (“una a una”), de “n:1” (“muchas a una”) o de “n:n” (“muchas a muchas”). La
Figura 22 describe los conceptos de las relaciones NAT-Dst de “1:1” (“una a una”) y
“n:1” (“muchas a una”).
Figura 22: NAT-Dst. “1:1” y “n:1”
El dispositivo de seguridad asigna tráfico desde aquí .......... hasta aquí
NAT-Dst: Asignación “1:1”
(Dispositivos virtuales)
NAT-Dst: Asignación “n:1”
Destino Destino
original traducido
Nota: Las direcciones IP de destino original y traducida deben estar en la misma zona de seguridad.
Ambas configuraciones que se muestran en la Figura 22 admiten la asignación de

puertos de destino. La asignación de puertos es la traducción determinista de un
número de puerto de destino original a otro número específico. En la asignación de
puertos, la relación del número original al traducido difiere con respecto a la
traducción de direcciones de puertos (PAT). En la asignación de puertos, el
dispositivo de seguridad traduce un número de puerto original predeterminado a
otro número de puerto predeterminado. Con PAT, el dispositivo de seguridad
traduce un número de puerto de origen original asignado aleatoriamente a otro
número asignado aleatoriamente.
Puede traducir un rango de direcciones de destino a otro rango (como una subred a
otra) mediante el desplazamiento de direcciones, de modo que el dispositivo de
seguridad asigne de forma fija cada dirección de destino original a una determinada
dirección de destino traducida. Observe que el dispositivo de seguridad no admite
la asignación de puertos con desplazamiento de direcciones. La Figura 23 describe
el concepto de relación de “n:n” para NAT-Dst.
30 Introducción a NAT-Dst
Figura 23: NAT-Dst: “n:n”
NAT-Dst: Asignación “n:n”
Destinos Destinos
originales traducidos
La tabla de rutas debe contener entradas tanto de la dirección IP de destino original
como de la dirección IP de destino traducida. El dispositivo de seguridad realiza una
consulta de rutas utilizando la dirección IP de destino original para determinar la
zona de destino y realizar la subsiguiente consulta de directivas. A continuación,
realiza una segunda consulta de rutas con la dirección traducida para determinar a
dónde enviar el paquete. Para garantizar que la decisión de enrutamiento cumpla
con la directiva, tanto la dirección IP de destino original como la dirección IP
traducida deben estar en la misma zona de seguridad. (Para obtener más
información sobre la relación entre la dirección IP de destino, la consulta de rutas y
la consulta de directivas, consulte “Flujo de paquetes para NAT-Dst” en esta página).
Flujo de paquetes para NAT-Dst

Los pasos siguientes describen la ruta de un paquete a través de un dispositivo de
seguridad y las diferentes operaciones que realiza al aplicar NAT-Dst:
1. Un paquete HTTP con dirección IP de origen:número de puerto 1.1.1.5:32455 y

dirección IP de destino:número de puerto 5.5.5.5:80 llega a ethernet1, que está
asociada a la zona Untrust.
Figura 24: Flujo de paquetes de NAT-Dst: Llegada del paquete
ORG DEST ORG DEST Zona DMZ

Carga ethernet2
1.1.1.5 5.5.5.5 32455 80 de datos
2.2.2.2/24
Zona Untrust
Zona Trust
ethernet1 ethernet3
1.1.1.1/24 3.3.3.3/24
1.1.1.5
Origen ethernet4 Zona Custom 1
4.4.4.4/24
Destino original Destino traducido

Los tres signos de interrogación indican que el dispositivo de seguridad todavía no ha realizado 5.5.5.5 4.4.4.5
los pasos necesarios para determinar qué interfaz debe utilizar para remitir el paquete.
Introducción a NAT-Dst 31
2. 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 la interfaz de entrada y procede al paso siguiente.

Si no ha habilitado ninguna opción de SCREEN para la zona Untrust, el

dispositivo de seguridad procede inmediatamente al paso siguiente.

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

ejecuta los pasos restantes con el procedimiento “First Packet Processing”.

ejecuta “Fast Processing”, utilizando la información disponible en la entrada de
sesiones existente para procesar el paquete. “Fast Processing” omite todos los
pasos salvo el último, porque la información generada por los pasos omitidos
ya se obtuvo durante el procesamiento del primer paquete de la sesión.
4. 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 5.5.5.5.
NOTA: El dispositivo de seguridad revisa únicamente si la dirección IP de destino se

utilizó en una configuración VIP sólo si el paquete llega en una interfaz unida a la
zona Untrust.
Si existe tal configuración, el dispositivo de seguridad resuelve la MIP o VIP

hacia la dirección IP de destino traducida y basa en ella su consulta de rutas.
Entonces realiza una consulta de directivas entre las zonas Untrust y Global. Si
encuentra una directiva que permita el tráfico, el dispositivo de seguridad
remite el paquete fuera de la interfaz de salida determinada en la consulta de
rutas.
Si 5.5.5.5 no se utiliza en ninguna configuración MIP o VIP, el dispositivo de

seguridad procede al paso siguiente.
rutas de la dirección IP de destino original; es decir, utiliza la dirección IP de
destino que aparece en el encabezado del paquete que llega a ethernet1. (El
módulo de rutas utiliza la interfaz de entrada para determinar qué enrutador
virtual debe utilizar para la consulta de rutas). Descubre que se accede a
5.5.5.5/32 a través de ethernet4, que está asociada a la zona Custom1.
Tabla de rutas trust-vr

Utilizar puerta
Para llegar a: Utilizar interfaz: En zona: de enlace:
0.0.0.0/0 ethernet1 Untrust 1.1.1.250
1.1.1.0/24 ethernet1 Untrust 0.0.0.0
2.2.2.0/24 ethernet2 DMZ 0.0.0.0
3.3.3.0/24 ethernet3 Trust 0.0.0.0
4.4.4.0/24 ethernet4 Custom1 0.0.0.0
5.5.5.5/32 ethernet4 Custom1 0.0.0.0
6. El motor de directivas realiza una consulta de directivas entre las zonas Untrust
y Custom1 (según lo determinado por las correspondientes interfaces de
entrada y de salida). Las direcciones IP de origen y de destino y el servicio
encuentran una directiva que desvía el tráfico HTTP de 5.5.5.5 a 4.4.4.5.
set policy from untrust to custom1 any v-server1 http nat dst ip 4.4.4.5 permit
(Previamente habrá definido la dirección “v-server1” con la dirección IP

5.5.5.5/32. Está en la zona Custom1).
El dispositivo de seguridad traduce la dirección IP de destino de 5.5.5.5 a

4.4.4.5. La directiva indica que no es necesario NAT-Src ni PAT-dst.
7. El dispositivo de seguridad efectúa una segunda consulta de rutas utilizando la

dirección IP traducida y descubre que se accede a 4.4.4.5/32 a través de
ethernet4.
8. El módulo de asignación de direcciones traduce la dirección IP de destino en el

encabezado del paquete a 4.4.4.5. El dispositivo de seguridad remite entonces
el paquete fuera de ethernet4 y crea una nueva entrada en su tabla de la sesión
(salvo que este paquete sea parte de una sesión existente y ya exista una
entrada).
Figura 25: Flujo de paquetes de NAT-Dst: Reenvío del paquete
Zona Untrust ORIG DEST ORIG DEST Carga de datos

1.1.1.5 5.5.5.5 32455 80
ethernet1
1.1.1.1/24
Origen
1.1.1.5
Zona Custom1
ethernet4
4.4.4.4/24
Destino
Identificación de la directiva 4.4.4.5
Sistema virtual al que
pertenece esta sesión aplicable a esta sesión
Identificación Flags de estado de la sesión Tiempo de espera de la sesión 30
de sesión (sólo para uso interno) unidades (30 x 10 = 300 segundos)
id 4 82/s**, vsy s 0, flag 04 000 000 /0 0/00 , polic y 21 , tim e 30

6 (2 1):1 .1.1.5/32 455 - > 4.4 .4 . 5/80, 6, 0 0b0d0a8 aa2 b, vla n 0 , tun 0, vsd 0
Identificación Puerto/dirección Dirección MAC de origen ID de túnel

de la interfaz Puerto/Dirección IP
IP de origen destino en la primera trama
Flag de NSP (sólo para uso interno) Protocolo de transporte 6 = TCP ID VLAN ID VSD
Nota: Dado que en esta sesión no participa ningún sistema virtual, VLAN, túnel VPN ni dispositivo de seguridad virtual (VSD), el ajuste para todos
estos números de identificación es cero.
Enrutamiento para NAT-Dst

Al configurar las direcciones para NAT-Dst, el dispositivo de seguridad debe
disponer en su tabla de enrutamiento de rutas tanto a la dirección de destino
original que aparece en el encabezado del paquete como a la dirección de destino
traducida (es decir, la dirección a la cual el dispositivo de seguridad reenvía el
paquete). Según lo explicado en “Flujo de paquetes para NAT-Dst” en la página 31,
el dispositivo de seguridad utiliza la dirección de destino original para realizar una
consulta de rutas, determinando de este modo la interfaz de salida. Al mismo
tiempo, la interfaz de salida proporciona la zona de destino (la zona a la que está
asociada la interfaz) para que el dispositivo de seguridad pueda realizar una
consulta de directivas. Cuando el dispositivo de seguridad encuentra una directiva
aplicable, ésta define la asignación de la dirección de destino original a la dirección
de destino traducida. El dispositivo de seguridad realiza entonces una segunda
consulta de rutas para determinar la interfaz a través de la cual debe reenviar el
paquete para alcanzar la nueva dirección de destino. En resumen, la ruta a la
dirección de destino original proporciona un medio de realizar la consulta de
directivas, mientras que la ruta a la dirección de destino traducida especifica la
interfaz de salida a través de la cual el dispositivo de seguridad debe reenviar el
paquete.
En los tres escenarios siguientes, la necesidad de introducir rutas estáticas cambia
según la topología de red que rodea a las direcciones de destino a las que se refiere
esta directiva:
set policy from untrust to trust any oda1 http nat dst ip 10.1.1.5 permit
donde “oda1” es la dirección de destino original 10.2.1.5, y 10.1.1.5 es la dirección

de destino traducida.

En este escenario, las rutas a las direcciones de destino originales y traducidas
dirigen el tráfico a través de la misma interfaz, ethernet3. El dispositivo de
seguridad agrega automáticamente una ruta a 10.1.1.0/24 a través de ethernet3 al
configurar la dirección IP de la interfaz ethernet3 como 10.1.1.1/24. Para completar
los requisitos de enrutamiento, deberá agregar una ruta adicional a 10.2.1.5/32 a
través de ethernet3.
Figura 26: Direcciones originales y traducidas utilizando la misma interfaz de salida
ethernet3 Destino original

“oda1” 10.2.1.5 * Destino Zona Trust
10.1.1.1/24 traducido
10.1.1.5
10.1.1.0/24
* Aunque 10.2.1.5 no se encuentra en la subred 10.1.1.0/24 porque su ruta no especifica una puerta de enlace, está ilustrada como
si estuviese en la misma subred conectada que el espacio de direcciones 10.1.1.0/24.
WebUI

CLI
save

pero separadas por un enrutador
En este escenario, las rutas a las direcciones de destino original y traducida dirigen
el tráfico a través de ethernet3. El dispositivo de seguridad agrega automáticamente
una ruta a 10.1.1.0/24 a través de ethernet3 al configurar la dirección IP de la
interfaz ethernet3 como 10.1.1.1/24. Para completar los requisitos de
enrutamiento, deberá agregar una ruta a 10.2.1.0/24 a través de ethernet3 y a la
puerta de enlace que conecta las subredes 10.1.1.0/24 y 10.2.1.0/24.
NOTA: Dado que esta ruta es necesaria para alcanzar cualquier dirección en la subred
10.2.1.0/24, probablemente ya la haya configurado. En tal caso, no es necesario
agregar ninguna ruta adicional sólo para que la directiva aplique NAT-Dst a
10.2.1.5.
Figura 27: Direcciones originales y traducidas separadas por un enrutador
Destino
ethernet3 traducido Zona Trust
10.1.1.1/24 Destino original
10.1.1.5 “oda1” 10.2.1.5
10.1.1.250/24
10.1.1.0/24
10.1.1.250/24 10.2.1.0/24
WebUI

CLI
save
Ejemplo: Direcciones separadas por una interfaz

En este escenario hay dos interfaces asociadas a la zona Trust: ethernet3 con la
dirección IP 10.1.1.1/24 y ethernet4 con la dirección IP 10.2.1.1/24. El dispositivo
de seguridad agrega automáticamente una ruta a 10.1.1.0/24 a través de ethernet3
y a 10.2.1.0/24 a través de ethernet4 cuando se configuran las direcciones IP de
estas interfaces. Al colocar la dirección original de destino en la subred 10.2.1.0/24
y la dirección de destino traducida en la subred 10.1.1.0/24, no es necesario
agregar ninguna otra ruta para que el dispositivo de seguridad aplique NAT-Dst de
10.1.1.5 a 10.2.1.5.
Figura 28: Direcciones originales y traducidas utilizando diferentes interfaces de salida
Destino
traducido
ethernet3 10.1.1.5
10.1.1.1/24
10.1.1.0/24
Zona Trust
10.2.1.0/24
ethernet4 (Dispositivo virtual)

10.2.1.1/24
Destino original
“oda1” 10.2.1.5
NAT-Dst— Asignación de “1:1”

Al aplicar la traducción de direcciones de red de destino (NAT-Dst) sin PAT, el
dispositivo de seguridad traduce la dirección IP de destino y realiza una inspección
de estado según se muestra en Figura 29 (observe que solamente se muestran los
elementos de los encabezados del paquete IP y del segmento TCP relevantes para
NAT-Dst).
Figura 29: NAT-Dst “1:1”
Origen Dispositivo de seguridad Destino original Destino traducido

2.2.2.5:36104 ethernet3 1.1.1.1/24, Untrust 1.2.1.5:80 10.1.1.5:80
ethernet2 10.1.1.1/24, DMZ
2.2.2.5 1.2.1.5 35104 80 HTTP
IP de origen de 10.1.1.5 a 1.1.1.30 y el puerto
de origen de 25611 a 41834. Almacena la
información de IP y de dirección del puerto en
su tabla de la sesión.
2.2.2.5 10.1.1.5 36104 80 HTTP

10.1.1.5 2.2.2.5 80 36104 HTTP
tabla de la sesión. Entonces traduce la dirección
IP de destino de 1.1.1.30 a 10.1.1.5 y el puerto
de destino de 41834 a 25611.
1.2.1.5 2.2.2.5 80 36104 HTTP
NAT-Dst— Asignación de “1:1” 37

Ejemplo: Traducción de destinos “1:1”

En este ejemplo establecerá una directiva para realizar la traducción “1:1” de
direcciones de red de destino (NAT-Dst) sin cambiar las direcciones de los puertos
de destino. La directiva ordena al dispositivo de seguridad realizar las siguientes
tareas:
Permitir el tráfico FTP y HTTP (definido como grupo de servicios “http-ftp”) de

cualquier dirección en la zona Untrust a la dirección original de destino
denominada “oda2” con la dirección 1.2.1.8 en la zona DMZ
Traducir la dirección IP de destino en el encabezado de paquetes IP de 1.2.1.8 a

10.2.1.8
Dejar intacto el número de puerto de destino original en el encabezado del

segmento TCP (80 para HTTP y 21 para FTP)
Reenviar el tráfico HTTP y FTP a 10.2.1.8 en la zona DMZ
Asociará ethernet3 a la zona Untrust y le asignará la dirección IP 1.1.1.1/24.

Asociará ethernet2 a DMZ y le asignará la dirección IP 10.2.1.1/24. También
definirá una ruta a la dirección de destino original 1.2.1.8 a través de ethernet2. Las
dos zonas Untrust y DMZ se encuentran en el dominio de enrutamiento trust-vr.
Figura 30: NAT-Dst: “1:1”
Destino original
“oda2” 1.2.1.8
ethernet3 ethernet2
1.1.1.1/24 10.2.1.1/24 (Dispositivo virtual)
Zona Untrust
Origen Destino
2.2.2.54 traducido
Zona DMZ 10.2.1.8
2.2.2.5 1.2.1.8 25611 80 HTTP 2.2.2.5 10.2.1.8 25611 80 HTTP
2.2.2.5 1.2.1.8 40365 21 FTP 2.2.2.5 10.2.1.8 40365 21 FTP
WebUI
1. Interfaces
haga clic en OK:
Zone Name: Untrust

haga clic en OK:
Zone Name: DMZ

38 NAT-Dst— Asignación de “1:1”

2. Dirección
en OK:
Address Name: oda2

Zone: DMZ
Group Name: HTTP-FTP

Seleccione FTP y utilice el botón << para mover el servicio de la columna

4. Ruta

5. Directivas
haga clic en OK:
Source Address:
Service: HTTP-FTP
Action: Permit
NAT:

CLI
1. Interfaces
2. Dirección
set address dmz oda2 1.2.1.8/32
set group service http-ftp
set group service http-ftp add http
set group service http-ftp add ftp
4. Ruta
5. Directivas
set policy from untrust to dmz any oda2 http-ftp nat dst ip 10.2.1.8 permit
save
Traducción de una dirección a múltiples direcciones

El dispositivo de seguridad puede traducir la misma dirección de destino original a
diversas direcciones de destino traducidas especificadas en diferentes directivas,
dependiendo del tipo de servicio o de la dirección de origen especificada en cada
directiva. Quizás le interese que el dispositivo de seguridad desvíe el tráfico HTTP
de 1.2.1.8 a 10.2.1.8 y el tráfico FTP de 1.2.1.8 a 10.2.1.9 (consulte el ejemplo
siguiente). O también que el dispositivo de seguridad desvíe el tráfico HTTP
enviado desde host1 a 1.2.1.8 hacia 10.2.1.8, pero que el tráfico HTTP sea enviado
desde host2 a 1.2.1.8 y hacia 10.2.1.37. En ambos casos, el dispositivo de
seguridad desviará el tráfico enviado a la misma dirección de destino original a
diferentes direcciones traducidas.
Ejemplo: Traducción de destinos “1:n”

En este ejemplo creará dos directivas que utilicen la misma dirección de destino
original (1.2.1.8), pero que dirijan el tráfico enviado a esa dirección a dos
direcciones de destino traducidas diferentes basándose en el tipo de servicio. Estas
directivas ordenarán al dispositivo de seguridad realizar las siguientes tareas:
Permitir el tráfico FTP y HTTP procedente de cualquier dirección de la zona

Untrust a una dirección definida por el usuario llamada “oda3” en la zona DMZ
Para el tráfico HTTP, traducir la dirección IP de destino del encabezado del

paquete IP de 1.2.1.8 a 10.2.1.8
Para el tráfico FTP, traducir la dirección IP de destino de 1.2.1.8 a 10.2.1.9

segmento TCP (80 para HTTP y 21 para FTP)
Transmitir el tráfico HTTP a 10.2.1.8 y el tráfico FTP a 10.2.1.9 en la zona DMZ

Figura 31: NAT-Dst: “1:n”
Destino original “oda3”

1.2.1.8:80
1.2.1.8:21
ethernet3 ethernet2
1.1.1.1/24 10.2.1.1/24
Zona Untrust Zona DMZ
2.2.2.5:25611
2.2.2.5:40365 (Dispositivo virtual)
Origen Destino Destino
traducido traducido
10.2.1.9:21 10.2.1.8:80
2.2.2.5 1.2.1.8 25611 80 HTTP 2.2.2.5 10.2.1.8 25611 80 HTTP
2.2.2.5 1.2.1.8 40365 21 FTP 2.2.2.5 10.2.1.9 40365 21 FTP

definirá una ruta a la dirección de destino original 1.2.1.8 a través de ethernet2. Las
zonas Untrust y DMZ se encuentran en el dominio de enrutamiento trust-vr.
WebUI
1. Interfaces
haga clic en OK:
Zone Name: Untrust

haga clic en OK:
Zone Name: DMZ

2. Dirección
en OK:
Address Name: oda3

Zone: DMZ
3. Ruta


4. Directivas
haga clic en OK:
Source Address:
Service: HTTP
Action: Permit
NAT:
haga clic en OK:
Source Address:
Service: FTP
Action: Permit
NAT:
CLI
1. Interfaces
2. Dirección
3. Ruta
4. Directivas
set policy from untrust to dmz any oda3 http nat dst ip 10.2.1.8 permit
set policy from untrust to dmz any oda3 ftp nat dst ip 10.2.1.9 permit
save

NAT-Dst—Asignación de “n:1”
La relación de la dirección de destino original con la dirección de destino traducida
también puede ser “n:1”. En este caso, el dispositivo de seguridad reenvía el tráfico
enviado a varias direcciones de destino originales a una sola dirección de destino
traducida. Opcionalmente, también puede especificar la asignación de puertos de
destino.
Ejemplo: Traducción de destinos “n:1”

En este ejemplo creará una directiva que desviará el tráfico enviado a diferentes
direcciones de destino originales (1.2.1.10 y 1.2.1.20) a la misma dirección de
destino traducida. Esta directiva ordena al dispositivo de seguridad realizar las
siguientes tareas:
Permitir el tráfico HTTP procedente de cualquier dirección de la zona Untrust a

un grupo de direcciones definido por el usuario denominado “oda45” con las
direcciones “oda4” (1.2.1.10) y “oda5” (1.2.1.20) en la zona DMZ
Traducir las direcciones IP de destino del encabezado de paquetes IP de

1.2.1.10 y 1.2.1.20 a 10.2.1.15

segmento TCP (80 para HTTP)
Reenviar el tráfico HTTP a 10.2.1.15 en la zona DMZ
Figura 32: NAT-Dst: “n:1”

ethernet3 ethernet2 1.2.1.10:80
1.1.1.1/24 10.2.2.1/24
Zona Untrust Destino
Zona DMZ traducido
10.2.1.15:80
10.2.1.15.80
Origen 1.2.1.20:80
1.1.1.5:25611 (Dispositivo virtual)
1.1.1.6:40365
1.1.1.5 1.2.1.10 25611 80 HTTP 1.1.1.5 10.2.1.1 25611 80 HTTP
1.1.1.6 1.2.1.20 40365 80 HTTP 1.1.1.6 10.2.1.1 40365 80 HTTP

definirá una ruta a las direcciones de destino originales 1.2.1.10 y 1.2.1.20 a través
de ethernet2. Las zonas Untrust y DMZ se encuentran en el dominio de
NAT-Dst—Asignación de “n:1” 43
WebUI
1. Interfaces
haga clic en OK:
Zone Name: Untrust

haga clic en OK:
Zone Name: DMZ

2. Direcciones
en OK:
Address Name: oda4

Zone: DMZ
en OK:
Address Name: oda5

Zone: DMZ
Objects > Addresses > Groups > (para Zone: DMZ) New: Introduzca el
Group Name: oda45
Seleccione oda4 y utilice el botón << para trasladar la dirección de la

Seleccione oda5 y utilice el botón << para mover la dirección de la

44 NAT-Dst—Asignación de “n:1”
3. Rutas


4. Directivas
haga clic en OK:
Source Address:
Service: HTTP
Action: Permit
NAT:
CLI
1. Interfaces
2. Direcciones
set group address dmz oda45 add oda4
set group address dmz oda45 add oda5
3. Rutas
4. Directivas
set policy from untrust to dmz any oda45 http nat dst ip 10.2.1.15 permit
save
NAT-Dst—Asignación de “n:1” 45
NAT-Dst— Asignación de “n:n”

Puede utilizar la traducción de direcciones de red de destino (NAT-Dst) para traducir
un rango de direcciones IP a otro rango. El rango de direcciones puede ser una
subred o un subconjunto de direcciones dentro de una subred. ScreenOS utiliza un
mecanismo de desplazamiento de direcciones para mantener las relaciones entre el
rango de direcciones de destino original después de traducirlas al nuevo rango de
direcciones. Por ejemplo, si el rango de direcciones originales es 10.1.1.1 a
10.1.1.50 y la dirección inicial del rango de direcciones traducidas es 10.100.3.101,
el dispositivo de seguridad traduce las direcciones como sigue:
10.1.1.1 – 10.100.3.101
10.1.1.2 – 10.100.3.102
10.1.1.3 – 10.100.3.103
10.1.1.48 – 10.100.3.148
10.1.1.49 – 10.100.3.149
10.1.1.50 – 10.100.3.150
Si, por ejemplo, desea crear una directiva que aplique las traducciones antedichas al
tráfico HTTP desde cualquier dirección de zoneA a un grupo de direcciones
denominado “addr1-50”, que contiene todas las direcciones de 10.1.1.1 a
10.1.1.50, en zoneB, puede introducir el comando CLI siguiente:
set policy id 1 from zoneA to zoneB any addr1-50 http nat dst ip 10.100.3.101
10.100.3.150 permit
Si cualquier host en zoneA inicia tráfico HTTP hacia una dirección dentro del rango
definido en zoneB, como 10.1.1.37, el dispositivo de seguridad aplica esta directiva
y traduce la dirección de destino a 10.100.3.137.
El dispositivo de seguridad solamente aplica NAT-Dst si las zonas de origen y de

destino, las direcciones de origen y de destino, y el servicio especificados en la
directiva coinciden con estos componentes en el paquete. Por ejemplo, puede crear
otra directiva que permita el tráfico desde cualquier host en zoneA a cualquier host
en zoneB y colocarla después de la directiva 1 en la lista de directivas:
set policy id 1 from zoneA to zoneB any addr1-50 http nat dst ip 10.100.3.101
10.100.3.150 permit
set policy id 2 from zoneA to zoneB any any any permit
46 NAT-Dst— Asignación de “n:n”

Una vea configuradas estas dos directivas, los siguientes tipos de tráfico enviados
desde un host en zoneA a un host en zoneB evitan el mecanismo de NAT-Dst:
Un host de zoneA inicia tráfico no HTTP hacia 10.1.1.37 en la zona B. El

dispositivo de seguridad aplica la directiva 2 porque el servicio no es HTTP, y
entrega el tráfico sin traducir la dirección de destino.
Un host de zoneA inicia tráfico HTTP hacia 10.1.1.51 en la zona B. El

dispositivo de seguridad también aplica la directiva 2 porque la dirección de
destino no pertenece al grupo de direcciones addr1-50, y entrega el tráfico sin
traducir la dirección de destino.
Ejemplo: Traducción de destinos “n:n”

En este ejemplo configurará una directiva que aplique NAT-Dst cuando se envíe
cualquier tipo de tráfico a cualquier host en una subred, ordenando al dispositivo de
seguridad realizar las siguientes tareas:
Permitir todos los tipos del tráfico desde cualquier dirección de la zona Untrust
a cualquier dirección en la zona DMZ
Traducir la dirección de destino original denominada “oda6” de la subred

1.2.1.0/24 a una dirección correspondiente en la subred 10.2.1.0/24

segmento TCP
Reenviar el tráfico HTTP a la dirección traducida en DMZ
Figura 33: NAT-Dst: “n:n”
Zona DMZ
ethernet3 ethernet2
Zona Untrust 1.1.1.1/24 10.2.1.1/24 1.2.1.1 – 10.2.1.1
1.2.1.2 – 10.2.1.2
Internet 1.2.1.3 – 10.2.1.3
1.2.1.253 – 10.2.1.253
1.2.1.254 – 10.2.1.254
Destinos originales Destinos traducidos

“oda6” 1.2.1.0/24 10.2.1.0/24

definirá una ruta a la subred de dirección de destino original (1.2.1.0/24) a través de
ethernet2. Las zonas Untrust y DMZ se encuentran en el dominio de enrutamiento
trust-vr.
WebUI
1. Interfaces
haga clic en OK:
NAT-Dst— Asignación de “n:n” 47

Zone Name: Untrust

haga clic en OK:
Zone Name: DMZ

2. Dirección
en OK:
Address Name: oda6

Zone: DMZ
3. Ruta

4. Directivas
haga clic en OK:
Source Address:
Service: Any
Action: Permit
NAT:
Translate to IP Range: (seleccione), 10.2.1.0 – 10.2.1.254
CLI
1. Interfaces
2. Dirección
48 NAT-Dst— Asignación de “n:n”

3. Ruta
4. Directivas
set policy from untrust to dmz any oda6 any nat dst ip 10.2.1.1 10.2.1.254 permit
save
NAT-Dst con asignación de puertos

Cuando se configura el dispositivo de seguridad para realizar la traducción de
direcciones de red de destino (NAT-Dst), puede habilitar opcionalmente la
asignación de puertos. Una razón para habilitar la asignación de puertos es admitir
múltiples procesos de servidor para un solo servicio en un solo host. Por ejemplo,
un host puede ejecutar dos servidores web, uno en el puerto 80 y otro en el puerto
8081. Para el servicio 1 de HTTP, el dispositivo de seguridad realiza NAT-Dst sin
asignación de puertos (puerto de destino 80 -> 80).
Para el servicio 2 de HTTP, el dispositivo de seguridad aplica NAT-Dst a la misma

dirección IP de destino con asignación de puertos (puerto destino 80 -> 8081). El
host puede distinguir el tráfico HTTP dirigido a ambos servidores web por los dos
diferentes números de puerto de destino.
NOTA: ScreenOS no admite la asignación de puertos para NAT-Dst con desplazamiento de

direcciones. Consulte “NAT-Dst— Asignación de “n:n”” en la página 46.
Ejemplo: NAT-Dst con asignación de puertos

En este ejemplo creará dos directivas que apliquen NAT-Dst y asignación de puertos
al tráfico Telnet procedente de las zonas Trust y Untrust y dirigido a un servidor
Telnet en la zona DMZ. Estas directivas ordenarán al dispositivo de seguridad
Permitir Telnet desde cualquier dirección en las zonas Untrust y Trust hacia
1.2.1.15 en la zona DMZ
Traducir la dirección IP de destino original denominada “oda7” de 1.2.1.15 a

10.2.1.15
Traducir el número de puerto de destino original en el encabezado del

segmento TCP de 23 a 2200
Reenviar el tráfico Telnet a la dirección traducida en la zona DMZ
Configurará los siguientes enlaces de interfaz a zona y asignaciones de direcciones:
ethernet1: zona trust, 10.1.1.1/24
ethernet2: zona DMZ, 10.2.1.1/24
ethernet3: zona Untrust, 1.1.1.1/24
NAT-Dst con asignación de puertos 49

Definirá una entrada de dirección “oda7” con la dirección IP 1.2.1.15/32 en la zona

DMZ. También definirá una ruta a la dirección de destino original 1.2.1.15 a través
de ethernet2. Las tres zonas Trust, Untrust y DMZ se encuentran en el dominio de
WebUI
1. Interfaces
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. Dirección
en OK:
Address Name: oda7

Zone: DMZ
3. Ruta

4. Directivas
clic en OK:
50 NAT-Dst con asignación de puertos

Source Address:
Service: Telnet
Action: Permit
NAT:
Map to Port: (seleccione), 2200
haga clic en OK:
Source Address:
Service: Telnet
Action: Permit
NAT:
Map to Port: (seleccione), 2200
CLI
1. Interfaces
2. Dirección
3. Ruta
4. Directivas
set policy from trust to dmz any oda7 telnet nat dst ip 10.2.1.15 port 2200 permit
set policy from untrust to dmz any oda7 telnet nat dst ip 10.2.1.15 port 2200
permit
save
NAT-Dst con asignación de puertos 51

NAT-Src y NAT-Dst en la misma directiva

Puede combinar la traducción de direcciones de red de origen (NAT-Src) y la
traducción de direcciones de red de destino (NAT-Dst) en la misma directiva. Esta
combinación proporciona un medio para cambiar tanto la dirección IP de origen
como la de destino en un único punto de la ruta de datos.
Ejemplo: NAT-Src y NAT-Dst combinadas

En el ejemplo que se muestra en la Figura 34, configurará un dispositivo de
seguridad (Dispositivo-1) que se encontrará entre las granjas de servidores y los
clientes de un proveedor de servicios. Los clientes se conectan a Dispositivo-1 a
través de ethernet1, que tiene la dirección IP 10.1.1.1/24 y está asociada a la zona
Trust. Dispositivo-1 reenvía su tráfico a través de uno de dos túneles VPN basados
en rutas para alcanzar los servidores de destino. Las interfaces de túnel asociadas a
estos túneles se encuentran en la zona Untrust. Las dos zonas Trust y Untrust se
NOTA: Las VPNs basadas en directivas no admiten NAT-Dst. Deberá utilizar una
configuración de VPN basada en rutas con NAT-Dst.
Debido a que los clientes podrían tener las mismas direcciones que los servidores a
los que desean conectarse, Dispositivo-1 debe realizar la traducción de las
direcciones tanto de origen como de destino (NAT-Src y NAT-Dst). Para mantener la
independencia y flexibilidad de direccionamiento, los dispositivos de seguridad que
protegen las granjas de servidores Dispositivo-A y Dispositivo-B realizan NAT-Dst. El
proveedor de servicios ordena a los clientes y a los administradores de la granja de
servidores que reserven las direcciones 10.173.10.1–10.173.10.7, 10.173.20.0/24,
10.173.30.0/24, 10.173.40.0/24 y 10.173.50.0/24 para este fin. Estas direcciones se
utilizan de la siguiente forma:
Las dos interfaces de túnel tienen las siguientes asignaciones de direcciones:
tunnel.1, 10.173.10.1/30
tunnel.2, 10.173.10.5/30
Cada interfaz de túnel admite los siguientes conjuntos de DIP con PAT
habilitada:
tunnel.1, DIP ID 5: 10.173.10.2–10.173.10.2
tunnel.2, DIP ID 6: 10.173.10.6–10.173.10.6
Cuando Dispositivo-1 realiza NAT-Dst, traduce las direcciones de destino

originales mediante desplazamiento de direcciones como sigue:
10.173.20.0/24 a 10.173.30.0/24
10.173.40.0/24 a 10.173.50.0/24
52 NAT-Src y NAT-Dst en la misma directiva

NOTA: Para obtener más información sobre el desplazamiento de direcciones al realizar
NAT-Dst, consulte “NAT-Dst— Asignación de “n:n”” en la página 46.
Las configuraciones para los túneles vpn1 y vpn2, utilizan los siguientes
parámetros: AutoKey IKE, clave previamente compartida (“dispositivo1” para vpn1
y “dispositivo2” para vpn2), así como 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 5-9). La identificación del
proxy tanto para vpn1 como para vpn2 es 0.0.0.0/0 - 0.0.0.0/0 - any.
NOTA: La configuración para Dispositivo-1 se proporciona en primer lugar. Después se

incluyen las configuraciones de VPN para Dispositivo-A y Dispositivo-B.
Figura 34: NAT-Src y NAT-Dst combinadas
Dispositivo de seguridad-1 Dispositivo de seguridad-A

tunnel.1, 10.173.10.1/30 Untrust 2.2.2.2/24, Trust 10.100.1.1/24
Los clientes con direcciones IP de origen tunnel.1, 10.2.2.1/24
diferentes se conectan a los servidores de NAT-Src
• Rango DIP 10.173.10.2 – 10.173.10.2 NAT-Dst
un proveedor a través de túneles VPN. • Destino original 10.173.30.0/24
NAT-Dst • Destino traducido 10.100.1.0/24
• Destino original 10.173.20.0/24
• Destino traducido 10.173.30.0/24
Direcciones ethernet1 ethernet3

de los clientes 10.1.1.1/24 1.1.1.1/24
Zona Untrust
Zona Trust Dispositivo-A
10.100.1.0/24 vpn1
10.100.1.0/24
10.100.2.0/24 vpn2 Dispositivo-B
10.100.2.0/24
seguridad-1
Enrutador
El dispositivo de seguridad realiza NAT-Src y Interno
NAT-Dst porque usted, como administrador de Dispositivo de seguridad-1
Dispositivo-1, no tiene ningún control sobre las tunnel.2, 10.173.10.5/30
direcciones de origen y de destino. Mientras haya NAT-Src Dispositivo de seguridad-B
un espacio de direcciones mutuamente neutral • Rango DIP 10.173.10.6 – 10.173.10.6 Untrust 3.3.3.3/24, Trust 10.100.2.1/24
para traducir direcciones entrantes y salientes, el NAT-Dst tunnel.1, 10.3.3.1/24
Dispositivo de seguridad-1 podrá procesar las • Destino original 10.173.40.0/24 NAT-Dst
peticiones de servicio de los clientes. • Destino traducido 10.173.50.0/24 • Destino original 10.173.50.0/24
• Destino traducido 10.100.2.0/24
Los dos dispositivos de seguridad que protegen
las granjas de servidores también realizan
NAT-Dst para conservar la independencia y
flexibilidad de direccionamiento.
WebUI (Dispositivo de seguridad-1)

1. Interfaces
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
NAT-Src y NAT-Dst en la misma directiva 53

haga clic en OK:
Zone Name: Untrust

clic en OK:

IP Address / Netmask: 10.173.10.1/30
clic en OK:

2. Conjuntos de DIP
ID: 5
ID: 6
3. Direcciones
en OK:
Address Name: serverfarm-A

Zone: Untrust
en OK:
Address Name: serverfarm-B

Zone: Untrust

4. VPN
VPN Name: vpn1

Gateway Name: gw-A
Preshared Key: device1

Bind to Tunnel Interface: (seleccione), tunnel.1

Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY
VPN Name: vpn2

Gateway Name: gw-B


Service: ANY
5. Rutas



Interface: tunnel.1

Interface: tunnel.1

Interface: tunnel.2

Interface: tunnel.2
6. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), serverfarm-A
Service: ANY
Action: Permit

Return para regresar a la página de configuración básica de directivas:
NAT:
(DIP on): 5 (10.173.10.2–10.173.10.2)/X-late

haga clic en OK:
Source Address:
Address Book Entry: (seleccione), serverfarm-B
Service: ANY
Action: Permit

NAT:
(DIP on): 6 (10.173.10.6–10.173.10.6)/X-late
CLI (Dispositivo de seguridad-1)

1. Interfaces
2. Conjuntos de DIP
set interface tunnel.1 dip-id 5 10.173.10.2 10.173.10.2
set interface tunnel.2 dip-id 6 10.173.10.6 10.173.10.6
3. Direcciones
set address untrust serverfarm-A 10.173.20.0/24
set address untrust serverfarm-B 10.173.40.0/24
4. VPN
set ike gateway gw-A ip 2.2.2.2 main outgoing-interface ethernet3 preshare
device1 sec-level compatible
set vpn vpn1 gateway gw-A sec-level compatible
set ike gateway gw-B ip 3.3.3.3 main outgoing-interface ethernet3 preshare
set vpn vpn2 gateway gw-B sec-level compatible
5. Rutas

6. Directivas
set policy top from trust to untrust any serverfarm-A any nat src dip-id 5 dst ip
10.173.30.0 10.173.30.255 permit
set policy top from trust to untrust any serverfarm-B any nat src dip-id 6 dst ip
10.173.50.0 10.173.50.255 permit
save
WebUI (Dispositivo de seguridad-A)

1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

clic en OK:

2. Direcciones
en OK:
Address Name: serverfarm-A

Zone: Trust
en OK:
Address Name: customer1

Zone: Untrust

3. VPN
VPN Name: vpn1

Gateway Name: gw-1


Service: ANY
4. Rutas


Interface: tunnel.1

5. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), customer1
Address Book Entry: (seleccione), serverfarm-A
Service: ANY
Action: Permit


NAT:
CLI (Dispositivo de seguridad-A)

1. Interfaces
2. Direcciones
set address trust serverfarm-A 10.173.30.0/24
set address untrust customer1 10.173.10.2/32
3. VPN
set ike gateway gw-1 ip 1.1.1.1 main outgoing-interface ethernet3 preshare
set vpn vpn1 gateway gw-1 sec-level compatible
4. Rutas
5. Directivas
set policy top from untrust to trust customer1 serverfarm-A any nat dst ip
10.100.1.0 10.100.1.255 permit
save
WebUI (Dispositivo de seguridad-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
en OK:
Address Name: serverfarm-B

Zone: Trust
en OK:
Address Name: customer1

Zone: Untrust
3. VPN
VPN Name: vpn1

Gateway Name: gw-1


Service: ANY
4. Rutas



Interface: tunnel.1

5. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), customer1
Address Book Entry: (seleccione), serverfarm-B
Service: ANY
Action: Permit

NAT:
CLI (Dispositivo de seguridad-B)

1. Interfaces
2. Direcciones
set address trust serverfarm-B 10.173.50.0/24
set address untrust customer1 10.173.10.6/32
3. VPN
set ike gateway gw-1 ip 1.1.1.1 main outgoing-interface ethernet3 preshare
set vpn vpn2 gateway gw-1 sec-level compatible

4. Rutas
5. Directivas
set policy top from untrust to trust customer1 serverfarm-B any nat dst ip
10.100.2.0 10.100.2.255 permit
save


Capítulo 4
Direcciones virtuales y asignadas
ScreenOS proporciona varios métodos para realizar la traducción de dirección de

puerto de destino y dirección IP de destino. Este capítulo describe cómo utilizar la
dirección IP asignada (MIP) e IP virtual (VIP) y está organizado en las siguientes
secciones:
“Direcciones IP asignadas” en esta página
“MIP y la zona Global” en la página 66
“MIP-Same-as-Untrust” en la página 73
“MIP y la interfaz de bucle invertido (loopback)” en la página 76
“Agrupamiento de MIP” en la página 82
“Direcciones IP virtuales” en la página 83
“VIP y la zona Global” en la página 85
Direcciones IP asignadas
Una dirección IP asignada (MIP) es una asignación directa (“1:1”) de una dirección
IP a otra. El dispositivo de seguridad reenvía el tráfico entrante destinado a una MIP
al host a cuya dirección apunta la MIP. En esencia, una MIP es la traducción de una
dirección de destino estática, la correspondencia de una dirección IP de destino en
un encabezado de paquete IP con otra dirección IP estática. Cuando un host de MIP
inicia tráfico saliente, el dispositivo de seguridad traduce la dirección IP de origen
del host a la correspondiente a la dirección MIP. Esta simetría de la traducción
bidireccional difiere del comportamiento de la traducción de direcciones de origen
y de destino (consulte “Naturaleza direccional de NAT-Src y NAT-Dst” en la
página 12).
Las MIPs permiten que el tráfico entrante alcance las direcciones privadas de una
zona cuya interfaz se encuentra en modo NAT. Las MIPs también proporcionan una
solución parcial al problema de la superposición de espacios de direcciones en dos
sitios conectados mediante un túnel de VPN. (Para ver la solución completa a este
problema, consulte “Puntos VPN con direcciones superpuestas” en la
página 5-141).
Direcciones IP asignadas 65
NOTA: Un espacio de direcciones superpuesto se produce cuando los rangos de

direcciones IP de dos redes coinciden parcial o totalmente.
Puede crear una MIP en la misma subred que una interfaz de túnel con una
dirección IP o máscara de red, o bien en la misma subred que la dirección IP o
máscara de red de una interfaz asociada a una zona de seguridad de la capa 3 (L3).
Aunque las MIPs se configuran para interfaces asociadas a zonas de túnel y a zonas
de seguridad, las MIPs definidas se almacenan en la zona Global.
NOTA: Una excepción es una MIP definida para una interfaz en la zona Untrust. Esa MIP
puede encontrarse en una subred diferente de una dirección IP de interfaz de la
zona Untrust. Sin embargo, en tal caso deberá agregar una ruta en el enrutador
externo que apunte a una interfaz de la zona Untrust para que el tráfico entrante
pueda alcanzar la MIP. Asimismo, deberá definir una ruta estática en el dispositivo
de seguridad asociando la MIP a la interfaz que la hospeda.
Figura 35: Dirección IP asignada
IP asignada: El tráfico Nota: La MIP (1.1.1.5) se

entrante desde la zona Espacio encuentra en la misma subred que
Untrust se asigna de público de la interfaz de la zona Untrust
210.1.1.5 a 10.1.1.5 en direcciones (1.1.1.1/24), pero está en otra zona.
Zona
la zona Trust. Internet Untrust
MIP 1.1.1.5 -> 10.1.1.5
Interfaz zona Untrust
ethernet3, 1.1.1.1/24 Zona
Interfaz de zona Trust Global
ethernet1, 10.1.1.1/24
modo NAT
Zona Trust
Espacio 10.1.1.5
privado de
direcciones
NOTA: En algunos dispositivos de seguridad, una MIP puede utilizar la misma dirección
que una interfaz, pero una dirección MIP no puede encontrarse en un rango DIP.
Puede asignar una relación de “dirección a dirección” o de “subred a subred”.

Cuando se define una configuración de direcciones IP “subred a subred”, la
máscara de red se aplica tanto a la subred de direcciones IP asignadas como a la
subred IP original.
MIP y la zona Global

El establecimiento de una MIP para una interfaz en cualquier zona genera una
entrada para la MIP en la libreta de direcciones de la zona Global. La libreta de
direcciones de la zona Global almacena todas las MIP, sin importar a qué zona
pertenezcan sus interfaces. Puede utilizar estas direcciones MIP como direcciones
de destino en directivas entre dos zonas cualesquiera, y como direcciones de
destino al definir una directiva Global. (Para obtener más información sobre las
directivas Global, consulte “Directivas globales” en la página 2-166). Aunque el
dispositivo de seguridad almacena MIPs en la zona Global, puede utilizar la zona
Global o la zona que contiene la dirección a la que apunta la MIP, como zona de
destino en una directiva que haga referencia a una MIP.
66 Direcciones IP asignadas
Ejemplo: MIP en una interfaz de la zona Untrust
En este ejemplo, asociará ethernet1 a la zona Trust y le asignará la dirección IP
10.1.1.1/24. Asociará ethernet2 a la zona Untrust y le asignará la dirección IP
1.1.1.1/24. A continuación configurará una MIP para dirigir el tráfico HTTP entrante
destinado a 1.1.1.5 en la zona Untrust a un servidor web en la dirección IP 10.1.1.5
de la zona Trust. Finalmente, creará una directiva que permita el tráfico HTTP desde
cualquier dirección de la zona Untrust a la dirección MIP (y, por lo tanto, al host con
la dirección a la que apunta la MIP) de la zona Trust. Todas las zonas de seguridad
NOTA: Para una MIP o para el host al que apunta no se requiere ninguna entrada en la
libreta de direcciones.
Figura 36: MIP en una interfaz de la zona Untrust
Zona Untrust
Internet
MIP 1.1.1.5 -> 10.1.1.5

(Configurado en ethernet2)
Interfaz zona Untrust
ethernet2, 1.1.1.1/24
Zona Global
Interfaz zona Trust
ethernet1, 10.1.1.1/24
El tráfico destinado a 1.1.1.5 llega a ethernet2.
El dispositivo de seguridad consulta la ruta de

Servidor web una MIP en ethernet2 y resuelve 1.1.1.5 como
10.1.1.5 10.1.1.5.
El dispositivo de seguridad consulta la ruta de

Zona Trust 10.1.1.5 y reenvía el tráfico fuera de ethernet1.
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. MIP
Mapped IP: 1.1.1.5

Netmask: 255.255.255.255
3. Directivas
haga clic en OK:
Source Address:
Service: HTTP
Action: Permit
CLI
1. Interfaces
2. MIP
set interface ethernet2 mip 1.1.1.5 host 10.1.1.5 netmask 255.255.255.255
vrouter trust-vr
NOTA: De forma predeterminada, la máscara de red de una MIP es de 32 bits

(255.255.255.255), asignando la dirección a un solo host. También puede definir
una MIP para un rango de direcciones. Por ejemplo, para definir 1.1.1.5 como MIP
para las direcciones 10.1.10.129 a 10.1.10.254 dentro de una subred de clase C
mediante la interfaz de línea de comandos (“CLI”), utilice la sintaxis siguiente: set
interface interfaz mip 1.1.1.5 host 10.1.10.128 netmask 255.255.255.128.
Tenga cuidado de no utilizar un rango de direcciones que incluya las direcciones
de la interfaz o del enrutador.
El enrutador virtual predeterminado es trust-vr. No es necesario especificar que el

enrutador virtual es trust-vr ni que la MIP tiene una máscara de red de 32 bits.
Estos argumentos se incluyen en este comando para proporcionar por coherencia
con la configuración de WebUI.
3. Directivas
set policy from untrust to trust any mip(1.1.1.5) http permit
save
Ejemplo: Alcanzar una MIP desde diferentes zonas
Aunque el tráfico proceda de zonas diferentes, puede alcanzar una MIP
determinada a través de otras interfaces distintas de la utilizada para configurar esa
MIP. Para lograrlo, debe establecerse una ruta en los enrutadores de cada una de las
otras zonas que dirija el tráfico entrante hacia la dirección IP de sus respectivas
interfaces con el fin de alcanzar la MIP.
NOTA: Si la MIP se encuentra en la misma subred que la interfaz en la cual fue

configurada, no es necesario agregar una ruta al dispositivo de seguridad para que
el tráfico alcance la MIP a través de otra interfaz. Sin embargo, si la MIP se
encuentra en una subred distinta que la dirección IP de su interfaz (lo cual sólo es
posible con una MIP en una interfaz de la zona Untrust), es necesario agregar una
ruta estática a la tabla de enrutamiento del dispositivo de seguridad. Utilice el
comando set vrouter cadena_nombre route dir_ip interface interfaz (o su
equivalente en WebUI), donde cadena_nombre es el enrutador virtual al que
pertenece la interfaz especificada e interfaz es la interfaz en la que se configuró la
MIP.
En este ejemplo configurará una MIP (1.1.1.5) en la interfaz de la zona Untrust

(ethernet2, 1.1.1.1/24) para asignarla a un servidor web de la zona Trust (10.1.1.5).
La interfaz asociada a la zona Trust será ethernet1 con la dirección IP 10.1.1.1/24.
Creará una zona de seguridad llamada “X-Net”, a la que asociará ethernet3, y

asignará a la interfaz la dirección IP 1.3.3.1/24. Definirá una dirección para 1.1.1.5
que se utilizará en una directiva para permitir tráfico HTTP desde cualquier
dirección de la zona “X-Net” a la MIP en la zona Untrust. También configurará una
directiva para permitir que el tráfico HTTP pase desde la zona Untrust a la zona
Trust. Todas las zonas de seguridad se encuentran en el dominio de enrutamiento
trust-vr.
NOTA: Deberá introducir una ruta en el enrutador de la zona “X-Net” que dirija el tráfico
destinado a 1.1.1.5 (MIP) a 1.3.3.1 (dirección IP de ethernet3).
Figura 37: Alcanzar una MIP desde diferentes zonas
Nota: Deberá agregar una ruta a

este enrutador que apunte a
Zona Untrust Zona X-Net 1.3.3.1 para alcanzar 1.1.1.5.
Internet
Interfaz zona Untrust MIP 1.1.1.5 -> 10.1.1.5

ethernet2, 1.1.1.1/24 (Configurado en ethernet2)
Interfaz de zona X-Net Zona Global

ethernet3, 1.3.3.1/24
Interfaz zona Trust
ethernet1, 10.1.1.1/24
El tráfico destinado a 1.1.1.5 llega a ethernet2 y ethernet3.
Servidor web ethernet2: El dispositivo de seguridad consulta la ruta de

10.1.1.5 una MIP en ethernet2 y resuelve 1.1.1.5 a 10.1.1.5.
ethernet3: La consulta de rutas de una MIP en ethernet3 no
encuentra nada. ScreenOS comprueba otras interfaces,
Zona Trust encuentra una MIP en ethernet2 y reenvía el paquete a
ethernet2, donde la MIP se resuelve como 10.1.1.5.
El dispositivo de seguridad consulta la ruta de 10.1.1.5 y

reenvía el tráfico fuera de ethernet1.
WebUI
haga clic en OK:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

Zone Name: X-Net

Zone Type: Layer 3
haga clic en OK:
Zone Name: X-Net

2. Dirección
en OK:
Address Name: 1.1.1.5

Zone: Untrust
3. MIP
Mapped IP: 1.1.1.5

Netmask: 255.255.255.255
4. Directivas
Policies > (From: X-Net, To: Untrust) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), 1.1.1.5
Service: HTTP
Action: Permit
haga clic en OK:
Source Address:
Service: HTTP
Action: Permit
CLI
set zone name X-Net
set interface ethernet3 zone X-Net
2. Dirección
set address untrust “1.1.1.5” 1.1.1.5/32
3. MIP
vrouter trust-vr

(255.255.255.255) y el enrutador virtual predeterminado es trust-vr. No es
necesario especificar estos datos en el comando. Estos argumentos se incluyen
aquí por coherencia con la configuración de WebUI.
4. Directivas
set policy from X-Net to untrust any “1.1.1.5” http permit
save
Ejemplo: Adición de una MIP a una interfaz de túnel

En este ejemplo, el espacio de direcciones IP de la red en la zona Trust es
10.1.1.0/24 y la dirección IP de la interfaz de túnel “tunnel.8” es 10.20.3.1. La
dirección IP física de un servidor en la red de la zona Trust es 10.1.1.25. Para
permitir que un sitio remoto, cuya red en la zona Trust utiliza un espacio de
direcciones solapado para acceder al servidor local a través de un túnel VPN,
deberá crear una MIP en la misma subred que la interfaz “tunnel.8”. La dirección
MIP es 10.20.3.25/32. (Para ver un ejemplo más completo de una MIP con una
interfaz de túnel, consulte “Puntos VPN con direcciones superpuestas” en la
página 5-141).
WebUI
Network > Interfaces > Edit (para tunnel.8) > MIP > New: Introduzca los
Mapped IP: 10.20.3.25

Netmask: 255.255.255.255
CLI
set interface tunnel.8 mip 10.20.3.25 host 10.1.1.25 netmask 255.255.255.255
vrouter trust-vr
save
Cuando el administrador remoto agrega la dirección del servidor en su libreta de

direcciones de la zona Untrust, debe introducir la MIP (10.20.3.25), no la dirección
IP física del servidor (10.1.1.25).
El administrador remoto también debe aplicar NAT-Src basada en directivas

(utilizando DIP) en los paquetes salientes dirigidos al servidor a través de la VPN,
para que el administrador local pueda agregar una dirección de la zona Untrust
que no esté en conflicto con las direcciones locales de la zona Trust. De lo
contrario, la dirección de origen en la directiva de tráfico entrante parecería estar
en la zona Trust.
MIP-Same-as-Untrust
Dado que las direcciones IPv4 se están agotando, los proveedores de servicios de
Internet (ISP) son cada vez más reacios a dar más de una o dos direcciones IP a sus
clientes. Si solamente dispone de una dirección IP para la interfaz asociada a la
zona Untrust, ya que la interfaz asociada a la zona Trust está en modo de traducción
de direcciones de red (NAT), puede utilizar la dirección IP de la interfaz de la zona
Untrust como dirección IP asignada (MIP) para proporcionar acceso entrante a un
servidor o host interno, o bien a un punto final del túnel VPN o L2TP.
Una MIP asigna el tráfico entrante a una dirección a otra dirección; por lo tanto, al
utilizar la dirección IP de la interfaz de la zona Untrust como MIP, el dispositivo de
seguridad asigna a una dirección interna especificada todo el tráfico entrante que
utilice la interfaz de la zona Untrust. Si la MIP de la interfaz Untrust está asignada a
un punto final del túnel VPN o L2TP, el dispositivo reenvía automáticamente los
paquetes IKE o L2TP entrantes al punto final del túnel, siempre que no haya ningún
túnel VPN o L2TP configurado en la interfaz de Untrust.
Si crea una directiva en la cual la dirección de destino sea una MIP que utilice la
dirección IP de la interfaz de la zona Untrust y especifica HTTP como servicio en la
directiva, perderá la administración web del dispositivo de seguridad a través de esa
interfaz (debido a que todo el tráfico HTTP entrante dirigido a esa dirección está
asignado a un servidor o host interno). Aún así podrá administrar el dispositivo a
través de la interfaz de la zona Untrust mediante WebUI, cambiando el número de
puerto para la administración web. Para cambiar el número de puerto de
administración web, haga lo siguiente:
1. Admin > Web: Introduzca un número de puerto registrado (de 1024 a 65.535)
en el campo “HTTP Port”. Haga clic en Apply.
2. Cuando se conecte de nuevo a la interfaz de la zona Untrust para administrar el

dispositivo, agregue el número de puerto a la dirección IP, por ejemplo,
http://209.157.66.170:5000.
Ejemplo: MIP en la interfaz Untrust

En este ejemplo seleccionará la dirección IP de la interfaz de la zona Untrust
(ethernet3, 1.1.1.1/24) como MIP para un servidor web cuya dirección IP real sea
10.1.1.5 en la zona Trust. Como desea conservar el acceso de administración Web a
la interfaz ethernet3, deberá cambiar el número del puerto de administración a
8080. Luego creará una directiva que permita el servicio HTTP (en el número de
puerto HTTP predeterminado, el 80) desde la zona Untrust a la MIP y, por lo tanto,
al host con la dirección a la que apunta la MIP, en la zona Trust.
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

NAT: (seleccione)
haga clic en OK:
Zone Name: Untrust

2. Puerto HTTP
Configuration > Admin > Management: Escriba 8080 en el campo “HTTP
Port”, luego haga clic en Apply.
(La conexión HTTP se perderá).
3. Reconexión
Vuelva a conectarse al dispositivo de seguridad, agregando “8080” a la
dirección IP en el campo de la dirección URL de su explorador. (Si actualmente
está administrando el dispositivo a través de la interfaz Untrust, escriba
http://1.1.1.1:8080).
4. MIP
Network > Interface > Edit (para ethernet3) > MIP > New: Introduzca los
Mapped IP: 1.1.1.1

Netmask: 255.255.255.255
NOTA: La máscara de red de una MIP que utilice una dirección IP de la interfaz de la zona
Untrust debe ser de 32 bits.
5. Ruta

6. Directivas
haga clic en OK:
Source Address:
Service: HTTP
Action: Permit
CLI
1. Interfaces
2. Puerto HTTP
set admin port 8080
3. MIP
vrouter trust-vr

4. Ruta
5. Directivas
save
MIP y la interfaz de bucle invertido (loopback)

Definir una MIP en la interfaz de bucle invertido permite que esa MIP sea accesible
desde un grupo de interfaces. La principal aplicación de esta característica es
permitir el acceso a un host a través de uno de varios túneles VPN usando una sola
dirección MIP. El host de la MIP puede también iniciar tráfico a un sitio remoto a
través del túnel apropiado.
Figura 38: MIP en la interfaz de bucle invertido
Zona Untrust
Interlocutor de VPN Interfaz de la Interlocutor de VPN
zona Untrust
Túneles VPN El tráfico de ambas VPN puede
alcanzar la dirección MIP en la
Interfaces de túnel: interfaz de bucle invertido.
Miembros del grupo
de la interfaz de bucle
invertido
Dirección MIP
(definida en la
interfaz de bucle
invertido pero
almacenada en la
Interfaz de la zona Global)
zona Trust Interfaz de bucle invertido
(en la zona Untrust)
El tráfico procedente de la dirección

Zona Trust MIP sale a través de la interfaz de
la zona Trust al host MIP.
Host MIP
Puede imaginar la interfaz de bucle invertido como un contenedor de recursos que

contiene una dirección MIP. Deberá configurar una interfaz de bucle invertido con
el nombre loopback.núm_id (donde núm_id corresponde al número de índice que
permite identificar de forma inequívoca la interfaz en el dispositivo) y asignar una
dirección IP a la interfaz (consulte “Interfaces de bucle invertido (loopback)” en la
página 2-60). Para permitir que otras interfaces puedan utilizar una MIP en la
interfaz de bucle invertido, agregue las interfaces como miembros del grupo de
bucle invertido.
La interfaz de bucle invertido y las interfaces que la componen deben encontrarse

en diferentes subredes IP de la misma zona. Cualquier tipo de interfaz puede ser
miembro de un grupo de bucle invertido siempre que tenga una dirección IP. Si
configura una MIP en una interfaz de bucle invertido y en una de las interfaces que
la componen, la configuración de la interfaz de bucle invertido tendrá preferencia.
Una interfaz de bucle invertido no puede formar parte de otro grupo de bucle
invertido.
Ejemplo: MIP para dos interfaces de túnel

En este ejemplo configurará las interfaces siguientes:
ethernet1, zona Trust, 10.1.1.1/24
ethernet3, zona Untrust, 1.1.1.1/24
tunnel.1, zona Untrust, 10.10.1.1/24, asociada a vpn1
tunnel.2, zona Untrust, 10.20.1.1/24, asociada a vpn2
loopback.3, zona Untrust, 10.100.1.1/24
Las interfaces de túnel forman parte del grupo de interfaces loopback.3. La interfaz
loopback.3 contiene la dirección MIP 10.100.1.5, asignada a un host en la dirección
10.1.1.5 de la zona Trust.
Figura 39: MIP para dos interfaces de túnel
Espacio de direcciones Espacio de direcciones

privado detrás de gw1: privado detrás de gw2:
10.2.1.0/24 Zona Untrust 10.3.1.0/24
ethernet3
1.1.1.1/24
gw1 gw2
vpn1 vpn2
tunnel.1, 10.10.1.1/24 tunnel.2, 10.20.1.1/24
ethernet1 loopback.3
10.1.1.1/24 10.100.1.1/24 Dirección MIP:
Interfaces de túnel: (en zona Untrust) 10.100.1.5 -> 10.1.1.5
Miembros del grupo de la
interfaz de bucle invertido
Zona Trust
Host MIP
10.1.1.5
Cuando un paquete destinado a 10.100.1.5 llega a través de un túnel de VPN a

“tunnel.1”, el dispositivo de seguridad busca la MIP en la interfaz de bucle invertido
denominada “loopback.3”. Cuando encuentra una coincidencia en loopback.3, el
dispositivo de seguridad traduce la IP original de destino (10.100.1.5) a la dirección
IP del host (10.1.1.5) y reenvía el paquete a través de ethernet1 al host MIP. El
tráfico destinado a 10.100.1.5 también puede llegar a través de un túnel VPN
asociado a tunnel.2. De nuevo, el dispositivo de seguridad encuentra una
coincidencia en loopback.3 y traduce la IP de destino original 10.100.1.5 a 10.1.1.5
y reenvía el paquete al host MIP.
También definirá las direcciones, rutas, directivas y túneles VPN necesarios para
completar la configuración. Todas las zonas de seguridad se encuentran en el
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

NAT: (seleccione)
haga clic en OK:
Zone Name: Untrust

haga clic en OK:

clic en Apply:

Seleccione loopback.3 en la lista desplegable “Member of Loopback

Group” y haga clic en OK.
clic en Apply:

Seleccione loopback.3 en la lista desplegable “Member of Loopback

Group” y haga clic en OK.
2. MIP
Mapped IP: 10.100.1.5

Netmask: 255.255.255.255
3. Direcciones
en OK:

Zone: Trust
en OK:
Address Name: peer-1

Zone: Untrust
en OK:
Address Name: peer-2

Zone: Untrust
4. VPN
VPN Name: vpn1

Gateway Name: gw1


Service: ANY
VPN Name: vpn2

Gateway Name: gw2


Service: ANY
5. Rutas

Interface: tunnel.1

Interface: tunnel.2

6. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), peer-1
Service: ANY
Action: Permit
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), peer-2
Service: ANY
Action: Permit
haga clic en OK:
Source Address:
Service: ANY
Action: Permit
CLI
1. Interfaces
set interface loopback.3 zone trust
set interface tunnel.1 loopback-group loopback.3
set interface tunnel.2 loopback-group loopback.3
2. MIP
set interface loopback.3 mip 10.100.1.5 host 10.1.1.5 netmask
255.255.255.255 vrouter trust-vr

3. Direcciones
set address trust local_lan 10.1.1.0/24
set address untrust peer-1 10.2.1.0/24
set address untrust peer-2 10.3.1.0/24
4. VPN
set ike gateway gw1 address 2.2.2.2 outgoing-interface ethernet3 preshare
set ike gateway gw2 address 3.3.3.3 outgoing-interface ethernet3 preshare
5. Rutas
6. Directivas
set policy top from untrust to trust peer-1 mip(10.100.1.5) any permit
set policy top from untrust to trust peer-2 mip(10.100.1.5) any permit
set policy from trust to untrust local_lan any any permit
save
Agrupamiento de MIP
La asignación de una MIP a un interfaz aparta un rango de direcciones IP para
utilizarlas como direcciones de destino para paquetes que pasan a través de la
interfaz. Luego puede utilizar la MIP en una directiva, que hace reconocible la
dirección para las interfaces que reciben los paquetes entrantes, o utilizable para las
interfaces que transmiten los paquetes de salientes.
Sin embargo, es posible que existan situaciones en las que sea necesario invocar
varias MIPs en una directiva individual. Por ejemplo, es posible que un rango de
direcciones individuales no proporcione suficientes direcciones cuando existen
varios host de destino o puertas de enlace en una topología de red determinada.
Dicha solución requiere del agrupamiento de MIP, lo que le permite diseñar
directivas de celdas múltiples. Dichas directivas invocan varios rangos de direcciones
como posibles direcciones de origen.
Ejemplo: Agrupamiento de MIP con directivas de celdas múltiples

En el siguiente ejemplo, puede crear una directiva que utiliza dos definiciones de
direcciones MIP diferentes (1.1.1.3 y 1.1.1.4).
NOTA: Para este ejemplo, se asume que la ID de la directiva para la directiva generada es
104.
WebUI
Network > Interface > Edit > MIP (List)
Policies > New
CLI
set interface ethernet1/2 mip 1.1.1.3 host 2.2.2.2
set interface ethernet1/2 mip 1.1.1.4 host 3.3.3.3
set policy from untrust to trust any mip(1.1.1.3) any permit
set policy id 104
(policy:104)-> set dst-address mip(1.1.1.4)
(policy:104)-> exit
get policy id 104
NOTA: Después de ejecutar el último comando de CLI en este ejemplo, busque la

siguiente salida para la confirmación:
2 destinations: “MIP(1.1.1.3)”, “MIP(1.1.1.4)”
Direcciones IP virtuales
Una dirección IP virtual IP (VIP) asigna el tráfico recibido en una dirección IP a otra
dirección basándose en el número del puerto de destino que figura en el
encabezado del segmento TCP o UDP. Por ejemplo:
Un paquete HTTP destinado a 1.1.1.3:80 (dirección IP 1.1.1.3 y puerto 80)

podría asignarse a un servidor web en 10.1.1.10.
Un paquete FTP destinado a 1.1.1.3:21 podría asignarse a un servidor FTP en

10.1.1.20.
Un paquete SMTP destinado a 1.1.1.3:25 podría asignarse a un servidor de

correo en 10.1.1.30.
Los direcciones IP de destino son iguales. Los números de los puertos de destino
determinan a qué host debe el dispositivo de seguridad reenviar el tráfico.
Figura 40: Dirección IP virtual o VIP
Servidor web
10.1.1.10
HTTP (80) FTP (21)

Zona Untrust Zona Global
Zona Trust
Servidor FTP
Internet 10.1.1.20
VIP 1.1.1.3
SMTP (25)
Servidor de correo
10.1.1.30
Interfaz zona Untrust Interfaz zona Trust

Tabla 2: Tabla de reenvíos de direcciones IP virtuales
IP de interfaz en zona Untrust VIP en la zona Global Puerto Reenviar a IP de host en la zona Trust
1.1.1.1/24 1.1.1.3 80 (HTTP) 10.1.1.10
1.1.1.1/24 1.1.1.3 21 (FTP) 10.1.1.20
1.1.1.1/24 1.1.1.3 25 (SMTP) 10.1.1.30
El dispositivo de seguridad reenvía el tráfico entrante destinado a una VIP al host a

cuya dirección apunta la VIP. Sin embargo, cuando un host VIP inicia el tráfico
saliente, el dispositivo de seguridad únicamente traduce la dirección IP original de
origen a otra dirección si usted ha configurado previamente NAT en la interfaz de
entrada o NAT-Src en una directiva que aplica al tráfico que proviene de ese host. En
caso contrario, el dispositivo de seguridad no traduce la dirección IP de origen en el
tráfico que se origina de un host VIP.
Direcciones IP virtuales 83
Para definir una IP virtual necesitará la información siguiente:
La dirección IP de la VIP debe pertenecer a la misma subred que una interfaz

en la zona Untrust o, en algunos dispositivos de seguridad, incluso puede tener
la misma dirección que esa interfaz.
En algunos dispositivos de seguridad, una interfaz en la zona Untrust puede

recibir su dirección IP dinámicamente a través de DHCP o PPPoE. Si desea
utilizar una VIP en dicha situación, puede utilizar uno de los siguientes WebUI
(Network > Interfaces > Edit (para una interfaz en la zona Untrust) > VIP:
Si configura una VIP para que utilice la misma dirección IP que una interfaz
de la zona Untrust en un dispositivo que admita múltiples VIP, las otras
VIPs “normales” dejarán de ser utilizables.
Si hay configurada alguna VIP normal, no podrá crear una VIP mediante
una interfaz de la zona Untrust salvo que elimine primero la VIP normal.
Las direcciones IP de los servidores que procesan las peticiones
El tipo de servicio que el dispositivo de seguridad debe remitir desde la VIP a la

dirección IP del host
NOTA: En una interfaz de la zona Untrust solamente se puede establecer una VIP.
Algunas notas sobre las VIPs:
Si está ejecutando múltiples procesos de servidor en un solo equipo, puede

utilizar números de puerto virtuales para los servicios conocidos. Por ejemplo,
si está ejecutando dos servidores FTP en el mismo equipo, puede ejecutar uno
de ellos en el puerto 21 y el otro en el puerto 2121. Sólo quienes conozcan de
antemano el número de puerto virtual y lo incluyan en el encabezado de
paquete de la dirección IP podrán obtener acceso al segundo servidor FTP.
Se pueden establecer asignaciones (correspondencias) para servicios

predefinidos y servicios definidos por el usuario.
Una sola VIP puede distinguir servicios personalizados con los mismos
números de puerto de origen y de destino pero diferentes medios de
transporte.
Los servicios personalizados pueden utilizar cualquier número de puerto de

destino o rango de números entre 1 y 65.535, no sólo entre 1024 y 65.535.
Una sola VIP puede admitir servicios personalizados con múltiples entradas de
puertos creando múltiples entradas de servicios bajo esa VIP (una por cada
puerto en el servicio). De forma predeterminada, en una VIP se pueden utilizar
servicios de puerto único. Para poder utilizar servicios de múltiples puertos en
una VIP, primero debe ejecutar el comando CLI set vip multi-port y enseguida
reiniciar el dispositivo de seguridad. (Consulte “Ejemplo: VIP con servicios
personalizados y de múltiples puertos” en la página 88).
El host al que el dispositivo de seguridad asigne el tráfico VIP debe ser

alcanzable desde trust-vr. Si el host se encuentra en un dominio de
enrutamiento distinto de trust-vr, debe definir una ruta para alcanzarlo.
84 Direcciones IP virtuales
VIP y la zona Global
Al establecer una VIP para una interfaz en la zona Untrust se genera una entrada en
la libreta de direcciones de la zona Global. La libreta de direcciones de la zona
Global mantiene un registro de todas las VIPs de todas las interfaces, sin importar a
qué zona pertenezca cada interfaz. Puede utilizar estas direcciones VIP como
dirección de destino en directivas entre dos zonas cualesquiera, y como dirección
de destino en directivas Global.
Ejemplo: Configuración de servidores de IP virtuales

En este ejemplo asociará la interfaz ethernet1 a la zona Trust y le asignará la
dirección IP 10.1.1.1/24. Asociará la interfaz ethernet3 a la zona Untrust y le
asignará la dirección IP 1.1.1.1/24.
Seguidamente, configurará una VIP en 1.1.1.10 para reenviar el tráfico HTTP

entrante a un servidor Web en 10.1.1.10 y creará una directiva que permita al
tráfico procedente de la zona Untrust alcanzar la VIP en la zona Trust (y, por lo
tanto, al host con la dirección a la que apunta la VIP).
Dado que la VIP se encuentra en la misma subred que la interfaz de la zona Untrust
(1.1.1.0/24), no es necesario definir una ruta para que el tráfico procedente de la
zona Untrust la alcance. Tampoco se requiere ninguna entrada en la libreta de
direcciones para el host al que una VIP reenvía tráfico. Todas las zonas de seguridad
NOTA: Si desea que el tráfico HTTP procedente de una zona de seguridad distinta de la
zona Untrust alcance la VIP, debe establecer una ruta para 1.1.1.10 en el enrutador
y en la otra zona que apunte a una interfaz asociada a esa zona. Por ejemplo,
suponga que ethernet2 está asociada a una zona definida por el usuario y que ha
configurado un enrutador en esa zona para que envíe a ethernet2 el tráfico
destinado a 1.1.1.10. Una vez que el enrutador envía tráfico a ethernet2, el
mecanismo de reenvío del dispositivo de seguridad localiza la VIP en ethernet3,
que lo asigna a 10.1.1.10 y lo envía a través de ethernet1 a la zona Trust. Este
proceso es similar al descrito en “Ejemplo: Alcanzar una MIP desde diferentes
zonas” en la página 69. También deberá establecer una directiva que permita el
tráfico HTTP procedente de la zona de origen a la VIP en la zona Trust.
Figura 41: Servidor IP virtual
Zona Untrust Zona Global Zona Trust
Internet HTTP (80)

Servidor web
10.1.1.10
VIP 1.1.1.10

WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. VIP
Network > Interfaces > Edit (para ethernet3) > VIP: Introduzca las siguientes
direcciones y haga clic en Add:
Virtual IP Address: 1.1.1.10
Network > Interfaces > Edit (para ethernet3) > VIP > New VIP Service:
Virtual IP: 1.1.1.10

Virtual Port: 80
Map to Service: HTTP (80)
Map to IP: 10.1.1.10
3. Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), ANY
Service: HTTP
Action: Permit
CLI
1. Interfaces
2. VIP
set interface ethernet3 vip 1.1.1.10 80 http 10.1.1.10
3. Directivas
set policy from untrust to trust any vip(1.1.1.10) http permit
save
Ejemplo: Edición de una configuración de VIP
En este ejemplo modificará la configuración del servidor de IPs virtuales que creó
en el ejemplo anterior. Para restringir el acceso al servidor web, cambiará el número
de puerto virtual para el tráfico HTTP de 80 (predeterminado) a 2211. Desde ese
momento, sólo podrán utilizar el servidor web quienes sepan que deben utilizar el
número de puerto 2211 para conectarse a él.
WebUI
Network > Interfaces > Edit (para ethernet3) > VIP > Edit (en la sección “VIP
Services Configure” correspondiente a 1.1.1.10): Introduzca los siguientes
Virtual Port: 2211
CLI
unset interface ethernet3 vip 1.1.1.10 port 80
set interface ethernet3 vip 1.1.1.10 2211 http 10.1.1.10
save
Ejemplo: Eliminación de una configuración VIP

En este ejemplo eliminará la configuración VIP que creó y modificó anteriormente.
Para poder eliminar una VIP, primero debe eliminar cualquier directiva existente
asociada a ella. El número de ID para la directiva que creó en “Ejemplo:
Configuración de servidores de IP virtuales” en la página 85 es 5.
WebUI
Policies > (From: Untrust, To: Trust) > Go: Haga clic en Remove para la
directiva con ID 5.
Network > Interfaces > Edit (para ethernet3) > VIP: Haga clic en Remove en
la sección “VIP Configure” correspondiente a 1.1.1.10.
CLI
unset policy id 5
unset interface ethernet3 vip 1.1.1.10
save
Ejemplo: VIP con servicios personalizados y de múltiples puertos

En el ejemplo siguiente, configurará una VIP en 1.1.1.3 para enrutar los siguientes
servicios hacia las direcciones internas siguientes:
Número de Número de Dirección IP

Servicio Transporte puerto virtual puerto real del host
DNS TCP, UDP 53 53 10.1.1.3
HTTP TCP 80 80 10.1.1.4
PCAnywhere TCP, UDP 5631, 5632 5631, 5632 10.1.1.4
LDAP TCP, UDP 5983 389 10.1.1.5
Figura 42: VIP con servicios personalizados y de múltiples puertos
Servidor web: 10.1.1.3

DNS 53 -> 53
Zona Untrust Zona Global Servidor DNS:

10.1.1.4
HTTP 80 -> 80
Administrador PCAnywhere
remoto 3.3.3.3 5631, 5632 ->
5631, 5632
VIP 1.1.1.3
Servidor LDAP: 10.1.1.5
LDAP 5983 -> 389
La VIP enruta (reenvía) las consultas DNS al servidor DNS en 10.1.1.3, el tráfico
HTTP al servidor Web en 10.1.1.4 y las comprobaciones de autenticación a la base
de datos del servidor LDAP en 10.1.1.5. Para HTTP, DNS y PCAnywhere, los
números de puerto virtuales siguen siendo iguales que los números de puerto
reales. Para LDAP, se utiliza un número de puerto virtual (5983) para agregar un
nivel adicional de seguridad al tráfico de autenticación de LDAP.
Para administrar remotamente el servidor HTTP, definirá un servicio personalizado

y lo llamará PCAnywhere. PCAnywhere es un servicio de puertos múltiples que
envía y recibe datos a través del puerto TCP 5631 y comprobaciones de estado a
través del puerto UDP 5632.
También introducirá la dirección del administrador remoto de 3.3.3.3 en la libreta

de direcciones de la zona Untrust y configurará directivas del tráfico desde la zona
Untrust a la zona Trust para todo el tráfico que deba utilizar las VIPs. Todas las
zonas de seguridad se encuentran en el dominio de enrutamiento trust-vr.
WebUI
1. Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust

2. Dirección
en OK:
Address Name: Administrador remoto

Zone: Untrust
clic en OK:
Service Name: PCAnywhere

No 1:
Transport Protocol: TCP
Source Port Low: 0
No 2:
Transport Protocol: UDP
Source Port Low: 0
4. Dirección y servicios VIP
NOTA: Para habilitar la VIP de modo que pueda trabajar con servicios de múltiples
puertos, deberá ejecutar el comando CLI set vip multi-port, guardar la
configuración y seguidamente reiniciar el dispositivo.
Network > Interfaces > Edit (para ethernet3) > VIP: haga clic aquí para
configurar: Escriba 1.1.1.3 en el campo “Virtual IP Address”, luego haga clic en
Add.
> New VIP Service: Introduzca los siguientes datos y haga clic en OK:
Virtual IP: 1.1.1.3

Virtual Port: 53
Map to Service: DNS
Map to IP: 10.1.1.3
Virtual IP: 1.1.1.3

Virtual Port: 80
Map to Service: HTTP
Map to IP: 10.1.1.4
Virtual IP: 1.1.1.3

Virtual Port: 5631
Map to Service: PCAnywhere
Map to IP: 10.1.1.4
NOTA: Para servicios de múltiples puertos, introduzca el número de puerto más bajo del
servicio como número de puerto virtual.
Virtual IP: 1.1.1.3

Virtual Port: 5983
Map to Service: LDAP
Map to IP: 10.1.1.5
NOTA: La utilización de números de puerto no estándar agrega otra capa de seguridad,

evitando ataques comunes que buscan servicios en los números de puerto
estándar.
5. Directivas
haga clic en OK:
Source Address:
Service: DNS
Action: Permit
haga clic en OK:
Source Address:
Service: HTTP
Action: Permit
haga clic en OK:
Source Address:
Service: LDAP
Action: Permit
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Remote Admin
Service: PCAnywhere
Action: Permit
CLI
1. Interfaces
2. Dirección
set address untrust “Remote Admin” 3.3.3.3/32
set service pcanywhere protocol udp src-port 0-65535 dst-port 5631-5631
set service pcanywhere + tcp src-port 0-65535 dst-port 5632-5632
4. Dirección y servicios VIP
set vip multi-port
save
reset
System reset, are you sure? y/[n]
set interface ethernet3 vip 1.1.1.3 53 dns 10.1.1.3
set interface ethernet3 vip 1.1.1.3 + 80 http 10.1.1.4
set interface ethernet3 vip 1.1.1.3 + 5631 pcanywhere 10.1.1.4
set interface ethernet3 vip 1.1.1.3 + 5983 ldap 10.1.1.5
NOTA: Para servicios de múltiples puertos, introduzca el número de puerto más bajo del
servicio como número de puerto virtual.
5. Directivas
set policy from untrust to trust any vip(1.1.1.3) dns permit
set policy from untrust to trust any vip(1.1.1.3) http permit
set policy from untrust to trust any vip(1.1.1.3) ldap permit
set policy from untrust to trust “Remote Admin” vip(1.1.1.3) pcanywhere permit
save
Índice
C N
CLI, set vip multi-port ...................................................84 NAT
conjuntos de DIP definición....................................................................1
consideraciones sobre direcciones .......................16 NAT-src con NAT-dst .......................................52 a 63
NAT-src .......................................................................1 NAT basada en directivas
tamaño .....................................................................16 Véase NAT-dst y NAT-src
NAT-dst ....................................................................30 a 63
D asignación de puertos ...................................5, 30, 49
dirección IP asignada con MIP o VIP ............................................................4
Véase MIP consideraciones sobre las rutas ...............31, 34 a 36
Direcciones IP, virtuales ................................................83 desplazamiento de direcciones ...............................6
flujo de paquetes .............................................31 a 33
E traducción unidireccional ...................................8, 12
enrutadores virtuales, MIP predeterminada ...............68 NAT-dst, direcciones
desplazamiento .................................................30, 46
F rango a IP única .................................................11, 43
flujo de paquetes, NAT-dst .................................... 31 a 33 rango a rango .....................................................11, 46
rangos .........................................................................5
I NAT-dst, IP individual
interfaces con asignación de puerto .......................................10
MIP ............................................................................66 sin asignación de puerto ........................................10
VIP.............................................................................83 NAT-dst, traducción
IP virtual “1:1”..........................................................................37
Véase VIP “1:n”..........................................................................40
NAT-src ................................................................1, 15 a 28
basada en interfaces .................................................2
M interfaz de salida .......................................10, 26 a 28
máscaras de red, MIP predeterminada .......................68
MIP ..................................................................................65 puerto fijo ...................................................16, 20 a 21
NAT-src, conjuntos de DIP ...............................................1
agrupamiento, directivas de celdas múltiples .....82
con desplazamiento de direcciones ........................9
alcanzable desde otras zonas ................................69
definición ...................................................................7 con PAT ........................................................8, 17 a 19
puerto fijo ...................................................................9
rangos de direcciones .............................................68
NAT-src, direcciones
same-as-untrust, interfaz ................................ 73 a 75
desplazamiento ...............................................22 a 26
traducción bidireccional ...........................................7
desplazamiento, consideraciones sobre el rango 22
zona global ...............................................................66
NAT-src, traducción
MIP, creación
direcciones de puerto ...............................................2
direcciones ...............................................................67
unidireccional ......................................................8, 12
en interfaz de túnel .................................................72
en interfaz de zona .................................................67
MIP, predeterminada P
enrutadores virtuales ..............................................68 PAT ...................................................................................16
máscaras de red ......................................................68 puertos
asignación ............................................................5, 30
números ...................................................................90
Índice IX-I
S
Servicios VIP
personalizados y multipuerto ........................ 88 a 92
personalizados, números de puerto bajos ........... 84
T
traducción de direcciones
Véase NAT, NAT-dst y NAT-src
V
VIP
alcanzable desde otras zonas ................................ 85
configuración ........................................................... 85
definición ................................................................... 7
edición ...................................................................... 87
eliminación .............................................................. 87
información necesaria ............................................ 84
zonas globales ......................................................... 85
Z
zonas globales ................................................................ 85
zonas, global .................................................................. 85
IX-II Índice
Volumen 9:

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Copyright Notice
without notice.
FCC Statement
Disclaimer
Writers: Richard Biegel, Sharmila Kumar

ii
Contenido
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
Personalizar mensajes de bienvenida............................................................. 10
Ejemplo: Personalización de un mensaje de bienvenida de WebAuth ..... 10
Capítulo 2 Servidores de autenticación 11

Base de datos local......................................................................................... 14
Ejemplo: Tiempo de espera de la base de datos local .............................. 15
Servidores de autenticación externos............................................................. 15
Propiedades del objeto “servidor de autenticación”................................. 17
Servicio de autenticación remota de usuarios de acceso telefónico.......... 19
Propiedades del objeto servidor de autenticación RADIUS ................ 19
Archivo de diccionario de ScreenOS.................................................. 20
Contabilidad de RADIUS ................................................................... 23
SecurID ............................................................................................. 25
Propiedades del objeto servidor de autenticación SecurID ................ 26
Protocolo ligero de acceso a directorios................................................... 27
Propiedades del objeto servidor de autenticación LDAP.................... 27
Definir objetos de servidor de autenticación .................................................. 28
Ejemplo: Servidor de autenticación RADIUS ............................................ 28
Ejemplo: Servidor de autenticación LDAP................................................ 32
Definir servidores de autenticación predeterminados .................................... 34
Ejemplo: Cambio de los servidores de autenticación predeterminados.... 34
Contenido iii
Capítulo 3 Usuarios de autenticación 37

Referencias a usuarios autenticados en directivas .......................................... 38
Autenticación en tiempo de ejecución ..................................................... 38
Autenticación de comprobación previa a la directiva (WebAuth) ............. 39
Referencias a grupos de usuarios de autenticación en directivas.................... 40
Ejemplo: Autenticación en tiempo de ejecución (usuario local)................ 41
Ejemplo: Autenticación en tiempo de ejecución (grupo de usuarios
locales)..............................................................................................43
Ejemplo: Autenticación en tiempo de ejecución (usuario externo) ........... 45
Ejemplo: Autenticación en tiempo de ejecución (grupo de usuarios
externo) ............................................................................................ 47
Ejemplo: Usuario de autenticación local en múltiples grupos................... 49
Ejemplo: WebAuth (grupo de usuarios local)............................................ 52
Ejemplo: WebAuth (grupo de usuarios externo)....................................... 53
Ejemplo: WebAuth + SSL sólo (grupo de usuarios externo) .................... 55
Capítulo 4 Usuarios IKE, XAuth y L2TP 59

Usuarios y grupos de usuarios IKE .................................................................59
Ejemplo: Definición de usuarios IKE ........................................................ 60
Ejemplo: Creación de un grupo de usuarios IKE ...................................... 62
Referencias a usuarios IKE en puertas de enlace ..................................... 62
Usuarios y grupos de usuarios XAuth ............................................................. 62
Usuarios XAuth en negociaciones IKE ..................................................... 64
Ejemplo: Autenticación XAuth (usuario local) .................................... 66
Ejemplo: Autenticación XAuth (usuario externo) ............................... 69
Cliente XAuth .......................................................................................... 79
Ejemplo: Dispositivo de seguridad como cliente XAuth..................... 79
Usuarios y grupos de usuarios L2TP ............................................................... 80
Ejemplo: Servidores de autenticación L2TP locales y externos ................ 80
Índice ........................................................................................................................IX-I
iv Contenido
El Volumen 9: Autenticación de usuarios describe los métodos de ScreenOS para

autenticar diferentes tipos de usuarios. Contiene una introducción a la
autenticación de usuarios, presenta las dos ubicaciones en las que se puede
almacenar la base de datos de perfiles de usuarios (la base de datos interna y un
servidor de autenticación externo), y luego proporciona numerosos ejemplos para
configurar la autenticación, usuarios y grupos de usuarios IKE, XAuth y L2TP.
También se tratan algunos otros aspectos de la autenticación de usuarios, como
cambiar los mensajes de bienvenida de inicio de sesión, crear usuarios de múltiple
tipos (por ejemplo, un usuario IKE/XAuth) y utilizar expresiones de grupos en
directivas que aplican la autenticación.
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 y 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, “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 4, “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.



En ejemplos:


En texto:
Los comandos aparecen en tipo negrita.



10.1.1.0/24)

Internet

dinámicas (DIP)

Equipo portátil
Interfaz de túnel
Servidor
Túnel VPN
Concentrador (hub)
Enrutador
Teléfono IP
Conmutador








de configuración:

en OK:
Zone: Untrust





Capítulo 1
Autenticación
Después de una introducción general a los diferentes tipos de autenticación

disponibles para los diferentes tipos de usuarios de la red, este capítulo dedica una
breve sección a la autenticación del usuario administrador (admin). A continuación,
proporciona información sobre la combinación de diferentes tipos de usuarios, la
utilización de expresiones de grupos y cómo personalizar los mensajes de
bienvenida que aparecen al iniciar una sesión HTTP, FTP, L2TP, Telnet y XAuth. Este
capítulo contiene las siguientes secciones:
“Tipos de autenticaciones de usuarios” en esta página
“Usuarios con permisos de administrador” en la página 2
“Usuarios de múltiples tipos” en la página 4
“Expresiones de grupos” en la página 5
“Personalizar mensajes de bienvenida” en la página 11
Tipos de autenticaciones de usuarios

En los siguientes capítulos se describen los diferentes tipos de usuarios y grupos de
usuarios que se pueden crear y cómo utilizarlos al configurar directivas, puertas de
enlace IKE y túneles L2TP:
“Usuarios de autenticación” en la página 39
“Usuarios y grupos de usuarios IKE” en la página 61
“Usuarios y grupos de usuarios XAuth” en la página 64
“Usuarios y grupos de usuarios L2TP” en la página 82
El dispositivo de seguridad autentica los diferentes tipos de usuarios en diversas

etapas durante el proceso de conexión. Las técnicas de autenticación de usuario
IKE, XAuth, L2TP y auth ocurren en diferentes momentos durante la creación del
túnel VPN L2TP a través de IPSec. Consulte la Figura 4.
Tipos de autenticaciones de usuarios 1

Figura 4: Autenticación durante el túnel VPN L2TP a través de IPSec
Las fases en las que se produce la autenticación de usuarios IKE, XAuth, L2TP y
auth ocurren durante la configuración y uso de un túnel L2TP sobre IPSec.
Identificación IKE
Durante la fase 1 XAuth L2TP Auth
Modo principal: Mens. 5 y 6 Entre las fases 1 y 2 Una vez establecido el túnel Cuando el tráfico enviado
Modo dinámico: Mens. 1 y 2 IPSec, durante la a través del túnel alcanza
negociación del túnel L2TP el cortafuegos de Juniper
Networks
Usuario
Auth/IKE/L2TP/XAuth
Fase 1 Fase 2
Túnel IPSec
Túnel L2TP
Tráfico
Nota: Dado que tanto XAuth como L2TP proporcionan autenticación de usuarios y asignaciones de direcciones, rara vez se utilizan juntos. Se
muestran juntos aquí solamente para ilustrar cuándo se produce cada tipo de autenticación durante la creación de un túnel VPN.
Usuarios con permisos de administrador

Los usuarios con permisos de administrador son los administradores de un
dispositivo de seguridad. Hay cinco clases de usuarios con permisos de
administrador:
Administrador raíz (“root admin”)
Administrador de lectura/escritura de nivel raíz (“root-level read/write admin”)
Administrador de sólo lectura de nivel raíz (“root-level read-only admin”)
Administrador Vsys (“Vsys admin”)
Administrador Vsys de sólo lectura (“Vsys read-only admin”)
NOTA: Para obtener información sobre los privilegios de cada tipo de usuario
administrador y ver ejemplos de creación, modificación y eliminación de usuarios
administradores, consulte “Administración” en la página 3-1.
Aunque el perfil del usuario raíz de un dispositivo de seguridad debe almacenarse

en la base de datos local, puede almacenar usuarios vsys y usuarios
administradores de nivel raíz con privilegios de lectura/escritura y privilegios de
sólo lectura en la base de datos local o en un servidor de autenticación externo.
Si almacena cuentas de usuarios administradores en un servidor de autenticación

RADIUS externo y carga el archivo de diccionario de ScreenOS en el servidor de
autenticación (consulte “Archivo de diccionario de ScreenOS” en la página 22),
puede optar por consultar los privilegios de administrador definidos en el servidor.
Opcionalmente, puede especificar un nivel de privilegios que se aplicará
globalmente a todos los usuarios con permisos de administrador almacenados en
2 Usuarios con permisos de administrador

Capítulo 1: Autenticación
ese servidor de autenticación. Puede especificar privilegios de lectura/escritura o de

sólo lectura. Si almacena usuarios con permisos de administrador en un servidor de
autenticación SecurID o LDAP externo, o en un servidor RADIUS sin el archivo de
diccionario de ScreenOS, no podrá definir sus atributos de privilegios en el servidor
de autenticación. Por lo tanto, debe asignarles un nivel de privilegios en el
Y el servidor RADIUS Y un servidor SecurID,

Si se establecen en tiene cargado el LDAP o RADIUS sin el
el dispositivo de archivo de diccionario archivo de diccionario de
seguridad: de ScreenOS: ScreenOS:
Obtener privilegios del Asignar los privilegios Falla inicio de sesión del
servidor RADIUS apropiados admin. de nivel raíz o vsys
Asignar privilegios de Asignar privilegios de Asignar privilegios de
lectura/escritura al lectura/escritura de nivel lectura/escritura de nivel raíz
admin. externo raíz o vsys Falla inicio de sesión del
admin. vsys
Asignar privilegios de Asignar privilegios de Asignar privilegios de sólo
sólo lectura al admin. sólo lectura de nivel raíz lectura de nivel raíz
externo o vsys Falla inicio de sesión del
admin. vsys
La Figura 5 muestra el proceso de autenticación de admin.
Figura 5: Proceso de autenticación de admin.
Usuario 4, 5. El dispositivo de seguridad comprueba una cuenta de usuario

1. El usuario administrador inicia una
administrador administrador primero en la base de datos local y luego, si no
sesión HTTP o Telnet.
ha encontrado ninguna coincidencia, revisa en un servidor de
autenticación externo.
Name: ?? BD local
Password: ??
Name: **
Password: ** Servidor de autenticación
WebUI o CLI
2, 3. ScreenOS envía una petición de inicio de sesión a
través de HTTP o Telnet al origen. 6. Después de autenticar con éxito a un usuario con
permisos de administrador, el dispositivo abre
una sesión de WebUI o de CLI.
Usuarios con permisos de administrador 3

Usuarios de múltiples tipos

Puede combinar usuarios de autenticación, IKE, L2TP o XAuth para crear las
siguientes combinaciones y almacenarlas en la base de datos local:
Usuario Auth/IKE
Usuario Auth/IKE/XAuth
Usuario Auth/L2TP
Usuario IKE/XAuth
Usuario Auth/IKE/L2TP
Usuario L2TP/XAuth
Usuarios IKE/L2TP
Usuario IKE/L2TP/XAuth
Usuario Auth/XAuth
Usuario Auth/IKE/L2TP/XAuth

Manual SSG 140

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

Manual SSG 140

Uploaded by

Copyright:

Available Formats

Conceptos y ejemplos

Manual de Referencia de ScreenOS

Versión 5.3.0, Rev. B

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.

Apéndice A Glosario A-I

Capítulo 1 Arquitectura de ScreenOS 1

Crear una dirección IP secundaria.................................................................. 59

Capítulo 4 Modos de las interfaces 81

Capítulo 5 Bloques para la construcción de directivas 105

Servicios relacionados con IP ..........................................................121

Capítulo 6 Directivas 163

Capítulo 7 Asignar tráfico 197

Capítulo 8 Parámetros del sistema 221

Protocolo de configuración dinámica de hosts .............................................229

Secure Sockets Layer ................................................................................. 5

Administración a través de un túnel VPN de clave manual

Capítulo 2 Supervisar dispositivos de seguridad 53

Apéndice A Archivos MIB para SNMP A-I

netscreenVsys ...................................................................................... A-VI

Capítulo 1 Protección de una red 1

Capítulo 2 Disuasión de reconocimiento 6

Capítulo 3 Defensas contra los ataques de denegación de servicio (DoS) 32

Inundación ICMP ..................................................................................... 52

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

Compatibilidad con sistemas virtuales .............................................. 99

Capítulo 5 Deep Inspection 105

Bloqueo granular de los componentes de HTTP ...........................................159

Capítulo 6 Atributos de los paquetes sospechosos 163

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

Capítulo 3 Directivas de red privada virtual 47

Capítulo 4 Redes privadas virtuales de punto a punto 81

Capítulo 5 Redes privadas virtuales de acceso telefónico 159

Capítulo 6 Protocolo de encapsulamiento de la capa 2 (L2TP) 205

Capítulo 7 Funciones avanzadas de redes privadas virtuales 231

Comprobar flag TCP SYN.......................................................................296

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

Capítulo 3 Puerta de enlace en la capa de aplicación del Protocolo

Capítulo 1 Enrutamiento estático 1

Reenviar tráfico a la interfaz nula................................................................... 10

Capítulo 3 Protocolo OSPF 47

Crear y eliminar una instancia de enrutamiento de OSPF........................ 53

Capítulo 4 Protocolo de información de enrutamiento 79

Notificar la ruta predeterminada .................................................................... 90

Capítulo 5 Protocolo BGP 109

Capítulo 6 Enrutamiento multicast 137

Capítulo 7 Protocolo IGMP 145

Capítulo 8 Multicast independiente de protocolo (PIM) 173

Capítulo 1 Traducción de direcciones 1

Capítulo 2 Traducción de direcciones de red de origen 15

NAT-Src desde un conjunto de DIP con desplazamiento de direcciones......... 22

Capítulo 3 Traducción de direcciones de red de destino 29

Capítulo 4 Direcciones virtuales y asignadas 65

Capítulo 2 Servidores de autenticación 13

Capítulo 3 Usuarios de autenticación 39

Capítulo 4 Usuarios IKE, XAuth y L2TP 61

Capítulo 1 Sistemas virtuales 1

Capítulo 2 Clasificar el tráfico 9

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

Funciones de red integradas: los protocolos de enrutamiento dinámico

Redundancia: Alta disponibilidad de interfaces, rutas de encaminamiento,

“Contenido” incluye un índice global de todos los volúmenes del manual.

El Apéndice A, “Glosario,” contiene definiciones de todos los términos clave

“Índice” es un índice global de todos los volúmenes del manual.

En el Capítulo 1, “Arquitectura de ScreenOS,” se describen los elementos

En el Capítulo 2, “Zonas,” se explican las zonas de seguridad, las zonas de

En el Capítulo 3, “Interfaces,” se describen las diferentes interfaces físicas,

En el Capítulo 4, “Modos de las interfaces,” se explican los conceptos

En el Capítulo 5, “Bloques para la construcción de directivas,” se explican los

En el Capítulo 6, “Directivas,” se examinan los componentes y las funciones de

En el Capítulo 7, “Asignar tráfico,” se explica cómo gestionar el ancho de

En el Capítulo 8, “Parámetros del sistema,” se describen los conceptos

Organización del volumen xxxv

Capítulo 1, “Administración,” se explican los distintos medios disponibles para

En el Capítulo 2, “Supervisar dispositivos de seguridad,” se explican los

En el Apéndice A, “Archivos MIB para SNMP,” se enumeran y describen

En el Capítulo 1, “Protección de una red,” se resumen las etapas básicas de un

En el Capítulo 2, “Disuasión de reconocimiento,” se describen las opciones

En el Capítulo 3, “Defensas contra los ataques de denegación de servicio

En el Capítulo 4, “Supervisión y filtrado de contenidos,” se describe cómo

En el Capítulo 5, “Deep Inspection,” se describe cómo configurar el dispositivo

En el Capítulo 6, “Atributos de los paquetes sospechosos,” se explican una serie

En el Apéndice A, “Contextos para las firmas definidas por el usuario,” se

xxxvi Organización del volumen

En el Capítulo 1, “Seguridad del protocolo de Internet,” se ofrece información

En el Capítulo 2, “Criptografía de claves públicas,” se explica cómo obtener y

El Capítulo 3, “Directivas de red privada virtual,” contiene información útil para

El Capítulo 4, “Redes privadas virtuales de punto a punto,” ofrece numerosos

El Capítulo 5, “Redes privadas virtuales de acceso telefónico,” ofrece

El Capítulo 6, “Protocolo de encapsulamiento de la capa 2 (L2TP),” explica el

El Capítulo 7, “Funciones avanzadas de redes privadas virtuales,” contiene

En “Puerta de enlace en la capa de aplicación H.323” se describe el protocolo

“Puerta de enlace de la capa de aplicación del protocolo de inicio de sesión”

“Puerta de enlace en la capa de aplicación del Protocolo de control de la puerta

Organización del volumen xxxvii

El Capítulo 1, “Enrutamiento estático,” describe la tabla de enrutamiento de

El Capítulo 2, “Enrutamiento,” explica cómo configurar los enrutadores

El Capítulo 3, “Protocolo OSPF,” describe cómo configurar el protocolo de

El Capítulo 4, “Protocolo de información de enrutamiento,” describe cómo

El Capítulo 5, “Protocolo BGP,” describe cómo configurar el protocolo de

El Capítulo 6, “Enrutamiento multicast,” presenta los conceptos básicos sobre

El Capítulo 7, “Protocolo IGMP,” describe cómo configurar el protocolo de

El Capítulo 8, “Multicast independiente de protocolo (PIM),” describe cómo

El Capítulo 1, “Traducción de direcciones,” proporciona una vista general de

El Capítulo 2, “Traducción de direcciones de red de origen,” describe NAT-src, la

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