Mettere in sicurezza Web Server Apache è una operazione di fondamentale importanza, dato che questo è molto spesso uno dei servizi più vulnerabile ad attacchi. Data la configurazione di default, molte informazioni sensibili possono essere sfruttate da un hacker per preparare un attacco all’intero web server.

La maggior parte delle applicazioni web vengono attaccate tramite XSS, furto di credenziali, sfruttamento malevolo delle sessioni e PHP Injection, attacchi che sono resi possibili proprio dalla debolezza del codice di programmazione e dalla incapacità di “sanificare” l’infrastruttura delle applicazioni web.

Stando a Cenzic, ben il 96% delle applicazioni testate presenta delle vulnerabilità; sotto è possibile visionare un grafico di Cenzic relativo ai trend di vulnerabilità del 2013.

Questa guida pratica ha come scopo proprio quello di fornire una serie di indicazioni necessarie per mettere in sicurezza web server Apache. Nel dettaglio, si discuterà di come rafforzare e rendere più sicuro un web server Apache su piattaforma Unix, con test eseguiti su Apache 2.4x (non c’è ragione di pensare che non funzionino su Apache 2.2x).

1. Si presuppone che Apache sia installato su piattaforma Unix. Se non è così, è possibile procedere all’installazione grazie alla Installation Guide o visionare una serie di video gratuiti relativi all’installazione di Apache, MySQL e PHP.
2. L’installazione di Apache sarà identificata con il nome di directory /opt/apache as $Web_Server
3. Si consiglia di fare un backup della configurazione esistente prima di procedere a qualunque modifica

Questa guida si indirizza agli amministratori, agli analisti di sistema e in generale a tutti coloro che desiderano mettere in sicurezza un web server Apache (è comunque necessaria una conoscenza di base sia di Apache che di Unix).

La sicurezza di un web server Apache: inizia dal controllare HTTP

Nella configurazione di default di Apache sono coinvolti molti dati sensibili che possono essere sfruttati per sferrare un attacco al web server. E’ quindi fondamentale per ogni amministratore mettere in sicurezza queste informazioni; come riportato da Cenzic, infatti, ben il 16% delle vulnerabilità è dovuta alla perdita di informazioni.

Per esaminare l’intestazione HTTP per la verifica sono necessari alcuni tool. La prima cosa da fare è quindi installare l’add-on Firebug su Firefox nel seguente modo:

• Aprire Firefox
• Accedere a https://addons.mozilla.org/en-US/firefox/addon/firebug/
• Cliccare su Aggiungi a Firefox

• Cliccare su installa
• Riavviare Firefox
• A questo punto è visibile l’icona di Firebug sulla destra della top bar

Per verificare le informazioni dell’intestazione HTTP è necessario cliccare sull’icona di Firebug. Oltre a questo ci sono molti altri tool online che consentono di verificare le informazioni dell’intestazione HTTP.

Per la sicurezza web server Apache, rimuovere la versione del server utilizzata

Si tratta di una delle prime cose da considerare se non si desidera mostrare quale versione del web server si sta utilizzando; mostrare quale versione è installata non fa altro che accorciare i tempi di un attacco hacker. La configurazione di default mostra la versione Apache e il tipo di sistema operativo come di seguito:

Server Apache/2.4.6 (Unix)

Implementazione:

• Andare su  $Web_Server/conf folder
• Modificare httpd.conf tramite vi editor
• Aggiungere la seguente direttiva e salvare httpd.conf

ServerTokens Prod

ServerSignature Off

• Riavviare Apache

ServerSignature rimuoverà le informazioni dal web server Apache generando pagine come 403,404.502 etc.

Verifica:

• Aprire Firefox
• Attivare Firebug cliccando l’icona dell’add-on
• Cliccare il tab Net

• Inserire l’URL nella barra degli indirizzi
• Espandere la GET request e a questo punto è possibile vedere che nella direttiva del server viene solo mostrato Apache, che è certamente meglio che mostrare il tipo e la versione del sistema operativo

Disabilitare la lista delle directory browser per la sicurezza del web server Apache

E’ molto importante disabilitare la lista delle directory nel browser di modo che non sia possibile per ogni visitatore vedere tutti i file e le cartelle archiviate nella cartella di root e nelle sottocartelle. Vediamo come questo appare nelle impostazioni di default:

