Windows 11 : « http://+:3387.rdp was successfully added » — signification, sécurité et suppression

Après une réinstallation de Windows 11, vous voyez dans l’Observateur d’événements : « http://+:3387.rdp was successfully added ». Voici ce que cela signifie, comment vérifier si un service écoute réellement sur ce port et, au besoin, comment supprimer proprement cette réservation.

Sommaire

Vue d’ensemble : d’où vient l’événement « http://+:3387.rdp was successfully added »

Ce message est généré par la pile HTTP de Windows, aussi appelée HTTP Server API (http.sys). Lorsqu’un service demande au système d’enregistrer une réservation d’URL (URL namespace reservation, alias URLACL), Windows consigne l’opération. Concrètement, un composant (le plus souvent lié à Remote Desktop / RDP ou à un module qui s’y intègre) a réservé le préfixe d’URL http://+:3387.rdp afin d’empêcher d’autres processus de s’y attacher.

Important : une réservation d’URL n’équivaut ni à une ouverture de port réseau ni à un service réellement à l’écoute. C’est un enregistrement de nom d’URL côté noyau, pas une socket TCP ouverte.

Décomposer la chaîne « http://+:3387.rdp »

Schéma : http:// → réservation au niveau HTTP (via http.sys), pas HTTPS.
Hôte : + → correspond à « toutes les adresses locales » (wildcard).
Port : 3387 → différent du port RDP 3389 par défaut. Ce n’est pas un choix « canonique » pour RDP, mais certains composants réservent des préfixes supplémentaires pour des scénarios internes, de test, de compatibilité ou d’outillage.
Suffixe : .rdp → extension souvent associée aux fichiers de connexion RDP/RemoteApp. Dans une réservation HTTP, ce suffixe fait partie du préfixe d’URL que le service voudrait éventuellement exposer (p. ex. pour servir un fichier .rdp ou un endpoint lié).

Le tout signifie simplement : « si un processus décide un jour de publier une ressource HTTP sur http://toute_ip_locale:3387/.rdp, il en a l’exclusivité grâce à cette réservation ».

Réponse rapide & solution

Point traité	Explications pratiques	Commande clé
Origine	L’événement provient de HTTP Server API. Quand un composant réserve un espace de noms URL (URLACL), Windows journalise l’ajout. « 3387 » n’est pas, à lui seul, la preuve d’un port réseau ouvert.
Rôle de la réservation	Empêcher les conflits : le préfixe d’URL est « verrouillé » pour un propriétaire (service, SID). Des modules liés à RDP peuvent déposer de telles réservations à l’installation ou à l’activation.	`netsh http show urlacl`
Sécurité	Une réservation ne traverse ni le pare-feu ni la pile TCP : elle ne signifie pas qu’un service écoute. Vérifiez l’écoute effective avant toute action.	`netstat -ano \| find ":3387"`
Normalité	Sur une installation neuve, après l’activation de RDP ou l’ajout de composants RemoteApp/assistance à distance, voir une réservation supplémentaire est courant et généralement inoffensif.
Suppression (optionnelle)	Listez puis supprimez exactement la ligne identifiée. L’entrée peut être recréée ultérieurement si le composant en a besoin.	`netsh http delete urlacl url=<copier le préfixe exact>`
Désactivation RDP	Si vous n’utilisez pas le Bureau à distance, désactivez-le et verrouillez les règles du pare-feu correspondantes.	Paramètres → Système → Bureau à distance

Réservation d’URL ≠ ouverture de port : comprendre la différence

La pile http.sys gère des préfixes d’URL côté noyau. Lorsqu’un service déclare « je compte utiliser http://+:3387/.rdp », http.sys stocke l’ACL (propriétaire, SDDL, options). À ce stade, rien n’écoute sur le port. L’écoute survient uniquement lorsqu’un processus crée un binding réseau (socket) sur le port.

En termes simples :

Réservation URL (URLACL) : une entrée de registre noyau pour réserver un espace de noms HTTP. Pas de socket, pas de trafic.
Ouverture de port : un processus appelle bind/listen sur TCP/UDP ⇒ netstat le montre, le pare-feu peut bloquer/autoriser.

Vérifier si quelque chose écoute réellement sur 3387

Tester l’écoute netstat -ano | find ":3387" Résultat vide ? Rien n’écoute. Un résultat avec LISTENING ou UDP ? Notez le PID.
Identifier le processus tasklist /FI "PID eq <PID_trouvé>" Ou en PowerShell : Get-Process -Id <PID_trouvé> | Select-Object Id,ProcessName,Path
Contrôler le pare-feu Get-NetFirewallRule -Enabled True | Where-Object {$_.DisplayName -match "3387|Remote|Bureau à distance"} | Get-NetFirewallPortFilter
Vérifier le port RDP configuré reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber La valeur par défaut est 3389. Si vous voyez 3387, votre instance RDP a été explicitement reconfigurée.
Inspecter les réservations URL netsh http show urlacl | findstr /I 3387 Puis regardez la fiche complète : netsh http show urlacl Repérez URL, Utilisateur (SID/service propriétaire) et les autorisations (SDDL).
État des services HTTP netsh http show servicestate view=requestq=detail Cela liste les préfixes actuellement revendiqués et leur propriétaire au sein de http.sys.

