Identification de services et ports ouverts

Pourquoi cette note existe

Cette note explique ce que les étrangers peuvent apprendre des ports ouverts sur une adresse IP publique.

La question initiale était simple:

If my public IP shows ports 22, 80, and 443 open, what can people figure out?

La réponse est plus nuancée que , ils peuvent pirater vous , ou , c'est bien.

Les ports ouverts ne sont pas automatiquement une vulnérabilité, mais ils sont des informations. Ils disent aux gens que quelque chose est à l'écoute, et parfois ils révèlent quel logiciel, version, système d'exploitation, pile web, certificat, nom d'hôte, ou surface d'authentification est exposée.

La présente note traite de la compréhension de l'exposition et de la réduction des risques inutiles.

Ce que signifie un port ouvert

Un port ouvert signifie qu'un service a répondu aux tentatives de connexion.

Exemple :

22/tcp open
80/tcp open
443/tcp open

Cela suggère généralement:

22  → SSH
80  → HTTP
443 → HTTPS

Mais le seul numéro de port n'est qu'un indice.

Un service peut fonctionner sur un port non standard, et un port peut être filtré, proxié, redirigé ou géré par un pare-feu. La vraie question est ce que le service répond et ce qu'il révèle.

Numérisation de ports vs impression de doigts de service

Réponses à la numérisation des ports :

Which ports are open?

Les empreintes digitales du service demandent :

What exactly is running on those ports?

Un scan de base peut montrer:

22/tcp open ssh
80/tcp open http
443/tcp open https

Une empreinte digitale plus profonde peut révéler:

OpenSSH version
nginx or Apache
TLS certificate names
HTTP response headers
server banners
supported protocols
redirect behavior
default pages
framework hints

C'est pourquoi les empreintes digitales sont plus importantes que la seule liste des ports.

Que peut montrer Nmap

Un simple scan Nmap peut afficher des ports ouverts.

Une analyse de version peut essayer d'identifier les services:

nmap -sV <target>

Un scan de script peut recueillir plus de détails:

nmap -sC -sV <target>

Une analyse de détection OS peut essayer de deviner le système d'exploitation:

nmap -O <target>

Un scan plus agressif combine plusieurs vérifications :

nmap -A <target>

Ces scans ne pénètrent pas par magie dans le serveur. Ils recueillent des informations visibles de services qui répondent déjà.

Ce que le port 22 révèle

Port 22 signifie généralement SSH.

Un service SSH peut révéler:

que SSH est disponible publiquement
la mise en œuvre de SSH
parfois la version OpenSSH
méthodes d'authentification supportées
algorithmes d'échange de clés pris en charge
si le mot de passe apparaît possible
si la connexion racine peut être tentée
informations sur la bannière du serveur

Habituellement, not révèle directement le nom d'utilisateur correct.

Les attaquants peuvent encore essayer des noms d'utilisateur communs:

root
admin
ubuntu
debian
oracle
opc
user
test

Ils n'ont pas besoin de connaître le véritable nom d'utilisateur pour commencer à deviner.

Exposition du nom d'utilisateur SSH

Un scan SSH normal ne dit pas simplement à quelqu'un:

the valid username is this

Cependant, les noms d'utilisateur peuvent fuir indirectement par:

public Git engage
applications web exposées
messages d'erreur
Noms d'utilisateur du cloud par défaut
Documentation
noms d'hôte réutilisés
anciens fichiers de configuration
chemins de dépôt publics
bannières de connexion
génie social

Donc le port lui-même ne révèle pas le nom d'utilisateur, mais le système plus large peut.

L'hypothèse la plus sûre est:

If SSH is public, someone will try common usernames automatically.

Bases de durcissement SSH

Bon durcissement de base SSH:

utiliser une connexion par clé
désactiver l'authentification du mot de passe si possible
désactiver la connexion root là où c'est pratique
tenir OpenSSH à jour
restreindre SSH au VPN ou aux IP de confiance si possible
utiliser les règles du pare-feu
contrôle des tentatives de connexion
éviter la fuite de noms d'utilisateur dans les bannières ou les documents
utiliser fail2ban ou l'équivalent le cas échéant
ne pas exposer SSH publiquement sauf si nécessaire

Le passage de SSH à un port non standard peut réduire le bruit aléatoire, mais ce n'est pas en soi une sécurité réelle.

La solution la plus forte est :

SSH reachable only over VPN

ou:

SSH reachable only from trusted source IPs

Ce que le port 80 révèle

Port 80 signifie généralement HTTP.

HTTP peut révéler beaucoup parce que le serveur envoie des réponses lisibles.

Informations exposées possibles:

type de serveur web
pages par défaut
rediriger le comportement
application cadre
En-têtes HTTP
chemins de fichiers
Panneaux d'administration
répertoires exposés
robots.txt contenu
pages d'erreur
comportement de l'hôte virtuel
vieilles pages de test

