Sicurezza e Apache

Introduzione alla sicurezza su Apache

In questi tempi la parola "sicurezza" viene spesa da molte bocche a vario titolo.
Non di rado lo si fa semplicemente perchè è un argomento "caldo", per cui può essere fonte e opportunità di profitto.

In questo capitolo si cerca di affrontare le problematiche di sicurezza reali che un amministratore di sistema deve affrontare nel momento in cui installa e rende pubblico un server web con Apache.
Non verranno trattati argomenti che si riferiscono alla sicurezza in termini di servizio, ma solo quelli che lo fanno in termini di implementazione specifica.
Spiegamoci:
Gli argomenti relativi alla criptazione dei dati che vengono scambiati fra client e server web (SSL e mod_ssl) o quelli relativi all'accesso alle risorse web (autenticazione degli utenti o access list basate su IP) li consideriamo dei servizi, che riguardano il mondo della sicurezza in genere, ma che in se non servono a rendere sicuro un server Web. Questi vengono trattati altrove.
Qui si affrontano le problematiche reali che un sysadmin deve affrontare per proteggere il suo sistema da un uso improprio: configurazioni di Apache e direttive che possono essere sfruttate da un intrusore o un webmaster non fidato, patch e buchi di siscurezza noti, utilizzo di pagine dinamiche e problematiche relative alle singole implementazione di script dinamici, hardening del sistema su cui gira il web server, design di una infrastruttura che garantisca sicurezza e confidenzialità dei dati.

Il modo stesso di affrontare le problematiche di sicurezza dipende fortemente dal tipo di servizio che il nostro server deve offrire: se è destinato ad un utilizzo privato, in una rete locale e a non essere pubblicamente raggiungibile, si può considerare un approccio meno stringente, la protezione dell'integrità e della riservatezza dei dati possono non essere un problema di primaria importanza e le possibilità di interazione fornite agli utenti (sia quelli che navigano che quelli che uploadano sul server i contenuti) più ampie.
Su un server destinato ad avere un utilizzo pubblico su Internet, invece, possono riscontrarsi casi e problematiche diverse:
- Se l'aggiornamento delle pagine è fatto da personale fidato, si possono prevedere meno restrizioni sulle possibilità di accesso e di utilizzo delle risorse del sistema da parte delle pagine web e ci si può concentrare sulla difesa dei servizi pubblici;
- Se il server contiene più domini virtuali, gestiti da diverse persone, di diverse provenienze e non certa affidabilità, ci si deve preoccupare non soltanto di cosa può fare l'utente navigatore, ma anche di come restringere il campo d'azione dell'utente webmaster, che potrebbe sfruttare in modo improprio dei permessi troppo lassi sul sistema (per esempio la possibilità di eseguire comandi locali tramite SSI o PHP).

Direttive di Apache e sicurezza

Analizziamo le direttive che possono essere usate nella configurazione di Apache per regolare i cordoni della sicurezza e rendere più tranquilla l'esistenza di un sysadmin.
Come sempre, più si stringe una configurazione per aumentare la sicurezza di un sistema, più si limitano le sue funzionalità e flessibilità, per cui ogni indicazione va correlata alle proprie esigenze.

Cataloghiamo le note riportate secondo vari criteri, alcuni casi ne possono prevedere più di una contemporaneamente, in certe situazioni, le indicazioni che vengono qui date DEVONO essere disattese per garantire il servizio previsto:
DEFAULT Indica settaggi presenti nella configurazione di default di Apache, distribuita con i sorgenti.
WEBMASTER Indica configurazioni che si prestano ad aumentare la sicurezza su server su cui diversi utenti non trusted possono uploadare pagine (clienti di un ISP, freepages di utenti privati ecc.)
NAVIGATORI Si riferisce a configurazioni che impediscono a normali navigatori il potenziale uso improprio dei servizi del web
RISERVATEZZA Si riferisce a settaggi che aumentano la riservatezza dei dati presenti sul server Web
DENIAL OF SERVICE Indica procedure che possono aiutare a difendersi da Denial Of Service Attacks.

