Configurer le pare-feu Windows Server sur un VPS

5 étapes pour sécuriser votre pare-feu VPS Windows

1. Vérifier l'état : Get-NetFirewallProfile | Select Name, Enabled en PowerShell.

2. Activer sur les 3 profils : Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True.

3. Créer une règle entrante via l'interface wf.msc ou New-NetFirewallRule en PowerShell.

4. Restreindre RDP (3389) à votre IP source uniquement.

5. Activer les logs pour auditer les connexions bloquées.

🛡️ Pourquoi le pare-feu Windows Server est critique sur un VPS

Un VPS Windows est exposé directement sur Internet. Sans pare-feu correctement configuré, n'importe qui peut tenter de se connecter à vos ports ouverts.

Pare-feu réseau vs pare-feu OS: deux couches distinctes.

Chez OuiHeberg, votre VPS Windows dispose d'un pare-feu réseau au niveau de l'infrastructure. Mais ce pare-feu ne remplace pas Windows Defender Firewall : il opère au niveau de l'OS, règle par règle, programme par programme. Les deux doivent être actifs.

Risques si le pare-feu Windows est désactivé :

• RDP (port 3389) exposé à tous les bots de scan: attaques brute-force en continu.

• SQL Server (1433), WinRM (5985/5986) accessibles sans restriction.

• Aucune visibilité sur le trafic bloqué (pas de logs).

Les 3 profils réseau: lequel s'applique sur un VPS ?

Sur un VPS standalone, c'est le profil Public qui s'applique. Activez les règles sur les 3 profils pour ne rien laisser au hasard.

🔍 Vérifier l'état du pare-feu avant de commencer

Toujours commencer par un état des lieux. Connectez-vous en RDP, ouvrez PowerShell en tant qu'administrateur.

Via PowerShell: état complet des 3 profils :

Get-NetFirewallProfile | Select Name, Enabled, DefaultInboundAction, DefaultOutboundAction

Résultat attendu : Enabled = True sur les 3 profils. Si l'un est à False, activez-le immédiatement.

Via l'interface graphique :

Panneau de configuration → Système et sécurité → Pare-feu Windows Defender → vérifier que chaque profil affiche "Activé".

Activer le pare-feu si désactivé :

Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True

Vérifier les actions par défaut (recommandé) :

Set-NetFirewallProfile -Profile Domain,Private,Public `
  -DefaultInboundAction Block `
  -DefaultOutboundAction Allow

Bloquer tout le trafic entrant par défaut et n'autoriser que ce que vous définissez explicitement: c'est la posture de sécurité correcte.

🖱️ Créer une règle de pare-feu (méthode GUI)

🖥️ Accéder à l'interface Windows Defender Firewall with Advanced Security

Deux chemins possibles :

• Touche Windows → taper wf.msc → Entrée.

• Panneau de configuration → Système et sécurité → Pare-feu Windows Defender → Paramètres avancés.

L'interface affiche 3 sections : Règles de trafic entrant, Règles de trafic sortant, Règles de sécurité de connexion.

➡️ Créer une règle entrante (inbound)

1. Clic droit sur Règles de trafic entrant → Nouvelle règle.

2. Choisir le type : Port, Programme, Prédéfinie ou Personnalisée.

3. Spécifier le protocole (TCP/UDP) et le numéro de port.

4. Action : Autoriser la connexion ou Bloquer.

5. Sélectionner les profils concernés (Domaine, Privé, Public).

6. Nommer la règle de façon explicite (ex. : Allow-HTTP-80-Inbound).

⬅️ Créer une règle sortante (outbound)

La plupart des guides s'arrêtent aux règles entrantes. C'est une erreur.

1. Clic droit sur Règles de trafic sortant → Nouvelle règle.

2. Même processus que pour une règle entrante.

3. Utile pour bloquer un processus ou une IP de destination spécifique.

Exemple concret : bloquer les connexions sortantes vers un port ou une IP suspecte sans toucher au reste du trafic.

🔧 Définir le type de règle

⚡ Créer une règle de pare-feu (méthode PowerShell)

PowerShell est la méthode à privilégier sur un VPS : scriptable, reproductible, auditable. Toutes les commandes ci-dessous nécessitent une session PowerShell élevée (administrateur).

💻 Commandes essentielles New-NetFirewallRule

Structure de base :