• Andare su $Web_Server/htdocs directory
• Creare una cartella con alcuni file all’interno

# mkdir test

# touch hi

# touch hello

Ora proviamo ad accedere ad Apache tramite http://localhost/test

Come si vede vengono mostrate tutte le cartelle e i file, informazioni che di certo non si desidera mostrare.

Implementazione:

• Andare su $Web_Server/conf directory
• Aprire httpd.conf using vi
• Cercare una directory e modificare le opzioni None o –Indexes

<Directory /opt/apache/htdocs>

Options None

Order allow,deny

Allow from all

</Directory>

oppure

<Directory /opt/apache/htdocs>

Options -Indexes

Order allow,deny

Allow from all

</Directory>

• Riavviare Apache

Da notare, se vi sono delle directory multiple nel sistema, bisogna considerare di ripetere l’operazione per ognuna di esse.

Verifica:

Proviamo ad accedere ad Apache da http://localhost/test

Come si vede viene mostrato un “forbidden error” invece che la lista delle cartelle

Per la sicurezza web server Apache nascondi Etag

Etag header permette agli hacker di ottenere informazioni importanti come inode number, multipart MIME. Per prevenire queste vulnerabilità, bisogna procedere come di seguito.

Implementazione:

• Andare su $Web_Server/conf directory
• Aggiungere la seguente direttiva e salvare https.conf

FileETag None

• Riavviare Apache

Verifica

• Aprire Firefox e accedere all’applicazione
• Controllare l’intestazione HTTP in Firebug, Etag non sarà più visibile a tutti

Sicurezza di un web server Apache: controlla le autorizzazioni

Esaminiamo il caso di avviare Apache da un account senza privilegi. La configurazione di default di Apache viene eseguita come “nessuno” o “daemon”. E’ una buona pratica usare un account senza privilegi separato per Apache, così da proteggere tutti gli altri servizi nel caso vi siano delle faglie di sicurezza.

Implementazione:

• Creare un utente o un gruppo chiamato apache

#groupadd apache

# useradd –G apache apache

• Cambiare la propria directory di installazione apache al nuovo utente senza privilegi

# chown –R apache:apache /opt/apache

• Andare su $Web_Server/conf
• Modificare https.conf using vi
• Cercare l’utente e il gruppo di direttive e modificare come account apache senza privilegi

User apache

Group apache

• Salvare https.conf
• Riavviare Apache

Verifica

Usare il comando grep per l’esecuzione del processo http e assicurarsi che sia in esecuzione con l’utente apache

# ps –ef |grep http

Si noti che un processo è in esecuzione su root e questo perché Apache è su porta 80 e deve essere avviato da root. In seguito vedremo come cambiare il numero della porta.

Per la sicurezza web server Apache proteggi i permessi di configurazione directory

Di default i permessi binari e di configurazione sono di tipo 755 il che significa che ogni utente sul server è in grado di vedere la configurazione. Modifichiamo questo dato:

Implementazione

• Andare su $Web_Server directory
• Modificare i permessi per la cartella bin e conf

# chmod –R 750 bin conf

Verifica:

Attenzione alle impostazioni di protezione del sistema per la sicurezza del web server Apache

In un’installazione di default, gli utenti possono ignorare la configurazione di Apache utilizzando .htacces. Se si vuole impedire agli utenti la modifica delle impostazioni del server Apache, allora è possibile aggiungere AllowOverride a None come mostrato sotto ( questo deve essere fatto a livello root).

Implementazione:

• Andare su $Web_Server directory
• Aprire httpd.conf using vi
• Cercare la directory a livello root

<Directory />

Options -Indexes

AllowOverride None

</Directory>

• Salvare https.conf
• Riavviare Apache

Metodi di richiesta HTTP e sicurezza web server Apache

Il protocollo HTTP 1.1 supporta molti metodi di richiesta (query) che potrebbero non essere necessari, senza contare che alcuni di essi hanno dei potenziali rischi. In genere si ha bisogno solo dei metodi di richiesta GET, HEAD, POST in un’applicazione web, da configurare nelle rispettive directory. Di default la configurazione apache supporta anche i metodi OPTIONS, GET, HEAD, POST, PUT, DELETE, TRANCE, CONNECT per il protocollo HTTP 1.1

