TurnKey Linux appliances detrás de un proxy inverso

A inversor es un servidor que se encuentra entre uno o más servidores "real" que sirven el contenido deseado y otra red, a menudo el Internet. Se puede utilizar para proporcionar alta disponibilidad (por ejemplo, caer sobre servidores si su servidor principal se bloquea) y/o una manera de albergar varios servidores a través de un IP único (generalmente público), a menudo incluyendo la terminación SSL/TLS. Aprovechar un solo IP para albergar un servidor múltiple es bastante común cuando "auto hosting" (como muchos usuarios de TurnKey lo hacen).

La configuración de la red se ve un poco así:

                                                backend server 1
                                               /
internet/external network <-> reverse proxy <-> backend server 2
                                               \
                                                backend server 3

Contexto y panorama general

Hay una gran variedad de proxies inversos construidos con propósito, más servidores web comunes, como Apache, Nginx y LigHTTPd pueden configurarse para actuar como un proxy inverso. Como tal, este post no busca proporcionar ninguna recomendación de software, ni cubrir exhaustivamente la configuración específica del software. Cuando menciona el config, generalmente se limitará a Apache y/o Nginx - como los servidores web más populares. Se tocará en algunos config específicos para casos de uso limitado, pero generalmente tomará una mirada de nivel más alto en el diseño y consideraciones de red general. El objetivo principal de esta página es examinar y explicar las diferentes opciones de conexión entre el proxy inverso y los servidores backend. Se centrará principalmente en la configuración/diseño de la conexión entre el proxy inverso y los servidores backend.

Históricamente, la forma predeterminada de configurar un proxy inverso es hacer TLS/SSL (es decir, https) terminación en el proxy inverso y simplemente utilizar vainilla http (es decir,. tráfico "texto de texto" no cifrado) entre los servidores proxy y backend inversos. Funciona bien y si la red de backend está aislada de cualquier agente potencialmente malicioso o dispositivos comprometidos, también puede ser suficientemente segura.

Sin embargo, en estos días ese tipo de montaje generalmente se considera inseguro. Esto se debe a que el uso de la dirección http simple permite a cualquier persona con acceso a la red para snoop tráfico de red e interceptar datos sensibles como contraseñas. También como no hay mecanismo para confirmar la identidad de un servidor a través de http, a MITM El ataque es trivial.

Como tal, generalmente se recomienda utilizar la comunicación https entre su proxy inverso y sus servidores backend. Pero incluso eso puede configurarse de múltiples maneras diferentes, cada una que proporciona su propio conjunto de ventajas y desventajas. Independientemente, vamos a tener una mirada rápida a las opciones. Espero que todos los importantes y comunes sean mencionados, pero esto no será una lista exhaustiva.

Las opciones

Todas las opciones hacen que se requieran compromisos entre seguridad y esfuerzo. Ya he proporcionado una visión general y superior de las opciones, pero vamos a tener un poco más específico y descomponerlas un poco más. Aquí están las opciones comunes que veo, en un orden vago de menos seguro a más (algunos de los rankings son debatables). Entonces nos sumergimos en cada uno un poco más de notar esfuerzo requerido.

• http - unencrypted, plain http
• https - cert auto firmado; cert ignorado por proxy inverso
• https - cert & CA; cert verificado por proxy inverso
• https - "proper" CA firmó certificado de comodín; certificado verificado por proxy inverso
• https - "proper" CA firmó cert específico; cert verificado por proxy inverso

http - unencrypted, plain http

Como se ha señalado anteriormente, se ha establecido la histórica "default" que, una vez configurada, generalmente "sólo funciona" y continúa haciéndolo "antes" sin necesidad de intervención. Una vez en un momento también era súper fácil de configurar; como la mayoría de los servidores fueron diseñados fuera de la caja para ser anfitriones vía http.

Sin embargo, como el tráfico se transmite sin cifrar, cualquier actor/dispositivo malicioso en la misma red que el servidor backend podría interceptar fácilmente el tráfico (por ejemplo, .contraseñas de esteril, etc, quizás peor). También como no hay validación que el servidor de backend, haciendo que MITM ataca trivialmente.

En cuanto al esfuerzo, si usted está construyendo todos sus propios servidores desde cero, entonces esto probablemente requiere el menor esfuerzo. Aunque si está utilizando TurnKey, dependerá del appliance específico. Muchos de nuestros appliances se redirigen a https, al menos para iniciar sesión (para reducir el riesgo de la secuencia de contraseñas). Muchos de ellos también requieren poder conectarse a través de un dominio pre-set específico, por lo que se redirigirá a eso FQDN por defecto. La redirección de dominio probablemente no será un problema y generalmente su proxy inverso sólo permitirá la conexión a través del dominio para que no sea un problema. Sin embargo, obviamente la redireccion de http a https (cuando sólo se admite la conexión http) causará problemas.

En resumen, aunque no es un montaje particularmente seguro, asumiendo que usted confía en todos los dispositivos de la gente que pueden conectarse a la red donde residen los servidores backend, creo que que es una configuración completamente legítima.

Cómo

Para hacer que este conjunto funcione con un servidor de backend TurnKey (o otro servidor que redirige http a https), necesitará deshabilitar la red de https. De hecho, es probablemente razonable desactivar https por completo. En Apache config, busque líneas que comiencen con "Reescribir" o "Redirect" en el puerto 80 host virtual. En Nginx, busque de nuevo redirecciones en el puerto 80 configuración del servidor virtual; busque líneas que comiencen "return 30x" (donde x es número) o "redirecto".

https - cert auto firmado; cert ignorado por proxy inverso

