La raison d'être de ces outils : lire les résultats, juger les avertissements et savoir quand un VPN est vraiment nécessaire

À quoi répond réellement chaque outil

Il est utile de répartir les seize outils de cette boîte à outils en quatre questions, car la bonne façon de lire un résultat dépend entièrement de la question à laquelle il répond. Ping et Traceroute répondent à « puis-je l'atteindre, et sinon, où le chemin se rompt-il » - pure connectivité, rien à voir avec la sécurité. DNS Lookup, Whois et GeoIP répondent à « qui est-ce, et où se trouve-t-il réellement » - identité et propriété, utile pour vérifier qu'une cible est bien ce qu'elle prétend être avant de lui faire confiance. Port Scan, HTTP Headers, SSL Checker et Blacklist Check répondent à « qu'est-ce que ce système expose au monde extérieur, et le devrait-il » - c'est le groupe qui touche réellement à la sécurité, et celui auquel cet article consacre le plus de temps. Le calculateur de sous-réseau, le test de vitesse et les deux dictionnaires de codes répondent à « combien, ou quelle taille » - pure information de capacité et de référence, sans aucun jugement de risque impliqué.

Savoir dans quelle catégorie se trouve un outil change la manière dont il faut réagir à son résultat. Un Traceroute montrant un saut qui n'obtient pas de réponse n'est pas une découverte de sécurité - il s'agit généralement d'un routeur configuré pour ignorer ICMP, ce qui n'a absolument rien à voir avec la question de savoir si quelque chose ne va réellement pas. Un Port Scan montrant un port ouvert, en revanche, est exactement le genre de résultat qui mérite l'attention du reste de cet article, car il vous dit quelque chose de réel sur ce qui est accessible depuis l'extérieur.

Lire un résultat sans sur-réagir ni sous-réagir

L'habitude la plus utile en lisant la sortie de n'importe lequel de ces outils est de comparer le résultat à ce que vous aviez réellement l'intention d'exposer - et non à un idéal imaginaire d'un système parfaitement verrouillé, qui n'existe pas et n'est de toute façon pas l'objectif. Un serveur web avec les ports 80 et 443 ouverts n'est pas une découverte ; c'est tout l'intérêt de faire tourner un serveur web. La question qui compte réellement est toujours « est-ce que cela correspond à ce que j'avais l'intention d'exposer », et non « est-ce que quelque chose est ouvert ou configuré ».

La majeure partie de ce que ces outils font remonter est informative plutôt qu'alarmante : un en-tête de sécurité optionnel manquant, un chiffrement TLS légèrement plus ancien encore proposé aux côtés de versions modernes pour des raisons de compatibilité, une fiche WHOIS avec la confidentialité activée - rien de tout cela n'est une urgence, et traiter chaque ligne de résultat avec la même urgence est précisément ce qui fait que les avertissements réels finissent noyés dans le bruit et ignorés. La compétence utile ici est le tri : lire l'ensemble du résultat une fois, classer mentalement chaque ligne en « attendu », « mérite un examen plus approfondi » ou « accessible depuis Internet et ne devrait pas l'être », et n'agir dans l'urgence que sur cette dernière catégorie.

Un avertissement est-il vraiment sérieux ? Un guide pratique

Quelques-uns des avertissements les plus courants, et le degré d'urgence que chacun mérite réellement. Un en-tête de sécurité manquant (Content-Security-Policy, Strict-Transport-Security) est réel mais rarement urgent en soi - c'est une lacune de durcissement, à corriger lors de la prochaine fenêtre de maintenance, pas un incendie à cinq alarmes, car il doit être combiné à une autre vulnérabilité pour être réellement exploitable. Un certificat TLS expiré ou sur le point de l'être est réellement urgent - il brise la confiance pour chaque visiteur dès qu'il expire, sans avertissement progressif pour les utilisateurs finaux, donc c'est un cas à corriger avant que cela n'arrive, pas après. Une inscription sur liste noire est urgente spécifiquement si le système concerné envoie des e-mails - le courrier cesse silencieusement d'arriver chez les grands fournisseurs en quelques heures, et la correction (identifier et supprimer la cause, puis demander le retrait de la liste) peut prendre plusieurs jours ; cela vaut donc la peine d'être vérifié de manière proactive plutôt que d'attendre qu'un client remarque que ses e-mails n'arrivent plus.

Un port ouvert est celui qui dépend le plus entièrement du contexte, ce qui explique pourquoi il a droit à sa propre section ci-dessous avec des exemples concrets plutôt qu'à une règle générale unique. En version courte : le même port ouvert peut être parfaitement normal sur un système et un problème sérieux sur un autre, purement en fonction du service concerné et de qui est censé pouvoir l'atteindre.

Ports ouverts : ce qui est normal et ce qui est un vrai risque