Pourquoi 3387 peut-il apparaître après une réinstallation ?

Même si le port 3387 n’est pas standard pour RDP, vous pouvez voir sa réservation :

Modules RDP/assistance fournis par Windows (ou des pilotes/compléments OEM) qui réservent des préfixes supplémentaires pour des fonctions internes (génération de fichiers .rdp, handlers HTTP auxiliaires, compatibilité).
Outils tiers liés au support à distance ou au déploiement, installés par l’OEM ou réintégrés par une sauvegarde, qui posent une URLACL même s’ils ne tournent pas en permanence.
Pré‑provisionnement : certains composants réservent des URL à l’installation pour éviter les conflits futurs, sans démarrer de service.

Dans tous les cas, ce n’est pas un indicateur de compromission à lui seul. L’audit ci‑dessous vous permet de trancher.

Supprimer proprement la réservation (optionnel)

Uniquement si l’audit montre qu’aucun service légitime n’en a besoin et que vous préférez un système minimaliste :

Ouvrez une console administrateur (Terminal Windows → « Exécuter en tant qu’administrateur »).
Listez la réservation exacte (copiez à l’identique la valeur URL) : netsh http show urlacl | more
Supprimez en collant le préfixe exact (note : les URLACL finissent souvent par « / ») : netsh http delete urlacl url=http://+:3387.rdp/ Si la commande renvoie « non trouvée », c’est que la chaîne ne correspond pas exactement (majuscules/minuscules ignorées, mais la présence du / final compte). Relistez et copiez-coller.
Vérifiez : netsh http show urlacl | findstr /I 3387

À savoir : lors d’une mise à jour ou du redémarrage d’un composant, Windows peut recréer l’entrée si elle est requise. C’est normal.

Désactiver totalement RDP si vous ne l’utilisez pas

Le meilleur durcissement consiste à ne pas exposer RDP du tout.

GUI : Paramètres → Système → Bureau à distance → désactivez Activer le Bureau à distance.
Pare-feu : désactivez/retirez les règles Bureau à distance (TCP/UDP 3389) et toute règle personnalisée (ex. 3387). Disable-NetFirewallRule -DisplayGroup "Bureau à distance"
Stratégie de groupe (éditions Pro/Enterprise) : Configuration ordinateur → Modèles d’administration → Composants Windows → Services Bureau à distance → Connexion → Refuser les connexions RDP.

Si vous gardez RDP : bonnes pratiques de sécurité

NLA obligatoire (Authentification au niveau réseau) et comptes protégés par MFA (via VPN/RD Gateway).
Limiter par réseau/IP : n’exposez jamais RDP à Internet. Autorisez uniquement des IP de confiance via le pare-feu/VPN.
Passphrases robustes et stratégies de verrouillage (anti‑bruteforce).
Journalisation et alertes (échecs d’authentification RDP, création de comptes, escalade de privilèges).
Éviter le « port‑knocking » marketing : changer 3389 → 3387 ne sécurise pas RDP, cela ne fait que réduire un peu le bruit des scans.
Mettre à jour Windows et activer Windows Defender avec protection contre les ransomwares.

Checklist d’audit rapide

Écoute réelle ? netstat -ano | find ":3387"
Propriétaire URLACL ? netsh http show urlacl → regardez Utilisateur
Règles pare-feu ? Get-NetFirewallRule filtré sur 3387
Port RDP ? reg query ... PortNumber → attend 3389
Besoin métier ? Service ou outil s’appuie‑t‑il vraiment sur cette réservation ?

FAQ

Est‑ce un malware ?
Non, pas en soi. C’est un enregistrement système normal (http.sys). Un logiciel malveillant pourrait créer des URLACL, mais la présence de cette seule entrée ne suffit pas à conclure. Vérifiez l’écoute et l’éditeur du processus si vous trouvez un PID.

Puis‑je simplement supprimer la réservation ?
Oui, si aucun service légitime ne l’utilise. Mais elle peut être recréée par Windows ou un module à la prochaine demande. Supprimez‑la pour assainir, pas comme « mesure de sécurité » principale.

Changer le port RDP améliore‑t‑il la sécurité ?
C’est au mieux une mesure d’obfuscation. La vraie sécurité passe par NLA, MFA, filtrage réseau, VPN/RD Gateway et une hygiène des comptes irréprochable.

Pourquoi .rdp dans la réservation ?
Pour réserver un préfixe lié à la distribution ou au traitement de connexions .rdp (RemoteApp, liens de connexion, gestionnaires). Cela ne signifie pas que des fichiers sont servis publiquement.

Où trouver l’événement ?
Dans l’Observateur d’événements, il est associé aux journaux Système ou Microsoft‑Windows‑HttpService/HttpLog/HttpEvent selon les versions et le contexte d’installation. Le texte « was successfully added » apparaît quand la réservation est enregistrée.

Procédures détaillées

