Comment sécuriser un VPS Windows : la checklist de durcissement

Pour sécuriser un VPS Windows sans en faire un projet de recherche, commencez par appliquer les correctifs, durcissez RDP avec NLA et des listes d'IP autorisées, imposez le verrouillage de compte, gardez des règles de pare-feu entrantes strictes, laissez la protection en temps réel de Defender activée et testez vos sauvegardes. Pour le travail à distance, les sites web ou les applications, l'objectif est simple : réduire la surface d'attaque, protéger l'identité et surveiller vos journaux.

Commencer par les correctifs : mises à jour, pilotes et rôles

Avant tout, appliquez les correctifs. Les serveurs non mis à jour exposés publiquement sont des cibles faciles, et la plupart des intrusions commencent là. Maintenez les mises à jour de sécurité à jour, supprimez les rôles Windows inutilisés et planifiez les redémarrages selon un calendrier que votre équipe peut respecter. C'est le travail de fond qui empêche les incidents bruyants.

• Configurez Windows Update pour installer les mises à jour de sécurité à intervalles réguliers ; alignez les fenêtres de maintenance sur les horaires qui conviennent à votre équipe.
• Supprimez les rôles et fonctionnalités dont vous n'avez pas besoin, comme les modules IIS hérités ou les composants SMB 1.0.
• Appliquez les mises à jour de pilotes, de firmware et d'applications de façon régulière, puis redémarrez selon le calendrier prévu, pas deux mois plus tard.
• Si le VPS est sur une IP publique, vérifiez l'exposition dans votre portail cloud et fermez ce qui n'est pas nécessaire.

Commencez ici et tenez un journal des changements simple chaque mois, afin de pouvoir dire ce qui a changé et quand. Cela prépare le terrain pour le volet identité, là où se jouent la plupart des gains.

Bases des identités : mots de passe forts, chemins MFA

L'identité, c'est votre porte d'entrée. Les phrases de passe longues et un second facteur bloquent la majorité des attaques courantes, et ils sont simples à déployer même sur un petit Windows Server.

• Utilisez des phrases secrètes d'au moins 14 caractères. Si le serveur est joint à un domaine, ajoutez un filtrage des mots de passe interdits via votre pile d'identité.
• Ajoutez le MFA à Remote Desktop via une passerelle RD Gateway, un VPN ou un fournisseur d'identifiants tiers.
• Utilisez des comptes administrateurs nominatifs distincts et effectuez le travail quotidien sous un compte utilisateur standard.
• Auditez qui peut se connecter via RDP, réduisez cette liste et appliquez le principe du moindre privilège.

Rien de tout cela n'est une astuce. C'est de la constance, et la constance mène directement à la gestion des comptes. Si vous faites cela pour un client, intégrez ces vérifications aux notes de passation pour que le prochain administrateur s'en tienne au plan.

Supprimez le compte « Administrator » par défaut et appliquez le verrouillage de compte

Les attaquants ciblent systématiquement le nom Administrator intégré. Désactivez-le, créez un administrateur nominatif et configurez le verrouillage de compte pour ralentir considérablement les tentatives de force brute.

• Créez et testez un compte administrateur nommé distinct, puis désactivez le compte Administrator intégré. Si vous devez le conserver, renommez-le et protégez-le comme un compte de secours.
• Configurez le verrouillage de compte à 10 tentatives, 15 minutes de verrouillage et 15 minutes de réinitialisation pour un équilibre pratique.
• Documentez une procédure de déverrouillage rapide afin que le support ne soit pas bloqué quand quelqu'un se trompe de mot de passe.

Pour les réglages de référence et les compromis, consultez la référence sur le seuil de verrouillage de compte de Microsoft.

De petits changements comme ceux-ci sont vite rentables sur une VM exposée. Une fois la porte par défaut fermée et le verrouillage en place, la couche suivante est la surface RDP.

Sécurisation de RDP : NLA, bruit de port et listes d'autorisation IP

Remote Desktop est une cible de choix : il faut le durcir. Activez l'authentification au niveau du réseau, réduisez l'exposition via des listes d'autorisation et diminuez le bruit des bots sur le port 3389. Changer le port n'est pas une mesure de sécurité en soi ; cela réduit simplement le trafic des scanners.

• Exigez NLA sur le serveur ; les anciens clients qui ne le prennent pas en charge ne doivent pas pouvoir se connecter.
• Autorisez uniquement certaines IP source sur le TCP 3389 ou sur le nouveau port ; mieux encore, placez RDP derrière un VPN ou une passerelle RD Gateway.
• Changez le port RDP par défaut pour réduire le bruit des scanners, mais ne considérez pas cela comme une mesure de sécurité suffisante.
• Désactivez la redirection des lecteurs et du presse-papiers si vous n'en avez pas besoin ; définissez des délais d'inactivité et forcez la ré-authentification.

