ASPF

100 0 0 0

Después de entender las políticas de seguridad, podrías pensar que las políticas de seguridad son configuradas de una vez y para defender de todas las amenazas. Sin embargo, algunos protocolos cambian de manera impredecible, tal como FTP. Los paquetes FTP puedes sobre escribir políticas de seguridad durante el intercambio. En este caso, las políticas de seguridad no son suficiente para controlar el reenvío de paquetes y llamar a un ayudante misterioso para ayudar.

Entonces, uso FTP como ejemplo para desvelar el ayudante misterioso.

1 Ayudando a los Paquetes FTP atravesar Firewalls

Primero, uso el eNSP para simular un cliente FTP para acceder a un servior FTP, como se muestra en la figura 1-1. El cliente y el servidor FTP conectan directamente a un firewall. El cliente FTP reside en la zona Trust, del cual el servidor FTP reside en la zona Untrust.

 

Figura 1-1 Red para un cliente FTP acceder a un servidor FTP.


104831nabena8aztr8nzah.png


¿Cómo debería configurar una política de seguridad si quiero que el cliente FTP acceda al servidor FTP?  Puede que digas: “Es fácil. Configurar una política de seguridad para permitir los paquetes FTP de 192.168.0.1 en la zona Trust para 172.16.0.1 en la zona Untrust”

104856z8o767v1p7boq461.png

Después de la configuración, usa el cliente FTP para acceder al servidor FTP en el eNSP. El acceso FALLA. Chequemos la configuración. Puedes ver que una “policy 1” emparejó, indicando que la configuración tomó efecto.

104900ydtaiyyzd6jhdaad.png

 

Veamos la tabla de sesión. Puedes ver que una sesión ha sido establecida en el firewall.

104904qnjadm9j0jnjkd0c.png

Todo parece estar bien. Bueno, ¿Por qué falló el acceso?

Veamos la característica particular de FTP. FTP es un típico protocolo multi-canal. El cliente y el servidor FTP establecen dos conexiones en el medio, llamémoslo, conexiones de control y datos. La conexión de control comunica comandos FTP y parámetros incluyendo la información necesaria para establecer la conexión de datos. La conexión de datos obtiene directorios y transfiere datos.

FTP trabaja ya sea en modo activo (PORT) o pasivo (PASV), determinado por el modo de iniciación de conexión de datos. En modo activo, el servidor FTP inicia una conexión de datos al cliente FTP. En modo pasivo, el servidor FTP recibe la conexión de datos iniciada desde el cliente FTP.

El modo de trabajo puede ser configurado en el cliente FTP. Este ejemplo usa el modo activo como se muestra en la figura 1-2.

Figura 1-2 Configuración de modo de trabajo en el cliente FTP.



104911dddcavvvwkonlldw.png


Veamos el proceso interactivo del FTP en modo activo, como se muestra en la Figura 1-3.

 

 

Figura1-3 Proceso interactivo de FTP en modo activo.


104924szco6svjyh9obd1p.png


El proceso se describe de la siguiente manera:

1.       El cliente FTP usa un puerto xxxx al azar para iniciar una solicitud de conexión de contron al puerto 21 del servidor FTP.

2.       El cliente FTP usa el comando PORT  para negociar el número de puerto con el servidor para la conexión de datos. Se obtiene el puerto yyyy.

3.       El servidor FTP inicia una solicitud de conexión de datos para el puerto yyyy del cliente FTP.

4.       El servidor FTP manda información al cliente después que la conexión de datos es establecida.

En el ejemplo anterior, hemos configurado solo una política de seguridad  para permitir al cliente FTP acceder al servidor FTP. Eso es, el control de conexión fue establecido. Cuando el firewall recibió el paquete del servidor FTP al puerto yyyy del cliente FTP, el firewall consideró el paquete una nueva conexión, no el paquete subsecuente de la conexión previa. Para permitir que el paquete llegue al cliente FTP tenemos que configurar otra política de seguridad.

