Le Hardening système

4 min. lecture

Share

Les bonnes pratiques de configuration permettent d’éviter un certain nombre d’actions malveillantes sur les systèmes. De nos jours, avec l’arrivée de nouveaux services, nous voyons de plus en plus de nouvelles applications, nécessitants des serveurs applicatifs pour s’exécuter. Cela augmente donc les surfaces d’attaques exploitables. Cependant un ensemble d’actions peuvent permettre d’assurer un minimum la sécurisation des serveurs portant les applications. C’est dans cette optique que nous allons discuter du hardening système. Qu’est-ce que le Hardening Système ? Le Hardening Système vise à fortifier une machine, un serveur, un poste client, dans l’optique d’en augmenter le niveau de sécurité. Le but premier du hardening est de réduire le nombre d’objets (utilisateurs, bibliothèques, applications, etc.) présents sur le système, en ne conservant que ceux qui sont nécessaires au bon fonctionnement du serveur et du service rendu par ce dernier. Un certain nombre de guides sont disponibles, en générale, rédigés par des agences de sécurités influentes. Ils visent à établir un socle « sain » en atteignant des niveaux de sécurité plus ou moins élevés sur certains aspects du système. Il est possible de trouver sur internet des guides de Hardening fournis par exemple par la NSA, le CIS, le DISA. Pour une même technologie, il existe quelques différences de prérequis entre ces différents guides pour être « compliant ». Un guide de hardening peut être lié à un standard (hardening guide PCI-DSS), à une application/un serveur applicatif (hardening guide Apache Tomcat) ou à un système d’exploitation (hardening guide Windows Server). Nous discuterons dans cet article des guides de hardening STIG (Security Technical Implantation Guides) fournis par le DISA (Defense Information Systems Agency). Pour rappel la DISA est l’agence Américaine assurant le contrôle des communications, de l’informatique, les renseignements pour les combattants. [caption id="attachment_3486" align="alignnone" width="180"]

DISA[/caption] Le standard STIG et son utilisation Les guides de hardening STIGs sont fournis par le DISA dans le but de fixer des niveaux de sécurité à observer pour le DoD Américain (U.S. Department of Defense). Un STIG est donc une sorte de “checklist”. Chaque vérification (check) est identifiée par un ID et associée à un niveau de criticité (CAT.1 le plus critique, CAT.3 le moins critique). Liste des rapports : http://iase.disa.mil/stigs/Pages/index.aspx En termes d’implémentation, il ne s’agit pas d’appliquer l’ensemble des correctifs fournis par un STIG. Cela est en général incompatible avec la façon dont fonctionne de manière spécifique un système au sein d’un environnement autre que celui du DoD. L’idée ici est donc de reprendre certains points clés, qui sont intéressants et qui concernent des éléments que l’on peut modifier sur le système sans impacter l’expérience utilisateur. Pour ce faire, il est intéressant de se focaliser sur les niveaux de criticités I (fort) et II (moyen) et de cibler les éléments qui nous intéressent. [caption id="attachment_3488" align="alignnone" width="180"]

Linux hardening[/caption] Exemple d’action de Hardening Linux Nous allons nous intéresser au STIG pour les systèmes Linux Red Hat EL6 en notant ici quelques éléments de criticité élevée (CAT.I) en les commentant un peu pour vous donner une overview de ce que l’on peut trouver. Exemples de quelques règles de CAT.I :

  • The system must not have accounts configured with blank or null passwords.
    • Afin d’éviter que quelqu’un n’étant pas autorisé à accéder au système puisse s’y connecter. Un énorme trou de sécurité.
  • The telnet daemon must not be running.
    • Pour éviter à de potentielles informations critiques de transiter sans être encryptées (informations de login, de session, retours de commandes, etc.).
  • The SSH daemon must not allow authentication using an empty password.
    • Permet de s’assurer qu’une connexion distante nécessite un mot de passe. Cela permet d’interdire un accès d’un compte utilisateur sans mot de passe par exemple.
  • The x86 Ctrl-Alt-Delete key sequence must be disabled.
    • Cette combinaison de commande permet, sur un système RHEL6, de redémarrer la machine.
  • The snmpd service must not use a default password.
    • Quiconque peut interroger un service snmpd qui tourne sur un serveur peut récupérer des informations sur le système. Donc lorsque le mot de passe du service snmpd est celui par défaut… c’est l’occasion pour n’importe qui non autorisé de récupérer des informations potentiellement sensibles !

Le Hardening n’est donc pas une action curative et doit être appliqué en vue d’éviter un problème et non pas suite à un problème. De même, l’ensemble d’un standard n’est pas à prendre et à appliquer aveuglement. Cependant certaines « bonnes idées » peuvent en être extraites et appliquées. S’appuyer sur des hardening guides est une bonne base pour définir les prérequis que les machines (postes clients et/ou serveurs) de l’entreprise doivent respecter, un peu à l’image d’une PSSI. En se concentrant sur la mise en place de ces mesures, un certain nombre d’actes malveillants peuvent déjà être évités. La sécurité du système d’information n’en est que meilleure.

Inscrivez-vous à notre newsletter

Recevez dans votre boîte aux lettres électronique les dernières nouvelles sur la sécurité, des informations et les tendances du marché.

À la une

Plus de nouveautés