Comment vérifier si votre serveur domestique est exposé à Internet ?

Un serveur domestique est exposé à internet lorsqu’un appareil extérieur peut atteindre un de ses services via votre connexion réseau publique. Cette exposition peut être intentionnelle, comme un site web public ou un serveur de jeu, ou accidentelle, comme une ancienne règle de redirection de port qui pointe encore vers un panneau d’administration.

Un port ouvert ne signifie pas automatiquement que votre serveur a été piraté. Cela signifie qu’un service est accessible et doit être identifié. La vérification pratique consiste à voir votre réseau depuis l’extérieur, puis à retracer chaque port accessible à travers le routeur, le pare-feu, le système d’exploitation et les conteneurs jusqu’à ce que vous sachiez exactement quel service répond.

Ce que signifie réellement « Exposé à Internet »

Supposons que votre serveur média, application de fichiers, service SSH ou tableau de bord se charge pendant que votre téléphone utilise les données mobiles. Cela ne signifie pas nécessairement que tout le serveur domestique est public. Cela signifie généralement qu’une IP publique et un port spécifiques peuvent atteindre un service fonctionnant sur cette machine.

Le risque dépend de ce qui est exposé. Un site HTTPS maintenu sur le port 443 est différent d’une page d’administration NAS, d’une base de données, d’une API Docker ou d’un service SSH avec mot de passe. L’exposition décrit la possibilité d’accès ; elle ne décrit pas si le service est sécurisé, vulnérable ou déjà compromis.

L’objectif n’est donc pas de fermer tous les ports sans les comprendre. L’objectif est de maintenir une liste courte de services publics intentionnels et d’enquêter sur tout ce qui n’appartient pas à cette liste.

Effectuez le premier test depuis l’extérieur de votre réseau domestique

Un test effectué depuis votre Wi-Fi domestique peut ne pas montrer ce qu’un utilisateur extérieur voit. Votre routeur peut supporter le NAT loopback, votre domaine peut résoudre une adresse privée via un DNS local, ou l’application peut silencieusement basculer vers une connexion LAN.

Désactivez le Wi-Fi sur votre téléphone et utilisez les données mobiles. Essayez le domaine public, l'IP publique ou l'adresse du service que vous pensez exposé. Vous pouvez aussi tester depuis un réseau de bureau, un autre foyer ou un système cloud que vous contrôlez. Testez uniquement les systèmes et adresses que vous possédez ou êtes autorisé à examiner.

Si le service se charge depuis un véritable réseau externe, il est accessible depuis internet par un certain chemin. S'il échoue, cela ne prouve pas encore que tout est fermé ; le service peut utiliser un port différent, une adresse IPv6, un VPN, un relais ou un tunnel.

Identifiez l'adresse publique que vous testez

Votre serveur domestique peut avoir une adresse telle que 192.168.1.50, tandis que votre routeur a une adresse WAN et que votre connexion internet apparaît sous une autre IP publique. Ces adresses ont des fonctions différentes.

L’adresse privée du serveur est utilisée à l’intérieur du LAN. Un vérificateur de port externe teste normalement l’adresse IPv4 publique ou le nom d’hôte public que le trafic extérieur atteint. Si l’adresse WAN du routeur ne correspond pas à l’adresse publique affichée par un service IP externe, votre ISP peut placer la connexion derrière un NAT de niveau opérateur (carrier-grade NAT).

Notez l’IP LAN du serveur, l’IP WAN du routeur, l’adresse IPv4 publique, l’adresse IPv6 publique si présente, et tous les noms de domaine que vous utilisez. Cela facilite grandement la liaison d’un résultat de scan externe à la bonne règle du routeur et à l’appareil interne.

Utilisez un test de port externe pour trouver les services accessibles

Un vérificateur de port externe tente de se connecter à un port spécifique depuis l’extérieur de votre LAN. Commencez par les ports que vous savez associés à vos services, plutôt que de scanner des milliers de ports sans plan.

Vous pouvez tester un port externe spécifique sur votre adresse publique. Cela peut confirmer si une règle de redirection de port fonctionne ou si un pare-feu bloque la connexion. Le service doit normalement être actif pendant le test ; une application inactive peut faire apparaître une règle de redirection valide comme fermée.

