D’un point de vue conception, les points sensibles résultent de certains choix techniques qui peuvent faciliter la tâche d’une personne malveillante pour porter atteinte à la confidentialité, à l’intégrité et à la disponibilité des ressources et des services. Ces choix techniques ne sont pas pour autant des erreurs de conception, mais plus généralement des fonctionnalités censées apporter de la puissance et de la souplesse au système. Ces points sensibles se retrouvent sous différentes formes selon les systèmes d’exploitation et les choix de conception qui ont été faits, et ils doivent être connus par l’administrateur de sécurité.

D’un point de vue exploitation, il est fréquent d’observer des situations d’exception qui perdurent, comme par exemple la création de comptes de maintenance non supprimés après intervention ou l’ouverture de services de confort. Les cas d’urgence multiplient en effet les risques de manipulations aux effets indésirables. Cependant, au-delà de ces cas exceptionnels, on s’aperçoit qu’une dérive du niveau de sécurité en conditions opérationnelles est quasi-inéluctable au vu du nombre de paramètres à administrer et à contrôler. Il est nécessaire de mener un suivi en exploitation des paramètres les plus sensibles du système pour maintenir dans le temps un niveau de sécurité opérationnel du système.

La connaissance de ces points sensibles liés à la conception et à l’exploitation constitue un point de départ essentiel pour garantir les propriétés de sécurité requises à un instant initial. Cependant, une fois le système en production, les questions essentielles à se poser sont :

• Avez-vous bien décrit toutes les procédures d’installation, de mise à jour, de maintenance pour l’exploitation de votre système d’information ?
• Etes-vous sûrs que ces procédures sont toujours respectées à la lettre ?
• Et s’il y avait des dérives ? L’erreur est humaine ! Il ne faut pas exclure que même l’administrateur système le plus consciencieux peut avoir un moment d’inattention, être dérangé pendant une procédure, ou tout simplement être noyé sous la charge de travail en cas d’urgence. Le turnover des effectifs est également un paramètre à considérer comme facteur aggravant les risques de dérives.

En tentant de répondre à ces questions, on s’aperçoit rapidement que même si des recommandations décrivent les bonnes pratiques censées permettre le maintien du niveau de sécurité initial en conditions opérationnelles, il est indispensable de se doter d’outils permettant de contrôler la bonne application de la politique de sécurité pour parer à toute dérive indésirable dans le temps.

Définition et distribution de la politique de sécurité

Définir une politique de sécurité commence par la constitution d’une liste d’exigences informelles, décrivant généralement l’ensemble des actions autorisées ou interdites. Cette politique pourra ensuite être exprimée de façon formelle à l’aide des modèles de contrôle d’accès existants (RBAC, OrBAC, etc.). Dans l’optique du maintien du niveau de sécurité opérationnel, cette politique de sécurité devra inclure la définition des contrôles à effectuer et les contre-mesures à appliquer. La plupart du temps, la notion de contre-mesure sera réduite à son strict minimum, c’est-à-dire à l’avertissement de l’administrateur par le biais d’alertes, afin qu’il puisse procéder par lui-même aux rectifications nécessaires.

De façon pratique, quelques exigences à définir sont par exemple :
• Les services autorisés (liste de ports), les autres étant interdits par défaut,
• Les règles de filtrage indiquant qui a le droit de s’y connecter,
• Les règles pour surveiller le propriétaire, le groupe et les droits sur les fichiers,
• La politique de mots de passe (types de caractères, nombre minimum de caractères, etc.),
• Les règles de contrôle des droits sur des fichiers particuliers ou des arborescences définies,
• Les profils de comptes utilisateurs (conventions de nommage, harmonisation sur les différents serveurs, etc.).
• Etc.

Les exigences ainsi définies par la politique de sécurité doivent être traduites et distribuées sous forme d’actions sur les points de contrôle. Par exemple, la liste des services autorisés et les règles de filtrage indiquant qui a le droit de s’y connecter pourront être dérivées en une série de règles de filtrage.
Détection des violations de la politique de sécurité

Afin de maintenir le niveau de sécurité en exploitation, il faut être capable de détecter les violations de la politique de sécurité pour réagir au plus vite. L’idée est de s’assurer de la non-dérive de la politique de sécurité sur les serveurs d’un parc de machine, ou tout du moins, la détection de cette dérive afin de notifier à l’administrateur la nécessité d’une action corrective.

Les principaux éléments à surveiller sont :
• Les comptes et habilitations,
• Les programmes SUID et SGID,
• Les fichiers spéciaux (devices),
• Les démons,
• Les fichiers de configuration sensibles,
• Les environnements de travail des utilisateurs,
• Les modules chargés par le système.

Pour ce faire, les mécanismes à mettre en œuvre sont principalement de quatre types : le contrôle d’intégrité, la vérification de la conformité de certains éléments par rapport à des profils de référence, la détection des vulnérabilités (hors vulnérabilités logicielles), et la journalisation. Nous décrivons ces quatre points par la suite.

Contrôle d’intégrité

