En informática , ciertos protocolos , por diseño, no pasan cortafuegos o tienen dificultades . Pueden causar problemas de filtrado o traducción de direcciones de red (NAT) .
Para solucionar este problema, la mayoría de los cortafuegos deben implementar mecanismos muy complejos.
Este problema es tan importante que existen varios RFC, incluido el RFC 3235, que describen cómo diseñar un protocolo compatible con firewalls.
Ciertos protocolos intercambian a nivel de aplicación (capa 7 del modelo OSI: FTP, etc.) direcciones IP que solo deben circular a nivel de red (capa 3: IP ) o puertos que solo deben circular a nivel de transporte (capa 4: TCP / UDP ). Estos intercambios violan el principio de separación de capas de red (al mismo tiempo violan RFC 3235 ).
Los ejemplos más conocidos son FTP en modo activo (el cliente ejecuta el comando PORT: proporciona su IP local y el puerto al que debe conectarse el servidor para intercambiar datos) y FTP en modo pasivo (el cliente ejecuta el comando PASV: el servidor responde proporcionando su IP local y el puerto al que el cliente debe conectarse para intercambiar datos).
Los datos intercambiados a nivel de la aplicación no se traducen. Como estos datos intercambiados no son válidos después de pasar por el enrutador NAT, no pueden ser utilizados por la máquina de destino.
Por esta razón, estos protocolos apenas pasan, si es que lo hacen, las reglas de NAT .
Algunos protocolos utilizan rangos de puertos grandes. De hecho, deciden los puertos de forma dinámica, intercambian los nuevos puertos a nivel de la aplicación (consulte la sección anterior) y luego abren nuevas conexiones a estos puertos.
Por tanto, cuando un administrador define la política de filtrado de su cortafuegos, tiene grandes dificultades para especificar los puertos en cuestión. En el peor de los casos, está obligado a abrir una gran cantidad de puertos, permitiendo, al mismo tiempo, otros protocolos distintos a los deseados.
Por ejemplo, el protocolo TFTP intercambia números de puerto abiertos en la máquina cliente. El servidor TFTP lo usa para abrir datagramas al cliente. Estos datagramas tienen un puerto de origen y un puerto de destino no especificados. Entonces, para pasar TFTP, debe pasar casi todo el UDP entre las dos máquinas.
En la definición de un protocolo, quien inicia la comunicación es el cliente, quien está en espera es el servidor. La mayoría de los protocolos se componen de una o más conexiones ( socket o datagrama ) del cliente al servidor, la primera se llama maestro . Pero algunos protocolos contienen conexiones secundarias iniciadas desde el servidor al cliente (ejemplo de FTP en modo activo).
La única solución para filtrar y "burlarse" de un protocolo de "contenido sucio" es realizar una inspección de la aplicación . La mayoría de los cortafuegos pueden inspeccionar un número limitado de aplicaciones. Cada aplicación es administrada por un módulo diferente que se puede activar o desactivar para mejorar el rendimiento o en caso de un error publicado. La terminología para el concepto de módulo de inspección es diferente para cada tipo de firewall:
Por razones de seguridad, BSD software cortafuegos ( IPFIREWALL , IPFilter y filtro de paquetes ) no hacen inspección de servicio en el kernel . De hecho, como la inspección del servicio es compleja, cualquier error podría permitir que la máquina se hiciera cargo. Para realizar la inspección del servicio es necesario en este caso instalar un proxy que, a su vez, se ejecuta en el espacio de usuario .
Los módulos de inspección de aplicaciones tienen dos acciones que corrigen ambos problemas:
Por ejemplo, basta con autorizar TCP al puerto 21 para autorizar FTP, autorizándose automáticamente el socket al puerto 20. Esto permite filtrar los protocolos infractores sin permitir grandes intervalos de puertos.
A continuación, se muestran algunos protocolos de red que son difíciles de filtrar por un firewall:
La verdadera solución es diseñar el protocolo de acuerdo con una lista completa de reglas. El RFC 3235 " Network Address Translator (NAT) - Directrices de diseño de aplicaciones amigables " describe cómo desarrollar un protocolo a través de NAT sin dificultad.