.pl 10.0i .po 0 .ll 7.2i .lt 7.2i .nr LL 7.2i .nr LT 7.2i .ds LF Chatel .ds RF FORMFEDD[Página %] .ds LH RFC 1919 .ds RH Marzo 1996 .ds CH Proxies IP Transparentes versus Clásicos .hy o .ad 1 .in0 Network Working Group M. Chatel Request for Commentes: 1919 Consultant Category: Informational Marzo 1996 .ce Proxies IP Transparentes versus Clásicos .ti 0 Estado de este memorándum .in 3 Este memorándum provee información para la comunidad Internet. Este memorándum no especifica un estándar Internet de ningún tipo. La distribución de este memorándum es ilimitada. .ti 0 Resumen .in 3 Muchos sistemas de seguridad IP modernos (también llamados "firewalls" en el mercado) hacen uso de la tecnología proxy para tener un control de acceso. Este documento explica las técnicas proxy "clásica" y "transparente" e intenta proveer reglas para ayudar a determinar cuando puede ser usado cada sistema proxy sin causar problemas. Tabla de contenidos INDICE .ti 0 1. Antecedentes Un creciente número de organizaciones usa sistemas de seguridad IP para proveer control de acceso específico cuando cruzan el perímetro de seguridad de la red. Estos sistemas son comúnmente empleados en el límite de la red entre dos organizaciones (que pueden ser parte de la misma entidad "oficial"), o entre la red de una organización y una gran interred pública como Internet. Algunas personas creen que los firewalls IP se convertirán en productos interesantes. Otros creen que la introducción de IPV6 y de sus capacidades de seguridad mejoradas harán que los firewalls sean vistos gradualmente como soluciones temporales, y por ende irrelevantes para el escenario de las redes. En cualquier caso, es realmente importante examinar el impacto de la inserción (y remoción) de un firewall en el límite de una red, y verificar que tipos específicos de tecnologías firewall pueden tener efectos diferentes en redes IP típicas, pequeñas y grandes. En la actualidad los firewalls son usualmente diseñados basados en el filtrado de paquetes, en tecnología proxy o en una combinación de ambos. El filtrado de paquetes (o las configuraciones de hard correctas en el sentido de seguridad) es ahora una tecnología bien documentada cuyas fortalezas y debilidades son razonablemente entendidas. La tecnología proxy, por otra parte, ha sido desarrollada bastante, pero poco estudiada. Además, muchos productos firewalls recientes soportan una capacidad llamada "proxy transparente". Este tipo de característica ha estado sujeto a mucha más atención de marketing que al análisis técnico de la comunidad de redes. Debe recordarse que el crecimiento y el éxito de Internet está fuertemente relacionado a su naturaleza "abierta". Una Internet que hubiera sido segmentada desde el comienzo con firewalls, filtros de paquete, y proxies puede ser que no fuese lo que es hoy. Este tipo de discusión está, sin embargo, fuera del ámbito de este documento, que sólo intenta proveer una descripción entendible de que son los proxies de red, y cuales son las diferencias, fortalezas y debilidades de los proxies de red "clásico" y "transparente". En el contexto de este documento, un proxy "clásico" es el estilo más antiguo (algunos le dirían fuera de moda) de los dos. También observe que en este documento, la palabra "conexión" es usada para una sesión de aplicación que usa TCP, mientras que la palabra "sesión" se refiere a una aplicación dialogando, que puede usar UDP o TCP. .ti 0 2. Comunicación directa (sin un proxy) .in 3 En el mundo "normal" de Internet, los sistemas no usan proxies y simplemente usan TCP/IP normal para comunicarse con algún otro. Es importante (para los lectores que pueden no estar familiarizados con esto) tomar una rápida vista de las operaciones involucradas, para entender mejor cual es el uso exacto de un proxy. .ti 3 2.1 Ejemplo de conexión directa .in 6 Vamos a tomar una sesión de red común y describir algunos detalles de su operación. Veremos que pasa cuando un usuario en un sistema cliente "c.dmn1.com" establece una conexión FTP al sistema servidor "s.dmn2.com". La dirección IP del sistema cliente es c1.c2.c3.c4, la dirección IP del servidor es s1.s2.s3.s4. +---------------+ +----------+ +---------------+ | | / \ | | | c.dmn1.com |----+ red(es) +----| s.dmn2.com | | (c1.c2.c3.c4) | \ IP / | (s1.s2.s3.s4) | +---------------+ +----------+ +---------------+ El usuario comienza una instancia de un programa cliente FTP en el sistema cliente "c.dmn1.com", y especifica que el sistema destino es "s.dmn2.com". En un sistema de línea de comando, el usuario típicamente escribe: .ti 10 ftp s.dmn2.com El sistema cliente necesita convertir el nombre del servidor en una dirección IP (si el usuario especificó directamente el servidor por su dirección este paso no es necesario). La conversión del nombre del servidor a una dirección IP requiere que el trabajo sea realizado con recorridos entre ambos extremos: .in 9 a) el sistema cliente tiene este nombre en su archivo de hosts, o tiene una caché (capacidad de almacenamiento) DNS local y obtiene exitosamente el nombre del sistema de su caché. No se realiza actividad de red para convertir el nombre a una dirección IP. b) el sistema cliente, en combinación con servidores de nombre DNS, genera solicitudes DNS que eventualmente se propagarán a través del árbol DNS y descenderán por la rama DNS del servidor. Eventualmente, un servidor DNS que está autorizado por el dominio del sistema servidor es consultado y devuelve la dirección IP asociada con "s.dmn2.com" (dependiendo del caso, puede devolver esto al sistema cliente directamente o a un servidor de nombre intermedio). Por último, el sistema cliente obtiene una dirección IP válida para s.dmn2.com. Por simplicidad, asumimos que el servidor tiene una sola dirección IP. +---------------+ +--------+ +---------------+ | | / \ | | | c.dmn1.com |---+ red(es) +---| s.dmn2.com | | (c1.c2.c3.c4) | \ IP / | (s1.s2.s3.s4) | +---------------+ +--------+ +---------------+ A | / \ | | dirección para/ \ | | s.dmn2.com? / \ | | / \ | | / \ | | +--------+ s.dmn2.com? +--------+ | +---->|servidor|------------->|servidor| | | DNS | | DNS | +--------| X |<-------------| Y | s1.s2.s3.s4 +--------+ s1.s2.s3.s4 +--------+ .in 6 Cuando el sistema cliente conoce la dirección IP del sistema servidor, intenta establecer una conexión al puerto TCP de "control" FTP estándar en el servidor (puerto 21). Para esta tarea, el sistema cliente debe tener una ruta válida a la dirección IP del servidor, y el sistema servidor debe tener una ruta válida a la dirección IP del cliente. Todos los dispositivos intermedios que conducen, como puertas de enlace IP, deben tener rutas válidas tanto para el cliente como para el servidor. Si estos dispositivos realizan filtrado de paquetes, ellos deben permitir TODOS los tipos específicos de tráfico requeridos entre C y S para esta aplicación específica. +---------------+ +---------------+ | c.dmn1.com | | s.dmn2.com | | (c1.c2.c3.c4) | | (s1.s2.s3.s4) | +---------------+ +---------------+ | | | | | | ruta a S ruta a C | | | V V | | | | A | A | | ruta a C | | ruta a S | | | | | | C S C | | +----+ <-- +----+ --> +----+ <-- +----+ | G1 |--------| Gx |--------| Gy |---------| Gn | +----+ --> +----+ <-- +----+ --> +----+ S C S La aplicación actual trabaja para que la sesión FTP entre el cliente y el servidor sea hecha con flujo bidireccional de paquetes TCP entre las direcciones IP del cliente y del servidor. El protocolo FTP usa un protocolo un poco complejo y un modelo de conexión TCP que, afortunadamente, no es importante en la presente discusión. Esto permite reducir un poco este documento... .ti 3 2.2 Requisitos de la comunicación directa .in 6 Basado en la discusión precedente, es posible decir que lo siguiente es requerido para que una sesión directa entre un cliente y un servidor sea exitosa: .in 9 a) Si el cliente usa el NOMBRE del servidor para referirse a el, el cliente debe tener un conversor nombre-dirección válido para el servidor, o este debe ser capaz de resolver el nombre del servidor (típicamente usando DNS). En el caso de DNS, esto implica que el cliente y el servidor deben ser parte de la misma arquitectura o árbol DNS. b) El cliente y el servidor deben ser parte de la misma interred: el cliente debe tener una ruta IP válida hacia el servidor, el servidor debe tener una ruta IP válida hacia el cliente y todas las puertas de enlace IP intermedias deben tener rutas válidas hacia el cliente y el servidor ("puerta de enlace IP" es la terminología estándar de RFC; la gente comúnmente usa el término "router IP" en ámbitos de computadoras). c) Si hay dispositivos en la ruta entre el cliente y el servidor que realizan filtrado de paquetes, todos estos dispositivos deben permitir el reenvío de paquetes entre la dirección IP del cliente y la dirección IP del servidor, al menos para los paquetes que se adecuan al modelo del protocolo de la aplicación FTP (puertos TCP usados, etc.). .ti 0 3. Proxies de aplicación clásicos .in 3 Un proxy de aplicación clásico es un programa especial que conoce uno (o más) protocolos de aplicación específicos. Muchos protocolos de aplicación no son simétricos; un extremo es considerado el "cliente" y un extremo es el "servidor". Un proxy de aplicación clásico implementa ambas partes, "cliente" y "servidor", de un protocolo de aplicación. En la práctica, sólo se necesita implementar lo suficiente de los protocolos cliente y servidor para efectuar lo siguiente: a) aceptar sesiones cliente y aparecer ante el como un servidor; b) recibir desde un cliente el nombre o dirección del servidor destino final (esto necesita ser pasado a través de la sesión "cliente-proxy" de cierta manera como una aplicación específica); c) establecer una sesión al servidor final y aparecer ante el como un cliente desde el punto de vista del servidor; d) retransmitir las solicitudes, respuestas y datos entre el cliente y el servidor; e) realizar el control de acceso acorde a los criterios de diseño del proxy (la principal meta del proxy, después de todo). La meta funcional del proxy es retransmitir los datos de aplicación entre los clientes y los servidores que pueden no tener conectividad IP directa. La meta de seguridad del proxy es realizar chequeos y diferentes controles de acceso que en general los softwares cliente y servidor no soportan o no implementan. La siguiente información mostrará que los proxies clásicos pueden ofrecer muchos beneficios ocultos a los diseñadores de red concientes de la seguridad, en el costo de implementar el software cliente con soporte proxy o de educación de los usuarios sobre el uso del proxy. Los temas relacionados con el software cliente son ahora más fáciles de manejar, dado el número creciente de aplicaciones cliente populares (para Web, FTP, etc.) que ofrecen soporte proxy. Los diseñadores desarrollando nuevos protocolos tienen más posibilidad de planear el soporte proxy desde el principio, para asegurarse que sus protocolos puedan cruzar la mayoría de los grandes firewalls corporativos existentes que están basados al menos en parte en la tecnología proxy clásica. .ti 3 3.1 Ejemplo de sesión proxy clásica .in 6 Repetiremos nuestro pequeño análisis de una sesión FTP. Esta vez, la sesión FTP está pasando a través de un sistema proxy de aplicación "clásico". Como es común el caso (aunque no indispensable), asumiremos que el sistema proxy tiene dos direcciones IP, dos interfaces de red y dos nombres DNS. El sistema proxy está corriendo un programa especial que sabe como desempeñarse como un cliente FTP en un lado, y como un servidor FTP en el otro. Este programa es lo que la gente llama el "proxy". Asumiremos que el programa proxy está escuchando solicitudes entrantes en el puerto de control FTP estándar (21/tcp), aunque este no es siempre el caso en la práctica. +---------------+ +----------+ | | / \ | c.dmn1.com |----+ red(es) +----------+ | (c1.c2.c3.c4) | \ IP / | +---------------+ +----------+ +-----------------+ | (p1.p2.p3.p4) | | proxy1.dmn3.com | | | | proxy2.dmn4.com | | (p5.p6.p7.p8) | +---------------+ +----------+ +-----------------+ | | / \ | | s.dmn2.com |----+ red(es) +----------+ | (s1.s2.s3.s4) | \ IP / +---------------+ +----------+ El usuario comienza una instancia de un programa cliente FTP en el sistema cliente "c.dmn1.com", y DEBE especificar que el sistema destino es "proxy1.dmn3.com". En los sistemas de línea de comando, el usuario típicamente escribe: .in 10 ftp proxy1.dmn3.com .in 6 El sistema cliente necesita convertir el nombre del proxy a una dirección IP (si el usuario directamente especifica el proxy por la dirección este paso no es necesario). La conversión del nombre del proxy a una dirección IP requiere que el trabajo sea realizado con recorridos entre ambos extremos: .in 9 a) el sistema cliente tiene este nombre en su archivo de hosts, o tiene una caché DNS local y obtiene exitosamente el nombre del sistema de su caché. No se realiza actividad de red para convertir el nombre a una dirección IP. b) el sistema cliente, en combinación con servidores de nombre DNS, genera solicitudes DNS que eventualmente se propagarán a través del árbol DNS y descenderán por la rama DNS del servidor. Eventualmente, un servidor DNS que está autorizado por el dominio del sistema servidor es consultado y devuelve la dirección IP asociada con "proxy1.dmn3.com" (dependiendo del caso, puede devolver esto al sistema cliente directamente o a un servidor de nombre intermedio). Por último, el sistema cliente obtiene una dirección IP válida para proxy1.dmn3.com. +---------------+ +--------+ | | / \ | c.dmn1.com |--------+ red(es) +------------+ | (c1.c2.c3.c4) | \ IP / | +---------------+ +--------+ +-----------------+ A | / \ | (p1.p2.p3.p4) | | | dirección para / \ | proxy1.dmn3.com | | | proxy1.dmn3.com? / \ | ... | | | / \ +-----------------+ | | / \ | | / \ | | +--------+ proxy1.dmn3.com? +--------+ | +-------->|servidor|------------------>|servidor| | | DNS | | DNS | +------------| X |<------------------| Y | p1.p2.p3.p4 +--------+ p1.p2.p3.p4 +--------+ .in 6 Cuando el sistema cliente conoce la dirección IP del sistema proxy, intenta establecer una conexión al puerto TCP de "control" FTP estándar en el proxy (puerto 21). Para esta tarea, el sistema cliente debe tener una ruta válida a la dirección IP del proxy, y el sistema proxy debe tener una ruta válida a la dirección IP del cliente. Todos los dispositivos intermedios que conducen, como puertas de enlace IP, deben tener rutas válidas tanto para el cliente como para el proxy. Si estos dispositivos realizan filtrado de paquetes, ellos deben permitir TODOS los tipos específicos de tráfico requerido entre C y P1 para esta aplicación específica (FTP). Finalmente, el sistema proxy debe aceptar esta conexión entrante, basado en la dirección IP del cliente (el propósito del proxy es generalmente realizar control de acceso, después de todo). +---------------+ | ... | | c.dmn1.com | | proxy1.dmn3.com | | (c1.c2.c3.c4) | | (p1.p2.p3.p4) | +---------------+ +-----------------+ | | | | | | ruta a P1 ruta a C | | | V V | | | | A | A | | ruta a C | | ruta a P1 | | | | | | C P1 C | | +----+ <-- +----+ --> +----+ <-- +----+ | G1 |--------| Gx |--------| Gy |---------| Gn | +----+ --> +----+ <-- +----+ --> +----+ P1 C P1 La aplicación actual trabaja para que la sesión FTP entre el cliente y el proxy sea hecha con flujo bidireccional de paquetes TCP entre las direcciones IP del cliente y del proxy. Para que esto trabaje, la aplicación FTP proxy DEBE soportar completamente el protocolo FTP y verse idéntico a un servidor FTP desde el punto de vista del cliente. Cuando la sesión cliente<->proxy es establecida, el nombre del servidor destino final debe ser pasada al proxy, ya que, cuando se usa un proxy de aplicación "clásico", un camino DEBE ser definido por el proxy para determinar el sistema destino final. Esto puede ser logrado de tres maneras: .in 12 a) El sistema cliente suministra el nombre o dirección del sistema destino final al proxy en un método que es compatible con el protocolo de aplicación específico que está siendo usado (en nuestro ejemplo, FTP). Esto es generalmente considerado como el principal problema con los proxies clásicos, ya que por cada aplicación que utiliza el proxy, debe ser definido un método para pasar el nombre o dirección del sistema destino final. Este método debe ser compatible con cada variante de aplicación cliente que implementa el protocolo (ej: el método de pasar el destino debe adaptarse a las MÍNIMAS funcionalidades requeridas por el protocolo de aplicación específico). Para el protocolo FTP, generalmente el método más común para el paso del nombre de servidor final al proxy se describe a continuación: Cuando el proxy solicita al cliente FTP un nombre de usuario, el cliente especifica una cadena de la forma: .in 15 usuario_destino@nombre_sistema_destino o usuario_destino@dirección_ip_destino .in 12 El proxy entonces sabrá que es el sistema destino final. El usuario_destino (y la contraseña suministrada por el cliente) será reenviado "tal como es" por el proxy al sistema destino final. Un ejemplo bien conocido de un proxy FTP que se maneja de esta manera es el programa "ftp-gw" que es parte del conjunto de herramientas firewall del Trusted Information System, disponible mediante FTP anónimo en ftp.tis.com. Varios firewalls comerciales también soportan de facto este estándar. b) Si sólo hay un posible destino final, el proxy puede ser configurado para conocer este destino anticipadamente. Ya que la dirección IP del sistema cliente es conocida cuando el proxy debe tomar esta decisión, el proxy puede (si se requiere) seleccionar un destino diferente basado en la dirección IP del cliente. c) El software cliente puede también soportar las capacidades que permiten presentar al usuario la ilusión de una sesión directa (el usuario solo especifica el sistema destino final, y el software cliente automáticamente manipula el problema de alcanzar el sistema proxy y pasar el nombre o dirección del sistema destino final en cualquier forma mutuamente aceptable). Un ejemplo bien conocido de un sistema que provee software cliente modificado, software proxy y que provee la ilusión de transparencia es el sistema SOCKS de NEC, disponible mediante FTP anónimo en ftp.nec.com. Altevernativamente, varias aplicaciones cliente FTP soportan el estándar "usuario@host_de_destino" implementado estándar de facto (por ejemplo) mediante la aplicación proxy "ftp-gw". .in 9 Cuando la aplicación proxy FTP conoce el nombre o dirección IP del sistema destino, puede elegir hacer dos cosas: .in 12 a) Establecer una sesión al sistema destino final, el caso más frecuente. b) Decidir (basado en algún dato de configuración interna) que no puede alcanzar el sistema destino final directamente, pero debe pasar por otro proxy. Esto es raro hoy en día, pero puede convertirse temporalmente en algo común debido al actual déficit de números de red IP que las organizaciones intentan mantener "ocultos" y que están actualmente asignados en otra parte. Las sesiones entre sistemas que tienen el mismo número de red IP pero que pertenecen a redes en realidad diferentes pueden requerir pasar a través de dos sistemas proxy. Esto se discute con más detalle en la sección 3.2.6, "Interconexión de redes IP en conflicto". .in 6 Si el proxy FTP decide conectarse directamente al sistema destino, y tiene el nombre del sistema destino, necesitará convertir el nombre del sistema destino a una dirección IP. Si este proceso involucra resolución DNS, sucederá algo como lo siguiente: +-----------------+ | proxy1.dmn3.com | | (p1.p2.p3.p4) | +--------+ | | / \ | proxy2.dmn4.com |--------+ red(es) +------------+ | (p5.p6.p7.p8) | \ IP / | +-----------------+ +--------+ +---------------+ A | / \ | (s1.s2.s3.s4) | | | dirección para / \ | s.dmn2.com | | | s.dmn2.com? / \ | | | | / \ +---------------+ | | / \ | | / \ | | +--------+ s.dmn2.com? +--------+ | +-------->|servidor|------------------>|servidor| | | DNS | | DNS | +------------| X |<------------------| Y | s1.s2.s3.s4 +--------+ s1.s2.s3.s4 +--------+ Cuando el sistema proxy conoce la dirección IP del sistema servidor, intenta establecer una conexión al puerto TCP de "control" estándar en el servidor (puerto 21). Para esta tarea, el sistema proxy debe tener una ruta válida a la dirección IP del servidor, y el sistema servidor debe tener una ruta válida a una de las direcciones IP del proxy al menos. Todos los dispositivos intermedios que conducen, como puertas de enlace IP, deben tener rutas válidas para ambos, el proxy y el servidor. Si estos dispositivos realizan filtrado de paquetes, ellos deben permitir TODOS los tipos específicos de tráfico requerido entre el proxy y S para esta aplicación específica. +-----------------+ | proxy1.dmn3.com | | (p1.p2.p3.p4) | | | +----------------+ | proxy2.dmn4.com | | s.dmn2.com | | (p5.p6.p7.p8) | | (s1.s2.s3.s4) | +-----------------+ +----------------+ | | | | | | ruta a S ruta a P2 | | | V V | | | | A | A | | ruta a P2 | | ruta a S | | | | | | P2 S P2 | | +----+ <-- +----+ --> +----+ <-- +----+ | G1 |--------| Gx |--------| Gy |---------| Gn | +----+ --> +----+ <-- +----+ --> +----+ S P2 S La aplicación actual trabaja para que la sesión FTP entre el proxy y el servidor sea hecha con flujo bidireccional de paquetes TCP entre las direcciones IP del proxy y del servidor. ¿Qué sucede actualmente ENTRE EL CLIENTE Y EL SERVIDOR? Ambos envían réplicas y respuestas al proxy, quien reenvía los datos al "otro" extremo. Cuando una parte abre una conexión de datos y envía un comando de PUERTO al proxy, el proxy asigna su propia conexión de datos y envía su comando de PUERTO al "otro" extremo. El proxy también copia los datos a través de las conexiones creadas de esta manera. .ti 3 3.2 Características de las configuraciones de proxy clásicos .in 6 Varias interredes IP pueden ser conectadas usando sólo la tecnología proxy clásica. Es común actualmente conectar dos interredes IP específicas de esta manera: Internet y alguna red IP "privada" de una organización. Tal enlace basado en proxy es comúnmente el componente clave de un firewall. Cuando esto es hecho, varios beneficios y problemas son introducidos para los administradores y usuarios de la red. 3.2.1 Requisitos de direccionamiento y encaminamiento IP .in 9 El sistema proxy debe ser capaz de direccionar todos los sistemas cliente y servidor para que puedan proveer servicio. Debe también conocer rutas IP válidas a todos los sistemas cliente y servidor. Los sistemas cliente y servidor deben ser capaces de direccionar el sistema proxy, y deben conocer una ruta IP válida al sistema proxy. Si el sistema proxy tiene varias direcciones IP (y comúnmente, varias interfaces físicas de red), los sistemas cliente y servidor sólo necesitan ser capaces de acceder a UNA de las direcciones IP del sistema proxy. Observe que los sistemas cliente y servidor que usan el proxy para la comunicación NO NECESITAN direccionamiento o información de encaminamiento IP válida para sistemas que alcanzan a través del proxy. En ese sentido, puede decirse que los sistemas separados por un proxy clásico están aislados uno del otro en el sentido de direccionamiento y encaminamiento IP. Por otro lado, el sistema proxy clásico (si posee una pila de software TCP/IP estándar) necesita tener una sola vista coherente del direccionamiento y encaminamiento IP. Si tal sistema proxy interconecta dos redes IP y dos sistemas que usan el mismo número de red/subred IP (un sistema en cada red), el proxy sólo será capaz de direccionar uno de los sistemas. Esta restricción pueden ser eliminada encadenando proxies clásicos (esto se describe luego en la sección 3.2.6, "Interconexión de redes IP en conflicto"). Usando un proxy clásico para interconexión de interredes IP, es también posible, con cuidado, lograr una característica deseable "a prueba de fallos": no se necesita que existan entradas de encaminamiento válidas para una interred que debería ser alcanzada sólo a través del proxy (actualizaciones de encaminamiento que podrían agregar tales entradas exclamando estar BLOQUEADAS). Si el proxy de repente comienza a manejarse como un router IP, sólo una forma de ataque es posible. En otras palabras, supongamos un atacante que tiene el control de la interred remota y ha encontrado una manera de causar que el proxy encamine paquetes IP, o ha encontrado una manera de saltear físicamente el proxy. El atacante puede introducir paquetes, pero el sistema interno atacado será incapaz de responder a estos paquetes. Esto verdaderamente no hace al ataque infalible (ejemplificado por los eventos verídicos en el período de vacaciones en años recientes), pero sin embargo lo hace más difícil. .ti 6 3.2.2 Ocultamiento de la dirección IP .in 9 Las "sesiones" de aplicación que pasan a través de un proxy clásico están actualmente compuestas de dos sesiones completas: .in 13 a) una sesión entre el cliente y el proxy b) una sesión entre el proxy y el servidor .in 9 Un dispositivo en la ruta ve sólo el tráfico cliente<->proxy o el tráfico proxy<->servidor, dependiendo de donde esté localizado. Si las dos sesiones pasan efectivamente a través de la misma red física, un dispositivo en esta red puede ver ambos tráficos, pero puede tener dificultades para establecer la relación entre las dos sesiones (dependiendo de la aplicación específica y del nivel de actividad de la red). Un producto derivado de una conducta de un proxy clásico es comúnmente conocido como "ocultamiento de dirección". Los equipos en algún lado de un proxy clásico no pueden determinar fácilmente cuales son las direcciones IP usadas en el otro. El ocultamiento de dirección es generalmente visto como una Buena Cosa, ya que uno de los propósitos del desarrollo de los proxies es develar la menor información sobre una interred como sea posible. La gente que está a cargo de la recolección de estadísticas de red, y que no tiene acceso a los reportes del sistema proxy (si hay alguno) puede considerar el ocultamiento de dirección como una Mala Cosa, ya que el proxy confunde la relación cliente/servidor real donde el proxy fue insertado. Toda la actividad IP se origina y termina en el proxy mismo (o parece hacerlo). De la misma manera, el software servidor que acepta conexiones que han venido a través de un proxy clásico no ven la dirección IP del cliente entrante, a menos que esta información esté incluida en el protocolo de aplicación (y si esto pasa, en muchos casos, el proxy reemplazará esta información con su dirección para que el protocolo sea consistente). Esto hace al control de acceso al servidor inservible si el control está basado en la dirección IP del cliente. .ti 6 3.2.3 Requisitos DNS .in 9 En muchas configuraciones proxy clásicas, los sistemas cliente pasan el nombre del servidor deseado (o dirección) al sistema proxy SIN INTERPRETARLO. Debido a esto, el sistema cliente NO REQUIERE ser capaz de resolver el nombre del sistema servidor para acceder a el a través de un proxy clásico. Sólo necesita ser capaz de resolver el nombre del proxy (si se refiere al sistema proxy por el nombre). Debido a esto, se puede decir que un sistema proxy clásico puede ofrecer aislamiento DNS. Si dos interredes IP usan árboles DNS completamente separados (cada uno con su propio servidor DNS base), el software cliente en una interred IP puede referir un nombre servidor en la otra interred IP pasando su nombre al proxy clásico. El proxy clásico en si mismo no será capaz por si solo de resolver los nombres DNS en ambos ambientes (si posee un software de resolución DNS estándar), ya que necesitará apuntar a uno o a otro de los dos "universos" DNS. Una técnica bien conocida llamada "cerebro DNS separado" puede ser usada para aliviar esta restricción en cierto modo. Si una solicitud DNS puede devolver una respuesta válida en ambos ambientes, sólo una de las respuestas será encontrada por el proxy. .ti 6 3.2.4 Requisitos de software .in 9 Una aplicación proxy clásico es una sola pieza de software completamente, a menudo solo una implementación cliente o una implementación servidor real. Estos programas pueden correr en cualquier sistema que soporte conexiones TCP/IP normales, y normalmente no requerirá privilegios de "sistema" o "superusuario". Las conexiones proxy clásicas no tienen impacto en el software servidor normal; el proxy se ve como un cliente normal excepto por su dirección IP y su naturaleza de "grupo". Todas las conexiones desde la red hacia el otro lado del proxy aparentan venir del proxy, esto supone problemas si se desea control de acceso por sistema cliente. El software cliente normal puede acceder a un proxy clásico si el usuario está dispuesto o es capaz de pasar a través de los pasos extras necesarios para indicar el servidor final al proxy (cualesquiera que sean). Alternativamente, software cliente modificado (o nuevo) puede ser usado para que sepa como negociar transparentemente con el proxy. .ti 6 3.2.5 Impacto de un proxy clásico en el filtrado de paquetes .in 9 Si el filtrado de paquetes es necesario alrededor de un proxy clásico, las reglas de filtrado de paquete tienden a ser simplificadas, ya que sólo el tráfico necesario y permitido se originará o terminará en el proxy (en un sentido IP). Si el proxy comienza conduciéndose como un router IP, o si es físicamente salteado, las reglas de filtrado, si son empleadas generalmente dentro de una interred IP, intentarán prevenir cualquier flujo de tráfico directo entre la interred "interna" y las interredes "externas" que se supone sólo son alcanzables a través de la aplicación proxy. .ti 6 3.2.6 Interconexión de redes IP en conflicto .in 9 Encadenando proxies clásicos es posible lograr alguna interconexión de redes IP que tienen un alto nivel de conflicto. En la práctica, este tipo de configuración resuelve los conflictos de direccionamiento IP mucho mejor que los conflictos DNS. Pero los conflictos DNS son un problema menor debido a que el "espacio de dirección" es prácticamente infinito (¿alguien ha calculado el espacio de dirección posible basado en el estándar RFC de longitud máxima de nombre de host?). Aunque el RFC 1597 no es más que un RFC informativo, muchas organizaciones han seguido completamente sus sugerencias, a falta de una solución más sencilla. Imaginemos dos organizaciones, cada una usa la red de clase A número 10 en su red. De repente necesitan conectarse. ¿Qué pueden hacer? Primera posibilidad: se cambia el número de red en uno de los lados (no es tan complicado como la gente cree si se planea correctamente, pero representa trabajo). Segunda posibilidad: se unen renumerando parcialmente cada uno de los lados para evitar conflictos (realmente complicado de hacer, pero tiene la ventaja política de que ambos lados tiene que hacer parte del trabajo). Tercera posibilidad: se comunican encadenando proxies clásicos: +--------+ +--------+ +--------+ +--------+ / Org. 1 \ |sistema | |sistema | / Org. 2 \ + dmn1.com +---+ Proxy +---+ Proxy +---+ dmn2.com + \ net 10 / | 1 | | 2 | \ net 10 / +--------+ +--------+ +--------+ +--------+ Ambos proxies 1 y 2 son sistemas estándar corriendo pilas de software TCP/IP normal. Sus configuraciones no son típicas, sin embargo: .in 12 a) La conexión entre el proxy 1 y el proxy 2 puede usar cualquier número de red IP que no este usado (o no sea necesario) en cada lado. En ninguna de las redes Org 1 y Org 2 se necesita tener una ruta IP a esta red. b) El proxy 1 tiene una ruta IP para la red 10 que apunta a la red de la Organización 1, y realiza la resolución DNS (si se requiere) usando servidores de nombre de dmn1.com. c) El proxy 2 tiene una ruta IP para la red 10 que apunta a la red de la Organización 2, y realiza la resolución DNS (si se requiere) usando servidores de nombre de dmn2.com. d) El proxy 1 y el proxy 2 sólo requieren una ruta IP de host hacia la otra red para comunicarse. e) Para esto es conveniente que las aplicaciones proxy clásicos soporten la selección automática de un destino basado en la dirección IP del cliente. f) En el sistema proxy 1, el software proxy negocia las sesiones entrantes desde el sistema proxy 2 de la manera normal: el "cliente" (el sistema proxy 2) será consultado en una manera específica de la aplicación por el destino final. Sin embargo, las sesiones entrantes desde las direcciones de Org 1 son inmediata y automáticamente reenviadas al sistema proxy 2. El sistema proxy 2 está configurado similarmente (o sea, las conexiones entrantes desde el proxy 1 son consultadas por un nombre de servidor destino, y las conexiones desde las direcciones de Org 2 son inmediata y automáticamente reenviadas al proxy 1). .in 9 Desde el punto de vista del usuario, la configuración anterior de la manera en que se encadena un sistema proxy clásico no es muy diferente de un solo proxy de aplicación clásico: .in 12 a) Un usuario en un sistema cliente con la dirección 10.1.2.3 en la red de Org 1 desea realizar un FTP anónimo a "server.dmn2.com". b) El usuario comienza un FTP a través del proxy 1. El proxy 1 ve una conexión entrante desde una dirección en la red 10, entonces inmediatamente reenvía la conexión al proxy 2. c) El proxy 2 ve una conexión entrante desde el proxy 1, entonces consulta al cliente. El usuario ve la solicitud de nombre de usuario e ingresa (asumiendo que los proxies FTP se manejan como ftp-gw de TIS): .ti 14 anonymous@server.dmn2.com Esto será resuelto EN EL CONTEXTO DE LA RED DE Org. 2. El usuario pueden completar el diálogo y usar la conexión FTP. d) Observe que esta configuración trabajará aunque el cliente y el servidor tengan EXACTAMENTE LA MISMA DIRECCIÓN IP (10.1.2.3 en nuestro ejemplo). Si las aplicaciones proxy soportan la selección de otro proxy basado en el destino provisto por el cliente y si el dominio DNS es único ¡más de dos redes IP con conflictos pueden ser conectadas de esta manera! Aquí hay un ejemplo de configuración: a) Cuatro redes IP las cuales usan todas la red 10 son conectadas por cuatro sistemas proxy. Los cuatro sistemas proxy comparten algo en común, el número de red IP privada y el enlace físico (LAN o WAN). b) Un usuario en la red de la organización 1 desea acceder a un servidor en la red 3. El usuario se conecta a su proxy local (proxy 1) y provee el nombre del sistema destino. c) El proxy 1 determina, basado en una regla de configuración, que el nombre del sistema destino es alcanzable utilizando el proxy 3. Entonces se conecta al proxy 3 y pasa el nombre del sistema destino. d) El proxy 3 determina que el nombre del sistema destino es local (a si mismo) y se conecta directamente. Implicaciones de seguridad de los proxies encadenados Obviamente, cuando tales configuraciones "encadenadas" son realizadas, las reglas de control de acceso y la autorización basadas en una combinación cliente final/servidor final son difíciles de realizar, ya que el primer proxy en la cadena ve una relación cliente final/proxy y el último proxy en la cadena ve una relación proxy/servidor final. Lo mejor que se puede hacer es que los proxies sean capaces de pasar la información del "cliente original" y del "destino final" hacia atrás y hacia adelante en la cadena proxy con propósitos de control de acceso y/o autorización. Esto requiere que los proxies se validen uno al otro, y requiere que la ruta de la red sea validada (evitando que esta información se convierta en un excelente ataque). Cuando estos problemas fueron resueltos realmente, la meta original de la cadena proxy fue resolver un conflicto de IP y posiblemente de DNS. El "cliente original" y el "destino final" pueden no tener el mismo sentido en cualquier parte de la configuración. Etiquetar la información con un "nombre universal" puede ayudar, asumiendo que es posible definir nombres universales únicos en primer lugar. Obviamente este tema requiere más estudio. .ti 0 4. Aplicaciones proxies transparentes .in 3 El problema más visible de las aplicaciones proxies clásicas es la necesidad de que los programas cliente soporten al proxy y/o la educación de los usuarios para que sepan como usarlos. Cuando alguien pensó en modificar los proxies de tal manera que los procedimientos normales de los usuarios y de las aplicaciones cliente fuesen capaces de tomar ventaja de los proxies, nació el proxy transparente. Una aplicación proxy transparente es normalmente descrita como un sistema que aparece como un filtro de paquete para los clientes, y como un proxy clásico para los servidores. Además de este importante concepto, los proxies clásicos y los transparentes pueden realizar un control de acceso similar y pueden ofrecer un nivel de seguridad/robustez/rendimiento equivalente, al menos en lo que al proxy mismo concierne. La siguiente información dejará en claro que las organizaciones pequeñas que desean usar la tecnología proxy para protección, que desean descansar enteramente en un sistema proxy para la seguridad del perímetro de su red, que quieren un impacto mínimo (o nulo) en los procedimientos de los usuarios y que no desean molestias con clientes que soporten proxy, preferirán una tecnología proxy transparente. Las organizaciones con una o más de las siguientes características pueden preferir emplear la tecnología proxy clásica: a) su propio router IP interno, y desear evitar el agregado de rutas "externas" en la red b) desear utilizar "defensa en profundidad", como firewalls internos o filtrados de paquetes en la red interna c) desear dejar su ambiente DNS completamente aislado del "otro lado" de su sistema proxy o temer que sus servidores DNS internos puedan ser vulnerables a los ataques por manejo de datos d) usar alguna red IP que está en conflicto con el "otro lado" de su sistema proxy e) desear usar las aplicaciones proxy que son fácilmente portables a diferentes tipos y/o versiones de sistemas operativos f) desear utilizar múltiples sistemas proxy interconectándolos a la MISMA red remota sin introducir encaminamientos dinámicos para rutas externas en la red interna 4.1 Ejemplo de conexión proxy transparente .in 6 Vamos a ir a un sesión FTP nuevamente, a través de un proxy "transparente" esta vez. Asumimos que el sistema proxy tiene dos direcciones IP, dos interfaces de red y dos nombres DNS. El sistema proxy está corriendo un programa especial que sabe como desempeñarse como un cliente FTP en un lado, y como un servidor FTP en el otro. Este programa es lo que la gente llama el "proxy". Este programa, siendo un proxy transparente, también tiene un relación especial con la implementación TCP/IP del sistema proxy. Esta relación puede ser hecha de varias maneras, describiremos sólo una de las posibles. Asumiremos que el programa proxy está escuchando las solicitudes entrantes en el puerto de control FTP estándar (21/tcp), sin embargo no siempre es el caso en la práctica. +---------------+ +----------+ | | / \ | c.dmn1.com |----+ red(es) +----------+ | (c1.c2.c3.c4) | \ IP / | +---------------+ +----------+ +-----------------+ | (p1.p2.p3.p4) | | proxy1.dmn3.com | | | | proxy2.dmn4.com | | (p5.p6.p7.p8) | +---------------+ +----------+ +-----------------+ | | / \ | | s.dmn2.com |----+ red(es) +----------+ | (s1.s2.s3.s4) | \ IP / +---------------+ +----------+ El usuario comienza una instancia de un programa cliente FTP en el sistema cliente "c.dmn1.com", y especifica un destino de "s.dmn2.com", sólo como si fuese alcanzable directamente. En los sistemas de línea de comando, el usuario normalmente escribiría: .ti 10 ftp s.dmn2.com El sistema cliente necesita convertir el nombre del servidor a una dirección IP (si el usuario especifica directamente la dirección del servidor este paso no es necesario). La conversión del nombre del servidor a una dirección IP requiere que el trabajo sea realizado con recorridos entre ambos extremos: .in 9 a) el sistema cliente tiene este nombre en su archivo de hosts o tiene una caché DNS local y obtiene exitosamente el nombre del sistema proxy de su caché. No se realiza actividad de red para convertir el nombre a una dirección IP. b) el sistema cliente, en combinación con servidores de nombre DNS, genera solicitudes DNS que eventualmente se propagarán a través del árbol DNS y descenderán por la rama DNS del servidor. Eventualmente, un servidor DNS que está autorizado por el dominio del sistema servidor es consultado y devuelve la dirección IP asociada con "s.dmn2.com" (dependiendo del caso, puede devolver esto al sistema cliente directamente o a un servidor de nombre intermedio). Por último, el sistema cliente obtiene una dirección IP válida para s.dmn2.com. +---------------+ +--------+ | | / \ | c.dmn1.com |--------+ red(es) +------------+ | (c1.c2.c3.c4) | \ IP / | +---------------+ +--------+ +-----------------+ A | / | (p1.p2.p3.p4) | | | dirección para / +-----+ | sistema proxy | | | s.dmn2.com? / / \ | (p5.p6.p7.p8) | | | / / \ +-----------------+ | | / / \ | | | / / s.dmn2.com? | | | | +--------+ / | +--------+ | +-------->|servidor|--+ +-------+ | / \ | | DNS | / \ | + red(es) + +------------| X |<---+ + | \ IP / s1.s2.s3.s4 +--------+ s1.s2.s3.s4| | +--------+ | | | | + | | \ +--------+ + +->|servidor| \ | DNS | +----| Y | +--------+ NOTA: en la práctica, los servidores DNS que están autorizados para s.dmn2.com es muy común que estén localizados en el OTRO lado del sistema proxy. Esto significa que las solicitudes DNS desde dentro hacia afuera DEBEN ser capaces de cruzar el sistema proxy. Si el sistema proxy desea proveer "ocultamiento de dirección" debe hacer que estas solicitudes DNS (originadas desde dentro) parezcan venir desde el proxy mismo. Esto puede ser realizado utilizando un servidor DNS basado en BIND (que tiene algunas capacidades proxy) o simplemente por algún programa proxy DNS. Para una completa compatibilidad RFC, el sistema proxy debe ser capaz de reenviar solicitudes basadas en TCP como también solicitudes basadas en UDP, ya que algunos sistemas cliente are rumored to SOLAMENTE usar TCP para las solicitudes DNS. El sistema proxy debe ser capaz de detectar y bloquear varias clases de ataques basados en DNS que (de lo contrario) pueden causar denegación de servicio: .in 12 a) intentos desde el exterior de devolver entradas de caché corruptas al servidor DNS interno b) intentos de devolver información DNS que no tiene relación con la solicitud DNS actual (algunos servidores DNS son vulnerables a esto). La meta de los atacantes puede ser principalmente el caché de los servidores DNS internos con entradas interesantes, incluyendo entradas para nombres DNS internos que apuntan a direcciones IP externas... c) datos basura manejados, similar en estilo a los ataques del tipo "desbordamiento del buffer del registro del sistema" .in 3 Cuando los sistemas cliente conocen la dirección IP del sistema servidor, intentan establecer una conexión al puerto TCP de "control" FTP estándar en el servidor (puerto 21). Para este trabajo, el sistema cliente debe tener una ruta válida para la dirección IP del servidor QUE GUIE AL SISTEMA PROXY, y el sistema proxy debe tener una ruta válida para la dirección IP del cliente y del servidor. Todos los dispositivos intermedios que conduzcan como puertas de enlace IP deben tener rutas válidas para el cliente, el servidor y usualmente para el proxy. Si estos dispositivos realizan filtrado de paquetes, ellos deben permitir TODOS los tipos específicos de tráfico requerido entre C y S para esta aplicación específica. A ruta a S | | +-----------------+ +---------------+ | (p5.p6.p7.p8) | | c.dmn1.com | | sistema proxy | | (c1.c2.c3.c4) | | (p1.p2.p3.p4) | +---------------+ +-----------------+ | | | | | | ruta a S ruta a C | | | V V | | | | A | A | | ruta a C | | ruta a S | | | | | | C S C | | +----+ <-- +----+ --> +----+ <-- +----+ | G1 |--------| Gx |--------| Gy |---------| Gn | +----+ --> +----+ <-- +----+ --> +----+ S C S En el comienzo de una sesión FTP, un paquete TCP con una dirección origen de C y una dirección destino de S atraviesa el sistema proxy, esperando cruzarlo sólo como una puerta de enlace IP normal. Aquí es cuando el proxy transparente muestra su magia: La pila de software TCP/IP del proxy ve este paquete entrante (y los subsecuentes) para una dirección destino que NO es una de sus propias direcciones. Basado en algún criterio (un archivo de configuración, por ejemplo), decide NO reenviar ni descartar el paquete (que son las únicas dos opciones que tendría en una implementación TCP/IP RFC estándar). El sistema proxy acepta el paquete como si fuese dirigido a una de sus propias direcciones IP. En nuestro ejemplo, el paquete entrante es un paquete TCP. Ya que las pilas TCP/IP estándar almacenan tanto un campo de dirección IP LOCAL como una REMOTA por cada conexión TCP, el proxy transparente puede establecer el campo de dirección IP LOCAL como la dirección IP que el cliente quiere alcanzar (s1.s2.s3.s4 en nuestro ejemplo). La pila TCP/IP estándar probablemente necesite ser modificada para hacer esto. Los ejemplos UDP, aunque no se basan en conexión, pueden ser manejados de manera similar. Cuando esto es hecho, la aplicación proxy FTP actual es invocada ya que una conexión entrante al puerto TCP 21 ha ocurrido. Puede determinar que es el destino final instantáneamente, ya que el campo de dirección IP LOCAL de la conexión contiene la dirección IP del servidor destino. No es necesario que la aplicación proxy consulte al cliente que es el sistema destino final. Ya que la aplicación proxy FTP conoce la dirección IP del sistema destino, puede elegir entre dos opciones: .in 6 a) Establecer una sesión al sistema destino final, el caso más frecuente. b) Decidir (basado en algún dato de configuración interna) que no puede alcanzar el sistema destino final directamente, pero debe pasar a través de un proxy "clásico". Esto se ve técnicamente factible, aunque los sistemas proxy transparente reales conocidos no ofrecen esta capacidad. El verdadero valor de tal característica (si está disponible) necesitaría ser estudiado. .in 3 Si el proxy FTP decide conectarse directamente al sistema destino, tiene la dirección IP del sistema destino. Debe elegir hacer una búsqueda inversa en la dirección IP destino para obtener el nombre del sistema destino (posiblemente necesario para control de acceso). Si este proceso involucra resolución DNS, algo como lo siguiente sucederá: +-----------------+ | proxy1.dmn3.com | | (p1.p2.p3.p4) | +--------+ | | / \ | proxy2.dmn4.com |--------+ red(es) +------------+ | (p5.p6.p7.p8) | \ IP / | +-----------------+ +--------+ +---------------+ A | / \ | (s1.s2.s3.s4) | | | nombre para / \ | s.dmn2.com | | | s1.s2.s3.s4? / \ | | | | / \ +---------------+ | | / \ | | / \ | | +--------+ s1.s2.s3.s4? +--------+ | +-------->|servidor|------------------>|servidor| | | DNS | | DNS | +------------| X |<------------------| Y | s.dmn2.com +--------+ s.dmn2.com +--------+ Cuando esto es realizado y si la conexión es permitida, el proxy intentará establecer una conexión al puerto TCP de "control" FTP estándar en el servidor destino (puerto 21), usando una técnica idéntica a un proxy "clásico". Para este trabajo, el sistema proxy debe tener una ruta válida a la dirección IP del servidor, y el sistema servidor debe tener una ruta válida hacia al menos una de las direcciones IP del proxy. Todos los dispositivos intermedios que conduzcan como puertas de enlace IP deben tener rutas válidas para el proxy y para el servidor. Si estos dispositivos realizan filtrado de paquetes, ellos deben permitir TODOS los tipos específicos de tráfico requeridos entre el proxy y S para esta aplicación específica. +-----------------+ | proxy1.dmn3.com | | (p1.p2.p3.p4) | | | +----------------+ | proxy2.dmn4.com | | s.dmn2.com | | (p5.p6.p7.p8) | | (s1.s2.s3.s4) | +-----------------+ +----------------+ | | | | | | ruta a S ruta a P2 | | | V V | | | | A | A | | ruta a P2 | | ruta a S | | | | | | P2 S P2 | | +----+ <-- +----+ --> +----+ <-- +----+ | G1 |--------| Gx |--------| Gy |---------| Gn | +----+ --> +----+ <-- +----+ --> +----+ S P2 S El resto de la operación del proxy transparente es muy similar a lo que ocurriría con un proxy clásico. .ti 0 4.2 Características de las configuraciones proxy transparente La tecnología proxy transparente puede ser usada para realizar el componente clave de un "firewall", de cierta manera completamente similar a la forma que la tecnología proxy clásica puede ser usada. Varios detalles importantes de la arquitectura deben ser diferentes, sin embargo. 4.2.1 Requisitos de direccionamiento y encaminamiento IP .in 9 El sistema proxy transparente debe ser capaz de direccionar todos los sistemas cliente y servidor para que puedan proveer servicio. Debe también conocer rutas IP válidas a todos estos sistemas cliente y servidor. Los sistemas servidor deben ser capaces de direccionar el sistema proxy, y deben conocer una ruta IP válida al sistema proxy. Si el sistema proxy tiene varias direcciones IP (y comúnmente, varias interfaces físicas de red), los sistemas servidor sólo necesitan ser capaces de acceder a UNA de las direcciones IP del sistema proxy. Los sistemas cliente DEBEN TENER información de direccionamiento y encaminamiento IP válida para los sistemas que alcanzan a través del proxy. Por ejemplo, en el caso común donde un proxy transparente está siendo usado para interconectar una red privada a Internet, la red privada efectivamente necesitará usar una ruta predeterminada que apunte al sistema proxy transparente. Esta es una necesidad específica de las configuraciones proxy transparente. La interconexión de dos interredes con múltiples proxies transparentes (para dividir la carga o tolerar fallos) puede ser conseguida usando diferentes técnicas de las que serían hechas con los proxies clásicos: .in 15 a) con múltiples proxies clásicos en la misma red remota, los clientes pueden ser configurados manualmente para acceder a diferentes proxies, o basado en técnicas DNS, una carga balanceada del DNS puede ser usada para lograr que los clientes accedan a diferentes proxies en diferentes momentos. b) con múltiples proxies transparentes en la misma red remota, la red interna debe ser capaz de proveer enrutamiento dinámico a través de los proxies (puede ser necesario que los proxies se provean a ellos mismos de actualizaciones de las rutas). Los sistemas cliente (dependiendo de la topología) pueden no necesitar ver los cambios de rutas, pero los routers del backbone interno probablemente si. .in 9 Está claro que las interredes conectadas por un proxy transparente no pueden estar completamente aisladas cada una de la otra en el sentido de direccionamiento y encaminamiento IP. La red en que los sistemas cliente están localizados debe tener entradas de encaminamiento efectivas válidas a la interred remota; estas entradas de encaminamiento deben apuntar al proxy. El sistema proxy transparente (si posee una pila de software TCP/IP vagamente estándar) necesitará tener una sola vista coherente del direccionamiento y encaminamiento IP. Si un sistema proxy interconecta dos redes IP y dos sistemas usan la misma red IP/número de subred (un sistema en cada interred), el proxy sólo será capaz de direccionar uno de los sistemas. Igual que si el proxy es capaz de manejar múltiples universos IP en conflicto (si, por ejemplo, una instancia de una pila TCP/IP completa y sus estructuras de datos están sujetas a cada una de las interfaces de red del proxy), el sistema cliente siempre tendrá un problema: ¿Por qué enviaría paquetes con este número de red al proxy ya que este número de red existe en la interred interna? El encadenado de proxies transparentes no se ve a primera vista para resolver conflictos de IP como lo hacen los proxies clásicos. Desde un punto de vista de "seguridad" a pruebas de fallos de, el proxy transparente tiene una característica indeseable: la red protegida debe tener entradas de encaminamiento válidas a la/s red/es remota/s. Si el proxy falla (deja de comportarse como un router IP de filtrado) o es físicamente salteado, entonces la red interna será inmediatamente capaz de responder a los paquetes "atacantes". El atacante no necesita modificar las tablas de encaminamiento o simular direcciones IP internas. Esto es importante para organizaciones que no desean ubicar TODA su seguridad y protección dentro de un sistema proxy (por alguna razón). .ti 6 4.2.2 Ocultamiento de la dirección IP Las "sesiones" de aplicación que pasan a través de un proxy transparente están en realidad compuestas de dos sesiones completas: .in 13 a) una sesión entre el cliente y la dirección del servidor, la sesión siendo "interceptada" por el proxy b) una sesión entre el proxy y el servidor .in 9 Un dispositivo en la ruta ve el tráfico cliente<->servidor o el tráfico proxy<->servidor, dependiendo de donde esté localizado. El tráfico cliente<-"servidor" es en realidad generado por el proxy transparente. Las dos sesiones NUNCA pasarían a través de la misma red física, ya que en ese caso (debido a los requerimientos de encaminamiento) un salto total del proxy en el nivel de encaminamiento IP puede ocurrir fácilmente sin que sea detectable. Como los proxies clásicos, los proxies transparentes efectúan una forma de ocultamiento de dirección IP. Las direcciones IP cliente son ocultadas desde los servidores, ya que los servidores ven una sesión siendo iniciada por el proxy. Las direcciones IP del servidor NO son ocultadas a los clientes, sin embargo, para que la ilusión de transparencia pueda ser mantenida. Esta diferencia implica que la red interna (el lado del cliente) estática en el nivel IP precisamente reflejará que destinos externos están siendo accedidos. Esto puede ser usado para el análisis de patrones de tráfico. .ti 6 4.2.3 Requisitos DNS En las configuraciones proxy transparente, los sistemas cliente DEBEN ser capaces de resolver nombres de servidor a través de redes remotas. Esto es crítico ya que el proxy determinará el servidor destino desde la dirección IP de los paquetes arribando desde los clientes. Debido a esto, la interred "cliente" necesita tener alguna forma de interconexión DNS a la red remota. Si el cliente interno y las direcciones IP del servidor de nombre deben ser ocultadas desde el exterior, estas solicitudes DNS también deben ser pasadas por el proxy. Por supuesto, las relaciones nombre/dirección del host remoto pueden ser almacenadas localmente en el sistema cliente, pero es bien sabido que esta implementación no es escalable... Debido a esto, se puede decir que un sistema proxy transparente no puede ofrecer aislamiento DNS. Si dos interredes IP usan árboles DNS completamente separados (cada uno con sus propios servidores DNS maestros), el software cliente en una interred IP no tendrá forma de encontrar las relaciones nombre/dirección en el "otro" árbol DNS, y esta información debe ser obtenida para lograr pasar la dirección deseada al proxy transparente. El proxy clásico por si mismo (si posee una solución de software DNS estándar) no será capaz de resolver los nombres DNS en ambos ambientes, ya que necesitará apuntar a uno o a otro de los dos "universos" DNS. Corriendo múltiples instancias de la solución de software DNS sin embargo, se puede permitir que el proxy haga esto. Debido a los requisitos encontrados de alguna forma en la comunicación DNS a través del proxy, es crítico para el proxy ser capaz de protegerse a SI MISMO, a los clientes internos y a los servidores de nombre internos de los ataques por manejo de datos en el nivel DNS. .ti 6 4.2.4 Requisitos de software La gran ventaja de los proxies transparentes es que el software cliente normal puede acceder a servidores remotos sin modificaciones ni cambios en los procedimientos de usuario. La aplicación proxy transparente en si misma no necesita ser más complicada que una aplicación proxy clásica. Sin embargo, la pila de software TCP/IP del proxy no puede ser completamente estándar (al menos no el estándar de hoy), y requiere extensiones específicas: .in 15 a) La aptitud de especificar rangos de direcciones IP que no pertenecen al proxy mismo, pero que deberá procesar por medio de "intercepción": si un paquete arriba al proxy con una dirección IP destino en su rango, la pila IP no reenviará ni descartará los paquetes, lo pasará a las capas de aplicación superiores. b) Este mecanismo requiere que la aplicaciones puedan obtener tanto la dirección IP de los paquetes que llegan, como la dirección a la cual los paquetes están yendo. Las pilas IP típicas deberían tener también los campos disponibles para almacenar la información; es cuestión de actualizarlos adecuadamente para estos paquetes "interceptados". c) En el caso de los paquetes TCP "interceptados" , la pila TCP debe soportar el establecimiento de conexiones TCP donde la dirección IP "local" no es una de las direcciones IP del proxy. .in 9 Una implementación de software TCP/IP debería ser modificable para realizar estas tareas. Si una API estándar está disponible para manejar estas extensiones, y si esta API es generalmente implementada, los proxies transparentes pueden ser aplicaciones "portables". Hasta que esto ocurra, se debe asumir que los implementadores tienen diferentes opciones para llevar a cabo estas funciones, por lo cual las aplicaciones proxy transparente de hoy no pueden ser completamente portables. También resta ver cuanto trabajo es necesario para propagar estas "extensiones" a las pilas de software IPV6. .ti 6 4.2.5 Impacto de un proxy transparente en el filtrado de paquetes La naturaleza de las funcionalidades del proxy transparente hace difícil emplear un buen filtrado de paquetes en el "interior" (o lado del cliente) del proxy. El proxy "enmascarará" todos los sistemas externos. Debido a esto, los filtros de paquete internos EN GENERAL NECESITARÁN PERMITIR tráfico IP entre las direcciones IP internas y externas. Dependiendo de la política de seguridad real de la red, puede ser posible realizar filtrado basado en tipo de protocolo y/o en bits TCP (para filtros basados en la dirección del establecimiento de la conexión), pero el filtrado de los bloques de direcciones IP externas NO PUEDE ser realizado. Si el proxy comienza a comportarse como un router IP, o si es físicamente salteado, las limitaciones prácticas impuestas en el filtrado interno de paquetes implican que algo del tráfico directo entre el interior y el exterior de la red será permitido fluir. Además, como vimos previamente, la red interna tendrá entradas de encaminamiento válidas para los números de red externos que apuntan al proxy. Si varios proxies han sido empleados, la red interna puede TENER QUE VALIDAR las actualizaciones de encaminamiento generadas por el proxy. En general, si una red interna desea comunicarse con una red externa a través del proxy transparente, este DEBE SER FUNDAMENTALMENTE DESIGNADO PARA COMUNICARSE DIRECTAMENTE con esa red externa. Esto es necesario en el nivel de direccionamiento IP, en el nivel de encaminamiento IP y en el nivel DNS. Un fallo en la seguridad del proxy en este tipo de ambiente resultará en una inmediata, total y no detectada accesibilidad de la red interna por parte de la red externa. .ti 6 4.2.6 Interconexión de redes IP en conflicto A diferencia de los proxies clásicos, los proxies transparentes no son fácilmente vistos en la resolución de conflictos de direccionamiento IP. Si dos interredes usan el mismo número/s de red, los sistemas y routers en cada una de las interredes tendrán rutas válidas a estos números de red. Si estas rutas son cambiadas para apuntar a un proxy transparente, el tráfico que debe estar dentro de la misma interred comenzará a fluir a través del proxy. El proxy no será capaz de distinguir realmente entre el tráfico entre sistemas de la misma interred y el tráfico que debe cruzar el proxy. Una posible solución de este problema es descrito en la sección 6 de este documento, "Mejorando los proxies transparentes". .ti 0 5. Comparación de proxies clásicos y transparentes .in 3 Para esto quienes no quieren largas discusiones de detalles técnicos, aquí hay un resumen en una página de las fortalezas/debilidades/diferencias de los proxies clásicos y transparentes: ------------------------------------------------------------------------------- | Tema | Proxy Clásico | Proxy transparente | |---------------------+---------------------------+---------------------------| | Direccionamiento IP | sistemas/puertas de enlace| sistemas/puertas de enlace| | | en cada lado de la red | en la red "cliente" | | | necesarios para | necesarios para | | | direccionar el proxy | direccionar las redes | | | | remotas | | | | | | Encaminamiento IP | sistemas/puertas de enlace| sistemas/puertas de enlace| | | en cada lado de la red | en la red "cliente" | | | necesitan una entrada de | también necesitan entradas| | | encaminamiento válida | de encaminamiento para | | | para el proxy | entradas remotas | | | | | | Ocultamiento de | los sistemas en cada lado | los sistemas en el lado | | dirección IP | del proxy están ocultos | "cliente" están ocultos | | | del lado opuesto | del lado opuesto | | | | | | DNS | posibilidad de aislamiento| se requiere resolución | | | completo | de nombres del exterior | | | | por sistemas del interior | | | | | | Requisitos del | corre una pila TCP/IP | requiere una pila TCP/IP | | software proxy | estándar; puede ser | especial; no es 100% | | | portable | portable | | | | | | Requisitos del | se requiere software con | nada más que una conexión | | software cliente | soporte proxy o educación | directa | | | de los usuarios | | | | | | | Requisitos de | debe usar software con | nada más que una conexión | | usuario | soporte proxy o saber | directa | | | como usar el proxy | | | | | | | Filtrado de paquetes| puede filtrar | no puede filtrar | | | direcciones "externas" | direcciones "externas" | | | | | | Resolución de | puede ser hecho por medio | no hay una forma obvia | | conflictos de | de encadenamiento de | de lograr esto | | dirección IP | proxies que soporten | | | | autoconexión | | ------------------------------------------------------------------------------- .ti 0 6. Mejorando los proxies transparentes El principal tema visto con los proxies transparentes es dar vueltas alrededor de la necesidad de forzar a los sistemas "cliente" a acceder directamente a direcciones externas. Para algunas personas, esta característica hace que un proxy transparente se vea mucho más complicado que un filtro de paquetes. ¿Puede ser resuelto este problema? La primera posibilidad que viene a la mente es usar la flexibilidad del protocolo DNS para hacer nuevos trucos. Si restringimos a los clientes "internos" a que ellos DEBAN SIEMPRE usar DNS para resolver los nombres de los hosts externos Y QUE ELLOS NUNCA DEBAN almacenar copias permanentes de las direcciones de los hosts externos, la siguiente técnica sería teóricamente posible (esta es una muy dolorosa restricción, por la manera): .in 6 a) Ordenar que todas las solicitudes internas para nombres DNS externos vayan al sistema proxy transparente(esto puede ser hecho de varias maneras). b) Ordenar que existan entradas de rutas para un número de red de clase A que no es usado en la red interna. Esto IMPLICA que la red interna no puede ser parte de Internet. Esta entrada de encaminamiento apuntará al sistema proxy transparente. Para el propósito de nuestra discusión, este número especial de red será X.0.0.0. c) Cuando un sistema interno genera una solicitud para una dirección externa, la solicitud (si no es respondida por la caché en la red interna) alcanzará al sistema proxy. Asumiendo que la solicitud es para obtener la dirección IP correspondiente al nombre de dominio, el proxy pasará a través del siguiente algoritmo: .in 9 - intenta encontrar una unión válida para este nombre de dominio externo en su caché local - si no encuentra, EL MISMO enviará una solicitud DNS externa para el nombre de dominio. Cuando (y si) recibe una respuesta válida, crea una entrada en la caché local conteniendo: .in 15 Tiempo de Vida de la respuesta Tiempo de Expiración de la entrada de la caché (basado en el tiempo actual) Nombre de dominio externo Dirección IP externa Dirección IP asignada dinámicamente de la forma X.x1.x2.x3 .in 9 y devuelve al cliente la dirección IP asignada dinámicamente en el rango X.0.0.0, NO LA REAL. - el cliente puede (o no) almacenar la dirección IP devuelta en su caché, e intentar entonces conectarse a la dirección IP asignada dinámicamente. Este tráfico arribará al proxy debido a la configuración del encaminamiento - el proxy transparente intercepta el tráfico y puede identificar el destino realmente deseado al que se debería conectar basado en la dirección IP asignada dinámicamente provista por el cliente .in 3 En una implementación, si es funcional, podrían mejorarse muchas características de los proxies transparentes y pueden siempre hacerse proxies capaces de manipular redes IP con números en conflicto. Sin embargo, el algoritmo anterior deja muchos interrogantes difíciles sin resolver. Aquí hay una lista (no muy exhaustiva) de estos interrogantes: .in 6 a) ¿Cuál es el porcentaje de aplicaciones DNS cliente y de implementaciones DNS servidor que conforman a la especificación RFC en su manejo del campo Tiempo de Vida (Time-To-Live)? b) ¿Cómo debería el proxy manipular otros tipos de solicitudes DNS para nombres de dominio externo (solicitudes inversas, solicitudes para otros tipos de registros de recursos)? c) Un programa cliente puede realizar una solicitud DNS para un nombre de dominio y luego usar la respuesta por un largo tiempo (un archivo grande transferido, o una sesión de administración permanente, por ejemplo). ¿Debería el proxy actualizar el Tiempo de Expiración de las entradas del caché basado en el tráfico IP transferido? y entonces ¿qué algoritmo utilizar? d) ¿Qué nuevos tipos de ataques a tal sistema serían posibles? e) ¿Qué estructuras de datos y recursos (memoria, disco) serían necesarios para una implementación eficiente si el proxy debe mantener un alto rango de solicitudes DNS para nombres externos, y donde un gran número de nombres externos diferentes son referidos? El número de red de clase A es usado básicamente para referirse a entradas de caché. ¿Sería un espacio de dirección de 24 bits suficiente para el uso en la práctica? f) ¿Que pasa con la caché (y la funcionalidad) si el proxy colapsa o se reinicia? .in 3 Tal sistema probablemente exhibiría dos tipos de fallos intermitentes: .in 6 a) un sistema cliente silencioso usando el resultado de una solicitud de nombre externo (alguna dirección X.x1.x2.x3 asignada dinámicamente por el proxy), pero dicha unión no existe hace tiempo en la caché del proxy. El cliente intenta una conexión a esta dirección, la cual falla. b) un nombre en la caché del cliente conteniendo una unión para X.x1.x2.x3, pero el proxy ha reutilizado esta dirección para un nombre de host externo diferente. El cliente intenta una conexión a esta dirección, no hay errores obvios, pero alcanza un sistema diferente del esperado. .in 3 Si alguien ha implementado tal esquema, la información y experiencia en el empleo sería útil en la comunidad del trabajo en red IP. .ti 0 7. Consideraciones de seguridad Gran parte de este documento es concerniente a las implicaciones de seguridad de las tecnologías proxy clásica y transparente. .ti 0 8. Reconocimientos No habría podido escribir este documento sin la ayuda de Digital Equipment Corporation para quien yo trabajo como consultor. .ti 0 9. Referencias .IP [1] Cheswick, W., Bellovin, S., "Firewalls and Internet Security: Repelling the Wily Hacker", Addison-Wesley, 1994. .IP [2] Chapman, B., Zwicky, E., "Building Internet Firewalls", OíReilly and Associates, Inc., Septiembre 1995. .IP [3] Comer, D., "Internetworking with TCP/IP volume 1: Priniples, Protocolos, and Architecture", Prentice-Hall, 1991. .IP [4] Comer, D., Stevens, D., "Internetworking with TCP/IP volume 2: Design, Implementation, and Internals", Prentice-Hall, 1991. .IP [5] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, USC/Information Sciences Institute, Octubre 1985. .IP [6] Huitema, C., "An experiment in DNS Based IP Routing", RFC 1383, INRIA, Diciembre 1992. .IP [7] Rekhter Y., Moskowit B., Karrenberg D., de Groot, G., "Address Allocation for Private Internets", RFC 1597, IBM Corp., Chryslet Corp, RIPE NCC, Marzo 1994. .IP [8] The TIS firewall toolkit's documentation, disponible en el sitio FTP anónimo Trusted Information Systemís, ftp.tis.com. .IP [9] Muchas discusiones en los últimos 18 meses en la lista de correo de firewalls mantenida por Great Circle Associates. El archivo de la lista es mantenido en ftp.greatcircle.com. .ti 0 Dirección del autor Marc Chatel 9, avenue Jean Monnet 74940 ANNECY-LE-VIEUX FRANCE Email: mchatel@pax.eunet.ch o en Digital Equipment: Marc.Chatel@aeo.mts.dec.com Traducción al castellano: Javier Waisbrot (2004), jwais@fi.uba.ar