La première et la plus radicale des restictions possibles est de désactiver l'interprétation des scripts PHP globalement sur le serveur avec la directive engine off. On pourra les autoriser ensuite dans les VirtualHosts par des directives spéciales comme décrit dans Section 5.2.4, « Exceptions ».

Même si ce n'est pas un moyen de protection valable, on peut toujours masquer la présence de PHP afin de rendre les choses plus difficiles pour les éventuels attaquants. PHP est plutôt verbeux sur sa présence. On trouve même dans les versions récentes, des URL easter-eggs ^[10]. On pourra les supprimer en mettant la variable expose_php ^[11] à Off. Cela ne suffit bien sûr pas : quand on a affaire à des fichiers se terminant par .php, cela lève le doute assez rapidement... Il faudra donc aussi modifier le handler PHP, définit dans /etc/apache2/mods-available/php5.conf pour y ajouter d'autres extensions moins « bavardes ». On pourra même demaner à Apache de renvoyer tous les fichiers .html au moteur PHP. C'est discret, mais le coût en performance peut être important si la proportion pages statiques/pages dynamiques est défavorable sur le serveur.

Lorsque PHP est activé (globalement, ou sur un virtualhost), la dernière chose que nous voulons le voir faire est de charger du code à notre insu. Il est donc conseillé de mettre la valeur de enable_dl à Off. allow_url_fopen permet de charger du code PHP distant en ouvrant un URL (par include ou fopen). Il faudra aussi désactiver cette possibilité en mettant la directive à Off.

PHP a toujous été handicapé par la nécessité de maintenir une certaine compatibilité ascendante. Les variables register_globals, register_long_arrays et register_argc_argv font partie de cet héritage. Mais pour déployer des scripts « modernes » et surtout bien écrits, il n'est pas nécessaire (et même dangereux) d'activer ces paramètres. Il faudra donc tous les mettre à Off.

PHP sait faire beaucoup. Parfois un peut trop dans le contexte de scripts web. Il est heureusement possible de desactiver certaines fonctions du language avec disable_functions. Il est probablement plus sûr de désactiver les fonctions suivantes : chgrp, chmod, chown, diskfreespace, dl, escapeshellcmd, exec, get_current_user, getmypid, getmyuid, getrusage, highlight_file, ignore_user_abord, ini_alter, ini_restore, ini_set, leak, link, listen, login, passthru, php_uname, popen, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, proc_get_status, proc_nice, proc_open, proc_terminate, set_time_limit, shell_exec, show_source, socket_bind, socket_listen, system et virtual. Attention toutefois : on ne peut configurer ce paramètre que dans php.ini, et non dans la configuration d'Apache (principale ou virtualhost). La valeur affectée sera donc globale.

Sur des serveurs ayant plusieurs virtualhosts, il est préférable de restreindre l'accès au filesystem aux secteurs strictement nécessaires. L'utilisateur alice qui met ses pages, par exemple, dans /home/alice/www/ n'a pas besoin d'ouvrir des fichiers se trouvant au dessus de son répertoire web dans le filesystem. Le paramètre open_basedir permet de configurer un répertoire au dessus duquel il ne sera pas possible d'ouvrir de fichier. Il conviendra de le spécifier dans chaque virtualhost.

doc_root permet de spécifier la racine des scripts php, à ne pas confondre avec open_basedir qui donne la racine de tous les fichiers accessibles par PHP (éventuellement des fichiers de données ou des fichiers de session).

Pour des raisons de sécurité, on veillera aussi à déplacer le répertoire utilisé pour stocker les fichiers de session (par défaut, /var/lib/php5/ sous Ubuntu). Il faudra créér un répertoire propre à chaque virtualhost, afin de limiter les éventuels problèmes de vol de session. On utilisera la variable session.save_path pour spécifier le nouveau répertoire et on veillera à mettre une valeur située sous celle d'open_basedir. Dans le cas contraire, PHP ne pourrait sauver les fichiers de session.

Selon la destination du serveur, on pourra être tenté de positionner la variable file_uploads à off. Cela désactivera la possibilité d'envoyer des fichiers en POST vers des scripts PHP.

Si l'on désire conserver cette possibilité, il vaut mieux modifier la variable upload_tmp_dir et lui affecter un répertoire accessible depuis le virtualhost (donc sous le répertoire pointé par open_basedir).

Un paramètre regroupe à lui seul plusieurs restrictions améliorant la sécurité : safe_mode. Il permet notamment de faire respecter les droits associés aux fichiers (un fichier appartenant à X ne pourra être utilisé par un script appartenant à Y) et d'empécher la modification des variables d'environnement listées dans le paramètre safe_mode_protected_env_vars.

Le paramètre safe_mode désactive aussi certaintes fonctions, listées dans le manuel de PHP, donc la plupart sont déja couvertes par la valeur recommandée pour disable_functions. Il faudra donc mettre cette valeur à On sans hésiter.