Iptable : comprends rien...

In article <x7iscwojy3.fsf@steph.teaser.fr>, et+news@steph.teaser.fr
says...

Jul 10 01:03:59 steph kernel: IN= OUT=eth0 SRC€.236.46.215 DST!3.91.2.137 LENv TOS=0x00 PREC=0x00 TTLd ID=0 DF PROTO=UDP SPT3 DPT3 LENV
iptables -A INPUT -p udp -i eth0 --dport 123 --sport 123 -m state --state NEW -j ACCEPT
Je suis loin d'être expert en la matière... mais le paquet logué et la

règle ne me semble pas correspondre...

OUT=eth0 => paquet resortant vers eth0
-A INPUT => règle pour les paquets entrant

mais peut être me trompé-je.... ?

Dans le message <news:MPG.1b594d187f982009896e6@news.free.fr>,
*Laurent* tapota sur f.c.r.ip :

Je suis loin d'être expert en la matière... mais le paquet logué et la
règle ne me semble pas correspondre...

OUT=eth0 => paquet resortant vers eth0
-A INPUT => règle pour les paquets entrant

mais peut être me trompé-je.... ?

Non.

--
TiChou

Etienne de Tocqueville wrote:

J'ai du récemment installer Iptable sur mon linux (à mon gfrand regret,
Ipchains n'était plus supporté)

V'la aut'chose. C'est quoi votre Linux qui ne supporte plus ipchains ?
Normalement, même avec le filtre de paquet Netfilter des noyaux 2.4 et
suivants, on peut rétablir le support d'ipchains avec le module
ipchains.o si le noyau a été compilé avec l'option correspondante. Mais
bon, franchement, il n'y a pas vraiment pas de quoi regretter de devoir
abandonner ipchains.

et je dois dire que je ne comprends rien

Et la doc de Netfilter, vous l'avez lue ? Elle explique très bien, alors
que je me rappelle qu'à la première lecture du man d'iptables je n'avais
rien compris.

! Par exemple, j'essaye de le régler pour que je puisse utiliser ntp,
mais je n'y arrive pas :

root@steph:~> /usr/sbin/ntpdate ntp.teaser.fr
10 Jul 01:05:06 ntpdate[12980]: sendto(213.91.2.137): Operation not permitted

Il doit y avoir un règle iptables qui bloque ces paquets en sortie. Ce
serait pas mal d'indiquer vos règles, ainsi que les politiques par
défaut des chaînes. Un jeu de règles est un ensemble cohérent, une règle
n'est efficace que par rapport au reste.

Pendant le meme temps, dans les logs, je trouve des trucs du genre :

Jul 10 01:03:58 steph kernel: IN= OUT=eth0 SRC€.236.46.215 DST!3.91.2.137 LENv TOS=0x00 PREC=0x00 TTLd ID=0 DF PROTO=UDP SPT3 DPT3 LENV

Et d'où viennent ces logs ? Ce sont les paquets qui sont bloqués ?

Je rajoute donc la règle :

iptables -A INPUT -p udp -i eth0 --dport 123 --sport 123
-m state --state NEW -j ACCEPT

Mais j'ai toujours la meme chose dans les logs :-( Ca me semble pourtant
correspondre aux paquets loggés ! Qu'ai-je loupé ?

Vous avez créé cette règle dans la chaîne INPUT qui, comme son nom
l'indique, traite les paquets entrants à destination de la machine
(contrairement à ipchains, elle ne traite pas les paquets entrants à
destination d'une autre machine, qui ne traversent que la chaîne
FORWARD, du moins dans la table 'filter' qui nous intéresse ici). Or il
semble, d'après le message d'erreur et les logs (si ceux-ci
correspondent bien aux paquets bloqués), que ce soient les paquets émis
par votre machine qui sont bloqués. Pour traiter les paquets émis par la
machine, il faut utiliser la chaîne OUTPUT. D'autre part, l'état NEW ne
concerne que le premier paquet de la communication. Il faut donc
s'occuper des éventuels paquets suivants (état ESTABLISHED) par une
règle spécifique ou générale.

Pour autoriser cette communication en utilisant les états de connexion,
il faudrait les deux règles spécifiques suivantes pour les paquets émis
et reçus respectivement :

iptables -A OUTPUT -o eth0 -p udp --sport 123 --dport 123
-m state --state NEW,ESTABLISHED -j ACCEPT

iptables -A INPUT -i eth0 -p udp --sport 123 --dport 123
-m state --state ESTABLISHED -j ACCEPT

A placer avant toute règle qui bloquerait ces mêmes paquets.

Sinon, il y a une autre possibilité : comme moi vous faites confiance à
ce qui sort de votre machine et vous autorisez tout en sortie.

