Proteggere un sito web senza spendere soldi

Questo articolo del blog lo dedico alle piccole aziende che, pur volendo, non hanno budget da dedicare alla sicurezza informatica. Parleremo infatti di come proteggere un sito web senza spendere soldi.

E’ inutile negarlo, la sicurezza costa. Hanno un prezzo le risorse tecnologiche e hanno un prezzo le risorse umane, ovvero gli esperti che ci aiutano a proteggere le nostre applicazioni.

Ma costa di più proteggere i nostri servizi o riparare un danno, causato per esempio da un’esfiltrazione o dalla perdita di dati? E se i dati persi o compromessi fossero quelli dei nostri clienti?

A riguardo apro una parentesi. Dal mio punto di vista le spese della sicurezza andrebbero catalogate tra i CAPEX, mentre purtroppo molte aziende, sia grandi che piccole, le intendono ancora come OPEX. Ragionatevi su anche voi 🙂

Indice dei contenuti

• Proteggere un sito web senza spendere soldi? La sicurezza costa
• Come possiamo proteggere il nostro sito senza spendere soldi?
• Blocchiamo gli attacchi DOS e DDOS con mod_evasive
• Come blocchiamo gli attacchi applicativi?
• Cos’è e come funziona il mod_security
• Bloccare bot, user agents, spider e crawler malevoli
• Conclusioni

Let’s go!

Proteggere un sito web senza spendere soldi? La sicurezza costa

Meglio (è solo un mio punto di vista, ma lo ritengo un dato di fatto) spendere per prevenire, piuttosto che spendere per provare a recupere qualcosa di recuperabile, forse, con estrema difficoltà e con enormi elargizioni economiche. Una famosa pubblicità recitava “Prevenire è meglio che curare”. Vogliamo dargli torto? Direi che questa frase calza alla perfezione anche in questo contesto.

Sempre dal mio punto di vista, non esiste risparmio che possa giustificare perdita di credibilità, fiducia e reputazione.

Gestire l’inevitabile per evitare l’ingestibile

Purtroppo però, non tutti hanno a disposizione grosse cifre da investire. Vuoi per impossibilità, vuoi per scelta (🤦 brividi lungo la schiena al solo pensiero). In alcuni casi il budget rasenta lo zero. I brividi mi hanno fatto pensare a una celebre frase di uno, se non il più famoso, hacker della storia:

“Chi non progetta la sicurezza, programma il fallimento”

Cit. Kevin Mitnick

Abbiamo quindi capito che molto spesso l’assenza di contromisure atte alla protezione dei nostri sistemi è causata da mancanza di fondi.

E se vi dicessi che possiamo fare qualcosa senza spendere un solo centesimo se non investire qualche ora di lavoro?

Come possiamo proteggere il nostro sito senza spendere soldi?

Entriamo nel vivo.

Molto, ma molto molto, brutalmente possiamo categorizzare 2 tipologie di attacco:

1. Attacchi di carico (Es DoS o DDoS), ovvero quando si cerca di mettere in difficoltà le risorse computazionali di un sito con l’obiettivo di renderlo indisponibile.
2. Attacchi che sfruttano vulnerabilità del server con l’obiettivo di rubarne dati, prenderne il controllo o comprometterlo.

Ovviamente la varietà di attacchi è ben più ampia rispetto a quanto elencato e questo articolo, altrettanto ovviamente, non vuole essere una trattato di sicurezza; tantomeno entrerà nella top ten dei testi di saggistica sulla sicurezza informatica. Prenderemo quindi in esame solo una piccola percentuale di possibili attacchi, ai quali proveremo a mettere un piccolo argine SENZA SPENDERE UN SOLO CENTESIMO.

E’ chiaro che quanto qui riportato non è la panacea dei mali della della sicurezza informatica sul web ma è senz’altro un buon punto di partenza, soprattutto se non si ha alcuna contromisura attiva. Della serie “è meglio averlo che non averlo”. 

Lo spirito di questo articolo, così come quello della mia newsletter qui su LinkedIn è sempre lo stesso, suscitare curiosità per approfondire e migliorare.

Blocchiamo gli attacchi DOS e DDOS con mod_evasive

Il mod_evasive è un modulo Apache che aiuta il tuo server a rimanere in esecuzione in caso di attacco. Come abbiamo detto i più comuni attacchi informatici si presentano sotto forma di Denial of Service (DoS), Distributed Denial of Service (DDoS) o tentativo di forza bruta il cui obiettivo è quello di sopraffare le performance del tuo, o tuoi, server. Nel caso in cui non abbiate il mod_evasive installato sulla vostra macchina, potete leggere il nostro articolo che spiega come installare il mod_evasive di Apache sulle distribuzioni Linux Debian, Ubuntu, CentOS e RedHat.

