il y a 1 an

Ports TCP/UDP : construire un firewall utile sans tout ouvrir

Configurer un pare-feu ne consiste pas à mémoriser cinquante numéros de ports puis à les ouvrir religieusement sur chaque machine.

La vraie question est :

Quel service doit communiquer ?
Dans quel sens ?
Avec quelles machines ?
Sur quel protocole ?
Et pourquoi ?

Un serveur Web public n’a aucune raison d’exposer MySQL à Internet simplement parce que :

3306 = MySQL

De même, un poste utilisateur n’a généralement pas besoin d’autoriser des connexions entrantes vers TCP/443 simplement parce qu’il navigue sur le Web.

Un port connu n’est pas un port à ouvrir. C’est seulement un numéro traditionnellement associé à un service.

À quoi sert un port TCP ou UDP ?

TCP et UDP utilisent des numéros de ports sur 16 bits pour distinguer plusieurs communications entre les mêmes machines.

Un numéro de port varie donc entre :

0
et
65535

Une connexion TCP peut être identifiée par plusieurs informations :

IP source
port source
IP destination
port destination
protocole

Par exemple :

192.0.2.15:53124
        ↓
198.51.100.20:443
       TCP

Ici :

53124 est un port client temporaire ;
443 est le port du service HTTPS contacté ;
le protocole de transport est TCP.

TCP et UDP possèdent leurs propres espaces de ports

TCP/53 et UDP/53 ne représentent pas la même extrémité de transport.

On doit donc toujours préciser :

numéro
+
protocole

Par exemple :

TCP/443
UDP/443

peuvent tous deux être légitimes pour le Web moderne, mais ils correspondent à des transports différents.

Les trois grandes plages de ports

Plage	Nom IANA	Usage général
0–1023	System / Well-Known Ports	Services disposant traditionnellement d’un point de contact standard
1024–49151	User / Registered Ports	Services et applications enregistrés
49152–65535	Dynamic / Private Ports	Utilisation dynamique, privée ou temporaire

Les ports dynamiques servent notamment souvent de :

ports source temporaires
côté client

Port dynamique ne signifie pas « toujours 49152–65535 sur chaque OS »

49152–65535 est la plage dynamique définie par l’IANA.

Un système d’exploitation peut néanmoins gérer sa plage éphémère selon ses propres paramètres.

Windows moderne utilise par exemple couramment :

49152–65535

pour ses ports dynamiques TCP/UDP par défaut, notamment dans de nombreux scénarios Active Directory et RPC.

Sur Linux, la plage locale peut être consultée avec :

cat /proc/sys/net/ipv4/ip_local_port_range

Un firewall stateful évite d’ouvrir tous les ports clients en entrée

Imaginons un navigateur qui initie :

client:53124
→
serveur:443

La réponse revient :

serveur:443
→
client:53124

Avec un pare-feu stateful, on n’ouvre pas nécessairement :

49152-65535
à tout Internet
en entrée

Le firewall reconnaît que les paquets appartiennent à une connexion déjà autorisée.

Avec nftables, la règle classique est :

ct state established,related accept

Port source et port destination

La distinction est fondamentale.

Lorsqu’un client contacte un serveur HTTPS :

Client
source      : 53124
destination : 443

Serveur
écoute      : TCP/443

Dire :

« Le client utilise le port 443. »

est donc imprécis.

Il contacte le port destination 443, généralement depuis un port source temporaire.

Ports courants à connaître

Voici un tableau plus utile qu’une liste de ports à ouvrir aveuglément.

