Proxy HTTP vs bump-in-wire

Con el proxy HTTP, los sistemas de usuario pueden tener direcciones privadas locales (por ejemplo, direcciones en las redes 10.0.0.0/8 o 192.168.0.0/16) ya que, a nivel de TCP / IP, estos sistemas solo hablan con el proxy, No internet en general. Con el cuadro "bump-in-the-wire", los sistemas de usuario deben poder comunicarse con sitios externos arbitrarios más o menos directamente, lo que implica una IP pública (¡costosa!) O algún NAT (que puede tener problemas para escalar a miles de usuarios locales). usuarios).

La caja de conexiones en el cable también necesita interceptar el tráfico entrante y saliente, y, como tal, puede ser engorroso adaptarlo en una arquitectura existente. El proxy HTTP, por otro lado, es un host ordinario, en lo que respecta a los enrutadores.

A los efectos de monitorear a los usuarios en una red corporativa, la diferencia entre la detección / intercepción en línea y los proxies es pequeña. De hecho, una caja en el cable es una opción superior en la mayoría de los casos si todo el tráfico es forzado, ya que verá tráfico en todos los puertos.

Sin embargo, los servidores proxy no se instalan únicamente en entornos corporativos para espiar y bloquear a sus usuarios. La capa de abstracción que proporcionan para requerir tráfico HTTP / HTTPS (de la cual probablemente sea la mayoría) es definitivamente una buena práctica para aumentar la seguridad de su red corporativa.

Aunque solo, un proxy no es la máxima seguridad de su red, ciertamente no es una solución que deba ignorarse porque "no hace mucho". Suponiendo que Windows domine la red, configurar una política de grupo en su red para exigir que los clientes se conecten en el proxy corporativo con credenciales de Active Directory es una mitigación increíblemente sencilla. Esto evita que Mr.BadGuy llegue a su red y (a) rastree credenciales vinculadas a Internet que pueden usarse para elevación y (b) extraiga datos corporativos de su red sin siquiera una cuenta.

Un proxy en una red bien diseñada puede llegar a ser una solución elegante y, en realidad, en un entorno corporativo, no se debe permitir la salida de HTTP (si existe) más que HTTP / HTTPS. Si bien una solución en el cable le da mucha potencia, también conlleva un gran riesgo. ¿Cuánto capital ganaría un atacante al entrar en su caja en el cable?

Creo que es una cuestión de escala de tráfico e infraestructura de redes actualmente en su lugar. Si solo desea proxy del tráfico HTTP, entonces no tiene sentido ponerlo como un bump en el cable (un proxy transparente) de tal manera que todo se debe separar en el conmutador. Esto significa que necesitaría un equipo L4 (adicional) para enviar el tráfico HTTP al proxy transparente, mientras que un proxy explícito no requiere el cambio adicional.

Mientras leía The Tangled Web , encontré un problema con un proxy transparente que también almacena en caché el contenido para ahorrar ancho de banda:

"El enfoque adoptado por los proxies transparentes es inusualmente peligroso: cualquier dicho proxy puede ver la IP de destino y el encabezado Host enviado en la conexión interceptada, pero no tiene forma de inmediato decir si esa IP de destino está realmente asociada con el Nombre del servidor especificado. A menos que una búsqueda y correlación adicional sea Los clientes y servidores co-conspirantes pueden tener un día de campo con este comportamiento. Sin estos controles adicionales, el atacante simplemente necesita conectarse a su servidor doméstico y enviar un mensaje engañoso Host: www.google.com encabezado para tener la respuesta en caché para todos otros usuarios como si realmente vinieran de www.google.com . "

Los proxies HTTP están limitados a HTTP, y generalmente solo buscan tráfico en el puerto 80. Un usuario inteligente podría fácilmente pasar por alto el proxy HTTP para llegar a Internet mediante la comunicación en algún otro puerto.

Recomendaría el enfoque de bump-in-the-wire siempre y cuando la solución que está implementando supervise todos los puertos de 65K +. En otras palabras, ningún usuario podría omitir porque todos los puertos están monitoreados. Por supuesto, sus políticas tendrían que aprovechar esta capacidad. Esto es muy fácil de instalar porque no se utilizan direcciones IP. Por lo tanto, no es necesaria la reconfiguración de la red. Obviamente, este enfoque supone que algún otro dispositivo está proporcionando funciones de firewall / NAT.

También, debería pensar en cómo falla el dispositivo de bump-in-the-wire. Si no se cierra, el acceso a Internet está bloqueado para todos. Podría usar un interruptor de derivación si esto es inaceptable. Por supuesto, puede implementar un par de dispositivos con alta disponibilidad / conmutación por error automática.

Un proxy puede ofrecer un mejor diseño de red de defensa en profundidad y más flexible. Por ejemplo, un firewall moderno puede identificar y eliminar todo el tráfico HTTP / HTTPS / contenido de transmisión que no pasa por el proxy, independientemente del puerto en el que se ejecute (o solo se permite si se trata de un host conocido que ejecuta una aplicación conocida que desconoce el proxy) . Además, al usar un conjunto de servidores proxy y un script .pac, puede separar diferentes tipos de tráfico web: los usuarios de escritorio pueden enviarse a un proxy de almacenamiento en caché en una conexión de Internet, el tráfico crítico de servidores o estaciones de trabajo puede dirigirse a otro. el tráfico de la aplicación web a una red de confianza (donde el proxy está configurado para proteger la red de confianza de usuarios no autorizados) en un tercero.

Esto se puede lograr con el filtrado en modo transparente con algunos enrutamientos inteligentes, cortafuegos y configuración de conmutador de capa 3, pero será mucho más fácil y más confiable en algunas situaciones gestionarlo con un conjunto de proxies.

Me temo que no hay una solución fácil. Una de las principales causas es que un usuario puede encontrar fácilmente en la web un sitio con nuevos nuevos proxies todos los días y pueden usar esas direcciones IP para omitir su proxy HTTP o su bump-in-the-wire.

El mejor enfoque es el que filtra por contenido, no por destino. Se podría omitir de todos modos, pero en menos casos y es difícil.