Une petite sécurité supplémentaire pour Apache

Trucs et Astuces
#1

blabla :
Voici une sécurisation supplémentaire d’Apache pour un serveur web.
Elle est réalisable simplement à l’aide d’un script.
Celui-ci permet au seul ‘root’ de créer ou de modifier les dossiers/fichiers contenus dans /var/www.
Le reste du monde ne pourra même pas y accéder, ce qui met à l’abri de la lecture d’éventuels mots de passe dans certains fichiers de config.

En pratique :

  • Copiez/collez le script ci-dessous dans un fichier que vous nommerez “www-securiser”.
    Il sera placé dans le dossier /usr/local/bin de votre serveur et vous lui donnerez les droits 750.
    Ce fichier devra être exécutable.

Vérifiez que le chemin /usr/local/bin soit bien dans le PATH pour réduire la commande à un simple :

Merci à Syam pour l’élaboration du script et pour les précisions supplémentaires qui suivent :

Attention ! Certaines applications web ont besoin de pouvoir écrire dans certains répertoires spécifiques. Si vous les installez manuellement à partir des sources il faudra prendre ça en compte.
Les répertoires concernés sont en principe indiqués dans la documentation d’installation de l’application web en question, que vous avez dû lire (ou devriez avoir lu).
Pour qu’elle fonctionne sans problème il vous faudra ajuster les droits de ces répertoires à la fin du script “www-securiser”.

Par exemple Drupal utilise le répertoire sites/default/files pour stocker des fichiers (temporaires ou ceux que vous uploadez à travers Drupal), il faudra donc rajouter la ligne suivante :

Certains fichiers dans ces répertoires ne devraient pas pouvoir être modifiés (par exemple les .htaccess). Utilisez votre bon sens et modifiez les droits de ces fichiers lorsque nécessaire :

# chmod -R g-w /var/www/chemin/vers/drupal/sites/default/files/.htaccessFaites bien attention à l’ordre dans lequel vous écrivez ces commandes dans le script “www-securiser”, n’oubliez pas que c’est la dernière commande exécutée qui a raison

SCRIPT

[code]#!/bin/sh

Nom du script : www-securiser

Emplacement : /usr/local/bin

Droits : 750.

Fonction : une fois les interventions effectuées, modifier le propriétaire et le groupe

#+ des nouveaux fichiers/dossiers contenus dans /var/www, puis en modifier les droits
#+ afin que /var/www soit de nouveau sécurisé.

chown -R root:www-data /var/www
find /var/www -type f -print0 | xargs -0 chmod 640
find /var/www -type d -print0 | xargs -0 chmod 750

Dans les lignes suivantes, vous indiquerez les chemins des éventuels fichiers/dossiers

#+ qui nécessitent d’être ouverts en permanence comme expliqué dans le “blabla”.

Vous pourrez ajouter autant de lignes que d’applications concernées

chmod -R g+w /var/www/chemin/vers/dossier/X-X-X (ligne(s) à compléter et à décommenter)

Selon le même principe, vous exclurez des précédents dossiers les fichiers/dossiers

#+ qui doivent, eux, rester invisibles de l’extérieur.

chmod -R g-w /var/www/chemin/vers/dossier/X-X-X/fichier_à_cacher (ligne(s) à compléter et à décommenter)

Reportez-vous au “blabla” pour un exemple concret avec l’application ‘Drupal’

exit[/code]

RÉCAPITULATIF :

[ul]
[li]bloquer l’ensemble de /var/www avec la commande :

[li]Pour intervenir, débloquer les droits des répertoires de cache, upload etc. de façon à le faire en tant que simple utilisateur, avec la commande :

À noter que la précédente commande peut être réduite à # chown -R userftp /var/www
À noter que l’on peut en faire un script plus mémorisable comme, par exemple : www-liberer
.[/li]
[li]Une fois l’intervention effectuée, sécurisez de nouveau avec la commande :

#2

