OBSD4* : wiki

Version de traduction basée sur la 6.2 officielle


PF - Redirection de Trafic (Port Forwarding)

Introduction

Lorsque vous faites fonctionner la NAT pour votre entreprise, vous avez internet entièrement disponible pour toutes vos machines. Que faire si vous avez une machine derrière la passerelle NAT qui a besoin d'être accessible depuis l’extérieur ? C'est là que la redirection entre en jeu. La redirection permet le trafic entrant à être envoyé à la machine derrière la passerelle NAT.

Voici un exemple :

  pass in on egress proto tcp from any to any port 80 rdr-to 192.168.1.20

Cette ligne redirige le trafic sur le port TCP 80 (serveur web) vers la machine à l'intérieur du réseau, ayant l'ip 192.168.1.20. Ainsi, même si 192.168.1.20 est derrière votre passerelle, à l'intérieur de votre réseau, l'extérieur y aura accès.

La partie from any to any de la ligne rdr ci-dessus peut être utile. Si vous savez quelles adresses ou sous-réseaux sont supposés avoir un accès au serveur web, sur le port 80, vous pouvez les restreindre :

  pass in on egress proto tcp from 203.0.113.0/24 to any port 80 rdr-to 192.168.1.20

Cela va rediriger seulement le sous-réseau spécifié. Notez que cela implique que vous pouvez rediriger différents hôtes entrants vers différentes machines derrière la passerelle. Cela peut être tout aussi bien utile. Par exemple, vous pourriez avoir des utilisateurs qui ont des accès à distance vers leurs stations informatiques, utilisant le même port et l'adresse IP de votre passerelle, tant que vous connaissez l'adresse IP à partir desquels ils se connecteront.

  pass in on egress proto tcp from 203.0.113.14 to any port 80 rdr-to 192.168.1.20
  pass in on egress proto tcp from 198.51.100.89 to any port 80 rdr-to 192.168.1.22
  pass in on egress proto tcp from 198.51.100.178 to any port 80 rdr-to 192.168.1.23

Un ensemble de ports peut aussi être redirigé de la même manière :

  pass in on egress proto tcp from any to any port 5000:5500 \
     rdr-to 192.168.1.20
  pass in on egress proto tcp from any to any port 5000:5500 \
     rdr-to 192.168.1.20 port 6000
  pass in on egress proto tcp from any to any port 5000:5500 \
     rdr-to 192.168.1.20 port 7000:*

Ces exemples montrent les ports 5 000 à 5 500 inclus redirigés vers 192.168.1.20. Dans la règle #1, le port 5 000 est redirigé vers le 5 000, le 5 001 vers le 5 001, etc. Dans la règle #2, la plage entière est redirigée vers le port 6 000. Et, dans la règle #3, le port 5 000 est redirigé vers le port 7 000, le 5 001 vers le 7 001, etc.

Implications de Sécurité

La redirection a des implications de sécurité. Ouvrir un trou dans le pare-feu pour permettre le trafic vers le réseau interne protégé est potentiellement une compromission de la machine interne. Si le trafic est redirigé vers un serveur web interne, et qu'une vulnérabilité est découverte dans le service du serveur web, la machine peut être compromise par un intrus depuis Internet. De là, l'intrus a une porte d'entrée vers le réseau interne, ce qui lui permet de passer au-travers du pare-feu.

Ces risques peuvent être minimisés en gardant les accès externes au système de manière confinée sur un réseau séparé. Ce réseau est souvent appelé Zone Démilitarisée (DMZ) ou Réseau de Service Privé (PSN). De cette manière, si le serveur web est compromis, les effets seront limités au réseau DMZ/PSN en filtrant soigneusement le trafic permis vers et depuis la DMZ/PSN.

Redirection et réflexion

Souvent, les règles de redirection sont utilisées pour rediriger les connexions entrantes depuis internet vers un serveur local avec une adresse privée depuis le réseau interne ou LAN, tel que :

  server = 192.168.1.40
  pass in on egress proto tcp from any to egress port 80 rdr-to $server port 80