New-NetFirewallRule `
  -DisplayName "Nom descriptif" `
  -Direction Inbound `          # ou Outbound
  -Protocol TCP `
  -LocalPort 80 `
  -Action Allow `               # ou Block
  -Profile Public,Private,Domain `
  -Enabled True

🔒 Sécuriser RDP (port 3389) : restreindre à une IP

Ne jamais laisser RDP ouvert à tout Internet. Restreindre à votre IP fixe ou à votre plage VPN.

# Bloquer RDP pour tout le monde
New-NetFirewallRule `
  -DisplayName "Block-RDP-All" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 3389 `
  -Action Block `
  -Profile Any

# Autoriser RDP uniquement depuis votre IP
New-NetFirewallRule `
  -DisplayName "Allow-RDP-MyIP" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 3389 `
  -RemoteAddress "203.0.113.10" `
  -Action Allow `
  -Profile Any

⚠️ Ordre d'application : créez d'abord la règle Allow avec votre IP, puis la règle Block. En cas de doute, testez depuis une autre session RDP ouverte avant de fermer la première.

🌐 Ouvrir HTTP/HTTPS (ports 80 et 443)

New-NetFirewallRule `
  -DisplayName "Allow-HTTP-HTTPS-Inbound" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort @(80, 443) `
  -Action Allow `
  -Profile Any

🗄️ Ouvrir SQL Server (port 1433) : restreindre à un sous-réseau

SQL Server ne doit jamais être exposé à Internet. Limitez à votre sous-réseau applicatif.

New-NetFirewallRule `
  -DisplayName "Allow-SQLServer-LAN" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 1433 `
  -RemoteAddress "10.0.0.0/24" `
  -Action Allow `
  -Profile Any

🔌 Ouvrir WinRM (5985/5986) pour la gestion distante

WinRM permet la gestion PowerShell à distance. À restreindre impérativement à une IP de gestion.

# WinRM HTTP (5985) et HTTPS (5986)
New-NetFirewallRule `
  -DisplayName "Allow-WinRM-Management" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort @(5985, 5986) `
  -RemoteAddress "203.0.113.10" `
  -Action Allow `
  -Profile Any

🚫 Bloquer un port ou une IP spécifique

# Bloquer un port entrant
New-NetFirewallRule `
  -DisplayName "Block-Port-8080-Inbound" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 8080 `
  -Action Block `
  -Profile Any

# Bloquer une IP source spécifique (entrant)
New-NetFirewallRule `
  -DisplayName "Block-IP-Suspect" `
  -Direction Inbound `
  -RemoteAddress "198.51.100.42" `
  -Action Block `
  -Profile Any

# Bloquer une connexion sortante vers une IP
New-NetFirewallRule `
  -DisplayName "Block-Outbound-IP" `
  -Direction Outbound `
  -RemoteAddress "198.51.100.42" `
  -Action Block `
  -Profile Any

📋 Règles prédéfinies Windows Server à connaître

Windows Server embarque des groupes de règles prêts à l'emploi. Activez-les par groupe plutôt que règle par règle.

Groupes utiles :

Activer un groupe entier avec netsh :

netsh advfirewall firewall set rule group="remote desktop" new enable=Yes
netsh advfirewall firewall set rule group="Windows Remote Management" new enable=Yes
netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes

Activer un groupe avec PowerShell :

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
Enable-NetFirewallRule -DisplayGroup "Windows Remote Management"

📝 Activer la journalisation du pare-feu

Sans logs, impossible de diagnostiquer un blocage ou de détecter une tentative d'intrusion.

Pourquoi logger :

• Identifier quelle règle bloque une connexion légitime.

• Détecter des scans de ports ou tentatives brute-force.

• Satisfaire aux exigences d'audit de sécurité.

Activer les logs via PowerShell (tous les profils) :

Set-NetFirewallProfile -Profile Domain,Private,Public `
  -LogFileName "%SystemRoot%\System32\LogFiles\Firewall\pfirewall.log" `
  -LogMaxSizeKilobytes 4096 `
  -LogAllowed True `
  -LogBlocked True

Activer via netsh :

netsh advfirewall set allprofiles logging filename "%SystemRoot%\System32\LogFiles\Firewall\pfirewall.log"
netsh advfirewall set allprofiles logging maxfilesize 4096
netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable

Où trouver les logs :