Port	Transport	Service	Remarque
20	TCP	FTP data	Données FTP en mode actif traditionnel
21	TCP	FTP	Canal de contrôle FTP
22	TCP	SSH	Administration distante, SFTP, tunnels
23	TCP	Telnet	Protocole historique non chiffré
25	TCP	SMTP	Relais de courrier entre serveurs
53	UDP/TCP	DNS	Résolution de noms
67	UDP	DHCPv4 serveur	Serveur DHCP
68	UDP	DHCPv4 client	Client DHCP
69	UDP	TFTP	Transfert minimaliste, souvent PXE/équipements
80	TCP	HTTP	Web non chiffré
88	TCP/UDP	Kerberos	Authentification, notamment Active Directory
110	TCP	POP3	Accès mail historique, chiffrement recommandé
123	UDP	NTP	Synchronisation horaire
135	TCP	RPC Endpoint Mapper	Important dans plusieurs environnements Windows
143	TCP	IMAP	Accès aux boîtes mail, éventuellement STARTTLS
161	UDP	SNMP	Interrogation et supervision
162	UDP	SNMP Trap	Notifications SNMP
389	TCP/UDP	LDAP / CLDAP	LDAP TCP ; UDP notamment dans certains usages CLDAP
443	TCP/UDP	HTTPS / HTTP/3	TCP pour HTTP/1.1 et HTTP/2 ; UDP notamment pour QUIC/HTTP/3
445	TCP	SMB	Partages Windows et services associés
465	TCP	SMTP Submission TLS implicite	Soumission de courrier sécurisée
514	UDP	Syslog	Transport syslog historique
546	UDP	DHCPv6 client	DHCP pour IPv6
547	UDP	DHCPv6 serveur	DHCP pour IPv6
587	TCP	SMTP Submission	Soumission client, typiquement avec STARTTLS
636	TCP	LDAP over TLS	LDAPS / LDAP TLS implicite
853	TCP	DNS over TLS	DNS chiffré avec TLS
993	TCP	IMAP over TLS	IMAPS
995	TCP	POP3 over TLS	POP3S
1194	UDP/TCP	OpenVPN	Port enregistré, configuration modifiable
1433	TCP	Microsoft SQL Server	Port courant des instances SQL Server par défaut
1434	UDP	SQL Server Browser	Découverte de certaines instances SQL Server
1812	UDP	RADIUS Authentication	Authentification AAA
1813	UDP	RADIUS Accounting	Comptabilisation AAA
2049	TCP/UDP	NFS	Network File System selon version/configuration
3128	TCP	Proxy HTTP	Très courant avec Squid, mais configurable
3268	TCP	Active Directory Global Catalog	LDAP vers le Global Catalog
3269	TCP	Global Catalog TLS	Global Catalog via TLS
3306	TCP	MySQL / MariaDB	Port classique des serveurs MySQL/MariaDB
3389	TCP/UDP	RDP	Remote Desktop Protocol
5432	TCP	PostgreSQL	Port PostgreSQL par défaut
5900+	TCP	VNC	5900 + numéro d’affichage selon implémentation
6514	TCP	Syslog over TLS	Transport syslog protégé par TLS

FTP : les ports 20 et 21 ne racontent qu’une partie de l’histoire

FTP est un protocole particulièrement pénible pour les pare-feu car il utilise deux connexions :

connexion de contrôle
+
connexion de données

Le canal de contrôle utilise normalement :

TCP/21

FTP actif

Dans le mode actif historique, le serveur établit typiquement la connexion de données depuis :

TCP/20

vers le client.

FTP passif

Dans le mode passif, le serveur indique au client un autre port sur lequel établir la connexion de données.

Ce port peut appartenir à une plage configurable.

Donc :

ouvrir TCP/20 et TCP/21

n’est pas une recette universelle permettant à tout FTP de fonctionner.

Les firewalls stateful et helpers protocolaires peuvent également intervenir selon l’architecture.

Et surtout : FTP n’est pas SFTP

SFTP signifie :

SSH File Transfer Protocol

et fonctionne typiquement sur :

TCP/22

Il ne s’agit pas de :

FTP
+
TLS

Ce sont des protocoles différents.

FTPS est encore autre chose

FTPS correspond à :

FTP avec TLS

Il conserve donc beaucoup des contraintes de FTP concernant :

