![[back]](../../../images/back.gif){kind=small}
![[OpenBSD]](../../../images/smalltitle.gif){kind=small}
[Précédent : Traduction d'Adresses Réseau] [Index] [Suivant : Raccourcis pour la Création de Jeux de Règles]
Prenons un exemple :
rdr on tl0 proto tcp from any to any port 80 -> 192.168.1.20
La ligne ci-dessus redirige le trafic à destination du port TCP 80 (serveur web) vers une machine sur le réseau d'adresse IP 192.168.1.20. Ainsi, même si cette machine est derrière votre passerelle, le monde externe peut y avoir accès.
La partie from any to any de la ligne rdr précitée peut être assez utile. Si vous voulez restreindre les adresses ou les sous-réseaux autorisés à avoir accès au serveur web sur le port 80, vous pouvez le faire de la façon suivante :
rdr on tl0 proto tcp from 27.146.49.0/24 to any port 80 -> \
192.168.1.20
Ceci aura pour effet de rediriger uniquement le trafic en provenance du sous-réseau spécifié. Notez que cela implique la possibilité de rediriger différentes machines en entrée vers des machines derrière la passerelle. Une telle fonctionnalité est utile. Par exemple, vous pouvez autoriser des utilisateurs sur des sites distants à accèder à leur propre machine dans la mesure où vous connaissez leur adresse IP :
rdr on tl0 proto tcp from 27.146.49.14 to any port 80 -> \
192.168.1.20
rdr on tl0 proto tcp from 16.114.4.89 to any port 80 -> \
192.168.1.22
rdr on tl0 proto tcp from 24.2.74.178 to any port 80 -> \
192.168.1.23
Notez aussi que la traduction est effectuée avant le filtrage. Le moteur de filtrage verra le paquet traduit, ç.à.d. après que son adresse IP destination et/ou port de destination soient modifiés pour correspondre à l'adresse/au port de redirection spécifié(e) dans la règle rdr. Considérons le cas suivant :
Règle de redirection :
rdr on tl0 proto tcp from 192.0.2.1 to 24.65.1.13 port 80 \
-> 192.168.1.5 8000
Avant que la règle de redirection ne soit utilisée, le paquet est traité :
Puis la règle de redirection est évaluée :
Le moteur de filtrage verra le paquet IP tel qu'il apparaît après la traduction effectuée par le mécanisme de redirection.
Ces risques peuvent être minimisés en confinant de manière stricte le système accédé depuis l'extérieur à un réseau séparé. Ce réseau est souvent appelé zone démilitarisée (DMZ) ou réseau de service privé (Private Service Network, PSN). De cette façon, si le serveur web est compromis, les effets peuvent être limités au réseau DMZ/PSN en filtrant soigneusement le trafic autorisé entre DMZ/PSN et vos autres réseaux.
server = 192.168.1.40
rdr on $ext_if proto tcp from any to $ext_if port 80 -> $server \
port 80
Mais lorsque la règle de redirection est testée par un client du LAN, elle ne fonctionne pas. C'est normal car les règles de redirection ne s'appliquent qu'aux paquets qui passent à travers l'interface spécifiée dans chacune d'elles (dans l'exemple précité, c'est l'interface externe $ext_if). Cependant, une connexion émanant d'un client interne et à destination de l'adresse externe du pare-feu n'implique pas que les paquets vont passer à travers l'interface externe du pare-feu. La pile TCP/IP sur le pare- feu compare l'adresse de destination des paquets entrants avec ses propres adresses et aliases et détecte les connexions qui lui sont destinées lorsque les paquets constituant celles-ci passent son interface interne. De tels paquets ne passent pas physiquement à travers l'interface externe, et de toute façon la pile ne simule pas ce passage. Ainsi, PF ne voit jamais ces paquets sur l'interface externe. Du coup, la règle de redirection sur l'interface externe n'est jamais appliquée.
Que doit-on faire alors ? ajouter une seconde règle de redirection sur l'interface interne ? non, ça ne fonctionnera pas mieux. Lorsque le client local se connecte à l'interface externe du pare-feu, le paquet initial de l'échange TCP atteint le pare-feu via son interface interne. La nouvelle règle de redirection s'applique et l'adresse de destination est remplacée par celle du serveur interne. Le paquet et alors redirigé par l'interface interne du pare-feu vers le serveur interne. Mais l'adresse source n'a pas été modifiée. Elle contient l'adresse du client local. Le serveur envoie alors directement les réponses au client. Le pare-feu ne voit jamais le retour et n'a aucune chance de traduire correctement les paquets de retour. Le client reçoit une réponse à partir d'une source inattendue. Il met alors fin à cette connexion.
Cependant, il est souvent souhaitable que les clients sur le LAN se connectent au même serveur interne que les clients externes et de manière aussi transparente. Il existe plusieurs solutions à ce problème :
Il est possible de configurer les serveurs DNS pour fournir une réponse différente selon la provenance de la requête : clients internes ou externes. Ainsi les clients internes recevront l'adresse interne du serveur en réponse à leur demande de résolution de nom. Ils pourront alors se connecter directement au serveur local sans impliquer le pare-feu. Ce dernier sera alors moins sollicité.
Une autre solution consiste à ajouter une carte réseau au pare-feu et à déplacer le serveur local vers un réseau dédié de type DMZ. Les connexions des clients locaux seront alors redirigées de la même manière que les connexions en provenance d'Internet. L'utilisation de réseaux séparés a plusieurs avantages. Entre autres, une amélioration du niveau de sécurité en isolant le serveur des machines internes. Si le serveur (qui, nous le rappelons, est joignable d'Internet) est compromis, il ne peut se connecter à des machines internes directement vu que toutes ces connexions doivent passer à travers le pare-feu.
Un proxy TCP générique peut être mis en place sur le pare-feu. Ce proxy devra écouter sur le port de redirection ou accepter les connexions sur l'interface interne et redirigées sur le port sur lequel il écoute. Lorsqu'un client se connecte sur le pare-feu, le proxy accepte la connexion, établit une seconde connexion au serveur interne, et véhicule les données entre les deux connexions.
Des proxies simples peuvent être crées avec inetd(8) et nc(1). L'entrée suivante dans le fichier /etc/inetd.conf crée une socket d'écoute rattachée à l'adresse de loopback (127.0.0.1) et le port 5000. Les connexions sont redirigées sur le port 80 du serveur 192.168.1.10.
127.0.0.1:5000 stream tcp nowait nobody /usr/bin/nc nc -w \
20 192.168.1.10 80
La règle de redirection suivante redirige le port 80 sur l'interface interne du proxy :
rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \
127.0.0.1 port 5000
A l'aide d'une règle NAT supplémentaire sur l'interface interne, la traduction manquante d'adresse source décrite plus haut peut être réalisée.
rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \
$server
no nat on $int_if proto tcp from $int_if to $int_net
nat on $int_if proto tcp from $int_net to $server port 80 -> \
$int_if
Ceci aura pour effet d'effectuer une autre traduction d'adresse du paquet initial envoyé par le client lorsque celui-ci est redirigé à travers l'interface interne. Cette seconde opération de traduction remplacera l'adresse source du client par l'adresse interne du pare-feu. Le serveur interne répondra alors à l'adresse interne du pare-feu, qui effectuera les opérations de NAT et de RDR inverses avant de faire suivre le paquet au client. Cette méthode est relativement complexe. Elle crée deux états séparés pour chaque connexion redirigée. Il faut prendre des précautions pour éviter que la règle de NAT s'applique au reste du trafic tel que les connexions en provenance de hôtes externes (via d'autres redirections) ou en provenance du pare-feu lui-même. Il est à noter que la règle rdr précitée fera apparaître à la pile TCP/IP des paquets en provenance du réseau interne et à destination de ce dernier. Pour éviter que la pile envoie des messages de redirection ICMP (disant au client que la destination est directement joignable ce qui aura pour effet de casser la redirection), désactivez l'envoi de messages de redirection ICMP sur le pare- feu en utilisant
# sysctl -w net.inet.ip.redirect=0
# sysctl -w net.inet6.ip6.redirect=0 (if using IPv6)
Cependant, nous recommandons de privilégier plutôt les solutions précédemment mentionnées.
[Précédent : Traduction d'Adresses Réseau] [Index] [Suivant : Raccourcis pour la Création de Jeux de Règles]
www@openbsd.org