Nel 2025 gli attacchi informatici gravi contro organizzazioni italiane sono cresciuti del 42% rispetto all’anno precedente,
con oltre cinquecento incidenti documentati solo nel nostro Paese secondo il Rapporto Clusit 2026.^[1] Non si tratta più soltanto di “criminalità digitale”, ma di un conflitto ibrido in cui cybercrime, hacktivism e interessi geopolitici si sovrappongono e si alimentano a vicenda.

Il Clusit evidenzia come in Italia la quota maggiore degli incidenti sia attribuibile al cybercrime,ma un ruolo in forte crescita è giocato dalle campagne di hacktivism, aumentate di oltre il 100% in un anno e spesso collegate a tensioni internazionali come la guerra in Ucraina, i rapporti tra Russia e Unione europea, le rivalità tra Stati Uniti e Cina e le crisi in Medio Oriente.
Nel mirino finiscono infrastrutture critiche, pubbliche amministrazioni, aziende private e studi professionali: chiunque gestisca dati o servizi esposti su Internet diventa un bersaglio potenziale.

In risposta, l’Italia ha avviato una strategia di rafforzamento della difesa digitale, con un ruolo centrale affidato all’Agenzia per la Cybersicurezza Nazionale e alla Strategia Nazionale di Cybersicurezza 2025–2027, che trasformano la sicurezza informatica in un tema di resilienza del sistema Paese e di competitività economica.

La direttiva europea NIS2, nel frattempo, estende obblighi minimi di sicurezza e gestione del rischio a una platea sempre più ampia di imprese, incluse molte PMI e realtà professionali che fino a pochi anni fa si percepivano ai margini di questo scenario.

Dal conflitto ibrido al tuo server: la sicurezza vista dai log

Tutto questo può sembrare astratto finché non si guarda dentro a un server reale, ad esempio una macchina Linux che ospita un sito WordPress, un servizio di posta e l’accesso SSH per gli amministratori.
È proprio lì, nei log di sistema, che la “guerra ibrida” assume una dimensione concreta: una pioggia continua di pacchetti, tentativi di connessione, bot e crawler che bussano alle porte digitali ventiquattr’ore su ventiquattro.

Analizziamo quindi alcuni spezzoni reali di log per capire:

• come si vede un attacco o uno scanning dalla prospettiva del sistema operativo;
• quale ruolo giocano strumenti come UFW (firewall) e fail2ban (banning dinamico basato sui log);
• quali sono le buone pratiche minime per difendere un server esposto a Internet;
• cosa non bisognerebbe mai fare in produzione.

Il primo anello di difesa: il firewall UFW

Partiamo dal perimetro di rete. Su molte distribuzioni basate su Debian/Ubuntu viene utilizzato UFW (Uncomplicated Firewall) come interfaccia semplificata a iptables o nftables per gestire le regole di filtraggio.
Nei log di kernel possono comparire righe di questo tipo:

Mar 16 18:29:43 kernel: [UFW BLOCK] IN=enx3 OUT= MAC=... SRC=113.203.203.206 DST=80.211.128.113 \
LEN=40 TOS=0x00 PREC=0x00 TTL=239 ID=45711 PROTO=TCP SPT=44577 DPT=3186 WINDOW=1024 RES=0x00 SYN URGP=0
Mar 16 18:28:41 kernel: [UFW BLOCK] IN=enx3 OUT= MAC=... SRC=61.245.11.87 DST=80.211.128.113 \
LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=14459 PROTO=TCP SPT=56114 DPT=2222 WINDOW=65535 RES=0x00 SYN URGP=0
Mar 16 18:28:56 kernel: [UFW BLOCK] IN=enx3 OUT= MAC=... SRC=162.142.125.250 DST=80.211.128.113 \
LEN=46 TOS=0x00 PREC=0x00 TTL=38 ID=43322 PROTO=UDP SPT=48218 DPT=46460 LEN=26

La parte fondamentale di queste righe è il blocco centrale: SRC indica l’IP sorgente, DST l’indirizzo del server, PROTO il protocollo (TCP o UDP), SPT la porta sorgente e DPT la porta di destinazione.
In tutti questi casi il firewall sta bloccando connessioni in ingresso sull’interfaccia esterna enx3 verso porte non esposte dalla policy (3186, 2222, 46460 e così via), spesso con pacchetti TCP flaggati SYN, cioè tentativi di apertura di una nuova sessione.

Questo è il rumore di fondo dello scanning globale: migliaia di indirizzi IP che ogni giorno provano porte a caso su server di tutto il mondo alla ricerca di un servizio poco protetto, come protocolli legacy, servizi di gestione remota obsoleti o applicazioni con vulnerabilità note.
I pacchetti UDP verso porte elevate sono un’altra faccia dello stesso fenomeno, spesso utilizzati per individuare servizi sfruttabili in attacchi di tipo reflection o amplification.