canal de contrôle ;
connexions de données ;
mode actif/passif.

SSH : TCP/22

SSH permet notamment :

shell distant ;
exécution de commandes ;
SFTP ;
SCP selon environnement ;
tunnels TCP ;
transferts sécurisés.

Pour un serveur exposé, une règle ne devrait pas forcément être :

Internet entier
→ TCP/22
→ ACCEPT

Si l’architecture le permet, il est préférable de limiter l’administration à :

un réseau d’administration ;
un VPN ;
certaines adresses sources ;
un bastion.

Changer SSH de 22 vers 2222 n’est pas une protection fondamentale

Cela peut réduire le bruit des robots les plus rudimentaires.

Mais un scanner de ports découvrira facilement :

TCP/2222 ouvert

La véritable sécurité vient notamment de :

l’authentification forte ;
la restriction des accès ;
les mises à jour ;
les bonnes permissions ;
la supervision.

DNS : UDP et TCP 53

La vieille règle pédagogique :

UDP/53 = requêtes
TCP/53 = transferts de zones

est aujourd’hui trop simpliste.

DNS doit pouvoir fonctionner avec :

UDP/53
et
TCP/53

TCP est notamment nécessaire pour certaines réponses volumineuses et différentes situations où UDP ne suffit pas.

Transferts de zones

Les opérations comme :

AXFR
IXFR

utilisent TCP.

Mais cela ne signifie pas que :

TCP/53 = uniquement AXFR

Un serveur DNS ne doit pas être ouvert comme un client DNS

Un poste utilisateur doit généralement pouvoir :

sortir vers ses résolveurs DNS autorisés
sur UDP/TCP 53

Il n’a aucune raison d’accepter :

Internet
→ son propre TCP/UDP 53

s’il n’exécute aucun serveur DNS.

DNS chiffré

On rencontre également :

DNS over TLS
→ TCP/853

et :

DNS over HTTPS
→ généralement HTTPS sur 443

Un firewall filtrant uniquement :

UDP/TCP 53

ne contrôle donc pas nécessairement toutes les formes de résolution DNS utilisées par les applications.

DHCPv4 : UDP/67 et UDP/68

DHCP utilise une architecture particulière car un client peut devoir obtenir une configuration réseau alors qu’il ne possède encore aucune adresse IPv4 utilisable.

Les ports standards sont :

UDP/67
→ serveur DHCP

UDP/68
→ client DHCP

Le trafic peut faire intervenir du broadcast avant que le client soit complètement configuré.

DHCP à travers plusieurs réseaux

Un serveur DHCP n’a pas besoin d’être présent dans chaque VLAN.

Un :

DHCP relay
IP helper

peut relayer les requêtes vers un serveur situé sur un autre réseau.

La politique firewall doit alors être conçue en fonction :

du client ;
du relais ;
du serveur ;
du sens réel des flux.

DHCPv6 utilise d’autres ports

UDP/546
→ client DHCPv6

UDP/547
→ serveur DHCPv6

IPv6 ne doit donc pas être administré en recopiant mécaniquement les règles IPv4 et en remplaçant quelques adresses.

NTP : UDP/123

NTP permet de synchroniser les horloges.

La précision horaire est particulièrement importante pour :

Kerberos ;
journaux ;
certificats ;
corrélation d’événements ;
systèmes distribués.

Un poste NTP client a généralement besoin de communiquer :

vers UDP/123
sur ses serveurs NTP autorisés

Cela ne signifie pas qu’il doit servir NTP à l’ensemble d’Internet.

HTTP et HTTPS

HTTP

TCP/80

Utilisé pour HTTP sans chiffrement.

Il reste très fréquent pour :

redirection vers HTTPS ;
services internes ;
certains mécanismes automatisés.

HTTPS traditionnel

TCP/443

HTTP/1.1 et HTTP/2 sont couramment transportés via TLS sur TCP/443.

