Appena metti online un server, qualcuno inizia a bussare. Non perché tu sia importante o interessante: su internet esistono scanner automatici che provano ogni indirizzo raggiungibile, a ogni ora. Per capire quanto è intenso questo rumore di fondo ho guardato il Security Log che il bot ALTaiR pubblica ogni quattro ore nel canale #X-Trivia (e a richiesta con il comando !log), sul server che ospita il sito e i bot del canale. Ecco cosa è successo in appena 24 ore.
⚡ I numeri di una giornata
- SSH: 4.229 eventi di accesso fallito registrati nei log in 24 ore. Un singolo tentativo può lasciare più righe, quindi i tentativi reali sono meno, ma dell’ordine di migliaia.
- Web (Nginx), ultime 5.000 richieste: 297 errori 403, 258 errori 404 e 347 connessioni chiuse con il codice 444.
- In proporzione: poco meno di una richiesta web su cinque (902 su 5.000, il 18%) era di un tipo che un visitatore normale non genera.
1. SSH: migliaia di porte bussate in un giorno
SSH è il servizio che permette di amministrare un server da remoto, ed è il primo bersaglio dei bot. Quei 4.229 eventi non sono 4.229 persone diverse, e nemmeno altrettanti tentativi distinti (lo script che li conta somma le righe di log che contengono messaggi come Failed password, Invalid user o [preauth], e un solo tentativo ne può generare più di una). Dietro ci sono programmi che provano combinazioni di nome utente e password prese da elenchi già pronti, a velocità costante e senza stancarsi.
Contando i tentativi con un nome utente inesistente nelle ultime 24 ore, i più provati sono: ubuntu (128 volte), rfnode (109), admin (76), user (31), test (14), poi oracle, dell, ubnt e deploy. Il nome più interessante è rfnode, al secondo posto, più frequente di admin: gli scanner provano il nome del dominio come utente, probabilmente perché lo ricavano dai certificati e dai record DNS pubblici. Resta fuori da questa classifica root, che invece esiste su ogni sistema Linux e compare in righe diverse del log (authenticating user root), ma compare molto spesso. Chi scansiona non sa nulla del server: spera solo che qualcuno abbia lasciato una password debole.
Nel log si vede anche perché il numero di righe supera quello dei tentativi: ogni tentativo ne lascia due, per esempio una riga Invalid user ... e subito dopo una Connection closed ... [preauth]. La dicitura [preauth] indica che la connessione è stata chiusa prima ancora di arrivare all’autenticazione: molti scanner si collegano, guardano e se ne vanno.
La cosa che conta: gli accessi riusciti
Il numero dei fallimenti, da solo, dice poco. Quello da controllare è se qualcuno è entrato. Se il server accetta solo chiavi SSH e non password, i bot non hanno alcuna possibilità di successo, per quanti tentativi facciano: possono solo sprecare banda.
2. Nginx: cosa significano 403, 404 e 444
Il server web registra ogni richiesta con un codice di risposta. Guardando le ultime 5.000 richieste, ecco cosa mostrano gli errori più frequenti:
| Codice | Richieste | Cosa significa |
|---|---|---|
| 403 | 297 | Accesso vietato: qualcuno ha chiesto un percorso che il server non permette di leggere, per esempio file nascosti o cartelle riservate. |
| 404 | 258 | Pagina inesistente: gli scanner cercano indirizzi tipici, come pannelli di amministrazione o file di configurazione, che su questo sito non ci sono. |
| 444 | 347 | Connessione chiusa senza risposta: è un codice speciale di Nginx, usato per ignorare del tutto le richieste indesiderate. |
Il codice 444: chiudere la porta senza dare spiegazioni
A differenza degli altri, il 444 non esiste nel protocollo HTTP: è un’invenzione di Nginx. Quando il server lo usa, chiude la connessione senza inviare nulla. È una tecnica utile contro chi scansiona gli indirizzi IP o chiede nomi di dominio che sul server non esistono: non restituire nemmeno un messaggio d’errore fa perdere tempo allo scanner e non rivela niente sulla configurazione.
3. Come leggere questi dati sul tuo server
Se hai un server Linux, puoi ricavare gli stessi numeri con pochi comandi. I percorsi e il nome del servizio possono cambiare a seconda della distribuzione.
Password errate nelle ultime 24 ore (su Debian e Ubuntu il servizio si chiama ssh, su altre distribuzioni sshd). Questo comando conta solo le righe Failed password, quindi darà un numero più basso di quello del Security Log, che somma più tipi di riga:
journalctl -u ssh --since "24 hours ago" | grep -c "Failed password"
Nomi utente più provati:
journalctl -u ssh --since "24 hours ago" | grep "Invalid user" | awk '{print $8}' | sort | uniq -c | sort -rn | head
Accessi riusciti, quelli da controllare davvero:
journalctl -u ssh --since "24 hours ago" | grep "Accepted"
Codici di risposta delle ultime 5.000 richieste di Nginx:
tail -n 5000 /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -rn
Percorsi più cercati tra i 404:
tail -n 5000 /var/log/nginx/access.log | awk '$9==404 {print $7}' | sort | uniq -c | sort -rn | head
Se l’output non corrisponde, probabilmente il formato dei log è diverso e vanno cambiati i numeri dei campi ($8, $9, $7).
🛡️ Come difendere un server: l’essenziale
- Solo chiavi SSH, niente password: con
PasswordAuthentication nonel file di configurazione di SSH i bot non possono indovinare nulla. - Niente accesso diretto come root: usa un utente normale e
sudo, conPermitRootLogin no. - Banna chi insiste: strumenti come Fail2ban o CrowdSec bloccano gli indirizzi che sbagliano troppe volte.
- Firewall con poche porte aperte: lascia raggiungibili solo i servizi che servono davvero.
- Aggiornamenti regolari: la maggior parte dei compromessi sfrutta falle già corrette.
- Un server web che non risponde a tutti: chiudi le richieste che arrivano con nomi di dominio sconosciuti, per esempio con
return 444;nel blocco predefinito di Nginx. - Un controllo automatico: avere un riepilogo periodico come il Security Log di ALTaiR fa notare subito un picco anomalo.
Una nota su cambiare porta
Spostare SSH su una porta non standard riduce molto il rumore nei log, perché gli scanner più semplici provano solo la 22. Non è però una vera protezione: chi scansiona tutte le porte la trova comunque. Va considerata una comodità per leggere meglio i log, mai al posto di chiavi e firewall.
Conclusione
Migliaia di tentativi in un giorno fanno impressione, ma sono la normalità per qualsiasi server raggiungibile da internet. Il punto non è quanti ne arrivano, ma che non ne vada a buon fine nessuno. Con poche regole di base e un controllo quotidiano, il rumore di fondo resta rumore. E guardare i propri log, ogni tanto, è il modo migliore per capire come funziona davvero la sicurezza di un server.
Articolo a cura della Redazione di rfnode.net