Bonjour,
je me pose des questions sur le cheminement des paquets dans netfilter.
Question 1:
imaginons tout ouvert a la base (pas de regles, politique en ACCEPT)
Supposons un paquet local, comme:
ping 127.0.0.1
iptables -t nat -P POSTROUTING DROP
va me bloquer le paquet; pourquoi un paquet local doit passer en
POSTROUTING?
Pour etre (eventuellement) altere? Je croyais que c'etait la chaine
-t nat OUTPUT qui s'en chargeait?
et un iptables -t nat -P OUTPUT DROP ne bloque pas le paquet
Le man dit que OUTPUT: altering locally-generated packet before
routing. Ok. mais alors il devrait le bloquer: le paquet est fait au
niveau ICMP qui l'envoie a IP, et la pas le droit de lire la table de
routage puisque ma chaine l'interdit. Mais il passe.
Alors que POSTROUTING: altering packet as they are about to go out.
ICMP envoie le ping, niveau 2 IP, la table de routage est lue, et le
paquet remonte sur lo immediatement, pas besoin de sortir. Mais il est
bloque?! Alors a quel niveau travaille POSTROUTING?
Deuxieme question:
Par defaut, je charge mon firewall par des policy en DROP pour les
tables filter (puis j'autorise au cas par cas).
Dois-je faire de meme pour les tables nat et mangle? J'ai du mal a
cerner l'impact du fait de laisser mes politiques pour nat et mangle
en ACCEPT? Comment un pirate pourrait il jouer sur cette permissivite?
Il se ferait bloquer au niveau du -t filter FORWARD non?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Cedric Blancher
Le Thu, 09 Dec 2004 12:59:53 +0000, Kevin Denis a écrit :
Supposons un paquet local, comme: ping 127.0.0.1 iptables -t nat -P POSTROUTING DROP va me bloquer le paquet; pourquoi un paquet local doit passer en POSTROUTING?
Parce que c'est la dernière chaîne par laquelle passe tous les packets émis, même à destination de localhost.
Pour etre (eventuellement) altere? Je croyais que c'etait la chaine -t nat OUTPUT qui s'en chargeait?
En OUTPUT, tu pourras faire des opération de DNAT, pas de SNAT qui doivent être faits en POSTROUTING.
et un iptables -t nat -P OUTPUT DROP ne bloque pas le paquet
Selon comment est compilé ton noyau, i.e. avec ou sans l'option de NAT des connexions locale, l'OUTPUT en table nat peut ne pas avoir d'effet. Sur mon noyau qui est compilé avec cette option (qui va être activée et non désactivable dans le prochain 2.6) :
:~$ sudo iptables -t nat -P OUTPUT DROP :~$ ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes ping: sendto: Operation not permitted ping: sendto: Operation not permitted ping: sendto: Operation not permitted ping: sendto: Operation not permitted --- 127.0.0.1 ping statistics --- 0 packets transmitted, 0 packets received, :~$ sudo iptables -t nat -P OUTPUT ACCEPT :~$ ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttld time=0.090 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttld time=0.088 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.079 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttld time=0.079 ms --- 127.0.0.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.079/0.084/0.090/0.000 ms
CQFD.
Alors a quel niveau travaille POSTROUTING?
"out" ne veux pas forcément dire "sur le câble qui sort de ma machine". Quand tu fais passer un paquet par l'interface de loopback, il passe en OUTPUT, puis en POSTROUTING (émission sur lo) et puis après on le retrouve (réception sur lo) en PREROUTING et en INPUT.
De même, "in" ne veut pas dire "qui arrive par le câble qui entre sur ma machine"...
Deuxieme question: Par defaut, je charge mon firewall par des policy en DROP pour les tables filter (puis j'autorise au cas par cas). Dois-je faire de meme pour les tables nat et mangle?
Non. La table filter est faite pour filtrer, pas les autres. C'est pour ça qu'elle s'appelle filter et pas les autres ;)
J'ai du mal a cerner l'impact du fait de laisser mes politiques pour nat et mangle en ACCEPT? Comment un pirate pourrait il jouer sur cette permissivite? Il se ferait bloquer au niveau du -t filter FORWARD non?
Ben oui. Comme tous les paquets passent par une des chaînes de la table filter, tu as toujours un endroit pour bloquer le flux.
Il y a certains cas extrêmement pointus, en particulier ce qui est DNAT qui sont difficiles à gérer, mais ça se règle en marquant les paquets. Genre un DNAT vers une IP interne. En FORWARD, tu ne sais pas si le gars a initialement demandé l'IP interne ou l'IP qui subit le NAT.
-- «je copie le fichier rpm dans un répertoire et l'installe, maintenant je ne sais pas lancer l'appli car elle ne s'est pas mise dans le menu "Démarrer-Programmes".» -+- Stéph in Guide du linuxien pervers : "install.exe il est ou?" -+-
Le Thu, 09 Dec 2004 12:59:53 +0000, Kevin Denis a écrit :
Supposons un paquet local, comme:
ping 127.0.0.1
iptables -t nat -P POSTROUTING DROP
va me bloquer le paquet; pourquoi un paquet local doit passer en
POSTROUTING?
Parce que c'est la dernière chaîne par laquelle passe tous les packets
émis, même à destination de localhost.
Pour etre (eventuellement) altere? Je croyais que c'etait la chaine -t
nat OUTPUT qui s'en chargeait?
En OUTPUT, tu pourras faire des opération de DNAT, pas de SNAT qui
doivent être faits en POSTROUTING.
et un iptables -t nat -P OUTPUT DROP ne bloque pas le paquet
Selon comment est compilé ton noyau, i.e. avec ou sans l'option de NAT
des connexions locale, l'OUTPUT en table nat peut ne pas avoir d'effet.
Sur mon noyau qui est compilé avec cette option (qui va être activée
et non désactivable dans le prochain 2.6) :
cbr@anduril:~$ sudo iptables -t nat -P OUTPUT DROP
cbr@anduril:~$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
--- 127.0.0.1 ping statistics ---
0 packets transmitted, 0 packets received,
cbr@anduril:~$ sudo iptables -t nat -P OUTPUT ACCEPT
cbr@anduril:~$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttld time=0.090 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttld time=0.088 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.079 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttld time=0.079 ms
--- 127.0.0.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.079/0.084/0.090/0.000 ms
CQFD.
Alors a quel niveau travaille POSTROUTING?
"out" ne veux pas forcément dire "sur le câble qui sort de ma machine".
Quand tu fais passer un paquet par l'interface de loopback, il passe en
OUTPUT, puis en POSTROUTING (émission sur lo) et puis après on le
retrouve (réception sur lo) en PREROUTING et en INPUT.
De même, "in" ne veut pas dire "qui arrive par le câble qui entre sur ma
machine"...
Deuxieme question:
Par defaut, je charge mon firewall par des policy en DROP pour les
tables filter (puis j'autorise au cas par cas). Dois-je faire de meme
pour les tables nat et mangle?
Non. La table filter est faite pour filtrer, pas les autres. C'est pour
ça qu'elle s'appelle filter et pas les autres ;)
J'ai du mal a cerner l'impact du fait de laisser mes politiques pour nat
et mangle en ACCEPT? Comment un pirate pourrait il jouer sur cette
permissivite? Il se ferait bloquer au niveau du -t filter FORWARD non?
Ben oui. Comme tous les paquets passent par une des chaînes de la table
filter, tu as toujours un endroit pour bloquer le flux.
Il y a certains cas extrêmement pointus, en particulier ce qui est DNAT
qui sont difficiles à gérer, mais ça se règle en marquant les paquets.
Genre un DNAT vers une IP interne. En FORWARD, tu ne sais pas si le gars a
initialement demandé l'IP interne ou l'IP qui subit le NAT.
--
«je copie le fichier rpm dans un répertoire et l'installe, maintenant
je ne sais pas lancer l'appli car elle ne s'est pas mise dans le menu
"Démarrer-Programmes".»
-+- Stéph in Guide du linuxien pervers : "install.exe il est ou?" -+-
Le Thu, 09 Dec 2004 12:59:53 +0000, Kevin Denis a écrit :
Supposons un paquet local, comme: ping 127.0.0.1 iptables -t nat -P POSTROUTING DROP va me bloquer le paquet; pourquoi un paquet local doit passer en POSTROUTING?
Parce que c'est la dernière chaîne par laquelle passe tous les packets émis, même à destination de localhost.
Pour etre (eventuellement) altere? Je croyais que c'etait la chaine -t nat OUTPUT qui s'en chargeait?
En OUTPUT, tu pourras faire des opération de DNAT, pas de SNAT qui doivent être faits en POSTROUTING.
et un iptables -t nat -P OUTPUT DROP ne bloque pas le paquet
Selon comment est compilé ton noyau, i.e. avec ou sans l'option de NAT des connexions locale, l'OUTPUT en table nat peut ne pas avoir d'effet. Sur mon noyau qui est compilé avec cette option (qui va être activée et non désactivable dans le prochain 2.6) :
:~$ sudo iptables -t nat -P OUTPUT DROP :~$ ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes ping: sendto: Operation not permitted ping: sendto: Operation not permitted ping: sendto: Operation not permitted ping: sendto: Operation not permitted --- 127.0.0.1 ping statistics --- 0 packets transmitted, 0 packets received, :~$ sudo iptables -t nat -P OUTPUT ACCEPT :~$ ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttld time=0.090 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttld time=0.088 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.079 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttld time=0.079 ms --- 127.0.0.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.079/0.084/0.090/0.000 ms
CQFD.
Alors a quel niveau travaille POSTROUTING?
"out" ne veux pas forcément dire "sur le câble qui sort de ma machine". Quand tu fais passer un paquet par l'interface de loopback, il passe en OUTPUT, puis en POSTROUTING (émission sur lo) et puis après on le retrouve (réception sur lo) en PREROUTING et en INPUT.
De même, "in" ne veut pas dire "qui arrive par le câble qui entre sur ma machine"...
Deuxieme question: Par defaut, je charge mon firewall par des policy en DROP pour les tables filter (puis j'autorise au cas par cas). Dois-je faire de meme pour les tables nat et mangle?
Non. La table filter est faite pour filtrer, pas les autres. C'est pour ça qu'elle s'appelle filter et pas les autres ;)
J'ai du mal a cerner l'impact du fait de laisser mes politiques pour nat et mangle en ACCEPT? Comment un pirate pourrait il jouer sur cette permissivite? Il se ferait bloquer au niveau du -t filter FORWARD non?
Ben oui. Comme tous les paquets passent par une des chaînes de la table filter, tu as toujours un endroit pour bloquer le flux.
Il y a certains cas extrêmement pointus, en particulier ce qui est DNAT qui sont difficiles à gérer, mais ça se règle en marquant les paquets. Genre un DNAT vers une IP interne. En FORWARD, tu ne sais pas si le gars a initialement demandé l'IP interne ou l'IP qui subit le NAT.
-- «je copie le fichier rpm dans un répertoire et l'installe, maintenant je ne sais pas lancer l'appli car elle ne s'est pas mise dans le menu "Démarrer-Programmes".» -+- Stéph in Guide du linuxien pervers : "install.exe il est ou?" -+-
T0t0
"Kevin Denis" wrote in message news:
je me pose des questions sur le cheminement des paquets dans netfilter.
Déjà, ce shéma devrait t'aider (si jamais il sort bien formaté :-)
--->PRE------>[ROUTE]--->FWD---------->POST------> Conntrack | Mangle ^ Mangle Mangle | Filter | NAT (Src) NAT (Dst) | | Conntrack (QDisc) | [ROUTE] v | IN Filter OUT Conntrack | Conntrack ^ Mangle | Mangle | NAT (Dst) v | Filter
Supposons un paquet local, comme: ping 127.0.0.1 iptables -t nat -P POSTROUTING DROP va me bloquer le paquet; pourquoi un paquet local doit passer en POSTROUTING?
Ben parceque tout paquet passe par la couche 3 et la table de routage (mentionnée par ROUTE sur le schéma) donc après ce passage, il est en postrouting.
Pour etre (eventuellement) altere? Je croyais que c'etait la chaine -t nat OUTPUT qui s'en chargeait? et un iptables -t nat -P OUTPUT DROP ne bloque pas le paquet
Tu ne fais pas de filtrage dans la table nat hein, parceque comme son nom l'indique, elle est là pour la nat... pas pour filtrer. Essaye plutôt iptables -t filter -P OUTPUT DROP
Alors que POSTROUTING: altering packet as they are about to go out. ICMP envoie le ping, niveau 2 IP,
niveau 3.
la table de routage est lue, et le paquet remonte sur lo immediatement, pas besoin de sortir. Mais il est bloque?! Alors a quel niveau travaille POSTROUTING?
Comme son nom l'indique, après le routage, mais pas pour filtrer, pour faire de la nat.
Deuxieme question: Par defaut, je charge mon firewall par des policy en DROP pour les tables filter (puis j'autorise au cas par cas). Dois-je faire de meme pour les tables nat et mangle?
Nop, elles ne sont pas là pour filtrer.
J'ai du mal a cerner l'impact du fait de laisser mes politiques pour nat et mangle en ACCEPT? Comment un pirate pourrait il jouer sur cette permissivite? Il se ferait bloquer au niveau du -t filter FORWARD non?
Yep, ou INPUT ou OUTPUT.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Kevin Denis" <kevin@nowhere.invalid> wrote in message
news:slrncrh3bp.1rp.kevin@zipslack.local.tux
je me pose des questions sur le cheminement des paquets dans netfilter.
Déjà, ce shéma devrait t'aider (si jamais il sort bien formaté :-)
--->PRE------>[ROUTE]--->FWD---------->POST------>
Conntrack | Mangle ^ Mangle
Mangle | Filter | NAT (Src)
NAT (Dst) | | Conntrack
(QDisc) | [ROUTE]
v |
IN Filter OUT Conntrack
| Conntrack ^ Mangle
| Mangle | NAT (Dst)
v | Filter
Supposons un paquet local, comme:
ping 127.0.0.1
iptables -t nat -P POSTROUTING DROP
va me bloquer le paquet; pourquoi un paquet local doit passer en
POSTROUTING?
Ben parceque tout paquet passe par la couche 3 et la table de routage
(mentionnée par ROUTE sur le schéma) donc après ce passage, il est en
postrouting.
Pour etre (eventuellement) altere? Je croyais que c'etait la chaine
-t nat OUTPUT qui s'en chargeait?
et un iptables -t nat -P OUTPUT DROP ne bloque pas le paquet
Tu ne fais pas de filtrage dans la table nat hein, parceque comme
son nom l'indique, elle est là pour la nat... pas pour filtrer.
Essaye plutôt
iptables -t filter -P OUTPUT DROP
Alors que POSTROUTING: altering packet as they are about to go out.
ICMP envoie le ping, niveau 2 IP,
niveau 3.
la table de routage est lue, et le
paquet remonte sur lo immediatement, pas besoin de sortir. Mais il est
bloque?! Alors a quel niveau travaille POSTROUTING?
Comme son nom l'indique, après le routage, mais pas pour filtrer, pour
faire de la nat.
Deuxieme question:
Par defaut, je charge mon firewall par des policy en DROP pour les
tables filter (puis j'autorise au cas par cas).
Dois-je faire de meme pour les tables nat et mangle?
Nop, elles ne sont pas là pour filtrer.
J'ai du mal a
cerner l'impact du fait de laisser mes politiques pour nat et mangle
en ACCEPT? Comment un pirate pourrait il jouer sur cette permissivite?
Il se ferait bloquer au niveau du -t filter FORWARD non?
Yep, ou INPUT ou OUTPUT.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
je me pose des questions sur le cheminement des paquets dans netfilter.
Déjà, ce shéma devrait t'aider (si jamais il sort bien formaté :-)
--->PRE------>[ROUTE]--->FWD---------->POST------> Conntrack | Mangle ^ Mangle Mangle | Filter | NAT (Src) NAT (Dst) | | Conntrack (QDisc) | [ROUTE] v | IN Filter OUT Conntrack | Conntrack ^ Mangle | Mangle | NAT (Dst) v | Filter
Supposons un paquet local, comme: ping 127.0.0.1 iptables -t nat -P POSTROUTING DROP va me bloquer le paquet; pourquoi un paquet local doit passer en POSTROUTING?
Ben parceque tout paquet passe par la couche 3 et la table de routage (mentionnée par ROUTE sur le schéma) donc après ce passage, il est en postrouting.
Pour etre (eventuellement) altere? Je croyais que c'etait la chaine -t nat OUTPUT qui s'en chargeait? et un iptables -t nat -P OUTPUT DROP ne bloque pas le paquet
Tu ne fais pas de filtrage dans la table nat hein, parceque comme son nom l'indique, elle est là pour la nat... pas pour filtrer. Essaye plutôt iptables -t filter -P OUTPUT DROP
Alors que POSTROUTING: altering packet as they are about to go out. ICMP envoie le ping, niveau 2 IP,
niveau 3.
la table de routage est lue, et le paquet remonte sur lo immediatement, pas besoin de sortir. Mais il est bloque?! Alors a quel niveau travaille POSTROUTING?
Comme son nom l'indique, après le routage, mais pas pour filtrer, pour faire de la nat.
Deuxieme question: Par defaut, je charge mon firewall par des policy en DROP pour les tables filter (puis j'autorise au cas par cas). Dois-je faire de meme pour les tables nat et mangle?
Nop, elles ne sont pas là pour filtrer.
J'ai du mal a cerner l'impact du fait de laisser mes politiques pour nat et mangle en ACCEPT? Comment un pirate pourrait il jouer sur cette permissivite? Il se ferait bloquer au niveau du -t filter FORWARD non?
Yep, ou INPUT ou OUTPUT.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Vincent Bernat
OoO En ce début d'après-midi ensoleillé du jeudi 09 décembre 2004, vers 15:15, "T0t0" disait:
Déjà, ce shéma devrait t'aider (si jamais il sort bien formaté :-)
Conntrack | Mangle ^ Mangle Mangle | Filter | NAT (Src) NAT (Dst) | | Conntrack (QDisc) | [ROUTE] v | IN Filter OUT Conntrack | Conntrack ^ Mangle | Mangle | NAT (Dst) v | Filter
A ce sujet, voici deux URL qui montrent où passent les paquets sur un Linux : <URL:http://www.docum.org/docum.org/kptd/> <URL:http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png>
Si quelqu'un a des documents plus complets ou plus à jour... -- I WILL RETURN THE SEEING-EYE DOG I WILL RETURN THE SEEING-EYE DOG I WILL RETURN THE SEEING-EYE DOG -+- Bart Simpson on chalkboard in episode 9F18
OoO En ce début d'après-midi ensoleillé du jeudi 09 décembre 2004,
vers 15:15, "T0t0" <bibi@antionline.org> disait:
Déjà, ce shéma devrait t'aider (si jamais il sort bien formaté :-)
Conntrack | Mangle ^ Mangle
Mangle | Filter | NAT (Src)
NAT (Dst) | | Conntrack
(QDisc) | [ROUTE]
v |
IN Filter OUT Conntrack
| Conntrack ^ Mangle
| Mangle | NAT (Dst)
v | Filter
A ce sujet, voici deux URL qui montrent où passent les paquets sur un
Linux :
<URL:http://www.docum.org/docum.org/kptd/>
<URL:http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png>
Si quelqu'un a des documents plus complets ou plus à jour...
--
I WILL RETURN THE SEEING-EYE DOG
I WILL RETURN THE SEEING-EYE DOG
I WILL RETURN THE SEEING-EYE DOG
-+- Bart Simpson on chalkboard in episode 9F18
Conntrack | Mangle ^ Mangle Mangle | Filter | NAT (Src) NAT (Dst) | | Conntrack (QDisc) | [ROUTE] v | IN Filter OUT Conntrack | Conntrack ^ Mangle | Mangle | NAT (Dst) v | Filter
A ce sujet, voici deux URL qui montrent où passent les paquets sur un Linux : <URL:http://www.docum.org/docum.org/kptd/> <URL:http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png>
Si quelqu'un a des documents plus complets ou plus à jour... -- I WILL RETURN THE SEEING-EYE DOG I WILL RETURN THE SEEING-EYE DOG I WILL RETURN THE SEEING-EYE DOG -+- Bart Simpson on chalkboard in episode 9F18
Pascal
Salut,
Il y a certains cas extrêmement pointus, en particulier ce qui est DNAT qui sont difficiles à gérer, mais ça se règle en marquant les paquets. Genre un DNAT vers une IP interne. En FORWARD, tu ne sais pas si le gars a initialement demandé l'IP interne ou l'IP qui subit le NAT.
Quelle est votre opinion sur les options suivantes afin de bloquer les paquets venant de l'extérieur avec une adresse de destination interne ? En connaissez-vous d'autres ? Laquelle a votre préférence, et pourquoi ?
- blocage dans PREROUTING mangle - marquage dans PREROUTING mangle pour filtrage dans FORWARD filter - DNAT dans PREROUTING nat vers une adresse non routée - DNAT dans PREROUTING nat vers une adresse filtrée dans FORWARD filter
Salut,
Il y a certains cas extrêmement pointus, en particulier ce qui est DNAT
qui sont difficiles à gérer, mais ça se règle en marquant les paquets.
Genre un DNAT vers une IP interne. En FORWARD, tu ne sais pas si le gars a
initialement demandé l'IP interne ou l'IP qui subit le NAT.
Quelle est votre opinion sur les options suivantes afin de bloquer les
paquets venant de l'extérieur avec une adresse de destination interne ?
En connaissez-vous d'autres ? Laquelle a votre préférence, et pourquoi ?
- blocage dans PREROUTING mangle
- marquage dans PREROUTING mangle pour filtrage dans FORWARD filter
- DNAT dans PREROUTING nat vers une adresse non routée
- DNAT dans PREROUTING nat vers une adresse filtrée dans FORWARD filter
Il y a certains cas extrêmement pointus, en particulier ce qui est DNAT qui sont difficiles à gérer, mais ça se règle en marquant les paquets. Genre un DNAT vers une IP interne. En FORWARD, tu ne sais pas si le gars a initialement demandé l'IP interne ou l'IP qui subit le NAT.
Quelle est votre opinion sur les options suivantes afin de bloquer les paquets venant de l'extérieur avec une adresse de destination interne ? En connaissez-vous d'autres ? Laquelle a votre préférence, et pourquoi ?
- blocage dans PREROUTING mangle - marquage dans PREROUTING mangle pour filtrage dans FORWARD filter - DNAT dans PREROUTING nat vers une adresse non routée - DNAT dans PREROUTING nat vers une adresse filtrée dans FORWARD filter
