ports VPS Windows··8 min de lecture·Par l'équipe OmegaCloud

Quels ports ouvrir sur un hébergement VPS Windows ?

Illustration immersive du sujet : ports VPS Windows

Savoir quels ports VPS Windows ouvrir est une etape critique lors de la mise en production d'un serveur distant sous Windows Server. Un pare-feu mal configure expose votre machine aux scans automatises et aux tentatives d'intrusion, tandis qu'un filtrage trop restrictif casse vos services. Ce guide 2026 detaille les ports essentiels, la logique de segmentation reseau et les commandes PowerShell concretes pour securiser votre environnement RDP.



Comprendre les ports VPS Windows et leur role

Sur un serveur Windows accessible depuis Internet, chaque port ouvert represente une surface d'attaque potentielle. La regle est simple : n'ouvrez que ce qui est strictement necessaire au fonctionnement de vos applications. Les ports VPS Windows se repartissent en trois grandes categories selon leur usage : administration, services web/applicatifs et protocoles reseau specifiques.

Les ports d'administration a maitriser en priorite

Le port le plus sensible sur un VPS Windows reste le 3389/TCP, utilise par le protocole RDP (Remote Desktop Protocol). C'est la porte d'entree de votre session graphique distante. Laisser ce port ouvert a l'ensemble d'Internet est la premiere cause de compromission des serveurs Windows exposes.

Port Protocole Usage Exposition recommandee
3389 TCP/UDP RDP (bureau a distance) IP fixe uniquement
5985 TCP WinRM HTTP (PowerShell remoting) Reseau interne / VPN
5986 TCP WinRM HTTPS Reseau interne / VPN
22 TCP OpenSSH (disponible sous Windows Server) Cles uniquement

Les ports de services web et applicatifs

Si votre VPS heberge un site ou une API, vous aurez besoin d'exposer les ports HTTP et HTTPS. Ce sont les seuls ports que l'on ouvre generalement en grand vers l'exterieur, car ils correspondent a un service public.

Port Protocole Usage
80 TCP HTTP (redirection vers HTTPS)
443 TCP HTTPS (TLS)
1433 TCP SQL Server (a ne jamais exposer publiquement)
25 / 587 / 465 TCP SMTP (mail sortant / soumission)
21 / 990 TCP FTP / FTPS (a eviter, preferer SFTP)
Principe directeur : un port de base de donnees comme 1433 (SQL Server) ou 3306 (MySQL) ne doit JAMAIS etre accessible depuis Internet. Restreignez-le au localhost ou a votre reseau prive.


Configurer le pare-feu Windows Defender pour vos ports VPS Windows

Windows Server embarque un pare-feu robuste : Windows Defender Firewall with Advanced Security. Sur un VPS Windows OmegaCloud, vous disposez d'un environnement RDP pret a l'emploi, mais la configuration fine des regles reste de votre responsabilite. PowerShell est l'outil le plus rapide et reproductible pour gerer ces regles.

Lister les regles existantes

Avant toute modification, faites l'inventaire de ce qui est deja ouvert :

Get-NetFirewallRule -Enabled True -Direction Inbound |
  Where-Object { $_.Action -eq "Allow" } |
  Format-Table DisplayName, Profile, Action -AutoSize

Pour identifier precisement les ports lies a une regle :

Get-NetFirewallRule -DisplayName "*Remote Desktop*" |
  Get-NetFirewallPortFilter |
  Format-Table LocalPort, Protocol

Restreindre le RDP a une IP source

Plutot que de laisser le 3389 ouvert a tous, limitez-le a votre adresse IP fixe. C'est la mesure la plus efficace contre les attaques par force brute sur RDP.

New-NetFirewallRule -DisplayName "RDP-Admin-Restreint" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 3389 `
  -RemoteAddress 203.0.113.42 `
  -Action Allow

# Puis desactiver la regle RDP par defaut trop permissive
Disable-NetFirewallRule -DisplayName "Remote Desktop - User Mode (TCP-In)"

Ouvrir les ports web publics

New-NetFirewallRule -DisplayName "HTTP-Public" `
  -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow

New-NetFirewallRule -DisplayName "HTTPS-Public" `
  -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

Bloquer explicitement les ports sensibles

Une regle de blocage explicite sur les ports de base de donnees ajoute une couche de securite en profondeur :

New-NetFirewallRule -DisplayName "Block-SQL-External" `
  -Direction Inbound -Protocol TCP -LocalPort 1433 `
  -RemoteAddress Internet -Action Block

Changer le port RDP par defaut

Deplacer RDP sur un port non standard reduit le bruit des scans automatises. Ce n'est pas une protection suffisante a elle seule, mais cela nettoie vos logs. Modifiez la cle de registre puis ouvrez le nouveau port :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name PortNumber -Value 49200

New-NetFirewallRule -DisplayName "RDP-Custom" `
  -Direction Inbound -Protocol TCP -LocalPort 49200 `
  -RemoteAddress 203.0.113.42 -Action Allow

Restart-Service TermService -Force


Securiser l'ensemble sans multiplier les ports ouverts

Ouvrir des ports VPS Windows n'a de sens que si l'exposition s'accompagne de mesures de durcissement. L'objectif est de reduire la surface d'attaque tout en gardant un serveur exploitable au quotidien.

