Publicar servidor por DNAT no Sophos Firewall

Com o DNAT você publica um servidor interno por meio de um endereço IP público ou porta. O Sophos Firewall então encaminha o tráfego de entrada para o servidor de destino interno. Exemplos típicos são servidores web, proxies reversos, gateways VPN ou outros serviços em uma DMZ.

Para o contexto geral de hardening, consultar o hub Sophos Firewall Hardening: melhores práticas para uma configuração segura.

O artigo explica o que deve ser verificado antes e depois da criação de uma regra DNAT e como proteger a publicação com o escopo mais restrito possível.

Planejamento antes da publicação

Antes de publicar um serviço por DNAT, deve ficar claro se ele realmente precisa ser acessível ao público e qual variante técnica é mais adequada. Um bom planejamento evita portas abertas, regras NAT duplicadas e caminhos de retorno difíceis de rastrear.

Requisitos

• Endereço IP público ou interface WAN
• Servidor interno com endereço IP fixo
• Serviço e porta conhecidos, por exemplo TCP 443
• Regra de firewall apropriada
• Opcional: IPS, Web Server Protection ou Reverse Proxy dependendo do serviço

⚠️ DNAT publica um serviço interno para o mundo exterior. Cada serviço publicado aumenta a superfície de ataque. Somente o que for realmente necessário deve ser publicado. A origem, o porto e o destino devem ser tão restritos quanto possível.

Esclareça com antecedência

Antes de configurar o sistema de controle, você deve responder a estas perguntas:

• Qual interface IP ou WAN pública é usada?
• Qual porta externa deve estar acessível?
• Para qual IP interno é encaminhado?
• A porta permanece a mesma ou está traduzida?
• O acesso deve ser permitido de qualquer lugar ou apenas de determinadas redes de origem?
• O NAT de origem ou NAT reflexivo precisa ser levado em consideração?
• Há necessidade de uma regra de loopback para clientes internos que usam o FQDN público?
• Será publicado apenas um servidor interno ou vários servidores com balanceamento de carga?
• Já existe uma regra que utiliza a mesma porta?
• O firewall Sophos está localizado diretamente na Internet ou atrás de um roteador do provedor?
• É necessário abrir regras adicionais num grupo de segurança na nuvem?

Essas informações evitam conflitos posteriores com regras de NAT ou firewall existentes.

Se os termos Original source, Original destination, Translated destination, Translated service, Loopback ou Regra Reflexiva ainda não estiverem claros, você deve primeiro ler Compreendendo o NAT no Sophos Firewall: SNAT, DNAT, MASQ, PAT. Esta página centra-se na publicação específica de um serviço interno.

DNAT, WAF, VPN ou ZTNA?

Nem todos os serviços acessíveis ao público devem ser publicados automaticamente através do DNAT. O DNAT é tecnicamente simples, mas também muito direto: o firewall encaminha uma porta para um destino interno. Se isto faz sentido depende do serviço, das fontes e da necessidade de proteção.

• Serviço não HTTP com fontes claramente definidas: DNAT com forte restrição de origem, registro e IPS.
• Aplicativo público HTTP ou HTTPS: primeira verificação Sophos Firewall WAF.
• Acesso de administração como SSH ou RDP: Para destinos fixos individuais, utilizar Clientless SSL VPN; caso contrário, utilizar VPN, ZTNA ou um IP de origem fixo em vez de DNAT aberto.
• Acesso apenas para alguns parceiros ou localidades: Prefira IP de origem, VPN ou conexão site a site.
• A aplicação deve estar acessível interna e externamente com o mesmo nome: Verifique DNS dividido ou regra de loopback planejada deliberadamente.

Para aplicações web clássicas, o WAF é muitas vezes um melhor ponto de partida porque nomes de host, certificados, caminhos, perfis de proteção web e opcionalmente autenticação podem ser levados em consideração. O DNAT só deve ser utilizado para acesso administrativo em casos excepcionais. Se um serviço interno não precisa realmente ser público, uma VPN ou uma arquitetura ZTNA geralmente são uma solução mais limpa. Os princípios básicos do ZTNA existentes estão disponíveis em Como configurar o Sophos ZTNA e Criar gateway Sophos ZTNA.

Se o firewall estiver atrás de um roteador

O DNAT também funciona se o firewall Sophos não tiver diretamente o endereço IP público, mas estiver atrás de um roteador NAT do provedor.

Neste caso são necessários dois redirecionamentos:

1. No roteador do provedor, a porta pública é encaminhada para o IP WAN do Sophos Firewall.
2. No firewall Sophos, a porta é encaminhada para o servidor interno via DNAT.

Muitos roteadores provedores oferecem encaminhamento de porta clássico ou uma função como Exposed Host ou DMZ Host. Com uma função de host exposta, muitas ou todas as portas de entrada são frequentemente encaminhadas para o firewall. Isso pode ser prático, mas deve ser cuidadosamente protegido porque o controle real fica inteiramente com o firewall Sophos.

Se não houver IP público fixo, você pode usar DynDNS. O Sophos Firewall pode configurar DNS dinâmico para que um nome DNS sempre aponte para o IP público atual. Ainda é importante: o encaminhamento de porta no roteador do provedor deve apontar para o firewall Sophos.

Com um endereço IPv4 público adicional num segmento WAN diretamente ligado, a resolução ARP anterior pode ainda estar em falta. O procedimento separado para configurar Proxy ARP na Sophos Firewall só é adequado quando uma captura comprova o pedido e a ausência de resposta da firewall; o DNAT não exige este passo manual em todos os casos.

O mesmo princípio se aplica em ambientes de nuvem. Com o Azure, a regra DNAT no Firewall Sophos por si só não é suficiente. Além disso, as regras de entrada apropriadas devem ser abertas no grupo de segurança de rede, caso contrário o tráfego não alcançará o firewall.

Configurar DNAT e regra de firewall

Uma publicação de servidor sempre consiste em duas partes: a regra NAT traduz o destino ou porta, a regra de firewall permite e controla o tráfego.

Server Access Assistant ou regra DNAT manual?

O Sophos Firewall oferece duas maneiras de publicar servidores:

• Server access assistant (DNAT): adequado como opção padrão rápida para uma única publicação. O assistente cria várias regras automaticamente e as posiciona no topo da base de regras.
• Regra DNAT manual: adequada para ambientes mais complexos com alias IP, PAT, balanceamento de carga, origens específicas ou um design de regras deliberado. Cada campo precisa ser configurado e testado individualmente.

O assistente pode ser útil porque cria não apenas uma regra DNAT de entrada, mas, dependendo da seleção, também uma regra de loopback, uma regra SNAT reflexiva e a regra de firewall correspondente. Isso economiza tempo, mas não substitui a revisão das regras criadas.

Usar Server Access Assistant

O assistente é o caminho mais rápido para uma primeira publicação. Ele é especialmente útil quando um único servidor interno deve ficar acessível por um endereço WAN e um serviço claramente definido.

Procedimento:

1. Abrir Rules and policies > NAT rules.
2. Selecionar IPv4 ou IPv6.
3. Selecionar Add NAT rule > Server access assistant (DNAT). Como alternativa, o assistente também pode ser iniciado em Rules and policies > Firewall rules > Add firewall rule.
4. Em Internal server IP address, selecionar o servidor interno ou inserir um endereço IP.
5. Em WAN IP address, selecionar a interface WAN ou o endereço IP público.
6. Em Services, selecionar o serviço interno, por exemplo HTTPS.
7. Em External source networks and devices, definir as origens permitidas. Para serviços públicos, Any só é adequado quando o serviço realmente precisa estar acessível a partir de toda a Internet.
8. Revisar as regras e salvar com Save and finish.

O assistente ativa imediatamente as regras geradas e as posiciona no topo das tabelas de regras NAT e de firewall. É justamente por isso que o salvamento deve ser seguido de uma revisão. Uma regra gerada automaticamente pode funcionar tecnicamente e ainda ser ampla demais, estar posicionada muito acima ou ter um nome inadequado para a operação.

Para que uma regra de loopback seja gerada automaticamente, uma interface do firewall precisa ser selecionada como destino WAN. Se um endereço IP público for inserido em seu lugar, o assistente não cria automaticamente a mesma lógica de loopback. Em muitos ambientes, Split DNS é de qualquer forma mais claro do que Loopback NAT.

Depois de usar o assistente, é necessário verificar:

• As regras de NAT e firewall estão na posição correta?
• A origem está realmente tão restrita quanto planejado ou ainda está em Any?
• Foi criada uma regra de loopback mesmo que Split DNS fosse a solução mais clara?
• Foi criada uma regra reflexiva que não é necessária para o tráfego de saída do servidor?
• A regra de firewall corresponde à zona de destino após o NAT e ao objeto de destino público antes do NAT?

