Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Descripción general de ALG

Descripciones de ALG

En este tema se describen las puertas de enlace de la capa de aplicación (ALG) compatibles con Junos OS. La compatibilidad de ALG incluye la administración de agujeros de alfiler y relaciones padre-hijo para los ALG compatibles.

ALG compatibles

En la tabla 1 se enumeran los ALG compatibles con Junos OS. Para obtener información acerca de qué ALG son compatibles con MS-DPC, MS-MPC y MS-MIC, consulte ALG disponibles para TDR con reconocimiento de direcciones de Junos OS.

Tabla 1: ALG compatibles con Junos OS

ALG compatibles

v4 - v4

v6 - v4

v6 - v6

DS-Lite (la compatibilidad con ALG con DS-lite en MS-MPC y MS-MIC comienza en Junos OS versión 18.1R1)

TCP ALG básico

UPD ALG básico

ARRANQUE

No

No

No

Servicios RPC de DCE

No

No

No

DNS

No

FTP

Sí (a partir de Junos OS versión 14.1R1)

No

RAS de guardián

Sí (a partir de la versión 17.1R1 de Junos OS)

Sí (a partir de la versión 17.2R1 de Junos OS)

No

No

H323

Sí (a partir de la versión 17.2R1 de Junos OS)

No

No

ICMP

ALG IKE (a partir de Junos OS versión 14.2R7, 15.1R5, 16.1R2 y 17.1R1)

No

No

IIOP

No

No

No

IP

No

No

No

NETBIOS

No

No

No

NETSHOW

No

No

No

PPTP

Sí (a partir de Junos OS versión 14.1R1)

No

REALAUDIO

No

No

No

Sun RPC y RPC Servicios de mapas de puertos

No

No

No

RTSP

Sí (a partir de Junos OS versión 14.1R1)

No

SIP

Sí (a partir de Junos OS versión 14.1R1)

No

SIP compatible con DS-Lite en MS-MPC y MS-MIC a partir de Junos OS versión 18.2R1.

SNMP

No

No

No

SQLNET

No

No

No

TFTP

Sí (a partir de Junos OS versión 14.1R1)

No

Traceroute

No

Servicio de shell remoto de Unix

No

No

No

WINFrame

No

No

No

Detalles de soporte de ALG

Esta sección incluye detalles sobre los ALG. Incluye lo siguiente:

TCP ALG básico

Este ALG realiza una comprobación básica de la cordura en los paquetes TCP. Si encuentra errores, genera los siguientes eventos de anomalía y mensajes de registro del sistema:

  • Puerto de origen o destino TCP cero

  • Error en la comprobación de la longitud del encabezado TCP

  • Número de secuencia TCP cero y no se han establecido indicadores

  • Se establecen el número de secuencia TCP cero y los indicadores FIN/PSH/RST

  • TCP FIN/RST o SYN(URG|FIN|RST)

TCP ALG realiza los pasos siguientes:

  1. Cuando el enrutador recibe un paquete SYN, el ALG crea flujos TCP hacia adelante e inverso y los agrupa en una conversación. Realiza un seguimiento del apretón de manos de tres vías TCP.

  2. El mecanismo de defensa SYN rastrea el estado de establecimiento de la conexión TCP. Espera que la sesión TCP se establezca en un intervalo de tiempo pequeño (actualmente 4 segundos). Si el apretón de manos de tres vías TCP no se establece en ese período, la sesión finaliza.

  3. Un mecanismo de keepalive detecta sesiones TCP con puntos de conexión que no responden.

  4. Los errores de ICMP solo se permiten cuando un flujo coincide con la información del selector especificada en los datos del ICMP.

UDP ALG básico

Este ALG realiza una comprobación básica de la cordura en los encabezados UDP. Si encuentra errores, genera los siguientes eventos de anomalía y mensajes de registro del sistema:

  • Puerto de origen o destino UDP 0

  • Error en la comprobación de la longitud del encabezado UDP

El ALG UDP realiza los pasos siguientes:

  1. Cuando recibe el primer paquete, el ALG crea flujos bidireccionales para aceptar el tráfico de la sesión UDP directa e inversa.

  2. Si la sesión está inactiva durante más tiempo que el máximo permitido (el valor predeterminado es de 30 segundos), se eliminarán los flujos.

  3. Los errores de ICMP solo se permiten cuando un flujo coincide con la información del selector especificada en los datos del ICMP.

ARRANQUE

El cliente del protocolo de arranque (BOOTP) recupera su información de red de un servidor a través de la red. Envía un mensaje de difusión general para solicitar la información, que es devuelta por el servidor BOOTP. Para obtener la especificación del protocolo, consulte ftp://ftp.isi.edu/in-notes/rfc951.txt.