1) Lister et interpréter les URLACL

netsh http show urlacl

Exemple d’extrait typique :

URL réservation     : http://+:3387.rdp/
    Utilisateur     : NT SERVICE\TermService
    Écouter         : Yes
    Délégation      : No
    SDDL            : D:(A;;GX;;;S-1-5-80-...)

URL réservation : doit correspondre exactement lors d’une suppression.
Utilisateur : l’identité (service ou compte) autorisée à utiliser ce préfixe.
SDDL : droits précis exprimés en langage de descripteur de sécurité.

2) Supprimer la réservation en toute sécurité

Désactivez temporairement le service qui l’utiliserait (si identifié).
Supprimez la réservation : netsh http delete urlacl url=http://+:3387.rdp/
Redémarrez le service uniquement si nécessaire.

3) Changer (ou rétablir) le port RDP si nécessaire

Attention : ne modifiez le port que si vous savez précisément pourquoi. Sinon, gardez 3389.

Consultez la valeur actuelle : reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber
Pour rétablir 3389 (exemple) : reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber /t REG_DWORD /d 3389 /f
Ouvrez/ajustez les règles pare‑feu si vous avez modifié le port.

Cas pratiques & diagnostics guidés

Cas A : vous ne voyez pas d’écoute sur 3387

C’est le cas le plus courant : la réservation est présente mais aucun service n’écoute. Vous pouvez la laisser telle quelle (inoffensive) ou la supprimer par hygiène. Rien d’autre n’est requis.

Cas B : un processus écoute activement sur 3387

Identifiez le processus (netstat → PID → tasklist/Get-Process).
Vérifiez l’éditeur et le chemin (Path du processus) pour confirmer qu’il s’agit bien d’un composant légitime (ex. TermService ou un outil d’assistance à distance approuvé).
Décidez :
- Autoriser et filtrer par pare‑feu si le service est nécessaire.
- Désactiver le service et supprimer la réservation si inutile.

Cas C : le port RDP a été changé (3387)

Si votre clé PortNumber indique 3387, votre système a été explicitement configuré. Rétablissez 3389 (ou le port choisi) et mettez à jour les règles pare‑feu/coffres‑forts de mots de passe. Évaluez qui a fait ce changement (audit de l’historique, GPO, script de post‑installation).

Synthèse

L’entrée « http://+:3387.rdp was successfully added » signale la création d’une réservation URL par la pile HTTP de Windows, sans ouvrir de port à elle seule. Dans la grande majorité des cas, elle est normale et sans danger, notamment après une réinstallation/activation de composants liés au Bureau à distance. Si vous n’utilisez pas RDP ou si vous visez une empreinte minimale, vous pouvez supprimer la réservation (et même désactiver RDP) après un court audit : vérifiez l’écoute, inspectez l’URLACL, contrôlez le pare‑feu et le registre. Conservez la réservation si un composant légitime en dépend, sachant que Windows peut la recréer automatiquement plus tard.

Annexe : bloc de commandes utiles (copier/coller)

:: 1) Voir si quelque chose écoute sur 3387
netstat -ano | find ":3387"

:: 2) Identifier le processus par PID
tasklist /FI "PID eq "

:: 3) Inventaire des réservations URL
netsh http show urlacl

:: 4) Trouver rapidement les réservations impliquant 3387
netsh http show urlacl | findstr /I 3387

:: 5) Supprimer la réservation (adapter l’URL EXACTE)
netsh http delete urlacl url=http://+:3387.rdp/

:: 6) État détaillé http.sys (préfixes, propriétaires)
netsh http show servicestate view=requestq=detail

:: 7) Port RDP configuré (attendu: 3389)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber

:: 8) Règles pare-feu liées
powershell -c "Get-NetFirewallRule -Enabled True | Where-Object {$_.DisplayName -match 'Remote|Bureau|3387'} | Get-NetFirewallPortFilter"

:: 9) Désactiver rapidement le groupe de règles RDP (si non utilisé)
powershell -c "Disable-NetFirewallRule -DisplayGroup 'Bureau à distance'"

Annexe : modèle d’analyse d’impact

Action envisagée	Impact potentiel	Mesure d’atténuation
Supprimer l’URLACL 3387	Un service qui la réclame à l’exécution peut échouer puis la recréer au prochain démarrage.	Documenter la suppression, surveiller les journaux, rétablir si nécessaire.
Désactiver RDP	Perte d’accès à distance direct.	Mettre en place VPN + RD Gateway ou alternatives (Remote Help, outils IT approuvés).
Changer le port RDP	Clients et règles pare‑feu deviennent obsolètes.	Mettre à jour scripts, GPO, documentation et ACLs.

Conclusion

Considérez ce message comme un indicateur d’initialisation, pas comme une alarme. Faites un contrôle d’écoute, identifiez l’éventuel propriétaire de l’URLACL et appliquez vos politiques : laisser tel quel, supprimer la réservation, ou désactiver RDP si inutile. La sécurité effective se joue surtout dans le pare‑feu, la réduction de surface d’attaque et l’authentification forte.