Les ports courants incluent 22 pour SSH, 80 pour HTTP, 443 pour HTTPS, 445 pour SMB, 3389 pour Bureau à distance, et des ports spécifiques aux applications pour les services médias, jeux ou auto-hébergés. Ne supposez pas qu’un port personnalisé à numéro élevé est sûr simplement parce qu’il est moins connu.

Passez en revue chaque règle de redirection de port sur votre routeur

La redirection de port est l’un des moyens les plus directs pour qu’un service domestique devienne public. Une règle indique au routeur d’accepter le trafic sur un port externe et de l’envoyer à une adresse IP interne et un port spécifiques.

Vérifiez les sections du routeur intitulées Redirection de port, Serveur virtuel, Règles NAT, Applications ou Jeux. Pour chaque règle, notez le port externe, le protocole, l'adresse IP de destination, le port interne et le service prévu. Le comportement important est le mappage des ports publics vers privés qui donne à une connexion externe un chemin vers un appareil interne.

Supprimez les règles qui n'ont plus de raison d'être claire. Portez une attention particulière aux règles de transfert visant l'administration du routeur, l'administration NAS, SSH, Bureau à distance, bases de données, interfaces de caméra ou anciennes applications auto-hébergées qui ne sont plus maintenues.

Vérifiez si UPnP a ouvert des ports automatiquement

Vous pouvez trouver un port ouvert même si vous n'avez jamais créé de règle de transfert manuellement. Les serveurs multimédias, consoles de jeux, applications peer-to-peer, caméras et autres logiciels peuvent parfois demander au routeur de créer un mappage automatiquement.

Ce comportement est généralement assuré via Universal Plug and Play. Les applications peuvent créer des mappages automatiques de ports du routeur via UPnP, ce qui est pratique mais rend l'exposition plus difficile à auditer lorsque les utilisateurs ne savent pas quelle application a demandé chaque règle.

Recherchez un statut UPnP ou une table de mappage de ports dans l'interface du routeur. Supprimez les mappages inexpliqués et désactivez UPnP si votre foyer n'en a pas besoin. Si vous le laissez activé pour une application particulière, vérifiez périodiquement ses mappages au lieu de supposer qu'ils disparaissent lorsque l'application est fermée.

Assurez-vous que le serveur n'est pas défini comme hôte DMZ

Certains routeurs domestiques incluent un paramètre appelé Hôte DMZ, Hôte exposé ou Serveur par défaut. Malgré son nom, ce n'est pas la même chose qu'un réseau DMZ d'entreprise soigneusement isolé.

Sur de nombreux routeurs grand public, ce paramètre envoie le trafic entrant non sollicité qui ne correspond à aucune autre règle vers un appareil interne sélectionné. Si le serveur domestique est sélectionné, beaucoup plus de ports peuvent être accessibles que prévu par l'utilisateur.

Sauf raison spécifique et bien comprise, le serveur ne doit pas être configuré comme hôte DMZ. Désactivez ce paramètre et créez des règles strictes uniquement pour les services individuels qui ont réellement besoin d'un accès public.

Vérifiez quels services écoutent sur le serveur

Un scan externe vous indique qu'un port répond, mais ne vous dit pas toujours quel processus local le possède. L'étape suivante est d'examiner le serveur lui-même.

Sous Linux, des commandes telles que ss -lntup peut afficher les sockets TCP et UDP à l'écoute ainsi que leurs processus associés. Sous Windows, netstat -ano et le Moniteur de ressources peuvent aider à relier un port à l'écoute à un ID de processus. Vérifiez si chaque service écoute sur 127.0.0.1, une adresse LAN spécifique, 0.0.0.0, ou une adresse IPv6.

Un service lié à 127.0.0.1 est normalement local à la machine. Un service lié à 0.0.0.0 ou :: écoute sur plusieurs interfaces et peut devenir accessible publiquement lorsque le routeur et le pare-feu le permettent. Une liaison large n'est pas automatiquement dangereuse, mais elle augmente l'importance des règles de pare-feu.

N'oubliez pas le pare-feu du serveur

Le routeur n'est qu'une couche de sécurité. Les règles de pare-feu Linux, le pare-feu Windows, un pare-feu d'hyperviseur ou les contrôles d'accès au niveau des applications peuvent autoriser ou bloquer la connexion finale.

