Ports 110/143/1433/3306 « open » malgré Windows Defender Firewall sur Windows Server 2022 (Plesk) : causes, tests et solutions

Vous avez bloqué POP 110, IMAP 143, SQL 1433 et MySQL 3306 dans Windows Defender Firewall, mais un scan Nmap continue de les indiquer « open » ? Voici une méthode concrète et reproductible pour comprendre pourquoi et les fermer réellement sur Windows Server 2022 avec Plesk.

Sommaire

Vue d’ensemble du problème

Scénario typique : un serveur Windows Server 2022 hébergeant Plesk perd soudain ses règles de pare‑feu. Une adresse APIPA 169.254.x.x apparaît, symptôme d’un DHCP défaillant ou d’un changement d’interface. Après rétablissement des règles Plesk / Windows Defender, vous désactivez les ports non sécurisés (POP 110, IMAP 143, SQL 1433, MySQL 3306) dans l’interface graphique et même via des règles « Block ». Pourtant, Nmap affiche toujours ces ports en « open ». La question : comment s’assurer qu’ils sont vraiment fermés ?

Comprendre « open » dans Nmap vs. Windows Defender Firewall

Nmap « open » : une application répond au handshake (SYN/SYN‑ACK) ou à connect(). Le port écoute réellement.
Nmap « closed » : aucun processus n’écoute ; le système renvoie généralement un RST.
Nmap « filtered » : un filtre (pare‑feu, ACL, routeur) bloque ou ignore les paquets.

Point clé : Windows Defender Firewall ne filtre pas le trafic de bouclage (loopback). Si vous scannez depuis la machine elle‑même (Nmap vers 127.0.0.1 ou l’IP locale), les ports apparaîtront « open » tant qu’un service écoute, même si une règle inbound bloquerait ce trafic depuis l’extérieur. Testez toujours depuis un hôte distant pour valider l’exposition réelle.

Checklist : pourquoi ces ports restent affichés « open » ?

Symptôme	Pourquoi Nmap voit « open »	Vérification	Correction
Scan exécuté depuis le serveur	Le loopback n’est pas filtré par le pare‑feu	Comparer un scan local et un scan depuis une autre machine	Valider avec un scan externe ; le local n’est pas probant
Un service écoute encore	Un processus POP/IMAP/SQL répond au handshake	`netstat -abno` / `Get-NetTCPConnection`	Arrêter/désactiver le service ou restreindre son binding
Règle mal orientée	Règle outbound créée, mais trafic à bloquer est inbound	Vérifier Direction dans la règle	Créer des règles inbound et, si besoin, outbound
Profil inadapté	La règle s’applique à Private mais l’interface est en Public	`Get-NetConnectionProfile`	Appliquer la règle à Any (Domain/Private/Public) ou corriger le profil
Scope limité	La règle ne bloque que Local Subnet	Onglet Scope / `Get-NetFirewallAddressFilter`	Bloquer Any adresse distante (IPv4/IPv6)
Edge traversal	Des paquets traversent via NAT/Edge	Champ EdgeTraversal de la règle	Forcer EdgeTraversalPolicy = Block
Firewall amont autorisant/redirect	Un Security Group / pare‑feu VPS publie le port	Comparer scan public vs. privé ; inspecter la console du cloud	Bloquer au niveau du SG/ACL en plus de l’hôte
Changement d’IP (APIPA 169.254.x.x)	Règles liées à l’ancienne interface/IPv4 uniquement	`ipconfig /all` et liste des interfaces	Rétablir l’IP correcte, lier les règles à Any interface
IPv6 encore ouvert	Blocage mal ciblé, service écoute sur ::	`netstat -ano` affiche `:::1433` etc.	Règles couvrant v4 & v6 ; restreindre le binding
Plesk gère ses propres règles	Extension Firewall de Plesk réécrit les ACL	Comparer l’état avant/après application Plesk	Définir les ports en deny aussi côté Plesk
Hyper‑V / conteneurs / portproxy	Redirection locale publiée sur l’externe	`netsh interface portproxy show all`	Supprimer les mappings indésirables
Règles contradictoires	Une règle Allow plus spécifique prend le dessus	`Get-NetFirewallRule` + filtres	Supprimer/désactiver l’Allow ou ajouter un Block plus spécifique

Procédure en 7 étapes pour fermer de façon certaine

1) Vérifier qui écoute vraiment

Avant de « tirer sur le pare‑feu », confirmez qu’aucune application utile ne dépend de ces ports.