Implementazione

• Andare su $Web_Server directory
• Aprire httpd.conf using vi
• Cercare la  directory e aggiungere

<LimitExcept GET POST HEAD>

deny from all

</LimitExcept>

Sicurezza web server Apache: disabilitare la traccia di una richiesta HTTP

Di default il metodo “Trace” è attivo sul web server Apache. Mantenerlo attivato significa favorire attacchi Cross Site Trancing e potenzialmente significa anche dare una possibilità agli hacker di rubare informazioni sensibili dai cookie. Vediamo quindi come appare nella configurazione di default:

• Fare un IP telnet web server con una porta di ascolto
• Fare una richiesta Trace come mostrato di seguito

#telnet localhost 80

Trying 127.0.0.1…

Connected to localhost.

Escape character is ‘^]’.

TRACE / HTTP/1.1 Host: test

HTTP/1.1 200 OK

Date: Sat, 31 Aug 2013 02:13:24 GMT

Server: Apache

Transfer-Encoding: chunked

Content-Type: message/http 20

TRACE / HTTP/1.1

Host: test 0

Connection closed by foreign host.

#

Come si vede, la richiesta Trace ha risposto alla query; vediamo come disabilitarlo e testarlo.

Implementazione:

• Andare su $Web_Server/conf directory
• Aggiungere la seguente direttiva e salvare httpd.conf

TraceEnable off

• Riavviare Apache

Verifica:

• Fare un IP telnet web server con una porta di ascolto e fare una richiesta Trace come di seguito

#telnet localhost 80

Trying 127.0.0.1…

Connected to localhost.

Escape character is ‘^]’.

TRACE / HTTP/1.1 Host: test

HTTP/1.1 405 Method Not Allowed

Date: Sat, 31 Aug 2013 02:18:27 GMT

Server: Apache Allow:

Content-Length: 223

Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”> <html><head> <title>405 Method Not Allowed</title> </head><body> <h1>Method Not Allowed</h1>

<p>The requested method TRACE is not allowed for the URL /.</p> </body></html>

Connection closed by foreign host.

#

Come si vede la richiesta Trace ha bloccato la richiesta con HTTP 405 Method Not Allowed. Ora questo web server con consente la richiesta Trace e aiuta a bloccare gli attacchi Cross Site Tracing.

Impostare i cookie con HttpOnly and Secure Flag per la sicurezza web server Apache

E’ possibile limitare buona parte degli attacchi Cross site Scripting usando HttpOnly and Secure Flag nei cookie. Senza HttpOnly and Secure è possibile rubare o manipolare le sessioni delle applicazioni web e i cookie, possibilità abbastanza pericolosa.

Implementazione:

•   Garantire mod_headers.so ATTIVO httpd.conf
• Andare su $ server_web directory / conf
• Aggiungere la seguente direttiva e salvare il httpd.conf

 Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

• Riavviare Apache

Verifica:

• Aprire Firefox e accedere all’applicazione
• Verificare le intestazioni di risposta HTTP in Firebug; si vedrà che Set-Cookie è contrassegnato con HttpOnly and Secure come mostrato di seguito:

 Sicurezza del web server Apache: proteggersi dagli attacchi Clickjacking

Clickjacking è una vulnerabilità molto conosciuta delle applicazioni web. Un attacco di questo tipo porta l’utente che clicca su un oggetto, ad essere redirezionato verso un’altra destinazione.

Implementazione:

• Garantire mod_headers.so ATTIVO httpd.conf
• Andare su  $ server_web directory / conf
• Aggiungere la seguente direttiva e salvare il httpd.conf

Header always append X-Frame-Options SAMEORIGIN

• Riavviare Apache

Verifica:

• Aprire Firefox e accedere all’applicazione
• Verificare le intestazioni di risposta HTTP in Firebug; si vedrà X-Frame-Options come di seguito

Server Side Include per la sicurezza web server Apache

Server Side Include (SSI) comporta il rischio di aumentare il carico sul server. Se l’ambiente è condiviso e si ha un traffico pesante delle applicazioni web, si potrebbe considerare di disabilitare SSI aggiungendo la direttiva Includes in Options. Gli attacchi SSI permettono di sfruttare le applicazioni web iniettando uno script nelle pagine HTML o eseguendo un codice da remoto.