Chemin par défaut : C:\Windows\System32\LogFiles\Firewall\pfirewall.log

Lire les logs: format des colonnes clés :

Pour lire rapidement les connexions bloquées en PowerShell :

Get-Content "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" |
  Where-Object { $_ -match "DROP" } |
  Select-Object -Last 50

🔎 Auditer et gérer les règles existantes

C'est la section que vous ne trouverez pas chez OVH ou Amen. Gérer les règles existantes est aussi important que d'en créer de nouvelles.

Lister toutes les règles actives :

Get-NetFirewallRule | Where-Object { $_.Enabled -eq "True" } |
  Select-Object DisplayName, Direction, Action, Profile |
  Sort-Object Direction

Lister les règles actives avec les ports associés :

Get-NetFirewallRule | Where-Object { $_.Enabled -eq "True" } |
  ForEach-Object {
    $rule = $_
    $portFilter = $rule | Get-NetFirewallPortFilter
    [PSCustomObject]@{
      Name      = $rule.DisplayName
      Direction = $rule.Direction
      Action    = $rule.Action
      Protocol  = $portFilter.Protocol
      LocalPort = $portFilter.LocalPort
    }
  } | Format-Table -AutoSize

Désactiver une règle sans la supprimer :

Disable-NetFirewallRule -DisplayName "Nom de la règle"

Réactiver une règle :

Enable-NetFirewallRule -DisplayName "Nom de la règle"

Supprimer une règle définitivement :

Remove-NetFirewallRule -DisplayName "Nom de la règle"

Exporter toutes les règles (backup) :

netsh advfirewall export "C:\Backup\firewall-backup.wfw"

Importer les règles depuis un backup :

netsh advfirewall import "C:\Backup\firewall-backup.wfw"

💡 Bonne pratique : exportez vos règles avant toute modification majeure. En cas de problème, la restauration prend 10 secondes.

🚨 Dépannage : connexion refusée malgré une règle active

Votre règle existe, elle est activée, mais la connexion échoue quand même. Voici les 5 scénarios les plus fréquents.

🔍 Vérifier si le port est bien ouvert localement

# Tester depuis le serveur lui-même
[Upload...]
# Tester depuis un poste externe (remplacer l'IP)
Test-NetConnection -ComputerName 203.0.113.50 -Port 443 -InformationLevel Detailed

Si TcpTestSucceeded : False → le port n'est pas accessible. Si True → le problème vient d'ailleurs (application, DNS, etc.).

⚠️ Conflit entre règle entrante et règle sortante

Windows applique les règles Block en priorité sur Allow. Si une règle Block plus générique existe, elle écrase votre règle Allow spécifique.

Vérifiez les règles en conflit :

# Règles Block actives en entrée
Get-NetFirewallRule -Direction Inbound -Action Block -Enabled True |
  Select-Object DisplayName, Profile

📡 Profil de réseau incorrect (Public vs Privé)

Votre règle est créée pour le profil Privé, mais votre VPS est en profil Public ? Elle ne s'applique pas.

Vérifier le profil actif :

Get-NetConnectionProfile | Select-Object Name, NetworkCategory

Corriger le profil si nécessaire :

Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private

🏗️ Pare-feu réseau OuiHeberg vs pare-feu Windows : lequel bloque ?

Si Test-NetConnection depuis le serveur lui-même réussit mais échoue depuis l'extérieur, le blocage vient du pare-feu réseau OuiHeberg, pas de Windows Defender Firewall.

Diagnostic rapide :

1. Depuis le VPS : Test-NetConnection -ComputerName localhost -Port XXXX → succès = Windows OK.

2. Depuis votre poste : Test-NetConnection -ComputerName <IP_VPS> -Port XXXX → échec = pare-feu réseau.

Dans ce cas, vérifiez les règles de votre pare-feu réseau dans l'espace client OuiHeberg.

📋 Vérifier les logs pour identifier la règle bloquante

# Chercher les DROP sur un port spécifique (ex. 8080)
Get-Content "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" |
  Where-Object { $_ -match "DROP" -and $_ -match "8080" }

La colonne path indique RECEIVE (entrant) ou SEND (sortant). Cela confirme la direction du blocage.

✅ Bonnes pratiques de sécurité pare-feu sur VPS Windows

Principe du moindre privilège : tout bloquer par défaut.

