Sicurezza del sito web: come i siti vengono hackerati e come fermarlo

Perché anche i siti piccoli vengono attaccati

Iniziamo con la convinzione che sentiamo in quasi ogni primo incontro: "Chi si preoccuperebbe di noi? Abbiamo cinque pagine e riceviamo tre richieste a settimana." Sembra ragionevole. È anche esattamente il motivo per cui siti del genere vengono compromessi più spesso.

Nessuno ti ha scelto. La stragrande maggioranza degli attacchi contro le piccole e medie imprese non è affatto personale. Il software fa il lavoro: prende elenchi di domini e indirizzi IP, li esamina uno per uno e testa ciascuno per decine di vulnerabilità note. Il bot non ha idea se sei una clinica dentale o uno studio di ceramica. Legge una stringa di versione nella risposta del server, controlla la sua lista e passa oltre se non c'è corrispondenza. Se c'è una corrispondenza, inizia a lavorare.

È l'equivalente di camminare lungo una strada tirando le maniglie delle porte delle auto. Nessuno ha scelto la tua auto. La tua era semplicemente sbloccata.

Quanto vale davvero un sito vetrina

Un attaccante quasi mai vuole ferire te specificamente. Un sito compromesso ha un valore di mercato, e proviene da diverse cose contemporaneamente:

• Equità dei link. Link nascosti o intere sezioni nascoste su casinò, prestiti o farmacie vengono silenziosamente iniettati nelle tue pagine. Tu non li vedi. I motori di ricerca sì.
• Traffico.I tuoi visitatori vengono reindirizzati altrove, ma non tutti. Spesso solo gli utenti mobili, solo quelli che arrivano da una ricerca e solo una volta al giorno per persona. È proprio per questo che puoi visitare il tuo stesso sito dal tuo laptop per mesi e non notare nulla.
• Risorse del server.Il tuo hosting diventa un nodo per inviare spam, fare mining o attaccare altri siti.
• Dati.Un database di richieste, numeri di telefono, indirizzi ed email è un prodotto con acquirenti. Anche se tutto ciò che hai è "solo un modulo di contatto".
• Estorsione.I file vengono crittografati o eliminati e ti viene chiesto di pagare per il loro ritorno.

Questo porta alla conclusione che cambia come ci si sente riguardo a tutto questo argomento: la sicurezza del sito web non riguarda la difesa contro un genio con un cappuccio. È igiene che ti sposta fuori dalla piscina degli obiettivi facili. Un bot non spenderà tempo su un sito ben curato mentre mille trascurati stanno accanto.

Come i proprietari di solito scoprono

I sintomi quasi mai provengono da te. Il tuo host invia email riguardo attività sospette. Google Search Console segnala un avviso. Un cliente chiama per dire che il suo browser sta urlando. L'email aziendale finisce improvvisamente nella cartella spam di tutti. Il traffico di ricerca diminuisce senza spiegazione. Se qualcosa di tutto ciò è successo, lo hai scoperto tardi — ma tardi non è lo stesso che troppo tardi.

Come i siti vengono effettivamente compromessi

Dimentica i film. In realtà, quasi ogni compromesso di piccole imprese risale a un elenco breve e straordinariamente noioso. Abbiamo ripulito dozzine di siti infetti, e il punto di ingresso era quasi sempre uno di questi.

CMS obsoleti e plugin soprattutto

Questo è il vincitore indiscusso. WordPress, Joomla, OpenCart — le piattaforme stesse non sono intrinsecamente vulnerabili. L'ecosistema è il problema: un plugin galleria aggiornato l'ultima volta nel 2021, un tema acquistato su un marketplace il cui autore è andato avanti anni fa, un modulo di contatto installato da un appaltatore e dimenticato.

Comprendi i meccanismi qui, perché sono controintuitivi. Quando viene trovata una vulnerabilità in un plugin, viene pubblicata. È così che funziona l'industria, ed è corretto. Ma da quel momento inizia una corsa: lo sviluppatore invia una correzione, e i bot di scansione ricevono l'impronta della versione vulnerabile entro poche ore. Un sito che si aggiorna una volta all'anno non è affatto in quella corsa.

Password deboli e, ancor peggio, riutilizzate

Una password come Admin2024! sembra forte — lettera maiuscola, cifre, un punto esclamativo. È in ogni dizionario di cracking. Ma non è questo il vero danno. Il vero danno è la stessa password sul tuo pannello di hosting, sul tuo admin del sito, sulla tua email e su qualche servizio che è stato violato due anni fa. La fuga di qualcun altro diventa il tuo accesso, e tecnicamente non avviene affatto "hacking". L'attaccante semplicemente digita un nome utente e una password.

