* NEW vs INVALID @ 2002-09-30 10:18 Jens Lechtenbörger 2002-09-30 14:39 ` Anders Fugmann 2002-09-30 15:26 ` Cedric Blancher 0 siblings, 2 replies; 8+ messages in thread From: Jens Lechtenbörger @ 2002-09-30 10:18 UTC (permalink / raw) To: netfilter Hi there, using stateful packet matching I wonder how an INVALID tcp packet is defined. In particular, I set up a rule to log inbound NEW ssh connections to port 22: iptables -A INPUT -m state --state NEW -p TCP --dport 22 -j LOG --log-level 5 --log-prefix "IPTABLES: Legal NEW TCP: " What confuses me, is that this rule not only logs initial SYN packets but also (initial) packets with SYN and FIN set. I thought that such packets should be INVALID... Is this a bug or a feature? Jens ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NEW vs INVALID 2002-09-30 10:18 NEW vs INVALID Jens Lechtenbörger @ 2002-09-30 14:39 ` Anders Fugmann 2002-10-01 8:49 ` Cedric Blancher 2002-09-30 15:26 ` Cedric Blancher 1 sibling, 1 reply; 8+ messages in thread From: Anders Fugmann @ 2002-09-30 14:39 UTC (permalink / raw) To: Jens Lechtenbörger; +Cc: netfilter Jens Lechtenbörger wrote: > Hi there, > > using stateful packet matching I wonder how an INVALID tcp packet is > defined. In particular, I set up a rule to log inbound NEW ssh > connections to port 22: > iptables -A INPUT -m state --state NEW -p TCP --dport 22 -j LOG --log-level 5 --log-prefix "IPTABLES: Legal NEW TCP: " > > What confuses me, is that this rule not only logs initial SYN > packets but also (initial) packets with SYN and FIN set. > I thought that such packets should be INVALID... SYN-FIN??? Are you sure of this? I would suspect some ACK-FIN when the connection closes, but not SYN-FIN. Anyhow, AFAIK, the INVALID target only matches ackets which are malformed. a SYN-FIN packets is not malformed as such. (But yes, SYN-FIN is an illegal combination, and should be dropped, though this is not the purpose of the INVALID match (IMHO, this can easily be done using standard netfilter rules). Regards Anders Fugmann -- Neo: 'Can you fly that thing?' Trinity: 'Not yet'. $ apt-get install pilot-prg-v212helicopter. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NEW vs INVALID 2002-09-30 14:39 ` Anders Fugmann @ 2002-10-01 8:49 ` Cedric Blancher 2002-10-01 9:05 ` Anders Fugmann 0 siblings, 1 reply; 8+ messages in thread From: Cedric Blancher @ 2002-10-01 8:49 UTC (permalink / raw) To: Anders Fugmann; +Cc: Jens Lechtenbörger, netfilter Le lun 30/09/2002 à 16:39, Anders Fugmann a écrit : > Anyhow, AFAIK, the INVALID target only matches ackets which are > malformed. a SYN-FIN packets is not malformed as such. (But yes, SYN-FIN > is an illegal combination, and should be dropped, though this is not the > purpose of the INVALID match (IMHO, this can easily be done using > standard netfilter rules). By the way, I was wondering why --syn was "only" equivalent to : --tcp-flags SYN,ACK,RST SYN And not to : --tcp-flags SYN,ACK,RST,FIN SYN I know it is definitly easy to filter according to such criterias, but I was just wondering if there were a good reason why --syn should match such packets (maybe should have asked netfilter-devel). -- Cédric Blancher Consultant en sécurité des systèmes et réseaux - Cartel Sécurité Tél: +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99 PGP KeyID:157E98EE FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NEW vs INVALID 2002-10-01 8:49 ` Cedric Blancher @ 2002-10-01 9:05 ` Anders Fugmann 2002-10-01 11:19 ` Cedric Blancher 0 siblings, 1 reply; 8+ messages in thread From: Anders Fugmann @ 2002-10-01 9:05 UTC (permalink / raw) To: Cedric Blancher; +Cc: netfilter Cedric Blancher wrote: > By the way, I was wondering why --syn was "only" equivalent to : > --tcp-flags SYN,ACK,RST SYN > > And not to : > --tcp-flags SYN,ACK,RST,FIN SYN > The tcp-flags would then not match packets with the SYN & FIN bits set, which is actually connection request, with should be closed immdiatly after opening. The syn-fin is widly used to scan hosts, and should be dropped. But still - it is a connection request and should therfore be caught by --syn. Regards Anders Fugmann -- Neo: 'Can you fly that thing?' Trinity: 'Not yet'. $ apt-get install pilot-prg-v212helicopter. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NEW vs INVALID 2002-10-01 9:05 ` Anders Fugmann @ 2002-10-01 11:19 ` Cedric Blancher 0 siblings, 0 replies; 8+ messages in thread From: Cedric Blancher @ 2002-10-01 11:19 UTC (permalink / raw) To: Anders Fugmann; +Cc: netfilter Le mar 01/10/2002 à 11:05, Anders Fugmann a écrit : > Cedric Blancher wrote: > > By the way, I was wondering why --syn was "only" equivalent to : > > --tcp-flags SYN,ACK,RST SYN > > And not to : > > --tcp-flags SYN,ACK,RST,FIN SYN > The tcp-flags would then not match packets with the SYN & FIN bits set, > which is actually connection request, with should be closed immdiatly > after opening. Well, as SYN,FIN packet is quite nonsense, for a FIN is destined to close an established connection (both parts) or spot a connection establishment (client) and thus should not be received on CLOSED, LISTEN or SYN-SENT, for while connection is not established, server sends RST. But RFC does not cover the SYN,FIN case. Well, in fact, if we're in LISTEN state, we are likeley to stop processing flags when we see SYN set (and RST,ACK not set), and so do not check FIN bit value. But it tells that a FIN should be discarded if received on CLOSED, LISTEN or SYN-SENT state. | eighth, check the FIN bit, | | Do not process the FIN if the state is CLOSED, LISTEN or SYN-SENT | since the SEG.SEQ cannot be validated; drop the segment and | return. > The syn-fin is widly used to scan hosts, and should be > dropped. Yeah it surely should ;) By the way, this harmless, for there's no valid application for SYN,FIN packets. > But still - it is a connection request and should therfore be > caught by --syn. I do not agree on the meaning of such a packet, but it is true that RFC does not explicitly forbid this kind of flags setting, although it is clear that a --syn packet must have RST and ACK set to 0 (for RST and ACK value are checked _before_ SYN one). So, it can be understood this way, and this should close the debate. Ahhhh, the art of understanding RFCs :)))) -- Cédric Blancher Consultant en sécurité des systèmes et réseaux - Cartel Sécurité Tél: +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99 PGP KeyID:157E98EE FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NEW vs INVALID 2002-09-30 10:18 NEW vs INVALID Jens Lechtenbörger 2002-09-30 14:39 ` Anders Fugmann @ 2002-09-30 15:26 ` Cedric Blancher 2002-09-30 15:50 ` Jens Lechtenbörger 1 sibling, 1 reply; 8+ messages in thread From: Cedric Blancher @ 2002-09-30 15:26 UTC (permalink / raw) To: Jens Lechtenbörger; +Cc: netfilter Le lun 30/09/2002 à 12:18, Jens Lechtenbörger a écrit : > using stateful packet matching I wonder how an INVALID tcp packet is > defined. In particular, I set up a rule to log inbound NEW ssh > connections to port 22: > iptables -A INPUT -m state --state NEW -p TCP --dport 22 -j LOG > --log-level 5 --log-prefix "IPTABLES: Legal NEW TCP: " > What confuses me, is that this rule not only logs initial SYN > packets but also (initial) packets with SYN and FIN set. > I thought that such packets should be INVALID... > Is this a bug or a feature? Definitly a feature ;) States a completly different concept than TCP connection, for it must also apply to UDP, or other layer 4 protocols, which can be connectionless. A NEW packet is a packet for which Netfilter cannot find an existing state in conntrack table. This packet, if TCP, can be SYN, as it should, but also ACK, or any flag combination you want. This packet, if allowed, create a state that will match following packets. An INVALID packet is a packet for which Netfilter cannot guess its state. Most of the time, it is ICMP errors that cannot be associated (i.e. RELATED) to an existing connection. You can also have ressources lack or bugs. So, a packet why strange flags combination, such as SYN+FIN, is wrong from TCP point of vue, but is a valid packet from state tracking point of vue. This behaviour allows you to define exactly want you want to match. As an example, you can consider match Xmas or Null scans : iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL ALL -j LOG iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL NONE -j LOG To be strict, your iptables command should be : iptables -A INPUT -m state --state NEW -p TCP --dport 22 --syn -j LOG --log-level 5 --log-prefix "IPTABLES: Legal NEW TCP: " My 2 cents of euro. -- Cédric Blancher Consultant en sécurité des systèmes et réseaux - Cartel Sécurité Tél: +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99 PGP KeyID:157E98EE FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NEW vs INVALID 2002-09-30 15:26 ` Cedric Blancher @ 2002-09-30 15:50 ` Jens Lechtenbörger 2002-10-01 10:33 ` Martijn Klingens 0 siblings, 1 reply; 8+ messages in thread From: Jens Lechtenbörger @ 2002-09-30 15:50 UTC (permalink / raw) To: Cedric Blancher; +Cc: netfilter Cedric Blancher <blancher@cartel-securite.fr> writes: > States a completly different concept than TCP connection, for it must > also apply to UDP, or other layer 4 protocols, which can be > connectionless. > > A NEW packet is a packet for which Netfilter cannot find an existing > state in conntrack table. This packet, if TCP, can be SYN, as it should, > but also ACK, or any flag combination you want. This packet, if allowed, > create a state that will match following packets. > > An INVALID packet is a packet for which Netfilter cannot guess its > state. Most of the time, it is ICMP errors that cannot be associated > (i.e. RELATED) to an existing connection. You can also have ressources > lack or bugs. Thank you very much for this explanation! > [...] > > To be strict, your iptables command should be : > > iptables -A INPUT -m state --state NEW -p TCP --dport 22 --syn -j LOG --log-level 5 --log-prefix "IPTABLES: Legal NEW TCP: " > In fact, I had a similar command, but this again allows SYN+FIN-packets. What I am doing now is "--state NEW --tcp-flags SYN,ACK,FIN,RST SYN"... I was just wondering about the meaning of INVALID, which you explained above. Thanks again, Jens ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NEW vs INVALID 2002-09-30 15:50 ` Jens Lechtenbörger @ 2002-10-01 10:33 ` Martijn Klingens 0 siblings, 0 replies; 8+ messages in thread From: Martijn Klingens @ 2002-10-01 10:33 UTC (permalink / raw) To: netfilter On Monday 30 September 2002 17:50, Jens Lechtenbörger wrote: > In fact, I had a similar command, but this again allows > SYN+FIN-packets. > > What I am doing now is > > "--state NEW --tcp-flags SYN,ACK,FIN,RST SYN"... This makes quite some sense, but it makes me wonder what the use is of the '--syn' option. Also, does that mean I have to update my firewall script if I want to achieve tighter security? I guess so :( -- Martijn ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-10-01 11:19 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-09-30 10:18 NEW vs INVALID Jens Lechtenbörger 2002-09-30 14:39 ` Anders Fugmann 2002-10-01 8:49 ` Cedric Blancher 2002-10-01 9:05 ` Anders Fugmann 2002-10-01 11:19 ` Cedric Blancher 2002-09-30 15:26 ` Cedric Blancher 2002-09-30 15:50 ` Jens Lechtenbörger 2002-10-01 10:33 ` Martijn Klingens
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.