Mais, quand la règle de redirection est testée depuis un client du LAN, cela ne fonctionne pas. La raison est que la règle de redirection s'applique seulement aux paquets qui passent au-travers de l'interface spécifiée (egress, l'interface externe, dans l'exemple). Se connecter à l'adresse externe du pare-feu depuis un hôte sur le LAN, toutefois ne signifie pas que les paquets passeront effectivement à-travers son interface externe. La pile TCP/IP du pare-feu compare l'adresse de destination des paquets entrants avec ses propres adresses, et alias, et détecte les connexions vers lui-même dès qu'ils passent l'interface interne. De tels paquets ne passent pas physiquement au-travers de l'interface externe, et la pile ne simule pas un tel passage, de toute manière. Ainsi, PF ne voit jamais ces paquets sur l'interface externe, et la règle de redirection, spécifiant l'interface externe, ne s'applique pas.

Ajouter une seconde règle de redirection pour l'interface interne n'aura pas l'effet désiré. Quand le client local se connecte à l'adresse externe du pare-feu, le paquet initial de la poignée de main TCP atteint le pare-feu au-travers de l'interface interne. La règle de redirection s'applique et l'adresse de destination est remplacée avec celle du serveur interne. Le paquet est redirigé vers l'interface interne et atteint le serveur interne. Mais l'adresse source n'est pas traduite, et contient toujours l'adresse du client local, ainsi le serveur envoie sa réponse directement au client. Le pare-feu ne verra jamais la réponse et n'a aucune chance d'inverser la traduction. Le client reçoit une réponse depuis la source inconnue et l'abandonne. La poignée de main TCP échoue alors et aucune connexion ne peut être établie.

Pourtant, il est souvent souhaitable pour les clients du LAN de se connecter à ce même serveur interne, et de le faire de manière transparente. Il y a plusieurs solutions à ce problème :

Split-horizon DNS

Il est possible de configurer les serveurs DNS pour répondre à des requêtes depuis des hôtes locaux différemment des requêtes externes de telle manière que les clients locaux reçoivent l'adresse du serveur interne durant la résolution de nom. Ils se connecteront directement au serveur local, et le pare-feu n'est pas du tout invoqué. Cela réduit le trafic local puisque les paquets ne sont pas envoyés au-travers du pare-feu.

Déplacer le serveur vers un réseau local séparé

Ajouter une interface réseau additionnelle au pare-feu et déplacer le serveur local de réseau des clients vers un réseau dédié (DMZ) permet de rediriger les connexions depuis les clients locaux de la même manière que s'ils étaient redirigés depuis la connexion externe. Utiliser des réseaux séparés a de sérieux avantages, incluant une sécurité améliorée par l'isolation du serveur depuis les hôtes locaux restants. Si jamais le serveur (qui dans notre cas est accessible depuis Internet) est compromis, les autres hôtes locaux ne seront pas directement accessibles, car toutes les connexions passent au-travers du pare-feu.

Mandataire TCP

Un mandataire TCP générique peut être paramétré sur le pare-feu, soit en écoutant sur le port à rediriger ou en obtenant les connexions depuis l'interface interne redirigeant vers le port qu'il écoute. Quand un client local se connecte au pare-feu, le mandataire accepte les connexions, établit une seconde connexion au serveur interne, et redirige les données entre ces deux connexions.

Combinaison RDR-TO et NAT-TO

Avec une règle NAT additionnelle sur l'interface interne, la traduction de l'adresse source de manquante décrite ci-dessus peut être atteinte.

  pass in on $int_if proto tcp from $int_net to egress port 80 rdr-to $server
  pass out on $int_if proto tcp to $server port 80 received-on $int_if nat-to $int_if

Cela aura pour effet que le paquet initial depuis le client sera encore traduit quand il sera redirigé au-travers de l'interface interne, remplaçant l'adresse source du client avec l'adresse interne du pare-feu. Le serveur interne répondra au pare-feu, inversant à la fois les traductions NAT et RDR lors de la redirection vers le client local. Cette construction est complexe, elle crée deux états séparés pour chaque connexion. Des précautions doivent être prises pour prévenir que la règle NAT s'applique à d'autres trafics, pour les instances de connexions depuis les hôtes externes (au-travers des redirections), ou le pare-feu lui-même. Notez que la règle rdr-to ci-dessus aura pour conséquence que la pile TCP/IP verra les paquets entrants sur l'interface interne avec une adresse de destination à l'intérieur du réseau interne.


Cette page est la traduction officieuse de la page “Traffic redirection (port forwarding)” de la FAQ officielle d'OpenBSD.
En cas de doute, merci de vous y référer !

Si vous voulez participer à l'effort de traduction, merci de lire ce topic.