Para ambientes de produção, uma regra DNAT nomeada manualmente e posicionada de forma deliberada costuma ser mais fácil de compreender. O assistente oferece um início rápido, mas as regras geradas exigem a mesma revisão das regras configuradas manualmente.

Criar regra DNAT

Um exemplo manual típico de DNAT publica TCP 443 externamente para um servidor web interno na DMZ. A regra traduz apenas o endereço de destino e, opcionalmente, a porta de destino. Ela não substitui uma regra de firewall.

Procedimento:

1. Abrir Rules and policies > NAT rules.
2. Selecionar IPv4 ou IPv6.
3. Selecionar Add NAT rule > New NAT rule.
4. Definir um Rule name descritivo, por exemplo DNAT_WEB_DMZ_HTTPS.
5. Escolher Rule position de modo que regras DNAT específicas fiquem antes de regras gerais.
6. Definir Original source como as origens externas permitidas. Usar Any apenas para serviços deliberadamente públicos.
7. Definir Original destination como o objeto de host WAN, o IP público ou a interface WAN adequada.
8. Definir Original service como o serviço acessível externamente, por exemplo HTTPS.
9. Definir Translated destination (DNAT) como o servidor interno ou o grupo de servidores.
10. Manter Translated service (PAT) em Original ou definir a porta de destino interna quando for necessário encaminhamento de porta.
11. Definir Inbound interface de forma deliberada. Para acesso pela Internet, normalmente é a interface WAN; em casos especiais, Any pode ser necessário.
12. Para DNAT para servidores internos, normalmente manter Outbound interface em Any, para que o roteamento e a zona de destino sejam avaliados corretamente.
13. Ativar loopback, reflexive rule, load balancing e health check apenas quando forem funcionalmente necessários.
14. Salvar e ativar a regra.

Quando apenas alguns endereços IP externos precisam acessar o serviço, Original source não deve ser Any, mas ficar restrita a essas origens.

Em publicações de produção, um objeto de host para o IP público costuma ser mais claro do que selecionar diretamente uma interface WAN. O objeto permanece rastreável se interfaces, endereços de alias ou detalhes do provedor mudarem posteriormente.

Compreender corretamente Original e Translated

Quando se trata de regras NAT, a distinção entre Original e Traduzido é importante.

• Origem/destino/serviço original descreve o tráfego conforme ele chega ao Sophos Firewall.
• Origem/destino/serviço traduzido descreve o tráfego conforme ele sai do Sophos Firewall após a tradução.

Para uma regra DNAT recebida, isso significa:

• Destino original é o endereço IP público ou WAN do firewall.
• Serviço original é a porta externa que o cliente aborda.
• Destino traduzido (DNAT) é o servidor interno.
• Serviço traduzido (PAT) é a porta interna no servidor de destino se a porta for traduzida.
• Fonte traduzida (SNAT) geralmente permanece em Original com regras normais de DNAT.

Encaminhamento de porta e PAT

O encaminhamento de porta é tecnicamente uma tradução de serviço. No Sophos Firewall, Serviço traduzido (PAT) é usado para isso.

Exemplo:

• Externo: TCP 20120
• Interno: TCP 22

O cliente externo se conecta na porta 20120, mas o firewall Sophos encaminha internamente na porta SSH 22. Isto pode ser útil, mas não substitui as restrições de acesso. Alterar a porta externa pode reduzir algum ruído de fundo, mas não torna o serviço seguro.

Importante: O protocolo deve permanecer o mesmo. O TCP pode ser traduzido para outra porta TCP, o UDP para outra porta UDP. TCP para UDP não é uma tradução de porta válida.

Se o HTTPS for publicado, você também precisará verificar se há conflitos com o WebAdmin ou o Portal do Usuário do Sophos Firewall. Por padrão, o console administrativo usa a porta HTTPS 4444, o portal do usuário usa a porta HTTPS 443. Se houver sobreposições, as portas próprias do firewall ou os serviços publicados deverão ser claramente separados.

Planeje o IP de origem e o caminho de retorno conscientemente

Para uma publicação DNAT normal, Fonte traduzida (SNAT) deve permanecer geralmente em Original. Assim, o servidor interno vê o IP de origem externo real. Isso é importante para logs do servidor, limites de taxa, mecanismos de proteção semelhantes a Fail2Ban, logs de aplicações, análise por WAF ou proxy reverso e investigações posteriores.

SNAT para o firewall ou um endereço interno ainda pode ser necessário se o caminho de retorno não passar pelo firewall Sophos. Isto é possível, por exemplo, se o servidor publicado utilizar um gateway padrão diferente, estiver em um segmento de roteamento externo ou tiver uma situação de roteamento assimétrico.