La compatibilidad con firewall de estado requiere que configure BOOTP ALG en el puerto de servidor UDP 67 y el puerto de cliente 68. Si el cliente envía un mensaje de difusión, debe configurar la dirección de difusión en la from instrucción de la regla de servicio. La traducción de direcciones de red (TDR) no se realiza en el tráfico de BOOTP, incluso si la regla de TDR coincide con el tráfico. Si la función de relé BOOTP está activada en el enrutador, se supone que el servidor BOOTP remoto asigna direcciones para los clientes enmascarados por la traducción TDR.

Servicios RPC de DCE

Los servicios de llamada de procedimiento remoto (RPC) del entorno informático distribuido (DCE) son utilizados principalmente por las aplicaciones de Microsoft. El ALG utiliza el conocido puerto TCP 135 para los servicios de asignación de puertos y utiliza el identificador único universal (UUID) en lugar del número de programa para identificar los protocolos. El principal RPC DCE basado en aplicaciones es el protocolo Microsoft Exchange.

La compatibilidad con firewalls con estado y servicios TDR requiere que configure el ALG de asignación de puerto RPC DCE en el puerto TCP 135. El ALG de RPC de DCE utiliza el protocolo TCP con UUID específicos de la aplicación.

DNS

El Sistema de nombres de dominio (DNS), que normalmente se ejecuta en el puerto 53, maneja los datos asociados con la localización y traducción de nombres de dominio a direcciones IP. El ALG de DNS de la serie MX supervisa los paquetes de consulta y respuesta de DNS, y admite el tráfico DNS UDP y TCP de forma independiente. El ALG de DNS no admite traducciones de carga útil para TDR, pero un operador puede usarlo para eliminar de manera eficiente las sesiones de DNS de firewall con estado o TDR de la memoria después de que el servidor DNS envíe su respuesta. El ALG DNS cierra la sesión solo cuando se recibe una respuesta o se alcanza un tiempo de espera de inactividad.

Puede haber problemas con el tráfico DNS TCP cuando se usa TCP-DNS-ALG si el tráfico DNS no es solo del tipo de solicitud y respuesta estándar. Por ejemplo, TCP-DNS-ALG podría interrumpir la comunicación DNS de servidor a servidor que utiliza TCP, como la replicación DNS o las transferencias de zona. Este tipo de tráfico puede ser interrumpido por los complementos de firewall de estado o TDR porque TCP-DNS-ALG cierra la sesión después de que se complete el apretón de manos TCP y después de que cada servidor haya enviado un paquete al otro. En estos casos, no utilice TCP-DNS-ALG.

Nota:

El TCP-DNS-ALG no es compatible con las tarjetas de servicio MS-CPC.

FTP

FTP es el protocolo de transferencia de archivos especificado en RFC 959. Además de la conexión de control principal, también se realizan conexiones de datos para cualquier transferencia de datos entre el cliente y el servidor; y el host, el puerto y la dirección se negocian a través del canal de control.

Para FTP en modo no pasivo, el servicio de firewall con estado de Junos OS analiza los datos de la aplicación de cliente a servidor para el comando PORT, el cual proporciona la dirección IP y el número de puerto al que se conecta el servidor. Para FTP en modo pasivo, el servicio de firewall con estado de Junos OS analiza los datos de la aplicación de cliente a servidor para el comando PASV y, luego, analiza las respuestas de servidor a cliente en busca de la respuesta 227, que contiene la dirección IP y el número de puerto a los que se conecta el cliente.

Hay una complicación adicional: FTP representa estas direcciones y números de puerto en ASCII. Como resultado, cuando se reescriben direcciones y puertos, el número de secuencia TCP puede cambiar y, a partir de entonces, el servicio TDR debe mantener esta diferencia en los números SEQ y ACK mediante la realización de la secuencia TDR en todos los paquetes posteriores.

La compatibilidad con firewalls con estado y servicios TDR requiere que configure FTP ALG en el puerto TCP 21 para habilitar el protocolo de control FTP. El ALG realiza las siguientes tareas:

  • Asigna automáticamente puertos de datos y permisos de firewall para una conexión de datos dinámica

  • Crea flujos para la conexión de datos negociada dinámicamente

  • Supervisa la conexión de control en modo activo y pasivo

  • Reescribe los paquetes de control con la dirección TDR adecuada y la información del puerto

En MS-MPC, MS-MIC, para que el FTP pasivo funcione correctamente sin la puerta de enlace de capa de aplicación (ALG) FTP habilitada (si no especifica la application junos-ftp instrucción en los niveles de [edit services stateful-firewall rule rule-name term term-name from] jerarquía y los [edit services nat rule rule-name term term-name from] niveles), debe habilitar la funcionalidad de emparejamiento de agrupación de direcciones (APP) habilitada (incluyendo la address-pooling instrucción en el nivel de [edit services nat rule rule-name term term-name then translated] jerarquía). Esta configuración hace que las sesiones FTP de datos y de control reciban la misma dirección TDR.

RAS de guardián