¿Cómo resolver este problema? ¿Está bien si configuramos una política de seguridad para paquetes del servidor FTP al cliente FTP? Pero hay otro problema. El puerto usado para la conexión de datos está negociado por el cliente  y servidor y por lo tanto es al azar. Así que tenemos que habilitar todos los puertos, y esta operación trae riesgos de seguridad para el cliente FTP. Sería perfecto si el firewall pudiera recordad el puerto y automáticamente configurar una política de seguridad para permitir los pasar los paquetes del servidor FTP al cliente FTP.

Afortunadamente, los diseñadores del firewall tienen considerado este problema e introdujeron un ayudante misterioso, Aplication Specific Packet Filter (ASPF). Como su nombre lo indica, ASPF trabaja en la capa de aplicación. Su principio de trabajo es revisar la información de la capa de aplicación de paquetes y records la información clave in la información clave, para que los paquetes que no están claramente definidos para pasar en las políticas de seguridad pueden ser propiamente reenviados.

Las entradas que registran los datos clave de la capa de aplicación se denominan entradas del mapa del servidor. Una vez que un paquete coincide con una entrada del mapa del servidor, ya no está controlado *****inguna política de seguridad. Parece habilitar un "canal invisible" en el firewall. Por supuesto, este canal no está habilitado arbitrariamente. En cambio, el firewall permite la existencia de dicho canal solo después de analizar la información de paquetes de la aplicación para predecir el comportamiento de los paquetes subsiguientes.

¿Cuál es la diferencia entre el mapa del servidor y la tabla de sesión? Primero, la tabla de sesión registra el estado de conexión de las partes comunicantes. Después de generar una sesión para el primer paquete de una conexión, el firewall envía directamente los paquetes subsiguientes de la sesión basados en esta sesión, y los paquetes ya no están controlados por políticas de seguridad. El mapa del servidor registra la información obtenida al analizar los paquetes para las conexiones existentes. Esta información indica las características del paquete, según la cual el firewall predice el comportamiento del paquete.

En segundo lugar, después de recibir un paquete, el firewall comprueba si el paquete coincide con la tabla de la sesión. Si es así, el firewall envía directamente el paquete. Si no, el firewall comprueba si el paquete coincide con el mapa del servidor. Si el paquete coincide con el mapa del servidor, ya no está controlado por las políticas de seguridad. Ciertamente, el firewall generará una sesión para el paquete.

 

Tanto el mapa del servidor como la tabla de sesiones son importantes para los firewalls. Tienen diferentes funciones y no pueden reemplazarse entre sí.

NOTA

 

Además de ASPF, NAT puede generar el mapa del servidor, que se detallará en el capítulo "NAT".

 

Es fácil habilitar ASPF. Por ejemplo, habilite ASPF para FTP en la interzona Trust-Untrust.

 

NOTA

 

ASPF también se puede habilitar para FTP dentro de una zona de seguridad.



104938hg5bghpee4rf1fbf.png


Podemos ver que el firewall ha generado una entrada de mapa de servidor. El paquete del servidor FTP al cliente FTP coincidió con esta entrada y se ha reenviado. De esta manera, no se requiere una política de seguridad para este paquete. Este mapa del servidor no existe permanentemente. Se eliminará después de que caduque su tiempo de envejecimiento. Esto significa que el "canal invisible" no está habilitado permanentemente, lo que mejora la seguridad.

 

Ver la tabla de sesiones en el firewall. La salida del comando muestra que el servidor FTP ha establecido una conexión de datos con el cliente FTP.

104954x26eiirxvl75xfo1.png

La Figura 1-4 muestra el procesamiento ASPF para FTP. Después de habilitar ASPF, el firewall genera un mapa de servidor en la conexión de control de FTP, de modo que se puede establecer la conexión de datos de FTP.

 

Figura 1-4 Procesamiento ASPF para FTP


105003ukf0ujryk5duzugv.png


En conclusión, ASPF genera dinámicamente entradas de mapas de servidor basadas en la información de nivel de aplicación en paquetes, simplificando la configuración de la política de seguridad y mejorando la seguridad. ASPF puede considerarse una técnica de firewall transversal. Las entradas del mapa del servidor "abren" un canal en el firewall, de modo que los paquetes subsiguientes de protocolos multicanal, como el FTP, atraviesen el firewall a través del canal sin ser controlados por políticas de seguridad

 

