Se explican las conexiones a través de firewalls

4

Estoy buscando una buena explicación de cómo funcionan las conexiones a través de firewalls. Tengo la idea de empaquetar (encapsular) algún protocolo dentro de otro como su carga útil al hacer un túnel. Pero lo que no puedo entender es por qué el firewall pasa los mensajes del servidor remoto al cliente que está detrás del firewall. Mi entendimiento es como tal: supongamos que estamos utilizando http como transporte

cliente - > envía msg al servidor remoto - > el firewall lo acepta y pasa - > el servidor recibe el mensaje

respuestas del servidor al cliente - > el firewall recuerda que este mensaje es una respuesta a msg del cliente y lo pasa al revés - > cliente recibe mensaje

ahora, el servidor quiere pasar otro msg - > cliente lo envía - > el firewall lo bloquea, ya que no es una respuesta a ninguna de las solicitudes de los clientes

Probablemente me esté perdiendo algo. ¿O deberíamos usar otro enfoque para tal propósito? ¿Cuándo, digamos que un servidor no cierra realmente la conexión a la solicitud del cliente y mantiene la conexión, y dentro de esta conexión tenemos una interacción transparente entre el servidor y el cliente?

cualquier buen recurso sería muy apreciado

gracias

    
pregunta Theo Walcott 24.01.2013 - 22:36
fuente

4 respuestas

2

Los cortafuegos se clasifican generalmente en tres categorías principales, estas son

  1. Filtros de paquetes Stateless / StateFul
  2. Aplicación / Proxy Firewall
  3. Cortafuegos de aplicaciones web / Cortafuegos de proxy inverso

Cada tipo de Firewall opera en diferentes capas en una pila TCP / IP y tiene sus propios pros y contras. En realidad, está utilizando una aplicación / Proxy Firewall que impone una sobrecarga significativa si las conexiones no se administran. Se creará un cuello de botella si mantenemos la conexión abierta, ya que el firewall mantiene el estado de cada conexión. Para obtener respuestas más detalladas, consulte esta figura y lea la página Proxy de aplicación Cortafuegos .

    
respondido por el Ali Ahmad 25.01.2013 - 15:23
fuente
2

Bueno, no puedo decir que haya entendido la pregunta por completo, incluso entonces puedo compartir algunas cosas que sé. Me refiero a los cortafuegos de red que se centran principalmente en la capa 3 (capa de Internet) y la capa 4 (capa de transporte) del Pila OSI.

Todos los cortafuegos con estado mantienen una tabla llamada tabla de sesión.

Por lo tanto, los firewalls con estado se denominan firewalls con estado debido a la presencia de una tabla de sesión. Una tabla de sesión básica tendrá 4 entradas Source-IP del paquete, IP de destino del paquete, puerto de origen y puerto de destino. El tipo de firewall que he trabajado tenía 2 entradas más, la interfaz de entrada y salida del paquete.

Bien, ahora veremos cómo se forma una conexión.

Tomaremos el caso de una conexión TCP en el puerto 80 (http). Para ser más específicos, un cliente sentado detrás de un firewall está intentando conectarse a google.com.El primer paquete que saldrá del cliente será un tcp SYN. Esto llega al firewall. El firewall, al ser un firewall de red, buscaría la IP de destino y luego realizaría una búsqueda de ruta para la IP de Google. Estamos viendo la parte de firewall, por lo que suponemos que hay una entrada en la tabla de enrutamiento. Desde la tabla de enrutamiento, el firewall obtiene la interfaz de salida.

Ahora, un firewall de red típico tendrá varias interfaces de red y cada interfaz se asignará a una "zona". El firewall implica la gobernanza del tráfico entre las interfaces mediante el uso de un conjunto de reglas.

Entonces, después de obtener la interfaz saliente de la tabla de enrutamiento, el firewall mira la zona de la interfaz saliente. Luego, el firewall busca una política (regla) desde la zona de la interfaz entrante a la zona de la interfaz saliente. Si hay una política que permite el tráfico entre las 2 zonas, el firewall envía el paquete fuera de la interfaz de salida y, a continuación, crea una entrada en la tabla de sesión. Tenga en cuenta que este es el primer paquete de una conexión. Ahora, cuando el paquete de respuesta proviene del servidor. de vuelta al cliente, no tiene que pasar por el proceso de búsqueda de reglas porque ya hay una entrada en la tabla de la sesión. Ahora, el puerto de origen del paquete de respuesta sería 80 y el puerto de destino sería el puerto de origen que estaba utilizado por el cliente para el tcp syn. Al coincidir con los puertos e IP, el firewall decide si el paquete entrante es una respuesta o no y luego lo envía fuera de la interfaz correcta.

Supongamos que el servidor envía un paquete que no es una respuesta para el cliente, la búsqueda de la sesión fallará y el firewall buscará una regla que permita el tráfico del lado del servidor al lado del cliente. Si esa regla no está presente, el paquete será eliminado.

Tenga en cuenta que esta comprobación de la regla no se realiza para un paquete de respuesta proveniente del servidor porque el paquete de solicitud inicial ya creó una sesión desde el lado del cliente. Esperamos que esto responda a su pregunta ... No dude en preguntar Si esta respuesta no es clara

    
respondido por el aRun 25.01.2013 - 18:03
fuente
1

La mayoría de los cortafuegos recordarán que se abrió una solicitud a un servidor en particular y le permitirán a ese servidor comunicarse con esa conexión. Si se está utilizando NAT, el puerto en el que se realiza la conexión seguirá en uso para esa conexión. En realidad, esto no es exclusivo de los túneles, sino que también se aplica a cualquier tipo de flujo de datos. Por ejemplo, cuando transmites un video desde Netflix o Youtube, el firewall sabe que te permite recibir datos de su servidor a pesar de que no envías un paquete por cada paquete que regresa.

    
respondido por el AJ Henderson 24.01.2013 - 22:42
fuente
1

Al usar un túnel, de hecho, encapsula un protocolo en otro. La forma más común de hacer túneles es configurar un túnel SOCKS5. SOCKS sucede en la 5ª capa, la capa de sesión. Cuando abres un túnel SOCKS, el túnel permanece establecido, incluso cuando no estás enviando nada sobre él.

    
respondido por el Lucas Kauffman 24.01.2013 - 22:49
fuente

Lea otras preguntas en las etiquetas