Une grande partie du travail pour maintenir le niveau de sécurité opérationnel, et par conséquent la non-dérive dans le temps des exigences définies à la mise en production, consiste en la mise en œuvre de contrôles d’intégrité sur les ressources. Ceci est notamment valable pour les fichiers spéciaux, qui constituent une base importante de certains systèmes en termes de sécurité, mais aussi pour tous les fichiers standard sensibles, comme les binaires systèmes, les applications métiers, et les fichiers de configuration.
Le contrôle d’intégrité repose sur un mécanisme d’empreinte (ou de photographie) prise à l’instant initial. Cette empreinte constitue la référence en termes de sécurité à la mise en production du système. Typiquement, la prise d’empreinte est effectuée grâce à des fonctions de hachage (ex : MD5, SHA-1, etc.). La prise d’empreinte considère différents paramètres, à commencer par le contenu des fichiers et leurs attributs (propriétaire, groupe, droits, date de création, date de modification, taille, etc.). Elle devra également intégrer le suivi des fichiers suid, les numéros major et minor pour les devices, l’intégrité du noyau, les modules ou encore les comptes et groupes utilisateurs. Le principe consiste à reprendre périodiquement une empreinte des ressources surveillées et de les comparer à l’empreinte de référence pour voir s’il y a eu dérive ou non. Le contrôle de l’intégrité peut aussi se faire de façon incrémentale, par comparaison avec l’empreinte précédente, afin de mieux suivre les évolutions dans le temps. Notons enfin l’importance du suivi des paramètres dynamiques du système, notamment pour détecter des modifications en mémoire comme nous avons pu le montrer avec l’exemple de l’utilisation des devices pour lire et écrire dans la mémoire du noyau.

Conformité par rapport à des profils de référence

Assurer la bonne application de la politique de sécurité requiert également de contrôler la conformité des éléments sensibles du système à des profils de référence. En particulier, les comptes utilisateurs sont généralement regroupés par type de permissions requises. Il est important de s’assurer que les droits de chaque utilisateur ne dévient pas dans le temps, et qu’ils correspondent bien à un profil de référence. En premier lieu, un contrôle simple et efficace est le parcours des répertoires utilisateurs pour vérifier qu’ils ont bien les droits standard d’un compte utilisateur. De même, il est essentiel de se doter d’outils permettant de vérifier la bonne application d’une politique de mots de passe. On peut également citer la synchronisation entre les bases des ressources humaines et les comptes informatiques. Il est important de s’assurer que le compte informatique de chaque personne qui quitte la société est bien supprimé, de sorte à ne pas voir apparaître des comptes dormants. Enfin, on donnera pour dernier exemple la gestion de la conformité des droits d’accès aux ressources par rapport aux règles définies par la politique de sécurité.

Détection de vulnérabilités

Outre les vulnérabilités logicielles, pour lesquelles il existe un certain nombre d’outils de détection, il est également essentiel de détecter les vulnérabilités au sens de points sensibles du système liés à des dérives en exploitation. La mise en œuvre de ces contrôles passe par l’intégration d’agents effectuant périodiquement des vérifications préconfigurées sur les machines, dont notamment :
• Le suivi des accès illicites aux services du réseau,
• La détection de services réseaux inutiles, interdits ou dangereux,
• Le suivi des changements d’identité (commande su et sudo),
• La détection de modules illégitimes,
• Le suivi d’options sensibles dans les fichiers de configuration (ex : SSH forwarding),
• La détection des mots de passe faibles (campagnes de cracking).

Journalisation

Nous citerons finalement la journalisation comme moyen d’action pour lutter contre les dérives du niveau de sécurité opérationnel. En particulier, le suivi des flux réseaux entrants, des accès aux modes « commandes » (telnet, rlogin, etc.), des accès aux fichiers du système, et la centralisation des logs applicatifs pourront se révéler très utile pour l’analyse a posteriori et la correction des failles du système. Les mécanismes de journalisation (ex : Syslog) devront par ailleurs être configurés correctement pour remonter des informations pertinentes et exploitables. Il est également à noter que la mise en place d’une plate-forme de centralisation et de normalisation de ces logs est indispensable pour en assurer l’exploitation, et ce pour deux raisons : d’abord, parce que l’exploitation de logs isolés et répartis sur différentes machines du parc rend difficile la tâche d’analyse, et ensuite, parce que les logs stockés localement sur les machines peuvent être corrompus par les attaquants. Il est donc fondamental de prélever ces logs à la source au plus tôt pour les regrouper en un point central.

Supervisez votre parc avec OSE

En conclusion, il existe des techniques simples pour piéger les systèmes, et leur multiplication rend très difficile leur détection par un administrateur mal outillé. Les techniques permettant de mettre en œuvre cette détection ne sont pas forcément très compliquées, notamment grâce à la facilité de développer des scripts supervisant bon nombre de paramètres du système. Malheureusement, ces mécanismes sont trop souvent isolés, indépendants les uns des autres, et la supervision de tout un parc de machines en exploitation reste difficile. Il est donc nécessaire de mettre en œuvre une véritable plateforme de supervision permettant la centralisation de ces contrôles et la remontée d’alertes en cas de déviation du niveau de sécurité opérationnel.

L’outil OSE, édité par OVELIANE permet de répondre à cette problématique, et donc d’assurer un suivi de la sécurité des systèmes, de garantir le niveau de sécurité du parc.

Pour tout renseignement : OVELIANE

54 rue de Bitche 92400 COURBEVOIE
Site Web : http://www.oveliane.com
Contact : contact@oveliane.com