Vous venez de déployer une machine virtuelle toute fraîche. Premier réflexe : lui coller une adresse IP publique pour y accéder de partout. Après tout, c’est pratique. Sauf que cette approche revient à brancher votre serveur directement sur Internet sans aucune protection entre lui et le reste du monde. Et ça, dans la vraie vie, ça ne pardonne pas.
J’ai vu des VMs se faire scanner et attaquer en moins de trois minutes après avoir reçu une IP publique. Pas trois heures. Trois minutes.
Quels sont les dangers quand on expose une adresse IP publique ?
Une VM avec une adresse IP publique accessible en permanence, c’est une cible visible depuis n’importe quel point du globe. Chaque port ouvert sur cette machine devient un point d’entrée potentiel pour les bots qui scannent Internet 24 heures sur 24, 7 jours sur 7. Et ces bots ne font pas la différence entre un serveur de production critique et votre petit environnement de test.
Même un simple hébergement web basique ou un labo de développement attire les tentatives. Dès qu’un service RDP tourne sur le port 3389 ou qu’un SSH écoute sur le port 22, les tentatives d’accès non autorisé commencent à pleuvoir. Parfois avant même que vous ayez fini de configurer la machine.
Failles de sécurité et accès non autorisé
Le scénario classique : votre VM a un retard de patch. Peut-être un service avec une CVE connue qui traîne, un mot de passe par défaut oublié, ou une version de logiciel qui n’a pas été mise à jour depuis quelques semaines. Un scan automatisé détecte le port ouvert, tente une série de mots de passe courants, trouve la faille. Résultat : un mineur de cryptomonnaie qui tourne en arrière-plan, ou pire, votre machine devient un relais pour attaquer d’autres cibles.
Le problème, c’est que la plupart de ces intrusions passent complètement inaperçues. Pas d’alerte, pas d’écran rouge. Juste vos ressources consommées en silence et votre VM qui rejoint un botnet. L’exposition externe directe multiplie ces risques alors qu’ils sont parfaitement évitables. Des solutions comme Azure Bastion de Microsoft permettent justement de sécuriser l’accès sans jamais rendre l’IP publique accessible.
Ports ouverts (RDP/SSH/3389) : les cibles favorites
Les ports 3389 (RDP) et 22 (SSH) sont les deux ports les plus attaqués au monde. C’est logique : ce sont les portes d’entrée d’administration par excellence. Selon les données de Shodan, des millions de machines exposent ces ports directement sur Internet. Et chaque jour, elles subissent des milliers de tentatives de connexion par force brute.
Laisser ces ports ouverts avec une adresse IP publique sans la moindre restriction d’accès IP ou filtrage, c’est accepter que n’importe qui puisse tenter sa chance. Pour canaliser ces flux d’administration de façon sécurisée, s’appuyer sur un bastion informatique reste l’une des approches les plus fiables.
Comment prévenir les risques de sécurité ?
La bonne nouvelle, c’est que protéger ses VMs ne demande pas un budget colossal ni des compétences de hacker éthique certifié. Quelques mesures bien placées suffisent à réduire la surface d’attaque de façon drastique.
Protection par pare-feu et restriction d’accès IP
Le strict minimum, c’est de configurer une protection par pare-feu qui limite les connexions entrantes aux seules adresses IP autorisées. Rien que ça élimine la quasi-totalité des attaques automatisées. Concrètement, vous configurez le firewall de la VM (ou celui de votre provider cloud) pour n’accepter que votre IP fixe. Si vous n’avez pas d’IP fixe ou que plusieurs personnes doivent se connecter depuis des endroits différents, un VPN fait le pont entre vos équipes et vos serveurs sans jamais exposer l’adresse IP publique au reste d’Internet.
Basculez sur des solutions d’accès sécurisé
Le RDP ou SSH en direct sur Internet, c’est une pratique d’un autre temps. Aujourd’hui, les alternatives ne manquent pas : bastion (jump host) dédié, passerelle VPN, solutions Zero Trust. Ces outils offrent un contrôle d’accès granulaire, avec de l’authentification forte et du logging détaillé, là où une connexion directe via IP publique ne vous donne aucune visibilité.
Pour l’hébergement web, la logique est la même. Un reverse proxy ou un service de publication sécurisé permet de n’exposer que les ports strictement nécessaires, avec un contrôle d’identité systématique en amont.
Que faire si une exposition accidentelle a déjà eu lieu ?
Si votre VM a été accessible publiquement ne serait-ce que quelques heures, partez du principe qu’elle a été scannée. Coupez immédiatement l’accès depuis Internet aux ports sensibles (RDP, SSH, MySQL, etc.) via le firewall ou la console de votre fournisseur cloud.
Ensuite, passez en mode investigation. Épluchlez les logs de connexion pour repérer toute activité suspecte. Changez l’ensemble des mots de passe. Mettez à jour tous les composants système. Et faites un scan complet de la machine pour détecter d’éventuels malwares ou backdoors installés pendant la période d’exposition. Si vous trouvez quoi que ce soit de suspect, le plus sûr reste de recréer la VM à partir d’un snapshot propre.
Bonnes pratiques pour renforcer la sécurité de vos VMs
La règle de base est simple : partez du principe qu’aucune VM ne devrait avoir d’adresse IP publique directement accessible, sauf besoin explicite et documenté. Préférez systématiquement les réseaux privés et les tunnels VPN.
Au quotidien, ça passe par des mises à jour régulières de vos systèmes et applications — idéalement automatisées via un script ou un outil de gestion de configuration. Activez l’authentification double facteur sur tous les accès administratifs sans exception, y compris SSH avec des clés et des passphrases robustes. Segmentez vos réseaux : si une VM tombe, elle ne doit pas entraîner les autres avec elle. Ne laissez jamais un port ouvert « par défaut » ; ouvrez uniquement ce dont vous avez besoin, le temps nécessaire, puis refermez. Et consultez vos logs de connexion régulièrement, avec des alertes automatiques sur les comportements anormaux.
Ces réflexes valent autant pour un serveur web en production que pour un backend applicatif interne.
Dans quels cas utiliser une adresse IP publique ?
Dans la grande majorité des cas, exposer une VM via une adresse IP publique n’a aucune justification face aux risques de sécurité que ça implique. Les infrastructures professionnelles misent sur l’isolation et les tunnels sécurisés. Seuls quelques fronts web durcis, monitorés en continu et protégés par plusieurs couches de sécurité, justifient une exposition directe.
Réserver une IP publique directement sur une VM devrait rester un dernier recours, limité à des cas très spécifiques : une démo temporaire, un sandbox sans données sensibles, des tests ponctuels sous surveillance. Pour tout le reste, isolez vos instances derrière des couches de protection solides. Vous aurez moins de surprises le lundi matin.
Fondateur d’Azertytech et passionné de high-tech et d’informatique, je rédige des articles sur le sujet depuis 2018. Éditeur de sites et consultant SEO, j’utilise ce site pour partager mon savoir et ma passion de l’informatique à travers des guides, tutoriels et analyses détaillées.
