Configure o Sophos Firewall Vamos criptografar certificados

Com Let’s Encrypt certificados no Sophos Firewall você pode criar certificados HTTPS públicos diretamente no firewall e renová-los automaticamente. Isso é particularmente útil para publicação WAF, WebAdmin, Portal do usuário, Portal VPN, Portal cativo, Portal SPX, páginas de login de hotspot e configurações SMTP TLS.

A função reduz o trabalho manual de certificação, mas não substitui o planejamento adequado. DNS, acessibilidade pública, porta 80, nomes de certificados, regras WAF, acesso ao portal e monitoramento devem corresponder. Se a validação ou renovação falhar despercebida, um portal ou aplicativo web publicado poderá falhar repentinamente com um aviso de certificado, apesar da regra WAF estar realmente correta.

Para a publicação propriamente dita de um servidor web, Sophos Firewall WAF: publique servidores web com segurança se ajusta primeiro. Este artigo se concentra no lado do certificado e na operação do Let’s Encrypt no firewall.

##Quando Let’s Encrypt faz sentido no firewall

O método Let’s Encrypt integrado faz sentido se o próprio Sophos Firewall fornecer o serviço público ou estiver na frente dele como um proxy reverso.

Nem todo serviço se enquadra nesse caminho. Para certificados curinga ou certificados que serão usados ​​em vários sistemas fora do firewall, um certificado gerado externamente é geralmente melhor. Existe o artigo existente Criar certificado curando Let’s Encrypt.

Limites e diferenças importantes

O Sophos Firewall cria certificados Let’s Encrypt para FQDNs específicos. A integração não é a mesma que um cliente ACME gerenciado gratuitamente em um servidor Linux.

Pontos importantes:

• O domínio deve ser especificado como um FQDN completo.
• Domínios curinga não são o caminho certo para o processo de firewall integrado.
• Os endereços IP não são nomes de certificados válidos.
• A validação do domínio HTTP deve ser capaz de alcançar o firewall através da porta 80.
• O firewall cria um servidor web temporário ou componentes WAF para validação.
• Após a emissão bem-sucedida, os componentes de validação temporários são removidos novamente.
• Os certificados têm vida curta e devem ser renovados automaticamente.

A Sophos introduziu o recurso com o SFOS 21. A classificação da Avanet das inovações da época pode ser encontrada na postagem do blog Sophos Firewall v21: as inovações mais importantes. Várias correções do WAF e do Let’s Encrypt estão listadas nas notas de versão recentes. Para ambientes produtivos, isso significa: o status do firmware, o status do certificado e a operação do WAF devem ser verificados em conjunto, e não isoladamente.

Requisitos

Antes de criar um certificado, estes pontos devem ser esclarecidos:

• O firewall funciona em uma versão SFOS com suporte Let’s Encrypt.
• O nome DNS público aponta para o endereço WAN ou endereço hospedado do firewall.
• A porta 80 pode ser acessada externamente para validação HTTP.
• Não há DNAT ativo, WAF ou outra regra interceptando a solicitação de validação na porta 80.
• O firewall pode se comunicar pela própria Internet.
• A data, hora e NTP do firewall estão corretos.
• Para atendimento posterior fica claro se o certificado é utilizado em WAF, WebAdmin, Portal ou SMTP TLS.
• O proprietário verifica regularmente a expiração do certificado, o status da renovação e os serviços afetados.

⚠️ Let’s Encrypt não é uma solução alternativa para acessibilidade pública impura. Se a porta 80 for bloqueada por uma regra DNAT antiga, outra regra WAF, um NAT upstream ou um filtro de provedor, a solicitação ou renovação do certificado poderá falhar.

Agendar nomes de certificadosAntes da configuração técnica, deve-se determinar quais nomes de host são realmente necessários. Um bom planejamento de certificados evita correções posteriores nas regras, portais e DNS do WAF.

Exemplos:

Se você tiver vários aplicativos, não se apresse em agrupar tudo em um único certificado. Um certificado com muitos nomes pode ser prático, mas também aumenta as dependências. Quando um certificado é renovado, substituído ou revertido, todos os nomes de host que ele contém são afetados.

Para regras WAF, também é importante que o DNS, o certificado, os domínios na regra WAF e o SNI correspondam. Os princípios básicos do WAF são descritos em Sophos Firewall WAF: servidores públicos web com segurança.

Criar conta e certificado Let’s Encrypt

A configuração é feita no WebAdmin na área Certificados. Dependendo da versão do SFOS, a representação exata pode variar um pouco, mas o processo permanece semelhante.

Processo básico:

1. Abra Certificados.
2. Abra a área Let’s Encrypt ou solicitação de certificado.
3. Prepare a conta Let’s Encrypt no firewall.
4. Insira os FQDNs desejados.
5. Selecione interface WAN ou endereço público para validação HTTP.
6. Verifique se a porta 80 aponta para o firewall de fora.
7. Solicite certificado.
8. Após a emissão bem-sucedida, verifique em Certificados > Certificados se o certificado está presente e é válido.

Durante a validação, o firewall usa o mecanismo HTTP de resposta a desafios. Para fazer isso, os sistemas Let’s Encrypt externos devem ser capazes de alcançar o caminho de validação. Se o firewall estiver atrás de um roteador, balanceador de carga ou provedor NAT, o redirecionamento deverá apontar para o firewall.