Trois grandes catégories couvrent presque tous les cas réels. Les ports destinés à être publics - 443 (HTTPS) et 80 (HTTP) sur tout ce qui héberge un site web - étant ouverts n'est absolument pas une découverte ; c'est le service qui fonctionne comme prévu, et un scan confirmant qu'ils sont accessibles est exactement ce qui devrait se produire. Les ports d'administration - 22 (SSH) et 3389 (RDP) sont les deux les plus fréquemment rencontrés - peuvent tout à fait rester ouverts spécifiquement pour les personnes qui en ont besoin, mais méritent un examen si un scan montre qu'ils sont accessibles depuis l'ensemble d'Internet plutôt que depuis un ensemble d'adresses connu et restreint ; la correction ici n'est pas nécessairement de les fermer, mais de restreindre qui peut les atteindre (une liste blanche de pare-feu, une authentification SSH par clé uniquement avec la connexion par mot de passe désactivée, ou faire passer l'accès entièrement derrière un VPN, ce qui est couvert plus bas). Les ports de bases de données et de services internes - 3306 (MySQL), 5432 (PostgreSQL), 27017 (MongoDB), et les protocoles hérités comme 23 (Telnet) sans aucun chiffrement - étant accessibles depuis Internet public n'est presque jamais intentionnel et presque toujours un vrai problème ; ils sont conçus pour être contactés par un serveur d'application situé à côté d'eux sur le même réseau privé, et non interrogés directement par n'importe qui sur Internet, et un nombre surprenant de véritables fuites de données remontent exactement à cela : une base de données laissée avec son port par défaut ouvert au monde entier, souvent parce qu'un groupe de sécurité cloud ou une règle de redirection de port d'un routeur domestique a été configuré négligemment et jamais revu.

La façon dont cela se produit réellement en pratique est presque toujours banale plutôt que malveillante : la fonctionnalité UPnP d'un routeur ouvre automatiquement un port pour une application et ne le referme jamais après la disparition de cet appareil ; un groupe de sécurité cloud est réglé sur « n'importe où » pendant les tests parce que c'est plus rapide que de configurer la bonne plage d'adresses IP, et le ticket pour le corriger plus tard n'est jamais déposé ; une base de données est mise en place pour un prototype rapide avec des identifiants et des paramètres réseau par défaut, et le prototype devient discrètement le système de production six mois plus tard. Rien de tout cela ne nécessite qu'un attaquant fasse preuve d'ingéniosité - il suffit simplement que personne ne vérifie ce qui est réellement accessible, ce qui est précisément la lacune qu'un scan de ports est conçu pour combler.

Quand un VPN est vraiment nécessaire (et quand il ne l'est pas)

Un VPN est l'outil approprié pour un problème récurrent bien précis : vous (ou un petit groupe de personnes identifiées) devez atteindre quelque chose - un panneau d'administration, un serveur SSH, un tableau de bord interne - depuis l'extérieur de son propre réseau, sans le rendre accessible à tout le monde sur Internet en même temps. Plutôt que de rediriger directement SSH ou RDP vers le monde entier puis d'essayer de le verrouiller avec des règles de pare-feu et fail2ban, le placer derrière un VPN le retire entièrement de la vue d'Internet public : personne ne peut même tenter de se connecter sans s'être d'abord authentifié sur le VPN, ce qui élimine la majeure partie du risque de port ouvert décrit ci-dessus avant même qu'une seule tentative de connexion n'ait lieu. Des options modernes comme WireGuard (couvert dans l'article « L'essor du VPN » de ce blog) rendent cela réellement simple à mettre en place, avec une fraction de la configuration et de la surface d'attaque des protocoles plus anciens comme PPTP ou IPsec.

Un VPN est tout aussi la bonne décision chaque fois qu'un appareil est régulièrement utilisé sur des réseaux non fiables - un café, une conférence, un aéroport - où n'importe qui d'autre sur le même WiFi peut potentiellement observer ou intercepter du trafic non chiffré ; faire passer ce trafic par un VPN élimine le réseau local comme point d'interception, ce qui est une menace réelle et courante, pas théorique. C'est également la méthode standard pour relier deux réseaux privés entre eux, par exemple le bureau d'une petite entreprise et ses serveurs cloud, sans exposer directement l'un ou l'autre à Internet entre les deux.

Là où un VPN n'est pas la solution : un service exposé publiquement et réellement mal configuré - une base de données sans authentification accessible depuis n'importe où, une application web avec une véritable vulnérabilité - ne devient pas plus sûr parce qu'un VPN tourne aussi ailleurs sur le réseau. Envelopper une serrure cassée dans une autre porte ne répare pas la serrure ; l'exposition réelle doit être corrigée à la source (authentification activée, port retiré de l'accès public, vulnérabilité corrigée), et le rôle d'un VPN est précisément de contrôler qui peut atteindre quelque chose qui n'est intentionnellement pas censé être entièrement public - pas de camoufler quelque chose qui fuit de toute façon.