HTTP/3

HTTP/3 repose sur :

QUIC
sur UDP

et utilise fréquemment :

UDP/443

Un firewall autorisant uniquement :

TCP/443

peut donc empêcher HTTP/3.

Les clients peuvent souvent revenir à une version HTTP sur TCP, mais les performances et comportements peuvent changer.

Le mail : ne mélangez pas relais et soumission

SMTP serveur à serveur

TCP/25

sert principalement au transfert du courrier entre serveurs SMTP.

Un poste utilisateur ordinaire n’a généralement aucune raison d’envoyer directement son courrier vers :

TCP/25
de n'importe quel serveur Internet

Submission

Les clients mail utilisent plutôt :

TCP/587
→ Message Submission
→ généralement avec STARTTLS

ou :

TCP/465
→ Submission avec TLS implicite

IMAP

TCP/143
→ IMAP, éventuellement STARTTLS

TCP/993
→ IMAP avec TLS implicite

POP3

TCP/110
→ POP3, éventuellement STARTTLS

TCP/995
→ POP3 avec TLS implicite

Ports connus ne signifie pas trafic chiffré

Le numéro de port ne garantit jamais à lui seul la sécurité.

Par exemple :

TCP/443

est traditionnellement HTTPS, mais un programme peut techniquement faire écouter autre chose dessus.

Inversement :

HTTPS

peut être configuré sur :

8443
9443
ou autre port

Un port indique un point de rendez-vous conventionnel, pas une analyse cryptographique du trafic.

LDAP et Active Directory

LDAP utilise notamment :

TCP/389

et certaines utilisations de :

UDP/389

existent notamment avec CLDAP.

LDAP avec TLS implicite est traditionnellement associé à :

TCP/636

Active Directory ne se résume surtout pas à TCP/389

Un environnement Active Directory utilise plusieurs protocoles :

Service	Ports importants
DNS	TCP/UDP 53
Kerberos	TCP/UDP 88
LDAP	TCP/UDP 389
Kerberos password change	TCP/UDP 464
SMB	TCP 445
RPC Endpoint Mapper	TCP 135
Global Catalog	TCP 3268 / 3269
RPC dynamique	Plage dynamique définie/configurée sur Windows

C’est pourquoi :

j'ai ouvert 389
donc Active Directory doit fonctionner

est une théorie qui ne résiste généralement pas très longtemps au premier contrôleur de domaine.

SMB : TCP/445

SMB est notamment utilisé pour :

partages de fichiers Windows ;
partages d’imprimantes ;
SYSVOL ;
différentes fonctions Active Directory ;
administration Windows.

Le port principal moderne est :

TCP/445

Les anciens réseaux peuvent aussi rencontrer NetBIOS sur :

UDP/137
UDP/138
TCP/139

mais les environnements modernes privilégient SMB directement sur TCP/445.

N’exposez pas SMB directement à Internet sans nécessité extrêmement particulière

Une politique saine ressemble davantage à :

LAN autorisé
VPN autorisé
Internet direct refusé

qu’à :

0.0.0.0/0
→ TCP/445
→ allons voir ce qui se passe

SNMP : UDP/161 et 162

Pour la supervision :

UDP/161
→ requêtes vers l'agent

UDP/162
→ traps / notifications vers le manager

Le sens est donc important.

Si :

serveur de supervision
→ switch
→ UDP/161

l’ouverture nécessaire n’est pas la même que pour :

switch
→ serveur de supervision
→ UDP/162

SNMPv1 et SNMPv2c : attention aux communautés

Les anciennes versions utilisent notamment des :

community strings

qui ne fournissent pas le niveau de sécurité d’un véritable mécanisme moderne de chiffrement et d’authentification.

Lorsque disponible, :

SNMPv3

est généralement préférable.

Syslog : 514 n’est pas la seule possibilité

Le syslog historique utilise très souvent :

UDP/514

UDP possède cependant plusieurs limites :