Commencez avec DefaultInboundAction Block et n'ouvrez que les ports strictement nécessaires. Chaque port ouvert est une surface d'attaque.

Changer le port RDP (3389 → port custom).

Changer le port ne remplace pas une bonne règle de pare-feu, mais réduit le bruit des scans automatisés. Modifiez la clé de registre, puis créez la règle pare-feu correspondante :

# Exemple : RDP sur port 54321
New-NetFirewallRule `
  -DisplayName "Allow-RDP-Custom-Port" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 54321 `
  -RemoteAddress "203.0.113.10" `
  -Action Allow `
  -Profile Any

Consultez notre guide connexion RDP pour la procédure complète de changement de port.

Restreindre RDP à une IP ou plage d'IP.

Si vous avez une IP fixe, c'est la mesure la plus efficace. Si votre IP change, utilisez un VPN et autorisez uniquement la plage VPN.

Désactiver les règles inutilisées.

Ne supprimez pas: désactivez. Vous pourrez les réactiver si besoin. Auditez les règles actives tous les trimestres.

Audit régulier des règles.

# Export mensuel des règles actives
Get-NetFirewallRule | Where-Object { $_.Enabled -eq "True" } |
  Export-Csv "C:\Audit\firewall-rules-$(Get-Date -Format 'yyyy-MM').csv" -NoTypeInformation

📊 Récapitulatif : checklist pare-feu VPS Windows

❓ FAQ

Quelle différence entre Windows Defender Firewall et un pare-feu réseau ?

Le pare-feu réseau (niveau infrastructure, chez OuiHeberg) filtre le trafic avant qu'il n'atteigne votre VPS. Windows Defender Firewall opère au niveau de l'OS : il contrôle les connexions programme par programme, port par port, avec des règles par profil réseau. Les deux sont complémentaires: l'un ne remplace pas l'autre.

Comment ouvrir un port sur un VPS Windows Server ?

En PowerShell (administrateur) :

New-NetFirewallRule -DisplayName "Allow-Port-XXXX" -Direction Inbound -Protocol TCP -LocalPort XXXX -Action Allow -Profile Any

Remplacez XXXX par le numéro de port. Si le port reste inaccessible depuis l'extérieur, vérifiez aussi le pare-feu réseau OuiHeberg dans votre espace client.

Mon application ne répond pas malgré une règle ouverte: que faire ?

Vérifiez dans cet ordre :

1. Test-NetConnection -ComputerName localhost -Port XXXX: le port est-il écouté ?

2. Le profil réseau actif correspond-il au profil de la règle ?

3. Une règle Block plus générique n'écrase-t-elle pas votre règle Allow ?

4. Le blocage vient-il du pare-feu réseau OuiHeberg (test depuis l'extérieur) ?

5. Consultez les logs : Get-Content pfirewall.log | Where-Object { $_ -match "DROP" }

Faut-il activer le pare-feu sur tous les profils (Domaine, Privé, Public) ?

Oui, toujours. Sur un VPS, le profil Public est généralement actif. Mais si la configuration réseau change (ajout d'une interface, jonction à un domaine), un autre profil peut s'activer. Activer les 3 profils garantit une protection continue quelle que soit la situation.

Comment sauvegarder mes règles de pare-feu Windows Server ?

netsh advfirewall export "C:\Backup\firewall-backup.wfw"

Pour restaurer :

netsh advfirewall import "C:\Backup\firewall-backup.wfw"

Planifiez cette export dans une tâche planifiée Windows avant chaque maintenance.

Quel port utilise RDP par défaut et comment le changer ?

RDP utilise le port TCP 3389 par défaut. Pour le changer :

1. Modifiez la clé de registre : HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp → valeur PortNumber.

2. Créez une nouvelle règle pare-feu autorisant le nouveau port depuis votre IP.

3. Désactivez (ou supprimez) la règle sur le port 3389.

4. Redémarrez le service TermService.

Consultez notre guide connexion RDP pour la procédure détaillée.

🔗 Sources utiles

• New-NetFirewallRule: Microsoft Learn

• Set-NetFirewallProfile: Microsoft Learn

• Windows Defender Firewall with Advanced Security: Microsoft Learn

• Gérer le pare-feu Windows via la ligne de commande: Microsoft Learn

• netsh advfirewall: Microsoft Learn

• Test-NetConnection: Microsoft Learn