Introduction

Il existe différents serveurs web mais le plus connu et utilisé est Apache.

Le serveur web permet de gerer les accès aux différents services web. C'est lui qui permet notamment d'orienter les requêtes de connection vers les bons services. Par exemple, si on tape l'URL http://calendriers.example.org/ c'est le serveur web qui va fournir l'accès à l'application de calendrier installé sur la machine (avec des options d'accès et de sécurité qui vont avec) alors que si on tape http://www.example.org/ on sera dirigé par le serveur web vers un site web situé dans un certain repertoire (avec d'autres options le cas échéant).

Apache

Créer des VirtualHost pour Apache

Pour gérer vos différents services, le plus simple est de créer un fichier pour chacun. Ces fichiers contiennent la configuration de nos différents VirtualHosts (VH).

Par exemple, si vous voulez avoir un site web accessible via www.example.org mais aussi un accès privé à votre calendrier via adresse cal.example.org vous devez créer deux fichiers distincts dans le répertoire dédié à cela c'est à dire /etc/apache2/sites-available

Notez que la configuration des VH n'est pas suffisante, il faut également s'assurer que la configuration DNS de votre domaine indique la correspondance entre les sous-domaines que vous souhaitez héberger sur un site web et l'adresse ip de votre serveur web.

Dans chaque fichier, il faut mettre quelque chose du type :

<VirtualHost *:80> 
ServerName www.example.org 
DocumentRoot /var/www/site/
</VirtualHost>

Une fois le fichier créé, il faut activer le VH en tapant :

a2ensite nom-du-fichier 

puis relancer apache avec

service apache2 reload

ou

service apache2 restart

Chaque VH peut donc être configuré à souhait en fonction des besoins (voir ces détails sur les pages dédiées aux différents services.)

Utiliser des aliases

Si par exemple, vous ne voulez pas utiliser de sous-domaines comme truc.example.org, vous avez la possibilité d'accéder à vos services en utilisant des adresses du type www.example.org/service

Cela peut se faire très simplement en ajoutant le répertoire du service à la racine de votre VH. Dans le cas présenté ci-dessus si vous avez un service de calendrier que vous appelez cal, il faut mettre les fichiers relatifs à ce service dans un répertoire suivant : /var/www/site/cal

Le problème inhérent à ce choix est la difficulté de gérer de manière indépendante les services. En effet, si vous avez attribué des paramètres à /var/www/site alors les répertoires situés plus bas comme /var/www/site/cal vont hériter de ces paramètres. De plus, la structure n'est pas mobile et si vous déplacez un répertoire, il ne sera plus accessible à cette adresse. L'autre solution est donc créer des aliases. Dans le fichier du VH de www.example.org, il suffit d'ajouter un ligne du type :

 Alias /public /media/data/echanges

De ce fait, si votre répertoire echanges change de place, il suffit de donner le nouvel emplacement dans la configuration de votre VH.

Configuration des VH

C'est dans le fichier du VH que l'on peut mettre certains attributs, comme les droits ou le mode d'affichage. Reprenons notre exemple précédent quelque peu agrémenté :

<VirtualHost *:80> 
ServerAdmin admin@example.org 
ServerName www.example.org
DocumentRoot /var/www/site

<Directory /var/www/site> 
    Options -Indexes +Includes +FollowSymLinks +MultiViews 
            AllowOverride All 
    Order allow,deny 
    Allow from all 
</Directory> 

  Alias /public /media/data/echanges 

  ErrorLog ${APACHE_LOG_DIR}/error.log 

Dans ce cas, on a renseigné le mail de l'administrateur du site, puis on indique à quelle adresse ce site est joignable et on indique le répertoire contenant tous les fichiers relatifs au site.

Ensuite, la partie contenue entre <Directory> et </Directory> permet de préciser des options relatives à un répertoire. Il peut y avoir plusieurs sections de ce type à la suite si on veux préciser des options différentes pour différents répertoires. Ici, nous avons indiqué -Indexes qui signifie que les fichiers ne seront pas listés dans le navigateur. +FollowSymLinks signifie que l'on pourra utiliser les liens. Les paramètres présents ici varieront en fonction du service que vous allez installer.

