(vedi anche parte 1)

Ban manuale indirizzi IP

Tutto è iniziato in ottobre 2024 con Meta. Per quanto fossimo sorpresi (forse nemmeno più di tanto, in realtà) che un’azienda con una certa reputazione nell’ambiente informatico, potesse mettersi a fare simili cose, tale comportamento non era per niente accettabile. Perciò, non ci abbiamo pensato due volte a bannare tutti i loro indirizzi IP.

Adesso non è più possibile nemmeno vedere l’anteprima del sito del GOLEM quando si condivide un post su Facebook o Instagram, ma ce ne siamo fatti una ragione (e forse, tutto sommato, non c’è voluto nemmeno molto).

Hack con fail2ban

In questo marasma, alcuni bot comunque continuano ad essere del tipo tradizionale, e si collegano da un ristretto numero di indirizzi IP (o addirittura da uno soltanto), perciò, c’è ragione di credere che questi bot appartengano ad altre piccole entità o singoli individui, come Università, piccoli enti di ricerca, e singoli individui.

Tuttavia, se prima potevamo trascurare questi maleducati occasionali, visto che adesso bisogna cercare di ripararsi da più fronti possibili, noi li banneremo, e loro si dovranno adeguare, banalmente aumentando l’intervallo di tempo che intercorre tra una richiesta e l’altra. Il lato positivo di questi bot è che sono facilmente individuabili da un sistema automatico, come qualsiasi proxy web, e come fail2ban.

fail2ban è uno strumento che tiene sotto controllo i log di un servizio, e se rileva troppi accessi falliti in un breve lasso di tempo, aggiunge una regola al firewall, in modo tale da bloccare il malintenzionato. L’obiettivo di fail2ban è di proteggere alcuni servizi, come ssh, da attacchi dizionario ed esaustivi, non da denial of service.

La sua protezione infatti entra in azione:

• solo quando viene rilevato un tentativo di accesso fallito
• solo quando più accessi fallimentari provengono dallo stesso indirizzo IP

Pur non essendo lo strumento più adatto a proteggersi dalla situazione di DDoS precedentemente descritta, fail2ban può essere configurato a piacere per proteggersi almeno da una sottocategoria di attacchi DoS. In particolare è possibile:

• specificare un’espressione regolare personalizzata, per riconoscere situazioni problematiche a piacimento. Per esempio, un accesso a una pagina HTML statica in /assets è ben diverso dall’accesso di un endpoint dispendioso del tipo /git/blame/hash-del-commit, per cui si può fare in modo che fail2ban consideri problematici accessi temporalmente ravvicinati a URL del secondo tipo.
• la regola di ban può essere estesa per comprendere più del solo IP malevolo, per esempio per bannare a prescindere tutta una sottorete a cui appartiene, grande a scelta (es. tutta una /16). Si tratta di una sorta di brutale pesca a strascico, che potrebbe accidentalmente coinvolgere anche utenti legittimi, ma è efficace e, come vedremo presto, comunque nessun sistema che abbiamo provato è completamente immune da effetti collaterali.

In linea di massima, un simile sistema, ad esempio per Gitea, può essere imbastito nel seguente modo (da affinare).

1. Aggiungere una regola di fallimento personalizzata che identifichi gli IP dannosi, a gruppi di 64k per volta, nel log di gitea:

# /etc/fail2ban/filter.d/gitea-crawler.local

[Definition]
failregex = router: completed GET .* for <F-ID>\d+\.\d+</F-ID>\.\d+.\d+:
    

2. Bannare l’intera sottorete /16 che circonda l’IP malevolo, arrotondato al blocco. (come dicevo, la tecnica va affinata)

# /etc/fail2ban/action.d/nftables-subnet.local
[INCLUDES]

before = nftables-allports.conf

[Definition]
actionban = <nftables> add element <table_family> <table> <addr_set> \{ <F-ID>.0.0/16 \}
actionunban = <nftables> delete element <table_family> <table> <addr_set> \{ <F-ID>.0.0/16 \}
    

Questo sistema ha attenuato il problema, ma era chiaro fin da subito che non era la soluzione. I bot più sofisticati e più forniti di risorse, in poco tempo sono diventati in grado di eluderla, cambiando dinamicamente la sottorete di indirizzi IP di provenienza, oppure, semplicemente spalmando le richieste su un numero di indirizzi IP esageratamente più grande, risorsa che solo Stati e grandi multinazionali possono permettersi.

fail2ban on steroids

Ciò che ci serviva era uno strumento come fail2ban, ma che fosse in grado di aggregare le richieste non solo per un indirizzo IP, ma per una intera sottorete, però in modo un po’ più furbo.

