Sécurité réseau : Security Groups, NACL et pare-feu cloud

Le filtrage réseau du cloud repose sur deux objets qui se ressemblent et ne fonctionnent pas pareil : le groupe de sécurité, attaché aux machines, et la liste de contrôle réseau, attachée au sous-réseau. Confondre les deux fait perdre des heures, parce qu'une règle écrite au mauvais endroit ne produit aucune erreur, seulement un silence. Cette page explique la différence, la politique par défaut à adopter, et l'erreur qui expose encore aujourd'hui des milliers de serveurs. Le lab se rejoue sans compte cloud.

Ce que vous allez apprendre

• Distinguer un filtrage à état d'un filtrage sans état, et savoir lequel vous utilisez.
• Écrire des règles qui n'ouvrent que ce qui doit l'être.
• Référencer un groupe depuis un autre, la technique qui remplace les listes d'adresses.
• Reconnaître la règle SSH ouverte au monde, et ce qu'elle coûte réellement.
• Diagnostiquer un blocage sans passer une heure sur le mauvais objet.

Prérequis

Les leçons sur le réseau privé et ses sous-réseaux et sur les tables de routage.

Deux objets, deux comportements

Le groupe de sécurité se souvient des connexions, la liste de contrôle réseau ne se souvient de rien. Cette phrase résume la seule différence qui compte au quotidien, et elle a des conséquences très concrètes.

	Groupe de sécurité	Liste de contrôle réseau
S'attache à	l'interface d'une machine	un sous-réseau entier
Mémoire des connexions	oui, il est à état	non, il est sans état
Règles de refus explicites	non, tout ce qui n'est pas autorisé est refusé	oui, l'ordre des règles compte
Portée	quelques machines	tout ce qui entre et sort du sous-réseau

Glissez pour voir

Ce que « à état » change en pratique : quand vous autorisez le trafic entrant sur le port 443, le groupe de sécurité laisse automatiquement repartir la réponse. Vous n'écrivez qu'une règle. Avec une liste de contrôle réseau, il faut deux règles, une pour l'aller et une pour le retour, sur les ports éphémères que le client a choisis. C'est la source classique du « ça marche dans un sens seulement ».

Lequel utiliser ? Le groupe de sécurité, dans la quasi-totalité des cas. La liste de contrôle réseau sert à poser un garde-fou large à l'échelle d'un sous-réseau, par exemple bloquer une plage d'adresses malveillantes pour tout le monde d'un coup. Commencez par les groupes, ajoutez des listes seulement quand vous avez un besoin qu'ils ne couvrent pas.

Le vocabulaire par fournisseur

Fournisseur	Filtrage à état	Filtrage sans état
AWS	Security Group	Network ACL
Azure	Network Security Group	pas d'équivalent séparé
Google Cloud	règles de pare-feu VPC, et les politiques hiérarchiques	pas d'équivalent séparé
OUTSCALE	Security Group	pas d'équivalent séparé
Scaleway	Security Group	pas d'équivalent séparé

Glissez pour voir

Notez que plusieurs fournisseurs n'exposent que le filtrage à état. C'est une simplification volontaire de leur part, et rarement un manque : le besoin d'un filtrage sans état est réel mais peu fréquent.

Attention à une confusion répandue au sujet de Google Cloud : ses règles de pare-feu VPC sont à état, et ses politiques hiérarchiques le sont également. Ces dernières n'ont donc rien d'un équivalent des listes de contrôle sans état d'AWS : leur apport est ailleurs, dans la possibilité d'imposer une politique au niveau de l'organisation ou d'un dossier, que les projets ne peuvent pas contourner.

Refuser par défaut, autoriser par exception

La politique par défaut du trafic entrant doit être « refuser ». C'est le réglage qui décide si votre sécurité repose sur ce que vous avez pensé à interdire, ou sur ce que vous avez explicitement autorisé. Seule la seconde approche tient dans la durée.