Usar certificado

Uma vez emitido, o certificado só existe. Ele só protege um serviço depois de ele ter sido selecionado ativamente.

Atribuição típica:

Após a atribuição, você não deve apenas salvar no WebAdmin, mas também testar o serviço externamente. Para publicações WAF, um teste fora da sua própria LAN é adequado porque a visualização interna do DNS, o loopback NAT ou o cache do navegador podem fornecer falsa segurança.

Teste de entrada em operação

Um teste de entrada em operação bem-sucedido consiste em DNS, TLS, funcionalidade de serviço e registro.

Lista de verificação:

• O FQDN resolve publicamente para o endereço esperado.
• A porta 80 está acessível ao firewall durante a validação.
• A porta 443 ou a porta HTTPS utilizada entrega o novo certificado.
• O navegador não mostra aviso de certificado.
• O certificado contém o nome do host esperado.
• A data de validade corresponde ao certificado recém-criado.
• A regra WAF, portal ou WebAdmin realmente usa este certificado.
• O Log Viewer não mostra nenhum erro perceptível de WAF, portal ou certificado.
• Para versões WAF, reverseproxy.log corresponde ao horário do teste.

Um simples teste TLS externo também pode mostrar qual certificado é realmente entregue. É importante realizar o teste fora da rede do cliente e não apenas do cliente interno.

Verifique a cadeia de certificados

Depois de mudar para um novo certificado Let’s Encrypt, não apenas o nome comum ou a entrada SAN devem ser verificados. Também é crucial que o cliente veja toda a cadeia de certificados. Se um navegador, aplicativo ou sistema de monitoramento relatar uma cadeia incompleta, a causa pode ser a seleção do certificado, um certificado importado antigo, uma regra WAF incorreta ou um proxy reverso intermediário.

Na prática, você deve verificar estes pontos:- O teste HTTPS externo mostra o FQDN esperado sem aviso de certificado.

• O certificado entregue é realmente o novo certificado Let’s Encrypt do Sophos Firewall.
• A cadeia de certificados está completa e não é substituída por um back-end antigo ou certificado proxy.
• Regra WAF, portal ou WebAdmin utilizam o mesmo certificado que está visível no teste externo.
• Se um balanceador de carga, roteador ou proxy reverso upstream estiver envolvido, nenhum outro certificado será entregue lá.

Essa verificação é particularmente importante se o mesmo domínio passou anteriormente por uma publicação diferente ou se várias regras WAF, regras DNAT ou proxies externos usarem o mesmo nome de host. Caso contrário, você verá um certificado válido no WebAdmin, enquanto os clientes externos ainda receberão uma cadeia diferente ou incompleta.

Monitore a renovação na empresa

Os certificados Let’s Encrypt têm vida curta. O ponto forte da integração é que o firewall pode realizar a renovação automaticamente. No entanto, você não deve permitir que o processo seja executado às cegas.

Estes pontos devem ser verificados regularmente em uma auditoria da empresa:

• O firewall está sendo executado em uma versão SFOS atual e estável?
• O certificado ainda é válido?
• A renovação automática foi bem-sucedida?
• A porta 80 ainda está acessível para validação?
• Existem novas regras DNAT ou WAF que possam bloquear a validação?
• Os usuários ou o monitoramento mostram avisos de certificado?
• Existem erros de WAF ou de portal no visualizador de log?

Essa verificação é particularmente importante após atualizações de firewall, alterações de WAF, alterações de provedor, alterações de DNS e alterações em roteadores upstream ou proxies reversos.

Erros típicos

Se o WAF e o certificado estiverem juntos, você não deve apenas olhar para o certificado. Correspondência de WAF, endereço hospedado, domínios, SNI e acessibilidade de back-end pertencem à mesma cadeia de erros.

Plan rollback

Para portais públicos e aplicações WAF, deve ficar claro como voltar antes de alterar um certificado.

Useful preparation:

• não exclua o certificado anterior imediatamente
• Documente a regra WAF afetada e a configuração do portal
• Tenha acesso de teste externo disponível
• Conheça o DNS TTL se os nomes de host forem alterados
• Selecione janelas de manutenção para portais críticos
• Preparar comunicações do usuário se um portal for afetado

Se o novo certificado tiver sido criado, mas um serviço funcionar incorretamente, normalmente você poderá selecionar o certificado anterior novamente. No entanto, se a causa for uma validação HTTP bloqueada, uma reversão do certificado só ajudará no curto prazo. Em seguida, o caminho de validação deve ser corrigido, caso contrário a próxima renovação falhará novamente.

Lista de verificação- FQDNs e serviços documentados.

• Resolução de DNS público verificada.
• Porta 80 verificada para validação HTTP.
• Conflitos com DNAT, WAF ou NAT upstream verificados.
• Vamos criptografar o certificado criado.
• Certificado atribuído ao serviço correto.
• Teste HTTPS externo realizado.
• Log Viewer e WAF reverseproxy.log verificados.
• Responsabilidade e monitoramento de renovação definidos.
• Certificado antigo removido somente após operação bem-sucedida.

Perguntas frequentes