netstat -abno | findstr /R ":(110|143|1433|3306)\s"
# Ou PowerShell
Get-NetTCPConnection -LocalPort 110,143,1433,3306 |
  Select-Object LocalAddress,LocalPort,State,OwningProcess |
  Sort-Object LocalPort

# Identifier le processus

Get-Process -Id

Si un service écoute et que vous n’en avez plus besoin, désactivez‑le : c’est la fermeture la plus sûre.

# Exemples (adaptez les noms réels)
Stop-Service "MailEnable POP3"; Set-Service "MailEnable POP3" -StartupType Disabled
Stop-Service "MailEnable IMAP"; Set-Service "MailEnable IMAP" -StartupType Disabled
Stop-Service "MySQL80";        Set-Service "MySQL80"        -StartupType Disabled
Stop-Service "MSSQLSERVER";    Set-Service "MSSQLSERVER"    -StartupType Disabled

2) Créer des règles de blocage explicite (inbound & outbound)

Empêchez l’ouverture accidentelle future, même si une application reconfigure le pare‑feu.

# PowerShell moderne (recommandé)
$ports = 110,143,1433,3306
foreach ($p in $ports) {
  New-NetFirewallRule -DisplayName "BLOCK In TCP $p" `
    -Direction Inbound -Action Block -Protocol TCP -LocalPort $p `
    -Profile Any -EdgeTraversalPolicy Block
  New-NetFirewallRule -DisplayName "BLOCK Out TCP $p" `
    -Direction Outbound -Action Block -Protocol TCP -RemotePort $p `
    -Profile Any
}

# Équivalent 'netsh' (si politique, script hérité, etc.)

netsh advfirewall firewall add rule name="Block Port 110 In"  dir=in  action=block protocol=TCP localport=110
netsh advfirewall firewall add rule name="Block Port 110 Out" dir=out action=block protocol=TCP remoteport=110
netsh advfirewall firewall add rule name="Block Port 143 In"  dir=in  action=block protocol=TCP localport=143
netsh advfirewall firewall add rule name="Block Port 143 Out" dir=out action=block protocol=TCP remoteport=143
netsh advfirewall firewall add rule name="Block Port 1433 In" dir=in  action=block protocol=TCP localport=1433
netsh advfirewall firewall add rule name="Block Port 1433 Out" dir=out action=block protocol=TCP remoteport=1433
netsh advfirewall firewall add rule name="Block Port 3306 In" dir=in  action=block protocol=TCP localport=3306
netsh advfirewall firewall add rule name="Block Port 3306 Out" dir=out action=block protocol=TCP remoteport=3306

Pour SQL Server, bloquez aussi le SQL Browser en UDP 1434 si vous ne publiez pas d’instances nommées :

New-NetFirewallRule -DisplayName "BLOCK In UDP 1434" -Direction Inbound -Action Block -Protocol UDP -LocalPort 1434 -Profile Any

3) Contrôler la priorité et la portée des règles

Une règle Allow plus spécifique (par exemple limitée à une IP, un service ou une interface) peut neutraliser un Block mal positionné. Vérifiez la pile complète :

# Règles liées aux ports cibles
Get-NetFirewallRule | Where-Object {$_.DisplayName -match '110|143(\D|$)|1433|3306'} |
  Get-NetFirewallPortFilter, Get-NetFirewallAddressFilter, Get-NetFirewallApplicationFilter |
  Format-List

# Activer l’audit si besoin (journalisation des paquets bloqués)

Set-NetFirewallProfile -All -LogAllowed True -LogBlocked True -LogMaxFileSizeKB 4096

Assurez-vous que vos règles s’appliquent à tous les profils (Domain, Private, Public) et à toutes les adresses distantes. Désactivez ou supprimez les Allow superflus hérités de Plesk ou d’anciennes configurations.

4) Redémarrer le service pare‑feu et remettre à plat

Lors de modifications massives, forcez un rechargement propre.

Restart-Service -Name mpssvc
# Si l’état est incohérent&nbsp;:
netsh advfirewall reset
# ⚠️ Réimportez ensuite vos règles (sauvegardées au préalable)

5) Vérifier la couche réseau externe (VPS/Cloud/Edge)

Un Security Group ou pare‑feu amont peut publier un port indépendamment de Windows Defender. Bloquez aussi en amont. Assurez-vous que les règles Plesk (si son extension Firewall est utilisée) refusent explicitement ces ports.

6) Corriger l’adressage IP (APIPA) et le profil réseau

Une interface en 169.254.x.x signifie « pas de DHCP ». Rétablissez l’IP statique/ DHCP corrects, la passerelle et le DNS, puis contrôlez le profil réseau actif :

# Voir le profil
Get-NetConnectionProfile