pas de garantie de livraison ;
pas de connexion ;
pas de chiffrement intrinsèque.

Selon l’architecture, on peut utiliser d’autres transports.

Le transport syslog protégé par TLS est notamment associé à :

TCP/6514

RDP : TCP et UDP 3389

Remote Desktop Protocol peut utiliser :

TCP/3389
UDP/3389

sur les configurations modernes.

TCP assure notamment la communication principale tandis qu’UDP peut améliorer certaines caractéristiques de transport de la session.

Comme pour SSH, l’exposition directe de RDP à Internet devrait être soigneusement évitée ou contrôlée.

Des architectures plus robustes utilisent par exemple :

VPN ;
RD Gateway ;
réseau d’administration ;
restrictions d’adresses ;
authentification forte.

Les bases de données ne devraient généralement pas être publiques

Ports courants :

Microsoft SQL Server
TCP/1433

MySQL / MariaDB
TCP/3306

PostgreSQL
TCP/5432

Sur une architecture classique :

Internet
   │
   ▼
Serveur Web
   │
   ▼
Base de données

le firewall devrait souvent autoriser :

serveur Web
→ serveur SQL
→ port précis

et non :

Internet entier
→ serveur SQL

Port de base de données ouvert ≠ authentification

Le firewall contrôle :

qui peut atteindre le service

La base de données contrôle ensuite :

qui peut s'authentifier
et
quelles opérations sont autorisées

Les deux couches sont complémentaires.

OpenVPN : 1194 est un défaut, pas une obligation

OpenVPN est traditionnellement associé à :

et utilise très fréquemment :

UDP/1194

Mais OpenVPN est configurable et peut fonctionner sur :

d’autres ports ;
UDP ;
TCP selon la configuration.

Ne déduisez donc pas qu’un VPN inconnu utilise forcément :

VNC : généralement autour de TCP/5900

Les implémentations VNC utilisent historiquement :

5900 + numéro d'affichage

Par exemple :

:0 → 5900
:1 → 5901
:2 → 5902

Mais les implémentations et configurations peuvent varier.

Un numéro de port n’est jamais une garantie absolue du protocole

Un administrateur peut configurer :

SSH sur 443
HTTPS sur 8443
PostgreSQL sur 15432

La table des ports connus permet surtout de savoir :

« Quel service rencontre-t-on normalement ici ? »

et non :

« Le noyau garantit que ce numéro ne peut servir qu’à ce protocole. »

Firewall entrant et sortant : ne posez pas la même question

Pour un serveur Web public :

Entrée :
TCP/80
TCP/443
UDP/443 si HTTP/3 souhaité

Administration :
TCP/22 depuis réseau d'admin uniquement

En sortie, ce même serveur peut avoir besoin de :

DNS
NTP
mises à jour
base de données
API
SMTP
supervision

Les besoins sont donc complètement différents selon le sens.

Exemple : serveur Web simple

Sens	Source	Destination	Port
Entrée	Internet	Serveur Web	TCP/80, TCP/443
Entrée	Internet	Serveur Web	UDP/443 si HTTP/3
Entrée	Réseau admin	Serveur Web	TCP/22
Sortie	Serveur Web	DNS interne	UDP/TCP 53
Sortie	Serveur Web	NTP	UDP/123
Sortie	Serveur Web	Serveur SQL	TCP/3306 selon architecture

Exemple : poste utilisateur

Un poste client classique peut principalement avoir besoin d’initier :

DNS
HTTP/HTTPS
NTP
services d'entreprise
mises à jour

Il n’a pas pour autant besoin d’accepter depuis Internet :

TCP/80
TCP/443
TCP/3306
TCP/3389
TCP/445

Le simple fait qu’un programme utilise un port distant ne signifie pas que le même port doit être ouvert en écoute localement.

Exemple : serveur de fichiers SMB

Une règle correcte ressemblera davantage à :