Credenziali rubate da un laptop dello staff

Il classico che nessuno sospetta. Le credenziali FTP salvate in un file manager sul laptop di un designer vengono lette da malware comune. Il sito viene "hackerato" attraverso un accesso legittimo. Il segnale rivelatore: pulisci tutto a fondo e l'infezione torna entro due giorni.

Moduli non protetti e endpoint aperti

Ogni luogo in cui il tuo sito accetta input dall'esterno — un modulo di contatto, la ricerca del sito, un caricamento di file, un endpoint API — è una porta. Quando l'input viene accettato senza controllarne il tipo, la dimensione e i contenuti, la porta funziona in entrambe le direzioni. Il caricamento di file merita una paura speciale: consentire a qualcuno di posizionare qualcosa sul tuo server che il server esegue successivamente è essenzialmente consegnare le chiavi.

File lasciati nel root del web

Il killer silenzioso, e lo troviamo costantemente. Vivendo nella cartella pubblica: backup.zip dell'agenzia precedente, dump.sql con l'intero database, un .git cartella contenente l'intera cronologia del progetto con password nei vecchi commit, un test.php, un info.php, una copia di configurazione chiamata config.php.bak. Ognuno di questi è scaricabile da chiunque indovini l'URL. E i bot non indovinano: portano elenchi dei nomi abituali e li controllano in pochi secondi.

Una parola specifica su .bak e .vecchio estensioni: il server non le esegue come codice, le serve come testo semplice. Significa che consegna la tua password del database direttamente al browser.

Progetti Dimenticati e Abbandonati

Una vecchia pagina di atterraggio di una campagna su un sottodominio. Una copia di staging costruita due anni fa e mai rimossa. Un forum che nessuno usa. Non vengono mai aggiornati perché nessuno ricorda che esistono. E di solito rimangono nello stesso account di hosting — quindi compromettere una pagina di atterraggio dimenticata consegna i file del tuo sito principale. Iniziamo ogni audit con "cosa altro vive in questo account?", e la risposta sorprende regolarmente il proprietario più di chiunque altro.

HTTPS e SSL: non è più un argomento di discussione

Se non hai HTTPS, smettila di leggere e risolvilo prima. Nel 2026, un sito senza crittografia non è economico. È un errore.

Cosa Fa Davvero un Certificato SSL

Senza HTTPS, i dati viaggiano tra il browser del tuo visitatore e il tuo server in testo semplice. Chiunque si trovi lungo quel percorso può leggerli e modificarli: il proprietario del Wi-Fi del caffè, un ISP, attrezzature su una rete intermedia. Leggerli significa leggere password e contenuti dei moduli. Modificarli significa che possono riscrivere la tua pagina o iniettare i propri annunci, e il tuo visitatore sarà certo che provengano da te.

Un certificato SSL risolve due problemi contemporaneamente. Crittografa il canale e prova che il dominio appartiene a chi lo sta servendo. Il secondo è importante quanto il primo: senza identità, la crittografia è inutile, perché potresti stare crittografando un canale verso un truffatore.

I Dettagli Che Contano Più del Certificato Stesso

I certificati sono ora gratuiti e automatici — Let's Encrypt ha risolto questa questione per tutti. Quindi gli errori non riguardano più "averne uno o meno". Sono nella configurazione:

• Reindirizzamenti.Ogni richiesta HTTP deve reindirizzare permanentemente a HTTPS. Altrimenti, la vecchia versione continua semplicemente a funzionare accanto a quella nuova.
• Contenuto misto.La pagina si carica su HTTPS ma carica un'immagine, un font o uno script su HTTP. Il browser si lamenta e il lucchetto scompare. I vecchi frammenti di analisi e i widget di terze parti sono i colpevoli abituali.
• Rinnovo automatico.I certificati hanno una vita breve e vengono rinnovati da un robot. Quando il robot si guasta, ne sentirai parlare dai clienti nel giorno peggiore possibile. Monitora la data di scadenza.
• URL canonici.Dopo essere passati a HTTPS, assicurati che ogni pagina abbia un indirizzo piuttosto che quattro variazioni con e senza www.

Cosa non fa HTTPS