Impedire il controllo degli accessi per directory - WEBMASTER - DEFAULT
Tramite l'uso dei file .htaccess è possibile definire direttive di configurazione specifiche in ogni singola directory, direttamente da parte di chi ci uploada file.
Su un server su cui possono uploadare documenti anche webmaster non noti, è opportuno limitare il più possibile questa funzionalità con una radicale disabilitazione dell'uso degli .htaccess su ogni directory:
<Directory />
    AllowOverride None
</Directory>
E' poi possibile "aprire" per directory e funzionalità selezionate, la possibilità di fare l'override della conf generale tramite i file .htaccess locali.
Le diverse opzioni di AllowOverride controllano quali direttive possono essere definite nei file .htaccess: All, AuthConfig, FileInfo, Indexes, Limit, Options, None.

Impedire la lettura via Web a file .htaccess - NAVIGATORI - DEFAULT - RISERVATEZZA
Nella configurazione di Apache di default è presente un provvidenziale:
<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
    Satisfy All
</Files>
che impedisce la lettura via Web di file che iniziano con .ht e di conseguenza evita che un utente via Web possa leggere le informazioni delicate che possono essere presenti nei file .htaccess.
Ovviamente se si decide di cambiare il nome del file che controlla gli accessi sulle singole directory (direttiva di default: AccessFileName .htaccess) si dovrà adattare anche questa configurazione.

Impedire la lettura via Web a file di configurazione - NAVIGATORI - RISERVATEZZA
Analogamente al caso precedente può essere utile impedire l'accesso diretto a file che possono contenere parametri di configurazione (che finiscono con inc o conf):
<FilesMatch \.(inc|conf)>
    Order Allow,Deny
    Deny from all
</FilesMatch>

Disattivare l'uso di .cgi e .shtml al di fuori di directory predefinite  - WEBMASTER - DEFAULT
Tramite la direttiva AddHandler si può dire al server web di trattare file con determinate estensioni con un apposito handler (per esempio un modulo per gestire pagine dinamiche). Di default sulla conf di Apache sono disattivati gli handler per script .cgi e .shtml:
#AddHandler cgi-script .cgi
#AddType text/html .shtml
#AddHandler server-parsed .shtml
per cui se si vogliono usare dei Server Side Includes o degli script CGI al di fuori della directory predefinita con la direttiva ScriptAlias /cgi-bin/ "@@ServerRoot@@/cgi-bin/", queste righe vanno scommentate.

Disabilitare l'accesso pubblico a server-info e server-status - NAVIGATORI - DEFAULT - RISERVATEZZA
Apache prevede due location speciali che possono essere utilizzate per visualizzare informazioni utili al sysadmin sullo stato del server web e la sua configurazione. Di default questo sono disabilitate, ma possono essere abilitate limitando gli IP da cui possono essere visualizzate. In genere è consigliabile non renderle visibili pubblicamente (in particolare server-info, che di fatto espone la configurazione completa di Apache).
#<Location /server-status>
#    SetHandler server-status
#    Order deny,allow
#    Deny from all
#    Allow from .your-domain.com
#</Location>

#<Location /server-info>
#    SetHandler server-info
#    Order deny,allow
#    Deny from all
#    Allow from .your-domain.com
#</Location>
Se si vogliono visualizzare server-status e server-info, scommentare queste righe e specificare i domini o gli IP da cui è permesso visualizzarli.

Disabilitare il file listing in directory senza index.html (o analoghi nomi di file predefiniti) - NAVIGATORI - RISERVATEZZA
Con la direttiva DirectoryIndex si definiscono quali file Apache automaticamente cerca, e visualizza, quando il client richiede un URI che contiene solo il nome di una directory, senza specificare il nome della pagina web. Se il client accede ad una directory che non contiene uno di questi index predefiniti, Apache visualizza direttamente tutti i file contenuti nella directory stessa, esponendo infomazioni potenzialmente riservate.
Se si vuole disabilitare il listing di tutti i file presenti in una directory, quando non è presente il file di indice, si usa la direttiva Options -Indexes. Es:
<Location />
Options -Indexes
</Location />
Per disabilitare il directory listing si può anche direttamente rimuovere il caricamento (o la compilazione) del modulo mod_autoindex, se invece si vuole abilitarlo, ma al contempo escludere dal listing dei file potenzialmente sensibili si può usare una direttiva come:
IndexIgnore .??* *.bak *.swp *# HEADER* README* RCS