Implementazione:

• Andare su $ server_web directory / conf
• Aprire httpd.conf using vi
• Ricercare la directory e aggiungere la direttiva Includes in Options

<Directory /opt/apache/htdocs>

Options –Indexes -Includes

Order allow,deny

Allow from all

</Directory>

• Riavviare Apache

Si noti che se vi sono più directory è necessario ripetere il processo per ognuna di queste.

Protezione X-XSS per la sicurezza web server Apache

La protezione Cross Site Scripting (XSS) può essere bypassata in molti browser. E’ possibile applicare questa protezione per le applicazioni web se l’user è stato disabilitato. Questo sistema è utilizzato da grande compagnie come Facebook, Twitter, Google etc.

Implementazione:

• Andare su  $ server_web directory / conf
• Aprire httpd.conf using vi e aggiungere la seguente direttiva Header

Header set X-XSS-Protection “1; mode=block”

• Riavviare Apache

Verifica:

• Aprite Firefox e accedere all’applicazione
• Controllare le intestazioni di risposta HTTP in Firebug, si dovrebbe vedere che XSS Protection è abilitato e una modalità è bloccata.

Disabilitare il Protocollo HTTP 1.0

Quando si parla di sicurezza è indispensabile proteggere tutto quello che si può. Quindi perché utilizzare la vecchia versione del protocollo HTTP? E’ possibile disattivarla usando il modulo the mod_rewrite.

Implementazione:

• Assicurarsi di caricare il modulo mod_rewrite nel file httpd.conf
• Abilitare la direttiva RewriteEngine come segue e aggiungere la condizione Rewrite per consentire solo HTTP 1.1

RewriteEngine On

RewriteCond %{THE_REQUEST} !HTTP/1.1$

RewriteRule .* – [F]

Per la sicurezza web server Apache configurare il valore Timeout

Di default il valore di Timeout di Apache è di 300 secondi, il che può rendere il server vittima di attacchi Slow Loris o DoS. Per prevenirli è possibile ridurre il valore del Timeout a circa 60 secondi.

Implementazione:

• Andare su  $ server_web directory / conf
• Aprire httpd.conf using vi
• Aggiungere il  Timeout 60 in httpd.conf

Dotarsi di SSL per la sicurezza web server Apache

Attivare la tecnologia SSL significa avere un ulteriore livello di protezione che si può aggiungere alle applicazioni web. Tuttavia la configurazione di default di SSL comporta alcune vulnerabilità ed è quindi opportuno modificare queste configurazioni. Usiamo allora alcuni tool per verificare le impostazioni SSL. Ve ne sono molti disponibili, tuttavia è possibile usare uno strumento gratuito come SSL-Scan.

Sicurezza web server Apache e SSL Key

Violare una chiave SSL è difficile ma non impossibile. E’ infatti solo una questione di tempo e di tentativi. Ad esempio, usando un PC del 2009 e tentando per circa 73 giorni è possibile decodificare addirittura una chiave 512 bit. La maggior parte delle grandi aziende web utilizza ormai un chiave a 2048 bit. Facciamolo anche noi.

Implementazione:

• E’ possibile usare openssl per generare CSR con 2048 bit come di seguito
• Generare un certificato auto-firmato

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout localhost.key -out localhost.crt

• Generare una nuova CSR e chiave privata

openssl req -out localhost.csr -new -newkey rsa:2048 -nodes -keyout localhost.key

• Aggiungere Personal Cert, Signer Cert e il file Key nel file httpd-ssl.conf come di seguito:

SSLCertificateFile # Personal Certificate

SSLCertificateKeyFile # Key File

SSLCACertificateFile # Signer Cert file

Verifica:

Eseguire sslscan utility con il seguente parametro. Modificare localhost all’attuale nome dominio.

sslscan localhost | grep –i key

• Come si vede l’attuale chiave SSL è 2048 bit, che è decisamente più forte

SSL Cipher per la sicurezza web server Apache

La crittografia è il processo che consente di convertire i testi in codici segreti cifrati. SSL Cipher è un ottimo algoritmo di crittografia che si basa su due chiavi di sicurezza. Vediamo come implementarlo.

