Cloudflare 'super bot fight' come farne a meno (parte 3)

Bentornati!

In questo post continuo a parlarvi di tecniche per bloccare gli scraper e altre brutture che cercano di invadere i vostri siti, pensando che siano dei blog wordpress non aggiornati.

Chiaramente dovreste aggiornarli sempre e attivare l’auto aggiornamento per la vostra sicurezza, anche se la sicurezza maggiore è sempre quella di fare a meno di wordpress.

Nel secondo post vi ho illustrato una serie di regole di cloudflare che uso per schermare i miei siti da accessi indesiderati: io non uso quasi mai wordpress, ma comunque sia vedere questi tentativi mi da fastidio. E oltretutto usano banda e processi dei miei server, quindi è praticamente un furto.

Nei 3 mesi che sono passati, mi sono reso conto che potevo attivare una barriera ancora più potente, ma che ovviamente richiede una serie di considerazioni aggiuntive.

Da un punto di vista della sicurezza, il cloud computing è a tratti una merda

Calma. Mi spiego meglio.

Con l’evoluzione di questi decenni, i server hanno perso la connotazione fisica, per diventare sempre più virtuali. Spesso anzi sono dei “processi” che vengono creati e distrutti, con poche linee di codice. Non è complicato prendere una sorta di “copione” che verrà usato per configurare un server con determinate caratteristiche di potenza, disco, software installato.

Tecnologie come Docker, lo consentono facilmente, e rappresentano per chi sviluppa una tecnologia potentissima per diminuire i tempi di sviluppo, perchè la “configurazione” che usi nell’ambiente locale può essere replicata senza differenze in un ambiente online.

Queste innovazioni creano l’infrastruttura del cosidetto SAAS (software as a service), dove la macchina fisica viene nascosta dietro infiniti frammenti virtuali. che vengono continuamente creati e distrutti senza che ce ne accorgiamo.

Ovviamente ci sono dei grandi operatori che sono specializzati in queste tecnologie, che hanno fatto di questa virtualizzazione il loro punto chiave: Amazon Cloud su tutti è il leader, ma poi c’è anche Google Cloud, Digital Ocean , Microsoft Cloud e via dicendo.

tutto molto interessante ma a me come impatta?

Facciamo un’analogia.

C’è un “venditore di armi” che vende a chiunque senza farsi troppi problemi. Non ha nemmeno bisogno di sapere chi è il cliente, ha un ecommerce dove chiunque può registrarsi, pagare e ottenere l’accesso. C’è solo un piccolo inconveniente, non ti vende davvero le armi, ti vende una officina dove puoi costruire quello che vuoi.

In realtà non è davvero un venditore di armi è una specie di intermediario, ma senza di lui i criminali avrebbero vita dura a costruirsi le armi.

Bisognerebbe dire all’intermediario che deve fare più attenzione e che tutto c’è un limite, ma l’intermediario è un bestione di 3 metri, gira con un nodoso randello e un battaglione di avvocati berserker col sangue alla bocca.

Delle tue lamentele, all’intermediario non frega niente. E poi comunque se provi a fargli notare che i servizi stanno arrecando un danno, ti dice che ha già provveduto a chiudere il servizio che dava problemi. Forse. Non hai modo di verificarlo.

Ecco quello che succede nella realtà

• Questi fornitori hanno comprato centinaia di migliaia di indirizzi IP
• Quando un servizio viene “avviato” su richiesta gli viene assegnato un ip
• Quando il servizio “muore” l’ip viene rimesso nel mucchio di quelli disponibili
• Tempo che arrivi qualche rimostranza, il servizio che ha dato problemi è già stato chiuso e magari l’ip ha già cambiato 4 servizi.
• Ma nel frattempo chi ha creato il servizio “fastidioso” (che magari ha cercato una vulnerabilità di accesso o ha scrapato dei contenuti) si è già dileguato.
• A quel punto il fornitore dice “ho già fatto il possibile” (cioè niente) e non c’è nemmeno una indagine. Sopratutto se la richiesta arriva da un paese diverso dal suo.
• …salvo non ci sia di mezzo un hacking di alto livello che introduce nel giro delle richieste anche una forza di polizia. A quel punto il fornitore per non finire al gabbio, si prostra a terra e nel caso degli Stati Uniti, se possibile scava anche una buca.

Ma quindi siamo fottuti ? Non c’è protezione da questi attori malvagi ?