Authentification et acces

  • NLA (Network Level Authentication) : activez-le sur RDP pour exiger une authentification avant l'ouverture de session complete.
  • OpenSSH sur Windows Server : preferez l'authentification par cle plutot que par mot de passe pour les acces administratifs en ligne de commande.
  • 2FA sur le panel : activez l'authentification a deux facteurs sur le panel OmegaCloud pour proteger la gestion de votre infrastructure.
  • Comptes dedies : evitez d'exposer le compte Administrateur par defaut, creez des comptes nominatifs avec droits limites.

Generer une paire de cles pour l'acces SSH vers votre serveur Windows depuis un poste Linux :

ssh-keygen -t ed25519 -C "admin@omega-vps" -f ~/.ssh/omega_win

# Deposer la cle publique dans authorized_keys sur le serveur Windows
# (C:\ProgramData\ssh\administrators_authorized_keys pour un compte admin)

La protection volumetrique deja prise en charge

La question des attaques par saturation revient souvent quand on ouvre des ports publics. Sur l'infrastructure OmegaCloud, la mitigation anti-DDoS volumetrique est geree au niveau kernel cote reseau, de maniere transparente. Vous n'avez pas de service supplementaire a installer ni a configurer pour absorber les floods L3/L4 : cela reste actif par defaut sur tous les services. Votre travail se concentre donc sur le filtrage applicatif et la gestion des acces, pas sur la couche volumetrique.

Surveiller les connexions actives

Pour verifier quels ports sont reellement en ecoute et par quel processus :

Get-NetTCPConnection -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess |
  Sort-Object LocalPort |
  Format-Table -AutoSize

# Correlation avec les processus
Get-Process -Id (Get-NetTCPConnection -LocalPort 3389).OwningProcess

Cette verification reguliere permet de detecter un service qui ouvrirait un port inattendu apres une mise a jour ou l'installation d'un logiciel tiers.

Segmenter avec le reseau prive

Pour les communications entre plusieurs machines (VPS Windows applicatif et base de donnees, par exemple), privilegiez un reseau prive interne. Les ports de service (1433, 5985) restent alors accessibles uniquement entre vos serveurs, sans passer par Internet. Le panel expose un dashboard temps reel CPU/RAM/SSD/reseau qui aide a reperer un trafic anormal sur un port donne.

Checklist des ports a exposer selon le role du serveur

  • Serveur web public : 80, 443 ouverts a tous ; 3389 restreint a votre IP.
  • Serveur applicatif interne : ports metier sur reseau prive uniquement ; aucun port public sauf administration filtree.
  • Serveur base de donnees : 1433/3306 en localhost ou reseau prive ; jamais d'exposition Internet.
  • Serveur d'administration : 3389 et/ou 22 restreints par IP source, NLA active, 2FA sur le panel.

Pour aller plus loin sur la configuration du pare-feu avance et les profils reseau, la documentation officielle de Microsoft constitue une reference fiable : Source.

Automatiser via l'API et la CI/CD

Si vous gerez plusieurs serveurs, scriptez la configuration des ports plutot que de la faire a la main. Les Integrations & API OmegaCloud permettent de piloter le provisioning via API REST et pipelines GitHub Actions ou GitLab CI. Vous pouvez ainsi appliquer une baseline de regles de pare-feu identique sur chaque nouveau VPS, garantissant la coherence de votre parc. Pour des workloads Linux equivalents, les memes principes s'appliquent sur les VPS Linux OmegaCloud avec ufw ou nftables.

# Exemple de baseline ufw cote Linux (equivalent conceptuel)
ufw default deny incoming
ufw default allow outgoing
ufw allow 443/tcp
ufw allow from 203.0.113.42 to any port 22 proto tcp
ufw enable


Conclusion

Maitriser les ports VPS Windows revient a appliquer une regle constante : ouvrir le minimum, filtrer par IP source les acces d'administration, et ne jamais exposer une base de donnees a Internet. Combinez pare-feu Windows Defender, NLA sur RDP, 2FA sur le panel et surveillance reguliere des ports en ecoute. La couche volumetrique etant deja geree cote infrastructure, votre attention se porte sur le filtrage applicatif.



FAQ

Faut-il changer le port RDP 3389 par defaut sur un VPS Windows ?

Changer le port 3389 reduit le bruit des scans automatises et allege vos logs, mais ce n'est pas une protection reelle contre un attaquant motive. La mesure prioritaire reste de restreindre l'acces RDP a votre IP fixe via une regle de pare-feu, d'activer NLA et d'utiliser des mots de passe forts ou une authentification par cle. Le changement de port est une couche complementaire, pas un substitut.

Quels ports ne doivent jamais etre ouverts vers Internet ?

Les ports de bases de donnees (1433 pour SQL Server, 3306 pour MySQL), le WinRM (5985/5986) et les partages SMB (445) ne doivent jamais etre exposes publiquement. Ils doivent rester en localhost ou sur un reseau prive interne. Une exposition Internet de ces services conduit rapidement a une compromission via brute force ou exploitation de vulnerabilites connues.

Comment verifier rapidement quels ports sont ouverts sur mon VPS Windows ?

Utilisez la commande PowerShell Get-NetTCPConnection -State Listen pour lister les ports en ecoute et les processus associes, et Get-NetFirewallRule -Enabled True -Direction Inbound pour auditer les regles autorisees. Completez avec un scan externe depuis un poste tiers pour valider ce qui est reellement accessible depuis Internet, car le pare-feu local ne reflete pas toujours l'exposition reseau reelle.

Prêt à mettre en pratique ce que vous venez de lire ?

Découvrir nos offres

Articles liés

Prêt à vous lancer ?

à partir de 6,99 € HT/mois

Découvrir nos offres

Hébergements

Navigation