Guias · Investigar um IP

Achei um IP desconhecido nos logs do meu servidor. O que eu faço?

Escrito por Aldo · threat hunter em um blue team
Última atualização: 9 de novembro de 2026 · 10 min de leitura

Você abre o log de acesso para procurar outra coisa e lá está: um endereço que você nunca viu, acessando o seu site às quatro da manhã. Veja como descobrir, em uns dez minutos, se ele merece atenção.

Comece pela parte tranquilizadora. Um servidor na internet pública recebe tráfego automatizado o dia inteiro, geralmente muito antes de alguma pessoa encontrá-lo. Rastreadores indexam páginas. Projetos de pesquisa varrem todos os endereços da internet para mapear o que existe. Outros scripts testam as mesmas poucas portas em milhões de sites, na esperança de que alguém tenha deixado uma aberta. Ver endereços desconhecidos é normal. A pergunta nunca é “esse IP é do mal?”, e sim “o que ele tentou, e funcionou?”

Encontre as linhas

O WordPress não mantém um log próprio de visitantes. O registro fica no log de acesso do seu servidor web, e onde ele está depende da sua hospedagem:

• Hospedagem compartilhada com cPanel: Métricas → Acesso bruto (Metrics → Raw Access) permite baixar o log de cada domínio. No Plesk, abra Sites e Domínios → Logs.
• Seu próprio servidor (VPS): os padrões mais comuns são /var/log/nginx/access.log para o nginx, /var/log/apache2/access.log para o Apache no Debian e no Ubuntu, e /var/log/httpd/access_log no Red Hat, Fedora e similares. A hospedagem pode ter mudado esses caminhos; o arquivo de configuração do servidor dá a palavra final.
• Windows com IIS: C:inetpublogsLogFilesW3SVC1 (o número é o ID do seu site).

Para puxar todas as linhas de um endereço no Linux ou no macOS, procure por ele seguido de um espaço. Sem o espaço, uma busca por 203.0.113.4 também encontraria 203.0.113.45:

grep -F '185.220.101.1 ' /var/log/nginx/access.log
zgrep -F '185.220.101.1 ' /var/log/nginx/access.log.*.gz   # dias anteriores, compactados

Para ver quais endereços visitam mais, conte o primeiro campo:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

No Windows, o PowerShell faz a mesma busca:

Select-String -Path 'C:inetpublogsLogFilesW3SVC1*.log' -Pattern '185.220.101.1' -SimpleMatch

O IIS grava os campos numa ordem diferente da do Apache e do nginx; a linha #Fields: no topo de cada arquivo diz qual coluna é o endereço do cliente (c-ip).

Esse é mesmo o endereço do visitante?

Confira isso antes de qualquer coisa. Se o seu site fica atrás de uma CDN ou de um proxy como a Cloudflare, o servidor pode estar registrando o endereço da CDN em todas as requisições, e não o do visitante. Se os mesmos poucos endereços aparecem em todas as linhas e pertencem à sua CDN, é a CDN que você está vendo. O servidor precisa ler o endereço original no cabeçalho que a CDN adiciona (CF-Connecting-IP na Cloudflare, por exemplo; o mod_remoteip do Apache e o módulo real_ip do nginx fazem isso). Até lá, bloquear um IP no servidor bloquearia a CDN, e todo mundo junto.

Leia uma linha

A maioria dos servidores Apache e nginx usa o formato “combined”. Esta é uma linha do exemplo abaixo, separada em partes:

185.220.101.1 - - [05/Nov/2026:09:31:07 +0000] "POST /wp-login.php HTTP/1.1" 200 6832 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"

185.220.101.1

O endereço que se conectou ao seu servidor. Numa requisição web concluída, é difícil de falsificar, mas pode ser de uma VPN, do Tor ou de um servidor de nuvem, e não da pessoa por trás.

- -

Identidade e nome de usuário. Quase sempre vazios.

[05/Nov/2026:09:31:07 +0000]

Quando aconteceu, com o fuso horário.

"POST /wp-login.php HTTP/1.1"

O que foi pedido. POST envia dados, aqui um usuário e uma senha.

200

A resposta do seu servidor. É o campo mais importante da linha.

6832

Bytes enviados de volta.

"-"

Referer: a página que trouxe até aqui. Enviado pelo cliente, então pode dizer qualquer coisa.

"Mozilla/5.0 …"

User agent: o que o cliente diz ser. Também enviado pelo cliente, então também não prova nada.

Guarde esse último ponto: o endereço é evidência, o user agent é uma alegação.