Qui vive un pericoloso malinteso. Il lucchetto non significa che il sito sia sicuro. Significa esattamente una cosa: il canale verso il server è crittografato. Un sito compromesso pieno di codice malevolo funziona felicemente su HTTPS con il lucchetto intatto. Anche i siti di phishing hanno certificati — vengono rilasciati gratuitamente e automaticamente a chiunque. HTTPS è una fondazione, non un tetto.

Per i siti che gestiscono denaro, la soglia è molto più alta. La crittografia del canale è il biglietto d'ingresso; dopo ci sono la verifica della firma del webhook, le operazioni idempotenti e la rigorosa separazione degli accessi. Abbiamo esaminato quella macchina in dettaglio utilizzando il gateway di pagamento Payora, dove la sicurezza delle transazioni supera ogni altra caratteristica nella costruzione.

Intestazioni di Sicurezza: La Difesa Silenziosa Che Nessuno Attiva

Le intestazioni di sicurezza sono istruzioni che il tuo server invia al browser insieme alla pagina. Il punto è che i browser sono fiduciosi per impostazione predefinita: eseguiranno qualsiasi script trovino sulla tua pagina e visualizzeranno la tua pagina all'interno della finestra di qualcun altro se richiesto. Le intestazioni sono il modo in cui dici al browser: "non farlo con me."

La loro grande virtù è che sono gratuite, configurate una volta e applicate dal lato del visitatore senza caricare il tuo server. Il loro grande problema è che sono assenti per impostazione predefinita quasi ovunque.

Content-Security-Policy (CSP)

Il più potente e il più capriccioso. È una lista di autorizzazione: da dove questa pagina può caricare script, stili, immagini e font. Se un attaccante riesce a iniettare uno script estraneo nella tua pagina, il browser semplicemente rifiuta di eseguirlo, perché la fonte non è nella lista. Di fatto, CSP trasforma un compromesso riuscito in uno fallito.

Un avviso onesto: affrettare il CSP romperà il tuo sito. Il percorso giusto è prima la modalità solo report, raccogliere le violazioni e poi stringere. Su un sito con una dozzina di widget di terze parti, sono diversi giorni di lavoro, non dieci minuti.

Strict-Transport-Security (HSTS)

Dice al browser: questo dominio è solo HTTPS, ricordalo per un anno. Chiude il divario tra qualcuno che digita un indirizzo senza un prefisso e il reindirizzamento che scatta. Quel divario è esattamente dove avviene l'intercettazione. Abilitalo solo quando sei sicuro che HTTPS funzioni ovunque e in modo permanente: invertire la decisione è lento.

X-Frame-Options

Impedisce che il tuo sito venga incorporato in un frame sulla pagina di qualcun altro. Difende contro un trucco semplice e sgradevole: uno strato invisibile posizionato sopra il tuo vero pulsante, in modo che il clic dell'utente vada da qualche parte che non intendeva. Per qualsiasi sito con un account cliente o un checkout, questo è obbligatorio.

X-Content-Type-Options

Una riga, nessuna configurazione. Vietando al browser di indovinare il tipo di un file rispetto a quanto dichiarato dal server. Senza di esso, un'immagine caricata può, nelle giuste condizioni, essere interpretata come uno script ed eseguita.

Referrer-Policy

Controlla quali informazioni sul tuo sito il browser trasmette quando un visitatore clicca altrove. Senza di essa, l'URL completo della pagina — inclusi parametri come un token di reset della password o un identificatore interno — viaggia nelle analisi di qualcun altro. Non è un hack. È una fuga: silenziosa e continua.

Permissions-Policy

Disattiva ciò di cui il tuo sito non ha chiaramente bisogno: fotocamera, microfono, geolocalizzazione, sensori. La regola è semplice: tutto ciò che non viene utilizzato dovrebbe essere spento.

Qualsiasi scanner pubblico online valuterà le tue intestazioni in un minuto, e il risultato è solitamente disarmante. Per noi, le intestazioni fanno parte della base di ogni progetto — parte dello sviluppo stesso, non un extra a pagamento aggiunto in seguito.

Aggiornamenti e Codice di Terze Parti: Disciplina Anziché Eroismi

Il consiglio è noioso: mantieni tutto aggiornato. Il problema è che è l'unico consiglio che tutti hanno sentito e quasi nessuno segue. Vediamo perché — e come farlo diventare una routine.

Perché gli Aggiornamenti Vengono Rimandati

Non pigrizia. Paura. Un aggiornamento ha una volta rovinato il layout, o il carrello ha smesso di funzionare, e il pulsante "aggiorna" è stato evitato da allora. La paura è razionale: gli aggiornamenti possono effettivamente rompere le cose, specialmente quando un sito è assemblato da plugin che sono stati modificati direttamente nel loro codice sorgente.

