it-swarm-es.com

¿Se debe terminar SSL en un equilibrador de carga?

Cuando se aloja un clúster de servidores de aplicaciones web, es común tener un proxy inverso (HAProxy, Nginx, F5, etc.) entre el clúster y la Internet pública para equilibrar la carga del tráfico entre los servidores de aplicaciones. Para realizar una inspección profunda de paquetes, SSL debe terminarse en el equilibrador de carga (o anterior), pero el tráfico entre el equilibrador de carga y los servidores de aplicaciones no se cifrará. ¿La terminación anticipada de SSL no dejaría a los servidores de aplicaciones vulnerables al rastreo de paquetes o al envenenamiento por ARP?

¿Se debe descargar SSL? Si es así, ¿cómo se puede hacer sin comprometer la integridad de los datos que se sirven? Mi principal preocupación es una aplicación web donde el cifrado de la capa de mensajes no es una opción.

99
Matt Goforth

Me parece que la pregunta es "¿confía en su propio centro de datos". En otras palabras, parece que está tratando de dibujar con precisión la línea donde se encuentran las redes no confiables y comienza la confianza .

En mi opinión, la confianza SSL/TLS debería terminar en el dispositivo de descarga SSL ya que el departamento que administra ese dispositivo a menudo también administra la red y la infraestructura. Hay una cierta cantidad de confianza contractual allí. No tiene sentido cifrar datos en un servidor posterior, ya que las mismas personas que respaldan la red generalmente también tienen acceso a esto. (con la posible excepción en entornos de múltiples inquilinos o requisitos empresariales únicos que requieren una segmentación más profunda).

Una segunda razón por la que SSL debería terminar en el equilibrador de carga es porque ofrece un lugar centralizado para corregir ataques SSL como CRIMEN o BESTIA . Si SSL se termina en una variedad de servidores web, si se ejecuta en diferentes sistemas operativos, es más probable que tenga problemas debido a adicionalcomplejidad . Hazlo simple y tendrás menos problemas a largo plazo.

Habiendo dicho eso

  1. Sí, terminar en el equilibrador de carga y la descarga SSL allí. Mantenlo simple.
  2. El equilibrador de carga de Citrix Netscaler (por ejemplo) puede denegar el acceso inseguro a una URL. Esta lógica de política, combinada con las características de TLS debería garantizar que sus datos permanezcan confidenciales y libres de alteraciones (dado que entiendo adecuadamente su requisito de integridad)

Editar:

Es posible (y común)

  • Subcontrata el equilibrador de carga (Amazon, Microsoft, etc.)
  • Use un CDN de terceros (Akamai, Amazon, Microsoft, etc.)
  • O use un proxy de terceros para evitar ataques DoS

... donde el tráfico de ese tercero se enviaría a sus servidores a través de enlaces de red que no administra. Por lo tanto, es posible que no confíe en esos enlaces no cifrados. En ese caso, debe volver a cifrar los datos, o al menos hacer que todos esos datos viajen a través de una VPN de punto a punto.

Microsoft ofrece un producto VPN de este tipo y permite la externalización segura del perímetro.

78

Sí, diría que TLS debería descargarse. He hecho todo lo que menciono a continuación específicamente con Citrix Netscaler, pero creo que F5 debería ser capaz de hacer lo mismo.

Primero, siempre debe asegurarse de volver a encriptar en el otro lado del equilibrador de carga, pero el dispositivo que desencripta TLS debería poder inspeccionar lo que está sucediendo desde una perspectiva de seguridad. La integridad de los datos no debe verse comprometida por este enfoque.

Muchas personas me han dicho que la reencriptación en el back-end hace que sea computacionalmente costoso, pero eso no es cierto. El gasto con TLS es la construcción y el cierre de la conexión, que maneja el descargador TLS. En el backend, tiene una conexión más persistente con los servidores y, por lo tanto, los recursos necesarios son mucho más bajos.

Además, si no tiene descarga de TLS, incluso un pequeño ataque DDoS a través de TLS aniquilaría por completo sus servidores. Estoy muy familiarizado con esta situación y la descarga de TLS es una ayuda increíble desde una perspectiva computacional, y también le permite bloquear ataques más adelante en la cadena. Para ataques DDoS extremadamente grandes, incluso podría dividir su estrategia de mitigación entre su cargador TLS y sus servidores.

18
JZeolla

Para inspeccionar los datos que van dentro de una conexión SSL, cualquiera de estos debe ser cierto:

  • El túnel termina en la máquina que realiza la inspección, p. su "equilibrador de carga".
  • El sistema de inspección conoce una copia de la clave privada del servidor, y la conexión SSL no utiliza Diffie-Hellman efímera (es decir, el servidor no permite los conjuntos de cifrado que contienen "DHE" en su nombre).

