Beruflich Dokumente
Kultur Dokumente
1. Prambule
Ce document est un livre de recettes pour protger une architecture LAMP (Linux, Apache, MySQL,
PHP), mais elle peut aussi aider, pour peu qu'on l'adapte correctement, protger toute architecture Web. La
dmarche ne garantit absolument pas l'inviolabilit, le 100% ne faisant pas partie de ce monde, mais va rendre la
tche du pirate plus complique, et plus longue.
1.1. Pr-requis
Nous supposerons que PHP est install en tant que module dans Apache. Le cas de PHP utilis comme
CGI ne devrait recouvrir que le cas des particuliers chez leur FAI favori. Nous supposerons aussi que le lecteur
est au moins habitu la programmation, mme sans tre un expert. Nous supposerons enfin que les
dveloppeurs web ne sont pas hostiles, tout au plus inconscients.
3. Apache
3.2. Le paramtrage
Il est important de vrifier quelques paramtres, et de limiter leur action suivant vos utilisateurs (les
options allowOverride sont l pour cela).
<Directory />
AllowOverride None
</Directory>
Dsactivez la signature de l'apache:
ServerSignature Off
ServerTokens Prod
Dsactiver le mode trace
TraceEnable off
Pensez aussi journaliser correctement :
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog logs/access_log combined
Evitez les log DNS qui sont une mauvaise ide, car ils prennent du temps pour une information inutile,
voire dangereuse : l'information DNS peut changer entre le problme et sa dtection.
Idem pour les IdentityCheck, hormis cas particulier.
HostnameLookups Off
3.4. L'arborescence
3.4.2.Rpertoires et fichiers
Il faut aussi faire sortir de l'arborescence, tant que faire se peut, les fichiers qui n'ont pas vocation tre
directement visibles. En particulier tout ce qui concerne les include et les fichiers de donnes.
3.5.1.Mod_chroot
Mod_chroot qui se trouve sur http://core.segfault.pl/~hobbit/mod_chroot/permet de mettre Apache dans
un chroot, sans avoir copier les innombrables fichiers ncessaires son fonctionnement. Rapide et efficace, il
n'atteint pas, malgr tout, la prcision d'une installation manuelle. De plus, il sera ncessaire de garder l'esprit
que tous les programmes lancs par apache seront cantonns au rpertoire chroot.
SecChrootDir /chroot/apache
3.5.2.Mod_security
Mod_security se trouve sur http://www.modsecurity.org. Il permet de normaliser les urls avant l'envoi
aux divers modules, et surtout de reprer les chanes de caractres, ou plutt les expressions rgulires
dangereuses dans les variables envoyes, ainsi que reprer, dans les pages de retour, les informations qui sont
signes d'une attaque russie. Il est de plus capable de chrooter apache de la mme manire que mod_chroot.
Son emploi est plus adapt un Apache 2.x. Mais sa rputation est telle que dsormais il est intgr
dans quasiment toutes les distributions.
Les signatures sont, quant elles, gres par l'OWASP, qui les met jour rgulirement.
Il suffit alors en gnral de tout activer et de dsactiver les rgles une par une et par virtualhost.
secremovebyid 13789432
Par souci d'explication voici comment se passait anciennement l'installation et sa configuration.
yum install httpd-devel # Installation des libraires de dveloppements apache
cd /usr/local/src
wget http://www.modsecurity.org/download/mod_security-2.5.7.tar.gz
tar zxvf mod_security-2.5.7.tar.gz
cd mod_security-2.5.7/apache2
apxs -cia mod_security.c
ou plus simplement sur une ubuntu/debian
apt-get install libapache2-modsecurity
cd /etc/modsecurity/
cp modsecurity.conf-recommended modsecurity.conf
service apache2 restart
Puis configuration pour une instance donne, ou au global
#
#
# Dfinition du comportement mod_security
#
LoadModule security2_module modules/mod_security2.so
<IfModule !mod_unique_id.c>
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off
SecUploadKeepFiles Off
SecUploadFileLimit 10
SecDebugLog /var/log/httpd/modsec_debug.log
SecDebugLogLevel 0
# Audit log
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^5
SecAuditLogType Serial
SecAuditLogParts ABIFHZ
SecAuditLog /var/log/httpd/modsec_audit.log
SecTmpDir /var/lib/mod_security
SecDataDir /var/lib/mod_security
</IfModule>
On pourra trouver sur le site http://www.modsecurity.org/projects/rules/index.html des rgles de filtrage,
qui seront, bien videmment, adapter : on ne scurise pas une application simple comme le logiciel
phpmyadmin.
3.5.3.Suhosin
Ceci est un module pour PHP, qui va en combler les trous les plus flagrants. Il se compose de deux
parties indpendantes : un patch et une extension. On peut le trouver sur http://www.hardened-
php.net/suhosin.127.html.
Le patch va ncessiter de recompiler php (et tous ses modules). L'extension, quant elle, peut s'utiliser
seule sans modification. Mais elle ne donne sa pleine puissance qu'avec le patch.
3.5.4.Mod_evasive
Ce module permet de mettre en liste noire des machines qui tentent de saturer un serveur web, par des
requtes trop rapides. Voici un exemple de configuration pour apache 2.x. A mettre dans le httpd.conf. Une
option supplmentaire permet aussi de lancer une commande systme.
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
DOSEmailNotify webmaster@site.fr
DOSLogDir "/var/lock/mod_evasive"
DOSWhitelist 127.0.0.1
DOSWhitelist 193.49.*.*
</IfModule>
3.6.1.L'installation du chiffrement
En apache, le chiffrement se fait de manire relativement simple : l'coute se fera sur le port ddi 443.
Le reste dpendra des certificats obtenus, plus quelques options si l'on souhaite rcuprer des variables dans les
certificats (le nom de l'utilisateur en particulier). Nous ne nous attarderons pas ici sur la gnration des
certificats, qui relverait d'un chapitre complet.
Mais on pourra avec profit liminer les chiffrements les moins puissants en travaillent su sslciphersuite
(en particulier ssl v2). On pourra se reporter au site http://www.sslabs.com pour valuer cette robustesse.
<VirtualHost webmail.site.fr:443>
ServerAdmin reseau@site.fr
DocumentRoot /var/www/html_webmail/
ServerName webmail.site.fr
SSLEngine on
SSLCertificateFile /etc/httpd/conf/ssl.crt/webmail.site.fr.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/webmail.site.fr.key
SSLCertificateChainFile /etc/httpd/conf/ssl.crt/cachain.txt
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
ErrorDocument 402 https://webmail.site.fr/
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
ErrorLog logs/error_webmail_log
CustomLog logs/access_webmail_log combined
</VirtualHost>
3.7.2.Le SSO
Acronyme de Single Sign On, il dcrit un mcanisme d'authentification unique permettant l'utilisateur
de ne rentrer qu'une seule fois son mot de passe pour plusieurs applications (souvent web). Cela recouvre
plusieurs techniques bases quasiment toutes sur un serveur d'authentification.
Dans un cas le serveur connait tous les mots de passe et les fournit l'application qui le demande. Ceci
est particulirement dangereux : l'application va tre au courant du login et du mot de passe. Si elle est pirate ou
pirate, ceux-ci vont tre diffuss.
Dans le second, le serveur fournit l'identit du client et confirme son authentification l'application
demandeuse (voir par exemple le projet CAS). L'application ne connait donc pas le mot de passe.
3.8.1.Le mod_proxy
Le mod_proxy va permettre de placer un apache en frontal d'un autre serveur HTTP, de type apache ou
non. Cela va dcharger le serveur protg d'un certain nombre d'actions de scurit (voir le module
mod_security), et ventuellement du chiffrement des communications.
Le serveur frontal n'ayant qu'un rle de relais, on va pouvoir lui faire subir une cure d'amaigrissement,
toujours profitable, et lui restreindre ses possibilits de communications. Il deviendra alors moins vulnrable, et
moins capable d'actions nfastes.
Afin de pouvoir faire du reverse-proxying en toute circonstance, on regardera du cot de mod_ext_filter
pour faire une rcriture des urls, mme dans les javascript.
La configuration d'un reverse-proxy pouvant tre assez longue, nous laisserons le lecteur faire ses
propres recherches.
3.8.4.NGINX
Serveur web d'origine russe il est rput pour sa faible empreinte mmoire et CPU, ainsi que pour sa
rapidit. On l'utilise soit en remplacement, soit en reverse-proxy de Apache. http://www.nginx.org. Sa faible
modularit et sa rigidit en font un outil dur, mais terriblement efficace.
Certains le coupleront, profit, avec son module NAXSI qui fait du filtrage positif (on n'autorise que ce
que l'on connait) contrairement mod_security.
4. Paramtrer PHP
4.1. Le safe-mode
4.1.1.But
Le safe-mode est une configuration particulire du module PHP qui permet de limiter les actions
possibles pour le pirate, mais aussi celles du programmeur par la mme occasion. Mais elle n'est plus active
depuis la 5.4.0.
4.2.1.open_basedir
Permet de limiter louverture des fichiers un rpertoire donn. Attention bien le terminer par /. Ceci
est plus ou moins redondant avec le safe_mode.
4.2.2.disable_functions
On peut dsactiver des fonctions. Est-il indispensable de laisser les commandes system et readfile
actives ?
disable_functions readfile,system
4.2.3.disable_classes
Idem, mais avec les classes.
4.2.4.register_globals
Permet dviter que des variables internes aux scripts ne soient directement affectes dune valeur
par lutilisateur distant. Facilit offerte par PHP ses dbut, elle est devenue la principale cause de failles des
scripts PHP pendant une longue priode. Dsormais, depuis la version 4.2.0, elle est OFF par dfaut. Ce
changement a occasionn le mauvais fonctionnement de plusieurs milliers de scripts dans le monde.
register_globals off
Ce nouveau comportement implique que les variables seront dsormais rcupres par les tableaux
$_GET
$_POST
$_COOKIE
$_REQUEST (quivalent aux 3 premiers)
4.2.6.magic_quotes_gpc
Les variables peuvent tre utilises pour bloquer ou modifier le systme. magic_quotes_gpc est un
moyen efficace de protger le systme (particulirement les accs aux bases de donnes) dun comportement
imprvu. Magic_quotes_gpc va ainsi protger le systme des caractres NULL, \, quotes et guillemet " .
magic_quotes_gpc on
L'inconvnient de cette mthode est qu'elle alourdit les scripts, et rend toutes les variables sous forme
protg. Il faut alors, lors de l'affichage, toutes les dprotger par la fonction strip_slashes(). On peut ,
parfois, remplacer ce procd trs "dgt collatral" par une utilisation judicieuse de la fonction
add_slashes(). Il est d'ailleurs fortement question de remettre le magic_quotes_gpc off dans les futures
versions de PHP.
4.2.8.1.HTMLPURIFIER
Il s'agit d'une classe php qui va vrifier la conformit de la page et la nettoyer de tout XSS qui pourrait
tre prsent avant son affichage. Elle est disponible sur http://htmlpurifier.org/ et son utilisation est relativement
simple.
4.2.8.2.INPUTFILTER
Cest un ensemble de classes php, disponible ici, http://cyberai.com/inputfilter/ et qui permet de filtrer
les URLs et les variables des codes javascript, SQL injection ou autres.
4.2.8.3.PHP-IDS
Disponible sur http://php-ids.org, il permet de dtecter des utilisations potentiellement dangereuses en
donnant une valeur d'impact (de dangerosit). L'intgration dans le code source est relativement simple :
set_include_path(
get_include_path()
. PATH_SEPARATOR
. 'chemin/vers/la/bibliotheque/phpids'
);
if (!$result->isEmpty()) {
// On regarde le rsultat
echo $result;
}
5. MySQL
6. Programmer en PHP
Une fois que lon a pris en compte lenvironnement de travail, mis en place les protections ncessaires
sur les scripts PHP et autres fichiers de configuration, un grand nombre de choses restent regarder.
8.1.1.Nmap
Grand classique. Il permet de reprer les ports ouverts, la version du logiciel qui tourne (en se basant sur
les bannires). Il est disponible sur http://insecure.org
8.1.2.Wapiti
Scanneur de vulnrabilits inconnues, principalement pour XSS. Il est disponible sur
http://wapiti.sourceforge.net/.
8.1.3.Autres outils
NIKTO http://www.cirt.net/code/nikto.shtml (vulnrabilits web connues)
Nessus http://www.nessus.org (vulnrabilits connues)
Springenwerk http://www.springenwerk.org (failles XSS)
skipfish http://www.googlecode.com/skipfish (scanner exhaustif )
sqlmap http://sqlmap.sourceforge.net/ (SQL injection)
8.2.2.Pixy
8.2.3.RATS
http://www.securesoftware.com/resources/download_rats.html
9. URLographie
Voici quelques URLs sur la bonne protection des scripts en PHP
http://fr2.php.net/features.safe-mode
http://fr2.php.net/manual/fr/security.php
http://phpsec.org/
http://www.phpsecure.info/
http://shiflett.org/php-security.pdf
http://regexlib.com/
http://www.owasp.org/
http://www.securityfocus.com/infocus/1694
http://dev.mysql.com/doc/mysql/en/Security.html
http://www.securityfocus.com/infocus/1726
http://www.kitebird.com/articles/ins-sec.html
http://www.certa.ssi.gouv.fr/site/CERTA-2007-INF-002.pdf
http://www.certa.ssi.gouv.fr/site/CERTA-2004-INF-001/index.html
http://www.apachesecurity.net/ (horse book de chez O'Reilly)
http://en.wikibooks.org/wiki/Programming:PHP:SQL_Injection
10.Autres informations
Ce document est largement perfectible. n'hsitez pas me signaler les erreurs et les amliorations
l'adresse fabrice.prigent@laposte.net.
Il est disponible sous licence creative commons http://creativecommons.org/licenses/by-nc-sa/2.0/fr/