A decisão deve ser tomada conscientemente:

• Fonte permanece Original: Servidor vê IP externo real. O caminho de retorno deve passar de forma limpa pelo firewall.
• A fonte é traduzida via SNAT: A rota de retorno é mais fácil de controlar. O servidor vê apenas o firewall ou IP SNAT, o IP real do cliente é perdido no log do servidor.

Se um serviço só funciona com SNAT, você não deve simplesmente persistir e deixar o assunto para trás. É melhor verificar primeiro se o gateway, a rota, a VLAN, o firewall do servidor ou o design de roteamento podem ser corrigidos. O SNAT pode ser uma solução alternativa legítima, mas torna a análise posterior mais difícil.

Ao testar, você deve sempre verificar qual IP de origem o servidor realmente vê. Se apenas o IP do firewall aparecer em vez do IP do cliente externo, deve ser claramente documentado se isso é intencional.

Verifique a regra do firewall

Uma regra NAT por si só não permite tráfego automaticamente. Além disso, é necessária uma regra de firewall adequada.

Com o DNAT, a visualização na regra do firewall é incomum porque o firewall deve conhecer simultaneamente o acesso original de fora e o alvo interno traduzido.

A regra prática mais importante:

⚠️ Com DNAT, a regra de firewall usa a zona alvo após o NAT, mas a rede alvo antes do NAT.

A ordem de processamento é importante: no tráfego de entrada, o Sophos Firewall primeiro localiza a regra DNAT correspondente e determina o destino traduzido. Em seguida, a regra de firewall é avaliada. Em Destination zone, o firewall usa a zona na qual se encontra o destino traduzido. Em Destination networks, porém, o objeto de destino original da regra DNAT continua relevante.

Configuração típica:

• Zona de origem: Principalmente WAN quando o acesso vem da Internet.
• Redes e dispositivos de origem: Tão limitado quanto possível, por exemplo IPs individuais, redes, países ou grupos.
• Zonas de destino: Zona do servidor interno por DNAT, por exemplo DMZ ou SERVER.
• Redes de destino: Endereço de destino público ou objeto host WAN de Original destination.
• Serviços: Serviço externo de Original service, ou seja, a porta que os clientes acessam de fora.
• Perfis de segurança: Dependendo do serviço, IPS, verificação de malware, política da web ou outra verificação adequada
• Registro: Habilitar para serviços publicados

Sem uma regra de firewall adequada, o tráfego é rejeitado apesar do DNAT.

Este ponto é uma fonte comum de erro: se você inserir o servidor interno como rede de destino, mesmo que a regra espere o objeto WAN público, a regra não corresponderá. A lógica exata é explicada com mais detalhes no artigo Compreendendo o NAT no Sophos Firewall: SNAT, DNAT, MASQ, PAT.

A ordem também se aplica às regras NAT. O Sophos verifica as regras NAT de cima para baixo e usa a primeira regra correspondente. Uma regra NAT acima que seja demasiado geral pode, portanto, impedir que a regra DNAT específica entre em vigor.

As conexões já estabelecidas mantêm sua tradução NAT mesmo que a regra NAT seja alterada posteriormente. Por isso, os testes após uma alteração devem usar novas sessões ou encerrar corretamente as conexões antigas; caso contrário, o resultado ainda poderá refletir o estado anterior.

Opções avançadas de NAT

Essas opções só se tornam relevantes quando clientes internos usam nomes públicos, caminhos de retorno precisam ser traduzidos especificamente ou vários servidores de destino estão envolvidos.

Loopback, regras NAT reflexivas e vinculadas

O Sophos Firewall oferece diversas opções de NAT que são facilmente confundidas:

• Regra de loopback: ajuda quando clientes internos devem acessar um servidor interno por meio do IP público ou do nome DNS público.
• Regra reflexiva: cria uma regra SNAT de espelhamento para uma regra DNAT para que o tráfego de retorno ou certas direções opostas sejam traduzidos adequadamente.
• Regra NAT vinculada: criada a partir de uma regra de firewall e é uma regra SNAT vinculada. Uma regra NAT vinculada não é igual a uma regra DNAT de entrada para um servidor publicado.

Para publicações clássicas de servidor, uma regra DNAT independente mais uma regra de firewall adequada geralmente é a mais clara. As regras NAT vinculadas podem ser úteis se uma regra de firewall exigir diretamente uma tradução SNAT especial. No entanto, em ambientes gerais, regras NAT independentes e claramente nomeadas tendem a permanecer mais fáceis de entender e manter.

