| Port | Action | Source | |
|---|---|---|---|
22/tcp |
ALLOW | Anywhere | |
80/tcp |
ALLOW | Anywhere | |
443/tcp |
ALLOW | Anywhere | |
8083/tcp |
ALLOW | Anywhere | |
3306/tcp |
DENY | Anywhere | |
25/tcp |
DENY | Anywhere |
UFW existe parce que la syntaxe iptables brute ne pardonne rien, et il remplit cet office. Ce qu’il ne fait pas, c’est rendre un jeu de règles facile à relire des mois plus tard, quand ufw status numbered renvoie trente lignes et que vous cherchez lesquelles servent encore.
Cette page présente les mêmes règles, mais annonce d’abord les politiques par défaut en entrée et en sortie — car c’est précisément ce qu’on oublie. Un jeu de règles d’apparence restrictive ne vaut rien si la politique par défaut en entrée est restée sur allow. Les règles apparaissent avec leur action, leur port, leur protocole et leur source, et les entrées IPv6 sont présentées à côté de leurs équivalents IPv4 plutôt que de doubler la liste.
Les erreurs à chercher : un port ouvert pour un test ponctuel et jamais refermé, un service à l’écoute sur toutes les interfaces alors que localhost aurait suffi, une règle qui autorise un sous-réseau entier là où une seule adresse ferait l’affaire. La page des ports ouverts montre l’autre moitié du tableau : ce qui écoute réellement derrière ces règles.
Ces deux images méritent d'être confrontées régulièrement, car elles divergent en silence. Une règle peut fermer un port que personne n'écoute — elle n'est alors qu'un encombrement dans le jeu de règles. L'inverse arrive aussi : un service à l'écoute sur toutes les interfaces derrière une règle que vous croyiez fermée. La vieille réponse à cette question s'appelle netstat, et elle reste juste ; seulement, sa sortie doit être relue à l'œil à chaque fois.