Passa ai contenuti principali

Cinque milioni di bot contro due sysadmin, la battaglia (dimenticata) della FSF

Sono diventato membro donatore della Free Software Foundation quando avevo quindici anni. In quelle pagine e in quei principi c’era qualcosa che andava oltre il codice: c’era la libertà, quella vera, quella di scegliere, quella di capire cosa c’era dentro il software che usavi, quella di modificarlo, condividerlo, metterlo al servizio degli altri. Una visione nobile, idealista, certo. Eppure reale, concreta, fatta di server, shell, mailing list, bug da inseguire, discussioni infinite sul concetto di libertà 0.

Negli anni, ammetto di essermi allontanato. Ho iniziato a usare anche sistemi non liberi, per esigenze pratiche, lavorative, per quel compromesso che spesso chi lavora nell’IT finisce per fare. Ma la FSF è rimasta lì, in piedi, come un presidio di resistenza. E oggi, quando ho ricevuto questa loro comunicazione, mi sono fermato. Perché quello che stanno subendo è semplicemente folle, e merita attenzione.

Due soli amministratori di sistema a tempo pieno, supportati da un piccolo manipolo di volontari, stanno fronteggiando da quasi un anno una serie continua e devastante di attacchi DDoS contro le infrastrutture principali del mondo GNU e della FSF. Parliamo di oltre settanta servizi attivi e una dozzina di server fisici distribuiti tra due datacenter nell’area di Boston. Su quei server girano, tra le altre cose, i progetti JShelter, KDE, Sugar Labs, Savannah, GNU stesso. Servizi pubblici, gratuiti, aperti, fondamentali per l’ecosistema del software libero. Eppure, sono nel mirino.

Tutto è cominciato nell’agosto del 2024, con un attacco a gnu.org che mirava chiaramente a metterlo offline. Non era un crawler da LLM, non sembrava avere scopi di raccolta dati. Solo danno. È stato mitigato, ma da allora la situazione è peggiorata. Nel gennaio 2025, Savannah.gnu.org – la piattaforma di sviluppo collaborativo del progetto GNU – è stata colpita da una botnet di circa cinque milioni di IP, probabilmente al servizio di qualche sistema di addestramento LLM, se vogliamo dar credito alle impronte lasciate. L’attacco è tuttora in corso, anche se attualmente mitigato.

Poi, a fine maggio, un nuovo DDoS contro gnu.org e ftp.gnu.org, nuovamente con l’obiettivo di farli crollare. Ancora ignoti gli autori, ancora ore e ore di blackout e contromisure tecniche da sviluppare in corsa. Come se non bastasse, da metà giugno è sotto attacco anche directory.fsf.org, probabilmente da parte di uno scraper automatizzato costruito per colpire in massa siti MediaWiki. Anche in questo caso: botnet, traffico distribuito, intensità crescente, obiettivo oscuro.

Oltre a questi attacchi deliberati, c’è una nuova forma di “abuso involontario” che oggi aggrava la situazione: i sistemi di CI/CD (continuous integration/deployment) automatizzati che interrogano ripetutamente Savannah alla ricerca di nuove release. Niente di male in teoria, ma il problema è che questi sistemi spesso generano un carico eccessivo, paragonabile a un attacco DDoS, senza lasciare contatti o identificazione nell’header HTTP. Così, l’unico modo per fermarli è bloccare i loro IP.

A questo si somma la giungla di crawler SEO, scanner di vulnerabilità, uptime checker, browser automatizzati e traffico spazzatura da VPN e CGNAT. Difendersi è un lavoro di cesello, ogni volta diverso, e richiede tempo, intelligenza e precisione, soprattutto per non escludere utenti legittimi. La FSF, quando possibile, rimuove gli IP errati dalla lista nera, ma chiede a chi ha problemi di accesso di scrivere direttamente ai sysadmin con il proprio indirizzo IP. Capite quanto siamo lontani da qualsiasi automatismo: qui si lavora ancora con gli script cuciti a mano.

Il problema è talmente diffuso che alcuni sviluppatori hanno cominciato a integrare un sistema chiamato Anubis, che invia all’utente un JavaScript da eseguire prima di accedere al sito. Questo JS fa calcoli inutili, simili a quelli del mining, tenendo la CPU occupata anche per più di un minuto. Una sorta di prova di lavoro client-side, pensata per “filtrare” i bot. Eppure, se ci pensiamo bene, è malware. È un codice che il tuo browser esegue contro la tua volontà, solo per ottenere il contenuto di una pagina. La FSF – coerente con i suoi principi – si rifiuta di implementarlo, anche se potrebbe aiutarli a ridurre gli attacchi.