Si les autres communications sortantes fonctionnent, il se peut que les
ports source privilégiés (0 à 1023), qui correspondent habituellement à
des services, soient bloqués en sortie de votre machine. Pour vérifier,
vous pouvez essayer ntpdate avec l'option -q qui ne fait qu'une lecture
de la date sur le serveur et utilise un port source non privilégié au
lieu du port 123 :

/usr/sbin/ntpdate -q ntp.teaser.fr

"Annie D." <annie.demur@free.fr> a écrit sur fr.comp.reseaux.ip :

V'la aut'chose. C'est quoi votre Linux qui ne supporte plus ipchains ?

C'est la 2.4.26. Il y a effectivement une option a activer lors de la
compilation du noyau, je l'avais rapidement trouvé sur Google, mais je
n'ai jamais réussi à la trouver ni dans menuconfig ni dans xconfig ! Ca
n'est pourtant pas faute d'avoir cherché !

Et la doc de Netfilter, vous l'avez lue ? Elle explique très bien, alors
que je me rappelle qu'à la première lecture du man d'iptables je n'avais
rien compris.

Je suppose qu'il fallait lire là "iptables". Bien sur que j'ai la doc !
Ca fait plus de 3 mois que j'ai ce problème, donc j'ai eu le temps de la
lire ;-) Mais je n'y ai absolument rien compris... Ipchains était à mon
gout nettement plus clair !

root@steph:~> /usr/sbin/ntpdate ntp.teaser.fr
10 Jul 01:05:06 ntpdate[12980]: sendto(213.91.2.137): Operation not permitted

Il doit y avoir un règle iptables qui bloque ces paquets en sortie. Ce
serait pas mal d'indiquer vos règles, ainsi que les politiques par
défaut des chaînes. Un jeu de règles est un ensemble cohérent, une règle
n'est efficace que par rapport au reste.

Oui, bien sur, il y avait une règle qui bloquait le paquet :

iptables -A OUTPUT -j DROP
iptables -A INPUT -j DROP

Mais en fait, je ne cherchait pas vraiment quelle règle bloquait le
paquet. Je cherchais juste pourquoi celle que je citais ne le laissait
pas passer. C'est pour ça que je n'ai pas mis toute les autres règles.

Jul 10 01:03:58 steph kernel: IN= OUT=eth0 SRC€.236.46.215 DST!3.91.2.137 LENv TOS=0x00 PREC=0x00 TTLd ID=0 DF PROTO=UDP SPT3 DPT3 LENV

Et d'où viennent ces logs ? Ce sont les paquets qui sont bloqués ?

C'est les logs que j'ai trouvé dans /var/log/messages, et ça
correspondent effectivement aux paquets bloqués.

Je rajoute donc la règle :

iptables -A INPUT -p udp -i eth0 --dport 123 --sport 123
-m state --state NEW -j ACCEPT

Mais j'ai toujours la meme chose dans les logs :-( Ca me semble pourtant
correspondre aux paquets loggés ! Qu'ai-je loupé ?

Vous avez créé cette règle dans la chaîne INPUT qui, comme son nom
l'indique,

Ah oui, je n'avais pas repéré ça ! Merci bien !

Pour autoriser cette communication en utilisant les états de connexion,
il faudrait les deux règles spécifiques suivantes pour les paquets émis
et reçus respectivement :

iptables -A OUTPUT -o eth0 -p udp --sport 123 --dport 123
-m state --state NEW,ESTABLISHED -j ACCEPT

iptables -A INPUT -i eth0 -p udp --sport 123 --dport 123
-m state --state ESTABLISHED -j ACCEPT

Je n'ai pas vraiment compris cette histoire de NEW et de ESTABLISHED (en
fait, je n'avais déjà rien compris en lisant les docs) mais le fait est
que là, ça marche impeccable !

Sinon, il y a une autre possibilité : comme moi vous faites confiance à
ce qui sort de votre machine et vous autorisez tout en sortie.

Ah oui, c'est pas bete du tout ! En fait, un peu comme ipchains, si je
ne m'abuse ;-) J'essayerais de faire ça dès que j'aurais compris comment
ça marche !

En tout cas merci à tous !

Etienne de Tocqueville wrote:

"Annie D." <annie.demur@free.fr> a écrit sur fr.comp.reseaux.ip :

V'la aut'chose. C'est quoi votre Linux qui ne supporte plus ipchains ?

C'est la 2.4.26. Il y a effectivement une option a activer lors de la
compilation du noyau, je l'avais rapidement trouvé sur Google, mais je
n'ai jamais réussi à la trouver ni dans menuconfig ni dans xconfig !

C'est l'option CONFIG_IP_NF_COMPAT_IPCHAINS à mettre à 'm' (module).
Dans menuconfig à partir du menu principal, elle se trouve dans
l'arborescence suivante, tout à la fin du dernier menu :

Networking options --->
IP: Netfilter Configuration --->
[ ] ipchains (2.2-style) support

