Hardening di un web server Apache

Versioni Compatibili

Tutte le versioni supportate di Debian

Introduzione

Apache come ogni software usato in rete, è soggetto a bug che lo possono rendere vulnerabile ad attacchi di diversa natura: Denial of Service, Information Disclosure, System Violation, Data Corruption...
La storia di Apache ha avuto vulnerabilità anche serie, prontamente corrette, e problemi minori, applicabili a situazioni particolari.
Al giorno d'oggi in realtà la maggior parte dei problemi di sicurezza di un sito web non è dovuta al software che fa da server web (Apache), ma dalle applicazioni web, basate su diversi linguaggi.
In questa guida vedremo come modificare alcune direttive dei file di configurazione di Apache per migliorare la sicurezza del demone, installeremo alcuni moduli aggiuntivi molto utili per aumentare la robustezza del nostro servizio web e, infine, vedremo alcuni consigli per sviluppare con un occhio rivolto alla sicurezza le nostre applicazioni in PHP, Perl o in altri linguaggi.

Direttive di Apache

Debian prevede un file specifico per la configurazione e la gestione della sicurezza di Apache: /etc/apache2/conf.d/security.
Si consiglia quindi di apportare in questo file tutte le modifiche seguenti che desiderate implementare nella vostra configurazione.

Impedire il controllo degli accessi per directory

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>

È 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

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

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

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 decommentate.

Disabilitare l'accesso pubblico a server-info e server-status

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, decommentare 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)

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:

<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

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

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.

Modificare la direttiva `ServerTokens`

Di default il valore della direttiva è:

ServerTokens Full

e indica quante informazioni vengono inviate dal server nell'header. Può essere utile modificare il valore di default per una questione di sicurezza: meno informazioni forniamo sul nostro server, sulla versione di Apache e sui moduli installati, e meno facile sarà trovare un exploit per bucarci.
Le possibili opzioni sono:

Full

Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny3 with Suhosin-Patch Server at demo

OS

Apache/2.2.9 (Debian) Server

Minimal

Apache/2.2.9 Server

Minor

Apache/2.2 Server

Major

Apache/2 Server

Prod

Apache Server

Pur sembrando una cosa da poco, si noti che è assai semplice recuperare le informazioni di questa direttiva, ad esempio inviando una richiesta GET sbagliata al web server da attaccare:

ferdy@server:~$ telnet 127.0.0.1 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
GET /index.ht PIPPO/1.1
host: 127.0.0.1

HTTP/1.1 404 Not Found
Date: Wed, 10 Nov 2010 23:23:00 GMT
Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
Vary: Accept-Encoding
Content-Length: 347
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /index.ht was not found on this server.</p>
<hr>
<address>Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g Server at 127.0.0.1 Port 80</address>
</body></html>
Connection closed by foreign host.

Il modulo `mod_evasive` di Apache

Il modulo di Apache mod_evasive (Debian Package, Sito web ufficiale) è un modulo aggiuntivo di Apache studiato per fornire un po' di protezione contro gli attacchi DDoS e di brute force.
Per installarlo è sufficiente:

# aptitude install libapache2-mod-evasive

Durante l'installazione del modulo il servizio Apache sarà riavviato e il modulo automaticamente caricato al successivo riavvio. È possibile verificare il corretto caricamento del modulo con:

# find /etc/apache2/ | xargs fgrep -nH evasive

Su alcuni siti viene suggerito di aumentare la sicurezza del modulo aggiungendo alcuni parametri di configurazione al file /etc/apache2/mods-available/mod-evasive.load:

<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 5
DOSSiteCount 100
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 600
</IfModule>

Un riavvio del server Apache caricherà la nuova configurazione:

# /etc/init.d/apache2 restart

È possibile testare il corretto funzionamento del modulo con il seguente script, installato insieme al modulo stesso:

# perl /usr/share/doc/libapache2-mod-evasive/examples/test.pl

Dovreste ottenere un risultato del genere:

HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 200 OK
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 200 OK
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden

Il modulo `mod_security` di Apache

Il modulo di Apache mod_security è un modulo che permette di loggare i più comuni attacchi ad Apache come XSS, remote command execution, file disclosure e tutto quello che può essere considerato dannoso nei confronti di un povero web server. Il sito ufficiale del modulo è http://www.modsecurity.org , ma per fortuna esiste un pacchetto Debian, presente in Squeeze e nei Backport di Lenny.
Per installarlo è quindi sufficiente:

Lenny:

# apt-get -t lenny-backports install libapache-mod-security

Squeeze:

# apt-get install libapache-mod-security

Abilitiamo il modulo appena installato e ci troveremo già con una configurazione minimale funzionante:

# a2enmod mod-security
# /etc/init.d/apache2 restart

La forza di questo modulo, però, risiede nella sua possibilità di tuning. Creiamo quindi il file /etc/apache2/conf.d/mod_security e impostiamo una prima configurazione di base personalizzata:

<<IfModule mod_security.c>
# Basic configuration options
SecFilterEngine On
SecFilterCheckURLEncoding On
SecFilterCheckUnicodeEncoding Off
SecFilterForceByteRange 0 255
SecFilterScanPOST On
SecFilterDefaultAction "deny,log,status:500"
SecRequestBodyAccess On
SecResponseBodyAccess Off

# Handling of file uploads
# TODO Choose a folder private to Apache.
# SecUploadDir /opt/apache-frontend/tmp/
SecUploadKeepFiles Off

# Debug log
SecDebugLog /var/log/apache2/modsec_debug.log
SecDebugLogLevel 0

# Serial audit log
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^5
SecAuditLogParts ABIFHZ
SecAuditLogType Serial
SecAuditLog /var/log/apache2/modsec_audit.log

# Maximum request body size we will
# accept for buffering
SecRequestBodyLimit 131072

# Store up to 128 KB in memory SecRequestBodyInMemoryLimit 131072
# Buffer response bodies of up to # 512 KB in length SecResponseBodyLimit 524288

</IfModule>

In questo primo template di default abbiamo impostato alcune regole:

SecFiterEngine (On|Off): abilita o disabilita il modulo
SecFilterCheckUrlEncoding (On|Off): controlla se i caratteri speciali vengono encodati prima di essere passati all'URL
SecFilterCheckUnicodeEncoding (On|Off): controlla se l'encoding Unicode è valido
SecFilterForceByteRange: forza le richieste dentro un range predefinito di bytes. Può aiutare a prevenire attacchi stack overflow. Il range può essere impostato da 0 a 255.
SecServerSignature: cambia la signature nella risposta agli header. Perché funzioni è necessaria la direttiva Apache ServerTokens Full.
SecAuditEngine (On|Off|RelevantOnly): abilita o disabilita il loggind di mod-security. RelevantOnly logga solo le richieste che coincidono con una regola impostata.
SecAuditLog /path/to/audit_log: define the file where mod-security will write its logs.
SecFilterDebugLog /path/to/debug_log: il percorso del log di debug.
SecFilterDebugLevel (0-9): mod-security ha 10 livelli di debug: 0 (non vengono loggate informazioni di debug) - 9 (viene loggato tutto).
SecFilterScanPost (On|Off): di default, mod-security scansiona solo le richieste GET datas. Abilitando questa direttiva gli faremo scansionare anche i dati POST

Verifichiamo la nuova configurazione:

# apache2ctl -t
Syntax OK

e riavviamo Apache:

# /etc/init.d/apache restart

Per verificare il corretto funzionamento del modulo appena installato è sufficiente aprire il file di log di Apache:

# tail /var/log/apache2/error.log

e verificare che dopo l'ultimo riavvio compaia una riga simile a questa:

[Sat Nov 13 13:09:49 2010] [notice] ModSecurity for Apache/2.5.11 (http://www.modsecurity.org/) configured.

A questo punto potremmo voler abilitare la protezione per alcuni attacchi comuni attraverso le cosiddette Core Rules, che possiamo scaricare da qui: http://sourceforge.net/projects/mod-security/files/modsecurity-crs/0-CURRENT/modsecurity-crs_2.0.8.tar.gz/download
Una volta scaricato il file delle regole (al momento della stesura di questa guida il file più aggiornato è modsecurity-crs_2.0.8.tar.gz), copiamolo al posto giusto e scompattiamolo:

# cp -rpf ~/modsecurity-crs_2.0.8.tar.gz /etc/apache2/
# cd /etc/apache2/; tar -zxvvf modsecurity-crs_2.0.8.tar.gz
# mv modsecurity-crs_2.0.8 modsecurity-crs

Apriamo il file di configurazione di mod_security:

# nano /etc/apache2/conf.d/mod_security

e aggiungiamo alla fine del file le righe:

Include /etc/apache2/modsecurity-crs/*.conf
Include /etc/apache2/modsecurity-crs/base_rules/*.conf

Verifichiamo la nuova configurazione:

# apache2ctl -t
Syntax OK

e riavviamo Apache:

# /etc/init.d/apache restart

Ulteriori regole e aggiornamento automatico

La comunità Got Root? mette a disposizione un ulteriore pacchetto di regole molto completo e con possibilità di aggiornamento automatico. Vediamo come utilizzarlo.
Inannzitutto creiamo una nuova directory per archiviare le regole:

# cd /etc/apache2/modsecurity-crs
# mkdir gotroot_rules

Quindi apriamo il file di configurazione del modulo:

# nano /etc/apac
Include /etc/apache2/modsecurity-crs/base_rules/*.conf

Il modulo `mod_security` e Drupal

Sembra che alcune regole possano interferire con l'installazione e/o le normali operazioni di amministrazione del CMS Drupal. A questo indirizzo è possibile trovare un how-to per ovviare al problema.

Documentazione di `mod_security`

A questo indirizzo è possibile trovare l'ottima documentazione ufficiale di ModSecurity, unitamente a diversi esempi di regole personalizzate.

Ulteriori configurazioni

Diamo qui di seguito alcuni veloci consigli per impostare delle strategie di ottimizzazione e di protezioni di alcuni altri componenti della struttura di un server LAMP.

Configurazione di PHP

A livello di configurazione di PHP è possibile:

Limitare l'utilizzo delle risorse di sistema da parte di una pagina PHP
Introdurre filtri standard sugli input passati a query SQL
Limitare l'accesso al file system da parte di script PHP

Configurazione di MySQL

A livello di configurazione di MySQL è possibile:

Controllare e impedire accesso in lettura o in scrittura a dati da parte di applicazioni Web

Applicazioni web

A livello di applicazione web si deve:

Controllare i dati in input e renderli inoffensivi ad attacchi basati su SQL Injection, Cross Site Scripting, accesso al file sistema, abuso di risorse locali.
Verificare la logica del codice per impedire accesso ad aree riservate da parte di utenti non autorizzati

Sitografia

Per la redazione di questa guida sono state assai utili le informazioni raccolte qui:

--Ferdybassi 22:10, 11 nov 2010 (CET)

Hardening di un web server Apache

Indice

Introduzione

Direttive di Apache

Impedire il controllo degli accessi per directory

Impedire la lettura via Web a file .htaccess

Impedire la lettura via Web a file di configurazione

Disattivare l'uso di .cgi e .shtml al di fuori di directory predefinite

Disabilitare l'accesso pubblico a server-info e server-status

Disabilitare il file listing in directory senza index.html (o analoghi nomi di file predefiniti)

Limitare le richieste del client

Disabilitare l'uso di symlink

Modificare la direttiva `ServerTokens`

Il modulo `mod_evasive` di Apache

Il modulo `mod_security` di Apache

Ulteriori regole e aggiornamento automatico

Il modulo `mod_security` e Drupal

Documentazione di `mod_security`

Ulteriori configurazioni

Configurazione di PHP

Configurazione di MySQL

Applicazioni web

Sitografia

Menu di navigazione

Hardening di un web server Apache

Introduzione

Direttive di Apache

Impedire il controllo degli accessi per directory

Impedire la lettura via Web a file .htaccess

Impedire la lettura via Web a file di configurazione

Disattivare l'uso di .cgi e .shtml al di fuori di directory predefinite

Disabilitare l'accesso pubblico a server-info e server-status

Disabilitare il file listing in directory senza index.html (o analoghi nomi di file predefiniti)

Limitare le richieste del client

Disabilitare l'uso di symlink

Modificare la direttiva ServerTokens

Il modulo mod_evasive di Apache

Il modulo mod_security di Apache

Ulteriori regole e aggiornamento automatico

Il modulo mod_security e Drupal

Documentazione di mod_security

Ulteriori configurazioni

Configurazione di PHP

Configurazione di MySQL

Applicazioni web

Sitografia

Menu di navigazione

Ricerca

Modificare la direttiva `ServerTokens`

Il modulo `mod_evasive` di Apache

Il modulo `mod_security` di Apache

Il modulo `mod_security` e Drupal

Documentazione di `mod_security`