Um exemplo real: uma manhã num pequeno blog WordPress

Estas doze linhas são meia hora típica num blog pequeno. Trocamos o endereço do único leitor comum por um endereço de documentação (203.0.113.45, reservado para exemplos), então nenhuma pessoa real aparece aqui. Os outros endereços são de infraestrutura pública.

203.0.113.45 - - [05/Nov/2026:09:14:02 +0000] "GET /2026/10/back-up-your-photos/ HTTP/1.1" 200 18342 "https://www.google.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
203.0.113.45 - - [05/Nov/2026:09:14:03 +0000] "GET /wp-content/themes/twentytwentyfive/style.css HTTP/1.1" 200 4120 "https://example.com/2026/10/back-up-your-photos/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
66.249.66.1 - - [05/Nov/2026:09:15:40 +0000] "GET /2026/09/router-settings/ HTTP/1.1" 200 21004 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
167.94.138.35 - - [05/Nov/2026:09:17:11 +0000] "GET / HTTP/1.1" 200 15233 "-" "Mozilla/5.0 (compatible; CensysInspect/1.1; +https://about.censys.io/)"
3.5.140.1 - - [05/Nov/2026:09:20:55 +0000] "GET /.env HTTP/1.1" 404 548 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
3.5.140.1 - - [05/Nov/2026:09:20:55 +0000] "GET /wp-config.php.bak HTTP/1.1" 404 548 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
3.5.140.1 - - [05/Nov/2026:09:20:56 +0000] "GET /wp-content/uploads/2026/11/cache.php HTTP/1.1" 404 548 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
185.220.101.1 - - [05/Nov/2026:09:31:07 +0000] "POST /wp-login.php HTTP/1.1" 200 6832 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
185.220.101.1 - - [05/Nov/2026:09:31:09 +0000] "POST /wp-login.php HTTP/1.1" 200 6832 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
185.220.101.1 - - [05/Nov/2026:09:31:12 +0000] "POST /xmlrpc.php HTTP/1.1" 200 4272 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
185.220.101.1 - - [05/Nov/2026:09:31:15 +0000] "POST /wp-login.php HTTP/1.1" 200 6832 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
40.77.167.10 - - [05/Nov/2026:09:40:28 +0000] "GET /robots.txt HTTP/1.1" 200 67 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"

Colamos o log no verificador de logs do iplover. Ele encontrou seis endereços e comparou os cinco públicos com as listas públicas do nosso servidor; o log em si ficou no navegador. Esta é a tabela de resultados que ele mostrou em 9 de novembro de 2026:

Duas colunas, duas perguntas. Categoria diz pelo que o endereço é conhecido: rastreador, scanner, Tor, provedor de nuvem. Tipo de rede diz a que tipo de rede ele pertence, até onde as listas públicas mostram. “Não identificado” ali só quer dizer que nenhuma lista o cobre; não é um veredito sobre o endereço.

As listas mudam todos os dias, então, se você rodar o mesmo exemplo mais tarde, algum resultado pode mudar. Veja o que cada grupo significa para este site.

O leitor: 203.0.113.45

Duas requisições com um segundo de diferença: um post, depois a folha de estilo do tema, com o Google como referer e um user agent comum de Chrome. É uma pessoa que pesquisou, clicou e leu. No seu próprio log, o endereço de um visitante de verdade apareceria como de um provedor de internet. Nada a fazer.

Os rastreadores: 66.249.66.1 e 40.77.167.10

O Googlebot buscou um post, o Bingbot leu o robots.txt. O verificador de logs encontrou os dois endereços nas listas que os buscadores publicam, e é por isso que dá nome a eles; ele nunca se baseia só no user agent. Você mesmo pode confirmar o Googlebot com duas consultas DNS, como o Google recomenda: a consulta reversa precisa terminar em googlebot.com, google.com ou googleusercontent.com, e a consulta direta desse nome precisa devolver o mesmo endereço.

host 66.249.66.1
host crawl-66-249-66-1.googlebot.com

Se você prefere que um rastreador venha menos, diga isso no robots.txt. Bloquear buscadores de verdade tira você dos resultados deles.

O scanner: 167.94.138.35

A Censys varre a internet inteira e deixa os resultados pesquisáveis para equipes de segurança e pesquisadores. Ela pediu a sua página inicial e foi embora. Isso é ruído, não ataque. Você pode bloquear scanners se as linhas incomodam, mas eles não colocam o seu site em risco.

O impostor: 3.5.140.1