La natura di questi attacchi consiste nell’utilizzare diversi computer per effettuare richieste ripetute contro il tuo server. Ciò fa sì che il server esaurisca la potenza di elaborazione, la memoria o la larghezza di banda della rete e non sia più in grado di rispondere alle richieste.

Come funziona il mod_evasive e come ci aiuta a proteggere un sito web

L’utility mod_evasive di Apache funziona monitorando le richieste in ingresso al server e controllando le attività sospette dei singoli IP client.

Il mod_evasive controlla il numero di accessi al sito o a una singola pagina da parte di un determinato indirizzo IP e se vengono superate le soglie impostate, l’IP viene bloccato per un predeterminato periodo di tempo.

Nello specifico la configurazione prevede 5 metriche principali (più avanti troverete un esempio di configurazione):

• DOSBlockingPeriod è il periodo di tempo per il quale un IP verrà bloccato nel caso vengano superate le soglie sotto elencate. La configurazione prevede come valore un numero intero che rappresenta i secondi di blocco. Es. DOSBlockingPeriod 3600. Quando un IP supera le soglie verrà inserito in blacklist e riceverà un errore http 403 (access denied) per la durata dei secondi impostati in questa metrica.
• DOSPageCount è il numero di volte che un IP può visitare una singola pagina in un determinato arco temporale (DOSPageInterval). Il parametro si configura con un numero intero (es. 200 che rappresenta il numero di volte che una pagina può essere visitata).
• DOSPageInterval E’ l’intervallo di tempo entro il quale viene contato il numero di visite a una singola pagina (DOSPageCount) da parte di un singolo IP. Anche qui il parametro è un intero ed è espresso in secondi
• DOSSiteCount è il numero di pagine dell’intero sito che un IP può visitare in un determinato arco temporale (DOSSiteInterval). Il parametro si configura con un numero intero (es. 200 pagine del sito).
• DOSSiteInterval E’ l’intervallo di tempo entro il quale vengono contate le pagine del sito (DOSSiteCount) che un IP può visitare. Anche qui il parametro è un intero ed è espresso in secondi

Ecco un esempio di configurazione:

<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        2
    DOSPageInterval     5
    DOSSiteCount        50
    DOSSiteInterval     60
    DOSBlockingPeriod   3600
</IfModule>

Cosa succede con la configurazione qui riportata?

Un IP viene bloccato per 3600 secondi (DOSBlockingPeriod) se:

• Visita la stessa pagina del sito per più di 2 volte (DOSPageCount) in 5 secondi (DOSPageInterval)
• Il numero di pagine visitate (non importa quali) è superiore a 50 (DOSSiteCount) in un arco temporale di 60 secondi (DOSSiteInterval). 

Gli IP che incappano in una di queste due casistiche vengono bloccati e inseriti in una blacklist. Per impostazione predefinita, questo include anche un periodo di attesa di 10 secondi nella lista nera. Se l’indirizzo IP che effettua la richiesta riprova in quella finestra di 10 secondi, il tempo di attesa aumenta. Come detto precedentemente, i clienti in blacklist ricevono una risposta http 403.

Chiaramente questi parametri vanno configurati con attenzione o rischierete di avere una miriade di clienti bloccati che ricevono un http 403 anziché un 200. Il consiglio che mi sento di darvi è quello di analizzare il vostro analytics (o ELK se disponibile) per capire il comportamento dei vostri clienti clusterizzando almeno il 95% di essi in modo da avere percezione della loro navigazione. Se il 95% dei vostri clienti visita 30 pagine in 5 minuti, e visita solo 2 volte la stessa pagina in 1 minuto, potreste utilizzare queste informazioni per adattare la configurazione, che potrebbe diventare una cosa simile a:

<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        4
    DOSPageInterval     1
    DOSSiteCount        50
    DOSSiteInterval     300
    DOSBlockingPeriod   3600
</IfModule>

Il periodo di tempo per il quale l’IP resta bloccato è una vostra scelta.

Tornando alle configurazioni, ne esistono anche altre opzionali:

    DOSEmailNotify	[email protected]
    DOSSystemCommand	"su - someuser -c '/sbin/... %s ...'"
    DOSLogDir		"/var/lock/mod_evasive"
    DOSWhitelist="10.60.0.7,10.65.0.10" 

L’obiettivo di questo articolo è mettervi a conoscenza delle risorse che abbiamo a disposizione, quindi non vi spiegherò come si istalla il mod_evasive. Di manuali che parlano di compilazione e istallazione ce ne sono centinaia su internet. A tal proposito vi risparmio almeno la noia di cercare e vi lascio un paio di link utili relativamente proprio all’istallazione del mod_evasive:

• Install mod_evasive on Ubuntu
• Install mod_evasive on CentOS

