Usa Cloudflare e ainda sofre ataques? 7 formas ocultas de vazar o IP de origem e como se proteger

O blog ficou inacessível, consumiu 20 GB de tráfego em um único dia e o servidor foi suspenso por falta de saldo. Mas ele já usava Cloudflare: como ainda pôde ser atacado? Os logs mostraram que o tráfego malicioso não passou pela Cloudflare; todas as conexões foram feitas diretamente ao IP real do servidor. O invasor contornou a CDN e atingiu a origem. Esse é o problema do vazamento do IP de origem.

Isso é mais comum do que parece. Muita gente acredita que basta configurar a Cloudflare, embora o IP de origem possa ter sido exposto por históricos de DNS, cabeçalhos de e-mail ou varreduras de subdomínios. Neste artigo, veremos as formas mais comuns de vazamento, como detectá-las e como montar uma proteção completa.

Por que o IP de origem vaza

O que é o vazamento do IP de origem e quais são seus riscos

Primeiro, vale esclarecer o conceito. Ao usar uma CDN como a Cloudflare, o usuário acessa um nó da Cloudflare, que encaminha a solicitação ao seu servidor real, chamado servidor de origem. Assim, o invasor vê apenas o IP da Cloudflare, não o IP real do servidor.

Porém, se ele conseguir descobrir o IP de origem por outro caminho, a CDN deixa de funcionar como barreira. O invasor pode atacar diretamente o servidor real e contornar todas as proteções da Cloudflare.

As consequências podem ser graves:

• Servidor fora do ar: o ataque DDoS atinge diretamente a origem e pode derrubar um servidor sem capacidade suficiente
• Aumento repentino dos custos de tráfego: muitos servidores em nuvem cobram por volume transferido, e o ataque pode gerar uma conta enorme
• Risco de roubo de dados: se houver uma vulnerabilidade, o invasor contorna o WAF da CDN e ataca diretamente o servidor

Segundo o relatório da Cloudflare referente ao quarto trimestre de 2024, a empresa observou o maior ataque DDoS já registrado, com 5,6 Tbps.

Um site comum dificilmente enfrentará algo dessa escala, mas mesmo um ataque de poucos gigabits pode derrubar um servidor pequeno.

[Imagem: diagrama de funcionamento de uma CDN]

Prompt: servidor protegido por um escudo de CDN, fluxo do tráfego do usuário pelos nós da Cloudflare, diagrama simplificado, paleta tecnológica azul, ilustração profissional

Sete formas comuns de vazar o IP de origem

Como esse IP acaba exposto? Reuni as sete formas mais comuns, ordenadas do risco mais alto para o mais baixo.

Forma 1: histórico de DNS — risco alto

É a forma mais comum e também uma das mais ignoradas.

O problema aparece quando alguém mantém o domínio apontado diretamente para o IP real durante algum tempo e só depois decide usar a Cloudflare. Serviços de terceiros, como SecurityTrails e DNSdumpster, podem ter coletado e armazenado permanentemente esses registros históricos.

Eu mesmo já cometi esse erro. Publiquei um site apontando para o IP real e só configurei a Cloudflare seis meses depois. Quando consultei o SecurityTrails, os registros DNS de meses antes continuavam perfeitamente visíveis.

Forma 2: cabeçalhos do servidor de e-mail — risco alto

É uma exposição discreta que muita gente nem imagina.

Sites enviam confirmações de cadastro, recuperação de senha, notificações de RSS e outras mensagens. Os cabeçalhos desses e-mails podem conter o IP do servidor remetente. Se você usa um servidor de e-mail próprio ou envia mensagens diretamente pelo servidor do site, o IP de origem fica exposto.

Como o invasor aproveita isso? Basta criar uma conta para acionar o e-mail de confirmação, abrir a mensagem original e procurar o campo Received. Ali pode aparecer o IP real do servidor remetente.

Para ser sincero, fiquei surpreso quando descobri esse problema pela primeira vez. Eu não imaginava que um e-mail também pudesse revelar o IP.

Forma 3: varredura de subdomínios — risco médio-alto

Esse problema também é bastante comum.

