Comment limiter l’accès entre deux bureaux reliés par VPN

Un tunnel de site à site répond à une question, si les deux bureaux peuvent échanger des paquets, et laisse la plus importante ouverte : quel équipement de l’agence peut atteindre quel service central. Traiter le tunnel comme une confiance mutuelle est la façon dont un portable invité finit sur le même chemin que le serveur financier. La solution n’est pas un meilleur tunnel, mais une liste d’autorisations explicite appliquée après le déchiffrement. Ce guide mène cette liste de la définition à un refus prouvé.

Travaillez dans cet ordre et n’élargissez pas la route du tunnel avant que les étapes de politique ci-dessous ne passent.

Écrivez la matrice avant de toucher à la passerelle

Une ligne utile nomme trois choses : un groupe source, un hôte ou réseau de service de destination, et le protocole et le port que l’application utilise réellement. L’agence et le centre de données ne sont pas des entrées. Le DNS privé et les services d’authentification méritent leurs propres lignes seulement lorsque l’application ne peut pas fonctionner sans eux.

Groupez les sources par rôle plutôt que par commodité de sous-réseau : personnel, invités, administration. Quand les trois partagent un LAN plat, la passerelle ne peut pas les distinguer au niveau réseau, donc les contrôles d’identité ou la segmentation doivent venir en premier. Ensuite, mettez la matrice par écrit avec un responsable et une date de revue sur chaque ligne.

Appliquez là où les paquets sont déchiffrés

Les règles qui autorisent IKE et ESP ne construisent que le tunnel extérieur. Le trafic interne arrive en clair sur l’interface du tunnel, et c’est là que va la liste d’autorisations : une chaîne de transfert sur l’équipement qui déchiffre, rejet par défaut, une règle par ligne de la matrice. Sur les passerelles Linux, cela signifie le transfert activé et des règles de filtrage sur l’équipement du tunnel, pas sur la liaison physique, comme l’explique le guide de transfert de strongSwan.

Les sélecteurs de trafic sont une décision de routage, pas d’autorisation. Un sélecteur large qui couvre les deux sous-réseaux peut être juste pour le routage alors que le pare-feu n’autorise toujours que TCP 443 vers un hôte. Le sélecteur est négocié pour le tunnel et décrit ce qui peut y entrer, non ce qu’un équipement donné peut utiliser. N’élargissez jamais une règle de pare-feu parce que le sélecteur est large.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT et sous-réseaux qui se chevauchent changent les règles

Quand la passerelle de l’agence traduit chaque hôte en une seule adresse avant le tunnel, chaque ligne fondée sur la source s’effondre dans cette adresse unique. Soit vous arrêtez de traduire le trafic du tunnel, soit vous acceptez que les règles doivent reposer sur autre chose, comme l’adresse source d’origine relevée avant la traduction. L’extrémité distante a le même problème, car l’hôte de destination voit l’adresse après NAT et non l’originale.

Les plages qui se chevauchent sont l’autre piège. Deux bureaux qui utilisent tous deux 192.168.1.0/24 ne peuvent pas être décrits dans une seule table de politique sans mapper un côté, et un mappage ne remplace pas un adressage qui n’entre pas en collision. Corrigez le plan avant d’écrire des règles qu’il faudra défaire plus tard.

Prouvez un refus, pas seulement un succès

Tester seulement l’application autorisée prouve très peu, car une règle permissive quelque part en amont produit le même résultat.

Depuis un équipement ordinaire de l’agence, atteignez le service prévu et confirmez que toute la session fonctionne. Essayez ensuite une destination qui doit rester fermée, comme un port administratif sur un serveur avec lequel l’agence n’a rien à faire, et lisez le compteur ou l’entrée de journal qui l’a rejetée. Désactiver le jeu de règles pour vérifier s’il fonctionne invalide le test et laisse la passerelle ouverte pendant que vous regardez.

Gardez la liste vivante

Les applications bougent, et une règle qui survit à son application devient un trou que personne ne possède. Attachez la date de revue à la ligne et changez la portée du sélecteur et la règle de pare-feu dans la même étape de maintenance quand un service change d’adresse.

Les restrictions au niveau de l’hôte comptent encore derrière le tunnel : le pare-feu du serveur lui-même ne devrait accepter la plage de l’agence que pour le service qu’il publie. Deux couches qui s’accordent sont plus faciles à auditer qu’une seule couche à laquelle on se fie entièrement.