Ma fai i conti. Il rischio di un layout rotto ti costa un'ora. Il rischio di una compromissione ti costa un ripristino, una pulizia, conversazioni imbarazzanti con i clienti e mesi di recupero delle posizioni nei motori di ricerca. Il secondo rischio è di un ordine di grandezza più costoso.

Come Aggiornare Senza Panico

1. Fai un backup prima, non dopo.Backup completo: file e database. Non saltare mai questo passaggio, senza eccezioni.
2. Mantieni una copia di staging.Un ambiente separato, chiuso ai motori di ricerca e agli estranei, dove gli aggiornamenti vengono testati prima di andare online. In qualsiasi progetto serio, questo non è facoltativo.
3. Separa il critico dal routinario.Gli aggiornamenti di sicurezza vengono applicati immediatamente. Quelli minori seguono un programma. I salti di versione maggiori sono un progetto a sé stante con un piano.
4. Controlla le cose importanti dopo.Invia un modulo, esegui un pagamento, accedi a un account, guardalo su un telefono. Tre minuti di controllo manuale risparmiano settimane.

Audit del codice di altre persone

Una volta al trimestre, apri la tua lista di plugin e fai due domande. Prima: viene utilizzato? Un plugin installato "solo per precauzione" è un buco senza funzione. E nota che un plugin disattivato è ancora presente nel file system e può ancora essere vulnerabile — quindi le cose non utilizzate devono essere eliminate, non semplicemente spente.

Secondo: l'autore è vivo? Se l'ultimo aggiornamento risale a tre anni fa e la descrizione dice che è compatibile con una versione che è da tempo obsoleta, si tratta di codice abbandonato. Non diventerà più sicuro da solo. Trova un sostituto con calma, in anticipo, piuttosto che la notte dopo un compromesso.

E la regola da incorniciare sul muro: meno codice di terze parti sul tuo sito, minore sarà la tua superficie di attacco. Ogni plugin è uno sconosciuto a cui hai silenziosamente concesso accesso al tuo server.

Accesso e Igiene dell'Hosting: Vittorie Maggiori Rispetto al Codice

La causa più comune di un compromesso nel mondo reale non è un exploit astuto. È l'accesso disperso. Qui è anche dove l'ordine viene ripristinato più rapidamente e per quasi nessun costo.

Minimo Privilegio

Ogni persona e ogni processo dovrebbero avere esattamente i diritti richiesti dal loro lavoro e non un goccia di più. Un gestore di contenuti non ha bisogno di diritti da amministratore; ha bisogno di pubblicare articoli. Un collaboratore che modifica una pagina non ha bisogno del database. Uno script che legge un catalogo non ha bisogno di accesso in scrittura.

Apri subito la tua lista utenti amministratori. Negli audit troviamo regolarmente account attivi appartenenti a persone che se ne sono andate, un'agenzia con cui ti sei separato un anno fa, e un utente misterioso chiamato admin2 che nessuno può spiegare. Quest'ultimo non è una svista — è un sintomo.

Un Account Per Persona

Un condiviso adminl'accesso con la password presente in una chat significa che nessuno è responsabile. Quando succede qualcosa, il log dice "admin logged in", il che non ti dice nulla di preciso. Gli account individuali ti offrono due vantaggi: una cronologia leggibile di chi ha fatto cosa e la possibilità di revocare l'accesso a una persona senza cambiare le password per tutta l'azienda.

Autenticazione a Due Fattori

Se implementi esattamente un elemento di tutto questo articolo, fallo con questo. L'2FA rende una password rubata inutile. Ogni tentativo di forza bruta e ogni violazione di terze parti smettono di funzionare contro di te, perché la password da sola non è più sufficiente. Attivala ovunque esista: pannello di hosting, registrar di dominio, amministratore del sito, email, Cloudflare, GitHub.

Una parola speciale sul registrar di dominio. È il punto di fallimento più sottovalutato dell'intero stack. Perdere il controllo del tuo dominio è peggio che perdere il tuo sito: un sito si ripristina da un backup in un'ora, mentre un dominio torna dopo mesi di ticket di supporto — se torna.

Chiavi SSH invece di Password, e No FTP

Una password può essere indovinata o rubata da un laptop. Una chiave non può essere indovinata in un lasso di tempo utile. La configurazione richiede quindici minuti una sola volta, dopodiché l'accesso al server tramite password è completamente disabilitato.

