All of lore.kernel.org
 help / color / mirror / Atom feed
From: Emmanuel Fleury <fleury@cs.auc.dk>
To: netfilter-devel@lists.samba.org
Subject: Re: Security flaw in Stateful filtering ??????
Date: Fri, 07 Jun 2002 11:57:51 +0200	[thread overview]
Message-ID: <3D00839F.6000103@cs.auc.dk> (raw)
In-Reply-To: 20020607094319.GA595@morinfr.org

Guillaume Morin wrote:
> Dans un message du 07 jun à 11:31, Emmanuel Fleury écrivait :
> 
>>>iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>>>iptables -A FORWARD -i eth0 -j ACCEPT
>>>iptables -A FORWARD -j DROP
>>
>>Does that mean that you DROP all the ACKs, even those which are valid
> 
> Of course not, the ACKs packets are matched by --state ESTABLISHED since
> they do correspond to an established connection. When ACK packets are
> matched as NEW, that means that they do NOT correpond to an established
> connection in the conntrack.

Ok !!! I see the light now. :-)

Does this means that you are mapping the packets to a state (NEW,
ESTABLISHED, RELATED, INVALID) only based on information on their
header and a query to the connection table ? And that you do not
care about the previous state of the connection ?

At least, it doesn't seems to be necessary to take care of the previous
state of the connection in this case.

Moreover, is it possible to create an entry in the connection table
just by sending an ACK ??? (somebody wrote this at some point).


Finally, I tried to think about this 'connection pick-up' thing and
I really don't understand how do you can restore a connection after
the reboot. What is the algorithm which is used for this ?
(My problem is that in the case of a NAT, you can receive an ACK packet
on your FORWARD chain coming from outside and you have to translate
it to your inner network. But you lost all the informations about it).

-- 
Emmanuel

And I'm right. I'm always right, but in this case
I'm just a bit more right than I usually am.
   -- Linus Torvalds

  reply	other threads:[~2002-06-07  9:57 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 [this message]
2002-06-07 10:17             ` Guillaume Morin
2002-06-07 11:30               ` Emmanuel Fleury
2002-06-07 13:33                 ` Guillaume Morin
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=3D00839F.6000103@cs.auc.dk \
    --to=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.