Vai al contenuto
Home » L’ASAP parte da solide fondamenta ed una lucente armatura

L’ASAP parte da solide fondamenta ed una lucente armatura

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 bancaFigurati, quelle cose
degli hackers cattivi si vedono solo nei filmMa chi vuoi che venga ad
attaccarciIl 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.

Tag:

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.