La raison est simple à formuler : vous ne pouvez pas énumérer tout ce qui est dangereux, alors que vous pouvez énumérer ce dont votre application a besoin. Un serveur web a besoin des ports 443 et éventuellement 80. Tout le reste, y compris le port d'administration de la base de données qu'un collègue installera dans six mois, doit être refusé sans que personne ait à y penser.

Pour le trafic sortant, l'arbitrage est différent. Le refus par défaut en sortie est plus sûr, et considérablement plus pénible : chaque mise à jour de paquets, chaque appel d'API externe, chaque résolution DNS demande une règle. Commencez par autoriser la sortie, et durcissez-la sur les machines qui traitent des données sensibles, une fois que vous savez précisément ce qu'elles contactent.

La règle qui expose encore des milliers de serveurs

0.0.0.0/0 sur le port 22, c'est-à-dire SSH ouvert au monde entier. C'est la règle la plus fréquemment trouvée en audit, et elle est presque toujours posée « temporairement, le temps de déboguer ».

Ce qui se passe ensuite est mécanique : les balayages automatisés trouvent le port ouvert en quelques minutes, et les tentatives d'authentification commencent aussitôt. Un mot de passe faible ou une clé partagée suffit alors.

Trois façons de faire mieux, par ordre de préférence :

• Un serveur de rebond (bastion), seule machine à accepter SSH, et depuis une plage d'adresses connue. Tout le reste n'est joignable que depuis lui.
• Un accès par le fournisseur, sans port ouvert du tout : la plupart proposent une console série ou un service de connexion qui passe par leur plan de contrôle.
• Une plage d'adresses restreinte, au minimum celle de votre entreprise ou de votre VPN, plutôt que le monde entier.

Si vous devez vraiment ouvrir SSH temporairement, écrivez la date de fermeture dans la description de la règle. Une règle sans échéance devient permanente.

Référencer un groupe plutôt qu'une plage

La technique la plus utile de tout ce chapitre : une règle peut autoriser un autre groupe de sécurité, au lieu d'une plage d'adresses. Elle est peu connue des débutants et change la façon de concevoir.

Prenons trois étages, un répartiteur de charge, des serveurs applicatifs, une base de données. La version naïve consiste à autoriser, sur la base, la plage 10.20.2.0/24 du sous-réseau applicatif. Elle fonctionne, et elle a deux défauts : elle autorise toute machine du sous-réseau, y compris celles qui n'ont rien à voir, et elle casse le jour où l'on ajoute un sous-réseau.

La version par référence dit : « la base accepte le port 5432 depuis le groupe de sécurité applicatif ». Une machine qui rejoint ce groupe obtient l'accès, une machine qui le quitte le perd, quelle que soit son adresse. La règle décrit un rôle, pas une topologie, et elle survit aux réorganisations d'adressage.

Approche	Règle sur la base	Ce qui se passe si l'on ajoute un sous-réseau
Par plage	autoriser 10.20.2.0/24 sur 5432	il faut penser à ajouter la nouvelle plage
Par référence	autoriser le groupe app sur 5432	rien à faire, l'appartenance suffit

Glissez pour voir

Lab : écrire des règles, sans compte cloud

1. Préparer l'environnement

   feint serve

   Puis, dans un second terminal :

   eval "$(feint env scaleway)"

2. Créer un groupe qui refuse tout en entrée

   scw instance security-group create name=lab-web description="front web" \
     inbound-default-policy=drop outbound-default-policy=accept

   ID                     adb022cd-c024-42f8-97a3-305f9ec0ac44
   Name                   lab-web
   InboundDefaultPolicy   drop
   OutboundDefaultPolicy  accept

   Les deux politiques par défaut sont posées dès la création : refus en entrée, autorisation en sortie. C'est le réglage recommandé plus haut.