Tutta questa storia mi fa riflettere. Siamo nel 2025, nel pieno del boom dell’AI, dei LLM, del traffico automatico che satura la rete. E i bersagli non sono solo i siti a pagamento, o le piattaforme politiche, ma anche – e forse soprattutto – le enclavi di libertà. Perché un’infrastruttura libera, che ospita codice libero, educazione, alternative al mainstream, è un’anomalia da disinnescare. Siamo sicuri che non ci sia dietro la mano di qualche gigante del software proprietario? Un colosso che vede nella FSF e nei suoi valori un ostacolo culturale, ancora prima che tecnologico? È solo paranoia, la mia? Forse. Ma non riesco a ignorare la coincidenza tra la crescita degli interessi economici dei grandi vendor di AI e la recrudescenza degli attacchi ai pochi spazi che ancora difendono la libertà digitale.

Due sysadmin. Cinque milioni di bot. E un ideale che resiste.

Se oggi la FSF esiste ancora è grazie a persone come Bob, Corwin, Luke, e tutti quei volontari che continuano a lavorare in silenzio, gratis, per tenere in piedi questo fragile baluardo. E allora, anche se non uso più solo software libero, anche se ormai seguo meno mailing list e più repository GitHub, io non smetterò mai di ringraziarli. E voi, se potete, donate. Almeno una volta. Non per nostalgia. Ma perché un mondo in cui una FSF non può più esistere è un mondo che ha già perso.

Commenti

Popolari

IPv6, come siamo passati dai camuffamenti (tunnel broker) su IRCNet alle sfide di sicurezza di oggi

All’inizio degli anni 2000, prima che l’IPv6 fosse una realtà comune, per connettersi alla nuova rete servivano i tunnel broker: nodi messi in piedi da appassionati o provider che permettevano di avere un indirizzo IPv6 incapsulato dentro IPv4. In Italia c’erano nomi che oggi sembrano quasi leggendari: NGnet, Zibibbo, e poi, su scala più internazionale, SixXS, che per anni ha fornito tunnel di altissima qualità fino a dichiarare “mission accomplished” e chiudere nel 2017. Erano anni in cui IPv6 era roba da smanettoni, e la comunità IRCNet italiana era uno dei posti dove questo “potere” trovava applicazioni creative. Personalmente lo usavo per camuffare il mio IPv4: mentre con un indirizzo 95.x.x.x il server IRC mostrava il reverse DNS dell’ISP, con IPv6 potevo scegliere il mio indirizzo nel blocco assegnato, evitando di esporre il mio IP reale e cambiandolo a piacere. In quel periodo circolavano anche strumenti curiosi, come ipv6fuck.c dell’autore “schizoid”, un codice C che serviva pe...

WinRAR sotto attacco, zero-day critica sfruttata da hacker russi

Il 10 agosto 2025 è stata resa pubblica la vulnerabilità CVE-2025-8088 di WinRAR, una falla di tipo directory traversal già sfruttata in attacchi mirati da RomCom, gruppo hacker legato alla Russia e noto per operazioni di cyber-spionaggio ed estorsione. Il problema risiede nella gestione dei percorsi all’interno di archivi compressi: un file RAR malevolo può includere riferimenti a directory specifiche del sistema, forzando WinRAR a estrarre file in percorsi diversi da quelli scelti dall’utente. In particolare, è possibile copiare eseguibili nelle cartelle di avvio automatico di Windows, come %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup o %ProgramData%\Microsoft\Windows\Start Menu\Programs\StartUp. Alla successiva accensione del PC, il malware viene avviato in automatico, ottenendo così persistenza sul sistema e potenzialmente consentendo il controllo remoto. Gli attacchi osservati sono stati condotti tramite campagne di spear-phishing: le vittime ricevevano email contenenti...

Nuovo attacco agli ambienti ibridi Microsoft, l’allarme lanciato a Black Hat. Active Directory ed Entra ID sotto esame, la tecnica che sfida MFA e controlli tradizionali

A Black Hat USA 2025 è stata mostrata una lezione dura ma utile per chiunque gestisca identità e mail aziendali: un ricercatore ha dimostrato come, in certi ambienti ibridi che sincronizzano Active Directory locale con Microsoft Entra ID (ex Azure AD), un account cloud apparentemente a bassa priorità possa essere trasformato in un account “ibrido” con privilegi amministrativi, senza passare dalle normali barriere di autenticazione e senza far scattare gli allarmi tradizionali. La dimostrazione — presentata da Dirk-jan Mollema di Outsider Security — ha messo in luce vettori di abuso legati al server di sincronizzazione (Entra Connect), alle modalità di corrispondenza degli account tra on-prem e cloud (soft matching) e a token/claim usati nei meccanismi di delega e in Exchange ibrido. Per chi non mastica quotidianamente questi termini: molte aziende hanno ancora un Active Directory “dentro l’azienda” per utenti e servizi, e allo stesso tempo usano servizi cloud come Microsoft 365. Per fa...