Verrouiller RDP bloque la plupart des attaques automatisées, et c'est la liste d'IP autorisées qui fait l'essentiel du travail. Restreindre la plage source, ou utiliser une liste d'autorisation RDP et un géo-filtrage lorsque tous vos utilisateurs se trouvent dans une même région, empêche le trafic opportuniste d'atteindre l'écran de connexion. Cela se marie bien avec des règles de pare-feu sensées.

Règles de pare-feu vraiment Actuales

Les règles du pare-feu de l'hôte doivent rester simples : refus par défaut, puis ouverture de ce que vous utilisez seulement. Liez les règles RDP à des IP source connues, journalisez les rejets et laissez les protocoles hérités dehors.

• Commencez par bloquer tout le trafic entrant par défaut, puis autorisez uniquement les ports et protocoles nécessaires.
• Limitez les règles RDP aux IP connues, pas à 0.0.0.0/0, et journalisez le trafic bloqué pour analyse.
• Utilisez TLS 1.2 ou une version plus récente ; désactivez SMBv1 partout.
• Laissez le trafic sortant autorisé par défaut, sauf si vous disposez d'une politique de sortie gérée ; n'ajoutez des blocages sortants ciblés que là où le besoin est établi.

Les règles qui justifient leur existence couvrent en général des ports que personne n'a ouverts volontairement. Windows RPC sur TCP 135 en est l'exemple type, et le restreindre à des sources de confiance au niveau du pare-feu de l'hôte relève du même réflexe de refus par défaut, appliqué port par port. Derrière ces ports se trouvent les services eux-mêmes.

Hygiène des services : supprimez ce que vous n'utilisez pas

Chaque service inutile est une surface d'attaque de plus. Désactivez ce dont vous n'avez pas besoin, puis vérifiez à nouveau dans un mois ce qui a réapparu.

• Arrêtez et désactivez le spouleur d'impression si le serveur n'est pas un serveur d'impression.
• Désactivez le registre distant et les protocoles hérités que vous n'utilisez pas.
• Désinstallez les rôles web, fichiers ou FTP qui ne font pas partie de votre charge de travail.
• Passez en revue les éléments de démarrage et les tâches planifiées, et enquêtez sur tout ce que vous ne reconnaissez pas avant de le désactiver.

Une fois la maison rangée, ajoutez une protection de base avec Defender et des réglages EDR légers. L'effort est minime, et c'est le genre d'effort qui se voit au quotidien.

Defender, EDR et analyses planifiées

Microsoft Defender Antivirus offre une base intégrée solide sur les versions actuelles de Windows Server. Gardez la protection en temps réel et la protection cloud actives, et utilisez des analyses rapides pour la planification habituelle.

• Si le serveur est intégré à Defender for Endpoint, activez-y la protection contre les falsifications (Tamper Protection).
• Maintenez la protection en temps réel et la protection cloud ; planifiez une analyse rapide hebdomadaire pendant une période calme.
• N'exécutez des analyses complètes que pour des investigations précises ou lorsque vos outils de sécurité le demandent.

Ces réglages assurent une couverture au quotidien, ce qui constitue une base et non un programme géré de détection et de réponse. Ils fonctionnent d'autant mieux avec des sauvegardes que vous pouvez réellement restaurer.

Sauvegardes, snapshots et tests de restauration

Un Windows VPS qu'on ne peut pas restaurer est un point de défaillance unique. Prenez des snapshots quotidiens, conservez des sauvegardes hors site et testez les restaurations pour vous assurer que le plan fonctionne.

• Snapshots automatisés quotidiens avec une rétention de sept à 14 jours, plus longue pour les besoins de conformité.
• Sauvegardes hors site chez un fournisseur, dans une région ou un bucket utilisant des identifiants distincts.
• Tests de restauration mensuels, procédures documentées et liste de contacts pour estimer le temps de reprise.

Le comportement des snapshots et des restaurations est autant une question de plateforme que de politique interne, et il vaut mieux le vérifier avant le jour où vous en aurez besoin. Si vous déployez un nouveau serveur, notre Windows VPS offers one-click images for Server 2022, 2019, 2016, and 2012 R2.

Une réserve compte ici plus que tout le reste du paragraphe. Server 2012 figure encore sur la liste des images pour la compatibilité avec des applications héritées, et ce n'est pas une image de base pour une installation durcie. Microsoft indique dans son avis de cycle de vie de Server 2012 une fin de support au 10 octobre 2023, et les mises à jour de sécurité étendues payantes s'arrêtent définitivement le 13 octobre 2026. Server 2016 approche aussi de sa fin de support en janvier 2027, donc si vous construisez quelque chose de neuf et le placez sur une IP publique, partez sur Server 2019 ou 2022.

Surveiller et journaliser : RDP, Sécurité, PowerShell