Une page par défaut peut révéler la pile même si aucun site réel n'est déployé.

Exemples:

Welcome to nginx
Apache default page
OpenWrt LuCI login
Router admin page
Node/Express error page

Le plus grand risque est d'exposer accidentellement une interface administrative ou un service inachevé.

Ce que le port 443 révèle

Port 443 signifie généralement HTTPS.

HTTPS chiffre le trafic, mais il révèle encore les métadonnées.

Informations exposées possibles:

Noms de domaine des certificats TLS
émetteur de certificat
date de validité du certificat
versions TLS prises en charge
suites de chiffrement supportées
comportement du serveur web après la poignée de main TLS
En-têtes HTTP après connexion
détails de proxy inversés
configuration de l'hôte virtuel

Un certificat peut révéler des noms d'hôte même si le contenu de la page est protégé.

Par exemple, un certificat peut contenir :

example.com
api.example.com
admin.example.com

Cela peut donner des noms de cibles utiles aux attaquants.

En-têtes HTTP

Les en-têtes HTTP peuvent fuiter les détails d'implémentation.

Exemples:

Server: nginx
Server: Apache
X-Powered-By: Express
X-Powered-By: PHP/8.x
Via: reverse-proxy

Enlever ou réduire ces en-têtes peut aider, mais il ne doit pas être traité comme la défense principale.

Un en-tête caché ne garantit pas un service vulnérable.

L'ordre de priorité est :

patch services
restrict access
remove exposed admin panels
use authentication
then reduce banners/headers

Renseignements sur le certificat TLS

Les certificats TLS sont publics par conception.

Quiconque se connecte à un service HTTPS peut inspecter le certificat.

Il peut révéler:

nom de domaine
sous-domaines
organisation si inclus
émetteur
date d'expiration
chaîne de certification
parfois des erreurs de nommage interne

Les certificats ne sont pas secrets.

Si un nom d'hôte ne doit pas être public, ne le placez pas dans un certificat public.

Empreintes digitales Web

Les services Web peuvent être dactylographiés par :

entêtes
cookies
Structure HTML
Fichiers JavaScript
Voies CSS
haches de favicon
pages d'erreur par défaut
texte de la page de connexion
Réponses de l'API
Noms d'actifs statiques
fichiers spécifiques au cadre

Même si les en-têtes sont supprimés, l'application peut toujours se révéler par le biais du comportement et de la structure du fichier.

Exemple :

/wp-login.php → WordPress
/luci/       → OpenWrt LuCI direction
/api/docs    → API documentation

Ne comptez pas seulement sur des bannières cachées.

Exposition du routeur et du panneau d'administration

L'exposition la plus dangereuse n'est souvent pas un site Web normal.

C'est un panneau d'administration exposé par erreur.

Exemples:

page de connexion du routeur
LuCI ouvert
Panneau Proxmox
panneau d'administration de base de données
UI de Docker
Portainer
caméra DVR interface
panneau d'administration du serveur de jeu
tableau de bord du développement

Ils ne devraient généralement pas être publics.

Meilleur chemin d'accès :

Internet
  ↓
VPN
  ↓
private admin panel

Les panneaux publics d'administration créent des risques inutiles même lorsque le mot de passe est protégé.

Ce que les attaquants peuvent déduire

À partir des ports ouverts et des empreintes digitales, quelqu'un peut déduire :

quels services sont exposés
si le serveur est probablement Linux
si SSH est disponible
si un serveur web est nginx/Apache/Caddy/etc.
si un proxy inversé est présent
si HTTPS est configuré
noms d'hôte possibles à partir de certificats
si les pages par défaut existent
si les panels administratifs sont publics
si le logiciel semble dépassé
si des vulnérabilités communes peuvent s'appliquer

Cela ne signifie pas que le compromis est automatique.

Cela signifie que les services exposés définissent la surface d'attaque.

Ce que les attaquants ne peuvent habituellement pas déduire directement

Un scan ne peut généralement pas révéler directement:

clés SSH privées valides
mots de passe valides
disposition exacte du réseau interne
contenu de la base de données
corriger le nom d'utilisateur SSH avec certitude
services privés derrière un pare-feu
Dispositifs LAN seulement
Services VPN seulement

Mais si les services publics fuient la configuration, les journaux, les sauvegardes ou les pages d'administration, cela change rapidement.

L'objectif est d'éviter de donner à Internet des points de départ inutiles.

Ouvrir les ports sous CGNAT

Lors de la numérisation d'une IP publique sous CGNAT, les résultats peuvent être confus.

L'IP public ne peut pas appartenir seulement à un routeur client.

Un résultat Nmap montre :

what is reachable on that public IP

Elle ne prouve pas toujours:

this service is running on my local router

Pour vérifier la propriété, vérifiez :

routeur WAN IP
IP publique de l'extérieur
journaux de service pendant l'analyse
règles de port avant
si le service cible reçoit la connexion
test externe à partir de données mobiles ou VPS

Cela est important parce que les couches CGNAT et ISP peuvent rendre les tests publics-IP plus difficiles à interpréter.

Liste de contrôle publique de la numérisation IP

Pour vérifier votre propre IP publique, utilisez un processus :

1. Identifier la PI publique

curl -s ifconfig.me

2. Scanner depuis l'extérieur

Utilisez un réseau externe ou un VPS.

nmap -sV <public-ip>

3. Comparer l'IP du routeur WAN

Vérifiez si le routeur WAN IP correspond à l'IP public.

Dans le cas contraire, le CGNAT ou le NAT en amont peuvent être impliqués.

4. Vérifier les journaux de service

Lors d'un test de numérisation ou de connexion, vérifiez si votre serveur enregistre la tentative.

Si aucun journal n'apparaît, le trafic peut ne pas atteindre votre appareil.

5. Confirmer la propriété du port

Pour chaque port ouvert, confirmez quel service local le possède.

Sur les systèmes Linux/OpenWrt :

netstat -tulpn

ou:

ss -tulpn

L'écoute locale vs l'exposition publique

Un service peut être écouté localement sans être public.

Exemples:

127.0.0.1:3000
192.168.1.10:8080
0.0.0.0:22

Signification:

127.0.0.1 → local machine only
LAN IP    → local network interface
0.0.0.0   → all interfaces on that device

Un port d'écoute local ne devient public que si le pare-feu/NAT/routage l'expose.

Toujours séparer :

service is running

par:

service is reachable from the internet

Réduire la surface de l'attaque

La meilleure façon de réduire les risques est d'exposer moins de services.

Meilleure exposition du public:

80/443 → reverse proxy / website only
SSH    → VPN-only or trusted IP only
admin  → VPN-only
database → never public

Une installation publique propre expose généralement:

HTTP/HTTPS pour les sites publics prévus
peut-être des ports de serveur de jeu si nécessaire
rien d'autre sauf justifié

Tout administratif doit être privé ou protégé par VPN dans la mesure du possible.

Direction du mandataire inverse

Un proxy inverse peut aider à organiser l'exposition web.

Il peut parcourir:

site.example.com → public site
api.example.com  → backend API

Mais il ne devrait pas exposer aveuglément:

admin.example.com
proxmox.example.com
router.example.com
db.example.com

à moins que ceux-ci ne soient fortement protégés et intentionnellement publics.

Un modèle plus sûr:

public websites → reverse proxy
admin tools     → VPN
databases       → private only

Étapes pratiques de durcissement

Pour SSH

désactiver le mot de passe
utiliser les clés
désactiver la connexion racine si possible
Limiter par le pare-feu
préfèrent VPN seulement
contrôle des tentatives ratées

Pour HTTP/HTTPS

supprimer les pages par défaut
serveur web patch
masquer les en-têtes inutiles
désactiver la liste des répertoires
utiliser des TLS appropriés
ne pas exposer les panneaux d'administration
utiliser l'authentification au besoin

Pour les services Routeur/Administration

garder le routeur administrateur LAN/VPN seulement
n'exposez pas LuCI / UI administrateur public
vérifier le port vers l'avant
vérifier les règles UPnP si activé
services d'audit

Pour les bases de données

ne pas exposer publiquement
lier à IP privé ou localhost si possible
nécessitent une authentification forte
Limiter par le pare-feu
accès via un serveur app ou un VPN uniquement

Risque d'UPnP

UPnP peut automatiquement créer des renvois de port.

Cela peut être pratique, mais il peut aussi exposer les services de manière inattendue.

Si l'exposition du public est importante, vérifiez :

si UPnP est activé
les dispositifs demandés pour l'avant
quels ports ont été ouverts
si ces avancées sont encore nécessaires

Sur un réseau contrôlé, désactiver UPnP ou le limiter peut réduire les surprises.

Incompréhension commune

Seul le port 22 est ouvert, donc je suis en sécurité.

SSH est une surface d'accès sérieuse.

Changing SSH port le rend sécurisé.

Il réduit les scans aléatoires mais ne remplace pas l'authentification forte.

"HTTPS" signifie que rien n'est visible.

HTTPS chiffre le contenu mais expose toujours les métadonnées de certificat et de service.

Nmap trouvé nginx, donc je suis piraté.

L'empreinte digitale n'est pas un compromis.

Aucun site Web n'est déployé, donc le port 80 est inoffensif.

Les pages par défaut et les panneaux d'administration peuvent encore révéler des informations utiles.

Un scan révèle mon nom d'utilisateur SSH.