A partir de la versión 17.1R1 de Junos OS, el ALG de registro, administración y estado de gatekeeper (RAS) permite la compatibilidad completa del modo gatekeeper para llamadas H.323. Un punto de conexión se registra en un guardián y solicita su administración. Antes de realizar una llamada, un punto de conexión solicita permiso a su guardián para realizar la llamada. Tanto en la fase de registro como en la de admisión, se utiliza el canal RAS. Utilice el ALG RAS guardián y el ALG H323 en las reglas de firewall de estado IPv4 e IPv6 o las reglas NAPT-44. A partir de la versión 17.2R1 de Junos OS, también se admiten las reglas TDR-64. El conjunto junos-h323-suite de aplicaciones predeterminado de Junos incluye el ALG H323 y el ALG RAS de guardián.

H323

H323 es un conjunto de protocolos de la UIT para aplicaciones de colaboración y conferencias de audio y vídeo. H323 consta de protocolos de señalización de llamada H.225 y protocolo de control H.245 para comunicación de medios. Durante la negociación H.225, los puntos finales crean una llamada intercambiando mensajes de señalización de llamada en el canal de control y negocian un nuevo canal de control para H.245. Se crea una nueva conexión de control para los mensajes H.245. Los mensajes se intercambian en el canal de control H.245 para abrir canales de medios.

El firewall de estado monitorea el canal de control H.225 para abrir el canal de control H.245. Después de crear el canal H.245, el firewall de estado también supervisa este canal en busca de información del canal de medios y permite el tráfico de medios a través del firewall.

El ALG H323 admite TDR de destino estático, de origen estático y dinámico mediante la reescritura de las direcciones y puertos adecuados en los mensajes H.225 y H.245.

Para admitir el modo de guardián para llamadas H.323, utilice el ALG H323 y el ALG de RAS de gatekeeper en las reglas de firewall de estado IPv4 e IPv6 o en las reglas NAPT-44. A partir de la versión 17.2R1 de Junos OS, también se admiten las reglas TDR-64. El conjunto junos-h323-suite de aplicaciones predeterminado de Junos incluye el ALG H323 y el ALG RAS de guardián.

ICMP

El protocolo de mensajes de control de Internet (ICMP) se define en RFC 792. El servicio de firewall con estado de Junos OS permite que los mensajes ICMP se filtren por tipo específico o por valor de código de tipo específico. Los paquetes de error ICMP que carecen de un tipo y código configurados específicamente se comparan con cualquier flujo existente en la dirección opuesta para comprobar la legitimidad del paquete de error. Los paquetes de error ICMP que pasan la coincidencia de filtros están sujetos a traducción TDR.

El ALG ICMP siempre rastrea el tráfico ping con estado utilizando el número de secuencia ICMP. Cada respuesta de eco se reenvía solo si hay una solicitud de eco con el número de secuencia correspondiente. Para cualquier flujo de ping, solo se pueden reenviar 20 solicitudes de eco sin recibir una respuesta de eco. Cuando se configura TDR dinámico, el identificador de paquete PING se traduce para permitir que hosts adicionales en el conjunto de TDR utilicen el mismo identificador.

La compatibilidad con firewalls con estado y servicios TDR requiere que configure el ALG ICMP si se necesita el protocolo. Puede configurar el tipo y el código de ICMP para un filtrado adicional.

IIOP

El protocolo inter-ORB de Internet (IIOP) del servidor de nombres del servidor de aplicaciones de Oracle. Este ALG se utiliza en la arquitectura Common Object Request Broker (CORBA) basada en computación distribuida. Aunque CORBA e IIOP son estándares de grupo de gestión de objetos (OMG), no se asigna ningún puerto fijo para IIOP. Cada proveedor que implementa CORBA elige un puerto. La máquina virtual Java usa el puerto 1975 de forma predeterminada, mientras que ORBIX usa el puerto 3075 de forma predeterminada.

El firewall de estado y TDR requieren que ALG IIOP esté configurado para el puerto TCP 1975 para Java VM IIOP y 3075 para aplicaciones CORBA ORBIX, un marco CORBA de Iona Technologies.

IKE ALG

Antes de la versión 17.4R1 de Junos OS, la traducción de direcciones de red-recorrido (TDR-T) no es compatible con el conjunto de funciones IPsec de Junos VPN Site Secure en los enrutadores de la serie MX. A partir de las versiones 14.2R7, 15.1R5, 16.1R2 y 17.1R1 de Junos OS, el ALG de IKE permite el paso de paquetes IKEv1 e IPsec a través de reglas NAPT-44 y NAT64 entre pares IPsec que no cumplen con TDR-T. Este ALG solo admite el modo de túnel ESP.

Utilice este ALG en las reglas de TDR y especifique el protocolo UDP y el puerto 500.

Este ALG realiza lo siguiente:

  • Realiza un seguimiento de las solicitudes de iniciación de conexión IKEv1 para determinar si se requiere procesamiento TDR.

  • Realiza la traducción de TDR en solicitudes IKEv1 salientes y entrantes, y crea sesiones IKE.

  • Identifica paquetes IPsec relacionados con la sesión IKE establecida y establece una asociación de seguridad entre pares.

  • Realiza la traducción de TDR en paquetes IPsec.

