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.
Usare .htaccess per limitare l'accesso a directory e file
In alcune circostanze può essere necessario limitare l'accesso ad una o più sottodirectory del nostro sito.
Per gestire tali limitazioni di accesso possiamo intervenire sulle singole directory mediante il file .htaccess (il quale avrà valore unicamente dentro la directory in cui è contenuto).
Un semplice esempio di file .htaccess è:
<limit GET POST> order deny, allow deny from all allow from .dominio1.com allow from .dominio2.com allow from 123.123.123.123 <limit>
Lo scopo del codice qui sopra è limitare l'accesso a tutte le chiamate GET e POST (deny from all), tranne quelle dei domini (dominio1.com, dominio2.com) e dell'IP (123.123.123.123) esplicitamente indicati:
- abbiamo impostato la direttiva limit per tutte le chiamate GET e POST;
- abbiamo definito l'ordine (order deny, allow) di inserimento delle nostre istruzioni: prima deny e poi allow
- abbiamo negato l'accesso a tutti (deny from all) tranne...
- ... agli hostname e gli IP indicati con allow from ...;
Ovviamente avremmo potuto fare anche la cosa opposta, ovvero consentire l'accesso a tutti tranne a singoli domini, IP o classi di IP. Volendo è possibile agire, oltre che su intere cartelle, anche su singoli file o gruppi di file (ad esempio tutti i file con una data estensione). Ad esempio:
<FilesMatch \.(inc|conf)> order allow, deny deny from all </FilesMatch>
impedisce a chiunque (deny from all) l'accesso a file che finiscono con .inc o .conf (estensioni tipiche dei file di configurazione).
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/apache2/conf.d/mod_security
e aggiungiamo sul fondo del file la direttiva:
Include /etc/apache2/modsecurity-crs/gotroot_rules/*.conf
Ora prepariamoci al download e all'installazione delle regole:
# cd /etc/apache2/modsecurity-crs/gotroot_rules # wget http://www.gotroot.com/downloads/ftp/mod_security/2.0/apache2/apache2-gotrootrules-modsec2.0-latest.tar.gz # tar -xzvf apache2-gotrootrules-modsec2.0-latest.tar.gz # rm apache2-gotrootrules-modsec2.0-latest.tar.gz
Quindi prepariamo un file script per l'aggiornamento automatico delle regole:
# nano /etc/apache2/modsecurity-crs/gotroot_update.sh
con contenuto:
#!/bin/sh
# Autoupdater for modsec rulesets.
#
# This script will attempt to update your rulefiles, and restart apache.
# If it apache does not start after changing rules, it will roll back to
# the old ruleset and restart apache again.
#
# Version: $Id: modsec.sh,v 1.1 2005/06/29 18:07:53 olei Exp $
# URL: http://cs.evilnetwork.org/cycro
# Copyright 2005, All Rights Reserved
APACHESTART="/usr/sbin/apache2ctl start"
MODSECPATH="/etc/apache2/modsecurity-crs/gotroot_rules"
APACHEPID="/var/run/apache2.pid"
##########################################################################
######### you probably don't need to change anything below here ##########
##########################################################################
# urls
BLACKLIST="http://www.gotroot.com/downloads/ftp/mod_security/blacklist.conf"
RULES="http://www.gotroot.com/downloads/ftp/mod_security/rules.conf"
APACHE2="http://www.gotroot.com/downloads/ftp/mod_security/apache2-rules.conf"
# internal
PID=`cat ${APACHEPID}`
UPDATED=0
echo -n "Changing PWD: "
cd ${MODSECPATH}
echo `pwd`
# blacklist
echo -n "Updating blacklist.conf: "
/usr/bin/wget -t 30 -O blacklist.conf.1 -q ${BLACKLIST}
if [ `md5sum blacklist.conf | cut -d " " -f1` != `md5sum blacklist.conf.1 | cut -d " " -f1` ] ; then
/bin/mv blacklist.conf blacklist.conf.bak
/bin/mv blacklist.conf.1 blacklist.conf
UPDATED=`expr $UPDATED + 1`
echo "ok."
else
echo "allready up to date."
/bin/rm -f blacklist.conf.1
fi
# rules
echo -n "Updating rules.conf: "
/usr/bin/wget -t 30 -O rules.conf.1 -q ${RULES}
if [ `md5sum rules.conf | cut -d " " -f1` != `md5sum rules.conf.1 | cut -d " " -f1` ] ; then
/bin/mv rules.conf rules.conf.bak
/bin/mv rules.conf.1 rules.conf
UPDATED=`expr $UPDATED + 1`
echo "ok."
else
echo "allready up to date."
/bin/rm -f rules.conf.1
fi
# apache2 rules
echo -n "Updating apache2-rules.conf: "
/usr/bin/wget -t 30 -O apache2-rules.conf.1 -q ${APACHE2}
if [ `md5sum apache2-rules.conf | cut -d " " -f1` != `md5sum apache2-rules.conf.1 | cut -d " " -f1` ] ; then
/bin/mv apache2-rules.conf apache2-rules.conf.bak
/bin/mv apache2-rules.conf.1 apache2-rules.conf
UPDATED=`expr $UPDATED + 1`
echo "ok."
else
echo "allready up to date."
/bin/rm -f apache2-rules.conf.1
fi
# try restart
if [ "$UPDATED" -gt "0" ]; then
echo -n "Restarting apache: "
/bin/kill -HUP ${PID} 2>/dev/null
# did it work?
if `/bin/kill -CHLD ${PID} >/dev/null 2>&1`; then
echo "ok."
exit 0
fi
echo "error. Apache not running."
# blacklist
echo -n "Rolling back blacklist.conf: "
/bin/mv blacklist.conf blacklist.conf.new
/bin/mv blacklist.conf.bak blacklist.conf
echo "ok."
# rules
echo -n "Rolling back rules.conf: "
/bin/mv rules.conf rules.conf.new
/bin/mv rules.conf.bak rules.conf
echo "ok."
# apache2 rules
echo -n "Rolling back apache2-rules.conf: "
/bin/mv apache2-rules.conf apache2-rules.conf.new
/bin/mv apache2-rules.conf.bak apache2-rules.conf
echo "ok."
# try starting httpd again
`${APACHESTART}`
PID=`cat ${APACHEPID}`
# did that fix the problem?
if `/bin/kill -CHLD ${PID} >/dev/null 2>&1`; then
echo "That did the trick."
exit 0
fi
echo "Fatal: Apache still not running! Run apache2ctl -t to find the error."
exit 999
fi
Rendiamo eseguibile lo script:
# chmod 700 /etc/apache2/modsecurity-crs/gotroot_update.sh
Infine mettiamo nel crontab lo script appena creato:
# crontab -e
aggiungendo al file la riga:
## Got Root Modsecurity rules 00 5 * * * /etc/apache2/modsecurity-crs/gotroot_update.sh
In questo modo le regole verranno aggiornate ogni giorno alle 5 di mattina.
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.
Apachetop
Pur non essendo tecnicamente uno strumento per l'hardening di un server web, l'utility Apachetop può venire utile nell'analisi dei processi che stanno occupando le risorse di Apache.
Apache top è un'utilità basata su curses che mostra informazioni in tempo reale su una istanza di Apache in esecuzione.
È modellata prendenda ad esempio l'utilità "top" e mostra informazioni quali il numero di richieste al secondo, i byte al secondo e gli URL visualizzati più popolari.
Deve essere eseguito da una macchina su cui gira Apache dato che funziona analizzando i file di registro in /var/log/apache.
Per installarlo:
# apt-get install apachetop
Per utilizzarlo:
# apachetop last hit: 00:00:00 atop runtime: 0 days, 00:00:05 20:27:44 All: 0 reqs ( 0.0/sec) 0.0B ( 0.0B/sec) 0.0B/req 2xx: 0 ( 0.0%) 3xx: 0 ( 0.0%) 4xx: 0 ( 0.0%) 5xx: 0 ( 0.0%) R ( 5s): 0 reqs ( 0.0/sec) 0.0B ( 0.0B/sec) 0.0B/req 2xx: 0 ( 0.0%) 3xx: 0 ( 0.0%) 4xx: 0 ( 0.0%) 5xx: 0 ( 0.0%)
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)