En d'autres termes, le cloisonnement permet d'isoler les différents services installés sur une seule machine. Dans ce chapitre, je vous propose d'auditer ce principe de cloisonnement en se penchant sur les comptes système utilisés pour chaque service et sur le processus d'isolation, ou chroot.
Auditez les comptes Linux associés aux services
Dans un premier temps, il est nécessaire de vérifier que les services sont lancés avec un compte (système ou utilisateur) qui dispose des privilèges nécessaires à l'exécution de ce service. Regardons cela dans la vidéo ci-dessous.
Dans la plupart des cas, le compte associé au service est indiqué dans les fichiers de configuration.
Reprenons l'exemple du service HTTPD :
[root@fichesproduits ~]# ps -edf | grep httpd root 817 1 0 07:39 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND apache 973 817 0 07:39 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND apache 974 817 0 07:39 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND apache 975 817 0 07:39 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND apache 976 817 0 07:39 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND apache 977 817 0 07:39 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND apache 1634 817 0 09:26 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
Vous pouvez ici constater que le processus père est lancé avec l'utilisateur root, ce qui est indispensable pour que le service ouvre un port < 1000 sur le serveur. Par contre, vous constatez également que les threads (fils) sont attribués à un utilisateur non privilégié, dans notre cas apache.
Vous pouvez retrouver cette configuration dans le fichier httpd.conf :
[root@fichesproduits ~]# grep apache /etc/httpd/conf/httpd.conf # See <URL:http://httpd.apache.org/docs/2.4/> for detailed information. # <URL:http://httpd.apache.org/docs/2.4/mod/directives.html> User apache Group apache # http://httpd.apache.org/docs/2.4/mod/core.html#options
Pour obtenir des informations sur le compte apache, lancez les commandes suivantes :
[root@fichesproduits ~]# id apache uid=48(apache) gid=48(apache) groupes=48(apache) [root@fichesproduits ~]# grep apache /etc/passwd apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin [root@fichesproduits ~]# grep apache /etc/group apache:x:48:
L'UID du compte apache est inférieur à 100. Généralement, sur Linux, cette plage est justement réservée aux comptes système. Par ailleurs, vous pouvez aussi constater que le shell du compte pointe vers /sbin/nologin, ce qui est une bonne configuration. Il n'y a aucune raison que les comptes système chargés de l'exécution de services se connectent et obtiennent un shell sur le serveur. Enfin, le compte apache possède son propre groupe primaire apache.
Enfin, lancez la commande apachectl évoquée dans le chapitre précédent avec le filtre suivant :
[root@fichesproduits ~]# apachectl -S | grep DocumentRoot Main DocumentRoot: "/var/www/html" [root@fichesproduits ~]#
Le DocumentRoot du serveur Apache est le répertoire par défaut des sources applicatives. Il peut en exister un différent pour chaque site hébergé par le service. Vous pouvez consulter les attributs du répertoire avec la commande suivante :
[root@fichesproduits ~]# ls -lrtha /var/www/ total 4,0K drwxr-xr-x. 2 root root 6 5 nov. 2018 html drwxr-xr-x. 2 root root 6 5 nov. 2018 cgi-bin drwxr-xr-x. 4 root root 33 27 mars 09:43 . drwxr-xr-x. 21 root root 4,0K 27 mars 09:50 ..
Ici, le répertoire est la propriété du compte root et tout le monde peut y accéder. Cette configuration par défaut n'est donc pas acceptable.
Par exemple ici, vous pourriez passer les commandes suivantes :
chown -R apache:apache /var/www/html/ chmod -R 750 /var/www/html/
Auditez l'isolation des services lancés
Dans l'idéal, il faudrait attribuer une machine et un système d'exploitation à chaque service. Cette solution drastique est coûteuse en matériel et en maintenance. Aujourd'hui, il existe plusieurs solutions d'isolation moins coûteuses :
les conteneurs, où un même noyau gère plusieurs instances système ;
la virtualisation, où un hyperviseur gère plusieurs machines virtuelles émulées sur la même machine physique ;
un hyperviseur noyau, comme Linux KVM.
Ici, nous pourrions envisager d'émuler deux machines virtuelles avec VirtualBox (gratuit sous Linux) afin d'y installer, pour l'une le serveur Web Apache HTTPD, et pour l'autre la base de données MySQL. Bien entendu, il faudrait que ces machines communiquent via un réseau. Celui-ci pourrait être spécifique (nous y reviendrons dans la partie 5 de ce cours).
Sous Linux, il existe également un processus de cloisonnement historique nommé chroot. Cette technique utilise l'argument obligatoire, passé à tous les processus lors de leur exécution, désignant leur racine dans l'arborescence et dont la valeur est par défaut est / . Le chrootage consiste à donner à cet argument une valeur différente de / pour ce répertoire (/directory par exemple). Le résultat de cette opération limite le processus affecté dans cette sous-arborescence.
On peut regarder cela en vidéo ensemble, vous trouverez également la commande ci-dessous.
Par exemple, en exécutant une commande du type :
chroot /directory /directory/command
La commande va alors considérer /directory comme /.
Par exemple, considérons le service HTTPD. Un attaquant qui profite d'un défaut de configuration pourrait obtenir des accès sur l'arborescence du serveur. Le processus de chrootage d'Apache limiterait ces accès. La directive ChrootDir du module unixd_module permet de réaliser cette opération.
Il n'y a aucun sens à chrooter certains services, comme sshd, et ce pour plusieurs raisons :
l'objectif de ssh étant de fournir un shell distant aux utilisateurs connectés, il est nécessaire d'inclure toutes les commandes possibles dans l'environnement isolé, ce qui n'est pas chose évidente ;
un administrateur se connectant via ssh aura bien du mal à effectuer une opération de maintenance ou de restauration de service s'il est restreint dans un environnement spécifique.
Ceci dit, cette opération reste faisable, et il est possible d'isoler directement le processus ssh ainsi que les utilisateurs s'y connectant. Pour cela, vous allez pouvoir utiliser respectivement la commande chroot ou le module pam_chroot.so
Cependant, le processus d'isolation chroot présente quelques faiblesses :
le cloisonnement est limité en ce qui concerne les accès aux systèmes de fichiers, mais pas en ce qui concerne les accès aux processus ou aux réseaux ;
les utilisateurs peuvent sortir de leur environnement spécifique en utilisant des processus externes.
En résumé
Nous avons ici abordé les notions de cloisonnement pour les services lancés sur le serveur. Chacun de ces services laisse des traces dans des fichiers spécifiques via un service dédié. Dans le chapitre suivant, je vous propose de voir comment vérifier la sécurité relative à ce service spécifique.