Importante: As regras de loopback e reflexivas são derivadas da regra DNAT original. Se a regra original do DNAT for alterada posteriormente, deve-se verificar as regras derivadas separadamente. Caso contrário, pode acontecer que o acesso externo tenha sido ajustado corretamente, mas o acesso de loopback interno ou o tráfego de saída do servidor continue a funcionar de acordo com a lógica antiga.

Isso não é um detalhe cosmético. O Sophos cria regras de loopback e reflexive com referência ao nome e ao ID da regra DNAT original, mas alterações posteriores na regra original não atualizam automaticamente as regras derivadas. Após mudanças no IP público, no servidor de destino, no serviço ou nas origens, essas regras devem ser abertas e comparadas deliberadamente.

Balanceamento de carga e verificação de integridade

Quando vários servidores internos são publicados atrás de um IP público, o DNAT também pode ser usado para balanceamento de carga ou failover.

Os métodos possíveis são, por exemplo:

• Round Robin
• Primeiro vivo
• Aleatório
• IP fixo
• Um para um

Se você quiser que o firewall detecte se um servidor de destino está disponível, uma Verificação de integridade deverá ser configurada. Sem uma verificação de integridade, o firewall também pode encaminhar o tráfego para um servidor que não pode ser alcançado.

Segurança e entrada em produção

Um serviço publicado passa imediatamente a fazer parte da superfície de ataque pública. Por isso, acesso restrito, logging, perfis de segurança e um rollback claro fazem parte da entrada em produção.

Planeje a entrada em operação e a reversão

Uma publicação DNAT deve ser tratada como uma pequena mudança de produção. Assim que a regra estiver ativa, o serviço poderá ficar acessível pela Internet. Antes da entrada em produção, é necessário documentar qual regra será ativada, como o acesso será testado e como executar o rollback em caso de problemas.

Verifique antes de entrar em produção:

• Faça backup da configuração atual do firewall ou pelo menos documente as regras de NAT e firewall afetadas.
• Verifique as regras NAT existentes para o mesmo IP público, porta externa e interface WAN.
• Combine o roteador do provedor, o grupo de segurança da nuvem ou as regras de firewall upstream com a configuração do Sophos.
• Considere o DNS TTL quando um nome de host aponta novamente para o endereço publicado.
• Prepare uma fonte de teste fora da sua própria LAN, por exemplo, telefone celular, local externo ou teste de porta online controlada.
• Defina os locais de log esperados: Visualizador de log, ID de regra NAT, ID de regra de firewall, captura de pacotes e log do servidor.
• Definir critérios de reversão, por exemplo, serviço errado acessível, servidor não respondendo, erro de certificado, perfil de segurança bloqueia tráfego legítimo ou IP de origem inesperado no servidor.

Uma reversão simples geralmente envolve a desativação da nova regra DNAT e da regra de firewall correspondente. Se uma publicação antiga tiver sido substituída, deve ficar claro se a regra antiga pode ser reativada ou se o encaminhamento de porta do provedor, o DNS ou o monitoramento devem ser redefinidos primeiro.

Para serviços críticos, você não deve alterar várias coisas ao mesmo tempo. Se o DNS, o roteador do provedor, a regra NAT, a regra do firewall e a configuração do servidor forem ajustados ao mesmo tempo, será difícil atribuir um erro posteriormente. Um processo curto com etapas claras é melhor: preparar, ativar, testar externamente, verificar logs, verificar servidores, documentar resultados.

Restrinja o acesso o máximo possível

Nem todo serviço publicado precisa ser acessível por toda a Internet. Se possível, o acesso deve ser limitado.

Restrições úteis:

• Permitir apenas endereços IP de origem única.
• Permitir somente hosts FQDN conhecidos quando o outro lado usar IPs dinâmicos.
• Permitir apenas alguns países.
• Bloquear explicitamente determinados países.
• Permitir acesso apenas via VPN.
• Use uma solução ZTNA em vez de publicação direta.

O DNAT geralmente não é a melhor solução para serviços administrativos como SSH, RDP ou portais de administração internos. Se o acesso não precisar ser público, VPN ou ZTNA são quase sempre uma escolha melhor.

Melhore a segurança

Para serviços publicados você deve verificar:

• O servidor está atualizado atualmente?
• Existe uma opção de WAF ou proxy reverso?
• O IPS está ativo na regra do firewall?
• Apenas as portas necessárias estão abertas?
• O serviço está logado?
• Existem restrições de geo-IP, feed de ameaças ou IP de origem?
• O MFA é possível se for um portal?

Para aplicações web, Web Server Protection/WAF também pode ser útil em vez de DNAT puro.

Bots e feeds de ameaças

Portas públicas como HTTP, HTTPS, SSH ou RDP estão constantemente no foco dos bots. Assim que uma porta estiver acessível na Internet, muitas vezes você poderá ver rapidamente tentativas de conexão, varreduras, tentativas de login ou exploração de tráfego no visualizador de log.

Isso não significa automaticamente que o servidor esteja comprometido. Mas mostra que o serviço faz parte da superfície de ataque pública. Portanto, recomendamos proteger adicionalmente os serviços publicados com IPS, registro, fontes restritas e feeds de ameaças de terceiros.

Os feeds de ameaças fornecem continuamente ao firewall indicadores atuais de comprometimento, por exemplo, endereços IP ou domínios maliciosos. Isso permite que o firewall bloqueie invasores, botnets ou scanners conhecidos antes que eles alcancem o serviço publicado.

Mais: Feeds de ameaças do Firewall Sophos

Teste

Depois de salvar a regra DNAT:

• Teste de uma rede externa, não da mesma LAN
• Verifique apenas a porta pública esperada, não faça uma varredura ampla em endereços estrangeiros
• Verifique o Visualizador de log para ID de regra de firewall e ID de regra NAT
• Compare a captura de pacotes com fonte externa, destino público e destino interno
• Verifique os logs do servidor
• Controle o IP de origem visível no sistema de destino

Se o teste for realizado da LAN interna para o IP público, também poderá ser necessário NAT hairpin ou uma solução DNS interna.

Matriz de testes para publicações DNAT

Um único teste de porta raramente é suficiente para uma publicação DNAT em produção. É melhor usar uma pequena matriz de testes que separe caminhos permitidos e indesejados. Assim, não se verifica apenas se o serviço está acessível, mas também se as restrições, o registo e o caminho de retorno funcionam corretamente.

Fontes de teste úteis:

• Origem externa permitida: testar a ligação a partir de dados móveis, de uma localização externa ou de uma rede de parceiro para o IP público e a porta externa. No Log Viewer devem aparecer o ID esperado da regra de firewall e o ID da regra NAT.
• Origem externa não permitida: se a publicação estiver limitada a origens específicas, um teste a partir de uma origem não permitida deve falhar deliberadamente. Caso contrário, a restrição de origem está demasiado ampla.
• Cliente interno com nome DNS interno: verificar se os utilizadores internos resolvem diretamente para o IP interno do servidor. Isto é muitas vezes mais limpo do que loopback NAT.
• Cliente interno com FQDN público: testar apenas se este acesso for realmente necessário. Se falhar, verificar primeiro split DNS e não adicionar loopback NAT automaticamente.
• Servidor de destino: verificar o log do servidor, firewall local, serviço em escuta, certificado e IP de origem visível. Assim percebe-se se o servidor vê o IP externo real ou um endereço SNAT.
• Monitorização ou health check externo: verificar se o teste usa o mesmo URL, a mesma porta e a mesma lógica de origem da monitorização real.

Após cada teste, deve avaliar-se apenas uma conclusão: o tráfego chega à Sophos Firewall, a regra NAT esperada corresponde, a regra de firewall esperada corresponde, o pacote chega ao servidor e volta uma resposta? Se forem alteradas várias coisas ao mesmo tempo, o próximo erro torna-se muito mais difícil de atribuir.

Um teste DNAT limpo compara três pontos de vista:

• Cliente Externo: A conexão com IP público e porta externa funciona ou é deliberadamente bloqueada.
• Firewall Sophos: O Log Viewer mostra o ID da regra de firewall e o ID da regra NAT esperados.
• Servidor interno: Serviço vê o IP de origem esperado, responde através do gateway correto e registra o acesso.

Se apenas uma destas perspectivas for examinada, os erros típicos permanecem não detectados. Por exemplo, um teste de porta externa bem-sucedido ainda não diz se o registro, o IPS, as restrições de origem ou os proprietários do servidor estão devidamente documentados.

Solução de problemas e operações

Após a entrada em produção, não basta verificar se o serviço está acessível. Log Viewer, NAT Rule ID, Firewall Rule ID, logs do servidor e revisões regulares de publicações antigas também são importantes.

Solução de problemas

