> Server > Top 5 des configurations de sécurité à ne pas faire pour un Administrateur Système

Top 5 des configurations de sécurité à ne pas faire pour un Administrateur Système

Server - Par Freddy Elmaleh - Publié le 03 février 2014

Il n’est pas rare de constater plusieurs mauvaises pratiques en place au sein des différents systèmes d’information qu’il m’a été amené d’approcher.

Top 5 des configurations de sécurité à ne pas faire pour un Administrateur Système

Bien sûr, le but de cet article n’est pas de jeter la pierre sur nos chers administrateurs système mais au contraire de mettre en avant ces erreurs afin de prendre les mesures qui permettront de les corriger.

Voici donc les différents points d’attention à prendre en compte lorsque nous sommes un administrateur système :

1. Ne pas ouvrir de session sur son poste d’administration en utilisant un compte administrateur ou ayant des droits étendus.

Risque : Comme les postes d’administration doivent accéder à plusieurs serveurs, des règles réseau moins restrictives sont souvent en place. Les postes font généralement partis du « réseau d’administration » qui leur permet d’accéder à tous les serveurs, aux DMZ, etc.

L’admin s’authentifie également sur de nombreuses applications depuis cet ordinateur. Lors d’attaque ciblée, ces postes sont les premier recherchés par les pirates car toutes les informations d’authentification y sont généralement centralisées.

L’utilisation d’un compte admin augmente considérablement les risques de mener une attaque à son terme.

Solution : Sur les postes d’administration (tout comme les autres postes), utiliser deux comptes pour chaque Administrateur.

Un compte utilisateur sans droit particulier et un compte Administrateur avec des droits étendus.

Le compte utilisateur servira aux tâches courantes, tandis que le compte Administrateur sera utilisé pour réaliser les tâches d’administration (cf. point plus bas). Penser également à activer l’UAC sur Windows Vista/7/8.

2. Ne pas ouvrir de session interactive sur un serveur pour réaliser une tâche d’administration.

Risque : Impossibilité de déléguer une tâche d’administration spécifique en cas d’ouverture de session interactive et donc utilisation de droits étendus sur un serveur.

Solution : Préférez déléguer les droits justes nécessaires à vos administrateurs puis utiliser la command RunAs pour lancer les outils d’administration (AdminPak ou RSAT) à distance. Dans certains cas cependant (serveurs en DMZ notamment), il est acceptable de se connecter interactivement aux serveurs plutôt que d’avoir à ouvrir des flux spécifiques aux consoles MMC.

3. Ne pas utiliser le même mot de passe entre le compte utilisateur et le compte Administrateur.

Risque : Il n’est pas rare de retrouver des administrateurs utilisant le même mot de passe pour les deux comptes… Cela remet totalement en question l’intérêt des deux comptes.

Solution : Si votre domaine est en mode natif Windows 2008, vous pouvez utiliser une stratégie de mot de passe affinée (Fine-Grained Password Policy) afin de définir une stratégie de mot de passe propre à ces comptes (avec une durée de vie plus courte pour les comptes Administrateurs que pour les comptes utilisateurs, ou une longueur plus importante par exemple).

4. Ne pas autoriser les Administrateurs systèmes à sortir sur Internet avec leur compte Administrateur.

Risque : La plupart des virus sont récupérés lors de sessions de navigation sur Internet et utilisent les identifiants de la session piratée pour tenter de se propager sur les autres ordinateurs. Si le navigateur est lancé avec un compte Admin du domaine par exemple, le virus ne mettra que quelques minutes pour infecter l’ensemble du parc via les partages administratifs, du fait que le compte sera administrateur de tous les autres postes.

Solution : Ajouter les comptes Admins dans un groupe spécifique et bloquer l’accès à Internet pour ce groupe au niveau du proxy.

5. Ne pas utiliser plusieurs logiciels de prise de main à distance.

Risque : Plusieurs logiciels de prise de main à distance stockent leur mot de passe dans le cache LSA.

Ce cache LSA est un endroit de la base de registre accessible via des outils tiers et qui permet de visualiser les mots de passe des comptes de services, et autres programmes dont de nombreux logiciels de prise de main à distance.

Pour peu qu’un administrateur utilise ce type de logiciel, le mot de passe renseigné pour permettre la prise de main à distance (dont le mot de passe « d’administration » sera stocké à cet endroit.

Solution : Normer une seule façon se de prendre la main à distance sur les postes de travail et serveur et s’assurer que le mot de passe ne soit pas stocké dans le cache LSA.

Il s’agit ici d’un bref aperçu des erreurs les plus communément constatées dans les différents environnements que j’ai approchés pour des audits Sécurité Système.

Bien entendu, cette liste est très loin d’être exhaustive mais cela constitue un bon point de départ.

L’autre axe d’amélioration majeur concerne la sensibilisation au risque. Un administrateur sensibilisé intègrera d’autant mieux les « contraintes » de sécurité qui lui seront imposées.

Téléchargez gratuitement cette ressource

Adobe Creative Cloud Entreprise en 5 leviers majeurs d’innovation, de productivité et de simplicité pour les utilisateurs et la DSI

Adobe Creative Cloud Entreprise en 5 leviers majeurs d’innovation, de productivité et de simplicité pour les utilisateurs et la DSI

Les produits Adobe sont depuis longtemps reconnus et plébiscités par les entreprises pour leur faculté à libérer les talents créatifs. Avec l’évolution vers le Cloud et l’introduction du programme VIP Entreprise, utilisateurs et DSI gagnent en productivité et en agilité tout en réalisant des économies substantielles. Avec ce Top 5 Décideurs IT, Découvrez Adobe Creative Cloud Entreprise sous l'angle de 5 leviers majeurs d'innovation, de productivité et de simplicité pour les utilisateurs et le DSI.

Server - Par Freddy Elmaleh - Publié le 03 février 2014