Modificare localhost all’attuale nome dominio.

sslscan –no-failed localhost

In una installazione classica vengono accettati i protocolli DHE, AES, EDH, ed RC4, quest’ultimo un sistema di cifratura abbastanza debole, che non dovrebbe essere utilizzato. In generale non bisognerebbe accettare alcun sistema di cifratura inferiore ai 128 bit.

Implementazione:

• Andare alla cartella $ server_web / conf / extra
• Modificare la direttiva SSLCipherSuite in httpd-ssl.conf come di seguito per respingere RC4

 SSLCipherSuite HIGH:!MEDIUM:!aNULL:!MD5:!RC4

• Salvare il file di configurazione e riavviare il server Apache

Si noti che se vi sono molti cipher deboli nel report di SSL allora è possibile respingerlo aggiungendo ! all’inizio.

Per esempio per respingere RC4: !RC4

Verifica: Utilizzare di nuovo l’utility sslscan per validare come di seguito e cambiare localhost al nome dominio attuale.

sslscan –no-failed localhost

RC4 non è più accettato come Cipher. E’ buona pratica rigettare tutti i cipher bassi, medi o nulli per proteggersi da attacchi. E’ anche possibile verificare il proprio dominio con Qualys SSL Labs  per controllare se vi sono dei cipher vulnerabili nel sistema.

Per la sicurezza web server Apache disabilitare SSL v2 e v3

SSL v2 e v3 hanno molte falle di sicurezza e se si esegue un test di penetrazione si vedrà come sia necessario disabilitarli per rafforzare la sicurezza. Tutte le comunicazioni SSL v2/v3 possono essere vulnerabili a attacchi Man-in-The-Middle che potrebbero compromettere o divulgare i dati.

Vediamo come implementare il web server Apache in modo che accetti solo le ultime TLS e rifiuti la richiesta di connessione SSL v2/v3.

Implementazione

• Andare alla cartella $ server_web / conf / extra
• Modificare la direttiva SSLProtocol in httpd-ssl.conf come di seguito per accettare solo TLS 1.0+

 SSLProtocol –ALL +TLSv1 +TLSv1.1 +TLSv1.2

Verifica:

Usiamo l’utility sslscanper validare il seguente comando e modificare localhost all’attuale nome dominio.

sslscan –no-failed localhost

In alternativa, è possibile controllare il sito con il tool online SSL/TLS Certificate

Utilizzare Mod Security per la sicurezza web server Apache

Mod Security è un’applicazione Firewall opensource che può essere utilizzata con Apache. Si tratta di un modulo che è necessario compilare e installare. Nel caso in cui non sia possibile permettersi un’applicazione firewall commerciale, questo modulo può essere una buona scelta.

Mod Security dice: per garantire una protezione generica delle applicazioni web, il Core rules deve utilizzare le seguenti tecniche:

• HTTP Protection: rilevare le violazioni del protocollo HTTP e  definire un utilizzo della policy localmente
• Real-time Blacklist Lookups: utilizzare 3rd Party IP Reputation
• Web-based Malware Detection: identificare i contenuti web dannosi controllando Google Safe Browsing API
• HTTP Denial of service Protections: difendersi dagli attacchi HTTP Flooding and Slow HTTP DoS
• Common Web Attacks Protection: – rilevare i comuni attacchi alla sicurezza delle applicazioni web
• Automation Detection: Rilevare  bot, crawler, scanner e altre attività dannose
• Integrare con AV Scanning per il caricamento di file: rilevare i file maligni caricati tramite l’applicazione web.
• Monitoraggio dei dati sensibili: Tracciare l’uso delle carte di credito e bloccare le perdite
• Trojan Protection: Rilevare l’accesso ai cavalli di Troia
• Identificare i difetti delle applicazioni: Segnalazioni di errori di configurazione delle applicazioni
• Error Detection and Hiding: Mascherare i messaggi di errore inviati dal server.

Verificare i download e le installazioni per la sicurezza web server Apache

I seguenti prerequisiti devono essere installati sul server nel caso in cui si desideri utilizzare Mod Security con Apache. Se alcuni di essi non sono presenti la compilazione di Mod Security è destinata a fallire. E’ possibile utilizzare l’installazione yum o Linux o Cento per installare questi pacchetti:

• apache 2.xo superiore
• pacchetto libpcre
• pacchetto libxml2
• pacchetto liblua
• pacchetto libcurl
• libapr e pacchetto libapr-util
• Modulo mod_unique_id bundle con server web Apache

Ora, cerchiamo di scaricare l’ultima versione di Mod Security 2.7.5 da http://www.modsecurity.org/download/

• Trasferire il  file scaricato in / opt / apache

• estrarre modsecurity-apache_2.7.5.tar.gz

# gunzip –c modsecurity-apache_2.7.5.tar.gz | tar xvf –

• Andare a extracted folder modsecurity-apache_2.7.5

# cd modsecurity-apache_2.7.5

• Avviare lo script di configurazione includendo apxs path a Apacheù

# ./configure –with-apxs=/opt/apache/bin/apxs

• Compilare e installare con make script

# make

#make install

• Una volta che l’installazione è completa si vedrà mod_security2.so nella cartella moduli sotto /opt/apache come di seguito

A questo punto Mod Security è installato sul web server Apache

Configurazione del Mod Security per la sicurezza web server Apache

Per utilizzare Mod Security su Apache, è necessario caricare Mod Security in http.conf. Il modulo mod_unique_id è pre-requisito per Mod Security. Questo modulo fornisce un’ambiente variabile con un identificatore unico per ogni richiesta che viene monitorata e utilizzata da Mod Security.

• Aggiungere di seguito una riga per caricare il modulo per lMod Security in httpd.conf e salvare il file di configurazione

LoadModule unique_id_module moduli / mod_unique_id.so

LoadModule security2_module moduli / mod_security2.so

• Riavviare Apache

A questo punto Mod Security è installato. La cosa successiva da fare è installare Mod Security core rule per le versioni avanzate delle sue funzioni. L’ultimo Core Rule può essere scaricato gratuitamente dal link https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

• Copiare il Core Rule scaricato nella cartella /opt/apache/conf
• Decomprimere il file Core Rule; a questo punto è possibile vedere le cartelle estratte come di seguito

• Si possono rinominare le cartelle con identificativi più brevi e semplici da ricordare, come :

• Andare alla cartella ars e rinominare modsecurity_crs10_setup.conf.example to modsecurity_crs10_setup.conf

A questo punto abilitiamo le regole per attivarle sul web server Apache

• Aggiungere la seguente stringa in httpd.conf

<IfModule security2_module>

Include conf/crs/modsecurity_crs_10_setup.conf