Erros comuns:

• Regra de firewall ausente
• IP WAN errado selecionado
• Falta o encaminhamento de porta no roteador do provedor
• O Grupo de Segurança da Rede Azure bloqueia a porta
• O serviço não está sendo executado internamente
• O gateway do servidor não aponta para o Firewall Sophos
• A regra NAT está sob outra que entra em vigor antecipadamente
• A regra de firewall usa a rede de destino errada no DNAT
• A porta já está em uso por outro serviço
• Loopback ausente quando clientes internos usam FQDN público
• A verificação de integridade está ausente ou incorreta ao usar o balanceamento de carga
• O teste ocorre na rede interna e não externamente
• O servidor de destino responde através de um gateway diferente
• Um perfil de segurança bloqueia o tráfego, mas não é procurado no log correto

O Log Viewer é o ponto de partida mais importante para problemas de DNAT. Lá você pode ver se o tráfego está chegando, qual regra de firewall e qual regra NAT se aplica e se o tráfego é permitido ou rejeitado. Se a ocorrência não corresponder ao esperado, a regra de firewall do Sophos não se aplica: verificar as causas ajudará.

Para uma solução de problemas mais profunda, você não deve olhar apenas para o firewall Sophos. Se o visualizador de log permitir tráfego e a captura de pacotes mostrar que os pacotes continuam para o servidor, a causa geralmente está no sistema de destino: firewall local, gateway padrão incorreto, serviço não vinculado, problema de certificado, aplicativo escutando em uma porta diferente ou proxy reverso upstream não respondendo conforme esperado.

Uma classificação rápida ajuda a não procurar no local errado:

• Nenhum hit aparece no Log Viewer: O tráfego não chega à firewall ou está a ser usado o IP WAN errado. Verificar o router do fornecedor, o Cloud Security Group, o IP público e o Packet Capture na WAN.
• O Firewall Rule ID corresponde, mas o NAT Rule ID está ausente: A regra NAT não corresponde ou está demasiado abaixo na ordem. Verificar Original destination, Original service, interface de entrada e ordem NAT.
• O NAT Rule ID corresponde, mas o serviço não responde: O servidor de destino ou o caminho de retorno não está correto. Verificar firewall do servidor, gateway predefinido, routing e Packet Capture para o servidor.
• Funciona externamente, mas não internamente por FQDN: Falta Split DNS ou loopback. Verificar a resolução DNS interna e adicionar loopback apenas de forma consciente.
• Após alterar o assistente, apenas uma parte se comporta incorretamente: Uma regra loopback ou reflexive derivada deixou de encaixar. Verificar individualmente as regras NAT e firewall geradas.

SMTP via DNAT após atualização para o SFOS 22

Se, após uma atualização para o SFOS 22, os e-mails recebidos forem ocasionalmente entregues com atraso ou não forem entregues, a causa poderá ser NC-184583. A Sophos identifica explicitamente o SFOS 22.0 GA Respin Build 411 como afetado, mas descreve o problema de forma mais geral para atualizações para a v22.x. O MR1 e o MR2 não são indicados separadamente como afetados ou corrigidos. A única versão indicada como correção é o SFOS 23.0 EAP0 Build 253 – uma versão EAP que não deve ser implementada indiscriminadamente num sistema de produção. Não existe um workaround público; a Sophos remete para o suporte.

Um teste da porta TCP 25 não é suficiente neste cenário. Devem ser enviadas várias mensagens reais de forma controlada, registando-se a hora UTC, o remetente, o destinatário e o Message-ID. Em seguida, compara-se a fila de envio ou o bounce do remetente com a fila e o log de transporte do servidor interno de correio. Para o suporte, o pacote de evidências deve incluir o build do firmware, os carimbos de data/hora, as Rule IDs, fwlog.log, firewall_rule.log, nat_rule.log e os logs do servidor de correio. Os caminhos dos logs e o Consolidated Troubleshooting Report estão descritos em Verificar os serviços e logs do Sophos Firewall através da CLI. Ao abrir um caso de suporte, deve indicar-se explicitamente NC-184583.

O Known Issue descreve o caminho DNAT direto para o servidor interno de correio. No Sophos Firewall MTA Mode, a firewall recebe a mensagem e encaminha-a de seguida. No entanto, a Sophos não confirma que o MTA Mode esteja seguramente excluído, nem que a mudança para este modo seja o workaround oficial.

Quando Black Hole DNAT também ajuda

