[EMAIL PROTECTED]
To: Oskar Andreasson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, June 07, 2002 2:27 PM
Subject: Re: Security flaw in Stateful filtering ??
On Fri, 7 Jun 2002, Oskar Andreasson wrote:
Another, related, usage is
if we have a redundant firewall (I haven't seen
Hi Oskar,
Oskar Andreasson wrote:
My proposal was to create a way of doing more secure, and
stateful, redundancy mechanism. For example, 2 or more firewalls
which shares their conntrack tables via some userspace daemons.
This would require the daemon to have read/write access to the
Alternatively, if no answer comes back at all, the conntrack is in the
(extra) state UNREPLIED. When the connection table becomes full, UNREPLIED
connections are recycled preferentially.
Hey, this is not fair !
The behaviour is as fair as it can be, IMO.
This behaviour is not
My point is not to go on and on and on, but deeper and deeper
and deeper. Once I reach to right amount of knowledge about it,
I will fix it (or I will make it so clear that anybody which
has followed the thread will be abble to fix it).
The latter approach won't be effective. You want a
Hi all,
Ok, let's conclude this thread.
What was the initial problem ?:
---
FAQ: Some invalid ACK packets are going through my firewall !!!
By reading the current documentation, most of the people are assuming
that there is a perfect match between the states of
On Sat, Jun 08, 2002 at 04:13:58AM +0200, Emmanuel Fleury wrote:
If I have to fix the documentation, I would like to understand the
exact behaviour of the connection tracking module.
My point is not to go on and on and on, but deeper and deeper
and deeper. Once I reach to right amount of
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
Emmanuel Fleury wrote:
Henrik Nordstrom wrote:
This configuration can be done just fine with iptables as demonstrated in
my earlier message, but here we go again (but slightly different):
# Allow existing connections
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Emmanuel Fleury wrote:
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 ?
No,
Guillaume Morin wrote:
I really do not understand what you mean. The conntrack stores the
previous state of TCP connection. So indeed when a packet arrives, it
checks the information of the TCP and IP headers and tries to see if
there is something stored about this TCP connection.
On Fri, 7 Jun 2002, Oskar Andreasson wrote:
Another, related, usage is
if we have a redundant firewall (I haven't seen this discussed so far
so Consider this:
1 main firewall
1 router
and a secondary firewall.
The three are set up in a routing zone. If the main firewall goes
down,
Joerg Mayer [EMAIL PROTECTED] writes:
On Fri, Jun 07, 2002 at 12:10:09PM +1000, Rusty Russell wrote:
If their firewall reboots and is running iptables and thus Linux: How
long will it be down?
120 seconds to reboot with a fixed kernel...
Umm, OK, I shouldn't have compared the
Rusty Russell wrote:
If their firewall reboots and is running iptables and thus Linux: How
long will it be down?
120 seconds to reboot with a fixed kernel...
More like 20 seconds with a standard modular kernel for firewall boxes with a
slimmed OS running on commodity hardware..
With a
Hi,
Guillaume Morin wrote:
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.
Yes, I just checked it in the piece of code you pointed out (see below).
The documentation is
Hi Emmanuel,
Dans un message du 07 Jun à 17:13, Emmanuel Fleury écrivait :
The documentation is correct because it means
the connection in the conntrack sense NOT in the TCP sense.
I disagree on this point. The documentation is not correct.
Or, at least, the documentation is not precise
The funny thing is that if you have a bad ruleset, you can easily be
DOSed by some external people which are just sending random ACK packets.
Those ACKs will create entries in your connection table as ESTABLISHED
connections with a time-out of 5 days ! 8-)
Well no, since the
On Fri, Jun 07, 2002 at 10:15:26AM +0200, Emmanuel Fleury wrote:
Precisely.
Actually, my exact complain is now that the documentation is not
making you awared of what you are exactly doing...
Somehow, this is dangerous and can lead you to have a flaw in your
firewall without being awared
Hi Guillaume,
Guillaume Morin wrote:
The documentation is correct because it assumes you understand
connection as a conntrack entry.
Hum.
I do agree that it should be more explicit.
We met an agreement so.
The funny thing is that if you have a bad ruleset, you can easily be
DOSed by
Patrick Schaaf wrote:
The funny thing is that if you have a bad ruleset, you can easily be
DOSed by some external people which are just sending random ACK packets.
Those ACKs will create entries in your connection table as ESTABLISHED
connections with a time-out of 5 days ! 8-)
Well no,
Hi,
I am co-supervising students in Aalborg university on a project
about firewalls (and more precisely about stateful firewalling)
in collaboration with Mikkel Christiansen.
Recently, they were testing some of their ideas to improve the
connection tracking module of Netfilter in the university
On Thu, 2002-06-06 at 19:21, Emmanuel Fleury wrote:
[snip]
I am just quoting their mail here:
[snip again]
For short:
- ACK packets are classified as NEW (without opening a connection),
- Therefore, allowing NEW packets allow all the ACK packets to go
through,
- And consequently, in
Hello,
iptables -A FORWARD -p tcp -m state --state NEW -j ACCEPT
The Problem:
When sending an ACK packet, the packet is allowed through the filter.
Due to the second rule. This means that ACK packets are accepted as
being in the state NEW and does not create an entry in the
Hi,
Patrick Schaaf wrote:
The problem has been reported here several times, already.
Sorry, I should have browse the archive more carefully.
The behaviour is intentional. The reason is connection pickup. Imagine
a situation where the firewall reboots. All active conntracking information
Maciej Soltysiak wrote:
Hi,
A Solution:
---
As a temporary hack the following rule can be added as the second rule:
iptables -A FORWARD -p tcp --tcp-flags ACK ACK -j DROP
Well, i think everybody who gets to that point uses:
iptables -A FORWARD -p tcp -m state --state NEW --syn
The behaviour is intentional. The reason is connection pickup. Imagine
a situation where the firewall reboots. All active conntracking information
will be lost. With the observed behaviour, connections are relearned
on the fly as they create new traffic.
I simply disagree with you on
Title: RE: Security flaw in Stateful filtering ??
Yes, it's that time of the month again :-)
Emmanuel Fleury [mailto:[EMAIL PROTECTED]] wrote:
Patrick Schaaf wrote:
The behaviour is intentional. The reason is connection pickup. Imagine
a situation where the firewall reboots. All
Emmanuel Fleury wrote:
So, what are the INVALID packets ?
Packets where it is impossible to identify a session key to use when matching
reply packets as belonging to the same session. This is mostly malformed
packets.
I think RST of a non-existing session also classifies as INVALID, but
Henrik Nordstrom wrote:
And exactly what is the flaw here? What is it that your firewall ruleset is
trying to achieve?
Ok, a 'flaw' is not exactly matching with this. Now that I am more
awared of the problem, I can describe this as: an under-specified
feature which can lead the user to have
Emmanuel Fleury wrote:
The core of the problem seems to be a conflict between two features:
1) The existing connections shouldn't be stopped when you change the
rules of your firewall at run time (something which occur much more
often than the reboot of one firewall).
2) The
If I understand correctly what is being said is that if
an ACK only packet passes the firewall for a connection
which is otherwise unknown a lost connection is assumed
and the connection will be reaquired, ie become valid
and allow reply packets to be treated as ESTABLISHED from
a contrack point
In message [EMAIL PROTECTED] you write:
iptables -A FORWARD -p tcp -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -p tcp -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp -j DROP
The meaning of --state NEW is the number one misunderstanding of netfilter's
dynamic
On Fri, Jun 07, 2002 at 09:31:12AM +1000, Rusty Russell wrote:
Of course, you can still use SYNs to scan the network, so they
haven't actually won anything here, except that if their firewall
reboots, established connections will die.
If their firewall reboots and is running iptables
In message [EMAIL PROTECTED] you write:
On Fri, Jun 07, 2002 at 09:31:12AM +1000, Rusty Russell wrote:
Of course, you can still use SYNs to scan the network, so they
haven't actually won anything here, except that if their firewall
reboots, established connections will die.
If their
On Fri, Jun 07, 2002 at 12:10:09PM +1000, Rusty Russell wrote:
If their firewall reboots and is running iptables and thus Linux: How
long will it be down?
120 seconds to reboot with a fixed kernel...
Umm, OK, I shouldn't have compared the reboot time of my desktop pc
with a tuned
34 matches
Mail list logo