Separatamente: abbandona il FTP semplice. Invia il tuo nome utente e la tua password in chiaro, come se fossimo nel 1998. Usa solo SFTP o SSH. Se il tuo host offre FTP come metodo principale, questo ti dice qualcosa sull'host.

Un Gestore di Password invece della Memoria

Nessun essere umano può ricordare quaranta password complesse e distinte, ed è esattamente per questo che le riutilizzano. Un gestore di password elimina completamente il problema: genera una password unica per ogni servizio, le memorizza in modo crittografato e ti consente di fornire le credenziali a un collega senza incollarle in un messenger. Costa poco e previene una catastrofe.

Moduli, Spam e Limitazione del Tasso

Il modulo di contatto è la parte più accessibile del tuo sito web. È aperto a tutti, funziona senza login e rimane lì in attesa di dati. Non c'è da meravigliarsi che subisca il maggior abuso.

Perché CAPTCHA non è la risposta

Il CAPTCHA cattura script primitivi e infastidisce i veri esseri umani. Il traffico spam moderno lo supera sia tecnicamente che attraverso servizi di risoluzione dove persone reali rispondono ai captcha per frazioni di centesimo. Nel frattempo, danneggia misurabilmente la conversione: alcuni clienti genuini semplicemente si arrendono di fronte alle lettere distorte e se ne vanno.

L'approccio che funziona è stratificato e invisibile per il visitatore:

• Honeypot.Un campo nascosto che un umano non vede né compila, e un bot compila automaticamente. Compilato significa scartato. Semplice, gratuito, efficace contro la maggior parte di esso.
• Controlli di tempistica.Un modulo inviato mezzo secondo dopo il caricamento della pagina non è stato compilato da una persona.
• Limitazione della frequenza.Non più di alcune sottomissioni da un indirizzo in una finestra data. Questo è il meccanismo chiave, e lo stesso protegge la tua pagina di accesso da tentativi di indovinare la password.
• Punteggio invisibile.I sistemi moderni valutano il comportamento e sfidano solo le richieste che sembrano sospette. Un vero cliente non vede nulla.

La validazione lato server è non negoziabile

Una validazione elegante dei campi nel browser è una comodità per gli utenti, non una difesa. I dati che arrivano al tuo server possono essere inviati senza mai toccare la tua pagina. Quindi tutto viene controllato di nuovo lato server: tipo, lunghezza, formato, valori consentiti. La regola è semplice e universale: l'input dal mondo esterno non è mai affidabile, anche se il tuo stesso script lo ha convalidato un momento fa.

I caricamenti di file sono un problema a sé stante

Se un visitatore può caricare un file, comportati come se stesse caricando qualcosa di ostile. Controlla il vero tipo di contenuto, non l'estensione nel nome. Rinomina il file tu stesso. Limita la dimensione. E, cosa più importante, memorizza i caricamenti in un luogo dove il server fisicamente non eseguirà codice — idealmente su un'archiviazione separata completamente.

Il limitamento della velocità va oltre i moduli

Lo stesso meccanismo appartiene ai tuoi endpoint API, alla ricerca del sito, al ripristino della password e a qualsiasi operazione costosa. Senza di esso, un bot persistente può mandare in crash il tuo server attraverso la pura ripetizione. È particolarmente importante quando ci sono soldi coinvolti: nei progetti di pagamento limitiamo sempre la velocità con cui possono essere create le transazioni — il nostro articolo sull'accettazione dei pagamenti in criptovaluta spiega perché questo protegge la tua contabilità tanto quanto il tuo server.

Backup: L'Unica Polizza Assicurativa Che Paga Sempre

In parole povere: i backup contano più di tutto il resto in questo articolo. Ogni altra misura riduce la probabilità di un disastro. I backup decidono come finisce il disastro — una serata sgradevole o un'attività chiusa.

La regola 3-2-1

Un classico inventato molto prima di noi e ancora imbattuto:

• 3 copie dei tuoi dati: quella attiva e due backup.
• 2 media o piattaforme diversi — non mettere tutte le uova in un solo paniere.
• 1 copia off-site, fisicamente e amministrativamente separata dal server.

Questo ultimo punto è dove la maggior parte delle configurazioni fallisce. Un backup che si trova sullo stesso server, o nello stesso account di hosting, non è un backup. Un attaccante che riesce ad entrare lo elimina per primo — è un passaggio standard, non un colpo di scena. Il ransomware lo cripta insieme a tutto il resto. E se l'host muore, muore anche lui.