Vous n'avez pas besoin d'un SIEM pour tirer parti des journaux Windows. Commencez par les connexions échouées, les sessions RDP réussies et la transcription PowerShell. Ces trois signaux constituent une base de surveillance utile sur un petit serveur.

• Activez l'audit des échecs de connexion et surveillez les pics sur Event ID 4625 .
• Suivez les connexions RDP réussies avec l'Event ID 4624 filtré sur le Logon Type 10 (RemoteInteractive) ; utilisez 4634 pour la fin de session et 4647 pour la déconnexion initiée par l'utilisateur.
• Activez la transcription PowerShell par stratégie afin que les entrées et sorties PowerShell laissent une trace.

Une fois la visibilité en place, imprimez le récapitulatif de durcissement d'une page et gardez-le sous la main. C'est là que commence l'exploitation au jour le jour, puisque ce sont les alertes qui déclenchent le prochain tour de correctifs et de nettoyage.

Tableau de durcissement Windows VPS

Un récapitulatif rapide à consulter avant une fenêtre de maintenance ou après une reconstruction.

Ce tableau de bord vous offre une vue d'ensemble rapide ; la section suivante compare les mêmes points sur Linux, ce qui facilite la montée en compétences des équipes.

Bonus : comparaison avec le durcissement Linux

Certaines équipes combinent plusieurs plateformes. Les mêmes bonnes pratiques s'appliquent des deux côtés : patches selon un planning défini, comptes administrateurs nommés, SSH ou RDP solides, et pare-feux avec politique de refus par défaut. Si votre infrastructure inclut des machines Linux, ce plan Windows s'aligne bien avec un socle Linux VPS sécurisé , afin que vos procédures restent cohérentes d'un environnement à l'autre.

Cette vue multiplateforme prépare des choix concrets selon les cas d'usage, et vous donne quelque chose à transmettre au collègue qui gère des clés SSH et iptables toute la journée sans jamais avoir ouvert la stratégie de groupe.

Recommandations par cas d'usage

Votre liste doit correspondre à votre charge de travail. Voici une courte matrice pour associer les contrôles aux configurations courantes.

• Poste de développement solo : exigez NLA, autorisez votre plage d'IP actuelle et, si vous le souhaitez, changez le port RDP pour réduire le bruit des scanners, puis lancez des analyses rapides hebdomadaires. Conservez des snapshots quotidiens et testez une fois par mois.
• Serveur applicatif de PME pour l'ERP ou la comptabilité : placez RDP derrière un VPN ou une passerelle RD Gateway, limitez les droits d'administration, désactivez les protocoles hérités et ajoutez des alertes sur les pics d'événements 4625.
• Ferme de bureaux à distance pour une petite équipe : centralisez l'accès via une passerelle, ajoutez le MFA, utilisez des phrases secrètes uniques et changez-les en cas de suspicion de compromission, et gardez des règles de pare-feu strictes en entrée comme en sortie.

Foire aux questions

Changer le port RDP suffit-il ?

Non. Cela réduit seulement les scans opportunistes ; il vous faut toujours NLA, le verrouillage de compte et des listes d'IP autorisées, ou bien un VPN et une passerelle. Voyez le changement de port comme une réduction du bruit, pas comme un bouclier.

Ai-je besoin d'un VPN pour RDP ?

Si RDP est exposé à Internet, utilisez un VPN ou une passerelle RD Gateway pour réduire l'exposition. Associez-y le MFA et des listes d'IP autorisées au pare-feu : vous obtenez une configuration simple et solide, à la portée de la plupart des petites équipes.

À quelle fréquence dois-je patcher un VPS Windows ?

Suivez les fenêtres de maintenance de votre fournisseur si elles existent, puis appliquez les mises à jour de sécurité peu après leur sortie, pour le système comme pour les applications. Les chemins d'attaque partent souvent d'une exposition publique et de failles connues, alors ne prenez pas de retard sur les correctifs. Si le serveur héberge des données clients, inscrivez la cadence de correctifs dans une politique écrite pour qu'elle tienne.

Qu'est-ce que NLA, et pourquoi l'activer ?

Network Level Authentication exige l'authentification avant le démarrage de la session RDP, ce qui bloque les chemins de code non authentifiés et économise des ressources. Microsoft recommande NLA pour la plupart des environnements ; vérifiez qu'il est activé et laissez-le en place.

Que surveiller sur un petit serveur ?

Commencez par les échecs de connexion 4625, l'événement 4624 avec Logon Type 10 pour les connexions RDP réussies, 4634 pour la fin de session, 4647 pour la déconnexion initiée par l'utilisateur, et la transcription PowerShell. Ajoutez une revue hebdomadaire et une règle d'alerte simple sur les pics. Cela suffit à avoir de la visibilité sur une petite machine sans acheter une plateforme complète.