Examinez les règles entrantes et déterminez si elles s’appliquent uniquement au LAN, à toutes les interfaces, à des adresses sources spécifiques, ou aux deux IPv4 et IPv6. Un installateur d’application peut avoir créé automatiquement une règle d’autorisation, et une ancienne règle peut subsister après la suppression de l’application.

Une bonne pratique par défaut est de refuser le trafic entrant non sollicité et d’ajouter des exceptions strictes uniquement là où c’est nécessaire. Restreignez les services administratifs à un sous-réseau VPN ou à des adresses sources de confiance autant que possible.

La publication de ports Docker peut exposer plus que prévu

Les conteneurs créent une autre couche entre le port externe et l’application. Une entrée Compose telle que 8080:80 publie le port 80 du conteneur via le port 8080 de l’hôte.

Lorsqu’un port hôte publié est accessible via le pare-feu et le routeur, le conteneur peut devenir accessible depuis Internet. Passez en revue docker ps, fichiers Compose, réseau hôte, configuration de reverse-proxy, et tout conteneur qui monte le socket Docker ou s’exécute avec des privilèges élevés.

Ne publiez que les ports qui doivent être accessibles en dehors du réseau de conteneurs. Les bases de données internes, caches, tableaux de bord et API service-à-service doivent généralement rester sur des réseaux Docker privés plutôt que d’être publiés sur toutes les interfaces hôtes.

Vérifiez IPv6 séparément d’IPv4

Un serveur peut être inaccessible via IPv4 public et toujours accessible via IPv6. IPv6 ne dépend normalement pas du même modèle de redirection de port NAT utilisé par les connexions IPv4 domestiques.

Si votre FAI délègue des adresses IPv6 publiques aux appareils domestiques, le pare-feu du routeur devient la principale frontière. Un service à l’écoute sur :: peut avoir une adresse publique même lorsque le vérificateur de port IPv4 indique que le port correspondant est fermé.

Vérifiez les adresses IPv6 globales du serveur, les règles de pare-feu IPv6 du routeur, les enregistrements DNS publics AAAA et la liaison des services. Testez IPv4 et IPv6 indépendamment afin qu’un résultat IPv4 fermé ne crée pas une fausse confiance.

Utilisez Shodan comme vérification de visibilité historique

Un scan de port en direct montre ce qui répond actuellement. Vous pouvez également vouloir savoir si un scanner internet a déjà indexé des services à votre adresse publique.

Vous pouvez consulter les services indexés publiquement associés à une adresse IP. Les résultats peuvent inclure des ports, des bannières de service, des certificats, des noms de logiciels ou d’autres informations observées lors d’un scan précédent.

Considérez cela comme une vérification secondaire. Les données peuvent être anciennes, une IP dynamique peut avoir appartenu auparavant à un autre client, et un port nouvellement ouvert peut ne pas apparaître immédiatement. L’absence de résultat Shodan ne prouve pas que le serveur est invisible ou sécurisé.

Comparez chaque port ouvert avec une liste de services intentionnels

Une fois que vous disposez des résultats externes, des règles du routeur, des services à l'écoute et des mappages de conteneurs, créez une liste qui explique chaque port accessible. C’est l’étape qui transforme des vérifications dispersées en un audit d’exposition.

Classez chaque service comme public par conception, accès distant privé, uniquement LAN ou inconnu. Un site web public peut appartenir à la première catégorie. Un partage de fichiers, un panneau d'administration NAS ou un service SSH peuvent être placés derrière un VPN. Les bases de données et les interfaces de gestion Docker devraient généralement rester uniquement sur le LAN.

Tout ce qui est marqué inconnu doit être désactivé ou bloqué jusqu'à identification. Il est plus sûr d'interrompre temporairement un service inexpliqué que de laisser un point d'entrée public non identifié actif.

Que faire si vous trouvez un port ouvert inattendu

Si un scan externe détecte un service SSH, une interface d'administration, une base de données, une page de caméra, une API Docker ou un autre service que vous n'aviez pas l'intention de publier, réduisez l'exposition avant de poursuivre l'enquête.

Désactivez le transfert de port ou le mappage UPnP, retirez l'appareil de toute configuration DMZ, arrêtez le service inutile et ajoutez une règle de pare-feu qui bloque le chemin. Ensuite, mettez à jour le système d'exploitation et l'application, examinez les journaux d'accès récents et changez les identifiants ou clés API qui pourraient avoir été exposés.

