Guide · Indagare su un IP

Ho trovato un IP sconosciuto nei log del mio server. Cosa devo fare?

Scritto da Aldo · threat hunter in un blue team
Ultimo aggiornamento: 9 novembre 2026 · 10 min di lettura

Apri il log degli accessi per cercare tutt'altro, ed eccolo lì: un indirizzo mai visto che bussa al tuo sito alle quattro di mattina. Ecco come capire, in una decina di minuti, se merita davvero attenzione.

Partiamo dalla parte rassicurante. Un server raggiungibile da internet riceve traffico automatico tutto il giorno, di solito molto prima che una persona lo trovi. I crawler indicizzano le pagine. Progetti di ricerca scansionano ogni indirizzo di internet per mappare cosa c'è in giro. Altri script provano sempre le stesse poche porte su milioni di siti, sperando che qualcuno ne abbia lasciata una aperta. Vedere indirizzi che non conosci è normale. La domanda non è mai “questo IP è cattivo?”, ma “cosa ha provato a fare, e ci è riuscito?”

Trova le righe

WordPress non tiene un registro dei visitatori. La traccia è nel log degli accessi del server web, e dove si trova dipende dal tuo hosting:

• Hosting condiviso con cPanel: Metriche → Accesso grezzo (Metrics → Raw Access) ti fa scaricare il log di ogni dominio. Con Plesk, apri Siti web e domini → Log.
• Server tuo (VPS): i percorsi predefiniti più comuni sono /var/log/nginx/access.log per nginx, /var/log/apache2/access.log per Apache su Debian e Ubuntu, e /var/log/httpd/access_log su Red Hat, Fedora e simili. Il tuo provider potrebbe averli cambiati; l'ultima parola spetta al file di configurazione del server.
• Windows con IIS: C:\inetpub\logs\LogFiles\W3SVC1\ (il numero è l'ID del sito).

Per estrarre tutte le righe di un indirizzo su Linux o macOS, cercalo con uno spazio dopo. Senza lo spazio, una ricerca di 203.0.113.4 troverebbe anche 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   # giorni precedenti, compressi

Per vedere quali indirizzi passano più spesso, conta il primo campo:

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

Su Windows la stessa ricerca si fa con PowerShell:

Select-String -Path 'C:\inetpub\logs\LogFiles\W3SVC1\*.log' -Pattern '185.220.101.1' -SimpleMatch

IIS scrive i campi in un ordine diverso da Apache e nginx; la riga #Fields: all'inizio di ogni file ti dice quale colonna contiene l'indirizzo del client (c-ip).

È davvero l'indirizzo del visitatore?

Controllalo prima di tutto il resto. Se il tuo sito sta dietro una CDN o un proxy come Cloudflare, il server potrebbe registrare per ogni richiesta l'indirizzo della CDN, non quello del visitatore. Se in ogni riga compaiono sempre gli stessi pochi indirizzi e appartengono alla tua CDN, stai guardando la CDN. Il server deve leggere l'indirizzo originale dall'intestazione che la CDN aggiunge (per Cloudflare è CF-Connecting-IP; in Apache se ne occupa mod_remoteip, in nginx il modulo real_ip). Finché non lo fa, bloccare un IP sul server vorrebbe dire bloccare la CDN, e tutti i visitatori con lei.

Leggi una riga

La maggior parte dei server Apache e nginx usa il formato “combined”. Ecco una riga dell'esempio qui sotto, scomposta nelle sue parti:

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

L'indirizzo che si è collegato al tuo server. Per una richiesta web completata è difficile da falsificare, anche se può appartenere a una VPN, a Tor o a un server cloud invece che alla persona che c'è dietro.

- -

Identità e nome utente. Quasi sempre vuoti.

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

Quando è successo, con lo scostamento del fuso orario.

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

Cosa ha chiesto. POST invia dati, qui un nome utente e una password.

200

La risposta del tuo server. È il campo più importante della riga.

6832

Byte inviati in risposta.

"-"

Referrer: la pagina che conteneva il link. Lo invia il client, quindi può dire qualsiasi cosa.

"Mozilla/5.0 …"

User agent: ciò che il client dichiara di essere. Anche questo lo invia il client, quindi non è una prova.

Tieni a mente quest'ultimo punto: l'indirizzo è un indizio concreto, lo user agent è solo una dichiarazione.

Un esempio concreto: una mattina su un piccolo blog WordPress

Queste dodici righe sono una mezz'ora tipica su un piccolo blog. Abbiamo sostituito l'indirizzo dell'unico lettore normale con un indirizzo di documentazione (203.0.113.45, riservato agli esempi), così qui non compare nessuna persona reale. Gli altri indirizzi sono infrastruttura pubblica.

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)"

Abbiamo incollato il log nel log checker di iplover. Ha trovato sei indirizzi e ha controllato i cinque pubblici sulle liste pubbliche del nostro server; il log è rimasto nel browser. Questa è la tabella dei risultati che ha mostrato il 9 novembre 2026:

Due colonne, due domande. Categoria dice per cosa è noto l'indirizzo: un crawler, uno scanner, Tor, un provider cloud. Tipo di rete dice a che tipo di rete appartiene, per quanto risulta dalle liste pubbliche. “Non identificato” lì significa solo che nessuna lista lo copre; non è un giudizio sull'indirizzo.

Le liste cambiano ogni giorno, quindi se rifai lo stesso esempio più avanti un risultato può essere diverso. Ecco cosa significa ogni gruppo per questo sito.

Il lettore: 203.0.113.45

Due richieste a un secondo di distanza: un articolo del blog, poi il foglio di stile del tema, con Google come referrer e un normale user agent di Chrome. È una persona che ha cercato, cliccato e letto. Nel tuo log, l'indirizzo di un visitatore vero comparirebbe come un provider internet. Niente da fare.