Sécurité

Gestion des permissions pour les différents services web

Par défaut, nous appliquons des permissions restrictives sur les fichiers accessibles par le web et donc par le serveur web :

  • Les fichiers et les répertoires appartiennent à l'utilisateur et au groupe de l'administrateur du serveur (typiquement, votre user).

  • Le serveur web tournant sous l'utilisateur www-data, il n'est pas propriétaire des arborescences. Dans le triptyque des permissions user-group-other, il fait partie du groupe other les permissions sur les répertoires sont positionnés en 705 (lecture-écriture-exécution pour l'administrateur du serveur, lecture-exécution pour le serveur web). Cela permet au serveur web de parcourir les arborescences sans pour autant pouvoir créer de nouveaux fichiers ou répertoires.

  • Les permissions sur les fichiers sont positionnés en 604 (lecture-écriture pour l'administrateur du serveur, lecture pour le serveur web) Cela permet au serveur web de lire les fichiers des arborescences sans pour autant pouvoir modifier les fichiers.

  • Souvent, un service web nécessite un espace où il a des permissions en écriture (cet espace est soit un espace temporaire, un espace de cache, ou bien un répertoire de stockage des ressources générées ou uploadées par les utilisateur du service web)

Dans ces cas-là, essayons autant que possible de localiser ce(s) répertoire(s) hors du répertoire du serveur web /var/www. Des liens symboliques dans /home/<user>/web/*, par exemple /home/<user>/files/ ou /home/<user>/tmp/ est une bonne suggestion (cela nécessite souvent une configuration complémentaire du service web, pour lui indiquer où stocker ses données). Si cela n'est pas possible, et en dernier recours, nous ajoutons des permissions plus larges mais uniquement sur le répertoire temporaire ou le répertoire de cache, car cela constitue une faille potentielle de sécurité en augmentant la surface d'attaque de notre serveur.

En positionnant la variable d'environnement umask 0077 (voir la section configuration de l'environnement utilisateur), nous avons positionné des permissions par défaut en 700 pour les répertoires et en 600 pour les fichiers, nous avons donc une configuration par défaut encore plus restrictive et sécurisée que prévu ci-dessus. Il faut donc explicitement rendre les arborescences accessible au serveur web par la commande suivante (à défaut, le serveur web retournera une erreur pour cause d'arborescence non accessible) :

find /var/www/monservice/ -type d -exec chmod 705 {} \;
find /var/www/monservice/ -type f -exec chmod 604 {} \;

Note : toute installation d'un service web doit respecter ces préconisations de sécurité, même si cela n'est pas explicitement indiqué.

Mieux, utiliser le module apache mpm-itk

Avec le module mpm-itk, chaque virtual host peut tourner sous son propre user. Cela permet une isolation de chaque virtual host et donc une meilleure sécurité du serveur.

Ce n'est cependant pas suffisant. En effet, interdire à un virtual host d'aller écrire dans l'arborescence d'un autre virtual host est essentiel, mais il importe également d'empêcher une intrusion extérieure, et donc d'empêcher le virtual host d'écrire dans les fichiers qu'il doit servir.

Si toutefois le virtual host en question doit écrire dans un répertoire (sessions, cache, fichiers uploadés), alors ce répertoire ne doit pas faire partie de wwwroot ( /var/www ). Cette restriction permet d'empêcher un utilisateur qui uploaderait un fichier php, de l'appeler ensuite via son url et d'exécuter ce script sur lequel nous n'aurions alors plus aucune contrôle.

En empêchant le virtual host d'écrire dans le wwwroot, on bouche ainsi une faille potentielle du serveur.

La base est que chaque virtual host dispose de son propre user :

  • www-data : user par défaut
  • www-service1 : user pour le service1
  • www-service2 : user pour le service2
  • www-service3 : user pour le service3
  • etc...

Chaque user appartient à un groupe portant le même nom.

Ensuite, il faut associer les users des administrateurs aux groupes des sites dont chaque administrateur s'occupe :

  • le user admin1 fait partie du groupe www-service1
  • le user admin2 fait partie des groupes www-service2 et www-service3

Dès lors, toute les conditions sont réunies pour permettre la modification du propriétaire et des permissions des arborescences. Prenons par exemple l'arborescence du service service1 :

Les répertoires et les fichiers du virtual host service1.example.org appartiennent au user admin1 et au groupe www-service1 et leurs permissions sont respectivement :

  • 750 pour les fichiers
  • 640 pour les fichiers
  • par conséquent admin1 peut lire et écrire dans ces répertoires tandis que le user www-service1 peut uniquement lire

Si jamais, un répertoire doit être positionné en lecture/écriture pour apache/php, alors il suffit de modifier ses permissions en 770. Ainsi, le user www-service1 (donc le user apache via mpm-itk) peut alors écrire dans le répertoire, idem pour les fichiers qui passent en 660. Mais ce cas là doit rester une exception, car entraînant une faille de sécurité potentielle.

Protection d'un répertoire par un fichier .htaccess

Un fichier .htaccess permet de restreindre l'accès à une répertoire à des utilisateurs authentifiés par un login et un mot de passe. L'authentification souvent utilisée s'appelle basic authentication. Cette authentification est tout à fait déconseillée dans le cas d'un service sur http (non sécurisé) car le mot de passe est transmis en clair dans les trames réseau et donc facilement interceptable par quelqu'un qui serait en écoute quelque part entre le serveur et le client.

La basic authentication n'est à utiliser que sur des connexions http sécurisées, dites https.

Le http sécurisé : https

Comme http n'est pas sécurisé, il existe une solution plus sécurisée appelée https. Ce protocole https n'est rien d'autre que le protocole bien connu http, sous lequel on glisse une couche de sécurisation par chiffrement appelée TLS (pour Transport Layer Security). Parfois connu sous le nom de SSL (pour Secure Sockets Layer), SSL est en réalité l'ancêtre de TLS, la version précédente. On utilise donc aujourd'hui TLS pour sécuriser http et aboutir à https.

Pour mieux comprendre et mettre en place votre protocole https sur votre serveur, rendez-vous sur cette page

L'établissement d'une connexion https sécurisée par TLS nécessite la présence d'un certificat. Il existe des certificats de différents types :

  • Auto-signé : celui qui génère le certificat clame aussi que le certificat est valide. Cela peut-être une faiblesse dans le cas où une personne mal-intentionnée pourrait utiliser un certificat pour sécuriser une connexion : le fait que la connexion est sécurisée ne signifie par forcément que l'interlocuteur est honnête.

  • Signé par une autorité de certification reconnue : le certificat généré par l'interlocuteur a été signé par une autorité de certification reconnue (comme VeriSign) qui approuve le fait que le certificat appartient bien à la personne (physique ou morale) qui dit en être la propriétaire. L'autorité de certification est censée vérifier la légalité de la demande, et l'existence de la personne, avant de signer le certificat. Dans les faits, ces autorités de certification sont souvent critiquées par la légèreté de leurs procédures de vérification, et par le juteux business qu'elles génères : signer un certificat ne coûte rien, ou pas grand chose, mais les certificats signés sont facturés bien cher.

  • Signé par une autorité de certification communautaire : le certificat généré par l'interlocuteur a été signé par une autorité de certification communautaire (comme CAcert) qui approuve le fait que le certificat appartient bien à la personne qui dit en être propriétaire. Les contrôles effectués par CAcert sont des plus léger, CAcert ne faisant pas payer les certificats qu'elle signe, elle ne dispose pas de budget pour effectuer des contrôles poussés. Il faut donc s'en remettre à la confiance dans la communauté.

Une fois les certificats (auto-)signés disponibles, il faut les installer sur le serveur et modifier la configuration pour que les certificats soient pris en compte. On peut aussitôt les utiliser et commencer une connexion https sécurisée.

Si vous disposez déjà de certificat, alors vous n'avez rien de spécial à faire. Dans le cas contraire, vous pouvez générer des certificats auto-signés (vous seul affirmez que vos certificats sont valides) ou bien signé par une autorité de certification. CAcert est une autorité de certification animée par une communauté et propose de signer des certificats sans contrepartie financière. Vous pouvez facilement générer vos propres certificats en suivant ce mode d'emploi.