Réseaux utilisateurs autorisés
       │
       ▼
     TCP/445
       │
       ▼
Serveur de fichiers

qu’à :

n'importe quelle adresse
→ TCP/445
→ ACCEPT

Les ports seuls ne suffisent pas

Une règle firewall professionnelle devrait souvent tenir compte de :

l’adresse source ;
l’adresse destination ;
l’interface ;
le protocole ;
le port destination ;
l’état de la connexion ;
éventuellement le sens ou la zone réseau.

Par exemple :

autoriser TCP/22

est beaucoup moins précis que :

autoriser TCP/22
depuis 192.0.2.0/24
vers ce serveur
pour les nouvelles connexions

Exemple nftables : serveur simple

table inet firewall {

    chain input {
        type filter hook input priority filter;
        policy drop;

        iifname "lo" accept

        ct state invalid drop
        ct state established,related accept

        meta l4proto { icmp, ipv6-icmp } accept

        ip saddr 192.0.2.0/24 tcp dport 22 accept

        tcp dport { 80, 443 } accept
        udp dport 443 accept
    }

    chain forward {
        type filter hook forward priority filter;
        policy drop;
    }

    chain output {
        type filter hook output priority filter;
        policy accept;
    }
}

Dans cet exemple :

les nouvelles connexions entrantes sont refusées par défaut ;
loopback reste utilisable ;
les réponses aux connexions autorisées sont acceptées ;
SSH est limité au réseau d’administration ;
HTTP/HTTPS sont publics ;
UDP/443 permet HTTP/3 si le serveur l’utilise.

Ne recopiez jamais un exemple firewall sans l’adapter

Une configuration valable pour :

serveur Web public

peut être catastrophique sur :

contrôleur de domaine
routeur
serveur DNS
poste client
hyperviseur

Un firewall est une politique d’accès, pas un fichier de recettes universelles.

Comment savoir quels ports écoutent réellement ?

Sous Linux :

ss -lntup

permet d’examiner les sockets en écoute.

On peut également utiliser selon le besoin :

sudo ss -lntup

pour obtenir davantage d’informations sur les processus.

Exemple de résultat

tcp LISTEN 0 128 0.0.0.0:22
tcp LISTEN 0 511 0.0.0.0:443

Cela signifie qu’un programme écoute localement.

Mais cela ne garantit pas encore que le service soit joignable depuis le réseau :

service en écoute
+
firewall
+
routage
+
ACL intermédiaires
+
NAT éventuel

participent tous au résultat.

Sous Windows

On peut utiliser :

netstat -ano

ou PowerShell :

Get-NetTCPConnection

pour examiner les connexions et ports TCP locaux.

Scanner depuis une autre machine

Un outil comme :

nmap

permet de vérifier ce qui apparaît accessible depuis un autre point du réseau.

Exemple sur une machine ou un réseau que vous êtes autorisé à administrer :

nmap -sT 192.0.2.10

Pour quelques ports précis :

nmap -p 22,80,443,445 192.0.2.10

Écouter localement et être accessible sont deux choses différentes

Un service peut écouter sur :

127.0.0.1:3306

et donc n’être accessible que localement.

Ou sur :

0.0.0.0:3306

ce qui signifie qu’il écoute sur toutes les interfaces IPv4 concernées.

Mais même dans le deuxième cas, le firewall peut encore bloquer les connexions.

La règle du moindre privilège

Au lieu de :

ouvrir TCP/3306

demandez :

Qui doit accéder à MySQL ?

Si la réponse est :

uniquement 10.20.30.15

la règle devrait refléter cette réalité.

Par exemple :

ip saddr 10.20.30.15 tcp dport 3306 accept

Plusieurs services peuvent partager le même port

Un reverse proxy peut écouter sur :

TCP/443

puis distribuer les requêtes vers :

application A
application B
application C

selon :

le nom DNS ;
SNI ;
l’URL ;
d’autres informations applicatives.