Si sigue la primera opción, los datos viajarán sin cifrar entre el sistema de inspección (el equilibrador de carga) y los clústeres, a menos que lo vuelva a cifrar con algún otro túnel SSL: la conexión SSL principal es entre el navegador del cliente y el equilibrador de carga, y la carga el equilibrador mantiene un enlace SSL (o alguna otra tecnología de cifrado, por ejemplo, una VPN con IPsec ) entre sí mismo y cada uno de los nodos del clúster.

La segunda opción es algo más ligera, ya que el inspector de paquetes simplemente descifra los datos pero no tiene que volver a cifrarlos. Sin embargo, esto implica que todos los nodos del clúster pueden hacer el SSL completo con el cliente, es decir, conocer una copia de la clave privada del servidor. Además, no admitir DHE significa que no obtendrá la característica ingeniosa de Perfect Forward Secrecy (esto no es fatal, pero PFS se ve muy bien en las auditorías de seguridad, por lo que es bueno tenerlo).

De cualquier manera, el nodo que realiza la inspección profunda de paquetes debe tener algún acceso privilegiado al túnel SSL, lo que lo hace bastante crítico para la seguridad.

7
Tom Leek

Yo recomendaría la terminación de SSL en el equilibrador de carga (ya sea en su red, o en un proveedor de CDN o lo que sea). Significa que el LB puede inspeccionar el tráfico y puede hacer un mejor trabajo de equilibrio de carga. También significa que su equilibrador de carga es responsable de lidiar con clientes lentos, implementaciones SSL rotas y fallas generales de Internet. Es probable que su equilibrador de carga tenga más recursos para hacerlo que sus servidores de back-end. También significa que los certificados SSL que el mundo ve están todos en el equilibrador de carga (lo que con suerte los hace más fáciles de administrar).

La alternativa aquí es simplemente equilibrar la carga de las conexiones TCP de los clientes a sus servidores back-end. Como el LB no puede inspeccionar lo que está sucediendo de esta manera, no puede distribuir la carga de manera uniforme en todas partes los servidores de back-end y los servidores de back-end tienen que lidiar con todas las fallas de Internet. Solo usaría este método si no confía en su equilibrador de carga, proveedor de CDN o lo que sea.

Si vuelve a cifrar o no desde el equilibrador de carga a sus servidores de back-end es una cuestión de elección personal y circunstancia. Si está lidiando con tarjetas de crédito o transacciones financieras, entonces probablemente esté regulado por los gobiernos y, por lo tanto, tendrá que volver a cifrar. Probablemente también debería volver a cifrar si el tráfico entre el equilibrador de carga y los servidores de back-end viaja a través de redes no confiables. Si solo está alojando el sitio web de su empresa, es posible que pueda evitar la sobrecarga adicional del nuevo cifrado, si realmente no le importan los aspectos de seguridad del mismo.

Sin embargo, volver a cifrar no agrega tanta carga como podría pensar. Por lo general, el equilibrador de carga podrá mantener conexiones persistentes a los servidores, por lo que el costo de SSL será bastante bajo para ese 'salto' en la red.

Lo último en lo que debe pensar es en la aplicación en los servidores de servicios de fondo. Si todo el tráfico que llega allí es HTTP, entonces no puede tomar decisiones basadas en el protocolo que estaba usando el cliente. Entonces no puede decir "estás intentando acceder a la página de inicio de sesión a través de HTTP, por lo que te redirigiré a la versión HTTPS de la página", por ejemplo. Puede hacer que el equilibrador de carga agregue un encabezado HTTP para decir "esto vino de HTTPS", pero ese encabezado necesitaría un manejo especial en la aplicación. Dependiendo de su situación, puede ser más fácil volver a encriptar y dejar que la aplicación funcione de manera 'predeterminada' en lugar de necesitar una modificación específica del sitio.

En resumen, diría: terminar en el equilibrador de carga y volver a cifrar en sus servidores de fondo. Si hace esto y nota algún problema, puede hacer ajustes si es necesario.

6
Ralph Bolton

Puede elegir cifrar el tráfico interno con un certificado de clave inferior. Y también se recomienda colocar su equilibrador de carga lo más cerca posible de sus servidores para evitar la detección o ataques de intermediarios. La terminación de SSL se puede hacer en Load Balancer para descargar los trabajos intensivos de la CPU fuera de los servidores web. Si la marca LB que ha elegido puede realizar ciertas funciones, como inspeccionar conexiones de protocolo mal formadas, detectar el comportamiento DDoS, etc.

1
Davis