Sécuriser son serveur Apache (en particulier PHP et sites dynamiques) : Bloquer l’accès aux fichiers de sauvegardes et aux fichiers temporaires

Dans cet article, j’indique une mesure de sécurité utile (voire cruciale) pour ceux qui font tourner un site dynamique sous Apache : comment empêcher l’accès aux fichiers de sauvegarde et fichiers temporaires générés automatiquement par les éditeurs de texte. Ces fichiers peuvent en effet parfois contenir des informations ultra-sensibles tels que des mots de passe.

Qu’est ce qu’un fichier de sauvegarde ou un fichier temporaire (ou de sauvegarde automatique) ?

Les fichiers de sauvegarde sont souvent générés par les éditeurs de texte (tels que vim, emacs, gedit, kate, notepad++) pour vous permettre de conserver une ancienne version au moment où vous sauvegardez. Ils ont un nom qui se termine souvent par le symbole “~” (pour une majorité de programmes sous Linux ou provenant du monde Linux/Unix) ou par “.BAK“.

Je ne rentrerais pas dans le détail des extensions car chaque programme peut très bien utiliser une extension qui lui est propre, mais une très grande majorité d’éditeurs possède cette option, assez souvent activée d’origine.

La plupart du temps, cette option est perçue comme une fonctionnalité utile, qui permet parfois de s’en sortir après une erreur. (Je dis bien parfois, ce n’est pas le top pour revenir en arrière à volonté…)

Les fichiers de sauvegarde automatique (“auto save“) sont des fichiers temporaires (parmi d’autres) qui ont vocation à permettre de sauver la situation lorsqu’un problème survient et que l’utilisateur n’a pas préalablement enregistré manuellement son travail.

Bref, tous ces fichiers ont leur utilité, mais leur présence peut également parfois devenir problématique voire dangereuse.

Pourquoi est-ce crucial de restreindre l’accès à ces fichiers ?

Si ces fichiers sont présents sur un serveur, deux types de problèmes peuvent survenir :

1. Il est possible d’accéder à une version antérieure sans forcément que vous l’ayez prévu. Ce type de problème peut toucher aussi les éléments statiques (exemples: “index.html~“, “style.css~“). C’est parfois un problème.
2. L’extension étant différente des fichiers associés, ces fichiers sont bien souvent renvoyés tels quels sans même être interprétés (on voit le source). Cela peut permettre la fuite d’informations très sensibles comme des mots de passe. Un exemple de fichier de sauvegarde que bien peu de personnes partageraient volontiers : wp-config.php~ (fichier de configuration de WordPress qui a de fortes chances de contenir le mot de passe de connexion à la base MySQL).

wp-config.php

Il faut noter que même si votre site ne représente pas un enjeu crucial et que même si tout le monde vous veut du bien, cela ne vous protégera en aucun cas contre certains bots “méchants”, tournant souvent sur des “PCs zombis”, et scannant très vite de manière automatique tous les sites qu’ils peuvent trouver.

Si vous doutez du nombre de PCs zombis, regardez si vous avez du spam dans votre boite email, sinon demandez à des amis s’ils n’ont jamais reçu trop de spam. La majorité du spam est en effet envoyé par des botnets (réseaux de PCs zombis).

Protections “de base” : savoir, identifier, supprimer, ne pas transférer…

Savoir l’existence des fichiers de sauvegarde et savoir ce qu’il peut se passer lorsqu’ils sont accessibles vous évitera naturellement pas mal d’erreurs.

Il est également utile de chercher régulièrement à identifier les éventuels fichiers problématiques.

Depuis le terminal, sous Linux, une fois positionné dans le dossier qui contient les fichiers qui seront mis sur le serveur, vous pouvez par exemple faire un “find . | grep ~$” (attention, cela ne s’occupe que des fichiers qui se terminent par “~”). Si vous n’êtes pas très familier avec les expressions régulières de la commande grep, utilisez la commande less avec sa fonction de recherche qui s’active par la touche [/] et ou vous utilisez [n] pour voir le résultat suivant (pensez à revenir au début après chaque extension testée avec [Début/Home] et quittez less avec [q]).

UPDATE (13/05/2011, merci à chimrod pour son commentaire) : Vous pouvez également détecter les fichiers se terminant par “~” avec “find . -name *~“. Je vous invite à jeter un coup d’oeil à la documentation de find, vous pourrez y trouver pas mal d’options utiles (dont le “ou logique” avec l’option “-o“).

L’idéal, c’est de pouvoir le faire aussi sur le serveur (si vous pouvez vous y connecter en SSH ou si vous hébergez le site sur votre PC par exemple).

Supprimer les fichiers problématique avant d’envoyer des fichiers sur le serveur, ou empêcher qu’ils se génèrent (options de l’éditeur de texte) est plus que souhaitable !

Vous pouvez également tout simplement ne pas transférer certains fichiers lorsque vous envoyer le contenu au serveur, enfin cette méthode n’est pas simple pour tout le monde (si vous utilisez rsync pour envoyer au serveur, ce n’est qu’une petite option).

En cas de problème détecté

Si vous avez trouvé une faille, il faut savoir ce qui a pu (directement ou indirectement) être compromis.

Différentes actions peuvent être à prendre, suivant le contexte :

• Vérifiez l’allure de votre site : c’est bête mais parfois les sites sont défacés, ou plus subtilement des liens sont insérés…
• Vérifiez le code source du site : les liens peuvent être cachés (rendus invisibles par CSS ou javascript). Le but est souvent de s’approprier (directement ou indirectement) du “jus de PageRank” pour l’orienter vers un ou plusieurs sites. Avec des liens en masses et des sites peu recommandables, votre site peu plonger au fond des abimes de Google…
• Changez les mots de passe (base de données, wordpress, etc…)
• Adaptez, réfléchissez, sécurisez. Puis soufflez et surtout revenez-y plus tard !

Protection recommandée sous Apache (httpd)

Si vous utilisez Apache comme serveur, je vous recommande simplement de vous arranger pour que le serveur refuse de fournir les fichiers qui ont certaines extensions.

Il faut pour ce faire compléter votre fichier .htaccess (ou le fichier de configuration au niveau serveur). Voici un exemple (à compléter), de lignes qui peuvent vous épargner de gros soucis :

## Protection partielle, à compléter selon les éditeurs de texte utilisés
<FilesMatch "(\\.(swp|SWP)[.[:alnum:]]*|\\.bak|\\.BAK|\\$|~)$">
 order deny,allow
 deny from all
</FilesMatch>

Avec cette solution, qu’il y ait ou non un fichier de sauvegarde qui existe sur le serveur, si l’extension testée par le “méchant pirate” (ou le script) est dans la liste, alors le serveur renvoie une page “Accès interdit” (erreur 403). Il vous faut bien sûr faire attention à vérifier le périmètre d’effet du fichier de configuration ou .htaccess que vous avez édité.

Sécuriser son serveur Apache (en particulier PHP et sites dynamiques) : Bloquer l’accès aux fichiers de sauvegardes et aux fichiers temporaires
(fr) Commenter cet article - Partager - Lire un autre article (Blog de David Dallet)
(en) Comment this post - Share It - Read another post on David Dallet's Weblog