Talvez o domínio principal example.com esteja configurado na Cloudflare, mas e os subdomínios? Endereços como mail.example.com para e-mail, admin.example.com para o painel e dev.example.com para o ambiente de desenvolvimento podem apontar diretamente para o servidor de origem, sem passar pela CDN.

Ferramentas como Sublist3r e OneForAll enumeram todos os subdomínios. Depois, basta testar cada um: se um único endereço retornar o IP real, a localização da origem estará exposta.

Além disso, mesmo que o domínio principal e os subdomínios estejam em servidores diferentes, o invasor pode estimar a faixa de endereços se todos pertencerem ao mesmo bloco /24, como 192.168.1.x.

Forma 4: exposição no código-fonte do site — risco médio

Páginas de teste e informações de depuração deixadas durante o desenvolvimento também podem revelar o IP.

Casos comuns:

• uma página phpinfo() não removida mostra o IP do servidor e várias configurações
• o diretório .git continua acessível e os arquivos de configuração podem conter endereços IP
• o modo de depuração permanece ativo e os erros exibem caminhos do servidor e IPs
• o endereço de uma API foi fixado no código como IP em vez de domínio

Já vi uma página de teste info.php ser esquecida no servidor e indexada por mecanismos de busca, deixando todas as informações do servidor à vista. Esse tipo de erro básico é mais frequente do que parece.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Forma 5: consulta de certificados SSL — risco médio

Certificados SSL também podem ser uma fonte de exposição.

Os logs de Certificate Transparency registram todos os certificados emitidos. Ferramentas como crt.sh e Censys permitem consultar o histórico de certificados de um domínio e procurar os IPs aos quais eles já estiveram associados.

Se, antes de configurar a Cloudflare, o certificado SSL esteve ligado diretamente ao IP do servidor de origem, esse registro pode ter sido preservado. Nem sempre é possível encontrar o IP pelo certificado, mas essa é uma via real de investigação.

Forma 6: diferenças de resolução DNS no exterior — risco médio-baixo

Alguns serviços de CDN cobrem apenas rotas nacionais e não mantêm nós no exterior.

Nessa situação, uma consulta feita por um servidor DNS de outro país pode retornar diretamente o IP de origem em vez do nó da CDN. A Cloudflare é uma CDN global e sofre menos com esse problema, mas é preciso ter cuidado ao usar provedores locais menores.

O teste é simples: consulte o domínio pelo DNS do Google, 8.8.8.8, ou pelo DNS da Cloudflare, 1.1.1.1, e confira se o IP retornado pertence a um nó da CDN.

Forma 7: varredura do bloco /24 e outros sites no mesmo servidor — risco baixo

Se vários sites compartilham o mesmo servidor e um deles não está protegido, ele pode ajudar a localizar os demais.

Um invasor pode usar a sintaxe ip:xxx.xxx.xxx.xxx no Bing ou no Google para descobrir quais sites estão hospedados em determinado IP. Também pode varrer todo o bloco /24 em busca de outros sites relacionados.

O risco é menor, mas merece atenção quando muitos sites são executados no mesmo servidor.

[Imagem: resumo das formas de vazamento do IP de origem]

Prompt: infográfico com sete formas de vazamento de IP, histórico de DNS, cabeçalhos de e-mail, varredura de subdomínios, exposição de código-fonte, certificado SSL, ícones coloridos, design plano

Como verificar se o IP de origem vazou

Depois de conhecer as formas de vazamento, como saber se o seu site foi afetado? A lista abaixo permite fazer uma verificação bastante completa.

Resumo das ferramentas de detecção

Etapas detalhadas de verificação

Verificação 1: consultar o histórico de DNS

Abra estes sites e informe seu domínio:

• SecurityTrails (securitytrails.com) — mostra registros históricos de resolução DNS
• DNSdumpster (dnsdumpster.com) — ferramenta de enumeração de DNS que exibe subdomínios e registros históricos
• Netcraft (sitereport.netcraft.com) — também registra IPs usados anteriormente por sites

Se aparecer o IP real usado antes da Cloudflare, considere que ele já vazou.

Verificação 2: testar os cabeçalhos de e-mail

Este método é especialmente útil:

1. Se o site permite cadastro, crie uma conta de teste para acionar o e-mail de confirmação
2. Outra opção é solicitar a recuperação de senha e enviar a si mesmo uma mensagem de redefinição
3. Ao receber o e-mail, abra a opção de mensagem original ou exibição do código-fonte, cujo nome varia entre os clientes
4. Procure os campos Received ou X-Originating-IP
5. Confira se o endereço encontrado corresponde ao IP do servidor de origem

Se a mensagem tiver sido enviada por um serviço de terceiros, como SendGrid ou Amazon SES, aparecerá o IP desse serviço, o que não expõe sua origem.

Verificação 3: examinar subdomínios

Confira manualmente a resolução DNS de todos os subdomínios para saber se algum aponta diretamente para o IP de origem:

# Use o comando dig para consultar subdomínios
dig mail.yourdomain.com
dig admin.yourdomain.com
dig api.yourdomain.com

Você também pode usar ferramentas de varredura automática:

• Sublist3r — ferramenta em Python capaz de encontrar muitos subdomínios
• OneForAll — ferramenta de coleta de subdomínios criada por desenvolvedores chineses

Teste individualmente os subdomínios encontrados e confira se retornam um IP da Cloudflare ou o seu próprio IP.

Verificação 4: executar testes globais de ping

Teste o domínio em diferentes países e regiões para comparar os IPs retornados:

• o ping.pe executa ping simultaneamente em vários nós ao redor do mundo
• o 17ce.com oferece testes em diversas regiões da China

Se o domínio retornar IPs diferentes dentro e fora do país, pode haver um problema. Em condições normais, a Cloudflare usa uma rede global e cada região deve retornar o IP de um nó próximo da CDN.

Verificação 5: consultar associações de certificados SSL

Pesquise seu domínio no crt.sh e examine o histórico de certificados:

https://crt.sh/?q=yourdomain.com

Confira se algum certificado esteve associado ao IP de origem. Se estiver, esse endereço já pode ser considerado parcialmente público.

Verificação 6: usar mecanismos de busca da internet exposta

Este método é mais avançado, mas bastante eficaz. Pesquise seu domínio ou características do site nestes serviços:

• Shodan (shodan.io) — mecanismo de busca de dispositivos conectados à internet
• Censys (censys.io) — plataforma de varredura da internet
• Fofa (fofa.so) — mecanismo chinês de mapeamento da internet

Essas ferramentas varrem servidores na internet. Se a origem mantiver serviços públicos, como a porta 80, ela poderá ser registrada e ter o IP exposto.

Verificação 7: ler os logs do servidor

O método mais direto é examinar os logs de acesso no próprio servidor:

# Os logs do Nginx normalmente ficam em
tail -f /var/log/nginx/access.log
# Logs do Apache
tail -f /var/log/apache2/access.log

Se houver conexões diretas ao IP de origem vindas de endereços que não pertencem às faixas da Cloudflare, alguém já conhece o IP e está tentando acessá-lo.

As faixas de IP da Cloudflare estão disponíveis na documentação oficial. Em condições normais, todas as solicitações devem vir desses endereços.

Solução completa de proteção

Preparação antes de configurar

Se você ainda não usa a Cloudflare, ou descobriu que o IP vazou e pretende refazer a configuração, estas etapas evitam muitos problemas.

Preparação 1: trocar o IP do servidor ou usar um servidor novo

Esta é a solução mais completa. Se o IP de origem já vazou, o melhor é começar com outro endereço.

Em um servidor em nuvem, há algumas opções:

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

• Contratar outro servidor: migrar os dados e depois desativar o antigo
• Trocar o IP público: alguns provedores, como Alibaba Cloud e Tencent Cloud, permitem substituir um IP público elástico sem custo ou mediante uma pequena taxa
• Adotar outro domínio: se a associação entre domínio e IP for difícil de desfazer, também é possível trocar o domínio, embora o custo seja alto e isso só faça sentido em último caso

Minha recomendação: se o site ainda está no começo, migrar para um servidor novo costuma ser a opção mais simples. Com poucos dados, a mudança leva apenas alguns minutos.

Preparação 2: remover rastros que possam expor o IP

Não é possível apagar registros históricos de DNS já armazenados permanentemente por terceiros, mas você pode limpar tudo o que ainda controla:

• remova páginas de teste do servidor, como phpinfo.php e info.php
• desative o modo de depuração e a exibição de erros
• bloqueie o acesso externo ao diretório .git com uma regra no Nginx
• verifique o código do site e elimine endereços IP fixos

Preparação 3: planejar a estratégia de resolução dos domínios

Defina com antecedência quais domínios passarão pela Cloudflare:

• Domínio principal e www: devem passar pela Cloudflare
• Todos os subdomínios públicos: também devem passar pela Cloudflare, como blog, api e img
• Servidor de e-mail: se você mantém um serviço próprio, considere migrar para um provedor externo
• Serviços internos: painéis administrativos e bancos de dados não devem ter DNS público; use endereços da rede interna

Boas práticas de configuração da Cloudflare

Com a preparação concluída, veja como configurar corretamente a Cloudflare e manter o IP de origem oculto.

Prática 1: usar a CDN no site inteiro e em todos os subdomínios

Esta é a medida mais importante. Nas configurações de DNS da Cloudflare, cada registro tem um ícone de nuvem:

• Nuvem laranja: o tráfego passa pelo proxy da Cloudflare e o IP de origem fica oculto
• Nuvem cinza: não há proxy e o registro aponta diretamente para o IP de origem

Lembre-se: todos os domínios públicos devem usar a nuvem laranja. É comum proteger apenas o domínio principal e deixar todos os subdomínios com nuvem cinza, o que anula a proteção.

Use a nuvem cinza apenas nos registros que a Cloudflare não consegue intermediar, como registros MX de e-mail e registros TXT de verificação.

[Imagem: tela de configurações de DNS da Cloudflare]

Prompt: tela de configurações de DNS da Cloudflare, comparação entre nuvem laranja e nuvem cinza, destaque para o controle de status do proxy, interface limpa, 16:9

Prática 2: usar um serviço de e-mail de terceiros

Como vimos, cabeçalhos de e-mail podem revelar o IP do servidor remetente. A solução mais simples é deixar de enviar mensagens pelo próprio servidor e adotar um serviço externo:

• SendGrid: cota gratuita de 100 mensagens por dia, suficiente para sites pequenos
• Amazon SES: cobrança por uso e as primeiras 62.000 mensagens mensais gratuitas exigem uma conta AWS
• Mailgun: também oferece cota gratuita e uma API fácil de usar

Todos fornecem API e SMTP, portanto a migração não costuma ser difícil. A taxa de entrega também tende a ser muito melhor do que em um servidor próprio.

Prática 3: configurar uma lista de permissões no firewall para aceitar apenas IPs da Cloudflare

Esta é a proteção central. Mesmo que alguém conheça o IP de origem, o tráfego de ataque não entrará se o firewall aceitar somente as faixas da Cloudflare.

A Cloudflare publica a lista oficial de IPs em:

https://www.cloudflare.com/ips/

Baixe a lista e configure o firewall do servidor. Exemplo com iptables:

# ⚠️ Aviso importante: confirme antes que a porta SSH não será afetada
# Faça a validação primeiro em um ambiente de teste para não perder o acesso
# Limpe as regras atuais
iptables -F
# Permita o loopback local
iptables -A INPUT -i lo -j ACCEPT
# Permita conexões já estabelecidas
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Permita SSH (ajuste para sua própria porta SSH)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Permita somente as faixas de IP da Cloudflare nas portas 80 e 443
# Abaixo estão alguns blocos IPv4; baixe a lista completa no site oficial
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 173.245.48.0/20 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 103.21.244.0/22 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 103.22.200.0/22 -j ACCEPT
# ... adicione todas as faixas de IP da Cloudflare ...
# Bloqueie qualquer outro acesso às portas 80 e 443
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j DROP
# Salve as regras
iptables-save > /etc/iptables/rules.v4

Cuidados de configuração:

1. Teste primeiro em um ambiente de homologação
2. Mantenha obrigatoriamente o acesso à porta SSH 22
3. Depois de configurar, teste em outro dispositivo, como um celular
4. Em servidores em nuvem, prefira os grupos de segurança do painel, que são mais seguros e práticos

