Guide@Debianizzati.Org

Hardening di un web server Apache

Versione del 27 set 2012 alle 11:37 di People (discussione | contributi) (Aggiunto template autori)
Debian-swirl.png 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%)

Asql

Questo pacchetto contiene un semplice strumento che permette di fare facilmente interrogazioni SQL sui comuni file di log di Apache.
Può dare informazioni più chiarificanti rispetto alla visione di analisi statiche dei file di log. Per installarlo: 

# apt-get install asql

Una volta installato, avviamolo con: 

# asql

Quindi, come prima cosa, carichiamo il file di log che vogliamo analizzare: 

asql v1.5 - type 'help' for help.
asql> load /var/log/apache2/access.log
Loading: /var/log/apache2/access.log
asql>

Quella che segue è una veloce sessione in Asql dove vengono impostati alcuni alias: 


asql> select COUNT(id) FROM logs
5277

asql> alias hits SELECT COUNT(id) FROM logs
ALIAS hits SELECT COUNT(id) FROM logs
asql> alias ips SELECT DISTINCT(source) FROM logs;
ALIAS ips SELECT DISTINCT(source) FROM logs;
asql> hits
5277

asql> ips
127.0.0.1
160.78.28.135
184.73.137.204
217.201.81.207
31.44.184.50
65.52.109.151
66.220.149.245
66.220.149.251
67.207.141.237
79.10.163.223
80.76.69.7
82.50.107.25
92.240.68.153
93-58-79-25.ip157.fastwebnet.it
93.144.42.66
93.58.79.25
crawl-66-249-68-22.googlebot.com
crawl-66-249-72-170.googlebot.com
crawl-66-249-72-209.googlebot.com
host-89-107-230-194.routergate.com
host223-163-dynamic.10-79-r.retail.telecomitalia.it
klopstock.ce.unipr.it
localhost
msnbot-65-52-109-151.search.msn.com
net-93-144-42-66.cust.dsl.teletu.it
ns1.eliteturk.net
proxy-03.icteam.it

asql> quit

Per un utilizzo approfondito di questo strumento consiglio una letture alle pagine man.

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:



Guida scritta da: Ferdybassi 22:10, 11 nov 2010 (CET)   Debianized 20%
Estesa da:
Verificata da:

Verificare ed estendere la guida | Cos'è una guida Debianized

Estratto da "https://guide.debianizzati.org/index.php?title=Hardening_di_un_web_server_Apache&oldid=29831"