Restreindre à root la création/édition de fichiers web à root me semble excessif et même à la limite dangereux. En effet, à la moindre modification d’un fichier, on sera tenté de se connecter et travailler sous root (ou sudo) ce qui n’est pas recommandé et certainement pas pratique. Surtout en FTP où les données de connexion sont transmises en clair. Pourquoi ne pas simplement laisser www-data propriétaire des fichiers (configuration par défaut de Debian) et se rajouter dans le groupe www-data? Il suffit ensuite de mettre 770 sur les répertoires et 660 sur les fichiers. Pour les fichiers sensibles, contenant des mots de passe, il suffit de les mettre hors DocumentRoot d’Apache dans un répertoire sécurisé. Mais tout ça est personnel et sujet à discussion.

#3

Si on part du principe que le MDP root est le plus sophistiqué et donc le plus difficile à trouver, la sécurité est maximale.
Je t’accorde que ça relève de la paranoïa, mais j’assume.
Mais libre à toi de laisser le monde entier faire ce qu’il veut dans ta “maison” :smiley:

#4

[quote=“ricardo”]Mais libre à toi de laisser le monde entier faire ce qu’il veut dans ta “maison” :smiley:[/quote]De ce côté, je ne cours pas beaucoup de risques. J’utilise mon user normal sur mon lan. De l’extérieur seules les ip autorisées peuvent accéder au serveur en ssh (ou SFTP) par clés publiques/privées. Jamais au grand jamais en FTP simple! Comme la sécurité d’un serveur n’a que la solidité de son maillon le plus faible, je protège aussi du mieux possible mes applications web des attaques classiques, principalement injection SQL, et je surveille mes log. Une alarme m’est envoyée en cas d’anomalie. Et, surtout je reste attentif et me remets régulièrement en question au fil de mes expériences.

[quote=“ricardo”]Si on part du principe que le MDP root est le plus sophistiqué et donc le plus difficile à trouver, la sécurité est maximale.
Je t’accorde que ça relève de la paranoïa, mais j’assume.[/quote]
Ton conseil pourrait conduire les utilisateurs à travailler sous root pour modifier ou transférer les fichiers web ce qui n’est pas vraiment une bonne idée, même en local. Par ailleurs, il ne faut pas croire que ce qui est sous root est mieux protégé. C’est une illusion, illusion dangereuse à mon sens. Avec des droits 750 ou 740 ton user normal lit de toute façon tous les fichiers web puisqu’il est dans le groupe www-data. De plus, www-data est un user sans possibilité de login et avec des droits restreints. Il ne peut donc pas faire grand chose sur ta machine. Non, franchement Ricardo, Debian à très bien configuré par défaut son serveur web. :wink:

#5

Étant donné qu’initialement c’est moi qui ai donné cette astuce (que j’utilise) dans un fil de support, et que ricardo l’a retranscrite ici pour qu’elle ne se perde pas aux tréfonds du forum, je vais compléter les explications.

Tout d’abord, j’avais pas fait gaffe mais il manque le script “jumeau” pour débloquer les droits afin que l’utilisateur (S)FTP puisse modifier les répertoires.

La procédure que j’utilise lorsque je veux mettre à jour les fichiers www est :

  • débloquer les droits avec root/sudo (chown userftp:www-data)
  • modification via (S)FTP avec l’utilisateur non privilégié “userftp”
  • rebloquer les droits avec root/sudo (chown root:www-data)

Au delà de la protection des mots de passe dans les fichiers de config, ça élimine surtout une catégorie d’attaques très courante où, à cause d’une faille dans une appli PHP, le serveur web se retrouve capable d’enregistrer un script néfaste sur le disque, script qui sera alors exploitable de l’extérieur. Personnellement c’est ma principale motivation pour utiliser cette procédure. Bien évidemment il faut que l’ensemble soit configuré correctement, notamment interdire l’exécution de scripts dans les éventuels répertoires d’upload que l’appli utilise pour son stockage de fichiers (courant pour les CMS).
Le choix de root n’est pas non plus si important que ça puisque bien évidemment la vraie protection vis à vis de cette attaque est d’empêcher www-data d’écrire sur le disque ; simplement, le fait d’utiliser root permet aussi de forcer l’utilisation du script de déblocage avant toute modification, donc de “vérifier” que la personne faisant les modifs a bien un accès root.
D’autre part si on respecte la procédure, même en cas de brèche sur le compte utilisateur (S)FTP il n’y a aucune possibilité de modifier le contenu du site web puisque seul root peut débloquer les droits et autoriser l’écriture.