Limitare le richieste del client - NAVIGATORI - DENIAL OF SERVICE
Di default Apache permette al client di eseguire richieste particolarmente esose che possono essere impropriamente utilizzate per un Denial Of Service attack. Esistono alcune direttive che limitano alcune caratteristiche delle richieste che il client può eseguire:
LimitRequestBody 10240 Limita a meno di 10 Kb le dimensioni del body di una richiesta HTTP (PUT o POST). Di default questo valore è 0 (infinito). Si può specificare un valore in byte diverso, avendo cura di non interferire con il normale funzionamento di un sito.
LimitRequestFields 30 Imposta a 30 il numero massimo di header HTTP che il client può inserire nella sua richiesta. Il valore di default è 100, in genere è difficile avere richieste che abbiamo più di 20-30 header.
LimitRequestFieldSize 500 Imposta a 500 byte la dimensione massima di ogni singolo header HTTP in una richiesta. Il valore di default è 8190.
LimitRequestLine 500 Imposta a 500 byte le dimensioni della richiesta HTTP (metodo, URL e protocollo), limitando di fatto le dimensioni dell'URL stesso che un client può chiedere (attenzione a dimensionarlo secondo i nomi e i parametri passati negli URL del proprio sito). Valore di default 8190.

Disabilitare l'uso di symlink - WEBMASTER
Di default Apache se trova in una directory di un suo sito Web un link simbolico all'infuori della directory stessa, prova a seguirlo e fornire il file linkato.
Questo comportamento può essere usato per far vedere via web dati che non dovrebbero essere visibili (immaginare un webmaster che digita il seguente comando nella sua home: ln -s /etc/passwd passwd.html.
Per impedirlo si deve definire, nella conf generale o in un specifico contenitore:
Options -FollowSymLinks.
Esiste anche la possibilità di configurare Apache per seguire solo i symlink a file posseduti dall'utente, permettendo il symlinking all'interno del proprio sito web (e appesantendo non poco il server, per la quantità di controlli aggiuntivi che deve fare per ogni file servito):
Options -FollowSymLinks +SymLinksIfOwnerMatch.

Problematiche di sicurezza con contenuti dinamici

I veri grattacapi in termini di protezione di un server web arrivano quando si deve gestire un sito dinamico, in cui, tramite cgi, php, perl, ssi o altri metodi le pagine vengono generate on-the-fly e il server non solo deve leggere i file presenti sulla document root ma attingere a dati su un database ed eseguire operazioni sul sistema.

In simili casi le insidie sono enormemente maggiori, perchè non dipendono semplicemente dalla versione del web server installata o dalla sua configurazione, ma di fatto riguardano ogni singolo script che viene eseguito per gestire e generare le pagine.
Fondamentali, in questo senso, sono i permessi con cui vengono eseguiti script o programmi: questi vengono solitamente ereditati da Apache stesso  per cui è importante che il server web giri come utente comune (deve comunque essere lanciato come root, per bindarsi alla porta 80, ma tutti i processi figli che gestiscono le connessioni con i client, sono eseguiti con privilegi comuni).
A volte è necessario eseguire alcuni script come root, in questo caso è necessario abilitare funzionalità di suexec, che vanno sempre ponderate con attenzioni.

A prescindere dai singoli linguaggi utilizzati per generare pagine dinamiche, esistono alcune regole di fondo, legate alla stessa logica di un sistema operativo, che vanno considerate nell'analisi e nella realizzazione del codice:

Verifica dell'input di POST o GET
Qualsiasi dato che l'utente può postare su una pagina web va attentamente valutato e ponderato: le possibilità di abusare della funzionalità di uno script sono enormi, considerando la logica di Unix e la modalità con cui vengono gestiti gli input.
Immaginiamo di avere un form dove viene richiesto un indirizzo Email, questo viene passato tramite un nostro script CGI ad un comando shell come mail $indirizzo_inserito.
Se qualcuno inserisce come email qualcosa come [email protected] < /etc/passwd il comando eseguito sul sistema diventa mail [email protected] < /etc/passwd con le conseguenze che si possono immaginare.
Considerare anche le variazioni sul tema, nel caso nell'input venga inserito un ; seguito da un comando maligno, o un > o delle parentesi tonde () ecc.
In pratica si deve sempre porre la massima attenzione a qualsiasi "punto di entrata" di dati dall'esterno: di fatto a qualsiasi form che passa dati ad uno script CGI, o qualsiasi pagina dinamica che accetta parametri tramite l'URL passato in GET.

Controllo dell'input sul server (non lasciare la sicurezza sul lato client)
Le possibilità di abuso che si aprono nel momento in cui si utilizzano pagine dinamiche sono innumerevoli, le soluzioni varie, ma in genere la logica è sempre la stessa: controllare e filtrare ogni input accettabile e farlo sul server e non lasciarlo al client.
Eveitare per esempio di controllare l'input direttamente nella pagina HTML tramite javascript o analoghi.
In questo modo si lascia al lato client il controllo e la sicurezza dei dati: un utente ostile può sempre salvare la pagina html in locale, modificare il javascript che esegue il controllo dell'input, ed eseguire il POST dalla pagina modificata, senza i filtri previsti: l'unico modo per evitare una simile operazione sarebbe verificare il referrer da cui arrivano i dati postati, se la pagina è quella del nostro sito allora si accetta l'input, altrimenti si blocca, ma anche in questo caso l'header REFERRER può essere manipolato, per cui di fatto, è sempre meglio operare ogni controllo e filtro dell'input direttamente sul server.

Evitare l'output di codice HTML inseribile dall'utente
Si consideri un forum dove chiunque può scrivere messaggi. Se non vengono fatti specifici controlli e filtrati tutti i tag html tranne eventualmente quelli che possono essere ritenuti innocui, un utente ostile può postare del codice HTML con effetti imprevedibili e comunque molto ampi e variegati (Basta richiamare uno script remoto con <img src=http://www.sitoremoto.com/bruttecose.cgi> per eseguire codice ostile sul browser dell'utente che visita il forum)

Passaggio di dati e parametri sensibili via URL o hidden fields
A volte per gestire pagine dinamiche si devono passare dati e parametri da una pagina all'altra. I metodi per farlo possono essere via POST, tramite i contenuti di un form o via GET, tramite coppie di attributi/valori passati nell'URL.
Se i parametri sono sensibili e potenzialmente riservati o sfruttabili per usi impropri si deve prestare attenzione a come vengono gestiti: usare HIDDEN field in un form, per esempio, dal punto di vista della sicurezza è inutile, visto che il sorgente della pagina HTML è facilmente visualizzabile.
Si può pensare di criptare i dati, se si devono a tutti costi "passare", oppure di trovare soluzioni tali da rendere inutile il passaggio di simili dati, perchè associati alla singola sessione di navigazione (per esempio tramite cookie).

Nascondere la versione di Apache

E' possibile tramite la modifica e la compilazione dei sorgenti oppure tramite una direttiva nascondere la versione di Apache rendendo difficoltose le operazioni di scouting delle informazioni.

Innanzitutto occorre avere a disposizione i sorgenti (sono disponibili sul sito ufficiale) e modificare poche variabili nel file  src/include/httpd.h contenuto nella directory generale di apache.
Si può impostare la versione di Apache visualizzata cambiando il valore della seguente variabile:
#define SERVER_BASEREVISION "1.3.27"
Esempio: #define SERVER_BASEREVISION "1.0"
Questa operazione richiede l'opzione --force quando si lancia la compilazione di mod_ssl per evitare il check della versione di Apache.

Inoltre a livello di configurazione in httpd.conf si possono modificare i contenuti degli header di Apache con la direttiva: ServerTokens . Esempio:
ServerTokens Prod

Le opzioni dispobili sono le seguenti:
- Prod: Mostra il valore della variabile SERVER_BASEPRODUCT settata con il valore Apache.
Contenuto Header Server: Apache
- Min: Mostra il software vendor e la versione di Apache.
Contenuto Header Server: Apache/1.3.0
- OS: Oltre alle informazioni riguardnti alla versione aggiunge informazioni sul sistema operativo.
Contenuto Header Server: Apache/1.3.0 (Unix)
- Full(Impostazione di default): Vengono inviate tutte le informazioni possibili riguardanti alla versione, hai moduli installati e del sistema operativo.
Contenuto Header Server: Apache/1.3.0 (Unix) PHP/3.0 MyMod/1.2

La soluzione più idonea è l'uso di entrambe poichè la seconda possibilità nasconde la versione solo all'interno dei vari header inviati dal server e non ad esempio nelle pagine di errore create on-the-fly.
Infatti basta una semplice get irregolare o qualsiasi cosa che generi un errore per verificare la versione di un Apache server che usa la direttiva ServerTokens.
[root@dido include]# telnet 0 80
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
get /
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>501 Method Not Implemented</TITLE>
</HEAD><BODY>
<H1>Method Not Implemented</H1>
get to /index.htm not supported.<P>
Invalid method in request get /<P>
<HR>
<ADDRESS>Apache/1.3.27 Server at localhost.localdomain Port 80</ADDRESS>
</BODY></HTML>
Connection closed by foreign host.

Storia delle vulnerabilità di Apache

Come ogni software su ogni sistema operativo, Apache ha una lunga storia di aggiornamenti, bug e patch.
Come ogni software che viene usato su sistemi connessi ad Internet, Apache ha la sua storia di vulnerabilities, exploit e buchi di sicurezza che vengono regolarmente scoperti e regolarmente patchati.
Come ogni software per server, il modo più efficace e rapido per tenerlo il più possibile sicuro è mantenerlo aggiornato.

Riportiamo, come reference indicativa, la lista completa delle vulnerabilities scoperte su Apache fino al momento in cui si scrivono queste note come vengono riportate su SecurityFocus, che mantiene uno dei database più efficaci e completi sulla sicurezza.
Va considerato che non tutte le vulnerability qui riportate necessariamente riguardano i nostri sistemi o sono particolarmente gravi in quanto:
- Possono riferirsi a versioni di Apache per specifici sistemi operativi;
- Possono riferirsi a progetti correlati ad Apache che non sempre sono usati (es: Tomcat o mod_dav);
- Possono valere solo in determinati casi o con determinate configurazioni, non previste di default;
- Possono comportare problematiche di sicurezza non critiche, seppur degne di attenzione.

E' inevitabile che questo elenco sia destinato ad aumentare con il tempo e che le versioni di Apache attualmente disponibili contengano dei bug che verranno scoperti e resi pubblici in futuro.
Una volta installato il proprio server Web, quindi, è opportuno considerare strumenti e tecniche per aggiornarlo in modo rapido e senza complicazioni.

ELENCO VULNERABILITY SU APACHE Fonte: Security Focus Vulns Archive

2002-10-30:  Apache 2 WebDAV CGI POST Request Information Disclosure Vulnerability
2002-10-17:  Multiple Apache HTDigest Buffer Overflow Vulnerabilities    
2002-10-17:  Apache HTDigest Arbitrary Command Execution Vulnerability
2002-10-17:  Multiple Apache HTDigest and HTPassWD Component Vulnerabilites
2002-10-05:  OpenSSL SSLv2 Malformed Client Key Remote Buffer Overflow Vulnerability    
2002-10-04:  Apache Tomcat DefaultServlet File Disclosure Vulnerability
2002-10-01:  Apache Tomcat Mod_JK /Mod_JServ Directory Disclosure Vulnerability
2002-09-27:  Apache 2 mod_dav Denial Of Service Vulnerability
2002-09-24:  Apache Oversized STDERR Buffer Denial Of Service Vulnerability
2002-09-09:  Apache Chunked-Encoding Memory Corruption Vulnerability
2002-08-21:  Apache Tomcat 4.1 JSP Request Cross Site Scripting Vulnerability
2002-08-16:  Apache 2.0 CGI Path Disclosure Vulnerability
2002-08-16:  Apache 2.0 Path Disclosure Vulnerability
2002-08-16:  Apache 2.0 Encoded Backslash Directory Traversal Vulnerability
2002-07-17:  Apache httpd 2.0 CGI Error Path Disclosure Vulnerability
2002-07-10:  Apache Tomcat DOS Device Name Cross Site Scripting Vulnerability
2002-07-10:  Apache Tomcat Servlet Mapping Cross Site Scripting Vulnerability
2002-06-20:  Apache Tomcat Null Character Malformed Request Denial Of Service Vulnerability
2002-06-19:  Apache Tomcat Web Root Path Disclosure Vulnerability
2002-06-12:  Apache Tomcat JSP Engine Denial of Service Vulnerability
2002-05-29:  Apache Tomcat Example Files Web Root Path Disclosure Vulnerability
2002-05-29:  Apache Tomcat Source.JSP Malformed Request Information Disclosure Vulnerability
2002-05-29:  Apache Tomcat RealPath.JSP Malformed Request Information Disclosure Vulnerability
2002-05-13:  Multiple Vendor HTTP CONNECT TCP Tunnel Vulnerability
2002-04-23:  Apache Tomcat Servlet Path Disclosure Vulnerability
2002-04-19:  Apache Tomcat System Path Information Disclosure Vulnerability
2002-03-25:  Apache Double-Reverse Lookup Log Entry Spoofing Vulnerability
2002-03-25:  Apache Win32 Batch File Remote Command Execution Vulnerability
2002-03-16:  Apache Possible Directory Index Disclosure Vulnerability
2002-03-16:  Apache Split-Logfile File Append Vulnerability
2002-02-07:  Apache 2 for Windows OPTIONS request Path Disclosure Vulnerability
2002-02-07:  Apache 2 for Windows php.exe Path Disclosure Vulnerability
2002-01-08:  Apache HTTP Request Unexpected Behavior Vulnerability
2002-01-07:  Apache Non-Existent Log Directory Denial Of Service Vulnerability
2002-01-07:  Apache Win32 PHP.EXE Remote File Disclosure Vulnerability
2001-12-12:  Multiple Vendor URL JSP Request Source Code Disclosure Vulnerability
2001-11-29:  Apache Artificially Long Slash Path Directory Listing Vulnerability
2001-11-23:  Jakarta Tomcat Error Message Information Disclosure Vulnerability
2001-11-08:  Apache mod_usertrack Predictable ID Generation Vulnerability
2001-09-10:  MacOS X Client Apache Directory Contents Disclosure Vulnerability
2001-08-13:  Apache Mod ReWrite Rules Bypassing Image Linking Vulnerability
2001-08-13:  Apache Server Address Disclosure Vulnerability
2001-07-04:  Apache Tomcat Cross-Site Scripting Vulnerability
2001-06-11:  MacOS X Client Apache File Protection Bypass Vulnerability
2001-05-22:  Apache Web Server HTTP Request Denial of Service Vulnerability
2001-03-30:  Apache Tomcat 3.0 Directory Traversal Vulnerability
2000-12-06:  Apache Web Server with Php 3 File Disclosure Vulnerability
2000-09-29:  Apache Rewrite Module Arbitrary File Disclosure Vulnerability
2000-09-07:  SuSE Apache WebDAV Directory Listings Vulnerability
2000-07-20:  Apache Tomcat 3.1 Path Revealing Vulnerability
2000-07-20:  Apache Tomcat Snoop Servlet Information Disclosure Vulnerability
2000-07-20:  Apache Jakarta-Tomcat /admin Context Vulnerability
2000-05-31:  Apache HTTP Server (win32) Root Directory Access Vulnerability
1999-09-25:  NCSA/Apache httpd ScriptAlias Source Retrieval Vulnerability
1999-06-01:  phf Remote Command Execution Vulnerability
1999-06-01:  Multiple Vendor nph-test-cgi Vulnerability
1999-06-01:  Multiple Vendor MIME Header DoS Vulnerability
1999-06-01:  Apache mod_cookies Buffer Overflow Vulnerability
1999-06-01:  Multiple Vendor test-cgi Directory Listing Vulnerability
1999-06-01:  Apache Web Server DoS Vulnerability

Web Application Firewall (WAF) Opensource

Modsecurity(TM) è un IDS (intrusion detection system) per le applicazioni web.
In sostanza impedisce che un utente malintenzionato possa, sfruttando vulnerabilità varie (cgi/php) compromettere la sicurezza di un sistema.
Il suo funzionamento è alquanto semplice: essendo un mod per apache si integra perfettamente (ed esclusivamente) con lo stesso e permette di controllare tutte le richieste web in ingresso ed in uscita, graficamente l'impostazione è questa:

caso A) http get ---> [mod security] ---> [apache web server] ---> reply
caso B) vuln.cgi&file=|uname| ---> [mod security] ---> { LOG-IP/BLOCK/FORWARD }