# Si nécessaire, replacer l’interface en Private (exemple)

Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private

Des règles limitées à Private/Domain ne s’appliquent pas si l’interface est en Public, et inversement.

7) Valider correctement (depuis l’extérieur)

Testez depuis une autre machine, idéalement depuis Internet si votre serveur est public.

# Windows
Test-NetConnection -ComputerName <IP_publique> -Port 1433 -InformationLevel Detailed
Test-NetConnection -ComputerName <IP_publique> -Port 3306 -InformationLevel Detailed

# Nmap (depuis un hôte externe)

nmap -Pn -sS -p 110,143,1433,3306 
nmap -6 -Pn -sS -p 110,143,1433,3306   # si applicable

Script d’automatisation « tout‑en‑un » (audit, blocage, test)

Le bloc suivant automatise l’audit, la création de règles Block, la désactivation optionnelle des services connus et une validation locale (indicative) :

# Exécuter en PowerShell en tant qu'administrateur

$Ports = 110,143,1433,3306

Write-Host "== Audit des écoutes =="
Get-NetTCPConnection -LocalPort $Ports -ErrorAction SilentlyContinue |
Select-Object LocalAddress,LocalPort,State,OwningProcess |
Sort-Object LocalPort | Format-Table -AutoSize

Write-Host "== Règles de blocage (In/Out) =="
foreach ($p in $Ports) {
if (-not (Get-NetFirewallRule -DisplayName "BLOCK In TCP $p" -ErrorAction SilentlyContinue)) {
New-NetFirewallRule -DisplayName "BLOCK In TCP $p" -Direction Inbound -Action Block -Protocol TCP -LocalPort $p -Profile Any -EdgeTraversalPolicy Block | Out-Null
}
if (-not (Get-NetFirewallRule -DisplayName "BLOCK Out TCP $p" -ErrorAction SilentlyContinue)) {
New-NetFirewallRule -DisplayName "BLOCK Out TCP $p" -Direction Outbound -Action Block -Protocol TCP -RemotePort $p -Profile Any | Out-Null
}
}

Write-Host "== Journalisation Firewall =="
Set-NetFirewallProfile -All -LogAllowed True -LogBlocked True -LogMaxFileSizeKB 8192

Write-Host "== Services (optionnel : décommentez) =="

# Stop-Service "MailEnable POP3" -ErrorAction SilentlyContinue

# Set-Service "MailEnable POP3" -StartupType Disabled

# Stop-Service "MailEnable IMAP" -ErrorAction SilentlyContinue

# Set-Service "MailEnable IMAP" -StartupType Disabled

# Stop-Service "MySQL80" -ErrorAction SilentlyContinue

# Set-Service "MySQL80" -StartupType Disabled

# Stop-Service "MSSQLSERVER" -ErrorAction SilentlyContinue

# Set-Service "MSSQLSERVER" -StartupType Disabled

Write-Host "== Vérification (locale) =="
foreach ($p in $Ports) {
try {
$r = Test-NetConnection -ComputerName 127.0.0.1 -Port $p -WarningAction SilentlyContinue
"{0}/TCP loopback Listening={1}" -f $p, $r.TcpTestSucceeded
} catch {}
}

Write-Host "== Rappel =="
Write-Host "Validez depuis un hôte distant avec Nmap ou Test-NetConnection."

Cas particuliers Plesk (Windows)

POP/IMAP : Plesk s’appuie souvent sur MailEnable sous Windows. Si vous n’offrez pas de messagerie, désactivez les services IMAP/POP au niveau de Windows et dans Plesk (pour éviter une réactivation automatique).
MySQL/MariaDB (3306) : si la base ne doit pas être exposée, soit désactivez le service, soit limitez‑le à 127.0.0.1 (fichier my.ini, clé bind-address=127.0.0.1) et ajoutez vos règles Block.
SQL Server (1433) : via SQL Server Configuration Manager, désactivez Listen All et ne laissez que l’IP loopback si l’accès est strictement local. Si vous n’utilisez plus SQL, désactivez le service. Si vous gardez SQL Browser, bloquez UDP 1434 en inbound.
Extension Firewall Plesk : alignez la politique Plesk sur Windows Defender (mêmes ports en deny), sinon Plesk peut écraser vos ACL à la prochaine application.

IPv4, IPv6 et « ouvert ici / fermé là »

Un service peut écouter simultanément en IPv4 et IPv6 (0.0.0.0:1433 et :::1433). Si vous ne bloquez que l’un des deux, Nmap peut encore voir « open ». Les règles ci‑dessus pour TCP couvrent les deux piles ; vérifiez néanmoins le binding d’écoute dans netstat -ano.