IP

El ALG IP se utiliza solo para crear flujos unidireccionales. En el caso del tráfico TCP, no comprueba el proceso de apretón de manos de 3 vías. Este ALG es útil en el caso de conjuntos de servicios de firewall con estado, donde permite que el tráfico fluya unidireccionalmente solamente. Cuando se configura junto con match-direction input-output él, permite que el tráfico de retorno fluya a través del firewall de estado también. Los escenarios típicos son TDR estático, TDR de destino o escenarios en los que se espera que el tráfico atraviese el firewall de estado en presencia de enrutamiento asimétrico. El ALG de IP de Junos no está diseñado para usarse con NAPT, lo que hace que el tráfico coincidente se descarte mediante la creación de un flujo de caída.

BIOS de red

Un ALG de NetBIOS traduce las direcciones IP de NetBIOS y los números de puerto cuando se usa TDR.

NetBIOS admite los protocolos de transporte TCP y UDP. La compatibilidad con firewalls con estado y servicios TDR requiere que configure el ALG NetBIOS en los puertos UDP 138 y TCP 139.

NetShow

NetShow, el servidor multimedia de Microsoft, utiliza el protocolo Microsoft ms-streaming. Este protocolo admite varios protocolos de transporte: TCP, UDP y HTTP. El cliente inicia una conexión TCP en el puerto 1755 y envía el comando PORT al servidor. Luego, el servidor inicia UDP en ese puerto al cliente. La compatibilidad con firewalls con estado y servicios TDR requiere que configure el ALG de NetShow en el puerto UDP 1755.

Servicios de ONC RPC

Los servicios RPC de computación de redes abiertas (ONC) funcionan de manera similar a los servicios RCP DCE. Sin embargo, el ALG de RPC de ONC utiliza el puerto TCP/UDP 111 para los servicios de asignación de puertos y utiliza el número de programa para identificar protocolos en lugar del UUID.

La compatibilidad con firewalls con estado y servicios TDR requiere que configure el ALG de asignación de puertos RPC de ONC en el puerto TCP 111. El ALG de RPC de ONC utiliza el protocolo TCP con números de programa específicos de la aplicación.

PPTP

El ALG de protocolo de túnel punto a punto (PPTP) es un ALG basado en TCP. PPTP permite que el protocolo punto a punto (PPP) se tunelice a través de una red IP. PPTP define una arquitectura cliente-servidor, un servidor de red PPTP y un concentrador de acceso PPTP. El ALG PPTP requiere una conexión de control y un túnel de datos. La conexión de control utiliza TCP para establecer y desconectar sesiones PPP, y se ejecuta en el puerto 1723. El túnel de datos transporta tráfico PPP en paquetes encapsulados de enrutamiento genérico (GRE) que se transportan a través de IP.

Audio real

Protocolo PNA de Real Networks RealVideo no es un servicio separado. Es parte del RealPlayer y lo más probable es que use otro canal para video. Las versiones G2, 7 y 8 de RealPlayer utilizan PNA y RTSP. Para que esta versión funcione, el ALG debe permitir tanto PNA(7070) como RTSP(554). Para los medios, el servidor selecciona entre un rango de puertos UDP (6970 a 7170), o el puerto TCP 7071 o HTTP. El cliente puede configurarse para usar un puerto determinado. Las versiones 4.0 y 5.0 de RealPlayer utilizan los puertos UDP de medios del canal de control 7070 del 6970 al 7170, o el puerto TCP 7071 o HTTP. La versión 3.0 del reproductor RealAudio utiliza medios del canal de control 7070, puertos UDP 6770-7170 o puerto TCP 7071.

Los productos reales utilizan los puertos y rangos de puertos que se muestran en la Tabla 2.

Tabla 2: Uso del puerto del producto RealAudio

Producto real

Uso de puertos

Servidores/reproductores 4.0 y 5.0

Canal de control (bidireccional) en el puerto TCP 7070. Canal de datos del servidor al reproductor en el puerto TCP 7070 o UDP 6970-7170.

Servidores/codificadores 4.0 y 5.0

Canal de control (bidireccional) en el puerto TCP 7070. Canal de datos del codificador o servidor en el puerto TCP 7070.

Servidores/reproductores G2

Canal de control (bidireccional) en el puerto TCP 80, 554, 7070 u 8080. Canal de datos del servidor al reproductor en los puertos TCP 80, 554, 7070, 8080 o UDP 6970-32.000.

Codificadores G2 Server/3.1 y 5.x

Canal de control (bidireccional) en el puerto TCP 7070. Canal de datos del codificador al servidor en el puerto TCP 7070.

Servidor G2/Productor G2

Canal de control (bidireccional) en el puerto TCP 4040. Canal de datos del codificador al servidor en el puerto TCP 4040 y el puerto UDP 6970-32,000.

2 Servidor/Productor G2 (SOLO TCP)

Canal de control (bidireccional) en el puerto TCP 4040 Canal de datos del codificador al servidor en el puerto TCP 4040. Nota: La opción TCP-ONLY está disponible en la versión 6.1 o superior.