In questo articolo divulgativo orientato alle PMI, è utile spiegare che queste righe non indicano “un attacco mirato in corso”, ma piuttosto una costante attività di esplorazione automatizzata della superficie esposta: un motivo in più per avere un firewall configurato in modo corretto e non basarsi mai su “nessuno conosce il mio server”.

SSH: la porta più ambita dai bot

Se il firewall è il muro esterno, il servizio SSH è la “porta di servizio” per eccellenza, quella da cui amministratori e tecnici accedono alla macchina.
Non sorprende che sia uno dei bersagli principali dei bot che fanno brute force o scanning a larga scala.
Nei log possiamo vedere errori come questi:

Mar 15 12:19:40 sshd[3016203]: error: kex_exchange_identification: read: Connection reset by peer
Mar 15 03:48:53 sshd[2916786]: error: kex_exchange_identification: Connection closed by remote host
Mar 11 09:44:02 sshd[1639968]: error: kex_exchange_identification: client sent invalid protocol identifier "GET / HTTP/1.1"
Mar 11 09:44:01 sshd[1639965]: error: kex_exchange_identification: banner line contains invalid characters

La stringa kex_exchange_identification si riferisce alla fase di scambio iniziale delle chiavi e del banner di identificazione del protocollo SSH.
Quando vediamo messaggi come “read: Connection reset by peer” o “Connection closed by remote host”, significa che il client (spesso un bot automatico) si connette, scambia qualche byte e poi chiude bruscamente la sessione, magari perché il servizio non risponde come previsto o perché lo scanner procede rapidamente a testare altre porte.

La riga con client sent invalid protocol identifier "GET / HTTP/1.1" è ancora più interessante:
qualcuno sta inviando una richiesta HTTP (tipica del web) alla porta SSH, probabilmente un tool che prova a mandare GET / su più porte per capire se dietro c’è un server web o un altro tipo di servizio.
L’errore “banner line contains invalid characters” indica invece che i dati ricevuti non rispettano il formato previsto dal protocollo SSH, altro sintomo di scanner automatizzati o tentativi di exploit su implementazioni vulnerabili.

È importante sottolineare che qui non siamo ancora allo stadio “sto provando password a caso”: questi log descrivono traffico che non arriva neppure alla schermata di login, ma che basta da solo per indicare un ecosistema di bot, scanner e tool automatici che testano e mappano continuamente le porte esposte.

Mail server e rischi nascosti: l’esempio di Axigen

Proseguendo l’analisi, possiamo incontrare log del server di posta simili a questi:

Mar 13 11:35:19 sendmail-2344903[2344903]: Transaction aborted: cannot create a new mail in queue '/var/opt/axigen/queue' (No such file or directory)
Mar 11 23:10:35 sendmail-1797153[1797153]: Transaction aborted: cannot create a new mail in queue '/var/opt/axigen/queue' (No such file or directory)

Qui il problema è prima di tutto operativo: il processo di invio non riesce a scrivere la mail nella coda (queue) perché la directory non esiste o non ha i permessi corretti.
Tuttavia, in un contesto di sicurezza, il mail server rappresenta uno degli asset più delicati: se configurato male, può trasformarsi in un “open relay” utilizzato per spedire spam o campagne di phishing, con conseguenze pesanti sulla reputazione degli indirizzi IP e dei domini associati.

Anche qui strumenti come fail2ban possono essere estesi ai log dell’MTA, per individuare pattern anomali (molte transazioni fallite, tentativi ripetuti di invio da IP sospetti, autentiche fallite in serie) e reagire automaticamente con il blocco degli indirizzi sorgente.
Nell’ottica di una difesa a tutto tondo, disponibilità del servizio e sicurezza vanno considerati insieme: un errore di coda non è solo un disservizio, può essere il sintomo di una configurazione fragile che in futuro agevola abusi.

Livello HTTP: utenti reali, servizi e crawler “grigi”

I log HTTP raccontano invece la vita quotidiana del sito web, con una miscela di traffico umano, servizi applicativi e bot.
Uno spezzone può apparire così:

195.234.109.176 - - [16/Mar/2026:18:31:00 +0100] "GET /wp-content/uploads/...jpg HTTP/1.1" 301 162 "-" "Photon/1.0"
80.211.128.113 - - [16/Mar/2026:18:31:04 +0100] "POST /wp-cron.php?doing_wp_cron=... HTTP/1.1" 200 11 "-" "WordPress/6.9.4; https://onida.sssr.it"
192.0.103.42 - - [16/Mar/2026:18:31:06 +0100] "HEAD / HTTP/1.1" 200 0 "-" "jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)"
149.154.161.202 - - [16/Mar/2026:18:31:07 +0100] "GET /associazioni-culturali-non-ets-cosa-cambia-dal-2026/ HTTP/2.0" 200 39135 "-" "TelegramBot (like TwitterBot)"
2.39.218.219 - - [16/Mar/2026:18:31:11 +0100] "POST /wp-admin/admin-ajax.php HTTP/2.0" 200 51 "https://onida.sssr.it/wp-admin/admin.php?page=stats" "Mozilla/5.0 ..."

In queste righe vediamo:

• richieste a un’immagine da parte di Photon, un servizio di ottimizzazione immagini dell’ecosistema WordPress;
• una chiamata a wp-cron.php, il sistema di cron interno di WordPress che esegue task pianificati quando il sito riceve visite;
• richieste HEAD con user agent jetmon, il monitor di uptime di Jetpack che verifica periodicamente se il sito è online;
• il bot di Telegram che preleva il contenuto di una pagina per generare l’anteprima quando un link viene condiviso in chat;
• una chiamata a admin-ajax.php con user agent da browser desktop, tipicamente un amministratore che consulta statistiche o funzioni di backend.

Accanto a questo traffico legittimo troviamo anche crawler “grigi”, come nell’esempio seguente:

47.128.124.245 - - [16/Mar/2026:18:31:17 +0100] "GET /robots.txt HTTP/1.1" 200 171 "-" \
"Mozilla/5.0 (Linux; Android 5.0) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 \
(compatible; Bytespider; spider-feedback@bytedance.com)"

Bytespider è un crawler associato all’ecosistema ByteDance (TikTok), noto per essere piuttosto aggressivo in termini di numero di richieste e di frequenza di accesso.
Diversi provider hanno scelto di limitarlo o bloccarlo proprio per ridurre carico e scraping massivo, dimostrando come esista un’ampia zona grigia tra traffico completamente legittimo e vero e proprio attacco: bot che non sono malware ma possono comunque impattare prestazioni, banda e protezione dei contenuti.

Fail2ban: dai log alla reazione automatica

A questo punto è evidente che i log, da soli, non bastano: registrano ciò che accade, ma non reagiscono. Qui entra in gioco fail2ban, uno strumento che legge continuamente i file di log (SSH, web server, mail, ecc.) e applica regole di blocco temporaneo quando rileva pattern pericolosi.

Il funzionamento è concettualmente semplice:

• vengono definiti dei filtri (regex che intercettano, ad esempio, errori di login, stringhe kex_exchange_identification anomale, richieste malevole su HTTP);
• per ogni filtro è associata una jail, che stabilisce quanti eventi sono tollerati in un certo intervallo di tempo e quale azione intraprendere (bloccare l’IP con iptables, aggiornare UFW, loggare, ecc.);
• quando un IP supera i limiti impostati, fail2ban genera automaticamente una regola firewall che lo blocca per un periodo predefinito (ban temporaneo) o permanente.

In questo modo UFW fornisce il perimetro statico (quali porte sono aperte e verso chi), mentre fail2ban aggiunge un layer dinamico che reagisce al comportamento degli indirizzi sorgente:
non ci si limita a “vedere” i tentativi di brute force nei log, ma li si trasformano in trigger per attivare contromisure automatiche in tempo reale.

Come difendersi: best practice per server esposti

Dopo aver visto cosa accade dentro un server, possiamo sintetizzare alcune buone pratiche concrete per chi gestisce infrastrutture Linux esposte su Internet, con un occhio sia alla divulgazione sia alla precisione tecnica.

1. Firewall: policy chiare e porte essenziali

Un firewall mal configurato è quasi peggio di un firewall assente: dà l’illusione di protezione senza offrire una barriera coerente.
Alcune regole di base:

• impostare una policy di default deny in e aprire esplicitamente solo le porte strettamente necessarie (80/443 per il web, porta per SSH, eventuali porte per mail e VPN);
• limitare l’accesso a servizi di backend (pannelli di amministrazione, database, API interne) a specifici IP o reti tramite regole firewall o VPN dedicata;
• scegliere un livello di logging adeguato: sufficiente per analizzare problemi e incidenti, ma non così elevato da rendere ingestibile il volume di log.

Cosa evitare assolutamente:

• lasciare aperte porte “temporanee” e dimenticarsene;
• esporre servizi legacy (Telnet, vecchi pannelli di gestione remota) che secondo Clusit sono ancora oggi tra i vettori di attacco più sfruttati a causa di configurazioni non aggiornate.

2. Hardening di SSH

La porta SSH non può essere trattata come un qualunque servizio: rappresenta il controllo completo del server.
Alcune misure minime:

• abilitare solo l’autenticazione tramite chiave pubblica e disabilitare completamente il login tramite password;
• disabilitare l’accesso diretto dell’utente root via SSH e utilizzare utenti non privilegiati con sudo controllato;
• limitare l’accesso SSH a indirizzi IP specifici (whitelist) o a connessioni provenienti da una VPN dedicata;
• configurare fail2ban per proteggere SSH non solo sui tentativi di login falliti, ma anche intercettando pattern come kex_exchange_identification anomali e banner non validi.

Da non fare:

• lasciare SSH accessibile sulla porta di default 22 con password deboli o riutilizzate;
• mantenere l’accesso diretto di root o utenti generici condivisi tra più persone, rendendo impossibile ricostruire “chi ha fatto cosa”.

3. Proteggere WordPress e il layer applicativo

Per molti studi professionali e PMI il vero “front end” è un CMS come WordPress, che a sua volta diventa un bersaglio privilegiato di attacchi automatizzati.
Alcune buone pratiche:

• mantenere aggiornati core, temi e plugin, rimuovendo ciò che non è più utilizzato per ridurre la superficie di attacco;
• proteggere gli endpoint sensibili (es. wp-login.php, wp-admin, admin-ajax.php) con rate limiting, CAPTCHA, IP filtering o un WAF (Web Application Firewall);
• limitare o filtrare l’uso di XML-RPC e API pubbliche se non strettamente necessarie, perché spesso vengono sfruttate per brute force distribuiti o DDoS applicativi;
• gestire bot aggressivi come Bytespider con regole in robots.txt e, se necessario, blocchi a livello di web server (Nginx/Apache) o WAF, soprattutto quando impattano su banda e risorse della macchina.

Da evitare:

• installare plugin “tuttofare” senza verificarne reputazione, aggiornamenti e compatibilità;
• lasciare account amministratore inutilizzati, con credenziali deboli o non protetti con autenticazione a più fattori.

4. Mail server e reputazione del dominio

Il server di posta è spesso il punto di contatto con il mondo esterno e, allo stesso tempo, uno degli strumenti più utilizzati dai criminali per campagne di spam e phishing.
Alcune cautele operative:

• verificare regolarmente che la coda di posta (queue) sia correttamente configurata e che le directory esistano con i permessi giusti, evitando errori come quelli mostrati nei log di Axigen;
• abilitare autenticazione forte per l’invio (submission) e limitare l’uso del server SMTP solo a client autorizzati;
• monitorare volumi e pattern di invio, e utilizzare fail2ban o strumenti simili per bloccare IP che generano molte autentiche fallite o transazioni sospette;
• configurare correttamente record DNS come SPF, DKIM e DMARC per proteggere la reputazione del dominio e ridurre spoofing e abusi.

Da non fare:

• esporre un server SMTP aperto verso Internet senza autenticazione o limiti di relay;
• ignorare per giorni errori ripetuti nei log del mail server, che possono indicare tentativi di abuso o configurazioni fragili.

5. Monitoraggio, backup e risposta agli incidenti

Nessuna misura isolata è sufficiente senza visibilità e capacità di risposta.
Alcuni elementi fondamentali:

• centralizzare e conservare i log principali (firewall, SSH, web server, MTA) e definire semplici alert: picchi improvvisi di UFW BLOCK, aumento dei tentativi falliti su SSH, spike di richieste a wp-login.php o admin-ajax.php;
• Mantenere backup regolari, cifrati e testati, con procedure di ripristino verificate periodicamente: in caso di ransomware o compromissione, il backup è l’ultima linea di difesa;
• preparare un minimo di piano di risposta agli incidenti (Incident Response Plan): chi interviene, come isolare un server compromesso, quali log salvare, chi informare (fornitore hosting, DPO, eventuali autorità);
• verificare periodicamente il funzionamento di fail2ban (stato delle jail, IP bannati, efficacia dei filtri) per evitare di scoprire troppo tardi che non sta più applicando blocchi.

Ciò che non bisognerebbe mai fare è affidarsi alla sola percezione: il fatto che “il sito risponde” non significa che il server sia al sicuro. Senza log leggibili, backup affidabili e una minima procedura di risposta, un piccolo incidente può trasformarsi rapidamente in una crisi prolungata.

In conclusione, i log di un server raccontano molto più di errori e warning: sono la cronaca quotidiana di una pressione costante esercitata da bot, criminali, hacktivisti e attori collegati a interessi geopolitici. Interpretarli correttamente e trasformarli in azioni concrete attraverso strumenti come UFW e fail2ban significa fare un passo decisivo dal semplice “avere un server online” al “gestire consapevolmente un’infrastruttura critica”.