Mejores prácticas documentadas para la implementación de proxy inverso

Question

Mejores prácticas documentadas para la implementación de proxy inverso

#1 de mr.spuratic (9 votos)

8

Estoy buscando documentación sobre las mejores prácticas para la implementación de un proxy inverso.

Necesitamos permitir el acceso de una base de datos interna / servidor web al mundo exterior y estamos tratando de determinar el método más eficiente y seguro para lograrlo.

Ya tenemos un servidor Red Hat 2 que ejecuta una configuración mod Apache proxy, pero queremos echar un vistazo a las mejores prácticas de hoy (ya que este servidor es antiguo).

He buscado en Google bastante y, hasta el momento, no he podido encontrar nada menos que consejos extremadamente generales relacionados con las mejores prácticas de seguridad comunes.

Apreciaría enormemente cualquier cosa que pudieras proporcionar.

Gracias! Erik

proxy http-proxy

pregunta Irongrave 09.01.2014 - 17:44

fuente

1 respuesta

Lea otras preguntas en las etiquetas proxy http-proxy

¿Cómo usar el cifrado en un sitio que solo usa una dirección IP, no hay un nombre de dominio? ¿Por qué confiamos en la información de la sesión por el cable pero no en un token de acceso OAuth?

score 9 · Answer 1

NIST SP 800-44 Pautas para proteger servidores web públicos es un buen punto de partida, aunque no es una bala mágica (y tiene algunos años).

En mi experiencia, algunos de los requisitos y mitigaciones más importantes, sin ningún orden en particular, son:

Asegúrese de que su servidor proxy, servidores de back-end web (y DB) no puedan establecer conexiones directas de salida (Internet) (incluyendo DNS y SMTP, y particularmente HTTP). Esto significa proxy (reenvío) / retransmisiones para el acceso de salida requerido, si es necesario.
Asegúrese de que su registro sea útil (§9.1 en lo anterior) y coherente . Es posible que tenga registros de varios dispositivos (enrutador, firewall / IPS / WAF, proxy, servidores web / aplicaciones, servidores DB). Si no puede enlazar registros de forma rápida, confiable y determinista a través de cada dispositivo, lo está haciendo mal . Esto significa NTP, y el registro de cualquiera o todos: PID, TID, ID de sesión, puertos, encabezados, cookies, nombres de usuario, direcciones IP y quizás más (y puede significar que algunos registros contienen información confidencial).
Comprenda los protocolos y tome decisiones deliberadas e informadas: incluida la opción de versión de cifrado / TLS, tamaños de encabezado HTTP, longitudes de URL, cookies. Los límites deben implementarse en el proxy inverso. Si está migrando a una arquitectura escalonada, asegúrese de que el equipo de desarrollo esté en el circuito para que los problemas se detecten lo antes posible.
Realice exploraciones de vulnerabilidades desde el exterior o haga que alguien lo haga por usted. Asegúrese de que conoce su huella y de que los informes resaltan los deltas, así como el TLS SNAFU du-jour teórico.
Comprende los modos de falla. Enviar a los usuarios un valor por defecto "HTTP 500 - las ruedas se desprendieron" cuando tiene problemas de carga o de estabilidad es descuidado
Monitoreo, métricas y gráficos: tener datos normales e históricos es invaluable cuando se investigan anomalías y para la planificación de la capacidad.
Ajuste: desde el tiempo de espera de TCP para escuchar el registro de las cookies de SYN, nuevamente debe tomar decisiones deliberadas e informadas.
Siga las pautas básicas de fortalecimiento del SO, considere el uso de chroot / jails, IDS basados en host y otras medidas, donde estén disponibles.