Dans la manpage d'iptables, à la description de l'option --syn il est
écrit :
--syn
Only match TCP packets with the SYN bit set and the
ACK and FIN bits cleared. [...] It is equivalent
to --tcp-flags SYN,RST,ACK SYN.
Visiblement, il y a une incohérence entre la première phrase (ACK et FIN
à 0) et la deuxième (ACK et RST à 0). Ça m'étonne un peu depuis le temps
que cette doc existe. Concernant iptables, un "iptables -vL" montre que
c'est la deuxième qui a raison. Mais du point de vue du protocole TCP
(dont je ne maîtrise pas ces subtilités), laquelle serait la plus
logique pour reconnaître un paquet initiant une connexion ?
La première : SYN=1 ACK=0 FIN=0 ?
La seconde : SYN=1 ACK=0 RST=0 ?
Ou une autre, comme par exemple : SYN=1 ACK=0 FIN=0 RST=0 ?
Mais du point de vue du protocole TCP (dont je ne maîtrise pas ces subtilités), laquelle serait la plus logique pour reconnaître un paquet initiant une connexion ? La première : SYN=1 ACK=0 FIN=0 ? La seconde : SYN=1 ACK=0 RST=0 ?
La seconde. L'examen du bit FIN arrive après celui du bit du bit SYN dans la cinétique TCP, ce qui veut dire que si ce dernier est positionné, alors la valeur du bit FIN sera ignorée.
La première ne va pas dans la mesure où ce paquet pourrait avoir RST=1. Or ce type de paquet sera traité comme un RST, et non comme un SYN.
Ou une autre, comme par exemple : SYN=1 ACK=0 FIN=0 RST=0 ?
En tout état de cause, un "paquet SYN" proprement généré ne doit pas avoir son bit FIN positionné et donc répondre à cette dernière définition. Mais si on veut être cohérent avec la RFC, alors le bit FIN ne devrait pas être examiné. Ceci dit, pas mal de gens filtre avec ça et ne s'en portent pas plus mal :)
-- BOFH excuse #231:
We had to turn off that service to comply with the CDA Bill.
Le Sat, 20 Nov 2004 17:16:22 +0100, Pascal@plouf a écrit :
Mais du point de vue du protocole TCP (dont je ne maîtrise pas ces
subtilités), laquelle serait la plus logique pour reconnaître un
paquet initiant une connexion ?
La première : SYN=1 ACK=0 FIN=0 ?
La seconde : SYN=1 ACK=0 RST=0 ?
La seconde.
L'examen du bit FIN arrive après celui du bit du bit SYN dans la
cinétique TCP, ce qui veut dire que si ce dernier est positionné, alors
la valeur du bit FIN sera ignorée.
La première ne va pas dans la mesure où ce paquet pourrait avoir RST=1.
Or ce type de paquet sera traité comme un RST, et non comme un SYN.
Ou une autre, comme par exemple : SYN=1 ACK=0 FIN=0 RST=0 ?
En tout état de cause, un "paquet SYN" proprement généré ne doit pas
avoir son bit FIN positionné et donc répondre à cette dernière
définition. Mais si on veut être cohérent avec la RFC, alors le bit FIN
ne devrait pas être examiné. Ceci dit, pas mal de gens filtre avec ça
et ne s'en portent pas plus mal :)
--
BOFH excuse #231:
We had to turn off that service to comply with the CDA Bill.
Mais du point de vue du protocole TCP (dont je ne maîtrise pas ces subtilités), laquelle serait la plus logique pour reconnaître un paquet initiant une connexion ? La première : SYN=1 ACK=0 FIN=0 ? La seconde : SYN=1 ACK=0 RST=0 ?
La seconde. L'examen du bit FIN arrive après celui du bit du bit SYN dans la cinétique TCP, ce qui veut dire que si ce dernier est positionné, alors la valeur du bit FIN sera ignorée.
La première ne va pas dans la mesure où ce paquet pourrait avoir RST=1. Or ce type de paquet sera traité comme un RST, et non comme un SYN.
Ou une autre, comme par exemple : SYN=1 ACK=0 FIN=0 RST=0 ?
En tout état de cause, un "paquet SYN" proprement généré ne doit pas avoir son bit FIN positionné et donc répondre à cette dernière définition. Mais si on veut être cohérent avec la RFC, alors le bit FIN ne devrait pas être examiné. Ceci dit, pas mal de gens filtre avec ça et ne s'en portent pas plus mal :)
-- BOFH excuse #231:
We had to turn off that service to comply with the CDA Bill.
Pascal
Cedric Blancher wrote:
laquelle serait la plus logique pour reconnaître un paquet initiant une connexion ? La première : SYN=1 ACK=0 FIN=0 ? La seconde : SYN=1 ACK=0 RST=0 ?
La seconde.
Merci de cette réponse fort claire. Je sais maintenant que je peux continuer à faire confiance à l'option --syn, et pourquoi.
J'ai une autre question sur iptables. Dans plusieurs documents comme http://www.hsc.fr/ressources/presentations/netfilter-2.4/netfilter.htm.fr j'ai lu qu'un paquet TCP RST corespondant à un connexion existante était vu comme RELATED alors que mes observations avec un noyau 2.4.18 semblent plutôt indiquer qu'il est vu comme ESTABLISHED (ce qui me semble plus logique). Alors, qui a raison ?
Cedric Blancher wrote:
laquelle serait la plus logique pour reconnaître un
paquet initiant une connexion ?
La première : SYN=1 ACK=0 FIN=0 ?
La seconde : SYN=1 ACK=0 RST=0 ?
La seconde.
Merci de cette réponse fort claire. Je sais maintenant que je peux
continuer à faire confiance à l'option --syn, et pourquoi.
J'ai une autre question sur iptables. Dans plusieurs documents comme
http://www.hsc.fr/ressources/presentations/netfilter-2.4/netfilter.htm.fr
j'ai lu qu'un paquet TCP RST corespondant à un connexion existante était
vu comme RELATED alors que mes observations avec un noyau 2.4.18
semblent plutôt indiquer qu'il est vu comme ESTABLISHED (ce qui me
semble plus logique). Alors, qui a raison ?
laquelle serait la plus logique pour reconnaître un paquet initiant une connexion ? La première : SYN=1 ACK=0 FIN=0 ? La seconde : SYN=1 ACK=0 RST=0 ?
La seconde.
Merci de cette réponse fort claire. Je sais maintenant que je peux continuer à faire confiance à l'option --syn, et pourquoi.
J'ai une autre question sur iptables. Dans plusieurs documents comme http://www.hsc.fr/ressources/presentations/netfilter-2.4/netfilter.htm.fr j'ai lu qu'un paquet TCP RST corespondant à un connexion existante était vu comme RELATED alors que mes observations avec un noyau 2.4.18 semblent plutôt indiquer qu'il est vu comme ESTABLISHED (ce qui me semble plus logique). Alors, qui a raison ?
Cedric Blancher
Le Mon, 22 Nov 2004 13:47:23 +0100, a écrit :
J'ai une autre question sur iptables. Dans plusieurs documents comme http://www.hsc.fr/ressources/presentations/netfilter-2.4/netfilter.htm.fr j'ai lu qu'un paquet TCP RST corespondant à un connexion existante était vu comme RELATED alors que mes observations avec un noyau 2.4.18 semblent plutôt indiquer qu'il est vu comme ESTABLISHED (ce qui me semble plus logique). Alors, qui a raison ?
Je pense que le RST est vu comme ESTABLISHED. Mais je ne le jurerai pas.
-- EF> Je veux savoir si tout ce monde a posté sur les groupes votés. Tu veux montrer quelque chose de précis, ou tu cherches seulement à t'enfoncer encore un peu plus? -+-AG in : Guide du Neuneu d'Usenet - Parlez lui avec tendresse -+-
Le Mon, 22 Nov 2004 13:47:23 +0100, Pascal@plouf a écrit :
J'ai une autre question sur iptables. Dans plusieurs documents comme
http://www.hsc.fr/ressources/presentations/netfilter-2.4/netfilter.htm.fr
j'ai lu qu'un paquet TCP RST corespondant à un connexion existante était
vu comme RELATED alors que mes observations avec un noyau 2.4.18
semblent plutôt indiquer qu'il est vu comme ESTABLISHED (ce qui me
semble plus logique). Alors, qui a raison ?
Je pense que le RST est vu comme ESTABLISHED. Mais je ne le jurerai pas.
--
EF> Je veux savoir si tout ce monde a posté sur les groupes votés.
Tu veux montrer quelque chose de précis, ou tu cherches seulement à
t'enfoncer encore un peu plus?
-+-AG in : Guide du Neuneu d'Usenet - Parlez lui avec tendresse -+-
J'ai une autre question sur iptables. Dans plusieurs documents comme http://www.hsc.fr/ressources/presentations/netfilter-2.4/netfilter.htm.fr j'ai lu qu'un paquet TCP RST corespondant à un connexion existante était vu comme RELATED alors que mes observations avec un noyau 2.4.18 semblent plutôt indiquer qu'il est vu comme ESTABLISHED (ce qui me semble plus logique). Alors, qui a raison ?
Je pense que le RST est vu comme ESTABLISHED. Mais je ne le jurerai pas.
-- EF> Je veux savoir si tout ce monde a posté sur les groupes votés. Tu veux montrer quelque chose de précis, ou tu cherches seulement à t'enfoncer encore un peu plus? -+-AG in : Guide du Neuneu d'Usenet - Parlez lui avec tendresse -+-
Pascal
Cedric Blancher wrote:
j'ai lu qu'un paquet TCP RST corespondant à un connexion existante était vu comme RELATED alors que mes observations avec un noyau 2.4.18 semblent plutôt indiquer qu'il est vu comme ESTABLISHED (ce qui me semble plus logique). Alors, qui a raison ?
Je pense que le RST est vu comme ESTABLISHED. Mais je ne le jurerai pas.
Je le pense aussi, mais comment s'en assurer ? J'étais un peu par hasard tombé sur un doc sur le web émanant de l'équipe de développement de Netfilter qui en parlait, disant que ce serait préférable que le RST soit RELATED parce que ce serait plus cohérent avec les messages d'erreur ICMP. Mais impossible de remettre la main dessus. Ou alors ce n'était qu'un mauvais rêve...
Cedric Blancher wrote:
j'ai lu qu'un paquet TCP RST corespondant à un connexion existante était
vu comme RELATED alors que mes observations avec un noyau 2.4.18
semblent plutôt indiquer qu'il est vu comme ESTABLISHED (ce qui me
semble plus logique). Alors, qui a raison ?
Je pense que le RST est vu comme ESTABLISHED. Mais je ne le jurerai pas.
Je le pense aussi, mais comment s'en assurer ? J'étais un peu par hasard
tombé sur un doc sur le web émanant de l'équipe de développement de
Netfilter qui en parlait, disant que ce serait préférable que le RST
soit RELATED parce que ce serait plus cohérent avec les messages
d'erreur ICMP. Mais impossible de remettre la main dessus. Ou alors ce
n'était qu'un mauvais rêve...
j'ai lu qu'un paquet TCP RST corespondant à un connexion existante était vu comme RELATED alors que mes observations avec un noyau 2.4.18 semblent plutôt indiquer qu'il est vu comme ESTABLISHED (ce qui me semble plus logique). Alors, qui a raison ?
Je pense que le RST est vu comme ESTABLISHED. Mais je ne le jurerai pas.
Je le pense aussi, mais comment s'en assurer ? J'étais un peu par hasard tombé sur un doc sur le web émanant de l'équipe de développement de Netfilter qui en parlait, disant que ce serait préférable que le RST soit RELATED parce que ce serait plus cohérent avec les messages d'erreur ICMP. Mais impossible de remettre la main dessus. Ou alors ce n'était qu'un mauvais rêve...
Cedric Blancher
Le Mon, 22 Nov 2004 23:01:32 +0100, a écrit :
Je le pense aussi, mais comment s'en assurer ? J'étais un peu par hasard tombé sur un doc sur le web émanant de l'équipe de développement de Netfilter qui en parlait, disant que ce serait préférable que le RST soit RELATED parce que ce serait plus cohérent avec les messages d'erreur ICMP. Mais impossible de remettre la main dessus. Ou alors ce n'était qu'un mauvais rêve...
iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state RELATED -j LOG --log-prefix RST_REL iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED -j LOG --log-prefix RST_EST
Et tu t'amuses à générer des RST sur des connexions valides en coupant à la sauvage...
-- BC> désolé, mais j'ai pas pû m'empecher. On a vu, mais bon, vraiment fallait pas, vous ne manquiez pas encore assez. -+- RM in <http://neuneu.mine.nu> : En période de manque -+-
Le Mon, 22 Nov 2004 23:01:32 +0100, Pascal@plouf a écrit :
Je le pense aussi, mais comment s'en assurer ? J'étais un peu par hasard
tombé sur un doc sur le web émanant de l'équipe de développement de
Netfilter qui en parlait, disant que ce serait préférable que le RST
soit RELATED parce que ce serait plus cohérent avec les messages
d'erreur ICMP. Mais impossible de remettre la main dessus. Ou alors ce
n'était qu'un mauvais rêve...
iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state RELATED
-j LOG --log-prefix RST_REL
iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED
-j LOG --log-prefix RST_EST
Et tu t'amuses à générer des RST sur des connexions valides en coupant
à la sauvage...
--
BC> désolé, mais j'ai pas pû m'empecher.
On a vu, mais bon, vraiment fallait pas, vous ne manquiez pas encore
assez.
-+- RM in <http://neuneu.mine.nu> : En période de manque -+-
Je le pense aussi, mais comment s'en assurer ? J'étais un peu par hasard tombé sur un doc sur le web émanant de l'équipe de développement de Netfilter qui en parlait, disant que ce serait préférable que le RST soit RELATED parce que ce serait plus cohérent avec les messages d'erreur ICMP. Mais impossible de remettre la main dessus. Ou alors ce n'était qu'un mauvais rêve...
iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state RELATED -j LOG --log-prefix RST_REL iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED -j LOG --log-prefix RST_EST
Et tu t'amuses à générer des RST sur des connexions valides en coupant à la sauvage...
-- BC> désolé, mais j'ai pas pû m'empecher. On a vu, mais bon, vraiment fallait pas, vous ne manquiez pas encore assez. -+- RM in <http://neuneu.mine.nu> : En période de manque -+-
Pascal
Cedric Blancher wrote:
Je le pense aussi, mais comment s'en assurer ?
iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state RELATED -j LOG --log-prefix RST_REL iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED -j LOG --log-prefix RST_EST
Et tu t'amuses à générer des RST sur des connexions valides en coupant à la sauvage...
Oui, c'est comme ça que j'avais fait pour constater que les RST tombaient dans l'état ESTABLISHED. Mais ce n'est qu'empirique, rien ne dit que ça n'a pas changé sur des noyaux plus récents et je ne suis pas sûr de traiter tous les cas possible (je suis même sûr du contraire). D'ailleurs mes RST étaient juste ceux émis en réponse à des SYN sur des ports fermés, pas sur des connexions entièrement établies.
Cedric Blancher wrote:
Je le pense aussi, mais comment s'en assurer ?
iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state RELATED
-j LOG --log-prefix RST_REL
iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED
-j LOG --log-prefix RST_EST
Et tu t'amuses à générer des RST sur des connexions valides en coupant
à la sauvage...
Oui, c'est comme ça que j'avais fait pour constater que les RST
tombaient dans l'état ESTABLISHED. Mais ce n'est qu'empirique, rien ne
dit que ça n'a pas changé sur des noyaux plus récents et je ne suis pas
sûr de traiter tous les cas possible (je suis même sûr du contraire).
D'ailleurs mes RST étaient juste ceux émis en réponse à des SYN sur des
ports fermés, pas sur des connexions entièrement établies.
iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state RELATED -j LOG --log-prefix RST_REL iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED -j LOG --log-prefix RST_EST
Et tu t'amuses à générer des RST sur des connexions valides en coupant à la sauvage...
Oui, c'est comme ça que j'avais fait pour constater que les RST tombaient dans l'état ESTABLISHED. Mais ce n'est qu'empirique, rien ne dit que ça n'a pas changé sur des noyaux plus récents et je ne suis pas sûr de traiter tous les cas possible (je suis même sûr du contraire). D'ailleurs mes RST étaient juste ceux émis en réponse à des SYN sur des ports fermés, pas sur des connexions entièrement établies.
Cedric Blancher
Le Wed, 24 Nov 2004 00:47:14 +0100, a écrit :
Mais ce n'est qu'empirique, rien ne dit que ça n'a pas changé sur des noyaux plus récents et je ne suis pas sûr de traiter tous les cas possible (je suis même sûr du contraire). D'ailleurs mes RST étaient juste ceux émis en réponse à des SYN sur des ports fermés, pas sur des connexions entièrement établies.
Then use the source, Luke. Use the source...
--
Le neuneu est un con qui débute. C'est une espèce rare mais qui fait beaucoup de bruit. -+- JCD in Guide du Linuxien pervers - Bien configurer son neuneu.
Le Wed, 24 Nov 2004 00:47:14 +0100, Pascal@plouf a écrit :
Mais ce n'est qu'empirique, rien ne dit que ça n'a pas changé sur des
noyaux plus récents et je ne suis pas sûr de traiter tous les cas
possible (je suis même sûr du contraire). D'ailleurs mes RST étaient
juste ceux émis en réponse à des SYN sur des ports fermés, pas sur
des connexions entièrement établies.
Then use the source, Luke. Use the source...
--
Le neuneu est un con qui débute. C'est une espèce rare mais qui fait
beaucoup de bruit.
-+- JCD in Guide du Linuxien pervers - Bien configurer son neuneu.
Mais ce n'est qu'empirique, rien ne dit que ça n'a pas changé sur des noyaux plus récents et je ne suis pas sûr de traiter tous les cas possible (je suis même sûr du contraire). D'ailleurs mes RST étaient juste ceux émis en réponse à des SYN sur des ports fermés, pas sur des connexions entièrement établies.
Then use the source, Luke. Use the source...
--
Le neuneu est un con qui débute. C'est une espèce rare mais qui fait beaucoup de bruit. -+- JCD in Guide du Linuxien pervers - Bien configurer son neuneu.
Pascal
Cedric Blancher wrote:
Mais ce n'est qu'empirique, rien ne dit que ça n'a pas changé sur des noyaux plus récents et je ne suis pas sûr de traiter tous les cas possible (je suis même sûr du contraire). D'ailleurs mes RST étaient juste ceux émis en réponse à des SYN sur des ports fermés, pas sur des connexions entièrement établies.
Then use the source, Luke. Use the source...
Aïe, la réponse que je ne voulais pas lire :-( Blague à part, lire les sources d'UNE version du noyau (je vais quand même pas tous me les taper), à supposer que je sache m'y retrouver, ne me garantit pas que les développeurs n'auront pas changé d'idée dans une version ultérieure.
Cedric Blancher wrote:
Mais ce n'est qu'empirique, rien ne dit que ça n'a pas changé sur des
noyaux plus récents et je ne suis pas sûr de traiter tous les cas
possible (je suis même sûr du contraire). D'ailleurs mes RST étaient
juste ceux émis en réponse à des SYN sur des ports fermés, pas sur
des connexions entièrement établies.
Then use the source, Luke. Use the source...
Aïe, la réponse que je ne voulais pas lire :-(
Blague à part, lire les sources d'UNE version du noyau (je vais quand
même pas tous me les taper), à supposer que je sache m'y retrouver, ne
me garantit pas que les développeurs n'auront pas changé d'idée dans une
version ultérieure.
Mais ce n'est qu'empirique, rien ne dit que ça n'a pas changé sur des noyaux plus récents et je ne suis pas sûr de traiter tous les cas possible (je suis même sûr du contraire). D'ailleurs mes RST étaient juste ceux émis en réponse à des SYN sur des ports fermés, pas sur des connexions entièrement établies.
Then use the source, Luke. Use the source...
Aïe, la réponse que je ne voulais pas lire :-( Blague à part, lire les sources d'UNE version du noyau (je vais quand même pas tous me les taper), à supposer que je sache m'y retrouver, ne me garantit pas que les développeurs n'auront pas changé d'idée dans une version ultérieure.
Cedric Blancher
Le Thu, 25 Nov 2004 00:43:19 +0100, a écrit :
Aïe, la réponse que je ne voulais pas lire :-(
C'est pour ça que je l'ai écrite :)
Blague à part, lire les sources d'UNE version du noyau (je vais quand même pas tous me les taper), à supposer que je sache m'y retrouver, ne me garantit pas que les développeurs n'auront pas changé d'idée dans une version ultérieure.
En lisant la liste netfilter-devel, tu verras passer tous les patches, en particulier ceux acceptés par Dave Miller, et par conséquent tous les changements de comportement.
-- On m'a souvent dit que Club-Internet censurait les groupes (des abonnés de Wanadoo, notamment ;-), mais apparemment ce seraient "les webmasters" qui seraient responsables (?) de cette intervention ; -+- G in : Guide du Neuneu Usenetien - Tout est dans tout -+-
Le Thu, 25 Nov 2004 00:43:19 +0100, Pascal@plouf a écrit :
Aïe, la réponse que je ne voulais pas lire :-(
C'est pour ça que je l'ai écrite :)
Blague à part, lire les sources d'UNE version du noyau (je vais quand
même pas tous me les taper), à supposer que je sache m'y retrouver, ne
me garantit pas que les développeurs n'auront pas changé d'idée dans une
version ultérieure.
En lisant la liste netfilter-devel, tu verras passer tous les patches,
en particulier ceux acceptés par Dave Miller, et par conséquent tous les
changements de comportement.
--
On m'a souvent dit que Club-Internet censurait les groupes (des
abonnés de Wanadoo, notamment ;-), mais apparemment ce seraient "les
webmasters" qui seraient responsables (?) de cette intervention ;
-+- G in : Guide du Neuneu Usenetien - Tout est dans tout -+-
Blague à part, lire les sources d'UNE version du noyau (je vais quand même pas tous me les taper), à supposer que je sache m'y retrouver, ne me garantit pas que les développeurs n'auront pas changé d'idée dans une version ultérieure.
En lisant la liste netfilter-devel, tu verras passer tous les patches, en particulier ceux acceptés par Dave Miller, et par conséquent tous les changements de comportement.
-- On m'a souvent dit que Club-Internet censurait les groupes (des abonnés de Wanadoo, notamment ;-), mais apparemment ce seraient "les webmasters" qui seraient responsables (?) de cette intervention ; -+- G in : Guide du Neuneu Usenetien - Tout est dans tout -+-
Pascal
Cedric Blancher wrote:
En lisant la liste netfilter-devel, tu verras passer tous les patches, en particulier ceux acceptés par Dave Miller, et par conséquent tous les changements de comportement.
Il n'y aurait pas plutôt des spécs fonctionnelles ? Ils codent bien d'après des spécs, non ? Non ? Aaaaaaaaaaaaaaaaaaaaaaah !
Cedric Blancher wrote:
En lisant la liste netfilter-devel, tu verras passer tous les patches,
en particulier ceux acceptés par Dave Miller, et par conséquent tous les
changements de comportement.
Il n'y aurait pas plutôt des spécs fonctionnelles ? Ils codent bien
d'après des spécs, non ? Non ? Aaaaaaaaaaaaaaaaaaaaaaah !
En lisant la liste netfilter-devel, tu verras passer tous les patches, en particulier ceux acceptés par Dave Miller, et par conséquent tous les changements de comportement.
Il n'y aurait pas plutôt des spécs fonctionnelles ? Ils codent bien d'après des spécs, non ? Non ? Aaaaaaaaaaaaaaaaaaaaaaah !