3. Ouvrir uniquement HTTPS

   scw instance security-group create-rule security-group-id=<ID_DU_GROUPE> \
     protocol=TCP direction=inbound action=accept ip-range=0.0.0.0/0 dest-port-from=443

   Protocol      TCP
   Direction     inbound
   Action        accept
   IPRange       0.0.0.0/0
   DestPortFrom  443
   Position      1

   Ici, 0.0.0.0/0 est légitime : un site web public doit être joignable de partout. C'est sur le port 22 que la même plage devient un problème.

4. Restreindre l'administration à un réseau connu

   scw instance security-group create-rule security-group-id=<ID_DU_GROUPE> \
     protocol=TCP direction=inbound action=accept ip-range=10.20.1.0/24 dest-port-from=22

   IPRange       10.20.1.0/24
   DestPortFrom  22
   Position      2

   Comparez les deux champs IPRange. La différence entre une bonne et une mauvaise configuration tient dans cette seule valeur.

5. Relire l'ordre des règles

   scw instance security-group list-rules <ID_DU_GROUPE>

   Le champ Position donne l'ordre d'évaluation. Il compte dès qu'une règle de refus explicite entre en jeu.

Ce que ce lab ne prouve pas

Aucun paquet ne circule ici : l'émulateur enregistre vos règles et vous les rend, il ne filtre rien. Vous vérifiez que vous savez écrire la règle, pas qu'elle protège.

La vérification du filtrage réel demande une infrastructure où le trafic passe, et se fait en tentant une connexion qui doit échouer. C'est la seule preuve qui vaille, et les limites de l'émulateur le disent explicitement.

Diagnostiquer un blocage

Quand un flux ne passe pas, testez dans l'ordre du chemin, pas dans l'ordre de vos soupçons. Le chemin va de la route au filtrage, puis à l'application.

1. La route existe-t-elle ? Sans route, aucun filtrage n'entre en jeu. Voir la leçon précédente.

2. Le port écoute-t-il vraiment ? Sur la machine cible :

   ss -tlnp

   Un service qui n'écoute que sur 127.0.0.1 ne répondra jamais à personne, et aucune règle de pare-feu n'y changera rien. C'est une cause bien plus fréquente qu'on ne le croit.

3. Le filtrage laisse-t-il passer ? Depuis une machine autorisée :

   nc -zv 10.20.2.10 5432

   Une réponse immédiate de refus signale généralement que rien n'écoute ; un silence qui dure jusqu'au délai d'attente signale plutôt un filtrage.

Cette distinction entre refus immédiat et silence est le meilleur indice dont vous disposez. Un pare-feu qui jette les paquets ne répond rien, là où une machine sans service écoute répond tout de suite qu'il n'y a personne.

À retenir

• Le groupe de sécurité est à état : une règle entrante suffit, la réponse repart seule. La liste de contrôle réseau demande les deux sens.
• Le groupe s'attache à la machine, la liste au sous-réseau. Une règle écrite au mauvais endroit ne produit aucune erreur, juste un silence.
• Refusez tout en entrée par défaut, et n'ouvrez que ce dont l'application a besoin.
• Autorisez la sortie au départ, durcissez-la ensuite sur ce qui traite des données sensibles.
• 0.0.0.0/0 sur le port 22 est la règle la plus dangereuse du cloud. Un rebond, un accès par le fournisseur ou une plage restreinte font mieux.
• Référencez un groupe plutôt qu'une plage : la règle décrit alors un rôle, et survit aux changements d'adressage.
• Refus immédiat ou silence : cet indice sépare une panne de service d'un blocage de pare-feu.

Prochaines étapes

Connectivité hybride : VPN et interconnexion Relier ce réseau à un datacenter ou à un autre cloud, sans ouvrir de port.

Répartition de charge et TLS Exposer une application correctement, avec terminaison du chiffrement.

Gérer les identités et les accès Le filtrage réseau ne remplace pas le contrôle des permissions.

Sécurité cloud Replacer le filtrage réseau dans l'ensemble des mesures.

×

📖 Voir la documentation →