Utilizando esta opción, los servidores de backend son accedidos por el proxy inverso a través de https, pero solo utilizan certificados auto firmados (los que dan advertencias aterradoras en su web navegador).Este modelo de configuración es una actualización de seguridad ya que significa que el tráfico está encriptado, por lo que el snooping está bloqueado. Sin embargo, como no hay validación de que el servidor de backend es lo que usted piensa que es, los ataques MITM todavía son viables (y tan fácil como con http).

Esta opción requerirá un poco más de trabajo en su configuración de proxy inversa y hay una posibilidad de que algún software de proxy inverso específico puede no apoyar este enfoque. Habiendo dicho que, la mayoría de los proxies inversos deben apoyar esta opción, todos los principales servidores web ciertamente lo hacen. Si utiliza TurnKey como servidor(s) de backend, esto debe requerir cero esfuerzo en su servidor de backend y debe "sólo trabajo" - aunque si hay una redireccion al dominio, usted va a necesidad de asegurar que no lo haga también en el extremo de la fuente - que puede causar un bucle redirecto recursivo.

Cómo

Todo el config requerido para hacer este trabajo necesita ser hecho en el proxy inverso. AFAIK Nginx predetermina este comportamiento - es decir. ignora el hecho de que los certs son certificaciones auto firmados y se conecta de todos modos. Para más información re Nginx config, verifique el direct docs.

Apache necesita un poco de configuración adicional. No voy a entrar en detalles, pero requerirá usar Directivas SSLProxy*, como SSLProxyCheckPeerCN y SSLProxyCheckPeerName.

https - cert & CA; cert verificado por proxy inverso

Esta opción es una actualización de seguridad adicional, ya que más allá de la opción anterior, también se produce validación. Usando esta opción significa que los ataques de snooping y MITM no son viables. La desventaja es que se necesita un poco de esfuerzo extra como usted necesita para generar una clave CA (certificate autoridad) y (re)generar certificaciones auto-firmados, firmadas por su clave CA. La clave de CA (pública) también necesita ser almacenada en el proxy inverso.

Los riesgos son que si la clave privada de CA puede ser encontrada por un actor malicioso, entonces también pueden generar sus propios certificaciones que trabajarán con su poder inverso. Esto puede mitigarse generando y almacenando los certificaciones requeridos en otro lugar (por ejemplo, un tercer servidor) y no permitiendo ningún acceso a la clave privada de CA. Otra mitigación es asegurar que el desbloqueo del par de claves CA también requiere una contraseña. Entonces un atacante también necesitaría conocer la contraseña, así como tener acceso a la llave privada. Con esas mitigacións en su lugar, esta opción es probablemente tan segura como usted puede conseguir. Como controla la CA, los certificados pueden ser de duración extrema si lo desea (lo que significa que rara vez necesita ser actualizado). O podría configurar el tercer servidor para que empuje certs actualizados al servidor backend automáticamente (aunque reduce el valor de una contraseña).

Cómo

Sé que esta opción está disponible tanto para Apache como para Nginx. Desafortunadamente no tengo las directivas específicas requeridas a mano, pero casi seguro que contendrán "sl" y probable "ca" (y probablemente "proxy) en sus nombres. Como se ha indicado anteriormente, como Nginx no autentica certificaciones por defecto, desea habilitar eso.

https - "proper" CA firmó certificado de comodín; certificado verificado por proxy inverso

Un certificado de "wildcard" es un certificado TLS/SSL especial que es válido para múltiples subdominios. a wildcard certificado para *.example.com sería válido para www.example.com, docs.example.com y blog.example.com (etc). Utilizando certificaciones de comodín en los servidores de backend tiene un perfil de seguridad similar a las opciones anteriores y siguientes, aunque la vaildación es genérica, en lugar de específica. Mientras que el certificado será validado, no puedes estar seguro de a qué servidor de backend estás conectando. Debe ser bastante seguro, aunque si un atacante obtiene acceso a uno de sus servidores backend, podrían robar el certificado de comodín y utilizarlo para hacer otro servidor/servicio "válido".

Cómo

Más allá de un mecanismo para obtener y distribuir nuevos certificados cuando se actualizan, no debe haber ningún configuración adicional requerido. Aunque como he señalado anteriormente, Nginx no autentica certificaciones por defecto, así que querrás habilitar eso.

https - "proper" CA firmó cert específico; cert verificado por proxy inverso

En los tiempos modernos, donde tenemos servicios como Let's Encrypt, IMO esta es la opción más fácil y mejor. Usted obtiene los beneficios de un proxy inverso, con la seguridad de un servidor "standalone" con su propio certificado firmado CA legítimo. Esta es una opción particularmente buena si hay alguna posibilidad de que este servidor pueda ser trasladado a una situación de frente público. Usted podría permitir el acceso público directo con cero cambios y debe "sólo trabajo" (y todavía estar seguro).

Como su servidor de backend tendrá su propio certificado firmado por CA legítimo, las conexiones https serán válidas y deben "sólo trabajar". También obtiene la seguridad adicional de una conexión encriptada totalmente autenticada para "gratis".

Cómo

Para el servidor de backend TurnKey, puede aprovechar Menú avanzado de Confconsole para obtener un certificado Let's Encrypt "proper" La validación predeterminada (HTTP-01) requiere acceso al puerto 80 también, pero eso no debe requerir demasiado config adicional en su proxy inverso. La validación de la autoridad de dominio también se puede hacer a través de DNS (DNS-01) que es una opción alternativa (que también admite DNS-01), aunque IMO HTTP es más fácil.