Además de FTP, los firewalls son compatibles con ASPF para otros protocolos de múltiples canales, como el Protocolo de inicio de sesión (SIP), H.323 y el Protocolo de control de pasarela de medios (MGCP). Para verificar si un modelo de firewall es compatible con ASPF para un protocolo específico, consulte la documentación del producto del modelo de firewall.

 

2 paquetes que ayudan a QQ / MSN a atravesar cortafuegos

 

 

 

Los firewalls también admiten ASPF para los protocolos comunes de mensajería instantánea Tencent QQ y Microsoft Service Network (MSN) Messenger. El proceso de implementación difiere del de FTP. Permíteme presentarte APSF para QQ y MSN para ti.

 

Generalmente, los mensajes de texto QQ / MSN son retransmitidos por un servidor QQ o MSN. Como los mensajes de audio y video consumen muchos recursos, tales mensajes no se retransmiten a través de un servidor. En su lugar, las partes comunicantes establecen una conexión para transmitir tales mensajes, como se muestra en la Figura 1-5.

 

Figura 1-5 Redes para transmitir mensajes QQ / MSN


105012hff8mtt4t1mlxzmm.png


En la mayoría de los casos, configuramos solo la política de seguridad para la interzona Trust-Untrust en un firewall para permitir que los clientes QQ / MSN en una intranet accedan a Internet. Debido a la falta de la política de seguridad para la interzona Untrust-Trust, los clientes QQ / MSN en Internet no pueden iniciar solicitudes de conexión de audio / video a la intranet.

QQ se utiliza como ejemplo. Para permitir que los clientes QQ en Internet accedan al servidor QQ en una intranet, ASPF genera la siguiente entrada de mapa de servidor (esta entrada es solo un ejemplo. La entrada real debe contener información de traducción de direcciones):


105018mdd0w9gbp927deew.png


En la entrada, la dirección de origen es ANY, lo que indica que cualquier usuario puede iniciar solicitudes de conexión al 192.168.0.1 a través del puerto 53346, y el firewall permite que pasen las solicitudes. La entrada contiene la dirección de destino (192.168.0.1), el puerto de destino (53346) y el tipo de protocolo (udp), que se consideran un triplete para las entradas del mapa del servidor.

El tipo de entrada es Recorrido simple de UDP a través de traductores de direcciones de red (STUN). QQ, MSN y las entradas de mapa de servidor definidas por el usuario, que se describirán en la siguiente parte, son todas del tipo STUN. Es decir, los firewalls consideran que QQ, MSN y los protocolos definidos por el usuario están en el tipo STUN. STUN se describirá en la sección "NAT ALG".

El comando para habilitar ASPF para QQ y MSN es similar al de FTP. Habilite ASPF para QQ y MSN en la interzona Trust-Untrust.

NOTA

 

ASPF también se puede habilitar para QQ y MSN dentro de una zona de seguridad.

105031seeet59l55xxqled.png

3 auxiliares a los paquetes de protocolo definidos por el usuario a atravesar el firewall

Para las aplicaciones más allá del ámbito de aplicación admitido del comando de detección, los firewalls proporcionan ASPF para protocolos definidos por el usuario. En la premisa de que hemos entendido el principio de protocolo de una aplicación, podemos definir una ACL para identificar los paquetes de esta aplicación. ASPF establece automáticamente una entrada de mapa de servidor triplete para la aplicación en un servidor de seguridad, de modo que los paquetes de la aplicación puedan pasar el servidor de seguridad. Tenga en cuenta que se prefieren las reglas precisas de ACL para minimizar el impacto adverso en otros servicios.

Actualmente, la aplicación más típica es el Protocolo de transferencia de archivos trivial (TFTP), como se muestra en la Figura 1-6.

 

Figura 1-6 Redes para TFTP


105033rmn5snrtruoy9zwn.png