Nota:

RealAudio fue el protocolo original de RealPlayers. Las versiones más recientes de RealPlayer usan RTSP. El firewall de estado y TDR requieren que ALG RealAudio se programe en el puerto TCP 7070.

Sun RPC y RPC Portmap Services

El ALG de llamada a procedimiento remoto (RPC) utiliza los puertos conocidos TCP 111 y UDP 111 para la asignación de puertos, que asigna y abre puertos dinámicamente para servicios RPC. El ALG RPC Portmap realiza un seguimiento de las solicitudes de puertos y abre dinámicamente el firewall para estos puertos solicitados. El ALG RPC puede restringir aún más el protocolo RPC especificando los números de programa permitidos.

El ALG incluye los servicios RPC enumerados en el Cuadro 3.

Tabla 3: Servicios RPC compatibles

Nombre

Descripción

Comentarios

rpc-mountd

Demonio de montaje del servidor de archivos de red (NFS); para obtener más información, consulte la página del comando man de UNIX para rpc.mountd(8).

La compatibilidad base es RPC v2 y el servicio de asignación de puertos en el puerto 111 (consulte RFC 1050).

rpc-nfsprog

Se utiliza como parte de NFS. Para obtener más información, consulte RFC 1094. Consulte también RFC1813 para NFS v3.

La compatibilidad base es RPC v2 y el servicio de asignación de puertos en el puerto 111 (consulte RFC 1050).

rpc-nisplus

Network Information Service Plus (NIS+), diseñado para reemplazar a NIS; es un servicio de nomenclatura predeterminado para Sun Solaris y no está relacionado con el antiguo NIS. No se dispone de información sobre el protocolo.

La compatibilidad base es RPC v2 y el servicio de asignación de puertos en el puerto 111 (consulte RFC 1050).

rpc-nlockmgr

Administrador de bloqueo de red.

La compatibilidad base es RPC v2 y el servicio de asignación de puertos en el puerto 111 (consulte RFC 1050). Una vez que se crea la tabla de programa RPC, rpc-nlockmgr el servicio se puede permitir o bloquear según el 100021 del programa RPC.

rpc-pcnfsd

Servidor de estadísticas del kernel. Para obtener más información, consulte las páginas del comando man de UNIX para rstatd y rpc.rstatd.

La compatibilidad base es RPC v2 y el servicio de asignación de puertos en el puerto 111 (consulte RFC 1050). Una vez que se crea la tabla de programa RPC, rpc-rstat el servicio se puede permitir o bloquear según el 150001 del programa RPC.

rpc-rwall

Se utiliza para escribir un mensaje a los usuarios; para obtener más información, consulte la página del comando man de UNIX para rpc.rwalld.

La compatibilidad base es RPC v2 y el servicio de asignación de puertos en el puerto 111 (consulte RFC 1050). Una vez que se crea la tabla de programa RPC, rpc-rwall el servicio se puede permitir o bloquear según el 150008 del programa RPC.

rpc-ypbind

Proceso de vinculación NIS. Para obtener más información, consulte la página del comando man de UNIX para ypbind.

La compatibilidad base es RPC v2 y el servicio de asignación de puertos en el puerto 111 (consulte RFC 1050). Una vez que se crea la tabla de programa RPC, rpc-ypbind el servicio se puede permitir o bloquear según el 100007 del programa RPC.

rpc-yppasswd

Servidor de contraseñas NIS. Para obtener más información, consulte la página del comando man de UNIX para yppasswd.

La compatibilidad base es RPC v2 y el servicio de asignación de puertos en el puerto 111 (consulte RFC 1050). Una vez que se crea la tabla de programa RPC, rpc-yppasswd el servicio se puede permitir o bloquear según el 100009 del programa RPC.

rpc-ypserv

Servidor NIS. Para obtener más información, consulte la página del comando man de UNIX para ypserv.

La compatibilidad base es RPC v2 y el servicio de asignación de puertos en el puerto 111 (consulte RFC 1050). Una vez que se crea la tabla de programa RPC, rpc-ypserv el servicio se puede permitir o bloquear según el 100004 del programa RPC.

rpc-ypupdated

Herramienta de actualización de red.

La compatibilidad base es RPC v2 y el servicio de asignación de puertos en el puerto 111 (consulte RFC 1050). Una vez que se crea la tabla de programa RPC, rpc-ypupdated el servicio se puede permitir o bloquear según el 100028 del programa RPC.

rpc-ypxfrd

Servidor de transferencia de mapas NIS. Para obtener más información, consulte la página del comando man de UNIX para rpc.ypxfrd.

La compatibilidad base es RPC v2 y el servicio de asignación de puertos en el puerto 111 (consulte RFC 1050). Una vez que se crea la tabla de programa RPC, rpc-ypxfrd el servicio se puede permitir o bloquear según el 100069 del programa RPC.

