Inventorier les services exposés

Un serveur web peut écouter sur plusieurs ports, parfois pour des services que vous n’aviez pas prévu d’exposer. Si vous ne les identifiez pas avant de configurer le pare-feu, vous risquez soit de bloquer un accès nécessaire, soit de conserver une ouverture inutile. Vous allez dresser un inventaire vérifiable des services présents sur le serveur, sans modifier leur configuration.

Ce que vous devez relever

Un service réseau est un programme qui fournit une fonction accessible par le réseau, par exemple un serveur web ou un service d’administration à distance. Lorsqu’il accepte des connexions, il utilise un port d’écoute : une porte logique associée à un protocole et à une adresse réseau. Pour le projet fil rouge, vous devez donc relever les ports réellement utilisés par le serveur, puis déterminer lesquels correspondent aux besoins de l’application et de son administration.

Les ports 80 et 443 sont couramment associés respectivement au trafic web HTTP et HTTPS, et le port 22 est couramment utilisé par SSH. Ce sont des repères, pas une preuve de la configuration de votre machine : un service peut employer un port différent, ou ne pas être actif. Vérifiez toujours le port effectivement en écoute et le besoin opérationnel avant de prévoir une règle.

Afficher les ports en écoute

Depuis votre session SSH, lancez ss avec les options ci-dessous. La commande demande les sockets en écoute, affiche les ports numériques sans conversion en noms de services et tente d’associer les sockets TCP et UDP aux processus. L’option sudo permet généralement de voir davantage d’informations sur ces processus.

sudo ss -lntup

Dans les options, -l sélectionne les sockets en écoute, -n conserve les ports sous forme numérique, -t affiche TCP, -u affiche UDP et -p demande le nom du processus. Vous pouvez rencontrer des lignes TCP et UDP associées au même numéro de port : consignez-les séparément, car le protocole fait partie de ce que vous devez vérifier. Si votre système ne fournit pas l’association au processus, relancez la commande avec les privilèges d’administration.

Lire le résultat et vérifier les besoins

Les colonnes locales indiquent l’adresse et le port auxquels le serveur écoute. Une adresse telle que 0.0.0.0:80 indique une écoute sur toutes les interfaces IPv4, tandis que 127.0.0.1:8080 correspond à une écoute limitée à l’interface locale. Le nom du processus, lorsqu’il est affiché, vous aide à relier le port au service ; vérifiez son rôle au lieu de vous fier uniquement au numéro.

Netid  State  Local Address:Port  Process
 tcp   LISTEN  0.0.0.0:22          sshd
 tcp   LISTEN  0.0.0.0:80          nginx
 tcp   LISTEN  0.0.0.0:443         nginx
 tcp   LISTEN  127.0.0.1:8080      application

Dans cet exemple, SSH écoute sur 22, nginx sur 80 et 443, tandis que l’application écoute sur 8080 uniquement en local. Cela ne signifie pas que vous devez ouvrir chacun de ces ports au réseau : un port accessible seulement depuis l’interface locale n’a pas nécessairement besoin d’une ouverture entrante externe. Confirmez avec l’administrateur de l’application quels accès doivent venir d’autres machines et lesquels restent internes au serveur.

Pour chaque ligne, notez le protocole, le port, le processus, l’adresse d’écoute et la raison d’usage. Faites ensuite confirmer si l’accès doit être disponible depuis le réseau externe, depuis un réseau d’administration seulement, ou uniquement en local. Un inventaire des ports utiles est cette liste argumentée : il distingue les services observés des accès réellement requis, sans encore appliquer de filtrage.

À retenir

• Relevez les sockets en écoute avec sudo ss -lntup et identifiez, quand c’est possible, leur processus.
• Consignez le protocole, le port et l’adresse d’écoute ; un numéro de port seul ne décrit pas tout l’accès.
• Confirmez le besoin de chaque service avant de le considérer comme utile à l’application ou à son administration.
• Distinguez une écoute locale d’une écoute sur les interfaces réseau et ne modifiez pas encore le pare-feu.

Dans la prochaine leçon, vous utiliserez cet inventaire pour choisir une politique par défaut adaptée, sans confondre la politique générale et les règles qui autorisent des accès précis.