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

Rapport viral de l'année 2013

Le 06 février 2014 Doctor Web présente un bilan des menaces les plus importantes et/ou significatives ayant touché les utilisateurs en 2013. L'année 2013 a mis en lumière plusieurs menaces pour la sécurité informatique. Comme en 2012, l'une des grandes tendances de l'année passée a été la propagation des Trojans encoders qui ont touché les utilisateurs dans de nombreux pays.  Les spécialistes ont observé une augmentation du nombre de logiciels malveillant visant à afficher de la publicité sur les ordinateurs des victimes, ou à récolter de la crypto monnaie Bitcoin et Litecoin (surtout à la fin de l'année). La gamme de logiciels malveillants ciblant Android s’est considérablement élargie. Situation virale Les malwares les plus répandus en 2013 selon les statistiques de l'utilitaire de traitement Dr.Web CureIt! restent les Trojans de la famille  Trojan.Hosts , dont le plus répandu est le  Trojan.Hosts.6815 , qui modifie le fichier hosts sur l'ordinateur inf...
C’est sans doute le plus gros scandale de l’histoire des télécommunications modernes, et il est passé presque inaperçu ; le piratage par la  NSA  d’un câble sous-marin détenu (entre autres) par  Orange , le SEA-ME-WE 4. Cette liaison en fibre optique, co-gérée par un consortium de seize opérateurs mondiaux, assure une partie des liaisons nécessaires au bon fonctionnement du réseau téléphonique et Internet. Un grand nombre de communications y transitent, puisque la liaison relie la France (à partir de Marseille) à l’Afrique du Nord, le Moyen-Orient, et une petite partie de l’Asie. illustration Wikicommons De nouvelles révélations d’Edward Snowden indiquent que l’agence américaine de renseignements a organisé le piratage de ce réseau, début 2013. Cette attaque leur a permis de collecter des informations sur la structure et la cartographie du réseau, mais également sur une partie des données qui y transitaient : certaines données permettant, une fois c...

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