Diagnostics avancés

Règles contradictoires : listez toutes les règles pertinentes : Get-NetFirewallRule | Where-Object {$_.DisplayName -match '110|143(\D|$)|1433|3306'} | Format-Table -AutoSize
Portproxy / redirections : netsh interface portproxy show all # Supprimer un mapping inutile netsh interface portproxy delete v4tov4 listenport=1433 listenaddress=0.0.0.0
Hyper‑V / conteneurs : un switch virtuel NAT peut publier des ports via WinNAT. Inspectez votre stack virtuelle si le serveur héberge des VMs/conteneurs.
Journal Firewall : le fichier journal (chemin défini dans les profils) permet de vérifier qu’un paquet entrant a bien été bloqué.

Plan de prévention et résilience

Sauvegarder vos règles après (ré)création : Export-WindowsFirewallRules -FilePath "C:\Backup\wfpol.wfw" # via MMC WF.msc # ou PowerShell (granulaire) Get-NetFirewallRule | Export-Clixml "C:\Backup\firewall_rules.xml"
Politique « deny first » : n’autorisez que ce qui est strictement nécessaire. Bloquez explicitement les ports sensibles (110, 143, 1433, 3306, 3389 si non utilisé, etc.).
Surveillance : programmez des scans depuis un hôte externe de confiance (Nmap) après chaque changement majeur (mises à jour Plesk, patchs SQL/MySQL, changement réseau).
Rollback rapide : conservez un snapshot/backup système et une copie hors‑machine des règles. En cas de doute, restaurer un état connu reste la voie la plus rapide.

FAQ courte

Pourquoi Nmap indique encore « open » après mes règles ?
Parce que l’application écoute toujours et que vous scannez peut‑être en local. Le pare‑feu n’intercepte pas le loopback ; testez depuis l’extérieur et arrêtez/désactivez le service si vous n’en avez plus l’usage.

Un « Block » ne devrait‑il pas gagner sur un « Allow » ?
Oui, un blocage explicite prend le pas, mais une Allow plus spécifique (par exemple ciblée service/interface) peut s’appliquer dans une autre couche. D’où l’intérêt d’un Block global sur tous profils et toutes adresses, et de retirer les Allow superflus.

Dois‑je aussi bloquer UDP 1434 ?
Si vous n’exposez pas d’instances nommées SQL, bloquez‑le pour éviter la découverte à distance.

APIPA 169.254.x.x a tout cassé ; rapport avec le pare‑feu ?
Oui : le changement d’interface/profil peut invalider vos hypothèses de portée des règles. Corrigez l’IP, le profil et réappliquez vos politiques.

Modèle d’exécution pas‑à‑pas (résumé opérationnel)

Étape	Action	Objectif
1. Vérifier l’écoute	`netstat -ano` ou `Get-NetTCPConnection -LocalPort 110,143,1433,3306`	Confirmer qu’aucun processus POP/IMAP/SQL/MySQL n’écoute
2. Règles de blocage explicites	Créer des Block In/Out pour 110, 143, 1433, 3306 (et UDP 1434)	Empêcher toute (ré)ouverture, même depuis Plesk ou un setup
3. Priorité & portée	Vérifier profils, scope, EdgeTraversal, Allow concurrentes	S’assurer qu’aucune Allow plus spécifique ne contourne le Block
4. Redémarrer le service Firewall	`Restart-Service mpssvc` (ou `netsh advfirewall reset`)	Recharger une configuration propre
5. Effet de l’amont	Contrôler Security Groups/pare‑feux VPS & règles Plesk	Éviter une exposition malgré le blocage local
6. IP & profil réseau	Remplacer APIPA par l’IP correcte, corriger le profil	Aligner la portée des règles et l’interface active
7. Validation externe	`Test-NetConnection` / Nmap depuis une autre machine	Confirmer l’état réel depuis l’extérieur

Conclusion

Si Nmap continue d’indiquer « open » sur 110/143/1433/3306 après vos réglages, ne suspectez pas d’emblée un « pare‑feu qui n’obéit pas ». Dans l’immense majorité des cas : (1) un service écoute encore, (2) le test est réalisé en loopback, (3) une règle/profil/scope est mal ciblé, ou (4) une couche réseau amont publie le port. En suivant la checklist et la procédure ci‑dessus—désactivation des services non nécessaires, règles Block explicites et globales, contrôle des profils/scope/EdgeTraversal, redémarrage du service pare‑feu, vérification des ACL amont et validation depuis l’extérieur—vous obtiendrez une fermeture certaine de ces ports sensibles.