Ni, insomma. Fare un sistema a prova di attacco è praticamente impossibile se non staccandolo dalla rete fisica. Ma possiamo comunque, con l’aiuto di Cloudflare, iniziare ad arginare il diluvio di attacchi automatici.

E magari stoppare anche gli script di quel tizio dell’analytics e della privacy. Sapete di chi parlo no ?

Iniziamo!

Barriera di Livello 1: il codice ASN

Se riprendete l’episodio scorso, vi avevo spiegato che Cloudflare può bloccare determinate richieste che includano parti di indirizzo url, per esempio posso impostare la regola nel WAF che dice:

se la richiesta di una url contiene “wp-admin” applica dei controlli extra.

Fin qua tutto ok no ? Aggiungo un po’ di queste regole e posso iniziare a dare fastidio a chi cerca di intrufolarsi secondo diversi metodi di accesso.

Ma questo non mi basta. I cosidetti “vettori di attacco” cambiano nel tempo e nel corso dell’anno dovrei fare delle aggiunte alle regole che fino a quel momento non c’erano ma sono state improvvisamente scovate da chi cerca di entrare sul sito.

Nell’articolo avevo menzionato un parametro che è possibile analizzare il cosidetto ASNUM cioè un codice numerico che identifica un “fornitore.”

hm.

Quindi anche nel caso di un fornitore che ha diversi data center (aws, microsoft, google, ecc) mi basta un numeretto per bloccare tutti gli accessi…

Interessante no ?

La mia situazione è la seguente:

• io creo siti per utenti reali. Questi utenti visitano i siti tramite dispositivi cellulari e in piccola parte con desktop/laptop e tablet.
• Probabilmente una microscopica parte potrebbe visitare i siti tramite una VPN.
• Probabilmente questa microscopica parte potrebbe visitare i siti anche senza VPN, ma onestamente non ho tematiche che lo richiedono. E comunque posso predisporre una soluzione di ripiego…
• Quindi posso fare a meno delle connessioni tramite questi fornitori di servizio ? Direi proprio di si.

eccome come funziona

quando il parametro ASN è contenuto in questo elenco, attiva le contromisure.

Le contromisure sono la modalità “manage Challenge” di cloudflare, quindi in sequenza di complessità.

• 1. controlla se il client ha un interprete javascript
• 2. prova a scrivere dei valori tramite javascript e leggili
• 3. controlla se non è uno ip sospetto
• 4. fai premere un pulsante
• 5. fai compilare un captcha

Se questa sequenza viene interrotta, l’accesso viene impedito prima di arrivare sul sito.

fico ! Ma questi numeri come li hai scelti ?

Tramite l’osservazione per un mesetto circa, su diversi siti miei che sono targetizzati su diversi mercati.

Visto che le vostre necessità potrebbero essere diverse, li descrivo.

• 8075: Microsoft Corporation. Iniziamo subito dai pesi massimi. Il cloud di microsoft è diffuso in diversi paesi. Bloccandolo, impediamo l’accesso ad Azure, ai dipendenti Microsoft e chiaramente a BING bot. Se per voi il traffico di Bing non è trascurabile e come Seo volete comunque averlo aggiungete questa condizione alla regola.

NB: Ci tengo a sottolineare che tutti quelli elencati non sono direttamente implicati nei tentativi di intrusione, ma non hanno fatto abbastanza per impedirlo. Non li ho inseriti per antipatia.

• 24940: Hetzner Online: Hetzner è un fornitore di server fisici e virtuali della germania.

• 213230 Hetner.de: nuovamente Hetzner. Per ora l’unico caso che ho visto, probabilmente è il risultato di una fusione aziendale, fatto sta che questo codice esiste dal 2020, quello prima dal 2002! Ma la creazione di vettori d’attacco c’è comunque.

• 136907 : Huawei Clouds: Servizio di cloud computing di huawei. Come la maggior parte delle cose non gastro/culturali della Cina, può far meno di esistere per quanto mi riguarda. Fanculo le autocrazie.

• 27411: Leaseweb: Cloud hosting.

• 60068: cdn77 : cdn tipo cloudflare. Sono in dubbio, perchè potrebbe essere usata come tunnel in uscita ma la gestione della challenge blocca gli script, non eventuali dispositivi.

• 211138: private-hosting.eu: Non so cosa abbia Oscar da nascondere, ma di sicuro non ha bisogno di accedere ai miei siti.

