Magic Quadrant™ pour la gestion des accès privilégiés 2025 : Netwrix reconnue pour la quatrième année consécutive. Téléchargez le rapport.

Plateforme
Centre de ressourcesBlog
Politique de renforcement des serveurs : Exemples et conseils

Politique de renforcement des serveurs : Exemples et conseils

Nov 3, 2021

Diverses recherches révèlent qu'un étonnant 80 % des violations signalées impliquent l'exploitation de vulnérabilités dans les configurations des systèmes informatiques. Pour bloquer proactivement les attaques et ainsi prévenir les temps d'arrêt coûteux et les data breaches, les experts recommandent la mise en œuvre d'une politique de hardening policy, qui est un type spécifique de politique de system hardening.

Une politique de renforcement des serveurs est un ensemble de lignes directrices, procédures et contrôles conçus pour protéger les systèmes contre l'accès non autorisé et l'exploitation. En effet, un serveur déployé dans son état par défaut est à risque de compromission et d'attaques par logiciels malveillants. Mais en supprimant les logiciels et fonctionnalités inutiles, en configurant correctement les paramètres de sécurité et en mettant en œuvre les meilleures pratiques pour le contrôle d'accès, l'audit et la réponse aux incidents, vous pouvez réduire considérablement votre surface d'attaque.

Les conseils et exemples suivants peuvent servir de point de départ pour vos efforts de renforcement.

Comptes d'utilisateurs et mots de passe

  • La durée et le seuil de verrouillage du compte sont-ils définis ?
  • L'encryption Kerberos est-elle activée et les types sélectionnés sont-ils suffisamment robustes ?
  • Les comptes locaux par défaut, tels que les comptes Administrateur et Invité intégrés sur les systèmes Windows, sont-ils désactivés ou renommés ?
  • Les exigences concernant les mots de passe des utilisateurs sont-elles conformes aux meilleures pratiques, telles que les directives NIST ?

Exemple : Configurez une politique de mot de passe de compte avec les paramètres suivants :

  • Âge minimum du mot de passe : 1 jour ou plus
  • Longueur minimale du mot de passe : 14 caractères ou plus
  • Seuil de verrouillage de compte : 10 tentatives ou moins (mais pas 0)
  • Réinitialiser le compteur de verrouillage de compte : 15 minutes ou plus

Systèmes d'exploitation

  • Chaque système d'exploitation (OS) est-il pleinement pris en charge par le fournisseur et mis à jour avec les derniers correctifs ? Et cela est-il revu au moins une fois par mois ?
  • Tous les services et démons inutiles ont-ils été supprimés ou désactivés ? L'accès web, FTP, telnet et bureau à distance a-t-il été supprimé ? Le meilleur conseil est de désactiver tout ce que vous savez n'être pas nécessaire (comme le service Themes) puis d'expérimenter prudemment un par un avec d'autres services que vous jugez inutiles. Si la désactivation d'un service compromet les opérations commerciales, gardez-le activé.
  • Savez-vous quels ports sont ouverts ? Y a-t-il une bonne raison pour qu'ils restent ouverts ou peuvent-ils être supprimés ? Pouvez-vous détecter de nouveaux ports ouverts lorsqu'ils apparaissent ?
  • Has the Local Security Policybeen fully leveraged? Exploitable vulnerabilities can be mitigated using this policy, which offers hundreds of fine-grained security configuration controls to strengthen security.

Exemple: Définissez les paramètres suivants pour les systèmes d'exploitation Windows :

  • Autoriser les applications UIAccess à demander une élévation sans utiliser le bureau sécurisé : Désactivé
  • Invite d'élévation pour les administrateurs en mode d'approbation d'admin : Demander le consentement sur le bureau sécurisé
  • Invite d'élévation pour les utilisateurs standards : Refuser automatiquement les demandes d'élévation
  • Détectez les installations d'applications et demandez une élévation : Activé
  • N'autorisez l'élévation des applications UIAccess que si elles sont installées dans des emplacements sécurisés : Activé
  • Exécutez tous les administrateurs en mode Approbation d'administration : Activé
  • Virtualisez les échecs d'écriture de fichiers et de registre vers des emplacements par utilisateur : Activé