La compatibilidad con firewalls con estado y servicios TDR que utilizan la asignación de puertos requiere que configure el ALG de asignación de puertos RPC en el puerto de destino 111 de TCP/UDP y el ALG RPC para TCP y UDP. Puede especificar uno o varios rpc-program-number valores para restringir aún más los protocolos RPC permitidos.

RTSP

El protocolo de transmisión en tiempo real (RTSP) controla la entrega de datos con propiedades en tiempo real, como audio y video. Las transmisiones controladas por RTSP pueden usar RTP, pero no es obligatorio. Los medios se pueden transmitir en la misma secuencia de control RTSP. Este es un protocolo basado en texto similar a HTTP, pero el cliente y el servidor mantienen la información de la sesión. Una sesión se establece mediante el mensaje SETUP y finaliza mediante el mensaje TEARDOWN. El transporte (el protocolo de medios, la dirección y los números de puerto) se negocia en la configuración y la configuración-respuesta.

La compatibilidad con firewalls con estado y servicios TDR requiere que configure el ALG RTSP para el puerto TCP 554.

El ALG supervisa la conexión de control, abre flujos dinámicamente para flujos de medios (RTP/RTSP) y realiza reescrituras de direcciones y puertos TDR.

SIP

El protocolo de inicio de sesión (SIP) es un protocolo de capa de aplicación que puede establecer, mantener y terminar sesiones de medios. Es un protocolo de señalización de voz sobre IP (VoIP) ampliamente utilizado. El ALG de SIP monitorea el tráfico SIP y crea y administra dinámicamente agujeros en las rutas de señalización y medios. El ALG solo permite paquetes con los permisos correctos. El ALG SIP también realiza las siguientes funciones:

  • Administra las relaciones entre las sesiones de padres e hijos.

  • Hace cumplir las políticas de seguridad.

  • Gestiona los agujeros para el tráfico de VoIP.

El ALG SIP admite las siguientes características:

  • Firewall de estado

  • TDR de fuente estática

  • TDR de origen de solo dirección dinámica

  • Traducción de puerto de dirección de red (NAPT)

Nota:

Las sesiones SIP están limitadas a 12 horas (720 minutos) para el procesamiento de TDR en las tarjetas de interfaz MS-MIC y MS-MPC. Las sesiones SIP en MS-CPC no tienen límite de tiempo.

SNMP

SNMP es un protocolo de comunicación para administrar redes TCP/IP, que incluye dispositivos de red individuales y dispositivos agregados. El protocolo se define mediante RFC 1157. SNMP se ejecuta sobre UDP.

El servicio de firewall con estado de Junos OS implementa el ALG SNMP para inspeccionar el tipo SNMP. SNMP no aplica el flujo con estado. Cada tipo de SNMP debe habilitarse específicamente. La compatibilidad completa con SNMP de los servicios de firewall con estado requiere que configure el ALG SNMP en el puerto UDP 161. Esto habilita el SNMP get y get-next los comandos, así como su tráfico de respuesta en la dirección inversa: El puerto UDP 161 habilita el comando SNMP get-response . Si se permiten capturas SNMP, puede configurarlas en el puerto UDP 162, habilitando el comando SNMP trap .

SQLNet

Los servidores Oracle SQL utilizan el protocolo SQLNet para ejecutar comandos SQL desde los clientes, incluidos el equilibrio de carga y los servicios específicos de la aplicación.

La compatibilidad con firewalls con estado y servicios TDR requiere la configuración de SQLNet ALG para el puerto TCP 1521.

El ALG monitorea los paquetes de control, abre flujos dinámicamente para el tráfico de datos y realiza reescrituras de direcciones y puertos TDR.

TFTP

El protocolo de transferencia de archivos trivial (TFTP) se especifica en RFC 1350. Las solicitudes TFTP iniciales se envían al puerto de destino UDP 69. Se pueden crear flujos adicionales para obtener o colocar archivos individuales. La compatibilidad con firewalls con estado y servicios TDR requiere que configure el ALG TFTP para el puerto de destino UDP 69.

Traceroute

Traceroute es una herramienta para mostrar la ruta que los paquetes toman a un host de red. Utiliza el campo IP de tiempo de vida (TTL) para activar mensajes de tiempo excedido del ICMP desde enrutadores o puertas de enlace. Envía datagramas UDP a puertos de destino que se cree que no están en uso; Los puertos de destino se numeran mediante la fórmula: + nsaltos – 1. El puerto base predeterminado es 33434. Para admitir traceroute a través del firewall, se deben pasar dos tipos de tráfico:

  1. Paquetes de sonda UDP (puerto de destino UDP > 33000, IP TTL < 30)

  2. Paquetes de respuesta ICMP (tipo ICMP excedido en el tiempo)

Cuando se aplica TDR, también se deben cambiar la dirección IP y el puerto dentro del paquete de error ICMP.

La compatibilidad con firewalls con estado y servicios TDR requiere que configure el ALG de Traceroute para el puerto de destino UDP 33434 a 33450. Además, puede configurar el umbral TTL para evitar ataques de inundación UDP con valores TTL grandes.

