Checklist de durcissement Windows Server exposé à internet

Comment utiliser cette liste

Les checklists de durcissement échouent le plus souvent pour une raison : elles sont classées par ordre alphabétique et non par risque. On les descend, et le temps s'épuise quelque part vers la politique d'écran de veille, sans jamais avoir traité l'accès distant.

Celle-ci est ordonnée. Les premières sections suppriment les moyens par lesquels les serveurs sont réellement compromis. La dernière mérite d'être faite et ne vous sauvera pas à elle seule. Si vous n'avez qu'un après-midi : sections 2 et 3, puis arrêtez.

Elle suppose un serveur qui doit rester joignable depuis internet. Si le vôtre ne le doit pas, la section 3 se réduit à une ligne, et c'est une bonne nouvelle.

1. Comptes et authentification

Presque toute compromission d'un serveur Windows exposé commence par des identifiants valides — devinés, sprayés, réutilisés depuis une fuite, ou hameçonnés. C'est là que l'effort doit aller.

• Désactivez ou renommez le compte Administrator intégré. C'est le premier nom de toute liste d'attaque, et son SID bien connu fait que le renommage seul n'est pas une défense — préférez le désactiver, avec un compte administrateur nommé distinct.
• Exigez l'authentification multifacteur sur chaque compte pouvant se connecter à distance. C'est la mesure la plus rentable de cette liste : un mot de passe deviné ne vaut rien sans le second facteur.
• Imposez des mots de passe longs — un minimum de 15 caractères résiste bien mieux au cassage hors ligne que des règles de complexité sur plus court — et interdisez les mots de passe connus des fuites si votre outillage le permet.
• Auditez qui a réellement un accès distant. Supprimez les comptes des personnes parties, des prestataires dont la mission est finie, et des services qui n'existent plus. Chaque compte dormant est une surface d'attaque que personne ne surveille.
• Donnez aux comptes de service leur propre identité, sans droit d'ouverture de session interactive, et des mots de passe qui ne servent nulle part ailleurs.
• Maniez le verrouillage de compte avec précaution. Sur un hôte exposé, il permet à n'importe qui de désactiver vos comptes à la demande ; gardez un seuil modéré si vous l'utilisez, et ne comptez jamais dessus comme défense contre le devinage.

2. Exposition réseau

La deuxième question après « qui peut se connecter » est « depuis où ». Chaque port joignable depuis internet est un service que quelqu'un teste en ce moment.

• Inventoriez ce qui écoute réellement, depuis l'extérieur. Get-NetTCPConnection -State Listen sur l'hôte, puis vérifiez depuis un autre réseau lesquels répondent.
• Fermez SMB (445) au périmètre. Il ne devrait pour ainsi dire jamais faire face à internet, et c'est une seconde trouvaille fréquente sur des serveurs censés n'exposer que RDP.
• Idem pour WinRM (5985/5986), MS SQL (1433) et toute interface d'administration. Si un service n'a pas besoin d'être joignable depuis internet, c'est là toute la correction.
• Pour RDP lui-même, restreignez les adresses sources si vous le pouvez. Sinon, poursuivez — la section 3 est la mesure compensatoire.
• Activez Network Level Authentication pour qu'un client non authentifié n'obtienne jamais de session créée pour lui.
• Vérifiez aussi le groupe de sécurité cloud, pas seulement le pare-feu Windows. Deux couches, c'est deux endroits où se tromper, et un groupe permissif devant un pare-feu hôte soigné est un décalage courant.

3. Blocage automatique des connexions échouées

C'est la section que la plupart des checklists omettent, et celle qui change le quotidien d'un serveur exposé.

Windows enregistre chaque échec d'authentification comme événement 4625 et embarque un pare-feu parfaitement capable, mais ne fournit rien qui relie les deux. Livré à lui-même, un serveur absorbe des milliers de tentatives par jour : CPU consommé, journal d'audit brassé, et aucune limite au temps qu'un attaquant peut passer à essayer.

Il vous faut l'équivalent de fail2ban : surveiller le flux d'échecs et, quand une source franchit un seuil, la jeter au pare-feu. Trois propriétés séparent une implémentation qui tient d'une qui fuit — bannir le sous-réseau plutôt que l'adresse seule, rendre les bannissements permanents et résistants au redémarrage, et mettre votre propre accès en liste blanche avant d'activer quoi que ce soit.

Vous pouvez le construire comme une tâche planifiée PowerShell, et pour un serveur unique que vous regardez chaque jour c'est un choix raisonnable. Prévoyez une journée, et sachez que son mode de défaillance est le silence : les tâches planifiées s'arrêtent après les redémarrages et les changements de mot de passe sans prévenir. RDP Protector est la même logique en agent managé, avec liste blanche, gestion des sous-réseaux, détection des ports et une vue de santé.

4. Correctifs et surface d'attaque

Les identifiants sont la voie d'entrée habituelle ; les services non corrigés sont la voie mémorable.

• Activez les mises à jour automatiques, ou tenez un cycle de correctifs que vous respectez vraiment. RDP a connu des exécutions de code à distance avant authentification, et en connaîtra d'autres.
• Retirez les rôles et fonctionnalités inutilisés. Une installation d'IIS que personne ne se souvient d'avoir activée est un service que quelqu'un d'autre trouvera.
• Désinstallez les logiciels venus avec l'image et non nécessaires. Chaque agent, barre d'outils et utilitaire de mise à jour est du code s'exécutant avec des privilèges sur votre hôte.
• Gardez à jour les agents que vous exploitez réellement, y compris supervision et sauvegarde.
• Désactivez les protocoles hérités — SMBv1, TLS 1.0 et 1.1, NTLMv1 — sauf si quelque chose les exige vraiment, auquel cas notez quoi et revenez-y.

5. Journalisation et détection

On ne peut pas enquêter sur ce qu'on n'a pas enregistré, et la configuration par défaut enregistre moins que vous ne croyez, moins longtemps que vous ne l'espérez.

• Confirmez que l'audit des ouvertures de session capture les échecs, pas seulement les succès : auditpol /get /subcategory:"Logon" doit montrer les deux.
• Augmentez la taille maximale du journal de sécurité. La valeur par défaut se remplit en heures sur un hôte exposé, et les événements utiles disparaissent avant que vous ne regardiez.
• Exportez les événements hors de l'hôte. Le journal local d'une machine compromise est une preuve qu'un attaquant peut modifier ; une copie ailleurs ne l'est pas.
• Alertez sur ce qui compte plutôt que sur le volume : une connexion réussie depuis un nouveau pays, un nouvel administrateur local, un service installé, l'effacement du journal d'audit (événement 1102).
• Passez en revue, de temps en temps et délibérément, qui s'est connecté avec succès. Les échecs sont du bruit ; un succès que vous ne pouvez pas expliquer, c'est tout l'enjeu.

6. Des sauvegardes que vous avez réellement restaurées

Cette section est dernière non parce qu'elle compte le moins, mais parce qu'elle est la mesure qui suppose que toutes les autres ont échoué — et ce jour-là, une seule propriété de vos sauvegardes compte.

Gardez au moins une copie que le serveur lui-même ne peut ni atteindre ni supprimer. Les opérateurs de rançongiciels cherchent la cible de sauvegarde avant de chiffrer quoi que ce soit, et un partage sur lequel l'hôte compromis peut écrire n'est pas une sauvegarde, c'est une seconde copie qui attend d'être détruite.

Puis restaurez-en une. Une sauvegarde jamais restaurée est une hypothèse. Testez-la selon un calendrier, notez le temps que cela a pris, et assurez-vous que plus d'une personne connaît la procédure.