Le firewall de couche 3/4 voit alors principalement :

TCP/443

et non nécessairement l’application finale.

Un port ouvert n’est pas une vulnérabilité en soi

Un port ouvert signifie :

un service est accessible ici

Le risque dépend ensuite de :

ce service ;
sa version ;
sa configuration ;
son authentification ;
ses vulnérabilités ;
les sources autorisées.

Un TCP/22 correctement administré n’est pas automatiquement dangereux.

Un service inconnu écoutant sur :

TCP/45872

n’est pas automatiquement sûr parce que son port est exotique.

Un port fermé n’est pas une protection contre tout

Le firewall n’agit pas à la place :

des mises à jour ;
du contrôle d’accès ;
des ACL applicatives ;
de TLS ;
de la segmentation ;
de l’authentification ;
de la supervision.

Il réduit la surface exposée.

Il ne transforme pas un service vulnérable explicitement autorisé en forteresse.

Les erreurs classiques

Ouvrir toute la plage 49152–65535 en entrée

Pour un firewall stateful classique, cela n’est généralement pas nécessaire simplement pour permettre aux clients de recevoir les réponses de leurs connexions sortantes.

Utilisez le suivi d’état.

Ouvrir tous les ports de cette liste

Cette liste est un :

référentiel

pas une :

configuration recommandée

Autoriser UDP/53 mais bloquer TCP/53

Résultat possible :

DNS fonctionne presque toujours
jusqu'au moment où il ne fonctionne plus

Les problèmes intermittents sont les meilleurs problèmes, surtout quand ils touchent la résolution de noms.

Oublier UDP/443

Le Web fonctionnera souvent encore en TCP, mais HTTP/3 pourra être empêché.

Ouvrir une base SQL à Internet

Si seuls deux serveurs applicatifs doivent l’utiliser, limitez la règle à ces deux serveurs.

Exposer SMB ou RDP partout

Préférez :

VPN ;
réseaux dédiés ;
bastions ;
gateways ;
restrictions de sources.

Supposer que le numéro de port garantit le protocole

Un programme peut écouter sur pratiquement n’importe quel port disponible.

Confondre service et transport

Écrivez :

TCP/53
UDP/53

plutôt que simplement :

port 53

lorsque le protocole de transport compte.

Oublier IPv6

Une machine possédant :

firewall IPv4 strict
+
IPv6 actif sans filtrage

n’est pas nécessairement aussi protégée que son administrateur l’imagine.

Méthode correcte pour concevoir les règles

Pour chaque flux, documentez :

Élément	Exemple
Source	`10.20.30.0/24`
Destination	`10.20.40.10`
Transport	TCP
Port destination	443
Service	HTTPS
Sens	Utilisateurs → application
Justification	Application métier

On obtient alors une règle compréhensible :

10.20.30.0/24
→
10.20.40.10
→
TCP/443
→
autorisé

plutôt qu’un inquiétant :

443 ACCEPT

dont plus personne ne connaît la raison six mois plus tard.

Une règle firewall devrait avoir un propriétaire

Pour les environnements professionnels, il est utile de documenter :

le service concerné ;
le responsable ;
la justification ;
la date d’ouverture ;
la durée éventuelle ;
les machines concernées.

Une règle nommée :

TEMP_TEST_DO_NOT_DELETE

créée il y a sept ans appartient déjà au patrimoine historique de l’entreprise.

Checklist avant d’ouvrir un port

Le service existe-t-il réellement ?
Est-il en écoute sur ce port ?
TCP, UDP ou les deux ?
Le flux doit-il être entrant ou sortant ?
Quelles sources doivent y accéder ?
IPv4, IPv6 ou les deux ?
Le trafic doit-il traverser un NAT ?
Le service possède-t-il des ports secondaires ou dynamiques ?
Existe-t-il une alternative plus sûre, comme un VPN ?
La règle est-elle documentée ?

Checklist de diagnostic

