Settimana dei log: chi ha violato il mio sito Joomla e come

Dati reali degli access.log in due giorni — 1.199 richieste, 279 IP unici e decine di bot di attacco.

Ogni giorno il tuo sito elabora centinaia di richieste. Una parte sono bot dei motori di ricerca, una parte sono visitatori reali. Ma c'è una terza categoria: scanner automatizzati e bot exploit che metodicamente verificano il tuo sito alla ricerca di vulnerabilità. Ho deciso di esplorare i log di accesso del mio sito e analizzare chi esattamente tenta di ottenere accesso e come. Spoiler: il quadro non è dei più rassicuranti.

Periodo di analisi: 27–28 agosto 2026. Il sito gira su Joomla 6, il server è protetto da un .htaccess di base (blocco dei percorsi WP, file nascosti, POST senza referrer). In precedenza è stato bloccato il bot BitSight (USA) — maggiori dettagli abaixo.

Il quadro generale

In due giorni — 1.199 richieste da 279 IP unici. Di questi:

• ~100 richieste — bot legittimi dei motori di ricerca (Yandex, Google, Bing, ClaudeBot)
• ~260 richieste — io stesso (pannello admin, modifica contenuti)
• ~840 richieste — tutto il resto: scanner, bot, spazzatura

La maggior parte degli attaccanti riceve un 403 (blocco htaccess) o un 404 (file non trovato). Nessun attacco è riuscito — ma questo non significa che si possa rilassarsi.

Tipo di attacco #1: Ricerca di backup e archivi

IP: 94.154.35.236
Richieste: 35 in due giorni
Metodo: HEAD (verifica la presenza del file senza scaricarlo)

Il visitatore più ostinato. A intervalli di circa un'ora, questo bot invia richieste HEAD a file come /backup.xz, /archive.xz, /krim-web.ru.xz, /bitrix/backup.xz, /administrator.xz, /wp.xz, /joomla.xz e così via. Un dizionario di diverse decine di parole.

Obiettivo: trovare un archivio del sito o del database lasciato per sbaglio sul server. Se tale file esiste, il bot lo scaricherà e l'intero contenuto del sito finirà nelle mani dell'attaccante.

Risultato: 35 volte ha ricevuto un 403 — il .htaccess blocca le richieste ai file .xz. Il bot continua a tornare.

Come proteggersi: bloccare le richieste agli archivi (.xz, .tar, .gz, .zip, .sql, .bak) tramite .htaccess. Verificare che non ci siano backup dimenticati nelle directory pubbliche del server.

Tipo di attacco #2: RCE tramite SP Page Builder

IP: 176.234.229.85 e 103.59.161.106
Richieste: 16 + 19 = 35
Metodo: POST

Questa è la categoria più pericolosa. Entrambi i bot utilizzano lo stesso exploit con User-Agent sppb-rce-poc — letteralmente "Proof of Concept per RCE in SP Page Builder." RCE (Remote Code Execution) significa l'esecuzione di codice arbitrario sul tuo server.

L'attacco mira all'endpoint /index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon. Se il componente SP Page Builder ha una versione vulnerabile, tramite questa richiesta è possibile caricare una PHP shell sul server e ottenere il controllo totale.

Un bot (176.234.229.85) ha inviato 16 richieste POST con diversi payload in 2 secondi. Il secondo (103.59.161.106) — 19 richieste in 4 secondi. Questo è un fuzzing automatizzato: tentativi sistematici di varianti dell'exploit.

Risultato: 404 — il componente SP Page Builder non è installato sul sito, l'endpoint non esiste. Ma se lo fosse stato — le conseguenze sarebbero potute essere catastrofiche.

Come proteggersi: aggiornare SP Page Builder all'ultima versione. Rimuovere le estensioni inutilizzate. Utilizzare un WAF o un plugin di protezione dell'admin.

Tipo di attacco #3: Scansione JCE

IP: 176.234.229.85, 86.104.22.88, 107.174.33.101
Richieste: 3–4 da ogni IP

Diversi bot verificano la presenza di file dell'editor JCE:

• /plugins/editors/jce/jce.xml — configurazione dell'editor
• /administrator/components/com_jce/jce.xml — configurazione del componente
• /plugins/system/jcemediabox/js/jcemediabox.js
• /plugins/system/jce/css/content.css

JCE è un editor popolare per Joomla. La sua storia include diverse vulnerabilità critiche (specialmente nelle versioni precedenti alla 2.8.x). Tramite la presenza del file jce.xml, il bot determina se JCE è installato e, in caso affermativo, applica l'exploit corrispondente.

Un bot (107.174.33.101), dopo aver verificato JCE, ha immediatamente inviato una richiesta POST a /index.php?option=com_jce — un tentativo di sfruttamento diretto.

Come proteggersi: aggiornare JCE all'ultima versione. Se non lo si utilizza — rimuoverlo completamente, non semplicemente disabilitarlo.

Tipo di attacco #4: Backdoor dei bot Telegram

IP: 107.174.33.101
Richiesta: GET /tmp/tg_xiga857_59d1735a843dc59e7b075f12d96b3311.xml.php

La richiesta più allarmante dell'intero periodo di osservazione. Il bot è arrivato sulla homepage (200), immediatamente seguito da un POST a com_jce (404), e poi ha cercato un file con nome tg_ + hash + .xml.php nella directory /tmp/.

