From: Guillaume Morin <guillaume@morinfr.org>
To: Emmanuel Fleury <fleury@cs.auc.dk>
Cc: netfilter-devel@lists.samba.org
Subject: Re: Security flaw in Stateful filtering ??????
Date: Fri, 7 Jun 2002 15:33:00 +0200 [thread overview]
Message-ID: <20020607133300.GD595@morinfr.org> (raw)
In-Reply-To: <3D009951.5090004@cs.auc.dk>
Hi Emmanuel,
Dans un message du 07 jun à 13:30, Emmanuel Fleury écrivait :
> > the conntrack knows a connection is established -> ACK is matched as
> > ESTABLISHED
> >
> > the conntrack has seen no connection -> ACK is matched as NEW
>
> Actually, this is EXACTLY this behaviour which is surprising to me.
> Don't miss my point, I don't want this to be changed, but just
> writen in the definition of the states (eg in the packet-filtering
> HOWTO):
>
> NEW
>
> A packet which creates a new connection _or_a_ACK_packet_which_is
> _not_belonging_to_an_existing_connection(1).
>
Well, I understand your point. I know this is surprising. I really
thought it was in the FAQ or something.
I looked at the code and I was kind of wrong. Every untracked packets
are considered as NEW. That means that a syn/ack packet, a rst packet
will be matched as NEW. The documentation is correct because it means
the connection in the conntrack sense NOT in the TCP sense.
This is not a security flaw itself since when you allow NEW you always
allow the peer to scan you (syn, syn/ack, ack, whatever)
> > Of course ! This is what is done when an ACK packet is received and if
> > the conntrack can't find a related established connection.
>
> Are you sure ?
Yes.
> My students just told that they was no new connections after the ACK
> scanning...
That is logical. The scanner sends the ACK packet to the target machine.
The firewall let the packet pass. The target receives the bogus ACK
packet and sends back a RST packet. The firewall sees that and swith the
CONNECTION_CLOSE state which will be ripped off the connection table 10
seconds after that.
> What part of the code have we to look to see this ???@
see net/ipv4/netfilter/ip_conntrack_proto_tcp.c
> But, it looks like the ACK packets do not create new entry in the table
> (well, according to the proc/ thing at least).
It does create an entry.
HTH.
--
Guillaume Morin <guillaume@morinfr.org>
Sauvez un arbre, mangez un castor
next prev parent reply other threads:[~2002-06-07 13:33 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020606220914.A14542@groar.org>
2002-06-06 23:31 ` Security flaw in Stateful filtering ?????? Rusty Russell
2002-06-06 23:52 ` Joerg Mayer
2002-06-07 2:10 ` Rusty Russell
2002-06-07 2:53 ` Joerg Mayer
2002-06-07 12:45 ` Marcus Sundberg
2002-06-07 14:36 ` Henrik Nordstrom
2002-06-07 21:48 ` Ben Reser
2002-06-07 8:15 ` Emmanuel Fleury
2002-06-07 8:50 ` Oskar Andreasson
2002-06-07 12:27 ` Jozsef Kadlecsik
2002-06-10 8:04 ` Oskar Andreasson
2002-06-10 8:26 ` Emmanuel Fleury
2002-06-12 9:23 ` Jozsef Kadlecsik
2002-06-07 9:05 ` Henrik Nordstrom
2002-06-07 9:31 ` Emmanuel Fleury
2002-06-07 9:41 ` Oskar Andreasson
2002-06-07 9:43 ` Guillaume Morin
2002-06-07 9:57 ` Emmanuel Fleury
2002-06-07 10:17 ` Guillaume Morin
2002-06-07 11:30 ` Emmanuel Fleury
2002-06-07 13:33 ` Guillaume Morin [this message]
2002-06-07 15:13 ` Emmanuel Fleury
2002-06-07 18:36 ` Guillaume Morin
2002-06-07 19:00 ` Patrick Schaaf
2002-06-08 2:06 ` Emmanuel Fleury
2002-06-08 8:21 ` Patrick Schaaf
2002-06-08 12:02 ` Henrik Nordstrom
2002-06-09 7:03 ` Emmanuel Fleury
2002-06-09 8:29 ` Patrick Schaaf
2002-06-08 1:42 ` Emmanuel Fleury
2002-06-07 10:17 ` Henrik Nordstrom
2002-06-07 10:11 ` Henrik Nordstrom
2002-06-07 22:02 ` Ben Reser
2002-06-08 2:13 ` Emmanuel Fleury
2002-06-08 8:23 ` Patrick Schaaf
2002-06-08 16:41 ` Ben Reser
2002-06-08 9:07 ` ACK is NEW: Conclusion ? (was:Re: Security flaw in Stateful filtering ??????) Emmanuel Fleury
2002-06-07 9:42 Security flaw in Stateful filtering ?????? Mikkel Christiansen
2002-06-08 7:44 ` Harald Welte
-- strict thread matches above, loose matches on Subject: below --
2002-06-06 22:15 Andy Whitcroft
2002-06-06 19:29 Sneppe Filip
2002-06-06 17:21 Emmanuel Fleury
2002-06-06 17:48 ` Martin Josefsson
2002-06-06 17:54 ` Maciej Soltysiak
2002-06-06 18:52 ` Emmanuel Fleury
2002-06-06 19:11 ` Maciej Soltysiak
2002-06-06 19:30 ` Guillaume Morin
2002-06-06 19:53 ` Patrick Schaaf
2002-06-06 19:43 ` Henrik Nordstrom
2002-06-06 17:57 ` Patrick Schaaf
2002-06-06 18:34 ` Emmanuel Fleury
2002-06-06 19:12 ` Patrick Schaaf
2002-06-06 19:28 ` Emmanuel Fleury
2002-06-06 19:27 ` Henrik Nordstrom
2002-06-06 20:50 ` Emmanuel Fleury
2002-06-06 21:26 ` Henrik Nordstrom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020607133300.GD595@morinfr.org \
--to=guillaume@morinfr.org \
--cc=fleury@cs.auc.dk \
--cc=netfilter-devel@lists.samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.