Se você usa um servidor em nuvem, a maioria dos provedores oferece grupos de segurança. Configurá-los pelo painel costuma ser mais simples e reduz o risco de perder o acesso por engano.

Ao final, tente acessar diretamente o IP de origem usando a rede móvel do celular. A conexão deve falhar.

[Imagem: diagrama da configuração do firewall]

Prompt: diagrama em camadas de proteção por firewall, lista de permissões para IPs da Cloudflare, bloqueio de tráfego fora da Cloudflare, ícone de escudo de segurança, ilustração tecnológica profissional

Prática 4: desativar respostas a ping no servidor

Isso dificulta a localização do servidor por meio de varreduras de faixas de IP:

# Desative o ping
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
# Para tornar a alteração permanente, edite /etc/sysctl.conf
net.ipv4.icmp_echo_ignore_all = 1
# Depois execute
sysctl -p

Assim, o servidor não responde durante uma varredura e parece ser um IP inativo.

Medidas avançadas de proteção

Se o site é importante ou já sofreu ataques, considere estas medidas adicionais.

Medida 1: usar o Cloudflare Tunnel, antigo Argo Tunnel

Esse recurso da Cloudflare permite não expor o IP de origem.

Um programa cloudflared é executado no servidor e inicia uma conexão com a rede da Cloudflare, criando um túnel seguro. Com isso:

• o servidor não precisa abrir as portas 80 e 443
• a internet não consegue alcançar diretamente o IP de origem
• todo o tráfego é encaminhado pela Cloudflare através do túnel

Configuração simplificada:

# Instale o cloudflared
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
dpkg -i cloudflared-linux-amd64.deb
# Entre na Cloudflare
cloudflared tunnel login
# Crie o túnel
cloudflared tunnel create mytunnel
# Configure a rota
cloudflared tunnel route dns mytunnel yourdomain.com
# Execute o túnel
cloudflared tunnel run mytunnel

A solução é quase perfeita para ocultar o IP. A desvantagem é uma configuração um pouco mais complexa, e alguns recursos avançados do Cloudflare Tunnel exigem um plano pago.

Medida 2: trocar periodicamente o IP de origem

Para sites de alto risco, alternar o IP regularmente é uma boa prática.

Você pode trocar o servidor ou o IP a cada três a seis meses. Mesmo que o endereço anterior tenha vazado, o invasor atacará um destino que já não está em uso. O custo é maior, portanto a decisão depende da importância do site.

Medida 3: monitorar tráfego anormal

Configure o monitoramento para alertar imediatamente quando houver acessos vindos de IPs que não pertencem à Cloudflare:

# Exemplo simples de script de monitoramento
tail -f /var/log/nginx/access.log | grep -v -E "(173\.245\.|103\.21\.|103\.22\.)" | while read line
do
    echo "Alerta: acesso de um IP fora da Cloudflare! $line"
    # O alerta pode ser enviado por e-mail ou SMS
done

Assim, você descobre rapidamente quando alguém tenta se conectar diretamente ao IP de origem.

Medida 4: não fixar endereços IP no código do site

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

Esta é uma prática básica, mas vale reforçar.

Todas as chamadas de API e cargas de recursos devem usar domínios, não endereços IP. Por exemplo:

// Exemplo incorreto
fetch('http://123.456.78.90/api/data')
// Exemplo correto
fetch('https://api.yourdomain.com/data')

Assim, mesmo quem examinar o código frontend não encontrará o IP de origem.

O que fazer quando o IP já vazou

Se o IP de origem já vazou, não é preciso entrar em pânico. Você não consegue apagar registros mantidos por terceiros, mas pode reduzir o risco.

Etapa 1: trocar imediatamente o IP do servidor

Esta é a medida mais eficaz. Solicite outro servidor ou outro IP público e migre os dados.

Estimativa de custo:

• Troca do IP de um servidor em nuvem: a maioria dos provedores não cobra ou cobra uma pequena taxa, geralmente de 10 a 20 yuans
• Novo servidor: conforme a configuração, um modelo básico com 1 núcleo e 2 GB custa cerca de 30 a 50 yuans por mês
• Tempo de migração: em um site pequeno, normalmente cerca de meia hora

