Implementaciones de código abierto o comunes para la seguridad de la aplicación web de proxy inverso

2

Comprendo que hay ya una pregunta similar a esta , pero esto es algo así como un seguimiento.

Entiendo que un servidor proxy inverso por sí mismo no es útil como medida de seguridad de la aplicación web porque simplemente "oculta" el servidor que está detrás de él, protegiéndolo de las huellas dactilares, posiblemente DDoS, yada yada. Sin embargo, creo que la implementación de say snort + squid podría lograr cierta seguridad a nivel de aplicación porque podría analizar el tráfico en busca de patrones de ataque comunes. Pero no he visto mucha información en la red sobre qué productos, proyectos de código abierto o incluso recetas para este tipo de sistema están disponibles.

La motivación para esta pregunta es que soy compatible con una aplicación OLD antigua que se basa en una versión de Apache2 muy modificada, insegura y no actualizable. NO PUEDO simplemente colocar mod_security2 en la configuración, no funcionará (no puedo hacer que las fuentes de esta distribución desordenada de apache para compilar mod_security2). Entonces, pensé que lo mejor sería implementar un tipo de solución de proxy inverso, ya que no solo solucionaría mi problema inmediato para esta aplicación heredada, sino que, si se configuraba correctamente, podía ver que se utilizaba para aplicaciones futuras como bien - la seguridad de la aplicación web central.

¿Mi modo de pensar es incorrecto? Si no está totalmente fuera de la base, debe haber algunas soluciones, productos, proyectos, recetas, etc. existentes por ahí. ¿Es squid + snort todo lo que necesito?

EDITAR: ¿Y cómo funciona todo esto cuando necesito hacer esto también con el tráfico cifrado?

    
pregunta tacos_tacos_tacos 24.09.2012 - 22:54
fuente

1 respuesta

3

El uso de mod_security como proxy inverso es común , especialmente en el mundo de IIS, donde solo recientemente se ha puesto a disposición un WAF gratuito. Apache ejecutándose como un proxy inverso manejará sus protocolos SSL, por lo que esto no será un problema.

Sin embargo, parece que tienes un PROBLEMA MUCHO MÁS GRANDE en tus manos. Si no puedes actualizar Apache estás completamente jodido. Le garantizo que hay explotaciones públicamente disponibles para su sistema. Hay nuevos sistemas de seguridad disponibles para Linux como AppArmor y SELinux, no tener estos es un error fatal.

No estoy seguro de por qué crees que está bien tener un sistema extremadamente antiguo y que ponerle una curita es un comportamiento aceptable. Si un experto en seguridad ve esto, van a cagar ladrillos. Un WAF no es de ninguna manera forma o sustituye a reparar vulnerabilidades conocidas en su sistema (período). Un WAF es solo otra capa, y usted debe planear el fracaso. (Y un WAF será el primero en caer porque generalmente es el más débil.)

    
respondido por el rook 25.09.2012 - 03:30
fuente

Lea otras preguntas en las etiquetas