Oggi parlo di Apache web server.
Dopo l’attacco subito a Giugno ho imparato sulla mia pelle che tutto ciò che è esposto su internet deve essere trattato con un occhio di riguardo.
Per quanto questa affermazione possa risultare a tutti gli addetti ai lavori scontata mi sono reso conto che i server Apache esposti, sebbene fossero sempre aggiornati, mostravano al pubblico una quota di possibili elementi sfruttabili da un attaccante.
Come sempre l’intento di questo post non è né quello di insegnare niente a nessuno né quello di fare un tutorial in quanto internet è pieno. Il mio scopo è sottolineare ciò che io ho fatto con la speranza che possa venir utile anche a te, magari dando qualche spunto di riflessione per le tue analisi di postura.
Prima di continuare è doveroso sottolineare che non tutte queste considerazioni possano fare al caso tuo: non sono regole incise nella pietra e prima di iniziare a fare modifiche è indispensabile che tu conosca alla perfezione le applicazioni ospitate sul tuo server di modo da poter configurare solo quelle che ti interessano e nella maniera più congeniale alle tue esigenze. Internet è pieno di tutorial e ho visto (e fatto l'errore in passato) che il trend di molti sysadmin è quello di copia-incollare direttive senza capire che costa effettivamente queste fanno. Questo approccio lo trovo personalmente sbagliato: il mio consiglio è quello di prendersi il proprio tempo per analizzare le proprie esigenze (e/o le proprie vulnerabilità) e successivamente operare nella pratica per realizzare i cambiamenti.
Detto ciò cominciamo.
1. Nascondere la versione di Apache e il sistema operativo sul quale è installato
Questo suggerimento non mitiga nessuna vulnerabilità ma evita che un attaccante possa reperire informazioni facilmente sulla configurazione del server rendendo così più ardua la fase di “information gathering”.
Prima
$ curl -I https://esempio.com
HTTP/2 200
Date: Fri, 23 Oct 2020 01:54:00 GMT
Server: Apache/2.4.10 (Debian)
x-powered-by: PHP/7.3.33
...
Azioni correttive
Nel file di configurazione di Apache (httpd.conf o apache2.conf – in base alla distribuzione in uso) ho aggiunto le direttive
ServerSignature Off
ServerTokens Prod
nel file di configurazione di PHP (php.ini) ho modificato la direttiva “expose_php” al valore “Off”
Dopo
$ curl -I https://esempio.com
HTTP/2 200
Date: Fri, 23 Oct 2020 01:54:00 GMT
Server: Apache
...
Altra opzione è quella di installare il modulo mod-security2, abilitarlo, editare il suo file di configurazione così:
ServerTokens Full
ServerSignature Off
SecServerSignature " "
Il risultato
$ curl -I https://esempio.com
HTTP/2 200
Date: Fri, 23 Oct 2020 01:54:00 GMT
Server:
2. Disabilitare il directory listing
Di default in Apache è abilitato e permette di visualizzare il contenuto delle directory del nostro sito. Io lo disabilito SEMPRE.
3. Rimuovere tutti i moduli che non sono necessari
Di default Apache installa ed abilita moltissimi moduli i quali possono essere causa di vulnerabilità (oltre che di impegno nel tenerli tutti aggiornati) quindi, come buona norma, la mia regola è: se non ti serve, rimuovi. Stesso discorso è applicabile alle “CGI execution”: se non servono (come nel mio caso) è meglio eliminarle.
4. Tieni sempre aggiornato il server
Si, lo so, è un consiglio banale ma basta farsi un giro su Shodan per vedere in giro che non è poi così scontato.
5. Installa i moduli mod_security e mod_evasive
mod_security funziona come firewall e permette di monitorare il traffico e a proteggere il server da attacchi di tipo “brute force”
mod_evasive lavora come anti DDoS associando una richiesta a un processo specifico. Questa viene analizzata e gestita di modo da identificare eventuali richieste multiple alla stessa risorsa in un arco di tempo ristretto o se un processo tenta di accedere contemporaneamente a “enne” risorse o se un gruppo di IP tentano di accedere in contemporanea a molte risorse uguali.
mod_evasive è uno strumento complesso: ne consiglio una lettura alla documentazione ufficiale.
6. Limitare la dimensione delle richieste HTTP
Per impostazione predefinita Apache non ha limiti alla dimensione totale della richiesta HTTP e, quando si consentono richieste di grandi dimensioni su un server web, è possibile che si possa essere vittima di attacchi Denial of Service. Possiamo limitare la dimensione delle richieste con la direttiva Apache “LimitRequestBody”.
7. Abilitare il loggin su ciascun virtual host
Banale? Si, forse. Ma oltre a salvare i log di traffico per eventuali analisi statistiche o per correggere errori di programmazione i log sono indispensabili per individuare gli attacchi in corso (Log4Shell è l’ultimo esempio di una corposa lista).
Altro consiglio: inviare i log a un SIEM ed abilitare le regole di analisi del traffico.
8. Dotarsi di un Web Application Firewall
Questo consiglio lo riporto anche nell’articolo scritto sull’analisi di postura.
Il principio che sta alla base è semplice: tutte le richieste entrano prima nella CDN dell’operatore con il quale avete sottoscritto il servizio, successivamente vengono analizzate da svariati controlli di sicurezza (CSFR, XSS, SQL injection, etc) ed infine, se il traffico viene considerato sicuro, inoltrato al vostro server.
Unica nota importantissima (che pochi fanno e che consiglio vivamente), nella regola di NAT in ingresso, andate ad impostare una white list con solo gli IP della CDN, non lasciate il traffico permesso da qualsiasi sorgente!
EOF