Nell’ultima settimana il nostro sistema di monitoraggio della sicurezza ha registrato centinaia di tentativi di accesso al nostro sito. Il numero suona allarmante, ma la realtà è molto più tranquilla, e questo articolo spiega perché.
Non ci sono stati attacchi reali. Tutti i 616 eventi di sicurezza esterni registrati dal 7 al 15 luglio si sono rivelati rumore generato da bot automatici: scanner che controllano in massa migliaia di siti alla ricerca di vulnerabilità note di WordPress. Il nostro sito non è costruito su WordPress, quindi i percorsi cercati non sono mai esistiti e ogni tentativo si è concluso con un blocco o con un errore 404.
I numeri
Cosa cercavano esattamente e perché è pericoloso per un sito non protetto
I percorsi qui sotto sono bersagli classici di WordPress. Nel nostro caso erano innocui, perché questi file semplicemente non esistono, ma vale la pena capire perché proprio questi percorsi vengono cercati.
/wp-login.php – 273 richieste, 197 IP unici È il modulo di accesso all’amministrazione di WordPress. I bot tentano attacchi a forza bruta (brute force): provano automaticamente migliaia di combinazioni di nomi utente e password, sperando di indovinare un accesso valido. Se il sito ha password deboli o non limita i tentativi di accesso, un attacco del genere può finire con il pieno accesso come amministratore.
/xmlrpc.php – 255 richieste, 183 IP unici Un vecchio file di interfaccia di WordPress usato per la pubblicazione da remoto. È un bersaglio molto popolare per due motivi: può essere usato per indovinare le password molto più velocemente del normale modulo di accesso (centinaia di combinazioni in una sola richiesta) e può essere sfruttato in modo malevolo in attacchi DDoS di amplificazione contro terzi tramite la funzione “pingback”.
/en/wp-json/wp/v2/users/me – 23 richieste, 21 IP unici Un endpoint della REST API di WordPress che, per impostazione predefinita, può rivelare nomi utente validi. Di per sé non è un attacco, ma è un passo di ricognizione: scoprendo nomi utente reali, l’attaccante può indirizzare in modo più mirato i successivi tentativi di forza bruta.
/.env – 14 richieste, 12 IP unici Questo è l’unico bersaglio del nostro elenco con un reale potenziale di danno. I file .env di solito contengono password dei database, chiavi API e altri segreti. Se un file del genere è accessibile dall’esterno (a causa di una configurazione errata del server), la fuga del suo contenuto può significare la compromissione totale del sistema, non solo del sito ma anche dei servizi collegati. Nel nostro caso Next.js non serve questo file pubblicamente, quindi tutti i tentativi si sono conclusi con un 404 o con un blocco.
/lv/wp-content/uploads – 7 richieste, 7 IP unici La cartella degli upload di WordPress. Se è configurata in modo errato (ad esempio permette l’esecuzione di file PHP), un attaccante che ha già ottenuto anche solo un accesso minimo può caricare uno script malevolo e ottenere il pieno controllo del server.
Come funziona il nostro monitoraggio della sicurezza
Questi dati non provengono dai normali log del server: vengono analizzati dal sistema di sicurezza basato su AI sviluppato da noi, che segue tutto il traffico in entrata, classifica ogni evento in base alla gravità e decide in tempo reale se bloccarlo. Il sistema è collegato a un canale di notifiche Discord, dove due volte al giorno viene pubblicato un report riassuntivo: quanti eventi ci sono stati, quanti bloccati e se c’è qualcosa a cui prestare attenzione.
Oltre ai report periodici, il sistema dispone anche del cosiddetto meccanismo di page call – una notifica diretta e urgente al team di sviluppo che salta il riepilogo abituale due volte al giorno e avvisa subito, non appena accade qualcosa che richiede una reazione immediata. A differenza del consueto registro del rumore (dove centinaia di richieste dei bot vengono semplicemente registrate e bloccate in silenzio), la page call è riservata a casi rari e davvero importanti.
In pratica, una page call si presenta così: sul telefono arriva una chiamata diretta e urgente che informa dell’accaduto. Questa chiamata non si può rimandare (snooze): per fermarla bisogna alzarsi e collegarsi al sistema. Non appena un membro del team si è collegato, la page call viene disattivata e il sistema mostra chi esattamente ha preso in carico la gestione dell’incidente. Quando il problema è risolto, prima del rilascio il sistema controlla automaticamente codice, errori e vulnerabilità: prima che arrivi nel nostro repository GitHub privato, poi sul server e infine sul sito online (live), per assicurarsi che ovunque ci sia una versione coerente e corretta.
Nell’ultimo periodo questo meccanismo è scattato due volte:
- Tentativo di accesso al file
.env– poiché questo file può contenere password dei database e chiavi API, il sistema lo ha classificato come evento ad alto rischio e ha avvisato immediatamente il team, nonostante la richiesta fosse stata bloccata automaticamente. - gramatika.evoex.eu non raggiungibile – quando il sito di questo sottodominio è diventato irraggiungibile, il sistema lo ha riconosciuto come un’interruzione del servizio (e non come un incidente di sicurezza) e ha avvisato subito il team, così da poter reagire rapidamente e ripristinare il servizio.
Questo approccio a due livelli – registrazione silenziosa per il rumore di fondo dei bot di massa, ma notifica immediata nei rari casi davvero importanti – permette al team di sviluppo di non concentrarsi su centinaia di tentativi di scansione innocui, senza però correre il rischio che un evento realmente critico passi inosservato fino al successivo report programmato.
Origine
La maggior parte del traffico proveniva da USA (157), Francia (52), Regno Unito (48), Vietnam (46), Germania (39), Singapore (36) e India (32). Le stringhe User-Agent erano falsificate per sembrare normali browser – un segnale tipico di una botnet che cerca di passare per un visitatore reale.
La tendenza è nettamente in calo
Numero di eventi per giorno (dal 07-07 al 07-15): 148 → 137 → 75 → 61 → 110 → 41 → 38 → 13 → 1.
Il calo coincide con il blocco permanente di 95 indirizzi IP – la protezione funziona esattamente come previsto.
Conclusione
Nessun attacco riuscito, nessuna fuga di dati, nessun caso di spam nei form o di errore di autenticazione. Tutti i tentativi provenivano da scanner WordPress automatizzati che cercavano bersagli che qui non esistono. Questo non significa che la sicurezza sia superflua – al contrario, dimostra che un’architettura configurata correttamente, non basata su WordPress, e un blocco IP attivo respingono efficacemente anche gli attacchi automatizzati di massa, prima che possano raggiungere qualcosa di prezioso.