Systèmes de fichiers

  • Pour les serveurs Unix et Linux, les permissions sur les fichiers de sécurité clés (tels que /etc/password et /etc/shadow) sont-elles définies conformément aux recommandations des meilleures pratiques ? Est-ce que sudo est utilisé ? Si oui, seulement les membres du groupe root wheel sont-ils autorisés à l'utiliser ?
  • Pour les serveurs Windows, les exécutables clés, les DLL et les pilotes sont-ils protégés dans les dossiers System32 et SysWOW64, ainsi que dans les dossiers Program Files/(x86) ?

Example: Apply file integrity monitoring to the following files and folders:

  • %PROGRAMFILES% : Utilisez le hachage SHA1, les modifications des fichiers système, excluez les fichiers journaux, récursif
  • %PROGRAMFILES(x86)% : Utilisez le hachage SHA256, les modifications des fichiers système, excluez les fichiers journaux, récursif
  • %SYSDIR% : Utilisez le hachage SHA256, les modifications de fichiers système, excluez les fichiers journaux, récursif
  • %WINDIR%SysWOW64 : Utilisez le hachage SHA256, les modifications de fichiers système, excluez les fichiers journaux, récursif

Réseau Client/Serveur

  • Le pare-feu logiciel intégré est-il activé et configuré sur « Refuser tout » ?
  • Sur Linux, les TCP Wrappers ont-ils été configurés pour « Deny All » ?
  • Les chemins de registre et les partages accessibles à distance ont-ils été restreints de manière appropriée pour votre environnement ? Cela sera différent pour un serveur membre par rapport à un contrôleur de domaine.

