¿Un proxy inverso frente al servidor web mejorará la seguridad?

Un profesional de seguridad externo está recomendando que ejecutemos un proxy inverso frente al servidor web (todos alojados en la DMZ) como medida de seguridad recomendada.

Sé que esta es una arquitectura típica recomendada, ya que proporciona otro nivel de seguridad frente a una aplicación web para evitar hackers.

Sin embargo, como un proxy inverso está enviando alegremente HTTP de un lado a otro entre el usuario y el servidor web interno, no proporcionará ninguna medida de prevención de piratería en el servidor web en sí. En otras palabras, si su aplicación web tiene un agujero de seguridad, el proxy no proporcionará ninguna cantidad significativa de seguridad.

Y dado que el riesgo de un ataque a una aplicación web es mucho más alto que el de un ataque al proxy, ¿realmente se gana mucho al agregar un cuadro adicional en el medio? No estaríamos utilizando ninguna de las capacidades de almacenamiento en caché de un proxy inverso, solo una herramienta tonta para transportar paquetes de un lado a otro.

¿Hay algo más que me falta aquí? ¿La inspección de paquetes HTTP de proxy inverso se ha vuelto tan buena que puede detectar ataques significativos sin grandes cuellos de botella en el rendimiento, o este es solo otro ejemplo de Security Theater?

El proxy inverso es MS ISA fwiw.

Apache tiene mod_security, que detectará ataques de seguridad comunes. También hay mod_cband, que puede restringir el ancho de banda utilizado. No me sorprendería si ISA tuviera algo similar. Sin algo que realmente verifique el tráfico HTTP a medida que pasa por el proxy, todo es un poco inútil desde el punto de vista de la seguridad.

Lo que le proporcionará un proxy inverso es el equilibrio de carga, la conmutación por error, el almacenamiento en caché, SSL y la descarga de archivos, dejando que sus servidores web hagan lo que son buenos: servir HTML.

El servidor ISA puede buscar y prevenir varias vulnerabilidades HTTP y evitar que lleguen al servidor web. Si bien la mayoría de los servidores HTTP modernos ya no son explotables, tiene el beneficio adicional de no enviar este tráfico al servidor web.

Además, ISA puede hacer que sea más fácil hacer cosas como agregar aceleración SSL y autorización previa de usuarios a varias URL. Incluso puede actuar como un equilibrador de carga para que pueda agregar fácilmente más servidores web sin usar un equilibrador de carga de hardware separado.

Asegúrese de tomar las ventajas que esta persona está dando en ISA y compararlo con la cantidad de gastos adicionales que le costará administrar y ejecutar ISA en comparación con los beneficios.

¿Un proxy inverso frente al servidor web mejorará la seguridad?

Un proxy inverso le ofrece un par de cosas que pueden hacer que su servidor sea más seguro.

• Un lugar para monitorear y registrar lo que está sucediendo separado del servidor web
• Un lugar para filtrar o cortafuegos separado de su servidor web si sabe que alguna área de su sistema es vulnerable. Dependiendo del proxy, puede filtrar a nivel de aplicación.
• Otro lugar para implementar ACL y reglas si no puede ser lo suficientemente expresivo por alguna razón en su servidor web.
• Una pila de red separada que no será vulnerable de la misma manera que su servidor web. Esto es particularmente cierto si su proxy es de un proveedor diferente.
  • Usar la configuración de Apache como un proxy frente al servidor Apache probablemente no sea tan útil como algo parecido a Squid frente a Apache.

Un proxy inverso sin filtro no lo protege automáticamente contra todo, pero si el sistema que necesita proteger tiene un alto valor, entonces agregar un proxy inverso puede valer la pena los costos de soporte y rendimiento.

Podría proteger su servidor de aplicaciones de ataques basados ​​en solicitudes HTTP incorrectas ... Especialmente si es posible en el proxy inverso (y no en el servidor de aplicaciones) configurar exactamente el aspecto de una solicitud correcta y no permitir que se reciban solicitudes incorrectas. Si tiene que decirle cómo se ven las malas solicitudes, seguramente será inútil. En otras palabras, podría proteger contra ataques de desbordamiento del búfer, pero no de la inyección SQL.

Sobre todo, parece un teatro de seguridad. Contrató a un consultor de seguridad, y tienen que decirle algo que debe hacer para mejorar su seguridad. Es muy poco probable que un atacante rompa el proxy inverso y si simplemente lo omiten, siempre pueden culparlo; Es una recomendación segura.

Básicamente, los proxies inversos ocultarán su infraestructura del mundo. Por lo tanto, es principalmente un caso de seguridad por oscuridad, a menos que su servidor web sea realmente inmanejable y no esté seguro.

También puede proteger sus servidores web de algún tipo de DOS (denegación de servicio distribuida), especialmente si su sitio web es "pesado", actuando como una capa de almacenamiento en caché.

También tiene algunas trampas: ocultará de su aplicación la IP real del cliente. Te hará consumir más energía del servidor y agregará una capa de cosas que pueden romperse. Recuerde que su proxy inverso tendrá que manejar más conexiones (generalmente dos veces más: conexiones a clientes y conexiones a su servidor web).

Al final del día, un proxy inverso no te ahorrará tener un sitio web seguro de todos modos.

Creo que Zoredache ha dado una muy buena respuesta en cuanto a los beneficios que puede proporcionar un proxy inverso. He usado Pound, que es un proxy inverso, equilibrador de carga y frontend HTTPS.

http://www.apsis.ch/pound/

Un beneficio del que no creo que nadie más haya hablado es el hecho de que no tiene que abrir ningún IP / puerto externo a través de su firewall externo. Un buen sistema de proxy inverso iniciará la comunicación desde el interior de su red al servidor en la DMZ protegiendo las redes contra ataques directos. Esto, sin embargo y como han dicho otros, no lo protegerá contra una aplicación mal escrita.