TURNKEYGNU / LINUX
Português

Documentação

TurnKey Linux appliances atrás de um proxy reverso

A 'proxy' inverso é um servidor que se situa entre um ou mais servidores "reais" que servem o conteúdo desejado e outra rede, muitas vezes a Internet. alta disponibilidade (por exemplo, fall over servers se seu servidor principal falhar) e/ou uma maneira de hospedar vários servidores através de um único IP (geralmente público), muitas vezes incluindo terminação SSL/TLS. Aproveitar um único IP para hospedar vários servidores é bastante comum quando "self hosting" (como muitos usuários TurnKey fazem).

A configuração da rede parece-se um pouco com isto:

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

Contexto e visão geral

Há uma vasta gama de proxies inversos construídos para fins, além de servidores web comuns, como Apache, Nginx e LigHTTPd podem ser configurados para atuar como um proxy reverso. Como tal, este post não procura fornecer nenhuma recomendação de software, nem cobrir exaustivamente configuração específica de software. Quando menciona a configuração, geralmente será limitado a Apache e/ou Nginx - como os servidores web mais populares. Ele tocará em algumas configurações específicas para casos de uso limitado, mas geralmente vai ter um olhar de nível mais elevado no design geral da rede e considerações. O objetivo principal desta página é examinar e explicar as diferentes opções de conexão entre o proxy reverso e os servidores de infraestrutura. Ele vai focar principalmente na configuração/design da conexão entre o proxy inverso e os servidores de infraestrutura.