Habituellement pas directement, mais les noms d'utilisateur peuvent être devinés ou divulgués ailleurs.

Liste de vérification

Identifier les ports ouverts

nmap <public-ip>

Identifier les services

nmap -sV <public-ip>

Vérifier les scripts par défaut

nmap -sC -sV <public-ip>

Vérifiez les auditeurs locaux

ss -tulpn

ou:

netstat -tulpn

Vérifier les en-têtes HTTP

curl -I http://<public-ip>

curl -I https://<domain>

Vérifier le certificat

Utilisez le moniteur de certificat de navigateur ou l'inspection TLS en ligne de commande.

Cochez Routeur vers l'avant

Révision:

port forwards
firewall rules
UPnP leases
reverse proxy configs
running services

Décisions pratiques

Les services publics devraient être intentionnels

Chaque port ouvert devrait avoir une raison.

SSH doit généralement être privé

SSH VPN est plus propre que SSH public pour l'infrastructure personnelle.

Les panneaux administratifs ne devraient pas être publics

Protégez le routeur, Proxmox, la base de données et les tableaux de bord de service derrière VPN.

Une empreinte digitale est attendue

Supposons que les gens peuvent identifier les services exposés. La sécurité ne devrait pas dépendre de tout cacher.

En-têtes sont secondaires

La suppression des en-têtes est utile, mais le patching et le contrôle d'accès sont plus importants.

Les journaux comptent

Si un scan atteint votre service, les journaux devraient aider à le confirmer.

Ce qu'une note finie devrait montrer

Une note bien terminée doit montrer :

exemple de balayage de port
exemple d'empreintes digitales de service
explication de l'exposition aux SSH
explication des métadonnées HTTP/HTTPS
quels noms d'utilisateur peuvent et ne peuvent pas être découverts
Mise en garde du CGNAT
auditeur local vs exposition publique
Liste de contrôle pour le durcissement
décision de déplacer l'accès admin derrière VPN
différence entre les bannières cachées et la réduction de la surface d'attaque

Preuves à retenir

Voici quelques éléments de preuve utiles à cette note :

Nmap résultat avec IP public caché
routeur port-forward page avec des données sensibles cachées
Sortie ss -tulpn ou netstat
En-têtes HTTP avant/après le nettoyage
Capture d'écran du certificat TLS avec des domaines privés cachés si nécessaire
SSH config durcissement extrait
Capture d'écran de la règle de pare-feu
Schéma d'accès à l'administration VPN seulement
échec du test public de panneau d'administration après le blocage de l'accès

Hypothèses techniques

Cette note suppose que l'utilisateur scanne son propre IP public ou les systèmes qu'il est autorisé à tester.

Il suppose que l'objectif est la compréhension défensive et le durcissement, et non la numérisation de cibles tierces.

Il suppose également que l'environnement peut inclure OpenWrt, les services auto-hosted, SSH, les serveurs Web et l'hébergement de jeux/serveurs.

Principaux risques

exposant publiquement SSH avec mot de passe login
exposant l'interface utilisateur du routeur admin
exposant les services de base de données
laissant des pages par défaut en ligne
ignorer les métadonnées des certificats TLS
en supposant que les ports modifiés sont une sécurité réelle
s'appuyant uniquement sur des bannières cachées
oubliant les avancées créées par UPnP
confusion de l'écoute locale avec l'exposition du public
malentendu Résultats de l'analyse CGNAT
non-vérification des registres de service pendant les essais

État actuel

Cette note représente le raisonnement de sécurité autour des ports ouverts et des empreintes digitales de service.

Il se connecte à l'auto-hébergement, OpenWrt, CGNAT, SSH, l'hébergement web, les procurations inversées et l'accès VPN.

La principale valeur est de savoir ce que les services exposés révèlent et comment réduire l'exposition sans surréagir.

Ce que la présente note ne prétend pas

Cette note ne prétend pas que chaque port ouvert est dangereux.

Elle ne prétend pas que l'empreinte digitale soit identique à l'exploitation.

Il ne fournit pas d'instructions pour attaquer des systèmes tiers.

Il documente la compréhension défensive pour les systèmes que l'exploitant possède ou est autorisé à tester.

À emporter pratique

La leçon utile est:

Les ports ouverts ne sont pas automatiquement une brèche, mais ce sont des informations publiques.

Une configuration d'auto-hébergement propre devrait répondre:

Pourquoi ce port est-il ouvert ?
Quel service répond?
Quelle version ou métadonnées révèle-t-elle?
doit-il être public?
peut-il être déplacé derrière VPN ?
Les journaux et l'authentification sont-ils forts ?
Les outils d'administration et les bases de données sont-ils privés?

Cela transforme un scan de port effrayant en une liste de contrôle pratique de durcissement.