Les ports les plus attaqués (et comment les sécuriser)

Les attaquants ne scannent pas Internet au hasard — ils ciblent une courte liste de ports qui mènent de façon fiable à une compromission. Les scanners de masse martèlent ces services quelques minutes seulement après l'apparition d'un hôte en ligne. Cet article passe en revue les ports les plus attaqués, pourquoi chacun est une cible, et la mesure de durcissement la plus importante pour chacun. Vous pouvez consulter chacun d'eux sur PortsDB ou parcourir tous les ports.

Accès distant : les cibles principales

RDP — port 3389

Le Bureau à distance est le point d'entrée le plus abusé. Un RDP exposé invite la force brute sur les identifiants et l'exploitation de vulnérabilités comme BlueKeep (CVE-2019-0708), une faille pré-authentification propice aux vers. C'est le vecteur d'accès initial favori des groupes de rançongiciels. Mesure n°1 : n'exposez jamais le port 3389 directement — placez-le derrière un VPN ou une passerelle RD et exigez l'authentification au niveau réseau.

SSH — port 22

SSH subit un trafic incessant de force brute et de bourrage d'identifiants automatisés. Mesure n°1 : désactivez totalement l'authentification par mot de passe au profit des clés, puis limitez le débit avec fail2ban.

Telnet — port 23

Telnet transmet les identifiants en clair et est une cible de choix des botnets IoT comme Mirai. Mesure n°1 : désactivez complètement Telnet et remplacez-le par SSH sur le port 22.

VNC — port 5900

Les serveurs VNC sont fréquemment exposés avec une authentification faible ou inexistante. Mesure n°1 : faites passer VNC dans un tunnel SSH et ne le liez jamais à une interface publique.

Partage et transfert de fichiers

SMB — port 445

SMB est le terrain de EternalBlue (MS17-010), l'exploit derrière WannaCry et NotPetya. Il est encore scanné en permanence. Mesure n°1 : bloquez le port 445 et le port 139 au périmètre et corrigez agressivement ; SMB ne doit jamais faire face à Internet.

FTP — port 21

FTP transmet les identifiants en clair et le FTP anonyme fuite souvent des données. Mesure n°1 : remplacez-le par SFTP via le port 22 ou FTPS, et désactivez la connexion anonyme.

Services web

HTTP — port 80

Le HTTP en clair sur le port 80 est sondé à la recherche d'applications vulnérables, de panneaux d'administration exposés, et sert de rampe de lancement aux attaques par injection. Mesure n°1 : redirigez tout vers HTTPS sur le port 443 et maintenez votre pile web à jour. Méfiez-vous aussi des proxys égarés sur le port 8080 et le port 3128.

Bases de données — à ne jamais exposer

Les bases de données liées à des interfaces publiques sont une mine d'or. La correction est presque toujours la même : liez à localhost ou à un réseau privé, exigez une authentification et filtrez le port au pare-feu.

• MySQL — port 3306 : force brute et recherche d'identifiants par défaut.
• MS-SQL — port 1433 : ciblé via xp_cmdshell et des mots de passe sa faibles. Surveillez aussi le port UDP 1434.
• PostgreSQL — port 5432 : scanné à la recherche de mauvaises configurations trust-auth.
• Redis — port 6379 : sans authentification par défaut ; les attaquants écrivent des clés SSH ou des tâches cron pour obtenir une exécution de code.
• MongoDB — port 27017 : la cible originelle des rançons de « bases ouvertes ».
• Elasticsearch — port 9200 : les clusters exposés fuitent des données et autorisent l'exécution de scripts.
• Memcached — port 11211 : abusé pour des attaques DDoS par réflexion UDP massives.

Autres cibles fréquentes

Gardez un œil sur SIP sur le port 5060 (fraude téléphonique), l'API Docker sur le port 2375 (prise de contrôle de conteneurs sans authentification) et SNMP sur le port 161 (chaînes de communauté par défaut fuitant des données).

Conclusion

Le constat est constant : les ports d'accès distant et de bases de données sont les plus visés, et la meilleure défense est de ne pas les exposer du tout. Placez les surfaces d'administration derrière un VPN, liez les bases de données à des réseaux privés, imposez une authentification par clé ou forte, et corrigez les bugs propices aux vers. Réduire votre surface d'attaque exposée sur Internet au seul port 443 — et un SSH durci — élimine l'essentiel du risque.