Un Backup Non Testato Non È un Backup

Ecco la parte che fa male. Continuiamo a vedere la stessa scena: i backup sono stati eseguiti fedelmente per due anni, e nel giorno che conta gli archivi si rivelano corrotti. Oppure contengono file ma nessun database. O il database è presente, ma l'esportazione ha rovinato la codifica e il testo è fatto di punti interrogativi. Oppure l'archivio è di 40 kilobyte perché lo script è morto nella prima cartella e l'email di errore è andata in una casella di posta che nessuno legge.

La conclusione: i ripristini devono essere provati. Una volta a trimestre, distribuisci una copia in un ambiente di staging e controllala. Il sito si carica? Il database è presente? Le immagini sono presenti? Gli ordini appaiono? È l'unico modo per conoscere la verità sui tuoi backup in anticipo piuttosto che durante una catastrofe.

La conservazione batte la frequenza

Un backup giornaliero con tre giorni di retention è inutile contro un'infezione silenziosa. Il codice malevolo spesso rimane inattivo per mesi. Quando lo trovi, tutte e tre le copie sono già infette. Mantieni la profondità: giornaliero per due settimane, settimanale per un paio di mesi, mensile per un anno. Lo spazio su disco è incomparabilmente più economico di un sito senza nulla da ripristinare.

Cosa fare il backup

File e database sono ovvi. Ciò che viene dimenticato è tutto il resto: configurazione del server, regole del server web, lavori programmati, impostazioni DNS, email. Un buon indicatore è la domanda: "se la compagnia di hosting scomparisse domani, quanto tempo ci vorrebbe per una ricostruzione completa altrove?" Se non hai una risposta, il tuo backup è incompleto.

Monitoraggio e Log: Vedi Prima Tu del Tuo Cliente

I compromessi sono raramente rumorosi. Molto più spesso sono silenziosi, ed è proprio questo il punto: più a lungo non te ne accorgi, più a lungo l'asset guadagna denaro per chi lo ha preso. Quindi il compito del monitoraggio non è "catturare un hacker". È accorciare il divario tra l'evento e la tua consapevolezza.

Il set minimo

• Monitoraggio dell'uptime. Un controllo di disponibilità ogni minuto con un avviso. I servizi di base sono gratuiti e richiedono dieci minuti per essere configurati.
• Monitoraggio dell'integrità dei file. Il sistema registra lo stato dei tuoi file e ti avvisa quando qualcosa cambia. Nessuno ha toccato il codice, eppure due file sono cambiati alle 3 del mattino — questa è una conversazione.
• Scadenza SSL e dominio.Avvisi in anticipo, non dopo. Un rinnovo di dominio dimenticato fa più male di molti attacchi.
• Google Search Console.Gratuito e obbligatorio. I motori di ricerca spesso individuano un'infezione prima del proprietario e lo dicono chiaramente nella sezione sicurezza.
• Scansione malware esterna.Controlli regolari dall'esterno catturano ciò che solo un visitatore vede: reindirizzamenti, script iniettati, contenuti scambiati.

Log: Noioso, e Dove Risiede la Verità

I log del server web registrano ogni richiesta al tuo sito. In una giornata tranquilla, nessuno li vuole. Nel giorno di un incidente, sono la tua unica fonte di fatti: quando, da dove, cosa è stato richiesto esattamente e cosa ha risposto il server.

Due cose valgono la pena di essere fatte in anticipo, perché non possono essere fatte retroattivamente. Prima di tutto, conferma che i log vengano effettivamente scritti e conservati per almeno un mese. In molte configurazioni vengono troncati dopo 24 ore e non c'è nulla da investigare. In secondo luogo, abilita la registrazione del login admin — riuscito e fallito. Un picco nei fallimenti è un tentativo di indovinare la password in tempo reale, e puoi rispondere prima che abbia successo.

Cosa Cercare

Non è necessario essere un analista per notare l'ovvio. Richieste di file che non hai e non hai mai avuto. Richieste di amministrazione alle 3 del mattino da un paese in cui non assumi nessuno. Un indirizzo che fa centinaia di richieste in un minuto. Un aumento di risposte di errore dove prima non ce n'erano. Nessuno di questi è una prova da solo, ma ognuno è un motivo per guardare più da vicino.