Come blocchiamo gli attacchi applicativi?

Finora abbiamo parlato del blocco degli attacchi volumetrici, senza entrare nel dettaglio del contenuto dei pacchetti che arrivano sul server.

Una tipologia di attacco, diversa dal DoS o dal DDoS, è quella applicativa, che, anziché sfruttare grossi volumi di traffico, sfrutta vulnerabilità nella configurazione del server o dell’applicativo o del middleware per “entrare” nel server. Questa tipologia di attacco è molto più insidiosa rispetto a un attacco di tipo DoS o DDoS in quanto può essere svolta a bassi volumi di traffico, senza impatti su CPU o memoria, per cui risulta più difficile da individuare.

Alcuni esempi di attacco applicativo sono l’XSS (Cross Site Scripting),l’SQL Injection o il Session Hijacking. Ne esistono migliaia; quanto elencato è nulla rispetto a quelli disponibili.

Il modo migliore per bloccare questa tipologia di attacchi è quella di implementare sul nostro Apache un modulo chiamato mod_security.

Cos’è e come funziona il mod_security

ModSecurity altro non è che un WAF (Web Application Firewall) open source e multipiattaforma per Apache, IIS e Nginx. Dispone di un robusto linguaggio di programmazione basato su eventi, che fornisce protezione da una serie di attacchi sferrati contro le applicazioni Web e consente il monitoraggio del traffico HTTP, la registrazione e l’analisi in tempo reale.

Per rilevare le minacce, il motore ModSecurity viene distribuito integrato nel server Web o come server proxy davanti a un’applicazione Web (approfondiremo queste differenze più avanti). Ciò consente al motore di eseguire la scansione delle comunicazioni HTTP in entrata e in uscita verso l’endpoint. A seconda della configurazione della regola, il motore deciderà come gestire le comunicazioni. Nelle regole è infatti possibile configurare la possibilità di far passare la chiamata, eliminarla, reindirizzarla, restituire un determinato codice HTTP, eseguire uno script e altro ancora.

Uno dei motivi per cui ModSecurity è popolare tra gli ISP e i proprietari di siti è perché ti consente di decidere quali funzionalità sono importanti per te e ti consente di abilitarle e disabilitarle a piacimento attraverso il caricamento di alcune regole. Blocca molti degli attacchi più comuni e funziona anche se il proprietario del sito non è a conoscenza di come sfruttare una determinata vulnerabilità.

Le regole per ModSecurity possono essere scaricate e installate, ma gli amministratori possono anche creare regole proprie. Queste regole definiranno il modo in cui un server web si comporterà rispetto alle richieste ricevute. La configurazione delle regole di ModSecurity è fondamentale per la protezione dei dati e, senza di esse o con una configurazione errata, l’applicazione Web potrebbe essere sfruttata utilizzando una qualunque delle numerose vulnerabilità note.

La protezione si attiva abilitando il modulo sul nostro apache e richiamando una serie di files che contengono le regole desiderate.

Poiché ModSecurity è un WAF, le regole coprono la maggior parte della Top 10 di OWASP.

Anche in questo caso vi lascio un link utile al setup e alla configurazione di mod_security . 

Bloccare bot, user agents, spider e crawler malevoli

Sai che per proteggere un sito web, una delle prime cose da fare è bloccare i bot e gli user agent indesiderati, anche detti cattivi? Questo perchè molti strumenti di attacco “pronti all’uso” uso degli User Agents noti.

Una prima protezione in tal senso, molto semplice da applicare è attuabile tramite una semplice riga di configurazione di Apache. A tal riguardo vi invito a leggere la nostra guida su come bloccare i bot su Apache con mod_rewrite.

Configurazioni avanzate

Finora abbiamo parlato soltanto di teoria. Ma proviamo a entrare un po’ più nel dettaglio, con qualche grafico e qualche simulazione, di ciò che abbiamo fin qui descritto. Vediamo cosa succede in Figura 1. Abbiamo un load balancer che bilancia il traffico su tre server che ospitano sia il mod_evasive che il mod_security. E’ vero che sui nostri server abbiamo sia il mod_security che il mod_evasive, ma il traffico è comunque arrivato sul nostro server e per bloccarlo devi pur sempre prima analizzarlo. Ma se il nostro attaccante facesse un attacco, insieme a un migliaio di suoi amici? Saremmo di fronte a un attacco di tipo DDoS. Il server prima di bloccare quelle chiamate, deve mapparle sulle sue regole del mod_evasive e solo una volta che le regole saranno scattate inizierà a bloccare i primi IP. Troppo tardi. Il traffico ormai è arrivato sui server che ospitano la nostra applicazione.

Facciamo un passo avanti e proviamo a trovare una prima soluzione.