Ci è dunque venuto in mente di sfruttare il servizio whois. Tramite protocollo whois è possibile recuperare informazioni circa il proprietario di un determinato indirizzo IP, almeno in forma aggregata, e, di nuovo, un po’ approssimativa. Non solo: è anche possibile sapere quanto è grande la sua sottorete.

Per esempio, effettuando una richiesta whois sull’indirizzo IP di questo sito, si ottengono le seguenti utili informazioni:

    $ whois 152.228.140.73
    [...]
    NetRange:       152.228.128.0 - 152.228.255.255
    CIDR:           152.228.128.0/17
    OrgName:        RIPE Network Coordination Centre
    Entities:       OVH SAS
    Country:        FR
    [...]
    

In questo modo, bannando l’intera sottorete, è possibile difendersi in maniera molto più efficace da attacchi provenienti non da un singolo, ma da un’entità che gestisce interi datacenter. Il rovescio della medaglia è che, così facendo, si rischia di bannare anche utenti legittimi, che magari hanno solo affittato una macchina virtuale in quel datacenter, ignari delle cattive intenzioni dei vicini di cui si sono circondati.

Inoltre, whois presenta numerosi problemi, che lo rendono uno strumento tutto sommato inefficace.

• età: la prima versione di whois è di poco successiva al 1980, ed è un protocollo che è invecchiato piuttosto male. Abbiamo dato un’occhiata al suo successore RDAP, ma nel mentre abbiamo capito che, ancora una volta, stavamo affrontando il problema nel modo sbagliato.
• human readable: l’output di whois è facilmente interpretabile da un essere umano, ma molto difficilmente da una macchina: record di testo liberi, incongruenza tra i vari registri, …
• aggregazione: alcuni registri mostrano le informazioni whois in modo molto aggregato, tanto che un solo record può contenere spazi di indirizzamento enormi, grandi come interi Stati.
• IPv6: i registri IPv4 sono piuttosto inconsistenti e presentano lacune: quelli IPv6, lasciamo perdere.

Perciò, dopo un breve esperimento, si è optato per vie alternative.

(segue parte 3)

Negli ultimi mesi, su Internet, si è registrato un sensibile aumento del traffico web dovuto ai bot.

Ma cosa sono i bot?

Noti anche come crawler o spider, ciò che li caratterizza è che sono programmi automatici che navigano sul web, e non normali esseri umani. Lo scopo di questi programmi è vario: possono servire a recuperare dati dai siti web, quando questi non forniscano interfacce macchina adatte, per esempio per creare servizi aggiuntivi; possono avere come scopo l’archiviazione dei siti, una specie di “fotografia” che li immortala nel tempo, come fa il noto web.archive.org; questi bot possono anche essere degli esploratori per i motori di ricerca, che creano un indice di ciò che si trova sul web, e permettono poi di cercarlo con facilità, come fanno Startpage, Bing, Duckduckgo e Google, solo per citare alcuni dei più famosi; infine, in seguito alla nascita dei moderni modelli di intelligenza artificiale generativa, alcuni bot sono impiegati per la lettura di testi di ogni tipo, in modo da allenare queste intelligenze artificiali.

Come si vede, gli scopi per cui i bot navigano il web sono numerosi e diversi, e tutti anche piuttosto nobili.

Perché i bot possono essere un problema

Ciò che li rende però diversi dai navigatori umani, è che sono dei programmi automatici, che possono dunque navigare molto più velocemente: possono leggere, cliccare, scaricare, e fare qualunque cosa in molto meno tempo di un essere umano. Questa caratteristica fa sì che, se programmati senza cognizione di causa, possono facilmente diventare dannosi per i siti a cui si collegano. Infatti, se fanno molte richieste ravvicinate, possono mettere in difficoltà il server che deve loro rispondere, che si trova sovraccarico di lavoro.

Il web come un luogo civile

Le risorse che hanno a disposizione i bot e i server sono delle più varie. È facile immaginare che un’azienda come Google, che ha 180 mila dipendenti, possa mettere a disposizione molte più persone, denaro e computer per i suoi bot, rispetto a quanto può mettere a disposizione per i suoi server un’associazione come il GOLEM, che ha 40 soci, 10 volontari, e fattura un fico secco.

(Però l’Officina del GOLEM ha la sua personalissima pianta di fichi che cresce bucando l’asfalto)

È così che, per permettere ai siti web di fornire un servizio senza essere oberati di richieste, e per permettere ai bot di svolgere il loro utile lavoro senza essere d’intralcio, sono state concordate alcune buone regole per la convivenza civile.

