Devensys Cybersecurity – The Blog

Linux possède en grand nombre d’outils permettant de sécuriser les applications ce qui permet parfois de stopper un attaquant qui a déjà compromis un service hébergé. Cependant, ces outils demandent parfois une configuration manuelle ou sont parfois méconnus. Les Linux Security Modules (LSM) font partie de ces outils, leur position privilégiée dans le noyau leur procure une vue globale de tout le système. Il existe plusieurs LSM, notamment SELinux et AppArmor. 

Qu’est-ce que les Linux Security Modules ?

SELinux est un système de sécurité pour Linux permettant de limiter les actions possibles en fonction d’une politique de sécurité, il permet d’appliquer notamment différentes méthodes de contrôle d’accès obligatoire. SELinux a un fonctionnement différent de celui d’Apparmor, mais il est également bien plus complet (et complexe !). Il se base sur des étiquettes attribuées à des ressources en plus de politiques. Celui-ci est activé par défaut sur Red Hat Enterprise Linux (et dérivés) et il est fortement recommandé de le laisser activé. 

Apparmor est un autre module de sécurité et de contrôle d’accès obligatoire pour Linux. Celui-ci repose principalement sur des chemins de fichiers. Cependant, il peut limiter l’accès à de nombreuses autres ressources et capabilities. Sa configuration est uniquement textuelle et sous forme de profils par application. Combiné avec ses outils d’administration, il est simple et rapide à mettre en place. 

Ces deux outils sont capables de fonctionner en mode alerte uniquement (Complain/Permissive), ce qui permet de ne pas perturber le bon fonctionnement de vos services. Les messages générés signalent toute infraction et fournissent une trace auditable. C’est pourquoi il est vivement conseillé d’activer ces modules même s’ils ne seront jamais en mode strict/défense. (enforce)  

Il est également possible d’installer des antivirus (gratuit comme ClamAV, ou commerciaux comme Microsoft Defender for Endpoint), ce qui est parfois requis par le niveau de sécurité choisi par votre entreprise (ou même la législation en vigueur) 

Apparmor, un allié pour sécuriser vos serveurs Linux

Aujourd’hui, nous allons nous concentrer sur Apparmor, de par le niveau plus réduit de configuration requis. Dans cette optique, nous allons protéger un serveur Nginx en créant des règles de sécurité. Le nombre de règles disponibles sur internet est limité, il est donc probable que rédiger des règles propres à votre infrastructure soit nécessaire. Nous considèrerons que la distribution utilisée est Debian Linux pour toucher le plus grand nombre d’utilisateurs. 

Avant de démarrer, nous allons rappeler ce que sont les capabilities sous Linux, vu que cette notion entrera en jeu un peu plus tard lors de la configuration. Historiquement, l’utilisateur administrateur ROOT possédait tous les droits sur la machine, sans aucune restriction. C’est pourquoi le système de capabilities a été introduit. Toutes les permissions de l’utilisateur root sont maintenant séparées en capabilities. Par exemple, net_bind_service permet à un programme de se positionner en écoute sur un port privilégié (en dessous de 1024), mais n’octroie aucune autre permission. Il est donc possible d’être administrateur ROOT avec aucune capabilities et donc sans les pleins pouvoirs. Inversement, un programme avec un utilisateur non privilégié peut obtenir des capabilities supplémentaires, obtenant une partie du pouvoir de ROOT. 

Apparmor est administré avec différents outils de gestion, ceux-ci ne sont pas toujours installés par défaut. C’est pourquoi la première étape sera de corriger cela : 

sudo apt install apparmor-easyprof apparmor-profiles apparmor-profiles-extra apparmor-utils nginx 

La commande précédente a également installé le serveur Nginx s’il n’était pas déjà installé. Nginx est fourni avec une page web d’exemple qui sera suffisante pour cet article. Mais si vous possédez une application web avec sa configuration nginx associée, vous pouvez les utiliser sans problème. (Bien entendu, évitez de faire ceci en production sans avoir testé la solution au préalable) 

Comment créer un profil Apparmor ?

La manière la plus simple de créer un profil Apparmor est tout simplement de prendre un profil de base ou vide et d’activer le mode « complain ». Par défaut tout est refusé, c’est donc en utilisant les messages d’infraction de ce mode qu’il est donc possible de créer notre profil par « apprentissage ». Il est essentiel que le comportement de l’application pendant ce temps d’apprentissage soit normal et correct, et que toutes les fonctionnalités de l’application soient exploitées. Dans le cas contraire, notre profil ne serait pas complet : car une fonctionnalité non explorée lors de l’apprentissage pourrait solliciter une ressource que nous n’avions pas autorisée dans notre profil AppArmor. 