Quant à ton argument “on sera tenté de se connecter et travailler sous root (ou sudo)”, il est certes vrai mais on ne pourra jamais empêcher les gens de se comporter comme des idiots. Cette procédure est faite pour augmenter la sécurité du dossier /var/www et c’est bien évident que si on ne suit qu’une partie de la procédure (verrouillage des droits) puis qu’on outrepasse cette sécurité en uploadant directement sous root, ça n’a plus aucun intérêt.

#6

Je comprends mieux la démarche, et elle est justifiée, mais pourquoi root? En mode protection, un simple www-data:www-data 440 sur les fichiers et 550 pour les répertoires devrait suffire non? Et en mode de modification/téléchargement 660 et 770 devrait faire l’affaire.

J’ai vraiment du mal avec root comme propriétaire. Ça me fait comme un blocage. root ne me semble pas être fait pour ça. Et à la moindre occasion, les utilisateurs négligents ou distraits finiront par faire un 777 pour avoir la paix. Mais, tu vas me dire - à raison - qu’on ne peut pas empêcher les cons de faire les cons! :wink:

#7

Non : PHP permet de faire des chmod, à la condition (comme d’habitude) que ça soit le propriétaire du fichier qui l’effectue (alors le groupe ne peut pas changer ses propres droits).
Autrement dit, si www-data est propriétaire alors il peut changer les droits, mais si n’importe qui d’autre est propriétaire alors www-data ne pourra pas changer les droits. Pour que la protection soit sûre, il faut un propriétaire différent de l’utilisateur Apache.

Sous Linux, seul root peut changer le propriétaire d’un fichier. Étant donné que la sécurité repose sur le fait d’avoir un propriétaire différent, que tu attribues les fichiers à root ou à qui que ce soit d’autre ne change pas grand chose : il faudra toujours un shell root ou bien un script “sudo-isé” pour changer le propriétaire (personnellement je n’aime pas la méthode “sudo” pour des raisons que je vais expliquer juste après).
Tu pourrais effectivement attribuer les fichiers à ton utilisateur (S)FTP, du coup il n’y aurait pas besoin de débloquer les droits avant l’upload mais juste de les rectifier (bloquer) après upload pour s’assurer que tous les fichiers ont les bons droits. Mais ça veut dire qu’une brèche dans ton utilisateur (S)FTP permet de modifier les fichiers, alors que si root est propriétaire il faut :

  1. se connecter en tant qu’utilisateur non privilégié
  2. prendre les droits root avec su (si je n’aime pas sudo c’est parce qu’en cas de brèche sur ton utilisateur non privilégié, il peut alors utiliser sudo… alors qu’avec su il faut en plus trouver le mot de passe root)
  3. débloquer les droits

Comme tu peux le voir ça laisse pas beaucoup de place pour un éventuel attaquant. Je suis tout à fait conscient de sacrifier le côté pratique pour gagner (marginalement) en sécurité, mais que veux tu quand on est parano on compte pas… :wink:

Quitte à me faire des copains, j’estime que les utilisateurs négligents ou distraits (ou carrément incompétents) ne devraient pas maintenir un serveur ouvert sur le net (bien évidemment je ne dis pas ça dans le sens “je leur refuse ce droit” mais plutôt “c’est donner le bâton pour se faire battre”).

#8

Tuto légèrement modifié :
modif du nom "securiser ==> www-securiser"
ajout explicatif et commande pour intervenir en tant que simple utilisateur, juste avant le script.