IPv4, IPv6 et pare-feu : examinez les chemins d'accès à votre serveur
Un service peut être joignable via plusieurs familles d'adresses et plusieurs couches réseau. Restreindre un port IPv4 ne prouve pas que le même service est restreint via IPv6. Basez l'examen sur les chemins qui existent réellement, y compris les DNS, les écouteurs, les règles d'hôte et tout contrôle en amont.
L'essentiel à retenir
Inventoriez les deux familles d'adresses, n'exposez que les services prévus, préservez le trafic de contrôle nécessaire au réseau et testez l'accès depuis l'extérieur du serveur après chaque changement pertinent.
Commencez par les services et les adresses, pas par une liste de règles
Listez chaque service exposé publiquement, le transport qu'il utilise, son port d'écoute et le public qui doit y accéder. Une application web, une interface d'administration et une base de données nécessitent généralement une exposition différente. Notez les adresses réellement attribuées au serveur et les interfaces sur lesquelles chaque processus écoute. Un processus lié à une adresse de bouclage a une frontière prévue différente de celle d'un processus écoutant sur toutes les interfaces disponibles.
Incluez IPv4 et IPv6 dans le même inventaire, tout en distinguant leurs adresses et leur gestion de politique. Un DNS public peut diriger les visiteurs vers IPv4 via un enregistrement A et vers IPv6 via un enregistrement AAAA. La présence ou l'absence d'un enregistrement ne remplace pas la vérification du service lui-même. Une personne qui connaît déjà une adresse peut l'atteindre sans utiliser le nom d'hôte que vous attendiez.
HM Bastion décrit l'allocation IPv6 comme dépendante de la disponibilité du pool d'adresses. Confirmez l'allocation et la configuration du service réel avant de planifier en conséquence. Les options IPv4 supplémentaires sont distinctes du nombre de ports applicatifs exposés : une autre adresse ne constitue ni un pare-feu ni un substitut à l'authentification applicative. Indiquez les exigences réseau dans la commande ou le brief de support plutôt que de supposer qu'une disposition d'adresses particulière découle d'un nom de gamme.
Suivez la politique à travers chaque couche qui traite le trafic
Une connexion peut traverser les contrôles réseau du fournisseur, un pare-feu hôte, un réseau de conteneurs, un proxy inverse et les contrôles d'accès propres à l'application. Documentez les couches présentes dans votre déploiement et qui gère chacune. Deux contrôles utiles peuvent se compléter, mais ils peuvent aussi rendre une panne difficile à localiser lorsque leurs règles ne sont pas consignées. Une configuration hôte ne doit pas dépendre d'une restriction en amont qui n'a jamais été confirmée.
| Couche | Question à résoudre | Test utile |
|---|---|---|
| DNS et adresses publiques | Quelles destinations les clients peuvent-ils découvrir ou déjà connaître ? | Inspectez les réponses A et AAAA prévues |
| Processus en écoute | Quelles adresses et quels transports acceptent les connexions ? | Vérifiez la configuration du service et les écouteurs actifs |
| Politique réseau et hôte | Quelles sources peuvent atteindre chaque service ? | Testez les chemins autorisés et refusés depuis l'extérieur |
| Application | Qui peut effectuer une action après connexion ? | Vérifiez l'authentification et l'autorisation avec des comptes de test |
Si vous utilisez un gestionnaire de pare-feu, vérifiez comment il traite les deux familles d'adresses dans la configuration installée. Consultez la documentation de l'outil et de la distribution plutôt que de supposer des valeurs par défaut identiques partout. Les plateformes de conteneurs peuvent ajouter leurs propres règles de réseau et de filtrage : un port de conteneur publié mérite donc un examen explicite. Ne prenez pas l'état apparent d'une commande familière comme preuve du chemin complet vers la charge de travail.
Privilégiez une politique restreinte qui correspond à l'inventaire. Le trafic web public peut provenir de nombreuses sources, tandis que l'accès administratif peut, lorsque c'est possible, s'appuyer sur une politique de sources plus étroite. Les bases de données et les points de terminaison de gestion interne n'ont souvent pas besoin d'un accès public direct. Conservez un chemin d'accès de secours pendant la modification des règles, et vérifiez une seconde session autorisée avant de fermer la seule connexion administrative fonctionnelle.
Évitez de casser le réseau en cherchant à réduire l'exposition
IPv6 s'appuie sur ICMPv6 pour des fonctions qui vont au-delà d'un simple test d'écho. Une règle générale qui supprime tout ICMPv6 peut perturber un comportement réseau nécessaire, notamment la découverte et la gestion des erreurs liées à l'acheminement des paquets. Les recommandations de filtrage du IETF distinguent les types de messages et le rôle des différentes frontières. Suivez les recommandations adaptées à l'environnement plutôt que de copier un ensemble de règles inexpliqué qui traite chaque message de contrôle comme hostile.
Un réseau qui semble fonctionner pour une petite requête peut échouer pour d'autres tailles de trafic ou d'autres chemins. Testez de véritables échanges applicatifs, et pas seulement l'ouverture d'un port. Comparez le comportement depuis des réseaux qui prennent en charge la famille d'adresses visée, et conservez l'heure et la destination exactes lors du diagnostic d'un problème. Un test IPv6 échoué depuis un client sans chemin IPv6 utilisable n'apprend pas grand-chose sur la configuration applicative du serveur.
L'atténuation DDoS et l'exposition des services répondent aussi à des problèmes différents. L'atténuation peut réduire le trafic d'attaque, tandis qu'une politique de pare-feu définit l'accessibilité réseau autorisée à sa frontière. Ni l'une ni l'autre ne remplace des comptes applicatifs sécurisés, des mises à jour ou une gestion prudente des secrets. Un panneau d'administration exposé peut représenter un risque même lorsque sa consommation de bande passante est minime. Vérifiez ce qu'une connexion autorisée est en droit de faire après avoir atteint le service.
Testez la frontière visée et conservez un chemin de retour arrière
- Consignez les règles actuelles, la politique visée et la méthode d'accès de secours.
- Appliquez une modification restreinte pendant une fenêtre de maintenance appropriée.
- Testez les connexions autorisées et refusées pour chaque famille d'adresses concernée.
- Vérifiez le site web normal et les dépendances internes requises.
- Consignez la politique finale et supprimez les exceptions de diagnostic temporaires.
Par exemple, après avoir placé une interface d'administration derrière un accès restreint, vérifiez qu'un opérateur approuvé peut toujours se connecter et qu'un chemin externe ordinaire ne le peut pas. Répétez cette vérification pour chaque famille publique attribuée sur laquelle l'interface écoute. Effectuez ces tests uniquement sur des systèmes que vous exploitez ou que vous êtes autorisé à tester. L'objectif est de vérifier une frontière définie, et non de générer des scans étendus vers des adresses sans rapport.
Revenez à l'inventaire après la publication d'une nouvelle application, l'activation de IPv6, l'ajout d'une plateforme de conteneurs ou la modification de proxys. Ces changements peuvent introduire un nouveau service à l'écoute sans modifier de manière évidente l'ancienne liste de règles. Un court enregistrement reliant service, adresse, port, responsable et public autorisé accélère les vérifications futures et réduit la dépendance à la dernière personne ayant modifié le pare-feu.
