Performance & Security

Ciao Luca,

grazie per aver condiviso, casi così aiutano tutta la community a stare in guardia.

Quello che descrivi è un pattern classico di compromissione: l'attaccante è entrato, ha caricato i suoi script malevoli (probabilmente backdoor o webshell) e poi ha seminato quei .htaccess in ogni cartella per bloccare l'esecuzione di altri file .php che non siano i suoi — così nessun altro malware "concorrente" gira sul tuo spazio e, di fatto, ti blocca anche l'accesso all'admin. È un comportamento tipico di alcune famiglie di malware PHP.

Un paio di cose al volo prima di tutto il resto: non ti limitare a pulire. Se non chiudi la falla e non rimuovi le backdoor, in 24-48 ore ti ritrovi punto a capo. Quindi l'ordine giusto è: contenere, capire, pulire, blindare.

1. Trova tutti i file .htaccess malevoli
Via SSH (se ce l'hai) il modo più veloce per individuarli è cercare quelli che contengono quella stringa:

grep -rl "suspected" /percorso/del/sito --include=".htaccess"

e per i file PHP sospetti caricati di recente, controlla quelli modificati negli ultimi giorni:

find /percorso/del/sito -name "*.php" -mtime -7 -ls

Incrocia le date: capirai il giorno dell'intrusione e potrai poi cercare nei log di accesso cosa è successo in quelle ore.

2. Capire da dove sono entrati
I log sono la chiave. Guarda gli access log del webserver intorno alla data dei file modificati, cercando POST sospette verso file strani o verso componenti noti per vulnerabilità. Le porte d'ingresso più comuni in Joomla sono: estensioni di terze parti non aggiornate (è quasi sempre questo), un core vecchio, oppure credenziali deboli/rubate. Controlla che core ed estensioni siano tutti all'ultima versione.

3. La pulizia
Qui serve onestà: su un sito compromesso davvero pulito al 100% lo sei solo quando ripristini un backup sano precedente all'intrusione, e poi ci applichi sopra gli aggiornamenti. Cancellare i file uno per uno è rischioso perché una sola backdoor dimenticata vanifica tutto. Se hai un backup di prima del problema, è la strada più sicura.

4. Dopo la bonifica
Cambia tutte le password (Joomla admin, database, FTP/SSH, pannello hosting), rigenera il Secret in configuration.php, e valuta un componente come Admin Tools (Akeeba) che blinda l'.htaccess, mette in sicurezza l'admin e fa da firewall applicativo.

Una nota da chi sta dall'altra parte: questo è esattamente il tipo di situazione in cui, se fossi su Host.it, avresti potuto aprire un ticket e i nostri tecnici avrebbero potuto incrociare i log a livello server, isolare il punto d'ingresso e darti una mano nel ripristino — cose che da soli, senza accesso completo alla macchina, diventano molto più faticose.

Tienici aggiornati su cosa trovi nei log, sono curioso di sapere quale estensione (perché scommetto su un'estensione) ha aperto la porta. Magari salviamo qualche altro sito.

Hai fatto la mossa giusta. Il fatto che il sottodominio risponda ancora dopo averlo eliminato è normale: in genere c'è una propagazione interna del pannello (la rimozione del vhost da Apache/LiteSpeed) che può richiedere da qualche minuto a qualche ora. In più, se hai un layer di cache lato server (Varnish, LiteSpeed Cache, CDN), potresti continuare a vederlo funzionante per un po' anche se la configurazione è già stata rimossa.
Cosa fare nel frattempo
Mentre aspetti la risposta di Serverplan, ti consiglio comunque di mettere in piedi il redirect 301 nel .htaccess. Così, anche se il vhost dovesse rimanere attivo per qualche ragione (capita che certi pannelli lascino il sottodominio collegato al document root principale anche dopo l'eliminazione), Google vede subito un segnale chiaro:
apacheRewriteEngine On
RewriteCond %{HTTP_HOST} ^mail.lhmstudio.it$ [NC]
RewriteRule ^(.*)$ https://www.lhmstudio.it/$1 [L,R=301]
Mettilo all'inizio del file .htaccess, subito dopo RewriteEngine On se già c'è. Non interferisce con il resto delle regole di Joomla.
Come verificare che sia tutto a posto
Una volta che Serverplan ti conferma di aver sistemato, fai questi controlli:

Da terminale (o da un servizio online tipo httpstatus.io😞

curl -I https://mail.lhmstudio.it

Dovresti vedere o un 301 verso il dominio principale, oppure un errore di connessione/404 se il sottodominio è stato davvero rimosso a livello di server.

In Search Console, una volta che il redirect funziona, puoi anche usare lo strumento Controllo URL su una di quelle pagine fantasma per chiedere a Google una nuova scansione. Vedrà il 301 e nel giro di qualche settimana le rimuoverà dall'indice.

Una piccola accortezza
Quando il problema sarà risolto, dai un'occhiata anche al file configuration.php di Joomla e verifica il parametro $live_site. Se è vuoto (come dovrebbe essere nella maggior parte dei casi), va bene. Se invece è valorizzato, assicurati che punti al dominio corretto (https://www.lhmstudio.it) e non a qualcosa di generico. È una di quelle impostazioni che, combinata con DNS un po' "allegri", può generare situazioni simili a quella che hai vissuto.
Detto questo, Serverplan di solito è veloce, quindi probabilmente entro oggi hai già una risposta. Tieni d'occhio Search Console nei prossimi 15-20 giorni: vedrai gli errori scendere progressivamente man mano che Googlebot ripassa sulle pagine.
Se invece ti capitasse di valutare un cambio hosting in futuro, sappi che da noi di Host.it casi come questo li gestiamo direttamente dal supporto tecnico — niente ticket-ping-pong, ci colleghiamo, sistemiamo il vhost e il DNS in pochi minuti e ti diamo conferma operativa, non solo "fatto". Ma a giudicare da come stai gestendo la cosa, sei già sulla strada giusta.

Facci sapere come va con Serverplan!

@mangi-1 Ciao Marco ho installato il plugin, queste le performance dopo che l'ho installato.
Attenzione ad Admin Tool, se attivi cache pagina statica bisogna permettere l'accesso alla directory cache/fastcache/page altrimenti va in 403

18393810-125a-48ce-b392-8d59784cc371-image.png

14736d2e-0ca8-4946-93c4-a7842ae25af0-image.png

53b67a5d-c05c-474c-a6d5-72711f47ef7b-image.png

@AnnaEsse, come ti hanno giustamente suggerito, devi ripartire dalla versione funzionannte.
L'aggiornamento a una major version va fatto senza fretta, altrimenti lo si rimanda e ci si ritorna quando si ha più tempo.

Riparti dalla 4.4.14 Aggiorna tutte le estensioni che usi all'ultima versione. Fai backup Avvia l'aggiornamento alla 5.4.2 Tieni traccia di tutti gli eventuali warning sulle estensione che ti fornisce il pre-check di Joomla Verifica effettivameante sul sito degli sviluppatori delle estensioni segnalate, che non siano compatibili con Joomla 5 (il pre-check può restitutire falsi positivi). Quando hai verificato che tutto sia ok, conferma l'update di Joomla.

Mi sembra di aver letto che non ti ritrovi delle modifiche fatte al template Cassiopeia.
Sono modifiche fatte sui file del template (1) o nella configurazione dello stesso (2)?

Nel primo caso (1), le modifiche le perdi se hai editato direttamente i file di template senza fare override (o utilizzare i child template). Se ti ricordi le modifiche apportate, copiatele in un file a parte che poi vediamo di riportarle post update.

Nel secondo caso (2), segnati le modifiche, fatti degli screenshots della configurazione, che replicherai sulla nuova versione di Cassiopeia.

@pstrada ha detto in Gestione headers:

sistema header http

si si, lo so, ma non basta, bisogna aggiungere delle istruzioni anche nel .htaccess, il problema e che questo CSP e molto delicato per la gestione delle risorse. Avevo sentito che ci sta qualche extra plugin per questo ma vorrei evitare l'installazione di altre cose se possibile.

Quelli di akeeba sono in un formato compresso, dovrebbero essere buoni.
È consigliato tenere i backup in uno spazio al di fuori del server per i motivi di cui sopra.

Ok. Grazie

@jabba Chiaro, quindi con quel tipo di task posso, ad esempio, richiamare una pagina con una chiave segreta (magari quella creata con Cache Cleaner di Regular Labs) per cancellare la cache creata (e questo evita l'acquisto della versione a pagamento 🙂 )
Grazie quel video mi era sfuggito. Top!

se non ti serve disattiva il debug

Ciao, la prima cosa da tenere in considerazione è che le prestazioni sono influenzate moltissimo dal template che usi. Se il template installato è ottimizzato e scritto come si deve è intrinsecamente molto più leggero e prestante, se invece carica librerie iniutili, non utilizza best practice di programmazione ecc.. il tuo sito sarà molto più lento anche a parità di Joomla che ci sta sotto.

Detto questo: Joomla di per se è molto veloce. Un sito fatto con Cassiopeia non ha assolutamente bisogno di estensini tipo JCH. Per esperienza non ce n'è bisogno neanche su un sito fatto con Yootheme. Se il tuo sito usa un template molto pesante invece può avere senso, anche solo per minimizzare/ottimizzare il codice o usare features come il lazy load.

In generale se tra attivo e non attivo le differenze sono minime penso non valga la pena tenere un plugin (anche abbastanza invasivo) come JCH per pochi punti percentuali che non fanno veramente la differenza.

Valuta anche sistemi di cache lato server tipo Litespeed, aiutano senza essere troppo invasivi sul codice del sito.

Ciao!

Se attivi il plugin ls cache è consigliato di disattivare tutte le altre modalità di cache e gzip, proprio per evitare conflitti. Poi ovviamente puoi provare e vedere se ne trai ulteriore beneficio

un video spunto/idea per i più smanettoni https://youtu.be/xznKffSjXsA?si=8dT0oa_WaoeZGkl-

Jabba grazie mille, intanto ho imparato una cosa nuova, che si può forzare dalla dashboard. Paradossalmente, dopo svariati giorni, adesso vedo tutti sicuri... Misteri del web
Cmq tengo sotto controllo e farò tesoro della dritta, all'evenienza.
Grazie di nuovo. Informazione preziosa.

@pstrada io prima su tutti quelli che provavo ita e non. Da quando hanno risolto non ho più problemi