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.

O artigo explica quais pontos você deve verificar antes e depois de uma regra DNAT e como garantir a liberação o mais fielmente possível.

Planejando antes de publicar

Antes de o DNAT ser lançado, deve ficar claro se o serviço 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 administrador, como SSH, RDP ou portal de administração interno: Se possível, VPN, ZTNA ou IP de origem fixa 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.

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:

• ****Assistente de acesso ao servidor (DNAT): caso padrão rápido para uma única versão. cria múltiplas regras automaticamente e as coloca no topo da base de regras.
• Regra DNAT manual: ambientes mais complexos com alias IP, PAT, balanceamento de carga, fontes especiais ou design de regras deliberado. Cada campo deve ser definido e testado por você mesmo.

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

Depois de usar o assistente você deve sempre verificar:

• As regras de NAT e firewall estão na posição correta?
• A fonte é realmente tão estreita quanto planejado ou ainda está em Any?
• Foi criada uma regra de loopback mesmo que o Split DNS fosse uma solução mais limpa?
• 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 produtivos, uma regra DNAT nomeada manualmente e colocada deliberadamente é muitas vezes mais fácil de entender. O assistente é bom para um início rápido, mas as regras criadas pertencem à mesma revisão que as regras criadas manualmente.

Criar regra DNAT

Um exemplo típico de DNAT:

• Fonte original: Any ou redes de origem definidas
• Destino original: interface WAN-IP ou WAN
• Serviço original: HTTPS
• Destino traduzido: servidor interno
• Serviço traduzido: porta de destino inalterada ou interna

Procedimento:

1. Abra Regras e políticas.
2. Mude para a área Regras NAT.
3. Selecione Adicionar regra NAT > Nova regra NAT.
4. Defina origem, destino e serviço originais.
5. Defina Destino traduzido para o servidor interno.
6. Opcionalmente, defina Serviço traduzido.
7. Verifique conscientemente a interface de entrada e saída.
8. Salve e ative a regra.

Se apenas alguns endereços IP de fontes externas precisarem ser acessados, a fonte original não deverá ser Any, mas deverá ser limitada a essas fontes.

Para compartilhamentos de produção, um objeto host para o IP público geralmente é mais limpo do que selecionar diretamente uma interface WAN. O objeto permanece rastreável se as interfaces, endereços de alias ou detalhes do provedor forem alterados posteriormente.

Entenda o original e traduza corretamente

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 versão DNAT normal, Fonte traduzida (SNAT) deve permanecer principalmente em Original. Então o servidor interno vê o IP de origem externo real. Isso é importante para logs de servidor, limites de taxa, mecanismos de proteção semelhantes a Fail2Ban, logs de aplicativos, avaliação de WAF ou proxy reverso e análise posterior de incidentes.

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.

Atribuiçã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.

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.

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.

Cobertura e ativação

Um serviço publicado faz imediatamente parte da superfície de ataque pública. É por isso que o acesso próximo, o registro em log, os perfis de segurança e uma reversão clara fazem parte do go-live.

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

Uma liberação de DNAT deve ser tratada como uma pequena mudança na produção. Assim que a regra estiver ativa, o serviço poderá ser acessado pela Internet. Portanto, antes do go-live, deve ficar claro qual regra será ativada, como o acesso será testado e como voltar caso haja 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 operação, você não deve apenas verificar se o serviço está acessível. Visualizadores de log, ID de regra NAT, ID de regra de firewall, logs de servidor e revisões regulares de versões antigas 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.

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 a liberação limpa. A regra produtiva do DNAT ainda deve ser rígida, o registro deve estar ativo e o servidor publicado deve ser mantido atualizado. Black Hole DNAT é uma camada de bloco adicional antes de um lançamento, não a arquitetura de segurança real.

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 do DNAT devem ser revistas regularmente. Versões antigas são um risco típico de segurança porque os serviços publicados muitas vezes permanecem acessíveis mesmo que o aplicativo tenha sido movido, substituído ou necessário apenas temporariamente.

Para regras de DNAT produtivas, pelo menos o seguinte deve ser documentado:| ponto | Por que é importante |

• Objectivo da libertação: Mais tarde, deverá ficar claro por que o serviço é acessível ao público
• Pessoa ou equipe responsável: Sem proprietário, açõ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: Lançamentos temporários precisam de um fim claro

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 autorização ainda for necessária, a revisão deve terminar com uma conclusão concreta: deixar como está, restringir de forma mais restrita, mudar para WAF, transferi-la para VPN/ZTNA ou reexaminar com uma data de validade.

Perguntas frequentes