Si un service reste inaccessible :

1. Vérifier que le service fonctionne

2. Vérifier l'adresse d'écoute

3. Vérifier le port d'écoute

4. Vérifier TCP ou UDP

5. Vérifier le routage

6. Vérifier le firewall local

7. Vérifier les ACL/firewalls intermédiaires

8. Vérifier le NAT éventuel

9. Vérifier le DNS

10. Capturer le trafic si nécessaire

Quelques outils utiles

Outil	Utilisation
`ss`	Afficher sockets et ports Linux
`nft`	Inspecter/configurer nftables
`nmap`	Tester les ports accessibles depuis le réseau
`tcpdump`	Observer les paquets
`dig`	Tester DNS
`curl`	Tester HTTP/HTTPS et d’autres protocoles
`nc`	Tester certaines connexions TCP/UDP
`netstat`	Diagnostic historique / Windows

Les ports à retenir en priorité

Pour un administrateur réseau généraliste, cette sélection couvre déjà énormément de situations :

20/21    FTP
22       SSH
25       SMTP relay
53       DNS
67/68    DHCPv4
80       HTTP
88       Kerberos
123      NTP
135      RPC
161/162  SNMP
389      LDAP
443      HTTPS / HTTP3
445      SMB
465      SMTP Submission TLS
546/547  DHCPv6
587      SMTP Submission
636      LDAP TLS
993      IMAP TLS
995      POP3 TLS
1194     OpenVPN
1433     SQL Server
1812     RADIUS
1813     RADIUS Accounting
2049     NFS
3268     AD Global Catalog
3306     MySQL/MariaDB
3389     RDP
5432     PostgreSQL
5900     VNC
6514     Syslog TLS

Mais les mémoriser n’est pas le plus important.

Il faut comprendre :

service
+
transport
+
direction
+
source
+
destination
+
état de connexion

Conclusion : un firewall ne protège pas par accumulation de numéros

Les ports TCP et UDP sont essentiels pour comprendre les flux réseau, mais une bonne politique ne consiste pas à :

connaître 50 ports
↓
ouvrir les 50
↓
se déclarer sécurisé

Elle consiste plutôt à :

inventorier les services
↓
comprendre les flux
↓
autoriser le minimum nécessaire
↓
restreindre les sources
↓
utiliser le suivi d'état
↓
tester
↓
documenter
↓
réexaminer régulièrement

Retenez surtout :

un port connu n’est jamais automatiquement un port à ouvrir ;
TCP et UDP possèdent des espaces de ports distincts ;
le port destination d’un serveur et le port source temporaire d’un client ne jouent pas le même rôle ;
un firewall stateful permet généralement les réponses sans ouvrir toute la plage dynamique en entrée ;
DNS moderne nécessite la prise en charge de TCP et UDP 53 ;
HTTPS peut utiliser TCP/443 mais aussi UDP/443 avec HTTP/3 et QUIC ;
SMTP/25 est principalement destiné au relais entre serveurs, tandis que 587 et 465 servent à la soumission client ;
RDP moderne peut utiliser TCP et UDP 3389 ;
FTP possède plusieurs connexions et ne se résume pas aux ports 20 et 21 ;
Active Directory nécessite plusieurs protocoles et parfois des ports RPC dynamiques ;
les bases de données, SMB, SSH et RDP devraient être limités aux sources qui en ont réellement besoin ;
le numéro du port ne garantit pas quel protocole écoute réellement dessus ;
IPv6 doit être inclus dans la conception du filtrage ;
et une règle dont personne ne connaît la raison est déjà une dette technique.

Le bon pare-feu n’est donc pas celui qui bloque le plus de choses.

C’est celui qui autorise exactement ce qui doit fonctionner, refuse proprement le reste et laisse suffisamment de documentation pour que l’administrateur suivant n’ait pas à pratiquer la divination sur un fichier de règles écrit cinq ans plus tôt.

Post Views: 27