Un port ouvert seul n'est pas une preuve de compromission. Cependant, des connexions inconnues, des fichiers modifiés, des comptes inconnus, des processus inexpliqués, de nouvelles tâches planifiées ou un trafic sortant suspect méritent un examen approfondi de l'incident plutôt qu'un simple changement de pare-feu.

Choisissez une méthode d'accès adaptée au service

Tous les services distants ne doivent pas être publics. L'accès personnel aux fichiers, les tableaux de bord, l'administration du serveur, SSH, l'automatisation domestique et les bibliothèques multimédias privées sont généralement destinés à un petit groupe d'utilisateurs de confiance.

Les façons courantes dont les services auto-hébergés deviennent accessibles depuis l'extérieur du LAN incluent le transfert de port direct, l'accès VPN privé, les VPN maillés, les proxies inverses et les tunnels. Ces méthodes créent différentes limites d'exposition et de confiance.

Gardez les sites web publics publics lorsque c'est leur but, mais placez les services administratifs et personnels derrière un VPN, un VPN maillé, une passerelle d'accès authentifiée ou un tunnel configuré de manière étroite. Réduire le nombre d'applications directement accessibles facilite la compréhension et la maintenance du serveur.

Répétez la vérification après chaque changement réseau ou applicatif

L'exposition n'est pas un réglage ponctuel. Un remplacement de routeur, une mise à jour Docker Compose, un nouveau serveur de jeu, une application d'accès à distance, une réinitialisation du pare-feu, un changement IPv6 chez le FAI ou la réactivation d'UPnP peuvent modifier ce que l'internet voit.

Répétez le test externe chaque fois que vous ajoutez un service, modifiez des règles de routeur, remplacez du matériel réseau, activez IPv6 ou reconstruisez une pile de conteneurs. Gardez un court historique des ports publics approuvés pour comparer les nouveaux résultats à une base connue.

Pour un environnement domestique typique, une revue mensuelle ou trimestrielle suffit sauf si le serveur change fréquemment. L'habitude importante est de vérifier après des modifications de configuration au lieu de supposer que l'audit précédent est toujours valable.

Conclusion

La manière la plus fiable de vérifier si votre serveur domestique est exposé est de l'examiner depuis l'extérieur du réseau domestique. Testez vos chemins IPv4 et IPv6 publics, vérifiez des ports spécifiques, puis reliez chaque résultat à une règle de routeur, une exception de pare-feu, un processus à l'écoute ou un mappage de conteneur.

Un port ouvert signifie qu'un service est accessible, pas automatiquement compromis. Le risque vient d'un service inexpliqué ou mal sécurisé. Ne gardez exposés que les services publics intentionnels, supprimez les redirections et mappages UPnP oubliés, et utilisez un accès distant privé pour l'administration, les services de fichiers et les applications personnelles.

FAQ

Un port ouvert signifie-t-il que mon serveur domestique a été piraté ?

Non. Un port ouvert signifie qu'une connexion extérieure peut atteindre un service à l'écoute. Vous devez toujours identifier ce service, vérifier son authentification et son état de mise à jour, et consulter les journaux pour détecter toute activité non autorisée.

Mon serveur peut-il être exposé via IPv6 sans transfert de port ?

Oui. Les appareils IPv6 peuvent recevoir des adresses routables publiquement, donc la possibilité d'accès dépend largement des pare-feux du routeur et du serveur plutôt que du transfert NAT de type IPv4. Testez IPv6 séparément.

Dois-je désactiver UPnP sur mon routeur ?

Désactivez-le lorsque vous n'avez pas besoin que les applications créent automatiquement des mappages de ports. Si vous le laissez activé pour des applications de jeu ou multimédia, vérifiez régulièrement les mappages actifs et supprimez tout ce qui est inexpliqué.

Une recherche Shodan suffit-elle à prouver que mon serveur est sécurisé ?

Non. Les données de Shodan peuvent être retardées ou obsolètes, et l'absence de résultats ne prouve pas qu'aucun service n'est accessible. Utilisez un test de port externe actuel et inspectez directement la configuration du routeur et du serveur.

Quels services de serveur domestique ne devraient pas être directement publics ?

Les pages d'administration NAS et routeur, les bases de données, les API Docker, les consoles d'hyperviseur, les partages SMB et les tableaux de bord personnels doivent généralement rester privés. Accédez-y via un VPN, un VPN maillé ou un autre chemin privé authentifié.