Abbiamo già visto che prolifera come la gramigna una cultura, quella dell’ASAP, che ci vuole portare a buttare online secchi casuali di 1 e 0 in nome della celerità con cui si va sul mercato, a scapito della sicurezza e della robstezza del prodotto finale.

Debellarla è, come con la gramigna vera, una dura lotta. Mentre cerchiamo di sensibilizzare il committente che Roma non è stata costruita in un giorno, vediamo come evitarci qualche mal di testa quando dobbiamo lavorare per chi vuole tutto e subito.

Scenario

E’ arrivato il nuovo responsabile per il marketing che vuole essere aggressivo con il prodotto Scivolina, la sciolina per l’imbranato, e battere la concorrenza per il periodo invernale.

Nei primi di agosto convoca l’IT, convoca il Marketing ovviamente e qualche consulente outsourcer e spiega il suo piano geniale.

Entro ferragosto deve essere online un portale che permetta agli impianti sciistici di ordinare il nuovo prodotto.

“Una decina di giorni dovrebbe bastare per fare il sito, che ci vuole? In Internet si trova di tutto, figurati se qualcuno non ha fatto qualcosa di simile da copiare.”

A nulla vale far notare che, essendo agosto, la maggior parte delle persone è in vacanza. Il business non dorme mai.

Step backward

Come avrete notato, manca un attore nella convocazione iniziale. Non manca perché non c’è in azienda, ma manca perché nessuno sa che serve: il team di information security.

Se avete lavorato bene nelle puntate precedenti, IT o almeno chi materialmente installerà le macchine vi coinvolgerà. Se avete lavorato male, siete inguaiati.

Facciamo per un attimo l’assunzione che veniate coinvolti a progetto iniziato, quindi da 14 giorni (sabato e domenica sono sempre compresi nel grande mondo dell’ASAP) siamo già passati a 10 giorni dalla deadline, non prorogabile.

Buttate le fondamenta

Probabilmente stiamo parlando di un server web piazzato in una DMZ e protetto da un firewall. Questo server dovrà avere aperte le porte 80 e 443 per servire il sito anche su protocollo cifrato. Per l’accesso via SSH, ci sarà una seconda interfaccia sul server attestata su una rete di management opportunamente segregata in maniera tale da permette solo il traffico del sysadmin verso la porta 22. Supponiamo per semplicità che il database degli ordini per la Scivolina risieda fisicamente su questa macchina.

Accesso alla macchina

L’accesso SSH di root deve essere disabilitato. Gli amministratori si collegheranno con le loro utenze nominali e useranno sudo alla bisogna. La password degli utenti deve avere un minimo di criteri di robustezza. Password3, Sc1v0l1n4, S0n0R00t non sono password degne di tale nome. Sinceramente non sono un fan sfegatato di password come Rfd34$$a/dd!, perché credo che se obblighi i tuoi utenti a password assurde questi se le scriveranno da qualche parte.

Io sono della scuola di pensiero che una frase, un pezzo di una canzone abbiano poca entropia dal punto di vista computazionale ma siano molto più robuste di fronte ad un attacco a forza bruta.

Questa e’ Sparta

Provate con un password cracker a trovare un dizionario che includa anche questa… Non vi sentite sicuri, la vogliamo perturbare un po’?

Qu3St4 e’ Sp4Rt4

Ma veramente, una semplice frase (occhio alle lettere accentate) è facile da ricordare e difficile da trovare per un tool automatico.

Ordinaria amministrazione

Il server deve essere gestito. Questo vuol dire che se installate Apache, dovete gestirne il ciclo di vita; installare le patch proposte dal vendor, seguire le linee guida di hardening. Lo stesso vale per il sistema operativo, va aggiornato e mantenuto… un po’ come fate con la vostra auto, almeno una volta all’anno fate un controllo, no? Ecco, almeno una volta al mese va lanciato l’equivalente di:

$ sudo apt-get update
$ sudo apt-get upgrade

Tutte le distribuzioni Linux garantiscono la retrocompatibilità nelle API e nelle funzionalità di un tool quando, all’interno della stessa release ne propongono l’aggiornamento. Viene personi garantita la retrocompatibilità quando si cambia minor version della distribuzione. Aggiornare il proprio software è come fare il tagliando all’auto. E’ una cosa da fare. Punto.

Vulnerability management

Un post a parte meriterebbe il processo di gestione delle vulnerabilità, quindi daremo per scontato che abbiate un tool di scansione automatica, diciamo OpenVAS così citiamo quello opensource.

Il vostro tool di scansione automatica, regolarmente aggiornato, eseguirà un vulnerability assessment periodico sulla macchina e sarà vostra cura preparare un report con le principali azioni di mitigazione per chiudere le issue che saltano fuori volta per volta.

Indossiamo la lucente armatura

Descrizione

Quello che state per installare è un web application firewall, WAF per gli amici. Un WAF è qualcosa che si mette tra la vostra applicazione web e l’attaccante, intercetta le richieste che vengono fatte e fa passare solo quelle che non ricadono nelle regular expression che descrivono vettori di attacco noti.

