Accéder au contenu principal

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

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.
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.

source : http://www.itpro.fr/a/top-5-configurations-securite-pas-faire-administrateur-systeme/

Commentaires

Posts les plus consultés de ce blog

Juniper met en garde contre la présence de code-espion dans ses pare-feu

Quelques mois après les révélations d'Edward Snowden, Juniper signale la présence de code-espion, une back door, dans ses firewalls. Hier, le fabricant d'équipements réseaux Juniper a fait savoir qu'il avait trouvé du code suspect dans certains modèles de pare-feu de la marque. Cette découverte inquiétante semble faire écho aux soupçons de piratage des firewalls de Juniper par la NSA avec une back door, dont il était fait mention dans les documents fuités par Edward Snowden. Les produits affectés tournent avec ScreenOS, l'un des systèmes d'exploitation de Juniper, fonctionnant sur une série d’appliances utilisées comme pare-feu et comme support pour le VPN. Selon l’avis publié par l’équipementier, les versions 6.2.0r15 à 6.2.0r18 et 6.3.0r12 à 6.3.0r20 de ScreenOS sont vulnérables. « Le code non autorisé a été découvert pendant un audit récent mené en interne », a expliqué Bob Worrall, le CIO de Juniper. Mais le fabricant n'a pas don...

Une nouvelle affaire de vol de millions de mots de passe

Le serveur qui hébergeait les données volées à Adobe renfermait aussi 42 millions de mots de passe dérobées à un site de rencontre australien.  Là encore, la sécurité mise en place autour de ces données paraît bien mince. Le blogueur spécialiste de sécurité  Brian Krebs  semble être tombé sur un nid : après avoir retrouvé sur un serveur utilisé par des hackers les  millions de données volées à Adobe,  mais aussi des informations piochées chez PR Newswire et au sein d’une organisation à but non lucratif chargé de lutter contre… le cybercrime, ce sont cette fois-ci 42 millions de mots de passe qu’a  récolté l’ex-journaliste . Ces sésames, disponibles en clair dans le fichier mis au jour,  proviennent de Cupid Media , un site australien spécialisé dans les rencontres en ligne. Selon cette société, ces informations résulteraient d’une  attaque détectée en janvier dernier . Elle affirme avoir depuis enjoint les utilisateurs concernés de m...

Smartphones et tablettes : un gros manque de protection !

D'après Symantec, les internautes français sont davantage touchés par la cyber-criminalité sur mobile que leurs homologues européens, et rares sont ceux qui se protègent vraiment Les chiffres du "Norton Report 2013" montrent, en effet, un important besoin d'information et d'éducation des particuliers, mais aussi des entreprises sur les vulnérabilités des terminaux mobiles. 41 % des français utilisant des smartphones ont pourtant déjà été victimes d'actes de cybercriminalité au cours de l'année écoulée contre seulement 29 % en Europe et 38 % dans le monde. " Ce fort impact de la cybercriminalité sur mobile est à mettre en parallèle avec le fait que 60 % des utilisateurs de terminaux mobiles ne savent pas qu'il existe des solutions de sécurité pour terminaux mobiles " note Symantec. Il faut dire aussi qu'en France, 29 % des adultes utilisent leur terminal personnel à la fois pour travailler et pour jouer, contre 38 % e...