Il sito ufficiale del progetto è http://www.modsecurity.org.

Installazione:

-- da sorgenti

Attraverso DSO l'installazione è molto semplice.
Decomprimiamo il tarball da qualche parte ed installiamolo comodamente con attraverso il comando apxs:

# <apache-home>/bin/apxs -cia mod_security.c

dopodichè restariamo apache con apachectl restart

Per compilarlo staticamente con Apache 1.x portiamoci nella directory contenente i sorgenti di apache e copiamo mod_security in /src/modules/extra; fatto questo procediamo compilando:

$ cd <apache1.x-source>
$ cp <modsecurity-source>/apache1/mod_security.c ./src/modules/extra
$ ./configure \
> --activate-module=src/modules/extra/mod_security \
> -–enable-module=security


Per quanto concerne invece Apache 2, il procedimento è simile:

$ cd <apache2-source>
$ cp <modsecurity-source>/apache2/mod_security.c ./modules/proxy
$ ./configure \
> -enable-security \
> --with-module=proxy:mod_security.c


-- da binari

Per Apache 1.x bisogna copiare il modulo mod_security.so in libexec/ e, dopo aver fatto questo, modificare il file httpd.conf aggiungendo la seguente riga:

LoadModule security_module    libexec/mod_security.so

Per Apache 2.x il discorso è pressochè identico con l'unica eccezione dovuta al fatto che al posto di copiare il modulo in libexec/ lo copieremo in modules/ e quindi al file httpd.conf aggiungeremo:

LoadModule security_module    modules/mod_security.so

Configurazione:
Editiamo il file di configurazione del nostro web server aggiungendoci una direttiva al file che fungerà da configurazione di modsecurity:

# echo "#include /path_a_piacere/modsec.conf" >> /var/www/conf/httpd.conf (la path dell'httpd.conf varia, questa è quella che uso io su OpenBSD).

A questo punto scriviamo il file /path_a_piacere/modsec.conf:

# Abilitiamo ModSecurity
SecFilterEngine On

# Impostiamo il comportamento di default da assumere in caso di infrazione
# di una regola ove questo comportamento
# non è impostato direttamente dalla direttiva della regola stessa.
#
SecFilterDefaultAction "deny,log,status:403"

# Abilitiamo lo scan del POST, dell'encoding dell'URL e parsiamo l'unicode
SecFilterScanPOST On
SecFilterCheckURLEncoding On
SecFilterCheckUnicodeEncoding Off

# Usiamo un server-banner a piacere
# SecServerSignature "Micro$oft-IIS/9.0"

# Definiamo il margine d'importanza affinchè un evento venga loggato ed impostiamo la cartella dei logs.
SecAuditEngine RelevantOnly
SecAuditLog /path_a_piacere/logs.modsecurity

# Parametri opzionali:
SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
SecFilterSelective HTTP_Content-Type \
"!(^application/x-www-form-urlencoded$|^multipart/form-data;)"
SecFilterSelective REQUEST_METHOD "^(GET|HEAD)$" chain
SecFilterSelective HTTP_Content-Length "!^$"
SecFilterSelective REQUEST_METHOD "^POST$" chain
SecFilterSelective HTTP_Content-Length "^$"

# Definiamo gli attacchi che vanno per la maggiore tra le comunità di lamers ed impostiamo il logging ed, ovviamente il bloccaggio:

# CSS
SecFilter "../../../" "deny,log"
# Remote exec.
SecFilter "uname" "deny,log"
SecFilter "/etc/passwd" "deny,log"
SecFilter "echo" "deny,log"


Buon divertimento!