Et la doc de Netfilter, vous l'avez lue ?

Je suppose qu'il fallait lire là "iptables".

Non, ce n'était pas une erreur. Netfilter est le nom du filtre de
paquets IP du noyau. iptables n'est qu'une des interfaces utilisateur
pour créer, afficher ou supprimer les règles de filtrage/NAT/altération
qui sont appliquées par Netfilter. Si la compatibilité avec ipchains et
activée et le module correspondant chargé, l'interface utilisateur
devient ipchains mais le filtre de paquets du noyau est toujours
Netfilter.

Bien sur que j'ai la doc !

Laquelle ?
AMA, les indispensables sont le Packet-filtering-howto et l'excellent
"iptables tutorial" d'Oskar Andreasson que je garde toujours à portée de
main. Plus le NAT-howto pour ceux qui veulent mettre en place un routeur
NAT.

Le Netfilter-hacking-howto n'est pas à réserver aux hackers car il peut
apporter quelques informations intéressantes sur le fonctionnement
interne de Netfilter qui AMA manquent aux deux autres howtos.

Tous ces documents sont accessibles depuis la page de documentation du
projet netfilter (http://www.netfilter.org/documentation/index.html ou
http://www.iptables.org/documentation/index.html). Les howtos sont
disponibles en français, le tutorial est seulement en anglais.

Et, bien entendu, une connaissance de la famille des protocoles IP est
indispensable pour savoir ce qu'on fait.

Ca fait plus de 3 mois que j'ai ce problème, donc j'ai eu le temps de la
lire ;-) Mais je n'y ai absolument rien compris...

Trois mois, ce n'est pas normal. Vous auriez pu venir plus tôt.

Oui, bien sur, il y avait une règle qui bloquait le paquet :

iptables -A OUTPUT -j DROP
iptables -A INPUT -j DROP

Elles sont placées où ces règles ? En fin de chaînes ?

Je n'ai pas vraiment compris cette histoire de NEW et de ESTABLISHED (en
fait, je n'avais déjà rien compris en lisant les docs) mais le fait est
que là, ça marche impeccable !

Tant mieux si ce problème particulier est résolu, mais c'est ennuyeux
que vous n'ayez pas compris la gestion des états qui est décrit en long,
en large et en travers dans les différents documents que j'ai
mentionnés. C'est aussi très ennuyeux que vous exploitiez un firewall
dont vous ne maîtrisez pas le fonctionnement. Ici, c'était dans le "bon"
sens : des paquets qu'on veut laisser passer sont bloqués. Mais gare si
ça arrivait dans le "mauvais" sens : des paquets qu'on veut bloquer
passent grâce à une règle trop permissive ou mal placée.

"Annie D." <annie.demur@free.fr> a écrit sur fr.comp.reseaux.ip :

C'est l'option CONFIG_IP_NF_COMPAT_IPCHAINS à mettre à 'm' (module).

Oui, j'avais trouvé son nom, à l'époque, mais pas l'endroit où l'activer
dans la config. Enfin, maintenant que j'y suis prèsque avec iptables, je
ne vais quand même pas revenir à ipchaines !

Bien sur que j'ai la doc !

Laquelle ?

Je les avais récupéré en local, donc je ne sais plus trop d'où elle
viennent, mais la principale que j'ai utilisé pour essayer de comprendre
s'intitule « Linux Firewalls Using iptables », avec quelques liens vers
www.linuxhomenetworking.com, donc j'ai peut-etre récupéré ça là bas...

AMA, les indispensables sont le Packet-filtering-howto et l'excellent
"iptables tutorial" d'Oskar Andreasson que je garde toujours à portée de
main. Plus le NAT-howto pour ceux qui veulent mettre en place un routeur
NAT.

Je vais regarder ça ! Merci pour les références.

Et, bien entendu, une connaissance de la famille des protocoles IP est
indispensable pour savoir ce qu'on fait.

Quelle famille ? SMTP, POP3, etc... ou UDP, TCP, etc... ? Parce que la
différence entre UDP et RCP, je dois dire que j'ai jamais compris !
C'est grave ?...

Moi, mon principe est assez simple : je bloque tout, et quand je veux
utiliser un programme spécifique, je regarde dans les logs ce dont il a
besoin, et je débloque en conséquence. Comme ça, pas besoin de connaitre
la différence entre l'UDP et le TCP ;-)

En fait, marchait bien avec ipchains, mais plus avec iptables, parce que
les logs ne me disent pas ce que je dois mettre après --state, et c'est
bien là mon problème...

Ca fait plus de 3 mois que j'ai ce problème, donc j'ai eu le temps de la
lire ;-) Mais je n'y ai absolument rien compris...

Trois mois, ce n'est pas normal. Vous auriez pu venir plus tôt.

