Ports ouverts : bases de données et bureau à distance exposés
Quels services ne doivent jamais répondre à tout Internet, comment les attaquants les trouvent en quelques minutes, comment voir votre exposition sans scan, et fermer.
Votre site a besoin des ports 80 et 443 ouverts à tous. Presque rien d’autre n’en a besoin. Pourtant, la première étape la plus fréquente d’une attaque par rançongiciel contre une petite entreprise n’est pas une faille astucieuse : c’est un serveur de bureau à distance, une base de données ou une vieille page d’administration de pare-feu qui répond à n’importe qui sur Internet, trouvé par un moteur de recherche qui scanne tout Internet tous les quelques jours.
Les ports qui ne doivent pas être publics
| Port | Service | Pourquoi c’est dangereux en public |
|---|---|---|
| 3389 | Bureau à distance (RDP) | Des essais de mots de passe toute la journée, et une longue liste de failles critiques. Une porte d’entrée favorite des groupes de rançongiciels. |
| 22 | SSH | Sûr avec des clés seulement et une version récente ; avec des mots de passe, deviné. |
| 445 | Partage de fichiers Windows (SMB) | Jamais fait pour Internet ; la route de WannaCry. |
| 3306, 5432, 1433 | MySQL, PostgreSQL, SQL Server | Une base qui répond à Internet invite aux essais de mots de passe et au vol de données. |
| 27017, 6379, 9200 | MongoDB, Redis, Elasticsearch | Souvent installés sans aucun mot de passe ; des bases entières ont été copiées et rançonnées ainsi. |
| 21, 23 | FTP, Telnet | Les mots de passe circulent en clair. |
| 5900 | VNC | Contrôle d’écran à distance, souvent mal protégé. |
| 8080, 8443, 10000 | Pages d’administration | Gestion de routeur, de pare-feu, d’hébergement ou d’appliance. |
Comment les attaquants les trouvent
Ils n’ont pas besoin de vous scanner. Des services comme Shodan et Censys scannent en continu chaque adresse IPv4 publique et indexent ce qui répond, avec la version du logiciel. Un attaquant cherche « RDP en France » ou « MongoDB sans authentification » et obtient une liste. Quand une nouvelle faille est publiée dans un VPN ou un pare-feu, l’exploitation commence en quelques jours contre toutes les adresses que ce moteur liste.
Voir votre exposition sans scanner
Les mêmes index publics montrent votre exposition, et les consulter n’est pas un scan : vous lisez des données qui existent déjà. InternetDB de Shodan, par exemple, indique pour une adresse quels ports ont été vus ouverts et quelles vulnérabilités connues correspondent aux versions vues. Listez d’abord les adresses de votre domaine et de vos sous-domaines (la carte DNS et de surface gratuite le fait), puis consultez-les une à une.
Faites attention :
- aux hôtes qui contournent votre CDN ou votre pare-feu et répondent directement sur leur vraie adresse ;
- aux vieux serveurs que personne n’a en tête, qui tournent encore dans un coin d’un compte cloud ;
- à l’interface d’administration de votre pare-feu ou de votre VPN, qui ne devrait répondre qu’au réseau interne.
Une remarque : si votre site passe par Cloudflare ou un autre CDN, l’adresse publique est celle du CDN, partagée par des milliers de sites. Ce que les index disent de cette adresse (ports, versions, logiciels en fin de vie) concerne le CDN, pas votre serveur.
Fermer chacun d’eux
- Accès à distance (RDP, VNC, SSH avec mots de passe) : placez-le derrière un VPN ou un service d’accès « zéro confiance » avec authentification multifacteur, puis fermez le port. Si SSH doit rester public, n’autorisez que les clés et tenez-le à jour.
- Bases de données et caches : liez-les au réseau privé ou à
localhost, et filtrez le port. Une base qui doit être jointe de l’extérieur doit l’être par un tunnel, pas directement. - Pages d’administration : limitez-les aux adresses de votre bureau ou de votre VPN.
- Tout ce que vous ne reconnaissez pas : trouvez qui l’a mis en place avant de le fermer, puis fermez-le.
- Versions vulnérables : corrigez d’abord celles de la liste des vulnérabilités exploitées de la CISA ; elles sont utilisées contre d’autres en ce moment même.
Après chaque changement, vérifiez de nouveau : une exposition n’est corrigée que lorsque l’index public cesse de la montrer, ce qui peut prendre quelques jours.
Ce que surveille Perimetry
Chaque audit Perimetry lit les index publics pour les adresses de vos domaines, signale les services risqués qu’ils montrent et classe les vulnérabilités connues avec la liste des vulnérabilités exploitées de la CISA et la probabilité d’exploitation EPSS. Les adresses partagées des CDN sont reconnues et ne vous sont pas reprochées. Un nouveau port apparu entre deux audits figure dans les changements du rapport suivant et, s’il est grave, dans une alerte. Perimetry ne scanne jamais vos serveurs lui-même, sauf si vous souscrivez au scan actif vérifié.