--- title: "Ormai tutti possono hackerare" date: 2026-10-23 language: it topics: [] source_url: https://willem.com/it/2026-10-23_ormai-tutti-possono-hackerare/ --- # Ormai tutti possono hackerare *È ora di prendere sul serio la tua sicurezza* > Qui scrivo raramente di attualità: la cronaca del giorno la lascio volentieri ad altri. Ma quest'anno nella sicurezza informatica è cambiato qualcosa, e non si tratta di una singola vulnerabilità. È che ormai tutti possono hackerare. Dai a un modello linguistico un punto debole, o anche solo una direzione, e trova la falla, e se glielo permetti anche l'exploit. La domanda "perché dovrebbero hackerare proprio me?" ha perso ogni senso. È ora di raddoppiare gli sforzi! ## Questa volta la scala è diversa Questa settimana una vulnerabilità critica ha colpito un linguaggio di programmazione su cui gira buona parte del web. Matthew Prince, il CEO di Cloudflare, [ha contato su X](https://x.com/eastdakota/status/2113079352682570051) (22 ottobre 2026): migliaia di tentativi di exploit nelle dieci ore prima dell'annuncio pubblico, decine di migliaia nei 45 minuti successivi, centinaia di migliaia entro due ore, milioni il giorno dopo. Jason Clinton, responsabile della sicurezza di Anthropic, [ha scritto lo stesso giorno](https://x.com/JasonDClinton/status/2113325263157395456): vai subito dal tuo consiglio di amministrazione e chiedi aiuto, non per l'AI, per le basi. Ecco perché penso che sia più di una brutta settimana. La maggior parte del codice su internet non è mai stata letta da una macchina che lo capisce. Molte debolezze sono rimaste nascoste perché oscure, astratte o matematiche. Un essere umano aveva bisogno di vere doti da hacker, di tempo e di un po' di fortuna per trovarne una. Un modello ha la pazienza e l'acutezza per testare molti più vettori di attacco, su molto più codice, di qualunque team di persone. Bot e agenti setacciano il web in modo sistematico, su una scala e con una capacità che non avevamo mai visto, e migliorano ogni mese. Nessuno è più troppo piccolo per essere trovato. ![Global AppSec Amsterdam 2019. Alle conferenze come questa ci vado di persona: gli hacker, i ricercatori e i CISO che incontri lì vedono per primi ciò che sta arrivando](https://willem.com/global/images/8d096c9c5a49.webp) ## Raddoppiare gli sforzi Non c'è nessun trucco nuovo. Le basi sono le stesse da vent'anni. Quello che è cambiato è il prezzo di ignorarle. - **Resta aggiornato.** Installa in fretta gli aggiornamenti di sicurezza, in automatico dove puoi. L'intervallo tra un annuncio e lo sfruttamento di massa ormai si misura in minuti, non in settimane. - **Fai i backup.** Fuori sede, a rotazione e cifrati. Una sola copia non è un backup. - **Testa i tuoi backup.** Riesci davvero a ripristinarli? Fallo, cronometralo, e rifallo il trimestre prossimo. - **Riduci la tua superficie d'attacco.** Meno componenti in funzione, meno servizi pubblici, meno pezzi che non controlli tu. Ogni plugin, ogni account e ogni servizio è una porta. - **Parti dal peggio.** E se domani tutti i tuoi dati venissero rubati e resi pubblici? Pensaci oggi fino in fondo, e togli subito dal tavolo quello che puoi. I dati che non ti servono, non li conservi. - **Guarda.** Tieni un occhio forte e automatico sui tuoi log. Il danno lo decide il tuo tempo di reazione alla prima anomalia, non l'attacco in sé. ![2017: il mio server sotto il pavimento dell'ufficio. I tuoi dati puoi sempre nasconderli sotto lo zerbino... /s. La sicurezza per oscurità non è, e non è mai stata, una buona idea](https://willem.com/global/images/17aa8c676841.webp) ## Gli anni di DigiDef Dal 2015 al 2019 ho fatto questo lavoro con un nome tutto suo: DigiDef, uno studio di difesa digitale. Audit di sicurezza di server, siti web e app, audit dei backup prima che ti servano davvero, revisioni del codice sorgente, e la ricostruzione, a cose fatte, di come gli hacker sono entrati. Una parte l'ho raccontata qui: [cinque semplici consigli per proteggere il tuo server](https://willem.com/en/2018-03-10_cyber-security-5-easy-tips-to-protect-your-server-against-hackers/), [i rischi di sicurezza dello shared hosting](https://willem.com/en/2019-02-28_understanding-the-security-concerns-in-shared-hosting/), [dieci consigli per WordPress](https://willem.com/en/2019-03-31_wordpress-10-tips-to-secure-your-website/) e, più tardi, [uno schema di rotazione dei backup](https://willem.com/en/2023-12-15_backup-rotation-scheme/). digidef.nl ora è offline, ma il lavoro di DigiDef mi sembrava così importante che l'ho reso parte integrante di tutto quello che faccio: siti web generati in anticipo, senza niente sul server con cui un visitatore possa parlare, server con meno porte aperte possibile, log letti ogni notte e backup che vengono ripristinati sul serio. ![DigiDef, studio di consulenza per la difesa digitale, dal 2015 al 2019](https://willem.com/global/images/e9f42942df27.webp) ## Mani in pasta Ecco com'è nel mio lavoro. Dal 2016 ogni sito che costruisco viene generato in anticipo: le pagine si creano una volta sola, come file, e il server si limita a distribuirle. Dietro la richiesta di un visitatore non c'è nessuna applicazione che si possa convincere a fare ciò che non dovrebbe. Questo rende i siti più veloci e più semplici, e lascia pochissimo da attaccare. Meno parti in movimento: tutta l'idea è qui. Tutti i miei server inviano ogni riga di log al sistema di log unificato della piattaforma: circa 1,7 milioni di segnali al giorno, ordinati per tipo e contati al minuto. Ogni mattina un giro di controllo della sicurezza li legge, in cerca di ciò che esce dai binari: tipi di riga mai visti prima, tentativi a raffica su posta e ssh, rinnovi falliti, ban, un servizio che risponde con errori. Lo stesso giro confronta ogni host con il giorno prima: aggiornamenti di sicurezza in sospeso, porte aperte, utenti, chiavi, cron job, e l'elenco delle vulnerabilità note rispetto a ciò che è davvero installato. Si fa sentire solo quando serve una mano. ![Questa mattina nella mia app Contact: il giro di controllo della sicurezza ha trovato sette cose che richiedono una mano, e me l'ha detto](https://willem.com/global/images/27809e8f84d4.webp) I backup partono ogni notte, fuori sede, attraverso una porta a senso unico: la macchina di produzione decide cosa esce, il lato ricevente non può tornare indietro. Gli snapshot li fa, dopo la copia, un account separato, così nemmeno un mittente compromesso può cancellare la cronologia. Poi un controllo indipendente percorre lo specchio dall'esterno, confronta un campione byte per byte e dà un verdetto. Più di una volta ha sorpreso il backup a dichiarare un falso verde. Ogni tanto faccio uno scenario vero di disaster recovery, come ho fatto per uno dei miei clienti: si parte dai soli backup e si rimette in piedi il servizio da un'altra parte. La lacuna che trovi così, quell'unico file che la copia notturna non aveva mai incluso, non compare mai in un rapporto che dice solo OK. E resto "nel giro" con le persone della Silicon Valley che costruiscono questi modelli e si difendono da essi; le due citazioni qui sopra vengono da lì. ## Una maratona, non uno sprint Nessuno è al sicuro. Più sai e capisci di sicurezza informatica, più ti rendi conto che non esiste una soluzione rapida. È uno sforzo di resistenza, e somiglia molto più a una maratona che a uno sprint. Tieni un passo che puoi sostenere, guardi la strada davanti a te, sistemi ciò che trovi oggi, e domani guardi di nuovo. ![Köln Marathon, 4 ottobre 2026: un passo che puoi sostenere](https://willem.com/global/images/1e36ac60ab36.webp) ## Conclusione La sicurezza informatica non è più una possibilità teorica. Bot e agenti setacciano il web in modo sistematico, su una scala che nessun team umano può eguagliare, e trovano ciò che per anni era rimasto nascosto. La risposta non è un nuovo prodotto. Sono le basi, fatte bene e rifatte: resta aggiornato, fai i backup e testali, tieni in funzione meno componenti, parti dal peggio e guarda i tuoi log. Non sei sicuro di dove siano le tue porte? [Scrivimi un messaggio](https://willem.com/en/#contact), lo faccio da molto tempo. I bot sono già in corsa. Meglio allacciare le scarpe.