Ben je cherchais, avant ;-) Et comme je n'ai pas souvent le temps de
chercher, mes problèmes peuvent persister longtemps !

iptables -A OUTPUT -j DROP
iptables -A INPUT -j DROP

Elles sont placées où ces règles ? En fin de chaînes ?

Oui, bien sûr ! Je n'ai peut-etre pas tout saisi, mais il me semble
quand même que s'il y avait eu une règle après, elle n'aurait jamais pu
s'appliquer...

Tant mieux si ce problème particulier est résolu, mais c'est ennuyeux
que vous n'ayez pas compris la gestion des états qui est décrit en long,
en large et en travers dans les différents documents que j'ai
mentionnés.

J'espère effectivement que j'y verrais plus clair quand j'aurais lu ces
docs ! C'est à dire au moins dans un mois, vu que là c'est les vacances ;-)

Cela dit, sur les grands lignes, je comprends bien que NEW sert pour
dire qu'on peut initier une connexion dans le sens indiqué, et que
ESTABLISHED veut dire qu'on peut répondre sur une connexion déjà ouverte
(donc ouverte à priori dans l'autre sens), et que dont il vaut mieux
éviter les NEW sur INPUT tant qu'on n'en a pas besoin. Mais mon
problème, c'est que quand j'utilise un programme dont je ne connais pas
la façon de dialoguer, je ne sais absolument pas quoi ouvrir (qui parle
en premier ? sur quel port ? etc...)

C'est aussi très ennuyeux que vous exploitiez un firewall
dont vous ne maîtrisez pas le fonctionnement. Ici, c'était dans le "bon"
sens : des paquets qu'on veut laisser passer sont bloqués. Mais gare si
ça arrivait dans le "mauvais" sens : des paquets qu'on veut bloquer
passent grâce à une règle trop permissive ou mal placée.

Ca me semble pourtant mieux que de ne pas du tout utiliser de firewall,
non ?... ;-)

En tout cas, merci encore pour ces réponses !

Etienne de Tocqueville wrote:

Enfin, maintenant que j'y suis prèsque avec iptables, je
ne vais quand même pas revenir à ipchaines !

Excellente réaction !

Et, bien entendu, une connaissance de la famille des protocoles IP est
indispensable pour savoir ce qu'on fait.

Quelle famille ? SMTP, POP3, etc... ou UDP, TCP, etc... ? Parce que la
différence entre UDP et RCP, je dois dire que j'ai jamais compris !
C'est grave ?...

Un peu, quand même. Le "noyau dur" de base c'est le trio ICMP+UDP+TCP.
Ce n'est pas par hasard que ce sont ces protocoles qu'on retrouve dans
les options d'iptables et ipchains. La plupart des autres sont des
couches au-dessus de TCP ou UDP. Dans le firewall ils sont identifiés
par leur numéro de port TCP|UDP.

Moi, mon principe est assez simple : je bloque tout, et quand je veux
utiliser un programme spécifique, je regarde dans les logs ce dont il a
besoin, et je débloque en conséquence. Comme ça, pas besoin de connaitre
la différence entre l'UDP et le TCP ;-)

En fait, marchait bien avec ipchains, mais plus avec iptables, parce que
les logs ne me disent pas ce que je dois mettre après --state, et c'est
bien là mon problème...

Vous n'êtes pas du tout forcé d'utiliser les états de connexion, ce
n'est qu'une option. Vous pouvez dans un premier temps continuer à
écrire vos règles sans notion d'état comme avec ipchains pour vous
familiariser avec iptables.

Cela dit, sur les grands lignes, je comprends bien que NEW sert pour
dire qu'on peut initier une connexion dans le sens indiqué, et que
ESTABLISHED veut dire qu'on peut répondre sur une connexion déjà ouverte
(donc ouverte à priori dans l'autre sens), et que dont il vaut mieux
éviter les NEW sur INPUT tant qu'on n'en a pas besoin. Mais mon
problème, c'est que quand j'utilise un programme dont je ne connais pas
la façon de dialoguer, je ne sais absolument pas quoi ouvrir (qui parle
en premier ? sur quel port ? etc...)

Normalement, c'est la description du protocole concerné qui vous le dit.
Et pour les protocoles courants qui sont de type client-serveur (HTTP,
telnet, SMTP...), c'est simple : la connexion est à l'initiative du
client. Bon, il y a des cas particuliers comme FTP, c'est pour cela
qu'il existe un module de gestion spécifique à ce protocole dans le
suivi de connexion.

C'est aussi très ennuyeux que vous exploitiez un firewall
dont vous ne maîtrisez pas le fonctionnement.

Ca me semble pourtant mieux que de ne pas du tout utiliser de firewall,
non ?... ;-)

Ça se discute. Une machine ayant une pile IP et des services solides et
bien configurés ne devrait normalement pas avoir besoin de firewall.