Qu'est-ce qu'une politique de pare-feu par refus par défaut ?

Le refus par défaut signifie que le pare-feu bloque tout le trafic entrant sauf si une règle l'autorise explicitement. Vous n'ouvrez que les ports précis dont un service a besoin, plutôt que de bloquer les ports dangereux un par un. C'est la base la plus sûre pour tout hôte exposé sur internet.

Est-il sûr d'exposer RDP si j'utilise un mot de passe fort ?

Non. RDP sur le port 3389 est constamment scanné et attaqué par force brute, et a connu des vulnérabilités propageables comme BlueKeep. Même avec des identifiants forts, placez RDP derrière un VPN ou un hôte rebond et ne l'exposez jamais directement.

Pourquoi les bases de données ne devraient-elles jamais être accessibles depuis internet ?

Les ports de bases de données comme 3306, 5432, 1433, 27017 et 6379 arrivent souvent avec une authentification faible ou absente et exposent toutes vos données en un seul endroit. Elles ne devraient être accessibles que depuis les serveurs applicatifs sur un réseau privé.

Quels ports devriez-vous bloquer sur le pare-feu ?

Le rôle d'un pare-feu n'est pas de bloquer une liste de « mauvais » ports — c'est de n'autoriser que ce dont vous avez besoin et de refuser tout le reste. Pourtant, certains services sont si dangereux une fois exposés qu'ils méritent une place nommée sur votre liste de blocage. Ce guide passe en revue les ports que vous ne devriez jamais voir ouverts sur internet, le risque que porte chacun, et ce qu'il faut faire à la place.

Commencez par le refus par défaut en entrée

La règle la plus importante est le refus par défaut en entrée : bloquez toutes les connexions entrantes, puis n'ouvrez que les ports précis dont un service a réellement besoin (typiquement le port 443 pour HTTPS et peut-être le port 80 pour les redirections). Tout ce qui suit suppose que vous auditez un environnement où cette base a dérapé. Vous pouvez parcourir tous les ports pour rechercher tout ce que vous trouvez à l'écoute.

Partage de fichiers : SMB et NetBIOS

N'exposez jamais SMB sur le port 445 ni les anciens ports NetBIOS port 137 et port 139 sur internet. SMB a une longue histoire de bugs propageables — EternalBlue (WannaCry, NotPetya) visait exactement cela. Ce qu'il faut faire à la place : gardez SMB strictement interne, et accédez aux partages de fichiers via un VPN.

Accès distant : RDP et Telnet

Le port 3389 (RDP) est l'un des ports les plus attaqués sur internet, soumis à la force brute en permanence et frappé par des failles propageables comme BlueKeep. Le port 23 (Telnet) est pire encore : il envoie les identifiants en clair et n'a aucune place sur un réseau moderne. Ce qu'il faut faire à la place : placez RDP derrière un VPN ou un hôte rebond, et remplacez Telnet par SSH sur le port 22.

Bases de données

Les ports de bases de données sont une cible de premier choix car une seule brèche expose tout. Bloquez tous ceux-ci au périmètre :

port 3306 — MySQL / MariaDB
port 5432 — PostgreSQL
port 1433 — Microsoft SQL Server
port 27017 — MongoDB
port 6379 — Redis
port 9200 — Elasticsearch

Ce qu'il faut faire à la place : liez-les à une interface privée et n'autorisez l'accès que depuis vos serveurs applicatifs.

Services non authentifiés et de gestion

Certains services arrivent avec peu ou pas d'authentification et sont catastrophiques une fois exposés :

port 6379 — Redis n'a historiquement aucune authentification par défaut ; une instance ouverte est un risque d'exécution de code à distance.
port 2375 — l'API Docker non chiffrée donne un contrôle total équivalent root de l'hôte.
port 10000 — Webmin et les panneaux d'administration similaires sont très ciblés.
port 11211 — Memcached a été détourné pour de massives attaques d'amplification UDP.

Ce qu'il faut faire à la place : activez l'authentification et le TLS, liez à localhost, et administrez via un VPN.

Protocoles hérités et en clair

Les anciens protocoles envoient les données — y compris les mots de passe — en clair :

port 21 — FTP (utilisez SFTP sur le port 22 à la place)
port 23 — Telnet
port 69 — TFTP, qui n'a aucune authentification

Ce qu'il faut faire à la place : désactivez-les entièrement et utilisez des remplaçants chiffrés.

Amplificateurs UDP

Les services UDP sans connexion peuvent être détournés pour réfléchir et amplifier du trafic DDoS. Si vous n'en avez pas besoin publiquement, bloquez :

port 53 — DNS (seuls les serveurs autoritaires devraient répondre au monde entier)
port 123 — NTP
port 161 — SNMP
port 1900 — SSDP

Ce qu'il faut faire à la place : restreignez-les aux réseaux de confiance et désactivez la récursion ou les fonctions de type monlist lorsque c'est possible.

Conclusion

Les pare-feu fonctionnent mieux comme gardiens que comme listes de blocage : refusez l'entrée par défaut et n'exposez que la poignée de ports qu'un service exige vraiment. Mais les ports ci-dessus — SMB, RDP, Telnet, bases de données, interfaces d'administration non authentifiées, protocoles hérités en clair et amplificateurs UDP — sont des erreurs assez courantes pour qu'il vaille la peine de les vérifier nommément. En cas de doute, gardez le service privé et accédez-y via un VPN ou un hôte rebond.