Nella figura 2 i server che espongono l’applicazione (che sono gli ultimi 3 sulla destra) sono protetti da altre 2 istanze Apache che NON ospitano l’applicazione e i cui unici compiti sono:

1. Ospitare le istanze di mod_evasive
2. Ospitare le istanze mod_security
3. Fare da proxy, per le chiamate “buone” verso i webserver che ospitano l’applicazione

Con questa configurazione il traffico generato dal nostro hacker è stato bloccato prima di arrivare dove risiede la nostra applicazione. Chiaramente le 2 macchine (ne ho inserite due per assicurare un minimo di HA) che fanno da proxy devono essere sufficientemente carrozzate per reggere una più che modesta mole di traffico, nel caso in cui si trovassero ad affrontare un attacco di Tipo DoS o derivati.

Questa configurazione forse è la migliore da adottare rispetto alle opzioni precedenti, anche se richiede l’utilizzo di 2 server aggiuntivi; non dovete necessariamente acquistarli. Se siete on-premise potete benissimo riciclare qualcosa che magari non usate più. Se invece siete in cloud, allora è probabile che il vostro provider abbia già qualcosa di pronto da offrirvi …. continuate a leggere 🙂

Seppur migliorativa, quella appena descritta non è necessariamente la via maestra, anzi.

Come spesso succede nell’informatica le vie da seguire sono molteplici e a me piace sempre fare un passo avanti. Looking forward …

Soluzioni alternative e ottimizzazione delle performance

Abbiamo basato gli argomenti fin qui trattati sul fatto che i proxy (Figura 2) a protezione delle nostre Web Applications siano degli Apache httpd.

In realtà, come molti di voi sanno, Apache httpd server non è proprio un fulmine di guerra, sia come proxy che come webserver. Ne esistono altri, sempre open source, ma molto più light e performanti. Parliamo di nginx e di Envoy. Non li abbiamo presi come esempio iniziale in quanto entrambi supportano mod_security, me nessuno dei 2 supporta mod_evasive che è modulo dedicato di Apache.

Chi mi conosce sta che sono un po’ nerd. Mi sono quindi messo alla ricerca di qualcosa che avesse le stesse caratteristiche dei moduli di cui abbiamo parlato in questa pagine, e che possa essere utilizzato con prodotti più performanti come nginx ed Envoy, introdotti poco fa.

Curiefense is integrated with NGINX and Envoy proxy. It blocks hostile traffic from sites, services, microservices, containers, service meshes, and more.

Tra le features offerte vengono elencate le seguenti:

• Web Application Firewall
• Application-Layer DDoS Protection
• Advanced Rate Limiting
• API Security
• DevOps
• Logging and Real-Time Reporting
• Threat Feeds

Sembra proprio coprire ampliamente le casistiche discusse finora.

Per il momento non ho avuto modo di istallarlo. Spero di trovarne nelle prossime settimane perché mi ha incurioso e voglio capire meglio se fa veramente ciò che promette.

Se qualcuno di voi l’avesse testato, sarebbe utile un feedback a riguardo, anche nei commenti.

Next step, WAF in SaaS per proteggere un sito web

In questo articolo abbiamo nominato più volte il termine WAF, ovvero Web Application Firewall, senza ben specificare cosa sia, come funzioni e in quali modalità si può usare.

E se vi dicessi che ce ne sono alcuni completamente gratuiti e che si possono utilizzare in SaaS, quindi senza istallare virtual machines, senza dover compilare e senza scrivere una sola riga di codice? Sapete inoltre che potremmo gestire tutto ciò di cui abbiamo parlato finora, da una semplice GUI? Sapete inoltre che i WAF in SaaS più famosi si possono configurare per bloccare sia attacchi applicativi che attacchi volumetrici?

Per rendere l’idea, quella in Figura 3 è l’architettura classica di un WAF in SaaS.

Non voglio darvi ulteriori informazioni a riguardo. Non approfondiremo l’argomento WAF qui perché sarà il soggetto a cui sarà dedicato una delle prossime pubblicazioni di questa newsletter.

Conclusioni

Spero prenderete questi contenuti come spunto di approfondimento e, per i meno esperti, spero servano a spronarvi per imparare qualcosa di nuovo.

Cosa ne pensate dell’articolo? Mi piacerebbe avere la vostra opinione nei commenti.

Il confronto è sempre costruttivo.

I wish you a funny job

Fabio Iegri

Vi lascio il link della mia newsletter qualora vogliate iscrivervi: https://www.linkedin.com/newsletters/web-in-cloud-6945274376917274624/

Questo articolo è stato pubblica sulla suddetta newsletter il 27 luglio 2022 ed è raggiungibile al seguente link: https://www.linkedin.com/pulse/sec-proteggere-un-sito-web-senza-spendere-soldi-fabio-iegri/