Historicamente, a forma padrão de configurar um proxy reverso é fazer o término do TLS/SSL (i.e. https) no proxy reverso e usar apenas baunilha http (i.e. tráfego "texto simples" não criptografado entre o proxy reverso e servidores de infraestrutura. Isso funciona bem e se a rede de infraestrutura estiver isolada de qualquer ator potencialmente malicioso ou dispositivo comprometido, ela também pode ser segura o suficiente.

No entanto, hoje em dia, esse tipo de configuração é geralmente considerado inseguro. Isso porque usar o simples http permite que qualquer coisa/qualquer pessoa com acesso à rede para bisbilhotar o tráfego da rede e interceptar dados sensíveis, como senhas. Também como não existe nenhum mecanismo para confirmar a identidade de um servidor via http, a MITM O ataque é trivial.

Como tal, geralmente é recomendável usar a comunicação https entre seu proxy reverso e seus servidores de infraestrutura. Mas mesmo que possa ser configurado de várias maneiras diferentes, cada uma fornecendo seu próprio conjunto de vantagens e desvantagens. Independentemente disso, vamos dar uma olhada rápida nas opções. Espero que todos os importantes e comuns sejam mencionados, mas esta não será uma lista exaustiva.

As opções

Todas as opções fazem compromissos entre segurança e esforço necessários. Eu já forneci uma visão geral e de nível superior das opções, mas vamos ser um pouco mais específicos e decompô-las um pouco mais. Aqui estão as opções comuns que vejo, em uma ordem vaga de menos seguro para mais mais (algumas das classificações são discutíveis). Então vamos mergulhar em cada um um pouco mais de esforço de observação necessária.

  • http - não criptografado, http simples
  • https - certificado auto- assinado; certificado ignorado pelo proxy reverso
  • https - certificado auto- assinado & CA; certificado verificado por proxy inverso
  • https - Certificado de caracteres curinga assinado "properto" CA; certificado verificado por proxy reverso
  • https - Certificado específico assinado "property" CA; certificado verificado por proxy reverso

http - não criptografado, http simples

Como observado acima, este é o "padrão" histórico configurado. Uma vez configurado, geralmente "apenas funciona" e continua a fazê-lo "para sempre" sem qualquer intervenção necessária. Era uma vez que também era super fácil configurar; como a maioria dos servidores foram frequentemente projetados fora da caixa para hospedar via http.

No entanto, como o tráfego está sendo transmitido sem criptografia, qualquer ator/dispositivo malicioso na mesma rede que o servidor de infraestrutura seria facilmente capaz de interceptar tráfego (por exemplo, .steal passwords, etc, talvez pior). Também não existe validação de que o servidor de infra- estrutura, tornando os ataques MITM triviais.

No que diz respeito ao esforço, se você está construindo todos os seus próprios servidores do zero, então isso provavelmente requer o menor esforço. Embora se você estiver usando TurnKey, ele dependerá do appliance específico. Muitos dos nossos redirecionamentos appliances para https, pelo menos para fazer login (para reduzir o risco de xerox). Muitos deles também exigem ser capazes de se conectar através de um domínio predefinido específico, então irá redirecionar para isso FQDN por padrão. O redirecionamento do domínio provavelmente não será um problema e geralmente seu proxy reverso só permitirá conexão via domínio, de modo que não deve ser um problema. No entanto, obviamente, redirecionar http para https (quando apenas a conexão http é suportada) causará problemas.

Em resumo, embora não seja uma configuração particularmente segura, assumindo que você confia em todas as pessoas e dispositivos que podem se conectar à rede onde os servidores de backend residem, eu acho que é uma configuração completamente legítima.

Como

Para fazer com que esta configuração funcione com um servidor de infraestrutura TurnKey (ou outro servidor que redireciona http para https), você precisará desativar o redirecionamento https. Na verdade, é provavelmente razoável desabilitar completamente os https. Na configuração Apache, procure por linhas que comecem com "Reescrever" ou "Redireccionar" na máquina virtual porta 80. No Nginx, procure novamente redirecionamentos na configuração do servidor virtual do porto 80; procure por linhas iniciando "retorno 30x" (onde x é número) ou 'redirect".

https - certificado auto- assinado; certificado ignorado pelo proxy reverso

Usando esta opção, seus servidores de infraestrutura são acessados pelo proxy reverso via https, mas eles apenas usam certificados auto assinados (os que dão avisos assustadores em sua web Este modelo de configuração é uma atualização de segurança, pois significa que o tráfego está criptografado, então o bisbilhotamento está bloqueado. No entanto, como não há validação de que o servidor de infraestrutura é o que você pensa que é, os ataques MITM ainda são viáveis (e tão fácil quanto com o simples http).

Esta opção exigirá um pouco mais de trabalho na sua configuração de proxy reversa e há uma possibilidade de que algum software de proxy reverso específico não suporte esta abordagem. Dito isto, a maioria dos proxies reversos deve suportar esta opção, todos os principais servidores web certamente fazem. Se usar o TurnKey como servidor(s) de infraestrutura, isso deve exigir zero esforço no servidor de infraestrutura e deve "apenas funcionar" - embora se houver um redirecionamento para o domínio, você irá precisa garantir que você também não faça isso na extremidade da fonte - que pode causar um loop recursivo de redirecionamento.

Como

Toda a configuração necessária para fazer este trabalho precisa ser feita no proxy reverso. O AFAIK Nginx é padrão para este comportamento - ou seja, para o seu próprio usuário, é necessário que o usuário faça o proxy reverso. ignora o facto de que os certificados são certificados auto assinados e se conectam de qualquer forma. Para mais informações, configure o Nginx, verifique a Documentos de directiva.

O Apache precisa de uma configuração adicional. Não vou entrar em detalhes, mas vou precisar de usar Directivas SSLProxi*, tais como SSLProxyCheckPeerCN e SSLProxyCheckPeerName.

https - certificado auto- assinado & CA; certificado verificado por proxy inverso

Esta opção é uma atualização de segurança adicional, pois além da opção anterior, a validação também ocorre. Usando esta opção significa que tanto os ataques de bisbilhotamento quanto os ataques MITM não são viáveis. O lado negativo é que é preciso um pouco de esforço extra, pois você precisa gerar uma chave CA (autoridade certificado) e (re)gerar certs auto assinados, assinados por sua chave CA. A chave CA (público) também precisa ser armazenada no proxy reverso.

Os riscos são que se a chave privada da CA pode ser encontrada por um ator malicioso, então eles também podem gerar seus próprios certificados que funcionarão com seu proxy reverso. Isso pode ser atenuado gerando e armazenando os certificados necessários em outro lugar (por exemplo, um terceiro servidor) e não permitindo qualquer acesso à chave privada da CA. Outra mitigação é garantir que desbloquear o par de chaves CA também requer uma frase-passe. Então um atacante também precisaria saber a senha, bem como ter acesso à chave privada. Com essas mitigação no lugar, esta opção é provavelmente o mais seguro que você pode obter. Como você controla a CA, os certificados podem ser extremamente longos se desejar (o que significa que raramente precisaria ser atualizado). Ou você pode configurar o terceiro servidor para que ele envie certificados atualizados para o servidor de infraestrutura automaticamente (embora reduza o valor de uma frase- senha).

Como

Eu sei que esta opção está disponível tanto para Apache e Nginx. Infelizmente eu não tenho as diretivas específicas necessárias à mão, mas eles quase certamente conterão "ssl" e provavelmente "ca" (e provavelmente "proxy) em seu nome(s). Como observado acima, como Nginx não autentica certificados por padrão, você gostaria de habilitar isso.

https - Certificado de caracteres curinga assinado "properto" CA; certificado verificado por proxy reverso

Um certificado "wildcard" é um certificado especial TLS/SSL que é válido para vários subdomínios. Por exemplo. um certificado wildcard para *.example.com seria válido para www.example.com, docs.example.com e blog.example.com (etc). Usar certificados wildcard em seus servidores de infraestrutura tem um perfil de segurança semelhante às opções imediatas acima e abaixo, embora a vaildation seja genérica, em vez de específica. Ou seja. enquanto o certificado será validado, você não pode ter certeza de qual servidor de infraestrutura você está conectando. Ainda deve ser bastante seguro, embora se um atacante ganha acesso a um de seus servidores de infraestrutura, eles podem roubar o certificado wildcard e usá-lo para fazer algum outro servidor/serviço "válido".

Como

Além de um mecanismo para obter e distribuir novos certificados quando eles são atualizados, não deve haver nenhuma configuração adicional necessária. Embora como eu notei acima, Nginx não autentica certificados por padrão, então você vai querer habilitar isso.

https - Certificado específico assinado "property" CA; certificado verificado por proxy reverso

Nos tempos modernos, onde temos serviços como Let's Encrypt, IMO esta é a opção mais fácil e melhor. Você obtém os benefícios de um proxy reverso, com a segurança de um servidor "standalone" com seu próprio certificado legítimo assinado pela CA. Esta é uma opção particularmente boa se houver alguma chance de que este servidor possa ser movido para ser diretamente voltado para o público. Você poderia permitir o acesso direto do público com zero alterações e ele deve "apenas trabalhar" (e ainda estar seguro).

Como seu servidor de infraestrutura terá seu próprio certificado legítimo assinado pela CA, as conexões https serão válidas e devem "apenas funcionar". Você também obtém a segurança adicional de uma conexão criptografada totalmente autenticada para "livre".

Como

Para o servidor de infraestrutura TurnKey, você pode alavancar Menu Avançado do Confconsole para obter um certificado Let's Encrypt "adequado". A validação padrão (HTTP-01) requer acesso à porta 80 também, mas isso não deve exigir muita configuração adicional em seu proxy reverso. A validação de autoridade de domínio também pode ser feita via DNS (DNS-01) que é uma opção alternativa (que também suporta DNS-01), embora IMO HTTP seja mais fácil.