Esta é a linha que deveria fazer você olhar duas vezes. O user agent diz Googlebot, mas o endereço é da Amazon Web Services, não do Google. Os rastreadores do Google não rodam na nuvem da Amazon. Qualquer um pode escrever “Googlebot” num user agent.

Agora veja o que ele queria: /.env, /wp-config.php.bak e um arquivo .php dentro da pasta uploads. É uma lista de compras de segredos: arquivos .env e cópias de backup do wp-config.php costumam ter senhas de banco de dados e chaves, e um arquivo PHP em uploads seria um backdoor deixado antes por alguém. Os três receberam 404. Não havia nada lá, então nada foi levado.

Garanta que continue assim. Peça esses caminhos você mesmo e confira se a resposta é 404 ou 403, nunca 200:

curl -I https://example.com/.env
curl -I https://example.com/wp-config.php.bak

O adivinhador de senhas: 185.220.101.1

Quatro requisições POST em oito segundos, três para /wp-login.php e uma para /xmlrpc.php. É alguém testando senhas. O endpoint XML-RPC é um dos preferidos porque uma única requisição pode levar muitos palpites.

Todas as respostas foram 200, e isso é boa notícia. Quando um login no WordPress falha, a página de login aparece de novo com um erro, e essa página é um 200. Um login bem-sucedido recebe um redirecionamento para o painel, que aparece no log como 302. Sem 302, ninguém entrou.

O endereço é um relay de saída do Tor, compartilhado por muita gente. Bloqueá-lo pararia essas quatro requisições, mas a próxima tentativa simplesmente chega por outra saída, ou de um servidor de nuvem. O próprio Tor Project lembra que alguns usuários do Tor podem ser visitantes legítimos do seu site. A solução duradoura está do seu lado, mais abaixo.

Veredito desta manhã: ninguém entrou. Mas vale corrigir duas coisas: reforçar o login e confirmar que os arquivos secretos estão mesmo inacessíveis.

Se você vir isto, faça isto

O mesmo raciocínio vale para qualquer linha. Encontre a linha da tabela que corresponde ao que você está vendo:

Reforce o login

As tentativas de senha nunca param, então torne-as inúteis em vez de tentar bloquear cada endereço:

• Use uma senha longa e única em cada conta que pode fazer login, começando pelos administradores.
• Ative a autenticação de dois fatores para os administradores. O WordPress não traz isso de fábrica, então é preciso um plugin.
• Limite as tentativas de login, de preferência na CDN ou no servidor web, ou com um plugin de segurança.
• Se nada do que você usa precisa do XML-RPC (alguns plugins, como o Jetpack, e alguns apps antigos precisam), desative-o ou bloqueie /xmlrpc.php.

Quando bloquear um endereço faz sentido

Bloquear vale a pena para uma fonte única e persistente que está desperdiçando recursos, como um servidor de nuvem martelando o seu site. É uma defesa fraca contra todo o resto, porque bots trocam de endereço à vontade. Se for bloquear um, veja como. (A caixa Copiar uma lista de bloqueio do verificador de logs escreve estas linhas para você, para as categorias que você marcar.)

Apache 2.4, na configuração do site ou no .htaccess:

<RequireAll>
    Require all granted
    Require not ip 203.0.113.45
</RequireAll>

nginx, dentro do bloco server:

deny 203.0.113.45;

Atrás da Cloudflare ou de outra CDN, bloqueie na CDN (a Cloudflare chama isso de IP Access Rules ou regras personalizadas do WAF; os nomes dos menus mudam de vez em quando). O seu servidor só vê os endereços da CDN, a menos que você o tenha configurado para ler o do visitante.

O que um endereço IP não consegue dizer

Um endereço aponta para uma rede, não para uma pessoa. Ele pode ser compartilhado por milhares de pessoas atrás de um mesmo provedor, de uma VPN ou do Tor. Pode ser de outra pessoa na semana que vem. A localização é uma estimativa, muitas vezes só a cidade mais próxima do provedor. Então não trate um endereço como uma identidade e não tente localizar ninguém a partir dele. Nossos guias sobre o que alguém pode fazer com um endereço IP e sobre se um IP revela o endereço de casa explicam por quê.

Se um endereço continua atacando você, o contato útil é a rede que o opera. A consulta de IP mostra o dono e o e-mail de abuso, tirados dos registros oficiais. Espere resposta para abusos persistentes de um servidor, não para uma varredura isolada. Se você perdeu dados ou dinheiro, registre também um boletim de ocorrência; em muitos estados dá para fazer isso on-line, na delegacia virtual.