Réseaux et Fondamentaux

Ports réseau et protocoles courants

Un numéro de port identifie une application sur une machine. Plages IANA, ports éphémères, services courants et méthodes de vérification : l'essentiel pour configurer un pare-feu sans erreur.

Connexion entre un port source éphémère côté client et un port de service côté serveur

Une adresse IP désigne une machine ; un numéro de port désigne une application sur cette machine. Le couple adresse IP + port forme ce que l'on appelle couramment un socket. Une connexion est identifiée par cinq éléments : protocole, adresse et port source, adresse et port de destination.

Objectif : comprendre l'organisation des ports, connaître ceux des services courants et savoir vérifier ce qui écoute réellement sur un serveur.

Une liste plus complète, consultable et filtrable, est disponible dans la référence des ports TCP/UDP.

Ports source et ports de destination

Un numéro de port est un entier sur 16 bits : de 0 à 65 535. TCP et UDP ont des espaces de ports indépendants : le port 53/UDP et le port 53/TCP sont deux points d'écoute distincts, même si le DNS utilise les deux.

Lors d'une connexion :

  • le port de destination est celui du service (443 pour HTTPS) ;
  • le port source est un port éphémère, choisi dynamiquement par le système du client.
Client 192.168.1.20:51734  ──TCP──▶  Serveur 203.0.113.10:443

La réponse du serveur revient vers le port 51734 du client. C'est pourquoi un pare-feu sans suivi d'état devrait autoriser une large plage de ports de retour, alors qu'un pare-feu à états associe automatiquement les réponses à la connexion initiale.

Les plages définies par l'IANA

La RFC 6335 décrit trois plages :

Plage Nom Usage
0 – 1023 Ports système (well-known) Services standard ; sous Unix, l'écoute exige traditionnellement des privilèges
1024 – 49151 Ports utilisateur (registered) Services enregistrés auprès de l'IANA
49152 – 65535 Ports dynamiques ou privés Ports éphémères, usages locaux

Attention : les systèmes ne respectent pas tous cette plage pour les ports éphémères. Linux utilise par défaut 32768–60999 (paramètre net.ipv4.ip_local_port_range), tandis que Windows utilise par défaut 49152–65535 depuis Windows Vista et Windows Server 2008.

sysctl net.ipv4.ip_local_port_range
netsh int ipv4 show dynamicport tcp

Ports des services courants

Accès et administration

Port Protocole Service Remarque
22 TCP SSH, SFTP, SCP Administration chiffrée
23 TCP Telnet En clair : à proscrire
3389 TCP/UDP RDP Bureau à distance Windows ; ne jamais exposer directement sur Internet
5985 / 5986 TCP WinRM (HTTP / HTTPS) Administration PowerShell à distance

Web et messagerie

Port Protocole Service Remarque
80 TCP HTTP Généralement redirigé vers HTTPS
443 TCP (et UDP pour HTTP/3) HTTPS HTTP/3 utilise QUIC sur UDP 443
25 TCP SMTP (relais entre serveurs) Souvent bloqué en sortie par les FAI
587 TCP SMTP soumission (STARTTLS) Envoi par les clients authentifiés
465 TCP SMTP soumission (TLS implicite) Réhabilité par la RFC 8314
993 TCP IMAPS IMAP chiffré
995 TCP POP3S POP3 chiffré

Services d'infrastructure

Port Protocole Service Remarque
53 UDP et TCP DNS TCP indispensable pour les grosses réponses
853 TCP DNS over TLS (DoT) Chiffrement client-résolveur
67 / 68 UDP DHCP serveur / client
123 UDP NTP Synchronisation horaire
161 / 162 UDP SNMP / traps SNMP Préférer SNMPv3
514 UDP Syslog 6514/TCP pour syslog sur TLS
389 / 636 TCP LDAP / LDAPS Annuaire
88 TCP/UDP Kerberos Authentification Active Directory
445 TCP SMB Partages Windows ; jamais exposé sur Internet
1812 / 1813 UDP RADIUS authentification / comptabilité 802.1X, VPN

VPN et tunnels

Port Protocole Service
500 / 4500 UDP IKE / IPsec NAT-T
1194 UDP (ou TCP) OpenVPN (valeur par défaut)
51820 UDP WireGuard (valeur usuelle)

Un port n'est qu'une convention. Rien n'empêche un service SSH d'écouter sur le port 443, ni un logiciel malveillant d'utiliser le port 53. Pour identifier un service, il faut observer le protocole réellement échangé, pas seulement le numéro de port.

Vérifier ce qui écoute sur une machine

Linux

sudo ss -tulpn
Netid State  Local Address:Port  Process
tcp   LISTEN 0.0.0.0:22          users:(("sshd",pid=812,fd=3))
tcp   LISTEN 127.0.0.1:3306      users:(("mariadbd",pid=1033,fd=21))
tcp   LISTEN [::]:443            users:(("nginx",pid=1201,fd=7))

L'adresse d'écoute est aussi importante que le port :

  • 0.0.0.0 ou [::] : toutes les interfaces ;
  • 127.0.0.1 ou [::1] : uniquement en local — un service de base de données devrait souvent écouter ainsi.

Windows

Get-NetTCPConnection -State Listen | Sort-Object LocalPort |
  Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id 4321
netstat -abno        # nécessite une console administrateur pour -b

Depuis une autre machine

Test-NetConnection srv-app01 -Port 8443
nc -vz srv-app01 8443

Le balayage de ports avec des outils spécialisés ne doit être effectué que sur des systèmes dont vous avez la responsabilité ou une autorisation écrite.

Construire des règles de filtrage

  1. Inventoriez les flux nécessaires : source, destination, protocole, port.
  2. Autorisez explicitement ces flux et refusez le reste par défaut.
  3. Restreignez les sources : le port 22 d'un serveur ne doit être joignable que depuis le réseau d'administration ou un bastion.
  4. Distinguez TCP et UDP : ouvrir « le port 53 » sans préciser le protocole est une source d'erreurs.
  5. Documentez chaque règle (demandeur, justification, date de revue).

Voir Pare-feu : règles de filtrage et bonnes pratiques.

Erreurs courantes

  • Exposer des services d'administration (RDP, SSH, SMB, bases de données) sur Internet.
  • Oublier UDP pour des services comme DNS, NTP ou IPsec.
  • Laisser un service de développement écouter sur toutes les interfaces.
  • Croire que changer de port sécurise un service : cela réduit le bruit des robots, mais un balayage le retrouve.
  • Confondre port d'écoute du serveur et port source du client dans une règle de pare-feu.

Implications de sécurité

Chaque port en écoute est une porte d'entrée potentielle. Réduisez la surface d'attaque en désactivant les services inutiles, en liant les services internes à l'interface de bouclage ou à un réseau privé, en privilégiant les variantes chiffrées des protocoles et en surveillant l'apparition de nouveaux ports en écoute. Un inventaire régulier, comparé à une référence, révèle rapidement un service installé par erreur ou un logiciel indésirable.

Conclusion

Port de destination pour le service, port éphémère pour le client, protocole à toujours préciser : avec ces trois réflexes et une vérification par ss ou Get-NetTCPConnection, vous savez exactement ce qui est exposé sur vos machines. Approfondissez avec TCP et UDP : différences, cas d'utilisation et diagnostic.

Références