Référence des ports
Port 5000 (TCP) – UPnP / serveur de développement courant
Un port très surchargé utilisé par les points de contrôle UPnP, le serveur de dev Flask, le registre Docker et AirPlay de macOS (Centre de contrôle).
État par défaut
Variable selon le service. Le serveur de dev Flask et le registre Docker s'y lient à l'exécution ; sur macOS, le récepteur AirPlay écoute sur le 5000. Souvent ouvert involontairement pendant le développement.
Attaques courantes
- Atteindre un débogueur Flask/Werkzeug exposé pour une exécution de code à distance
- Pousser ou tirer des images depuis un registre Docker non authentifié
- Abus d'UPnP pour mapper des ports ou atteindre des services internes (pivots de type SSRF)
- Divulgation d'informations via les pages de debug et les erreurs verboses de l'application
Durcissement
- Ne jamais exécuter un serveur de développement (debug Flask/Werkzeug) en production
- Lier les services de dev et de registre à localhost, pas à 0.0.0.0
- Exiger authentification et TLS sur tout registre Docker exposé
- Désactiver l'UPnP sur les passerelles exposées à Internet et segmenter les appareils IoT
- Filtrer le 5000 et placer les applications de production derrière un reverse proxy durci
Commande nmap
nmap -p5000 --script http-title <target>Remplacez <target> par l’hôte ou la plage que vous êtes autorisé à scanner.
Ce qui s'exécute sur le port 5000
Le port 5000 est très surchargé. C'est un défaut pour les points de contrôle UPnP, le serveur de développement Flask/Werkzeug, le registre Docker et — sur macOS moderne — le récepteur AirPlay (Centre de contrôle). Ce qui écoute réellement dépend entièrement de l'hôte, ce qui est précisément la raison pour laquelle il vaut la peine d'être sondé.
Pourquoi c'est important pour la sécurité
Plusieurs de ces défauts sont dangereux une fois exposés. Une application Flask avec le débogueur activé offre une console interactive — une exécution de code à distance — et les serveurs de dev divulguent des traces de pile. Un registre Docker non authentifié laisse les attaquants tirer des images privées ou en pousser des falsifiées. L'UPnP peut être détourné pour mapper des ports ou atteindre des services internes.
Comment c'est attaqué
Les attaquants prennent l'empreinte du 5000 avec http-title et des
vérifications de bannière pour distinguer un débogueur Flask d'un registre ou
d'AirPlay. Contre une console de debug, ils déclenchent une erreur et exécutent du
Python arbitraire. Contre un registre ouvert, ils énumèrent et tirent/poussent
des images. Un UPnP exposé est détourné pour du mappage de ports et des
pivots de type SSRF vers le réseau interne.
Liste de durcissement
N'exécutez jamais un serveur de développement en production et gardez le
débogueur Werkzeug désactivé. Liez les services de dev et de registre à
localhost, pas à 0.0.0.0, et exigez authentification et TLS sur tout
registre Docker exposé. Désactivez l'UPnP sur les passerelles exposées à
Internet et segmentez les appareils IoT. Filtrez le 5000 et placez les
applications de production derrière un reverse proxy durci. Utilisez la
commande nmap ci-dessus pour vérifier l'exposition sur les hôtes que vous êtes
autorisé à tester.
Ports liés
Questions fréquentes
- Pourquoi le port 5000 est-il associé à autant de services ?
- C'est un défaut populaire. Le contrôle UPnP, le serveur de dev Flask/Werkzeug, le registre Docker et le récepteur AirPlay de macOS utilisent tous le 5000, donc ce que l'on y trouve dépend entièrement de l'hôte.
- Quel est le danger d'une application Flask exposée sur le 5000 ?
- Si le débogueur Werkzeug est activé, un attaquant peut ouvrir une console interactive et exécuter du Python arbitraire — une RCE complète. Les serveurs de développement divulguent aussi des traces de pile et ne sont pas conçus pour résister à un trafic hostile.