Tengo un Firewall, luego un LoadBalancer (equilibrador de carga IIS-ARR) y 2 servidores web IIS. Los 2 servidores web IIS estarán en LAN con IP privadas. Mi sitio web está alojado en ambos servidores web. Mi desafío real es que tengo una pasarela de pago en mi sitio web y funcionará como se esperaba solo si la solicitud llega al sitio web desde el nombre del sitio web (comowww.abc.com) o IP estática pública configurada para el equilibrador de carga IIS-ARR.
Tengo 4 consultas:
Cuando la solicitud http es manejada por cualquiera de los 2 servidores web, la solicitud provendrá del nombre del sitio web/IP estática pública asignada al balanceador de carga. O será la IP privada del servidor web.
¿La descarga de SSL en el balanceador de carga IIS-ARR es propensa a cualquier ataque ya que la solicitud http fluye desde el balanceador de carga al servidor real en texto sin cifrar dentro de la LAN?
Dónde crear una solicitud SSL CSR para mi sitio web. En el servidor IIS-ARR o cualquiera de los dos servidores web. Cuántos certificados SSL se requieren.
Cómo conservar https (SSL) durante toda la solicitud. Desde el navegador del cliente hasta el firewall, luego el equilibrador de carga y luego el servidor real. (Sin descarga SSL)
Respuesta1
1. El cliente esperará que la respuesta provenga de la misma sesión SSL que cree que ha iniciado con la dirección externa del firewall.
El cliente no sabe si el firewall pasa la secuencia tcp a un dispositivo diferente, como un equilibrador de carga con terminación SSL. Tampoco sabe si el balanceador de carga pasa la sesión SSL terminada a un servidor backend interno (independientemente de si el balanceador de carga pasa los datos al servidor backend en formato https recifrado o http sin cifrar). El cliente simplemente sabe que de alguna manera estableció una sesión SSL con una dirección IP, que resulta ser la IP externa de un firewall.
A través de las capas de firewall y equilibrador de carga y terminaciones SSL, la solicitud llega hasta un servidor backend. Sin embargo, mientras el backend prepara la respuesta, si el servidor backend mira la dirección IP del remitente y ve la dirección IP externa del cliente allí, responderá directamente a la dirección IP del cliente. Una respuesta enviada directamente desde el backend al cliente se recibiría fuera de la sesión SSL en la que el cliente inició y envió la solicitud. El cliente, naturalmente, no espera tal respuesta y la rechazará.
Entonces, para garantizar que la respuesta llegue a través de la sesión SSL iniciada por el cliente, el equilibrador de carga debe modificar la solicitud antes de pasarla al servidor backend.
Primero descifra la sesión SSL del cliente, luego modifica la solicitud original para que la dirección IP de origen se sobrescriba con una dirección IP de origen que pertenece al equilibrador de carga, antes de enviar la solicitud al servidor backend.
El servidor backend ahora cree que la solicitud se originó en el balanceador de carga y envía su respuesta al balanceador de carga en lugar de al cliente original.
El balanceador de carga vuelve a modificar los datos, de modo que la respuesta parece provenir del balanceador de carga en lugar del servidor backend. Después de lo cual, el equilibrador de carga cifra los datos para que estén dentro de la misma sesión SSL que ha establecido con el cliente y procede a enviar la respuesta directamente al cliente.
El cliente acepta esto felizmente y no se da cuenta de las rutas de red reales tomadas para producir la respuesta.
Estas modificaciones de IP realizadas por el equilibrador de carga se denominanNAT de origen(SNAT) y son comunes a todos los balanceadores de carga con los que he trabajado.
Por brevedad no he incluidolas traducciones del firewall entre espacios de direcciones públicos y privados. Sugiero separar esa pregunta por completo para no confundir la reescritura realizada por el firewall con la reescritura realizada por el balanceador de carga. Esto ya que la reescritura del firewall se puede hacer de varias maneras y merece su propia pregunta, una vez que se ha decidido o reducido la elección de la marca del firewall. Hasta entonces, piense en ello como magia que simplemente sucede en el firewall cuando cada paquete entrante o saliente pasa a través de él.
Una forma sencilla de verificar una configuración correcta como se describe anteriormente sería comenzar usando un cliente interno y configurar sesiones http no cifradas entre el cliente y el balanceador de carga, así como entre el balanceador de carga y los servidores backend.
Usar un rastreador de paquetes comoWiresharken el cliente, el equilibrador de carga y el backend, se puede ver el efecto de estas reescrituras en la práctica para cualquier par de solicitud/respuesta determinado y para cada una de las partes de la red.
Una vez que la configuración esté funcionando y se comprenda el proceso, se puede cifrar primero la ruta del cliente al balanceador de carga y luego la ruta del balanceador de carga al backend. Esto como sugerencia para facilitar la curva de aprendizaje y promover una configuración final correcta.
Una advertencia radica en la percepción de las solicitudes por parte del servidor backend.
Independientemente de la cantidad real de clientes externos, el backend verá y registrará solo un cliente: la dirección SNAT del balanceador de carga interno.
Este dilema se produce haciendo que el balanceador de carga haga SNAT a las solicitudes y se resuelve haciendo que el balanceador de carga informe al servidor backend de la dirección IP externa real del cliente. A medida que se modifica la IP de origen de la solicitud, la información de la dirección IP real del cliente se pasa al backend insertando un encabezado http en la solicitud http.
El encabezado puede tener cualquier nombre válido que aún no esté en uso; una opción común esX-ENVIADO-PARA.
Configurar el equilibrador de carga para insertar dicho encabezado es el primer requisito para que esta solución funcione; el segundo requisito es informar al servidor backend de la presencia de este encabezado. La configuración es específica de las marcas de equilibrador de carga y servidor backend, que se puede buscar fácilmente en Google.AquíPor ejemplo, se muestra cómo configurar un backend de Tomcat para iniciar sesión desde x-forwarded-for. Ha pasado mucho tiempo desde la última vez que configuré un ARR y no puedo recordar cómo se agregó x-forward-for, pero recuerdo que fue necesario experimentar un poco y buscar en Google para comenzar a trabajar.
2) Sí, como el tráfico puede ser detectado por un decodificador de protocolo como Wireshark, como se sugirió anteriormente, existe un vector de ataque.
Esto supone que un atacante tiene acceso al tráfico de la red.
Si el tráfico del balanceador de carga al backend se envía en texto claro, solucionar problemas de configuración incorrecta del balanceador de carga o del servidor backend es más fácil, pero conlleva el riesgo antes mencionado.
Cómo tomar esta decisión de diseño es una discusión que vale la pena tener tanto internamente como con las partes interesadas externas.
3) La CSR se realiza comúnmente cuando se termina SSL.
Para cifrar el tráfico del cliente al balanceador de carga, cree la solicitud csr en el balanceador de carga.
Para cifrar el tráfico del equilibrador de carga al backend, cree el csr en el servidor backend.
Hay formas de exportar tanto un certificado firmado como una clave privada correspondiente como un paquete, que se puede importar en un servidor diferente. Esto es útil para configurar un clúster de balanceador de carga donde se desea que todos los miembros presenten el mismo certificado, o para configurar varios backends idénticos para simplificar la configuración SSL del cliente del balanceador de carga (es decir, donde el balanceador de carga funciona como un cliente SSL para el servidor backend). ya que vuelve a cifrar los datos http).
4) Decida dónde se debe realizar la terminación del SSL del cliente.
Es posible finalizar SSL en algunos firewalls, pero lo más común es simplemente reenviar el flujo tcp a través del firewall al balanceador de carga que luego finaliza la sesión SSL del cliente.
También es posible que el balanceador de carga equilibre flujos tcp puros en los que el servidor backend termina ssl. Esto es poco común y no exploraré la opción aquí.
Una vez que se haya finalizado el SSL inicial, decida si los datos deben volver a cifrarse, por ejemplo, entre el equilibrador de carga y el siguiente salto. El siguiente salto puede ser un servidor backend u otro equilibrador de carga o...
Repita hasta que llegue el paso en el que se deben enviar los datos de forma clara o hasta llegar al último servidor de la cadena.
La terminación de SSL es un requisito para que el balanceador de carga pueda, por ejemplo, insertar un encabezado http x-forwarded-for o hacer otras cosas que requieran acceso a datos de texto sin cifrar. Por lo tanto, es común finalizar SSL antes del balanceador de carga, en el balanceador de carga o en ambos.
También es común tanto enviar tráfico a los backends cifrado como enviarlo sin cifrar. Simplemente depende de las circunstancias de la organización y de la finalidad de los datos enviados.
Descarga SSLes solo un término que describe un proceso en el que una pieza de tecnología realiza el cifrado/descifrado SSL en lugar de otra pieza de tecnología.
Puede ser un equilibrador de carga que descifra SSL y pasa texto sin cifrar a un backend; el backend se ha descargado SSL.
Puede ser un equilibrador de carga que tenga circuitos de hardware especializados dedicados al cifrado/descifrado SSL: la CPU del equilibrador de carga se ha descargado SSL. Etcétera...