Avvertenze (quelle che tutti saltano)

Installare un WAF non significa smettere di scrivere codice sicuro. Il WAF lavora applicando delle regular expression alle richieste che vengono fatte all’applicazione web. Non protegge da vulnerabilità legate alla logica applicativa, ad esempio. Potreste essere al sicuro dallo script kiddie che lancia sqlmap ma un attaccante più esperto potrebbe sempre trovare il vettore d’attacco che non è presente nella knowledge base.

Installare un WAF non significa smettere di scrivere codice sicuro.

Ha senso installare il WAF quindi? Bhé, fatto 100 tutti gli attacchi, almeno per un buon 90% ve ne potete dimenticare. Direi che ha senso.

E le performance? Noi siamo una startup giovane che fa il suo business innovativo nel cloud lanciando servizi social, per noi le performance sono tutto. Almeno il 90% di attacchi bloccati, e il vostro utente non si accorgerà di quei millisecondi in più che la foto del suo gattino viene sparata sui social.

mod_security

Installeremo mod_security dai sorgenti, quindi vi servono i tool per compilare codice C e le librerie di apache. Il nome dei pacchetti può variare da distribuzione a distribuzione, diciamo che vi serve:

• gcc
• make
• libxml2
• libxml2-devel
• httpd-devel
• pcre-devel
• curl-devel

mod_security è opensource e disponibile su github.com. Cloniamo il repository sul nostro server. E’ buona norma mettere tutto il software non pacchettizzato che viene installato nel sistema, in /usr/local. Creo una directory src nel caso non ci fosse, dove memorizzare i sorgenti.

Visto che dovete scrivere in /usr/local, dovete modificare la configurazione di Apache potete diventare root ora.

$ sudo bash

# mkdir -p /usr/local/src
# cd /usr/local/src
# git clone https://github.com/SpiderLabs/ModSecurity.git

E ora compiliamo mod_security.

# cd ModSecurity
# ./configure
# make
# make install

Abbiamo già, nell’archivio appena scaricato, un file di configurazione base che possiamo copiare nella directory della configurazione di apache. Va benissimo per partire.

# cp modsecurity.conf-recommended /etc/httpd/conf.d/modsecurity.conf

Ora dobbiamo dire ad Apache che mod_security è installato e che deve caricarlo come modulo.

# vim /etc/httpd/conf/httpd.conf

Dobbiamo assicurarci che nel file di configurazione, Apache carichi mod_security dopo le proprie dipendenze.

## Load dependencies ##
LoadFile /usr/lib/libxml2.so
LoadFile /usr/lib/liblua5.1.so
## Load mod_security ##
LoadModule security2_module modules/mod_security2.so

Riavviamo Apache ed avremo mod_security installato e funzionante con un set base di regole. Va bene per iniziare, ma vedremo subito come migliorare notevolmente le cose.

# /etc/init.d/httpd restart

Ora installiamo le Owasp Modsecurity core ruleset con un processo molto simile a quello usato per mod_security.

# cd /etc/httpd/
# git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git
# cd owasp-modsecurity-crs
# cp modsecurity_crs_10_setup.conf.example modsecurity_crs_10_config.conf

Con l’ultima riga abbiamo preparato il nostro file di configurazione da far caricare ad Apache. Non serve fare alcuna modifica, solo modificare ancora l’httpd.conf per istruire il modulo che deve caricare queste extra regole.

# vi /etc/httpd/conf/httpd.conf

...
<IfModule security2_module>
    Include owasp-modsecurity-crs/modsecurity_crs_10_config.conf
    Include owasp-modsecurity-crs/base_rules/*.conf
</IfModule>
...

Riavviamo Apache ed il nostro WAF è installato e pronto all’uso. Le regole preparate da OWASP mi garantiscono una buona protezione di base e di potermi dimenticare di buona parte degli attaccanti casuali là fuori.

Come abbiamo detto prima, ci sono attaccanti preparati là fuori quindi è obbligatorio aggiungere anche una parte di sviluppo sicuro ed eseguire un penetration test applicativo ed una code review prima del deploy in produzione.

# /etc/init.d/httpd restart

Off by one

Gli immancabili commenti: E ma non siamo una banca; Figurati, quelle cose degli hackers cattivi si vedono solo nei film; Ma chi vuoi che venga ad attaccarci; Il sito è sicuro, ha l’HTTPS

Se avete invece un programma di vulnerability management già in essere, potreste sentire qualcosa di più evoluto che ricalca il concetto assurdo che se una scansione viene fatta al tempo t0, non serva più farla neanche dopo anni e dopo innumerevoli modifiche al codice.

Ma non abbiamo fatto la scansione un anno fa?

A conti fatti, nessuno vuol fare application security se non dopo aver visto il proprio database su pastebin.com. A volte anche dopo aver subito un data breach, si fa spallucce tanto gli utenti hanno cambiato la password, un po’ come a dire… si arrangino un po’ questi utenti, perché devo fare lavoro extra?

No, la sicurezza del tuo business online è compito tuo e tuo solamente. Prendine atto e dillo anche a chi dice che quel sito doveva essere online ASAP.