• 16509: amazon.com: Ecco l’altro colosso (di cui sono anche cliente per alcuni servizi). Questa opzione blocca l’intero ecosistema amazon dei servizi web che non può più accedere al vostro sito web a cui è stata applicata. Questo non vi impedisce di accedere ai servizi AWS dal vostro server, ma blocca in entrata l’accesso di servizi che arrivano da AWS e sono destinati al sito web. Statisticamente avete bloccato il 32% degli attacchi. Se usate AWS fate attenzione e fate diversi test. NB: Amazon ha circa 43milioni di IP e ospita circa 38 milioni di domini.

• 13238 : Yandex: Non ho clienti o business in Russia e credo che per qualche anno non l’avrete nemmeno voi se leggete questo articolo. Chiaramente blocca il crawler di Yandex.

• 40021: Contabo: Hosting Americano

• 12479: Orange spagna: e’ una azienda che fa tutto, sia telefonia che servizi digitali in cloud. Visto che ho notato diversi tentativi di intrusione l’ho schermata tutta. Gli utenti normali vengono accettati, mentre i software vengono bloccati.

• 14061: digital Ocean: Li adoro dal punto di vista tecnico e ho anche un paio di servizi che girano li sopra (ma non siti web). Però sono davvero carenti dal punto di vista del supporto quando denunci problemi. E quindi li ho inseriti nell’elenco.

• 26496 Go daddy: un altro grosso nome storico nel campo dell’hosting in america, generalmente con un pessimo supporto clienti.

• 208046 Host Slick: hosting tedesco/olandese, non so molto di più.

• 7162 Universo Online: fornitore brasiliano di connettività e servizi web.

• 211252 Delis one: fornitore di servizi, superlosco, il cui dominio elencato nel profilo è SCADUTO. UN po’ in cina, un po’ in olanda, ma con base negli USA. Può decisamente stare lontano.

• 210228 Web hosted group: piccolo provider inglese. A me però ha infastidito.

• 212238 Datacamp: provider inglese, molti ip e pochi domini, fa pensare a diversi processi e pochi siti web. E comunque hanno cercato di violare i miei siti.

• 198375 Inulogic: fornitore francese. Non so molto di più.

Chi manca ?

• OVH Ovh è un fornitore gigantesco (4 milioni di IP e quasi 10 milioni di domini), tanto è che ho un server su di loro. Sto ancora cercando di capire se o quando tentare di bloccarli escludendo il mio server. Per ora non ho notato tentativi di intrusione o scraping.
• Google Cloud: è sicuramente l’altro grosso nome che manca. Io per ora non ho visto tentativi di attacco provenienti da Google, ma magari sono stato fortunato. In ogni caso prima di mettere blocchi, ricordatevi che l’ASN di Google Cloud finisce per includere Googlebot, quindi rischiate di bloccare Google dal vostro sito!

Personalizzatevi la regola

La incollo qua, potete inserirla cliccando su

• WAF
• nuova regola
• inserite un nome alla regola

• al posto delle condizioni cliccate su “Use Expression Builder” e incollate quanto segue:

• ….e cliccate nuovamente sul link per trasformare il contenuto in regole effettive
• applicate nella finestra in baso “Manage challenge”
• salvate!

E la barriera di livello 2?

Se siete arrivati fin qua con questo tarlo in testa, ottimo!

In sostanza, quello che è stato spiegato nella parte 2 rimane valido: le stringhe che identificano gli attacchi sono sempre utili per intercettare nuovi servizi.

Ma la differenza è evidente, guardate questi grafici delle ultime 24 ore di UN dominio.

Blocco tramite ASN

un CSR dello 0.23% sono i “veri utenti” che sono stati intercettati dalla regola. Il resto erano bot, scripts, scrapers, hackers, crawlers, etc.

Blocco tramite string

C’è una bella differenza no ?

ADDENDUM SEO

Attenzione alle regole, se finite per applicarle ad una GROSSA Massa di persone, con dispositivi reali, le metriche di UX di Google potrebbero peggiorare!

Ho la ragionevole certezza che Google conteggi il tempo che passa dal click dei risultati all’arrivo sulla pagina: viene trasmesso dallo spione Chrome, sopratutto sui dispositivi mobili.

Quindi andate sempre con cautela e in maniera progressiva.

Concludendo…

Una cosa è certa, è una battaglia senza fine, ma tramite Cloudflare si può combattere e contrastare una buona dose di questi attacchi.

Magari in futuro aggiornerò la regola con nuovi provider, sentitevi liberi di suggerirne altri!

If you have knowledge, let others light their candles in it. — Margaret Fuller

Photo by Rock’n Roll Monkey on Unsplash