Les profils sont stockés dans le dossier /etc/apparmor.d, avec comme nom le chemin de l’exécutable à limiter avec les slash « / » remplacés par des points « . » .  Un utilitaire existe pour créer un profil initial : 

sudo aa-autodep /usr/sbin/nginx 

Ensuite, activons le profil en mode « complain » 

sudo aa-complain nginx 

Redémarrons nginx : sudo service nginx restart 

Maintenant, naviguez avec votre navigateur web sur la page par défaut d’Nginx. (http://127.0.0.1 ou l’IP du serveur) Si vous avez une application existante, utilisez un maximum de fonctionnalités. (Tout particulièrement si vous avez choisi un autre programme que Nginx Il s’agit de créer une empreinte du comportement normal de l’application. 

Une fois l’apprentissage terminé, il suffit d’examiner les infractions et valider celles qui sont normales, afin de les ajouter en tant qu’exception dans notre profil Apparmor. Pour cela, nous allons utiliser aa-logprof : 

sudo aa-logprof 

Gérer les infractions avec Apparmor

Ce programme va parcourir tous les messages d’infraction et demander, une par une quelle action est désirée. La décision sera retranscrite dans le profil. 

Nous allons passer en revue toutes les actions nécessaires, ce qui nous permettra également de voir une majeure partie des cas de figure qui seront applicables à d’autres applications. Les infractions ne seront pas obligatoirement identiques ou listées dans le même ordre sur votre terminal. Une réflexion restera tout de même nécessaire pour ajuster la politique aux besoins de votre installation. 

Ce menu nous permet de choisir si l’infraction est erronée et doit être autorisée et ajoutée au profil. Celui-ci sera répété pour chaque infraction et nous allons voir ses différentes variantes. 

Ici, la capability dac_override permet d’ignorer le contrôle d’accès sur les fichiers. De la même manière que les permissions sur les fichiers ne s’appliquent pas à l’utilisateur root (par défaut). Cette permission est nécessaire si le fichier de log d’Nginx n’appartient pas à un groupe ou utilisateur dont Nginx fait partie. Ce qui est le cas par défaut. Si vous changez le propriétaire du fichier à l’utilisateur d’Nginx (www-data) dans ce cas vous pouvez appuyer sur D ou I pour refuser cet accès. Sinon dans la majorité des cas, appuyez sur A pour autoriser. Notez que cette capability reste limitée par Apparmor, même en la possédant il reste impossible d’accéder à des fichiers auxquels Apparmor bloque l’accès. 

Cette infraction est une tentative d’accès en écriture à un fichier. Ici, il s’agit du fichier de log d’erreur, autorisez en appuyant sur A. Faites de même pour /var/log/nginx/access.log quand demandé. 

Ici, nous avons un premier exemple de multiples actions possibles. Celles-ci sont numérotées de 1 à 3. Les crochets [ et ] marquent la ligne et l’action actuellement sélectionnée. Pour en changer, appuyez sur le numéro correspondant ou tout simplement utilisez les touches fléchées du clavier. 

Les lignes contenant un #include indiquent qu’Apparmor a détecté un profil de base contenant les permissions nécessaires pour autoriser cette infraction. C’est à vous de décider si la suggestion est judicieuse.  

Dans ce cas, le profil /abstractions/openssl correspond parfaitement, donc gardez-le sélectionné et appuyez sur A pour l’autoriser. 

L’accès à la configuration est bloqué, ce cas est similaire au cas des logs, mais l’accès est en lecture uniquement (r) . Sélectionnez A. 

Ici, nous avons deux nouveautés, tout d’abord c’est une permission sur un dossier, en lecture (r). Ensuite, le profil de base détecté n’est pas correct. Totem est un lecteur multimédia, et n‘a aucun rapport avec notre application. Utiliser ce profil accorderait bien trop de permissions inutiles à Nginx. Utilisez les flèches ou la touche 2 du clavier pour sélectionner l’action owner /etc/nginx/modules-enabled/ r . owner signifie que Nginx doit être propriétaire du fichier/dossier concerné. 

Même problématique ici. Le profil totem n’est pas le plus adapté. Cependant autoriser uniquement le fichier mod-http-geoip.conf semble trop restrictif, il parait plus logique d’autoriser Nginx à lire tous les fichiers de configuration des modules. Pour cela, sélectionnez G ou E. E est plus restrictif donc le plus adapté. G autorise tous les fichiers du dossier et E tous les fichiers avec l’extension indiquée (.conf). Le tout dans le monde indiqué : lecture (r). N’oubliez pas de vérifier que la nouvelle option est bien sélectionnée après avoir sélectionné G ou E et avant de confirmer avec A : 

Ce fichier contient le numéro de processus. Nous pouvons lui donner la permission en lecture et écriture (rw). Sélectionnez A. 

Ici, il s’agit de donner l’accès aux fichiers des pages web. En principe, il est nécessaire de donner accès à tous les fichiers récursivement dans ce répertoire du site web. Mais le profile présélectionné web-data s’en charge déjà. Validez avec A. 

De la même manière, autorisez également : 

• A – /etc/nginx/mime.types – r 
• A – [2 – owner /etc/nginx/conf.d/ r,]  – r 

• A – [2 – owner /etc/nginx/sites-enabled/ r,] – r 
• G – /etc/nginx/sites-available/default  et ensuite : A – [2 – owner /etc/nginx/sites-available/* r,] 

Pour terminer, le profil nameservice est correct. Sélectionnez-le avec A. 

Sauvegarder les changements dans le fichier profil

Une fois à la fin des infractions, aa-logprof demande une confirmation pour sauvegarder ces changements dans le fichier du profil : 

Appuyez sur S pour les sauvegarder. 

Au moment de l’écriture de cet article, une fois le profil sauvegardé, une permission nécessaire n’est pas automatiquement assignée dans le profil. Nous allons donc l’ajouter manuellement.  

En effet, Nginx fonctionne à l‘aide d’un processus parent et de processus enfants effectuant le travail. Le processus parent nécessite la permission d’exécuter les processus enfants en tant qu’utilisateur moins privilégié. Il a besoin des capacités (capabilities) setgid et setuid . Nous allons également ajouter deux autres capabilities, pour autoriser l’écoute sur un port privilégié. (80) 

Sudo nano /etc/apparmor.d/usr.sbin.nginx 

Profitons-en pour assouplir certaines permissions qui n’ont pas pu être détectées par aa-logprof, car l’installation par défaut d’Nginx sous Debian n’est pas très complexe. 

Une fois que vous avez inspecté les règles pour confirmer leur cohérence, vous pouvez les sauvegarder et quitter (CTRL+S puis CTRL+X).   

Voici le fichier au complet : 

#include <tunables/global> 

/usr/sbin/nginx { 

  #include <abstractions/base> 

  #include <abstractions/nameservice> 

  #include <abstractions/openssl> 

  #include <abstractions/web-data> 

  capability dac_override, 

  capability dac_read_search; 

  capability net_bind_service; 

  capability setgid, 

  capability setuid, 

  /usr/sbin/nginx mr, 

  /var/log/nginx/access.log w, 

  /var/log/nginx/error.log w, 

  owner /etc/nginx/conf.d/ r, 

  owner /etc/nginx/mime.types r, 

  owner /etc/nginx/modules-enabled/*.conf r, 

  owner /etc/nginx/nginx.conf r, 

  owner /etc/nginx/sites-available/* r, 

  owner /etc/nginx/sites-enabled/* r, 

  owner /run/nginx.pid rw, 

  owner /usr/share/nginx/modules-available/*.conf r, 

} 

Pour recharger ce profil uniquement, utilisez  

Sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx 

(  Pour recharger toutes les règles : systemctl  reload apparmor  ) 

Activer le mode bloquant sur le profil

Passez maintenant le profil en mode bloquant/strict : sudo aa-enforce nginx 

Maintenant, il suffit de redémarrer Nginx : systemctl restart nginx 

Sudo aa-status devrait afficher les processus comme « confined » : 

Si vous vous rendez sur la page d’exemple de Nginx (http://127.0.0.1 ou IP du serveur), la page s’affiche normalement sans problème. 

Cependant, si l’on configure Nginx pour servir un dossier en dehors de /var/www/html, l’accès sera refusé au programme et celui-ci retournera une erreur HTTP 403.  

Voilà, en cas de compromission du processus d’Nginx, celui-ci n’aura accès à aucun fichier du disque et ses permissions limitées rendront l’élévation de privilège très compliquée.  

Pour aller plus loin : 

Dans le cas ou un accès global à tous les sous-dossiers est nécessaire, il est possible de doubler le *. Par exemple, owner /etc/nginx/** r, autorise l’accès à tous les fichiers, dossiers et sous-dossiers (récursivement) possédés par l’utilisateur de Nginx dans le dossier /etc/nginx. 

Apparmor est également capable de gérer les signaux Unix et les sockets Unix, si cela est nécessaire. 

Ici, l’accès au réseau n’est pas limité. Au moment de l’écriture de cet article, cette fonctionnalité d’Apparmor n’est pas encore entièrement opérationnelle. Dans ce cas, d’autres modules de sécurité tels que SELinux peuvent être utilisés à la place d’Apparmor ou encore certains modules du pare-feu. 

Par Jérémy LIMOUSIN