Include conf/crs/base_rules/*.conf

</IfModule>

Nella configurazione precedente abbiamo caricato Mod Security con la configurazione del file principale modsecurity_crs_10_setup.conf e fissato le regole base_rules/*.conf fornite da Mod Security Core Rules per proteggere le applicazioni web

• Riavviare Apache

Mod Security è stato configurato con successo su Apache. Ora il web server Apache è protetto da Firewall Mod Security web application.

Una volta installato Mod Security, passiamo a esaminare le più importanti configurazione per la protezione e la sicurezza delle applicazioni web. In questa sessione tutte le modifiche di configurazione saranno effettuate in /opt/apache/conf/crs/modsecurity_crs_10_setup.conf.

Si farà riferimento a /opt/apache/conf/crs/modsecurity_crs_10_setup.conf setup.conf in questa sezione a scopo di esempio. E’ importante capire quali sono le regole OWASP gratuite. Ci sono tre tipi di regole fornite da OWASP.

Base Rules: queste regole sono state accuratamente testate e il rapporto di falsi allarme è basso.

Experimental Rules: queste regole sono per scopi sperimentali ed è possibile avere dei falsi allarmi. E’ importante configurare, testare e implementare in UAT prima di utilizzarle in un ambiente di produzione

Optional Rules: queste regole opzionali non sono adatte all’intero ambiente, ma possono essere utilizzate sulla base di requisiti specifici. Se si è alla ricerca di CSRF, del monitoraggio degli utenti, Session hijacking etc. per proteggerli allora è possibile utilizzare queste regole.

Le base, experimental e optional rules sono disponibili dopo aver estratto il file zip ars scaricato dalla pagina OWASP. Questi file di configurazione delle regole sono disponibili nella cartella ars / base_rules, crs / optional_rules e crs / experimental_rules.

Prediamo familiarità con alcune base rules.

• modsecurity_crs_20_protocol_violations.conf: questa regola protegge dalle vulnerabilità del protocollo come splitting, request smuggling, using non-allowed protocol (HTTP 1.0)
• modsecurity_crs_21_protocol_anomalies.conf: questa regola protegge da una richiesta mancante con Host, Accept, User-Agent nell’intestazione
• modsecurity_crs_23_request_limits.conf: questa regola dipende da applicazioni specifiche come request size, upload size, lunghezza parametro
• modsecurity_crs_30_http_policy.conf: questa regola è per configurare e proteggere i metodi permessi e non permessi come CONNECT, TRACE, PUT, DELETE, etc.
• modsecurity_crs_35_bad_robots.conf: Rintraccia i malicious robots
• modsecurity_crs_40_generic_attacks.conf: questa regola serve per proteggere da comandi OS injection, inclusione di file remoti etc
• modsecurity_crs_41_sql_injection_attacks.conf: questa regola è per proteggere SQL e per nascondere la richiesta SQL inject
• modsecurity_crs_41_xss_attacks.conf: Protezione contro la richiesta da Cross Site Scripting
• modsecurity_crs_42_tight_security.conf: Analisi e protezione trasversale Directory
• modsecurity_crs_45_trojans.conf: questa regola rileva i generici file di gestione output, il caricamento di pagine http backdoor, le firme conosciute
• modsecurity_crs_47_common_exceptions.conf: questa regola è usata come un meccanismo di eccezione per rimuovere i falsi positivi che si possono riscontrare come Apache internal dummy connection, SSL pinger etc.

Logging per la sicurezza web server Apache

La registrazione è una delle prime cose da configurare per creare dei logs per ciò che Mod Security sta facendo. Ci sono due tipi di registrazione disponibili: Debug & Audit log.

Debug Log: questo serve per duplicare i messaggi di errore di Apache, gli avvisi e le notifiche da error log

Audit Log: questo serve per scrivere i logs delle transazioni che sono contrassegnati da Mod

Security. Mod Security dà la possibilità di configurare Audit, Debug o entrambi. Vediamo la configurazione di default in setup.conf

SecDefaultAction “fphase:1,deny,log”

Per Debug e Audit log usare “log”. Per solo Audit log usare “nolog,auditlog”. Per solo Debug log usare “log,noauditlog”. E’ possibile specificare la posizione di Audit Log da archiviare e che deve essere controllato dalla direttiva SecAuditLog.

Scriviamo Audit log in /opt/apache/logs/modsec_audit.log aggiungendo come illustrato di seguito.

Implementazione:

• Aggiungere direttiva SecAuditLog in setup.conf e riavviare il server Web Apache

 SecAuditLog /opt/apache/logs/modsec_audit.log

• Dopo il riavvio è possibile vedere modsec_audit.log generato come di seguito

Abilitare Rule Engine per la sicurezza web server Apache

Di default Engine Rule è disabilitato il che significa che non si stanno utilizzando tutti i vantaggi di Mod Security. Rule Engine abilitato o disabilitato è controllato dalla direttiva SecRuleEngine.

Implementazione

• Aggiungere direttiva SecRuleEngine in setup.conf e riavviare il server Web Apache

SecRuleEngine On

Ci sono tre valori per SecRuleEngine:

• On: per abilitare Rule Engine
• Off: per disabilitare Rule Engine
• DetectionOnly: per abilitare Rule Engine senza eseguire nessuna azione come block, deny,drop, allow, proxy o redirect

Solo se Rule Engine è on Mod Security è pronto per proteggere dai più comuni attacchi.

Proteggersi dagli attacchi comuni per la sicurezza web server Apache

Ora il web server è pronto per difendersi dai più comuni attacchi come XSS, SQL Injection, Protocol Violation etc. visto che è stato installato Core rule su Rule Engine. Testiamolo:

Attacchi XSS:

• Aprire Firefox e accedere all’applicazione e inserire il tag <script>  alla fine o URL come mostrato di seguito
• Monitorare modsec_audit.log nella cartella apache/logs

Come si può vedere Mod Security blocca la richiesta che contiene il tag <script> che è la radice degli attacchi XSS.

Attacchi Directory Traversal: Questo tipo di attacchi può creare molti danni approfittando di vulnerabilità e riuscendo ad avere accesso al sistema correlato.Ex – /etc/passwd, .htaccess, etc.

• Aprire Firefox e accedere all’applicazione con directory traversal
• Monitorare modsec_audit.log nella cartella apache/logs

http://localhost/?../…/boot

Come si vede Mod Security blocca le richieste che contengono directory traversal

Cambiare Server Banner per la sicurezza web server Apache

In precedenza in questa guida, si è visto come rimuovere la versione Apache e il tipo di sistema operativo con la direttiva ServerTokens. Facciamo un passo in avanti e vediamo come mantenere il nome del server che si desidera. Questo è possibile con la direttiva SecServerSignature in Mod Security.

Si noti che per utilizzare Mod Security per manipolare Server Banner è necessario impostare ServerTokesn in httpd.conf del web server Apache.

Implementazione:

• Aggiungere la direttiva SecServerSignature con il nome del server desiderato in setup.conf e riavviare il server Web Apache

SecServerSignature YourServerName

es:

[/opt/apache/conf/crs] #grep SecServer modsecurity_crs_10_setup.conf

SecServerSignature chandank.com

[/opt/apache/conf/crs] #

Verifica:

• Aprire Firefox e accedere all’applicazione
• Verificare le intestazioni di risposta HTTP in Firebug; è possibile vedere che Server Banner si è modificato come di seguito:

Configurazione generale per mettere in sicurezza web server Apache

Ecco alcune best practice per la configurazione generale

Configure Listen e sicurezza web server Apache

Quando si dispone di un’interfaccia e IP multipli su un singolo server, è consigliato avere una direttiva Listen configurata con IP assoluto e numero di porta. Quando nella configurazione di Apache si lascia Listen a tutti gli IP con un certo numero di porta, si possono avere problemi nella trasmissione della richiesta HTTP ad altri server. Questa situazione è abbastanza comune negli ambienti condivisi.

Implementazione:

• Configurare la direttiva Listen in httpd.conf con IP assoluto e la porta come mostrato nell’esempio qui sotto:

Listen 10.10.10.1:80

Access Logging e sicurezza web server Apache

E’ essenziale configurare Access Logging correttamente sul web server. Alcuni dei parametri più importanti da impostare in log è il tempo necessario per soddisfare la richiesta, Session ID. Di default, apache non è configurato per catturare questi dati. E’ necessario configurarli manualmente come di seguito.

Implementazione:

• Per fissare il tempo necessario per soddisfare la richiesta e Session ID nei log di accesso
• Aggiungere% T &% sessionID in httpd.conf secondo la direttiva LogFormat

  LogFormat “% h% l% u% t “% {} sessionID C” “% r” %> s% b% T” common

È possibile fare riferimento http://httpd.apache.org/docs/2.2/mod/mod_log_config.html per un elenco completo dei parametri supportati dalla direttiva LogFormat nei web server Apache.

Per la sicurezza web server Apache disabilitare i moduli indesiderati

Se sono stati compilati e installati tutti i moduli in Apache allora vi è la possibilità che ve ne siano molti non necessari. Una buona pratica è di configurare Apache con i moduli necessari nelle proprie applicazioni web.

I moduli seguenti hanno mostrato alcuni problemi di sicurezza e si potrebbe pensare di disabilitarli in httpd.conf del web server Apache.

WebDAV (Web-based Distributed Authoring and Versioning), questo modulo consente ai clients remoti di manipolare i file sul server ed è quindi soggetto a vari tentativi di arranco denial-of-service. Per disabilitarlo aggiungere il seguente commento in https.conf

#LoadModule dav_module modules/mod_dav.so

#LoadModule dav_fs_module modules/mod_dav_fs.so

#Include conf/extra/httpd-dav.conf

Info Module: Il modulo mod_info può divulgare informazioni sensibili utilizzando .htaccess una volta che il modulo è stato caricato. Per disabilitarlo:

#LoadModule info_module modules/mod_info.so