Includiamo il monitoraggio di base in ogni progetto che supportiamo dopo il lancio — esempi di quel lavoro si trovano nel nostro portfolio. La lezione non è affascinante: un sito che nessuno guarda produrrà alla fine una sorpresa, e la sorpresa costa sempre più del monitoraggio.

WAF e CDN: Cosa Fa e Cosa Non Fa Cloudflare

Cloudflare e servizi simili sono uno strato genuinamente utile, ed è esattamente per questo che li circonda tanta mitologia. Siamo onesti su dove si trova il valore e dove inizia l'illusione.

Cosa Sono

Un CDN mette una rete di nodi in tutto il mondo tra il tuo visitatore e il tuo server. I file statici vengono serviti dal nodo più vicino — il sito è più veloce e il tuo server è alleggerito. Un WAF (firewall per applicazioni web) è un filtro che ispeziona le richieste in arrivo e scarta quelle a forma di attacco prima che raggiungano il tuo codice.

Il Vero Valore

• Assorbire DDoS.Il traffico spazzatura si infrange contro la rete del fornitore piuttosto che sul tuo server. Una piccola impresa non sopravvivrà a quell'attacco da sola.
• Nascondere il tuo vero IP del server.Gli attacchi diretti diventano più difficili quando il bersaglio non è visibile.
• Filtraggio dei bot.Una grande parte del rumore di scansione viene automaticamente eliminata, e i tuoi log diventano leggibili da un giorno all'altro.
• Patching virtuale.Una regola WAF può tenere chiusa una nuova vulnerabilità mentre prepari un aggiornamento adeguato. È tempo rubato, non una soluzione.
• Velocità.Un effetto collaterale piacevole che sia i visitatori che i motori di ricerca notano.

Cosa non faranno

Ora la parte scomoda. Un WAF non ti salverà quando:

• La tua password è stata rubata. Un accesso con credenziali valide è una richiesta legittima. Il filtro la passa, ed è giusto farlo.
• Il tuo IP reale è già conosciuto e il tuo server accetta connessioni direttamente, bypassando il filtro. Questa è una configurazione errata estremamente comune: il tuo server deve accettare traffico solo dalla rete del fornitore.
• Il difetto è nella tua logica aziendale. Se il tuo codice consente a un utente di recuperare l'ordine di un altro utente cambiando un numero, questa è una richiesta perfettamente formata per quanto riguarda il WAF.
• Il codice malevolo è già dentro. Il filtro osserva la porta d'ingresso, non ciò che sta accadendo dentro casa.
• La crittografia è impostata su "flessibile". Quindi il percorso da Cloudflare al tuo server viaggia in testo chiaro mentre il tuo visitatore vede un lucchetto e presume che tutto vada bene. Questa è un'imitazione pericolosa della sicurezza: utilizza la modalità rigorosa con la convalida del certificato.

In breve: un WAF e un CDN sono un'eccellente recinzione perimetrale. Una recinzione è inutile quando la chiave è sotto il tappeto e una finestra al piano terra è aperta. Completa l'igiene. Non la sostituisce.

Cosa Fare Se Sei Già Compromesso

Rimani calmo. Il panico costa più dell'hack stesso: in preda al panico le persone eliminano proprio le cose di cui un'indagine ha bisogno. La procedura è ben stabilita. Seguila.

1. Isola

Metti il sito dietro una pagina di manutenzione che restituisce uno stato 503. Questo protegge i visitatori dall'infezione e informa i motori di ricerca che l'interruzione è temporanea piuttosto che terminale. Non eliminare nulla per ora.

2. Preserva le Prove

Controintuitivo ma critico. Fai una copia completa del sito infetto più l'ultimo mese di log primadi qualsiasi pulizia. Se ripristini da un backup senza identificare il punto di ingresso, sarai compromesso di nuovo nello stesso modo, di solito entro una settimana. Quella copia è la tua unica possibilità di capire come sono entrati.

3. Ruota Ogni Credenziale

Tutte, senza eccezioni, nessun "quella sicuramente non potrebbe essere trapelata". Hosting, SSH, database, ogni utente admin, FTP, registrar di dominio, email, servizi connessi. Attiva l'autenticazione a due fattori ovunque mancava mentre sei lì. Un avvertimento che la gente ignora: fallo da un computer pulito. Se il laptop è infetto, le tue nuove password trapelano esattamente come quelle vecchie.

4. Trova il Punto di Ingresso

Inizia con i file modificati nella data di infezione — la pista più veloce. Cerca nei log quale richiesta è arrivata poco prima che apparisse il primo file straniero. Controlla tutto nell'account di hosting, inclusi i sottodomini dimenticati. Controlla i computer di tutti coloro che hanno accesso. Fino a quando il punto di ingresso non è trovato, l'incidente non è chiuso.