Servicios de shells remotos de UNIX

Tres protocolos forman la base de los servicios de shells remotos de UNIX:

  • Ejecutivo: ejecución remota de comandos; Permite a un usuario del sistema cliente ejecutar un comando en el sistema remoto. El primer comando del cliente (rcmd) al servidor (rshd) utiliza el conocido puerto TCP 512. Se puede abrir una segunda conexión TCP a petición de rcmd. El número de puerto de cliente para la segunda conexión se envía al servidor como una cadena ASCII.

  • Iniciar sesión: más conocido como rlogin; utiliza el conocido puerto TCP 513. Para obtener más información, consulte RFC 1282. No se requiere ningún procesamiento especial de firewall.

  • Shell: ejecución remota de comandos; Permite a un usuario del sistema cliente ejecutar un comando en el sistema remoto. El primer comando del cliente (rcmd) al servidor (rshd) utiliza el conocido puerto TCP 514. Se puede abrir una segunda conexión TCP a petición de rcmd. El número de puerto de cliente para la segunda conexión se envía al servidor como una cadena ASCII.

La compatibilidad con servicios de firewall con estado requiere que configure Exec ALG en el puerto TCP 512, Login ALG en el puerto TCP 513 y Shell ALG en el puerto TCP 514. Los servicios de shell remoto de TDR requieren que cualquier puerto de origen dinámico asignado esté dentro del intervalo de puertos 512 a 1023. Si configura un grupo TDR, este intervalo de puertos está reservado exclusivamente para aplicaciones de shell remotas.

WinFrame

El software de servidor de aplicaciones WinFrame brinda acceso a prácticamente cualquier aplicación de Windows, a través de cualquier tipo de conexión de red a cualquier tipo de cliente.

Este protocolo lo utilizan principalmente las aplicaciones Citrix Windows.

El firewall de estado y TDR requieren que el Winframe ALG esté configurado en el puerto de destino TCP 1494 y el puerto UDP 1604.

Valores predeterminados de Juniper Networks

Junos OS proporciona un grupo de configuración oculto predeterminado llamado junos-defaults que se aplica automáticamente a la configuración del enrutador. El junos-defaults grupo contiene instrucciones preconfiguradas que contienen valores predefinidos para aplicaciones comunes. Se debe hacer referencia a algunas de las instrucciones para que surtan efecto, como aplicaciones como FTP o Telnet. Otras instrucciones se aplican automáticamente, como la configuración del terminal. Todas las instrucciones preconfiguradas comienzan con el nombre junos-reservado .

Nota:

Puede anular los valores de configuración predeterminados de Junos OS, pero no puede eliminarlos ni editarlos. Si elimina una configuración, los valores predeterminados vuelven cuando se agrega una nueva configuración.

No puede utilizar la apply-groups instrucción con el grupo predeterminados de Junos OS.

Para ver el conjunto completo de instrucciones preestablecidas disponibles del grupo predeterminado de Junos OS, emita el comando de modo de show groups junos-defaults configuración. En el siguiente ejemplo, se muestra la lista de grupos predeterminados de Junos OS que utilizan protocolos de aplicación (ALG):

Para hacer referencia a las instrucciones disponibles en el junos-defaults grupo, incluya la instrucción seleccionada junos-default-name en el nivel de jerarquía aplicable. Para configurar protocolos de aplicación, consulte Configuración de propiedades de aplicación; para obtener más información sobre un protocolo específico, consulte Descripciones de ALG.

Ejemplos: Referencia a la instrucción Preset del grupo predeterminado de Junos OS

El siguiente ejemplo es una instrucción preestablecida de los grupos predeterminados de Junos OS que está disponible para FTP en un firewall con estado:

Para hacer referencia a una instrucción predeterminada de Junos OS preestablecida de los grupos predeterminados de Junos OS, incluya la junos-default-name instrucción en el nivel de jerarquía aplicable. Por ejemplo, para hacer referencia a la instrucción predeterminada de Junos OS para FTP en un firewall con estado, incluya la junos-ftp instrucción en el nivel de [edit services stateful-firewall rule rule-name term term-name from applications] jerarquía.

En el siguiente ejemplo, se muestra la configuración del ALG IP predeterminado de Junos:

Si configura el ALG IP en la regla de firewall con estado, cualquier tráfico IP coincide, pero cuando cualquier otra aplicación más específica coincide con el mismo tráfico, el ALG IP no coincide. Por ejemplo, en la siguiente configuración, se configuran tanto ICMP ALG como IP ALG, pero el tráfico coincide con los paquetes ICMP, ya que es la coincidencia más específica.

ALG ICMP, ping y traceroute para MS-MIC y MS-MPC