Não desligue o servidor antigo imediatamente após a troca. Mantenha-o por alguns dias para confirmar que o novo ambiente funciona corretamente.

Etapa 2: configurar a lista de permissões do firewall

Mesmo com o IP exposto, um firewall bem configurado impede a entrada do invasor.

Use o exemplo de iptables ou o grupo de segurança do provedor e permita somente as faixas da Cloudflare nas portas 80 e 443. Todo o restante será bloqueado pelo firewall.

Tenha cuidado ao configurar:

1. Teste primeiro em um ambiente de homologação
2. Preserve o acesso SSH na porta 22 para não se bloquear
3. Valide em outro dispositivo depois de concluir

Eu já me bloqueei por causa de uma regra incorreta e precisei entrar por VNC no painel do provedor para corrigir o problema. Foi bastante trabalhoso.

Etapa 3: usar o Cloudflare Rate Limiting

O Cloudflare Rate Limiting limita a frequência de acesso de cada IP.

O plano gratuito tem restrições, enquanto o Pro, por US$ 20 mensais, permite regras mais detalhadas, como:

• no máximo 10 solicitações por IP a cada 10 segundos
• bloqueio automático ou Challenge de verificação acima do limite
• proteção de caminhos específicos

É uma medida eficaz contra ataques menores.

Etapa 4: considerar um serviço especializado de proteção contra DDoS

Se o site for atacado com frequência ou sustentar uma operação importante, avalie um serviço de IP com proteção avançada.

Provedores chineses como Alibaba Cloud, Tencent Cloud e Baidu Cloud oferecem produtos desse tipo:

• Cobrança por largura de banda: uma taxa fixa inclui determinado nível de proteção, como 20 Gbps
• Cobrança por volume do ataque: o custo é menor em períodos normais e aumenta quando ocorre um ataque
• Custo: de algumas centenas a dezenas de milhares de yuans por mês, conforme o nível de proteção

Para sites pessoais e pequenas empresas, o preço pode ser alto. Para e-commerce e servidores de jogos que exigem alta disponibilidade, o investimento pode compensar.

Etapa 5: monitorar e responder rapidamente

Configure alertas e intervenha assim que detectar tráfego anormal ou acesso direto ao IP de origem:

• ative notificações da Cloudflare para anomalias de tráfego
• instale ferramentas como zabbix ou prometheus no servidor
• durante um ataque, altere temporariamente o DNS para encaminhar o tráfego a um servidor de contingência

A velocidade da resposta importa. Já vi ataques durarem horas antes de serem notados, quando o custo de tráfego já era elevado.

Conclusão

Em resumo, o vazamento do IP de origem é um problema sistêmico. Configurar a Cloudflare uma única vez não resolve tudo. Há muitas formas de exposição, desde registros históricos de DNS e cabeçalhos de e-mail até varreduras de subdomínios e certificados SSL.

As medidas de proteção mais importantes são:

1. CDN no site inteiro — faça todos os domínios públicos passarem pela Cloudflare e use a nuvem laranja
2. Lista de permissões no firewall — aceite somente as faixas de IP da Cloudflare; esta é a última linha de defesa
3. Serviço de e-mail externo — use SendGrid, SES ou outro provedor em vez de enviar mensagens pelo próprio servidor
4. Verificações periódicas — use as ferramentas deste artigo para encontrar problemas antes de um ataque

Se você ainda não configurou a Cloudflare, aproveite para fazer tudo corretamente desde o início. Se já usa o serviço, mas não sabe se houve vazamento, reserve dez minutos para executar a verificação.

Se descobrir que o IP já vazou, também não entre em pânico. Troque o endereço, configure o firewall e aplique as proteções necessárias.

Vale reforçar: proteger o IP de origem é um processo contínuo, não uma tarefa única. Novos subdomínios também precisam usar a CDN, alterações de configuração não podem revelar o IP e as medidas de proteção devem ser revisadas periodicamente.

Comece consultando o histórico do seu domínio no SecurityTrails. Se houver algum problema, siga as etapas deste artigo para reforçar a infraestrutura. Dá um pouco de trabalho, mas é melhor do que ver o servidor cair durante um ataque.