5. Ricostruisci

Il miglior percorso è una reinstallazione pulita: CMS fresco, plugin freschi da fonti ufficiali e solo il tuo contenuto e database presi dal backup — con il database controllato prima, perché il codice viene iniettato anche lì, di solito nei modelli e nelle impostazioni. Pulire manualmente i file infetti è una lotteria: se ne perdi anche solo uno, tutto torna.

6. Chiudi il Buco e Recupera la Tua Reputazione

Correggi la causa che hai identificato, altrimenti hai semplicemente resettato l'orologio. Poi: richiedi una revisione in Google Search Console, controlla i record di posta del tuo dominio (un sito compromesso stava probabilmente inviando spam, e il tuo dominio potrebbe già essere nelle liste di blocco), e conferma che non ci siano amministratori sconosciuti rimasti nel database.

Una nota onesta: se il tuo sito accetta pagamenti o memorizza dati personali dei clienti, improvvisare è la scelta sbagliata. Vuoi qualcuno che l'abbia già fatto — contattaci. Gestiamo incidenti come questi, e, cosa più importante, spieghiamo dopo esattamente cosa è andato storto e come assicurarci che non si ripeta.

Una Checklist di Sicurezza Pratica

Compattiamo tutto quanto sopra in un elenco su cui puoi iniziare oggi. È ordinato in base all'effetto relativo allo sforzo — inizia dall'alto.

Oggi, in Una Sera

1. Accendi 2FA per l'hosting, il tuo registrar di dominio, email e l'amministratore del sito.
2. Verifica HTTPS funziona ovunque e tutti i reindirizzamenti HTTP a esso.
3. Apri l'elenco degli utenti amministratori e rimuovi tutti coloro che non dovrebbero essere lì: ex membri dello staff, vecchi appaltatori, account che nessuno riconosce.
4. Controlla la radice web per file vaganti: archivi, dump del database, un .git cartella, copie di configurazione, script di test.
5. Conferma che i backup esistano e non siano memorizzati sullo stesso server.
6. Collega il sito a Google Search Console e leggi la sezione sicurezza.

Questa settimana

1. Imposta un gestore di password e sostituisci ogni password riutilizzata con una unica.
2. Aggiorna il CMS e tutti i plugin, dopo aver effettuato un backup completo.
3. Elimina plugin e temi non utilizzati — elimina, non disattivare.
4. Configura intestazioni di sicurezza: inizia con X-Content-Type-Options, X-Frame-Options e Referrer-Policy, che sono sicuri da abilitare immediatamente.
5. Disabilita FTP e passa alle chiavi SSH.
6. Aggiungi monitoraggio dell'uptime e avvisi per la scadenza di SSL e dominio.
7. Limita il numero di tentativi di accesso nel pannello di amministrazione.

Questo mese

1. Testa un ripristino in un ambiente di staging — distribuiscilo effettivamente e guardalo.
2. Metti un CDN e WAF davanti, e chiudi l'accesso diretto al server in modo che nulla bypassi il filtro.
3. Implementa CSP, iniziando in modalità solo report.
4. Audita tutto nell'account di hosting: sottodomini, copie di staging, pagine di atterraggio dimenticate. Elimina ciò che non è necessario.
5. Imposta monitoraggio dell'integrità dei file.
6. Rivedi permessi di file e cartelle, rimuovendo l'accesso in scrittura ovunque non sia richiesto.

In Ripetizione, Così Non Avrai Mai Più Bisogno di Questo Articolo

• Settimanale: aggiornamenti di sicurezza, uno sguardo al registro di accesso.
• Mensile: verifica i backup, rivedi gli utenti, scorri i log.
• Trimestrale: testa il ripristino, controlla i plugin, ruota le password delle chiavi.
• Annuale: audit completo, ripensa a chi ha accesso e perché.

Un'ultima riflessione da portare con te. La sicurezza non è uno stato che raggiungi e dimentichi; è un'abitudine, come chiudere a chiave la porta dell'ufficio. Nessuno può garantire una protezione assoluta, e chiunque lo prometta ti sta ingannando. Ma la differenza tra un sito dove questa lista è completata e un sito dove nulla di tutto ciò è fatto è la differenza tra "qualcuno ha provato e non è riuscito" e "siamo nella terza settimana di recupero dei nostri dati".

FAQ