• user agent: quando un bot fa una richiesta ad un sito web, trasmette il suo nome, identificandosi chiaramente come un bot. In questo modo, il sito web può attuare delle contromisure per proteggersi da sovraccarico, per esempio rallentando solo i bot quando è già impegnato a gestire le richieste di molti utenti umani.
• robots.txt: l’amministratore di un sito web può specificare quali pagine del suo sito possono essere recuperate dai bot, da quali bot, e con che frequenza. Un bot che desidera accedere a un sito web, deve prima controllare il contenuto di questo file, e poi regolarsi automaticamente, in modo da svolgere il suo lavoro senza arrecare danno o disturbo.

Da qualche mese a questa parte, tuttavia, alcune compagnie che allenano intelligenze artificiali, come Amazon, Meta, OpenAI e Alibaba, hanno smesso di comportarsi da onesti cittadini della rete, e hanno iniziato a contravvenire a tutte le norme di convivenza civile. In particolare:

• alcuni effettuano numerose richieste in breve tempo: le richieste giungono in modo aggressivo, anche centinaia di richieste al secondo, per un lasso di tempo di diversi minuti, e in più, dopo qualche ora, sebbene il contenuto del sito non cambi, il treno di richieste si ripete.
• alcuni falsificano lo user agent: non si identificano più come bot, ma cercano di aggirare i controlli fingendo di essere comuni browser comandati da esseri umani.
• altri trascurano il robots.txt: visitano qualunque pagina in modo indiscriminato e senza alcun freno temporale.

Il web come un luogo di malintenzionati

Fino a qui, questo comportamento potrebbe essere quasi giustificato dall’ignoranza: se il bot viene scritto dal primo script kiddie che passa per strada, potrebbe anche essere che egli ignori queste buone maniere, e, utilizzando sistemi con molte risorse per il suo bot, danneggi involontariamente le infrastrutture dei server più piccoli. Poco male: un bot così maleducato, comunque, è abbastanza facile da tenere sotto controllo: è sufficiente notare che un solo computer sta accedendo al sito in modo molto più frequente del normale, e bloccarlo.

Tuttavia, questi bot non solo sono maleducati, ma sono progettati in maniera tale da eludere deliberatamente le misure di contenimento. Infatti, invece di apparire come singoli computer, essi appaiono come tanti diversi computer, cambiano continuamente il loro indirizzo IP, e si collegano in maniera coordinata da più “luoghi” della rete.

Questo problema ha iniziato ad affliggere molto pesantemente tutto il web.

Questo dunque non è l’errore di un ignorante: questo è un comportamento malevolo e deliberato. Questo è un attacco DDoS (Distributed Denial of Service) realizzato per mezzo di una botnet.

Non esiste altra definizione per un simile comportamento. Infatti, anche ammesso di voler ulteriormente giustificare l’ingiustificabile, non si capisce quale altro dovrebbe essere lo scopo di questi bot, se non quello di causare disservizi, inondando i server con migliaia di richieste. Si potrebbe argomentare che stanno “semplicemente” allenando la loro intelligenza artificiale alla massima velocità possibile. Ma quando i piccoli server si trovano ad affrontare un’orda di migliaia e migliaia di richieste, ogni secondo, non fanno altro che soccombere, si bloccano e diventano irraggiungibili. Quindi su cosa si dovrebbero mai allenare queste intelligenze artificiali, se buttano giù i siti da cui risucchiano avidamente la loro stessa linfa vitale?

L’associazione GOLEM

Il GOLEM — Gruppo Operativo Linux Empoli, è un Linux Users Group (LUG) con sede a Empoli (FI). Da mesi i siti web del GOLEM sono instabili, a volte ci sono downtime prolungati, anche di diversi minuti, e ormai questi disservizi sono all’ordine del giorno.

Una volta, in seguito ad un attacco da parte di alcuni di questi avidi bot, quando siamo riusciti a collegarci al server, il carico del sistema registrava 172. Considerato che il VPS del GOLEM ha solo 4 processori, significa che il suo carico massimo è 4, e che quindi stava cercando di gestire, da solo, un carico 43 volte più grande di quello che poteva sostenere. ^{(con le dovute approssimazioni)}

In modo molto approssimativo, si immagini di perdere tutto il lavoro che si è fatto fatto nell’ultimo mese e mezzo, e il capo chieda di rifarlo daccapo entro oggi. Non c’è nessuna speranza che qualcuno ci possa riuscire, dunque si soccombe.

Per non soccombere, sono state dunque prese alcune contromisure.

(segue parte 2)