A partir de Junos OS versión 14.2, los paquetes de proveedores de extensiones de Junos OS que están preinstalados y preconfigurados en MS-MIC y MS-MPC ofrecen soporte para ping, traceroute y ALG ICMP de una manera consistente que es idéntica al soporte que proporciona el servicio uKernel. Se establece paridad y uniformidad de soporte para estos ALG entre MS-MIC / MS-MPC y el servicio uKernel. Hasta la versión 14.1 de Junos OS, los ALG ICMP, los ALG ping y los ALG traceroute no eran completamente compatibles con enrutadores de la serie MX con MS-MIC y MS-MPC en comparación con el servicio uKernel que habilita la traducción de direcciones de red (TDR) con firewall de estado (SFW) en la PIC de uKernel. Había soporte disponible para el manejo de paquetes de respuesta a errores ICMP que coincidan con cualquier flujo existente en la dirección opuesta y el procesamiento TDR de paquetes ICMP con el procesamiento TDR de paquetes ping.

En enrutadores de la serie MX con MS-MIC y MS-MPC, se admite el seguimiento de estados de tráfico ping utilizando completamente los números de secuencia ICMP (por ejemplo, reenviar una respuesta de eco solo si se identifica la solicitud de eco con el número de secuencia correspondiente). La puerta de enlace de la capa de aplicación (ALG) del ICMP se ha mejorado para proporcionar información de registro detallada. Además, los ALG de traceroute permiten que los paquetes de sondeo UDP se procesen con un número de puerto de destino UDP mayor que 33000 y el tiempo de vida (TTL) de IP es inferior a 30 segundos. Los ALG de traceroute permiten que se procesen paquetes de respuesta ICMP para los que se excede el tiempo del tipo ICMP y admitan un valor de umbral TTL de traceroute, que controla el nivel aceptable de penetración de red para el enrutamiento de seguimiento.

Puede configurar los mensajes ICMP y ping con las application junos-icmp-allinstrucciones , application junos-icmp-pingy application icmp-code en los [edit services stateful-firewall rule rule-name term term-name from] [edit services nat rule rule-name term term-name from] niveles de jerarquía para definir la condición de coincidencia para el firewall con estado y las reglas TDR. Hasta Junos OS versión 14.1, no existía una restricción o validación en las aplicaciones que pudiera definir para mensajes ICMP. Las MS-MIC y MS-MPC funcionan de la misma manera que el servicio uKernel, lo que hace que el tráfico de ping se rastree con estado utilizando los números de secuencia ICMP (una respuesta de eco solo se reenvía si la solicitud de eco con el número de secuencia correspondiente coincide). Además, las MS-MIC y MS-MPC imponen un límite a las solicitudes de ping pendientes y eliminan las solicitudes de ping posteriores cuando se alcanza el límite.

De manera similar, para los mensajes de traceroute, puede configurar las application junos-traceroute instrucciones y application junos-traceroute-ttl-1 en los niveles de [edit services stateful-firewall rule rule-name term term-name from] jerarquía para [edit services nat rule rule-name term term-name from] definir la condición de coincidencia de los mensajes de traceroute para el firewall de estado y las reglas de TDR.

Los mensajes Traceroute e ICMP son compatibles con paquetes IPv4 e IPv6. Para que la funcionalidad traceroute funcione, solo necesita asegurarse de que las aplicaciones definidas por el usuario funcionan según lo esperado con el período de tiempo de espera de inactividad y que los valores de umbral TTL están configurados para ser el mismo período de tiempo que se configuró mediante la session-timeout seconds instrucción en el [edit services application-identification application application-name] nivel de jerarquía. Durante el registro de mensajes ICMP, la información de ALG para las utilidades ping e ICMP se muestra en la salida de los comandos show relevantes, como show sessions y show conversations, de la misma manera que se muestra para el registro de uKernel.

Tabla de historial de cambios

La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.

Lanzamiento
Descripción
18.2R1
SIP compatible con DS-Lite en MS-MPC y MS-MIC a partir de Junos OS versión 18.2R1.
18.1R1
El soporte para ALG con DS-lite en MS-MPC y MS-MIC comienza en Junos OS versión 18.1R1
17.2R1
(A partir de la versión 17.2R1 de Junos OS)
17.2R1
(A partir de la versión 17.2R1 de Junos OS)
17.2R1
A partir de la versión 17.2R1 de Junos OS, también se admiten las reglas TDR-64.
17.2R1
A partir de la versión 17.2R1 de Junos OS, también se admiten las reglas TDR-64.
17.1R1
(A partir de la versión 17.1R1 de Junos OS)
17.1R1
A partir de la versión 17.1R1 de Junos OS, el ALG de registro, administración y estado de gatekeeper (RAS) permite la compatibilidad completa del modo gatekeeper para llamadas H.323.
14.2R7
ALG IKE (a partir de Junos OS versión 14.2R7, 15.1R5, 16.1R2 y 17.1R1)
14.2R7
A partir de las versiones 14.2R7, 15.1R5, 16.1R2 y 17.1R1 de Junos OS, el ALG de IKE permite el paso de paquetes IKEv1 e IPsec a través de reglas NAPT-44 y NAT64 entre pares IPsec que no cumplen con TDR-T.