Dans le chapitre précédent, vous avez découvert le périmètre de l'audit de sécurité. Avant de vous lancer dans les aspects techniques, je vous propose, dans ce chapitre, de parcourir les trois grands principes de sécurité des systèmes d'exploitation :
minimisation ;
moindre privilège ;
défense en profondeur.
Ces principes sont décrits notamment en introduction du guide de recommandations de l'ANSSI, l'agence nationale de la sécurité des systèmes d'information, un partenaire et une référence indispensable.
Découvrez le principe de minimisation
Dès le début des années 1990, lorsque le noyau Linux est devenu stable, il a été possible d'installer un système GNU/Linux grâce aux distributions. Ces dernières rassemblent sous la forme de packages, installés par défaut ou non, des fonctionnalités et des services.
Grâce à ces fonctionnalités et services, on dispose rapidement et facilement d'une machine répondant à un besoin spécifique (serveur Web, serveur de messagerie, ordinateur de bureau, etc.).
Sauf dans le cas où vous utiliseriez des distributions spécifiques (comme Slackware ou LFS), le processus d'installation standard d'une distribution Linux va déclencher un certain nombre d'opérations et activer des fonctionnalités et services par défaut. Cela peut être un service de messagerie alors que vous installez un serveur de base de données, un service DHCP alors que vous disposez d'une adresse IP statique, etc.
Par ailleurs, pour tous les services et fonctionnalités installés, la distribution va écrire une configuration par défaut : le démarrage automatique de tel service, le port en écoute, ou encore le chargement de tel module du noyau, etc.
Le principe de minimisation consiste à étudier, après l'installation du serveur, l'ensemble des services et processus installés et configurés par défaut afin de les maîtriser. Cette étude permet notamment de :
réduire la surface d'attaque potentielle du serveur. Par exemple, un service SMTP qui s'exécute inutilement est une cible potentielle d'attaque ;
réduire le nombre de composants exploités au strict minimum pour assurer les tâches de mise à jour de manière optimale ;
permettre la mise en place d'une supervision efficace et probante sur un nombre réduit et maîtrisé de composants.
Découvrez le principe de moindre privilège
Sous Linux, « tout est fichier » ! Cet adage est en réalité un héritage des premiers systèmes Unix et notamment de Rudd Canaday, l'un de ses inventeurs et le premier à conceptualiser tout le système d'exploitation en fichiers. Sous Linux donc, un processus est un fichier, un périphérique de type bloc est un fichier (disque dur, clé USB, etc.), une socket (port en écoute sur le réseau) ou un tube nommé sont des fichiers, etc.
Associée à ce concept primaire, la gestion des droits sous Linux est dite discrétionnaire. Avec le DAC (Discretionary Access Control), les droits sont gérés directement par les utilisateurs (ou les groupes qu'ils forment). Par exemple, si je suis propriétaire d'un fichier sous Linux, j'ai la possibilité d'indiquer moi-même les droits d'accès à ce fichier sous la forme de trois étiquettes classiques :
lecture : la ressource peut être lue ou chargée en mémoire ;
écriture : la ressource peut être créée ou modifiée ;
exécution : la ressource peut être exécutée en tant que programme.
Enfin, le super administrateur root dispose de tous les droits sur le système.
Bien entendu, ce principe va, par exemple, vous permettre de détecter que tel processus s'exécute sous l'utilisateur root alors qu'il n'a pas besoin d'autant de privilèges, ou que telle arborescence sensible du système de fichier est trop permissive.
Les objectifs de cette démarche de moindre privilège sont avant tout de :
s'assurer qu'un processus qui sort de son périmètre fonctionnel classique (par anomalie technique ou par malveillance volontaire) soit le moins nocif possible, car contraint par des droits d'accès bien gérés ;
s'assurer qu'il n'est pas possible d'effectuer des actions dangereuses pour le système sans disposer de privilèges élevés, qui ne sont pas simples à acquérir (protection par mot de passe fort, fichiers de trace, etc.).
Découvrez le principe de défense en profondeur
Ce troisième principe est souvent le plus coûteux à mettre en place ( en termes de charge humaine et de matériel ), car il complexifie par nature l'architecture système et applicative des SI.
Pour illustrer, prenons un exemple très classique. Pour mettre en place un serveur d'applications Web Java sous Tomcat, reposant sur une base de données MySQL, vous pouvez tout à fait installer l'ensemble des composants de cette architecture sur un seul et même serveur (ce que vous ferez très probablement pour votre environnement de développement). En faisant ainsi, comprenez qu'une faille sur l'un des composants peut mettre en danger les autres. Le principe de défense en profondeur préconise de séparer les composants applicatifs :
un serveur frontal (Apache par exemple) ;
un serveur pour l'application (Tomcat) ;
un serveur pour la base de données (MySQL).
Ainsi, une faille sur le composant le plus exposé, dans notre cas Apache, ne permettra pas, ou du moins autorisera plus difficilement, l'accès aux données en base. Évidemment, il est nécessaire d'installer et de maintenir trois serveurs au lieu d'un.
Cependant, le principe de défense en profondeur s'applique également sur le périmètre d'un serveur unique. Les objectifs étant les mêmes :
compliquer au maximum les attaques, et
disposer de traces permettant de détecter très rapidement les tentatives de compromission.
Concrètement, ce principe va le plus souvent résulter en :
une séparation des services réseaux (voir exemple ci-dessus) ;
la mise en place d'un processus d'authentification manuel obligatoire pour toute action privilégiée ;
la mise en place d'une gestion centralisée et sécurisée des traces (journaux d'évènements applicatifs ou système) ;
un cloisonnement systématiquedes processus exposés.
En résumé
Ces trois grands principes généraux de sécurité sont à la base de toute démarche de protection d'un système d'exploitation. Je vous invite à bien les garder en mémoire pendant toute la durée de l'audit afin de vous guider dans vos réflexions.
En matière de sécurité, le bon sens est aussi un atout formidable ! Vais-je cloisonner un serveur d'archives, accessible uniquement via son port SSH, installé au fin fond du dernier bastion de mon SI ? Probablement pas. Un changement de port et un mot de passe fort suffiront amplement. Second point très important également, l'application de ces principes est certes fortement recommandée mais ne suffit jamais ! Il faut toujours l'accompagner d'une démarche de veille permanente, qui repose principalement sur deux piliers :
la supervision : consultez les traces de vos serveurs vocaux. Et s'ils vous crient qu'ils sont attaqués, réagissez immédiatement ;
les mises à jour : vérifiez constamment que vos composants sensibles n'ont pas besoin d'être mis à jour. Corrigez ici une faille critique sur SSH, là une autre concernant HTTPD ou MySQL, etc.