El control TFTP y las conexiones de datos comparten el número de puerto del cliente TFTP. Después de que el cliente TFTP inicia una solicitud de acceso al servidor TFTP, ASPF genera la siguiente entrada de mapa de servidor:


105040ecjt7edzdnnqadte.png

En esta entrada, 192.168.0.1 es la dirección IP del cliente TFTP, y 55199 es el número de puerto habilitado para el cliente TFTP. El cliente TFTP también usa este número de puerto para acceder al servidor TFTP. Antes de que caduque esta entrada de mapa de servidor, el cliente TFTP en cualquier dirección puede iniciar solicitudes de conexión al 192.168.0.1 a través del puerto 55199, lo que garantiza que los paquetes TFTP puedan pasar a través del firewall.

 

Del mismo modo, no es difícil habilitar ASPF para protocolos definidos por el usuario. La condición de soporte y la sintaxis del comando varían con los modelos de firewall. Esté sujeto a la documentación del producto de un modelo de firewall específico.


105045t4de25nez5cltyoe.png


 

Para QQ, MSN y los protocolos definidos por el usuario, aunque las entradas triples de mapa de servidor generadas por ASPF aseguran el funcionamiento normal de los servicios, este mecanismo conlleva riesgos porque los puertos se han habilitado para el acceso y los paquetes que coinciden con las entradas de mapa de servidor ya no son controlado por las políticas de seguridad.

 

Para reducir los riesgos, los firewalls proporcionan políticas de seguridad específicas de ASPF (filtrado de paquetes) para filtrar los paquetes que coinciden con las entradas de mapa de servidor de triplete para un control de acceso refinado. Por ejemplo, después de que se genere la entrada del mapa de servidor de tripletes anterior, configure la siguiente ACL para permitir que solo pasen los paquetes coincidentes de 192.168.0.1 a 172.16.0.1


105053y7kkqpjkzq7nponz.png


En la descripción anterior, encontramos que ASPF genera entradas de mapas de servidor para protocolos multicanal (como FTP), QQ, MSN y protocolos definidos por el usuario para ayudar a que los paquetes de estos protocolos atraviesen los firewalls.

 

Además, ASPF en los firewalls puede bloquear los complementos de Java y ActiveX en HTTP. Estos complementos proporcionados por HTTP se pueden convertir en caballos de Troya y virus para comprometer a los hosts en intranets. En general, los complementos Java y ActiveX se transportan en cargas útiles HTTP para su transmisión. Si los firewalls solo verifican los encabezados HTTP, no podrán identificar los complementos. En este caso, se debe usar ASPF para verificar las cargas HTTP para bloquear los complementos de Java y ActiveX.

Es fácil configurar un firewall para bloquear los complementos HTTP. Ejecute los comandos de detección de bloqueo de activex y de detección de bloqueo de java en una zona de seguridad o en una interzona. La condición de soporte y la sintaxis del comando varían con los modelos de firewall. Estar sujeto a la documentación del producto de un modelo de firewall específico.


  • x
  • convención:

Responder

Responder
Debe iniciar sesión para responder la publicación Inicio de sesión | Registrarse

Aviso Aviso: Para garantizar sus legítimos derechos e intereses, la comunidad y los terceros no publicarán contenido que pueda generar riesgos legales a las partes, por ejemplo, pornografía, contenido político, contenido sobre juego, consumo y tráfico de drogas, así como contenido que viole los derechos de propiedad intelectual de terceros, por ejemplo, secretos comerciales, marcas, derechos de autor, patentes y privacidad personal. No comparta su cuenta ni su contraseña con terceros. Todas las operaciones realizadas usando su cuenta se considerarán como sus acciones y todas las consecuencias que estas acciones generen serán responsabilidad suya. Para obtener información detallada, consulte la “ Política de privacidad.”
Si el botón para adjuntar no está disponible, actualice Adobe Flash Player con la versión más reciente
¡Ingresa y disfruta de todos los beneficios para los miembros!

¡Ingresa y disfruta de todos los beneficios para los miembros!

Aterrizaje