Se um serviço precisa deliberadamente permanecer acessível ao público, mas certas fontes precisam ser interceptadas antes da publicação real, uma regra de DNAT de buraco negro acima da regra de DNAT produtiva pode fazer sentido. Isso funciona, por exemplo, para listas de IPs inválidos conhecidos, países permanentemente indesejados ou fontes de scanner recorrentes.

Esta técnica não substitui uma publicação corretamente protegida. A regra DNAT de produção deve continuar com escopo restrito, o logging deve permanecer ativo e o servidor publicado deve ser mantido atualizado. Black Hole DNAT acrescenta uma camada de bloqueio antes da publicação, mas não constitui a própria arquitetura de segurança.

Black Hole DNAT é particularmente útil nestes casos:

• Fontes recorrentes de scanner atingem o mesmo serviço publicado: As fontes podem dar em nada antes da regra produtiva do DNAT.

• Os países individuais não deveriam ter acesso ao encaminhamento portuário: A regra de bloqueio pode ser colocada acima da regra DNAT real.

• Já existe um grupo de IP inválido mantido: O grupo pode ser usado como Original source da Regra do Buraco Negro.

• Um serviço deve permanecer público, mas deve gerar menos tráfego de bots: A regra produtiva é mantida, fontes indesejadas são interceptadas antecipadamente

Black Hole DNAT não é adequado para serviços de firewall locais, como WebAdmin, Portal do Usuário, Portal VPN ou SSH para o próprio firewall. Acesso ao dispositivo e Regras de exceção de ACL de serviço local são responsáveis ​​por isso. Para servidores web via WAF, você deve primeiro verificar a regra do WAF, os países bloqueados, a autenticação e os logs do WAF.

A ordem é importante: a regra do DNAT do Buraco Negro deve estar acima da regra do DNAT produtivo. Você deve então verificar no visualizador de log se as fontes bloqueadas realmente atendem à regra do buraco negro e se as fontes permitidas continuam a usar o NAT produtivo e a regra de firewall. O procedimento exato pode ser encontrado em Sophos Firewall: Bloquear países e IPs maliciosos.

Verificação operacional

As regras DNAT devem ser revistas regularmente. Publicações antigas representam um risco frequente porque os serviços podem permanecer acessíveis depois de a aplicação ter sido movida, substituída ou deixar de ser necessária.

Para regras DNAT de produção, deve ser documentado pelo menos o seguinte:

• Objetivo da publicação: A documentação deve explicar por que o serviço está acessível ao público.
• Pessoa ou equipe responsável: Sem proprietário, as publicações antigas raramente são retiradas.
• IP público e porta externa: Facilita testes, monitoramento e verificações externas
• Servidor de destino interno e porta de destino: Importante para migrações de servidores, balanceamento de carga e alterações de certificados
• Fontes esperadas: Ajuda a determinar se Any é realmente necessário
• Medidas de proteção: IPS, alternativa WAF, MFA, feeds de ameaças, registro em log e status de patch devem ser rastreáveis ​​
• Data de validade ou data de revisão: Publicações temporárias precisam de uma data de término clara.

Uma revisão significativa não consiste apenas em observar a regra. Você deve verificar externamente se apenas as portas esperadas estão abertas, verificar no visualizador de log quais fontes estão realmente acessando e verificar no servidor de destino se a aplicação ainda está sendo mantida. Se o serviço for necessário apenas internamente ou para alguns parceiros, VPN, ZTNA, uma restrição de IP de origem ou uma regra WAF deverão ser reavaliados.

Ao remover regras antigas de DNAT, você não deve apenas excluir a regra NAT. Regras de firewall, objetos de host, objetos de serviço, regras de loopback, regras reflexivas, entradas de DNS, verificações de monitoramento ou encaminhamento de porta do provedor são frequentemente anexados a ele. Um curto processo de desativação é melhor:

1. Verifique os últimos acessos no visualizador de logs.
2. Peça à pessoa ou departamento responsável que confirme que o serviço não é mais necessário.
3. Primeiro desative a regra NAT e a regra de firewall apropriada.
4. Teste externamente se a porta está fechada.
5. Verifique se há erros nos logs de monitoramento e do servidor.
6. Só então limpe objetos, entradas de DNS e regras de provedores que não são mais necessários.

Se a publicação continuar necessária, a revisão deve resultar numa decisão concreta: mantê-la inalterada, restringi-la mais, migrá-la para WAF, colocá-la atrás de VPN/ZTNA ou reavaliá-la antes de uma data de validade definida.

Perguntas frequentes