Questo non è semplice scanning. È la ricerca di una backdoor già installata. Se il tuo sito è già stato compromesso (tramite una vecchia vulnerabilità JCE, SP Page Builder o altro) — gli attaccanti lasciano un file PHP mascherato da XML in /tmp/, che permette di controllare il server tramite un bot Telegram. Una tale backdoor può esistere per mesi senza essere rilevata.

Come verificare:

• find /tmp -name "*.php" -o -name "*.xml.php"
• Controllare uploads/, images/, media/ per file PHP sospetti
• Verificare gli hash dei file core di Joomla con quelli ufficiali

Tipo di attacco #5: Scanner WordPress

IP: 134.199.175.172
Richieste: 13
Pattern: /wp/wp-admin/install.php, /blog/wp-admin/install.php, /shop/wp-admin/install.php...

Il bot prova 13 percorsi comuni di installazione di WordPress: /wp/, /blog/, /shop/, /old/, /new/, /cms/, /backup/ e così via. Se trova un'installazione WP incompleta, può creare un account amministratore.

Un altro bot (89.163.146.197) ha cercato il file txets.php — con un errore di battitura nell'User-Agent (Mozlila invece di Mozilla). Appassionati del copia-incolla.

Come proteggersi: assicurarsi che nella root del sito non ci siano file non relativi a Joomla. Un 404 è normale, ma è meglio non dare ai bot alcun motivo per tornare.

Tipo di attacco #6: Path-traversal e ricerca di configurazioni

IP: 45.38.18.22 (path-traversal) e 103.77.106.45 (configurazione SFTP)

Path-traversal (45.38.18.22): il bot prova percorsi annidati come /images/images/images/images/cache.php — se sul server c'è un percorso mal configurato, può uscire dai limiti della DocumentRoot.

Scanner SFTP (103.77.106.45): cerca i file /sftp-config.json e /.vscode/sftp.json. Se uno sviluppatore lavora tramite VS Code con il plugin SFTP e ha inavvertitamente committato la configurazione, un attaccante ottiene l'accesso al server FTP/SFTP.

Come proteggersi: verificare il .gitignore, il .htaccess (bloccare .vscode/, .env, sftp-config.json), assicurarsi che il path-traversal non funzioni sul server.

Tipo di attacco #7: Scanner MCP (nuovo)

IP: 2a10:3c0:100:0:1:1:0:5 (IPv6)
UA: python-httpx/0.28.1

Una tendenza recente — scanner che cercano server MCP aperti (Model Context Protocol). Richieste: POST /mcp e GET /sse. Se sul server è in esecuzione un MCP, il bot tenterà di eseguire azioni tramite di esso.

Come proteggersi: se non si utilizza MCP — bloccare gli endpoint corrispondenti tramite .htaccess.

Chi non attacca?

Non tutti i bot sono cattivi. I bot utili in due giorni:

Questi bot sono utili (o almeno innocui). Non c'è bisogno di bloccarli.

E BitSight?

Nella sessione precedente, ho bloccato il bot BitSight (USA) tramite .htaccess — metodicamente provava percorsi dizionario e bombardava i log. Risultato: per il 27–28 agosto — zero richieste da BitSight. Il blocco ha funzionato perfettamente, il bot se n'è andato e non è tornato.

Tabella riepilogativa degli IP bloccati

Conclusioni principali

1. I bot non dormono mai. In due giorni, oltre 10 attaccanti diversi con vettori differenti hanno colpito un sito con traffico moderato. Questa è la norma, non l'eccezione.
2. L'attacco più pericoloso è l'RCE tramite SP Page Builder. Se il componente fosse stato installato con una versione obsoleta, il sito sarebbe stato compromesso in pochi secondi.
3. La ricerca di backdoor in /tmp/ è un segnale che gli attaccanti contano su siti già compromessi. Controlla il tuo server.
4. Un .htaccess di base blocca ~80% del rumore. Bloccare i percorsi WP, i file nascosti e gli archivi riduce significativamente il carico e il rumore nei log.
5. Il blocco per IP funziona, ma è un gioco del moles. Meglio chiudere i vettori di attacco piuttosto che IP specifici.

Cosa puoi fare subito

Checklist minimo di sicurezza per un sito Joomla:

• Rimuovere i componenti inutilizzati (SP Page Builder, JCE se non necessari)
• Aggiornare tutto ciò che è installato alle ultime versioni
• Controllare /tmp/ e uploads/ per file PHP sospetti
• Configurare .htaccess (bloccare archivi, file nascosti, percorsi WP)
• Proteggere il pannello di amministrazione — chiudere l'admin con una chiave segreta in modo che i bot non possano nemmeno raggiungere i moduli di accesso

È proprio per quest'ultimo punto che ho creato il plugin Safe Admin Pro. Aggiunge una chiave segreta all'URL del pannello admin — senza la chiave corretta, l'accesso a /administrator è impossibile, e i tentativi vengono registrati con rilevamento del paese e autoban. Nessun bot vedrà il modulo di accesso, potrà forzare le password o sfruttare vulnerabilità a livello di amministrazione.

Nei log sopra si vede: i bot bussano a /administrator/components/, cercano JCE, provano com_jce — tutto questo avviene all'interno dell'area admin. Se il pannello admin è chiuso con chiave — non sapranno nemmeno cosa c'è lì dentro.