Je passe doucement du noyau 2.2 avec ipchains au noyau 2.4 avec le
couple infernal Netfilter/iptables pour une passerelle qui NATe un
réseau local. Dans les règles de filtrage, je souhaite bloquer tout ce
qui arriverait sur l'interface externe (appelons-la eth0, d'adresse
IP_EXT) avec une adresse destination autre que IP_EXT, en particulier
appartenant au réseau local interne (appelons-le 192.168.0.0/24).
Avec ipchains, c'était facile, tous les paquets entrants passant par la
chaîne input :
ipchains -A input -i eth0 -d ! $IP_EXT -j DENY
Avec Netfilter/iptables, il faut créer cette règle à la fois dans les
chaînes INPUT et FORWARD.
Pour INPUT, par de problème :
iptables -A INPUT -i eth0 -d ! $IP_EXT -j DROP
Seulement voilà, pour la chaîne FORWARD ça se complique... Il y a aussi
des redirections avec DNAT de l'extérieur vers le réseau local dans la
chaîne PREROUTING, du genre pour 192.168.0.7 qui est serveur web :
Ensuite, je crée la règle FORWARD qui va bien pour les paquets DNATés :
iptables -A FORWARD -d 192.168.0.7 -p tcp --dport 80 --syn \
-i eth0 -o eth1 -m state --state NEW -j ACCEPT
eth1 étant l'interface interne de la passerelle côté LAN. (Pour les
états ESTABLISHED et RELATED, il y a d'autres règles plus générales)
Ma question : comment empêcher que des paquets entrants par eth0 avec
comme destination 192.168.0.7:80 traversent ma passerelle sans bloquer
les paquets DNATés légitimes qui comportent la même destination après
avoir traversé la chaîne PREROUTING ?
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
TiChou
Dans l'article news:, Annie D. écrivait :
Bonjour à tous,
Bonsoir,
Je passe doucement du noyau 2.2 avec ipchains au noyau 2.4 avec le couple infernal Netfilter/iptables pour une passerelle qui NATe un réseau local. Dans les règles de filtrage, je souhaite bloquer tout ce qui arriverait sur l'interface externe (appelons-la eth0, d'adresse IP_EXT) avec une adresse destination autre que IP_EXT, en particulier appartenant au réseau local interne (appelons-le 192.168.0.0/24).
Avec ipchains, c'était facile, tous les paquets entrants passant par la chaîne input :
ipchains -A input -i eth0 -d ! $IP_EXT -j DENY
Avec Netfilter/iptables, il faut créer cette règle à la fois dans les chaînes INPUT et FORWARD.
Pour INPUT, par de problème :
iptables -A INPUT -i eth0 -d ! $IP_EXT -j DROP
Seulement voilà, pour la chaîne FORWARD ça se complique... Il y a aussi des redirections avec DNAT de l'extérieur vers le réseau local dans la chaîne PREROUTING, du genre pour 192.168.0.7 qui est serveur web :
Ensuite, je crée la règle FORWARD qui va bien pour les paquets DNATés :
iptables -A FORWARD -d 192.168.0.7 -p tcp --dport 80 --syn -i eth0 -o eth1 -m state --state NEW -j ACCEPT
eth1 étant l'interface interne de la passerelle côté LAN. (Pour les états ESTABLISHED et RELATED, il y a d'autres règles plus générales)
Ma question : comment empêcher que des paquets entrants par eth0 avec comme destination 192.168.0.7:80 traversent ma passerelle sans bloquer les paquets DNATés légitimes qui comportent la même destination après avoir traversé la chaîne PREROUTING ?
Réponse : bloquer les paquets entrants avec une adresse de destination ! $IP_EXT avant qu'ils n'atteignent la chaine PREROUTING de la table nat, ce qu'on peut faire avec la règle suivante :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j DROP
la règle 'iptables -A INPUT -i eth0 -d ! $IP_EXT -j DROP' étant alors redondante et pouvant être supprimée.
Il y aurait d'autre moyen de faire, par exemple toujours avec la table mangle et avec la cible ROUTE ou bien en aussi en marquant les paquets avec la cible MARK, mais cela ne ferait que compliquer les choses. Pis vu l'heure, j'ai un peu de mal j'avoue. ;)
Merci de vos commentaires/suggestions.
Avec plaisir.
-- TiChou
Dans l'article news:40297368.81A721F7@free.fr,
Annie D. <annie.demur@free.fr> écrivait :
Bonjour à tous,
Bonsoir,
Je passe doucement du noyau 2.2 avec ipchains au noyau 2.4 avec le
couple infernal Netfilter/iptables pour une passerelle qui NATe un
réseau local. Dans les règles de filtrage, je souhaite bloquer tout ce
qui arriverait sur l'interface externe (appelons-la eth0, d'adresse
IP_EXT) avec une adresse destination autre que IP_EXT, en particulier
appartenant au réseau local interne (appelons-le 192.168.0.0/24).
Avec ipchains, c'était facile, tous les paquets entrants passant par la
chaîne input :
ipchains -A input -i eth0 -d ! $IP_EXT -j DENY
Avec Netfilter/iptables, il faut créer cette règle à la fois dans les
chaînes INPUT et FORWARD.
Pour INPUT, par de problème :
iptables -A INPUT -i eth0 -d ! $IP_EXT -j DROP
Seulement voilà, pour la chaîne FORWARD ça se complique... Il y a aussi
des redirections avec DNAT de l'extérieur vers le réseau local dans la
chaîne PREROUTING, du genre pour 192.168.0.7 qui est serveur web :
Ensuite, je crée la règle FORWARD qui va bien pour les paquets DNATés :
iptables -A FORWARD -d 192.168.0.7 -p tcp --dport 80 --syn
-i eth0 -o eth1 -m state --state NEW -j ACCEPT
eth1 étant l'interface interne de la passerelle côté LAN. (Pour les
états ESTABLISHED et RELATED, il y a d'autres règles plus générales)
Ma question : comment empêcher que des paquets entrants par eth0 avec
comme destination 192.168.0.7:80 traversent ma passerelle sans bloquer
les paquets DNATés légitimes qui comportent la même destination après
avoir traversé la chaîne PREROUTING ?
Réponse : bloquer les paquets entrants avec une adresse de destination !
$IP_EXT avant qu'ils n'atteignent la chaine PREROUTING de la table nat, ce
qu'on peut faire avec la règle suivante :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j DROP
la règle 'iptables -A INPUT -i eth0 -d ! $IP_EXT -j DROP' étant alors
redondante et pouvant être supprimée.
Il y aurait d'autre moyen de faire, par exemple toujours avec la table
mangle et avec la cible ROUTE ou bien en aussi en marquant les paquets avec
la cible MARK, mais cela ne ferait que compliquer les choses. Pis vu
l'heure, j'ai un peu de mal j'avoue. ;)
Je passe doucement du noyau 2.2 avec ipchains au noyau 2.4 avec le couple infernal Netfilter/iptables pour une passerelle qui NATe un réseau local. Dans les règles de filtrage, je souhaite bloquer tout ce qui arriverait sur l'interface externe (appelons-la eth0, d'adresse IP_EXT) avec une adresse destination autre que IP_EXT, en particulier appartenant au réseau local interne (appelons-le 192.168.0.0/24).
Avec ipchains, c'était facile, tous les paquets entrants passant par la chaîne input :
ipchains -A input -i eth0 -d ! $IP_EXT -j DENY
Avec Netfilter/iptables, il faut créer cette règle à la fois dans les chaînes INPUT et FORWARD.
Pour INPUT, par de problème :
iptables -A INPUT -i eth0 -d ! $IP_EXT -j DROP
Seulement voilà, pour la chaîne FORWARD ça se complique... Il y a aussi des redirections avec DNAT de l'extérieur vers le réseau local dans la chaîne PREROUTING, du genre pour 192.168.0.7 qui est serveur web :
Ensuite, je crée la règle FORWARD qui va bien pour les paquets DNATés :
iptables -A FORWARD -d 192.168.0.7 -p tcp --dport 80 --syn -i eth0 -o eth1 -m state --state NEW -j ACCEPT
eth1 étant l'interface interne de la passerelle côté LAN. (Pour les états ESTABLISHED et RELATED, il y a d'autres règles plus générales)
Ma question : comment empêcher que des paquets entrants par eth0 avec comme destination 192.168.0.7:80 traversent ma passerelle sans bloquer les paquets DNATés légitimes qui comportent la même destination après avoir traversé la chaîne PREROUTING ?
Réponse : bloquer les paquets entrants avec une adresse de destination ! $IP_EXT avant qu'ils n'atteignent la chaine PREROUTING de la table nat, ce qu'on peut faire avec la règle suivante :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j DROP
la règle 'iptables -A INPUT -i eth0 -d ! $IP_EXT -j DROP' étant alors redondante et pouvant être supprimée.
Il y aurait d'autre moyen de faire, par exemple toujours avec la table mangle et avec la cible ROUTE ou bien en aussi en marquant les paquets avec la cible MARK, mais cela ne ferait que compliquer les choses. Pis vu l'heure, j'ai un peu de mal j'avoue. ;)
Merci de vos commentaires/suggestions.
Avec plaisir.
-- TiChou
Annie D.
TiChou wrote:
Ma question : comment empêcher que des paquets entrants par eth0 avec comme destination 192.168.0.7:80 traversent ma passerelle sans bloquer les paquets DNATés légitimes qui comportent la même destination après avoir traversé la chaîne PREROUTING ?
Réponse : bloquer les paquets entrants avec une adresse de destination ! $IP_EXT avant qu'ils n'atteignent la chaine PREROUTING de la table nat, ce qu'on peut faire avec la règle suivante :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j DROP
Intéressante suggestion. Mais le tutorial d'O. Andreasson dont le lien figure dans la page des docs du site de Netfilter déconseille fortement d'utiliser la table 'mangle' pour filtrer. Savez-vous pourquoi ?
Il y aurait d'autre moyen de faire, par exemple toujours avec la table mangle et avec la cible ROUTE
Je n'ai pas la cible ROUTE dans ma doc. C'est standard ?
ou bien en aussi en marquant les paquets avec la cible MARK, mais cela ne ferait que compliquer les choses.
Je viens de lire un peu à ce sujet - en fait jusqu'ici j'ai un peu zappé tout ce qui concerne la table 'mangle', un peu compliqué pour moi - et il me reste une question dont je n'ai pas trouvé la réponse : quelle est la valeur de 'mark' par défaut quand elle n'a pas été modifiée par la cible MARK ? Zéro ?
TiChou wrote:
Ma question : comment empêcher que des paquets entrants par eth0 avec
comme destination 192.168.0.7:80 traversent ma passerelle sans bloquer
les paquets DNATés légitimes qui comportent la même destination après
avoir traversé la chaîne PREROUTING ?
Réponse : bloquer les paquets entrants avec une adresse de destination !
$IP_EXT avant qu'ils n'atteignent la chaine PREROUTING de la table nat, ce
qu'on peut faire avec la règle suivante :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j DROP
Intéressante suggestion. Mais le tutorial d'O. Andreasson dont le lien
figure dans la page des docs du site de Netfilter déconseille fortement
d'utiliser la table 'mangle' pour filtrer. Savez-vous pourquoi ?
Il y aurait d'autre moyen de faire, par exemple toujours avec la table
mangle et avec la cible ROUTE
Je n'ai pas la cible ROUTE dans ma doc. C'est standard ?
ou bien en aussi en marquant les paquets avec
la cible MARK, mais cela ne ferait que compliquer les choses.
Je viens de lire un peu à ce sujet - en fait jusqu'ici j'ai un peu zappé
tout ce qui concerne la table 'mangle', un peu compliqué pour moi - et
il me reste une question dont je n'ai pas trouvé la réponse : quelle est
la valeur de 'mark' par défaut quand elle n'a pas été modifiée par la
cible MARK ? Zéro ?
Ma question : comment empêcher que des paquets entrants par eth0 avec comme destination 192.168.0.7:80 traversent ma passerelle sans bloquer les paquets DNATés légitimes qui comportent la même destination après avoir traversé la chaîne PREROUTING ?
Réponse : bloquer les paquets entrants avec une adresse de destination ! $IP_EXT avant qu'ils n'atteignent la chaine PREROUTING de la table nat, ce qu'on peut faire avec la règle suivante :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j DROP
Intéressante suggestion. Mais le tutorial d'O. Andreasson dont le lien figure dans la page des docs du site de Netfilter déconseille fortement d'utiliser la table 'mangle' pour filtrer. Savez-vous pourquoi ?
Il y aurait d'autre moyen de faire, par exemple toujours avec la table mangle et avec la cible ROUTE
Je n'ai pas la cible ROUTE dans ma doc. C'est standard ?
ou bien en aussi en marquant les paquets avec la cible MARK, mais cela ne ferait que compliquer les choses.
Je viens de lire un peu à ce sujet - en fait jusqu'ici j'ai un peu zappé tout ce qui concerne la table 'mangle', un peu compliqué pour moi - et il me reste une question dont je n'ai pas trouvé la réponse : quelle est la valeur de 'mark' par défaut quand elle n'a pas été modifiée par la cible MARK ? Zéro ?
Lsom
"Annie D." wrote:
Merci de vos commentaires/suggestions.
Je suis entrain de lire un tutorial, pour ma culture perso :) : http://olivieraj.free.fr/fr/linux/information/firewall/index.html
Tu auras peut etre une solution dans ses exemples.
Je ne maitrise pas assez pour répondre. Il ne semble pas y avoir de solution unique. Il faut choisir la plus simple... ;)
Bon courage !
"Annie D." wrote:
Merci de vos commentaires/suggestions.
Je suis entrain de lire un tutorial, pour ma culture perso :) :
http://olivieraj.free.fr/fr/linux/information/firewall/index.html
Tu auras peut etre une solution dans ses exemples.
Je ne maitrise pas assez pour répondre.
Il ne semble pas y avoir de solution unique.
Il faut choisir la plus simple... ;)
Je suis entrain de lire un tutorial, pour ma culture perso :) : http://olivieraj.free.fr/fr/linux/information/firewall/index.html
Tu auras peut etre une solution dans ses exemples.
Je ne maitrise pas assez pour répondre. Il ne semble pas y avoir de solution unique. Il faut choisir la plus simple... ;)
Bon courage !
Lsom
Lsom wrote:
Tu auras peut etre une solution dans ses exemples.
Il faudra sans doute que tu lises un peu pour connaitre la config de son exemple. Mais tu as peut etre la réponse au paragraphe III-8-1 IP masquerading .=
Lsom wrote:
Tu auras peut etre une solution dans ses exemples.
Il faudra sans doute que tu lises un peu pour connaitre la config de son
exemple.
Mais tu as peut etre la réponse au paragraphe III-8-1 IP masquerading .=
Tu auras peut etre une solution dans ses exemples.
Il faudra sans doute que tu lises un peu pour connaitre la config de son exemple. Mais tu as peut etre la réponse au paragraphe III-8-1 IP masquerading .=
TiChou
Dans l'article news:, Annie D. écrivait :
Ma question : comment empêcher que des paquets entrants par eth0 avec comme destination 192.168.0.7:80 traversent ma passerelle sans bloquer les paquets DNATés légitimes qui comportent la même destination après avoir traversé la chaîne PREROUTING ?
Réponse : bloquer les paquets entrants avec une adresse de destination ! $IP_EXT avant qu'ils n'atteignent la chaine PREROUTING de la table nat, ce
qu'on peut faire avec la règle suivante :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j DROP
Intéressante suggestion. Mais le tutorial d'O. Andreasson dont le lien figure dans la page des docs du site de Netfilter déconseille fortement d'utiliser la table 'mangle' pour filtrer. Savez-vous pourquoi ?
La table mangle a été intégrée par les développeurs de Netfilter afin de pouvoir modifier certaines caractéristiques des paquets avant qu'on ne décide comment ils seront filtrés et routés. D'un point de vue conception, la table mangle ne doit effectivement pas servir au filtrage des paquets d'une manière général, c'est en ça que Oskar Andreasson nous met en garde, mais rien ne nous empêche de l'utiliser pour filtrer des paquets dans des cas particuliers.
Il y aurait d'autre moyen de faire, par exemple toujours avec la table mangle et avec la cible ROUTE
Je n'ai pas la cible ROUTE dans ma doc. C'est standard ?
C'est une cible qui n'est pas disponible sur les noyaux standards. Elle fait partie depuis deux ans des extensions de Netfilter qui peuvent être ajoutées avec le Patch-O-Matic. Je vous invite, si ce n'est pas déjà fait, à lire le Netfilter-Extensions-HOWTO qui décrit ces extensions et comment les installer, même si ce document est un peu obsolète car de nombreuses extensions n'y sont pas référencées. Certaines de ces extensions se montrent très intéressantes.
ou bien en aussi en marquant les paquets avec la cible MARK, mais cela ne ferait que compliquer les choses.
Je viens de lire un peu à ce sujet - en fait jusqu'ici j'ai un peu zappé tout ce qui concerne la table 'mangle', un peu compliqué pour moi - et il me reste une question dont je n'ai pas trouvé la réponse : quelle est la valeur de 'mark' par défaut quand elle n'a pas été modifiée par la cible MARK ? Zéro ?
Il n'y en a pas. Les paquets traversant le noyau ne sont pas par défaut marqués.
Pour en revenir à votre cas, si on avait voulut utiliser le marquage des paquets, on aurait pu alors faire :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j MARK --set-mark 666 iptables -t filter -A FORWARD -m mark --mark 666 -j DROP
On obtient le même résultat, sauf qu'on a "compliqué" un peu plus les règles et que le noyau sera un peu plus "sollicité" pour bloquer ces paquets (marquage+décision de routage+2 chaînes à traverser).
Par contre je me pose une question sur la finalité de tout ça. Pourquoi vouloir bloquer avec Netfilter tous les paquets dont l'IP de destination n'est pas celle de l'interface ($IP_EXT) puisque l'interface réseau ignorera d'elle même ces paquets qui ne lui sont pas destinées ? Ensuite, autre question et sans vouloir remettre les choses en cause, comment se fait-il que deux réseaux physiquement distinct utilisent la même classe d'IP ?
-- TiChou
Dans l'article news:4029DB6E.8382F289@free.fr,
Annie D. <annie.demur@free.fr> écrivait :
Ma question : comment empêcher que des paquets entrants par eth0 avec
comme destination 192.168.0.7:80 traversent ma passerelle sans bloquer
les paquets DNATés légitimes qui comportent la même destination après
avoir traversé la chaîne PREROUTING ?
Réponse : bloquer les paquets entrants avec une adresse de destination !
$IP_EXT avant qu'ils n'atteignent la chaine PREROUTING de la table nat,
ce
qu'on peut faire avec la règle suivante :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j DROP
Intéressante suggestion. Mais le tutorial d'O. Andreasson dont le lien
figure dans la page des docs du site de Netfilter déconseille fortement
d'utiliser la table 'mangle' pour filtrer. Savez-vous pourquoi ?
La table mangle a été intégrée par les développeurs de Netfilter afin de
pouvoir modifier certaines caractéristiques des paquets avant qu'on ne
décide comment ils seront filtrés et routés.
D'un point de vue conception, la table mangle ne doit effectivement pas
servir au filtrage des paquets d'une manière général, c'est en ça que Oskar
Andreasson nous met en garde, mais rien ne nous empêche de l'utiliser pour
filtrer des paquets dans des cas particuliers.
Il y aurait d'autre moyen de faire, par exemple toujours avec la table
mangle et avec la cible ROUTE
Je n'ai pas la cible ROUTE dans ma doc. C'est standard ?
C'est une cible qui n'est pas disponible sur les noyaux standards. Elle fait
partie depuis deux ans des extensions de Netfilter qui peuvent être ajoutées
avec le Patch-O-Matic. Je vous invite, si ce n'est pas déjà fait, à lire le
Netfilter-Extensions-HOWTO qui décrit ces extensions et comment les
installer, même si ce document est un peu obsolète car de nombreuses
extensions n'y sont pas référencées. Certaines de ces extensions se montrent
très intéressantes.
ou bien en aussi en marquant les paquets avec
la cible MARK, mais cela ne ferait que compliquer les choses.
Je viens de lire un peu à ce sujet - en fait jusqu'ici j'ai un peu zappé
tout ce qui concerne la table 'mangle', un peu compliqué pour moi - et
il me reste une question dont je n'ai pas trouvé la réponse : quelle est
la valeur de 'mark' par défaut quand elle n'a pas été modifiée par la
cible MARK ? Zéro ?
Il n'y en a pas. Les paquets traversant le noyau ne sont pas par défaut
marqués.
Pour en revenir à votre cas, si on avait voulut utiliser le marquage des
paquets, on aurait pu alors faire :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j MARK --set-mark 666
iptables -t filter -A FORWARD -m mark --mark 666 -j DROP
On obtient le même résultat, sauf qu'on a "compliqué" un peu plus les règles
et que le noyau sera un peu plus "sollicité" pour bloquer ces paquets
(marquage+décision de routage+2 chaînes à traverser).
Par contre je me pose une question sur la finalité de tout ça. Pourquoi
vouloir bloquer avec Netfilter tous les paquets dont l'IP de destination
n'est pas celle de l'interface ($IP_EXT) puisque l'interface réseau ignorera
d'elle même ces paquets qui ne lui sont pas destinées ?
Ensuite, autre question et sans vouloir remettre les choses en cause,
comment se fait-il que deux réseaux physiquement distinct utilisent la même
classe d'IP ?
Ma question : comment empêcher que des paquets entrants par eth0 avec comme destination 192.168.0.7:80 traversent ma passerelle sans bloquer les paquets DNATés légitimes qui comportent la même destination après avoir traversé la chaîne PREROUTING ?
Réponse : bloquer les paquets entrants avec une adresse de destination ! $IP_EXT avant qu'ils n'atteignent la chaine PREROUTING de la table nat, ce
qu'on peut faire avec la règle suivante :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j DROP
Intéressante suggestion. Mais le tutorial d'O. Andreasson dont le lien figure dans la page des docs du site de Netfilter déconseille fortement d'utiliser la table 'mangle' pour filtrer. Savez-vous pourquoi ?
La table mangle a été intégrée par les développeurs de Netfilter afin de pouvoir modifier certaines caractéristiques des paquets avant qu'on ne décide comment ils seront filtrés et routés. D'un point de vue conception, la table mangle ne doit effectivement pas servir au filtrage des paquets d'une manière général, c'est en ça que Oskar Andreasson nous met en garde, mais rien ne nous empêche de l'utiliser pour filtrer des paquets dans des cas particuliers.
Il y aurait d'autre moyen de faire, par exemple toujours avec la table mangle et avec la cible ROUTE
Je n'ai pas la cible ROUTE dans ma doc. C'est standard ?
C'est une cible qui n'est pas disponible sur les noyaux standards. Elle fait partie depuis deux ans des extensions de Netfilter qui peuvent être ajoutées avec le Patch-O-Matic. Je vous invite, si ce n'est pas déjà fait, à lire le Netfilter-Extensions-HOWTO qui décrit ces extensions et comment les installer, même si ce document est un peu obsolète car de nombreuses extensions n'y sont pas référencées. Certaines de ces extensions se montrent très intéressantes.
ou bien en aussi en marquant les paquets avec la cible MARK, mais cela ne ferait que compliquer les choses.
Je viens de lire un peu à ce sujet - en fait jusqu'ici j'ai un peu zappé tout ce qui concerne la table 'mangle', un peu compliqué pour moi - et il me reste une question dont je n'ai pas trouvé la réponse : quelle est la valeur de 'mark' par défaut quand elle n'a pas été modifiée par la cible MARK ? Zéro ?
Il n'y en a pas. Les paquets traversant le noyau ne sont pas par défaut marqués.
Pour en revenir à votre cas, si on avait voulut utiliser le marquage des paquets, on aurait pu alors faire :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j MARK --set-mark 666 iptables -t filter -A FORWARD -m mark --mark 666 -j DROP
On obtient le même résultat, sauf qu'on a "compliqué" un peu plus les règles et que le noyau sera un peu plus "sollicité" pour bloquer ces paquets (marquage+décision de routage+2 chaînes à traverser).
Par contre je me pose une question sur la finalité de tout ça. Pourquoi vouloir bloquer avec Netfilter tous les paquets dont l'IP de destination n'est pas celle de l'interface ($IP_EXT) puisque l'interface réseau ignorera d'elle même ces paquets qui ne lui sont pas destinées ? Ensuite, autre question et sans vouloir remettre les choses en cause, comment se fait-il que deux réseaux physiquement distinct utilisent la même classe d'IP ?
-- TiChou
TiChou
Dans l'article news:402a4ff5$0$28125$, je délirais complètement :
Par contre je me pose une question sur la finalité de tout ça. Pourquoi vouloir bloquer avec Netfilter tous les paquets dont l'IP de destination n'est pas celle de l'interface ($IP_EXT) puisque l'interface réseau ignorera
d'elle même ces paquets qui ne lui sont pas destinées ?
Faudrait que j'aille dormir je pense... Merci d'oublier très vite cette remarque. ;)
-- TiChou
Dans l'article news:402a4ff5$0$28125$626a14ce@news.free.fr,
je délirais complètement :
Par contre je me pose une question sur la finalité de tout ça. Pourquoi
vouloir bloquer avec Netfilter tous les paquets dont l'IP de destination
n'est pas celle de l'interface ($IP_EXT) puisque l'interface réseau
ignorera
d'elle même ces paquets qui ne lui sont pas destinées ?
Faudrait que j'aille dormir je pense... Merci d'oublier très vite cette
remarque. ;)
Dans l'article news:402a4ff5$0$28125$, je délirais complètement :
Par contre je me pose une question sur la finalité de tout ça. Pourquoi vouloir bloquer avec Netfilter tous les paquets dont l'IP de destination n'est pas celle de l'interface ($IP_EXT) puisque l'interface réseau ignorera
d'elle même ces paquets qui ne lui sont pas destinées ?
Faudrait que j'aille dormir je pense... Merci d'oublier très vite cette remarque. ;)
-- TiChou
Annie D.
Lsom wrote:
Je suis entrain de lire un tutorial, pour ma culture perso :) : http://olivieraj.free.fr/fr/linux/information/firewall/index.html [...]
tu as peut etre la réponse au paragraphe III-8-1 IP masquerading .
Hélas, rien de nouveau par rapport à ce que j'ai déjà lu ici et là.
Ah, si quand même, un détail qui m'a étonnée dans le paragraphe III-8-2 "Port forwarding" : la méthode que je jugerais "classique" consistant à modifier l'adresse destination seule (DNAT) y est jugée "sale" par opposition à une méthode qui me semble moins orthodoxe consistant à modifier également l'adresse source (DNAT+SNAT).
Chain POSTROUTING (policy ACCEPT 1 packets, 60 bytes) pkts bytes target prot opt in out source destination
Comme précédemment, un paquet est passé par le chaîne "PREROUTING", mais aucun n'est passé par de règles "POSTROUTING". Et pour cause, il n'y en a plus. Par contre, le paquet de retour est passé par la règle par défaut de la chaîne POSTROUTING... C'est parce que les paquets n'empruntent pas les mêmes canaux en entrée et en sortie que j'estime cette méthode comme étant "sale"."
Il me semble que cette interprétation des statistiques des chaînes PREROUTING et POSTROUTING est erronée : c'est le même premier paquet aller de la connexion qui est compté comme ayant traversé les deux chaînes, alors que le premier paquet retour et les paquets aller et retour suivants n'en ont traversé aucune. C'est le comportement normal de la table nat. Et par conséquent, la méthode de port forwarding sans SNAT n'a rien de "sale". Ou alors je n'ai rien compris, mais je préfèrerais qu'on me le dise tout de suite.
Lsom wrote:
Je suis entrain de lire un tutorial, pour ma culture perso :) :
http://olivieraj.free.fr/fr/linux/information/firewall/index.html
[...]
tu as peut etre la réponse au paragraphe III-8-1 IP masquerading .
Hélas, rien de nouveau par rapport à ce que j'ai déjà lu ici et là.
Ah, si quand même, un détail qui m'a étonnée dans le paragraphe III-8-2
"Port forwarding" : la méthode que je jugerais "classique" consistant à
modifier l'adresse destination seule (DNAT) y est jugée "sale" par
opposition à une méthode qui me semble moins orthodoxe consistant à
modifier également l'adresse source (DNAT+SNAT).
Chain POSTROUTING (policy ACCEPT 1 packets, 60 bytes)
pkts bytes target prot opt in out source destination
Comme précédemment, un paquet est passé par le chaîne "PREROUTING",
mais aucun n'est passé par de règles "POSTROUTING". Et pour cause,
il n'y en a plus. Par contre, le paquet de retour est passé par la
règle par défaut de la chaîne POSTROUTING... C'est parce que les
paquets n'empruntent pas les mêmes canaux en entrée et en sortie
que j'estime cette méthode comme étant "sale"."
Il me semble que cette interprétation des statistiques des chaînes
PREROUTING et POSTROUTING est erronée : c'est le même premier paquet
aller de la connexion qui est compté comme ayant traversé les deux
chaînes, alors que le premier paquet retour et les paquets aller et
retour suivants n'en ont traversé aucune. C'est le comportement normal
de la table nat. Et par conséquent, la méthode de port forwarding sans
SNAT n'a rien de "sale". Ou alors je n'ai rien compris, mais je
préfèrerais qu'on me le dise tout de suite.
Je suis entrain de lire un tutorial, pour ma culture perso :) : http://olivieraj.free.fr/fr/linux/information/firewall/index.html [...]
tu as peut etre la réponse au paragraphe III-8-1 IP masquerading .
Hélas, rien de nouveau par rapport à ce que j'ai déjà lu ici et là.
Ah, si quand même, un détail qui m'a étonnée dans le paragraphe III-8-2 "Port forwarding" : la méthode que je jugerais "classique" consistant à modifier l'adresse destination seule (DNAT) y est jugée "sale" par opposition à une méthode qui me semble moins orthodoxe consistant à modifier également l'adresse source (DNAT+SNAT).
Chain POSTROUTING (policy ACCEPT 1 packets, 60 bytes) pkts bytes target prot opt in out source destination
Comme précédemment, un paquet est passé par le chaîne "PREROUTING", mais aucun n'est passé par de règles "POSTROUTING". Et pour cause, il n'y en a plus. Par contre, le paquet de retour est passé par la règle par défaut de la chaîne POSTROUTING... C'est parce que les paquets n'empruntent pas les mêmes canaux en entrée et en sortie que j'estime cette méthode comme étant "sale"."
Il me semble que cette interprétation des statistiques des chaînes PREROUTING et POSTROUTING est erronée : c'est le même premier paquet aller de la connexion qui est compté comme ayant traversé les deux chaînes, alors que le premier paquet retour et les paquets aller et retour suivants n'en ont traversé aucune. C'est le comportement normal de la table nat. Et par conséquent, la méthode de port forwarding sans SNAT n'a rien de "sale". Ou alors je n'ai rien compris, mais je préfèrerais qu'on me le dise tout de suite.
Annie D.
TiChou wrote:
La table mangle a été intégrée par les développeurs de Netfilter afin de pouvoir modifier certaines caractéristiques des paquets avant qu'on ne décide comment ils seront filtrés et routés. D'un point de vue conception, la table mangle ne doit effectivement pas servir au filtrage des paquets d'une manière général, c'est en ça que Oskar Andreasson nous met en garde, mais rien ne nous empêche de l'utiliser pour filtrer des paquets dans des cas particuliers.
Donc je retiens qu'il n'y a pas d'inconvénient technique comme pour la table nat. Parfait.
Je n'ai pas la cible ROUTE dans ma doc. C'est standard ?
C'est une cible qui n'est pas disponible sur les noyaux standards. Elle fait partie depuis deux ans des extensions de Netfilter qui peuvent être ajoutées avec le Patch-O-Matic. Je vous invite, si ce n'est pas déjà fait, à lire le Netfilter-Extensions-HOWTO qui décrit ces extensions et comment les installer, même si ce document est un peu obsolète car de nombreuses extensions n'y sont pas référencées. Certaines de ces extensions se montrent très intéressantes.
J'avais déjà un peu lu, mais c'est très long. Je recherchais le module pour la NAT du protocole PPTP qui n'a pas non plus l'air d'être inclus dans le noyau standard de la distribution. Or d'après les essais que j'ai faits, ça a quand même l'air de marcher dans les deux sens sans ce module.
Pour en revenir à votre cas, si on avait voulut utiliser le marquage des paquets, on aurait pu alors faire :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j MARK --set-mark 666 iptables -t filter -A FORWARD -m mark --mark 666 -j DROP
On obtient le même résultat, sauf qu'on a "compliqué" un peu plus les règles et que le noyau sera un peu plus "sollicité" pour bloquer ces paquets (marquage+décision de routage+2 chaînes à traverser).
C'est embêtant. Le coeur de la passerelle en question est un vénérable 486-33MHz qui doit être ménagé.
Par contre je me pose une question sur la finalité de tout ça. <coupe pudique>
Faudrait que j'aille dormir je pense... Merci d'oublier très vite cette remarque. ;)
Résumons, si vous voulez bien. A 2 heures du matin, vous avez du mal. A 17 heures dans l'après-midi, ça n'a pas l'air beaucoup mieux. A quelle heure dois-je poster mes questions pour optimiser vos réponses ?
TiChou wrote:
La table mangle a été intégrée par les développeurs de Netfilter afin de
pouvoir modifier certaines caractéristiques des paquets avant qu'on ne
décide comment ils seront filtrés et routés.
D'un point de vue conception, la table mangle ne doit effectivement pas
servir au filtrage des paquets d'une manière général, c'est en ça que Oskar
Andreasson nous met en garde, mais rien ne nous empêche de l'utiliser pour
filtrer des paquets dans des cas particuliers.
Donc je retiens qu'il n'y a pas d'inconvénient technique comme pour la
table nat. Parfait.
Je n'ai pas la cible ROUTE dans ma doc. C'est standard ?
C'est une cible qui n'est pas disponible sur les noyaux standards. Elle fait
partie depuis deux ans des extensions de Netfilter qui peuvent être ajoutées
avec le Patch-O-Matic. Je vous invite, si ce n'est pas déjà fait, à lire le
Netfilter-Extensions-HOWTO qui décrit ces extensions et comment les
installer, même si ce document est un peu obsolète car de nombreuses
extensions n'y sont pas référencées. Certaines de ces extensions se montrent
très intéressantes.
J'avais déjà un peu lu, mais c'est très long. Je recherchais le module
pour la NAT du protocole PPTP qui n'a pas non plus l'air d'être inclus
dans le noyau standard de la distribution. Or d'après les essais que
j'ai faits, ça a quand même l'air de marcher dans les deux sens sans ce
module.
Pour en revenir à votre cas, si on avait voulut utiliser le marquage des
paquets, on aurait pu alors faire :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j MARK --set-mark 666
iptables -t filter -A FORWARD -m mark --mark 666 -j DROP
On obtient le même résultat, sauf qu'on a "compliqué" un peu plus les règles
et que le noyau sera un peu plus "sollicité" pour bloquer ces paquets
(marquage+décision de routage+2 chaînes à traverser).
C'est embêtant. Le coeur de la passerelle en question est un vénérable
486-33MHz qui doit être ménagé.
Par contre je me pose une question sur la finalité de tout ça.
<coupe pudique>
Faudrait que j'aille dormir je pense... Merci d'oublier très vite cette
remarque. ;)
Résumons, si vous voulez bien. A 2 heures du matin, vous avez du mal. A
17 heures dans l'après-midi, ça n'a pas l'air beaucoup mieux. A quelle
heure dois-je poster mes questions pour optimiser vos réponses ?
La table mangle a été intégrée par les développeurs de Netfilter afin de pouvoir modifier certaines caractéristiques des paquets avant qu'on ne décide comment ils seront filtrés et routés. D'un point de vue conception, la table mangle ne doit effectivement pas servir au filtrage des paquets d'une manière général, c'est en ça que Oskar Andreasson nous met en garde, mais rien ne nous empêche de l'utiliser pour filtrer des paquets dans des cas particuliers.
Donc je retiens qu'il n'y a pas d'inconvénient technique comme pour la table nat. Parfait.
Je n'ai pas la cible ROUTE dans ma doc. C'est standard ?
C'est une cible qui n'est pas disponible sur les noyaux standards. Elle fait partie depuis deux ans des extensions de Netfilter qui peuvent être ajoutées avec le Patch-O-Matic. Je vous invite, si ce n'est pas déjà fait, à lire le Netfilter-Extensions-HOWTO qui décrit ces extensions et comment les installer, même si ce document est un peu obsolète car de nombreuses extensions n'y sont pas référencées. Certaines de ces extensions se montrent très intéressantes.
J'avais déjà un peu lu, mais c'est très long. Je recherchais le module pour la NAT du protocole PPTP qui n'a pas non plus l'air d'être inclus dans le noyau standard de la distribution. Or d'après les essais que j'ai faits, ça a quand même l'air de marcher dans les deux sens sans ce module.
Pour en revenir à votre cas, si on avait voulut utiliser le marquage des paquets, on aurait pu alors faire :
iptables -t mangle -A PREROUTING -i eth0 -d ! $IP_EXT -j MARK --set-mark 666 iptables -t filter -A FORWARD -m mark --mark 666 -j DROP
On obtient le même résultat, sauf qu'on a "compliqué" un peu plus les règles et que le noyau sera un peu plus "sollicité" pour bloquer ces paquets (marquage+décision de routage+2 chaînes à traverser).
C'est embêtant. Le coeur de la passerelle en question est un vénérable 486-33MHz qui doit être ménagé.
Par contre je me pose une question sur la finalité de tout ça. <coupe pudique>
Faudrait que j'aille dormir je pense... Merci d'oublier très vite cette remarque. ;)
Résumons, si vous voulez bien. A 2 heures du matin, vous avez du mal. A 17 heures dans l'après-midi, ça n'a pas l'air beaucoup mieux. A quelle heure dois-je poster mes questions pour optimiser vos réponses ?
TiChou
Dans l'article news:, Annie D. écrivait :
Par contre je me pose une question sur la finalité de tout ça. <coupe pudique>
Merci. :)
Faudrait que j'aille dormir je pense... Merci d'oublier très vite cette remarque. ;)
Résumons, si vous voulez bien. A 2 heures du matin, vous avez du mal. A 17 heures dans l'après-midi, ça n'a pas l'air beaucoup mieux. A quelle heure dois-je poster mes questions pour optimiser vos réponses ?
Vers 16H à l'heure du gouter, mais je ne suis hélas plus devant l'écran. :p
-- TiChou
Dans l'article news:402AB74A.BE75A74D@free.fr,
Annie D. <annie.demur@free.fr> écrivait :
Par contre je me pose une question sur la finalité de tout ça.
<coupe pudique>
Merci. :)
Faudrait que j'aille dormir je pense... Merci d'oublier très vite cette
remarque. ;)
Résumons, si vous voulez bien. A 2 heures du matin, vous avez du mal. A
17 heures dans l'après-midi, ça n'a pas l'air beaucoup mieux. A quelle
heure dois-je poster mes questions pour optimiser vos réponses ?
Vers 16H à l'heure du gouter, mais je ne suis hélas plus devant l'écran. :p
Par contre je me pose une question sur la finalité de tout ça. <coupe pudique>
Merci. :)
Faudrait que j'aille dormir je pense... Merci d'oublier très vite cette remarque. ;)
Résumons, si vous voulez bien. A 2 heures du matin, vous avez du mal. A 17 heures dans l'après-midi, ça n'a pas l'air beaucoup mieux. A quelle heure dois-je poster mes questions pour optimiser vos réponses ?
Vers 16H à l'heure du gouter, mais je ne suis hélas plus devant l'écran. :p
-- TiChou
Julien Salgado
Annie D. a écrit :
Il me semble que cette interprétation des statistiques des chaînes PREROUTING et POSTROUTING est erronée : c'est le même premier paquet aller de la connexion qui est compté comme ayant traversé les deux chaînes, alors que le premier paquet retour et les paquets aller et retour suivants n'en ont traversé aucune. C'est le comportement normal de la table nat. Et par conséquent, la méthode de port forwarding sans SNAT n'a rien de "sale". Ou alors je n'ai rien compris, mais je préfèrerais qu'on me le dise tout de suite.
En effet, de plus la double NAT, n'a pas que des avantages en effet, elle empeche tout filtrage applicatif ou statistique sur les IP sources, ne cache pas le fait qu'on fait de la NAT [1] si on a la main sur le serveur. Le seul réel avantage est l'absence de routage sur le serveur qui se content de switcher les paquets.
[1] On peut faire de la double-double (sic) NAT mais c'est se compliquer la vie pour un gain faible.
-- Julien
Annie D. a écrit :
Il me semble que cette interprétation des statistiques des chaînes
PREROUTING et POSTROUTING est erronée : c'est le même premier paquet
aller de la connexion qui est compté comme ayant traversé les deux
chaînes, alors que le premier paquet retour et les paquets aller et
retour suivants n'en ont traversé aucune. C'est le comportement normal
de la table nat. Et par conséquent, la méthode de port forwarding sans
SNAT n'a rien de "sale". Ou alors je n'ai rien compris, mais je
préfèrerais qu'on me le dise tout de suite.
En effet, de plus la double NAT, n'a pas que des avantages en effet,
elle empeche tout filtrage applicatif ou statistique sur les IP sources,
ne cache pas le fait qu'on fait de la NAT [1] si on a la main sur le
serveur. Le seul réel avantage est l'absence de routage sur le serveur
qui se content de switcher les paquets.
[1] On peut faire de la double-double (sic) NAT mais c'est se compliquer
la vie pour un gain faible.
Il me semble que cette interprétation des statistiques des chaînes PREROUTING et POSTROUTING est erronée : c'est le même premier paquet aller de la connexion qui est compté comme ayant traversé les deux chaînes, alors que le premier paquet retour et les paquets aller et retour suivants n'en ont traversé aucune. C'est le comportement normal de la table nat. Et par conséquent, la méthode de port forwarding sans SNAT n'a rien de "sale". Ou alors je n'ai rien compris, mais je préfèrerais qu'on me le dise tout de suite.
En effet, de plus la double NAT, n'a pas que des avantages en effet, elle empeche tout filtrage applicatif ou statistique sur les IP sources, ne cache pas le fait qu'on fait de la NAT [1] si on a la main sur le serveur. Le seul réel avantage est l'absence de routage sur le serveur qui se content de switcher les paquets.
[1] On peut faire de la double-double (sic) NAT mais c'est se compliquer la vie pour un gain faible.