I crawler: 66.249.66.1 e 40.77.167.10

Googlebot ha scaricato un articolo, Bingbot ha letto robots.txt. Il log checker ha trovato entrambi gli indirizzi nelle liste pubblicate dai motori di ricerca, ed è per questo che li chiama per nome; non si fida mai del solo user agent. Puoi verificare Googlebot da solo con due interrogazioni DNS, come consiglia Google: la ricerca inversa deve finire con googlebot.com, google.com o googleusercontent.com, e la ricerca diretta di quel nome deve restituire lo stesso indirizzo.

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

Se preferisci che un crawler passi meno spesso, diglielo in robots.txt. Bloccare i veri motori di ricerca ti fa sparire dai loro risultati.

Lo scanner: 167.94.138.35

Censys scansiona l'intera internet e rende i risultati consultabili da team di sicurezza e ricercatori. Ha chiesto la tua homepage ed è andato via. È rumore, non un attacco. Puoi bloccare gli scanner se le righe ti danno fastidio, ma non mettono a rischio il tuo sito.

L'impostore: 3.5.140.1

Questa è la riga che dovrebbe farti guardare due volte. Lo user agent dice Googlebot, ma l'indirizzo appartiene ad Amazon Web Services, non a Google. I crawler di Google non girano sul cloud di Amazon. Chiunque può scrivere “Googlebot” in uno user agent.

Poi guarda cosa cercava: /.env, /wp-config.php.bak e un file .php nella cartella degli upload. È una lista della spesa di segreti: i file .env e le copie di backup di wp-config.php contengono spesso password del database e chiavi, e un file PHP in uploads sarebbe una backdoor lasciata da qualcuno in precedenza. Tutte e tre le richieste hanno avuto 404. Non c'era niente, quindi non è stato preso niente.

Assicurati che resti così. Chiedi tu stesso quei percorsi e verifica che la risposta sia 404 o 403, mai 200:

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

Chi tenta le password: 185.220.101.1

Quattro richieste POST in otto secondi, tre a /wp-login.php e una a /xmlrpc.php. È qualcuno che prova password. L'endpoint XML-RPC è tra i preferiti perché una sola richiesta può contenere molti tentativi.

Ogni risposta è stata 200, ed è una buona notizia. Quando un login di WordPress fallisce, la pagina di accesso viene mostrata di nuovo con un errore, e quella pagina è un 200. Un login riuscito riceve invece un reindirizzamento alla bacheca, che nel log appare come 302. Niente 302, nessun accesso.

L'indirizzo è un nodo di uscita Tor, condiviso da molte persone. Bloccarlo fermerebbe queste quattro richieste, ma il tentativo successivo arriverebbe semplicemente da un altro nodo, o da un server cloud. Lo stesso Tor Project ricorda che alcuni utenti Tor possono essere visitatori legittimi del tuo sito. La soluzione che dura è dalla tua parte, e la trovi più sotto.

Verdetto della mattinata: non è entrato nessuno. Due cose però vanno sistemate: rafforzare il login e verificare che i file segreti non siano davvero raggiungibili.

Se vedi questo, fai questo

Lo stesso ragionamento vale per qualsiasi riga. Trova quella che corrisponde a ciò che hai davanti:

Rafforza il login

I tentativi di password non finiscono mai, quindi rendili inutili invece di inseguire ogni indirizzo:

• Usa una password lunga e unica per ogni account che può accedere, a partire dagli amministratori.
• Attiva l'autenticazione a due fattori per gli amministratori. WordPress non la include di serie, quindi serve un plugin.
• Limita i tentativi di accesso, meglio se sulla CDN o sul server web, oppure con un plugin di sicurezza.
• Se niente di ciò che usi ha bisogno di XML-RPC (alcuni plugin come Jetpack e alcune app più vecchie sì), disattivalo o blocca /xmlrpc.php.

Quando bloccare un indirizzo ha senso

Bloccare conviene per una singola fonte insistente che spreca risorse, per esempio un server cloud che martella il tuo sito. Contro tutto il resto è una difesa debole, perché i bot cambiano indirizzo quando vogliono. Se decidi di bloccarne uno, ecco come. (Il riquadro Copia una blocklist del log checker scrive queste righe per te, per le categorie che spunti.)

Apache 2.4, nella configurazione del sito o in .htaccess:

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

nginx, dentro il blocco server:

deny 203.0.113.45;

Dietro Cloudflare o un'altra CDN, blocca sulla CDN (Cloudflare le chiama IP Access Rules o regole personalizzate del WAF; i nomi dei menu cambiano di tanto in tanto). Il tuo server vede solo gli indirizzi della CDN, a meno che tu non l'abbia configurato per leggere quello del visitatore.

Cosa un indirizzo IP non può dirti

Un indirizzo indica una rete, non una persona. Può essere condiviso da migliaia di persone dietro lo stesso provider, una VPN o Tor. La settimana prossima può appartenere a qualcun altro. La sua posizione è una stima, spesso solo la città più vicina del provider. Quindi non trattare un indirizzo come un'identità, e non cercare di rintracciare qualcuno a partire da esso. Le nostre guide su cosa si può fare con un indirizzo IP e su se un IP rivela un indirizzo di casa spiegano perché.

Se un indirizzo continua ad attaccarti, il contatto utile è la rete che lo gestisce. Il lookup IP mostra il titolare e il suo indirizzo per gli abusi, presi dai registri ufficiali. Aspettati una risposta per abusi ripetuti da un server, non per una singola scansione. Se hai perso dati o denaro, denuncialo anche alla Polizia Postale o alle autorità del tuo paese.