Exemple: Dans votre politique de sécurité, spécifiez les paramètres suivants pour le client réseau et le serveur réseau :

  • Signer numériquement les communications (si le serveur est d'accord) : Activé
  • Envoyer le mot de passe non chiffré aux serveurs SMB tiers : Désactivé
  • Signer numériquement les communications (toujours) : Activé
  • Signer numériquement les communications (si le client est d'accord) : Activé
  • Déconnecter les clients lorsque les heures de connexion expirent : Activé

Audit et contrôle des changements

  • Les pistes d'audit sont-elles activées pour tous les accès, l'utilisation des privilèges, les modifications de configuration, et l'accès, la création et la suppression d'objets ?
  • Les pistes d'audit sont-elles sauvegardées de manière sécurisée et conservées pendant au moins 12 mois ?
  • Une source NTP centrale et protégée est-elle configurée et utilisée ?
  • Is file integrity monitoring (FIM) used to maintain your secure build standards?
  • Existe-t-il un processus de change management défini qui inclut la proposition de changement (couvrant l'analyse d'impact et les dispositions de retour en arrière), l'approbation du changement, les tests d'assurance qualité et la revue post-implémentation ?
  • Les événements enregistrés sont-ils sauvegardés de manière sécurisée sur un serveur central ? Cela nécessite un moyen de transférer les événements des serveurs surveillés vers le serveur de logs (généralement un agent de transfert Syslog ou une solution plus complète comme Netwrix Change Tracker) ainsi qu'une politique d’audit structurée.

Exemple: Définissez les paramètres suivants dans votre politique d'audit avancée :

  • Audit de déconnexion : Réussite
  • Audit de connexion : Réussite et échec
  • Auditez les autres événements de connexion/déconnexion : Succès et Échec
  • Audit de connexion spéciale : Réussite

Logiciels et applications

  • Quels paquets et applications sont définis par votre norme de construction sécurisée ? Par exemple, avez-vous des normes pour votre anti-virus, data leakage prévention, pare-feu et outils FIM ? Quel est le processus de mise à jour périodique des bases de référence avec les changements approuvés ?
  • Existe-t-il un processus pour garantir que vous disposez des dernières versions et que les correctifs ont été testés et appliqués ?
  • Les mises à jour automatiques des paquets sont-elles désactivées au profit du déploiement planifié des mises à jour ?

Choisir une politique de durcissement de serveur et l'adapter à votre organisation

Obtenir une liste de contrôle de durcissement ou une politique de durcissement de serveur est assez simple. Par exemple, le Center for Internet Security (CIS) fournit des hardening checklists ; Microsoft propose des listes de contrôle pour les appareils Windows ; Cisco fournit des listes de contrôle pour ses routeurs ; et la National Vulnerability Database hébergée par NIST fournit des listes de contrôle pour une large gamme d'appareils Linux, Unix, Windows et de pare-feu. NIST propose également le National Checklist Program Repository, qui est basé sur les normes SCAP et OVAL.

Ce sont de bons points de départ, mais vous devez adapter toute liste de contrôle en fonction de l'opération et du rôle d'un serveur. Par exemple, un serveur exposé à Internet nécessite un contrôle d'accès plus strict qu'un serveur de base de données qui se trouve derrière votre pare-feu.

Une fois que vous avez établi votre politique de durcissement de serveur et appliqué les listes de contrôle des meilleures pratiques à votre configuration standard, vous devez auditer en continu tous les appareils pour toute dérive de configuration. Votre processus de gestion des changements devrait définir comment les changements sont évalués puis soit corrigés, soit promus à la ligne de base de la configuration. Netwrix Change Tracker fournit un contrôle intelligent des changements, donc les changements doivent être approuvés seulement une fois pour un serveur, et ensuite toute autre occurrence du même changement sera automatiquement approuvée. Cela élimine le plus gros problème avec la plupart des systèmes FIM et SIEM , qui est que le bruit des changements peut facilement devenir accablant.

Résumé

La première étape la plus efficace dans toute stratégie de data security est de prévenir les violations de sécurité. En s'attaquant de manière proactive aux vulnérabilités de configuration par le durcissement, les serveurs peuvent être rendus plus sûrs et résistants aux attaques. Les solutions de gestion des changements et de file integrity monitoring surveillent ensuite toute déviation par rapport à votre référence pour vous assurer que tous les serveurs restent configurés de manière sécurisée.

FAQ

Qu'est-ce que le durcissement de serveur ?

Le durcissement des serveurs est le processus proactif de désactivation des programmes et fonctionnalités inutilisés, de renforcement des paramètres de sécurité des serveurs, et d'application des meilleures pratiques d'audit et de réponse aux incidents afin de rendre les serveurs moins vulnérables aux attaques.

Qu'est-ce qu'une politique de durcissement ?

Une politique de durcissement est un ensemble de directives et de procédures mises en œuvre pour réduire la surface d'attaque d'un système. La politique doit être basée sur le contrôle d'accès, la journalisation et la réponse aux incidents. Une politique peut être spécifique à un système particulier, comme Linux ou Windows Server, ou généralisée comme une politique de durcissement de base de données.

Qu'est-ce qu'un modèle de politique de durcissement de système ?

Un modèle de politique de system hardening est un document qui décrit les directives et les procédures à suivre pour sécuriser et protéger les systèmes. Il comprend généralement une liste des meilleures pratiques et des contrôles de sécurité à mettre en œuvre pour des actifs spécifiques. Le modèle peut servir de point de départ pour créer une politique de durcissement personnalisée pour différents systèmes.

Comment puis-je renforcer la sécurité de mon serveur ?

Les étapes clés incluent généralement :

  • Suppression des logiciels et services inutiles pour réduire la surface d'attaque
  • Configurer les pare-feu et les systèmes de détection/prévention d'intrusion pour bloquer l'accès non autorisé
  • Activation des fonctionnalités de sécurité telles que le chiffrement et le démarrage sécurisé
  • Mettre en œuvre les meilleures pratiques pour le contrôle d'accès, telles que l'authentification multifacteur et le principe du moindre privilège
  • Mettre à jour régulièrement les logiciels et appliquer les correctifs de sécurité
  • Mettre en œuvre une journalisation des événements robuste et une surveillance du trafic pour détecter et répondre aux incidents de sécurité potentiels
  • Tester et réviser régulièrement la politique de durcissement des serveurs pour identifier et résoudre toute vulnérabilité.

Partager sur

En savoir plus

À propos de l'auteur

Asset Not Found

Dirk Schrader

Vice-président de la Recherche en Sécurité

Dirk Schrader est un Resident CISO (EMEA) et VP of Security Research chez Netwrix. Fort d'une expérience de 25 ans dans la sécurité informatique avec des certifications telles que CISSP (ISC²) et CISM (ISACA), il œuvre pour promouvoir la cyber résilience comme approche moderne pour faire face aux menaces cybernétiques. Dirk a travaillé sur des projets de cybersécurité dans le monde entier, commençant par des rôles techniques et de support au début de sa carrière, puis évoluant vers des postes de vente, marketing et gestion de produit chez de grandes multinationales ainsi que dans de petites startups. Il a publié de nombreux articles sur la nécessité de s'attaquer à la gestion des changements et des vulnérabilités pour atteindre la cyber résilience.