NAT et filtrage IP source dans PF, en utilisant OpenBSD> = 4.7

Je viens de lire un livre sur PF (The Book Of PF, No Starch), mais il n'y a pas de question sans réponse.

Si j'ai une machine passerelle utilisant deux interfaces, $ int_if et $ ext_if, et que je NAT les packages provenant de $ int_if: net (qui est, disons, 10.0.0.0/24) à $ ext_if en utilisant match, quand obtient le NAT appliqué ? Avant ou après les règles de filtrage?

Exemple:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
pass out on $ext_if from 10.0.0.0/24
block drop out on $ext_if from 10.0.0.23

Est-ce que ça marche? Ou obtient l'IP source d'un paquet provenant de 10.0.0.23 NATed à l'adresse de $ ext_if avant que la vérification de sa provenance de 10.0.0.23 ne soit évaluée?

Ce schéma n'est pas utile pour répondre à cette question, je pense, mais il est néanmoins intéressant: [ http://www.benzedrine.cx/pf_flow.png ]

Si vous lisez la FAQ PF NAT [ http://www.openbsd.org/faq/pf/nat.html ], en particulier la section "Configurer NAT", vous rencontrerez ces phrases:

Lorsqu'un paquet est sélectionné par une règle de correspondance, les paramètres (par exemple nat-to) de cette règle sont mémorisés et sont appliqués au paquet lorsqu'une règle de passage correspondant au paquet est atteinte. Cela permet à une classe entière de paquets d'être gérée par une seule règle de correspondance, puis des décisions spécifiques sur l'autorisation du trafic peuvent être prises avec des règles de blocage et de passage.

Je pense que cela ne semble pas être comme je l'ai dit dans le paragraphe ci-dessus, donc l'IP source est "mémorisée" jusqu'à ce qu'il y ait une décision sur l'action à faire avec le paquet. Si la décision est prise, le NATting est appliqué.

Qu'est-ce que tu penses?

PS: C'est une question assez théorique. Si vous êtes un peu pragmatique, vous le ferez de cette façon:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
block drop from 10.0.0.23
# or, explicitly,
# block drop in on $int_if from 10.0.0.23

La blockrègle est donc déjà appliquée lorsque le paquet arrive sur $ int_if.

EDIT: Une autre possibilité est, bien sûr, de décider avant NAT:

pass from 10.0.0.0/24
block drop from 10.0.0.23
match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)

Si un paquet de .23 arrive, il correspond d'abord à la première règle, puis à la deuxième règle et à la troisième "règle". Mais comme la deuxième règle est la dernière à décider de passer / bloquer, le paquet est bloqué. Droite?

Oui, c'est assez théorique, ce que vous avez demandé, mais une question très intéressante.

La matchrègle sera appliquée lorsqu'elle agira sur la dernière règle correspondante. matchles règles sont "collantes", comme vous l'avez mentionné. Leur objectif principal est de pouvoir définir des choses comme une règle NAT une fois, et de ne pas avoir à mettre nat-to à la fin d'un tas de règles que vous avez sur le trafic sortant.

Dans votre exemple, le paquet sera abandonné. Je devrais regarder le code ou demander à Henning Brauer d'être certain s'ils sautent complètement la vérification NAT dans le cas de dépôt, mais cela ne sortirait pas NAT.

Je pense que votre règle est couverte par le Livre de PF (obtenu la 2e édition?), Mais je ne pense pas qu'ils soient explicites à ce sujet avec la règle de match.

Veuillez me corriger si je me trompais, vous voulez passer tous les paquets sortants de 10.0.0.0/24 mais vous voulez bloquer 10.0.0.23? Si c'est le cas, changez votre règle en:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
block drop out quick on $ext_if from 10.0.0.23
pass out on $ext_if from 10.0.0.0/24

Utilisez simplement quickpour empêcher le pare-feu de continuer le filtrage (similaire à breakdans certains langages de programmation).

http://www.openbsd.org/faq/pf/filter.html#quick

Le mot-clé rapide

Comme indiqué précédemment, chaque paquet est évalué par rapport à l'ensemble de règles de filtrage de haut en bas. Par défaut, le paquet est marqué pour le passage, qui peut être modifié par n'importe quelle règle, et pourrait être changé d'avant en arrière plusieurs fois avant la fin des règles de filtrage. La dernière règle de correspondance "gagne". Il existe une exception à cette règle: l'option rapide sur une règle de filtrage a pour effet d'annuler tout traitement de règle supplémentaire et entraîne l'exécution de l'action spécifiée. Regardons quelques exemples:

Faux:

block in on fxp0 proto tcp to port ssh
pass  in all 

Dans ce cas, la ligne de bloc peut être évaluée, mais n'aura jamais aucun effet, car elle est ensuite suivie d'une ligne qui passera tout.

Meilleur:

block in quick on fxp0 proto tcp to port ssh
pass  in all 

Ces règles sont évaluées un peu différemment. Si la ligne de blocage correspond, en raison de l'option rapide, le paquet sera bloqué et le reste de l'ensemble de règles sera ignoré.