[LARTC] Interesting article about punching holes in firewalls...

[LARTC] Interesting article about punching holes in firewalls...

[Grant Taylor]

I ran across an interesting article 
(http://www.heise-security.co.uk/articles/print/82481) (1) that I think 
any and all firewall administrators should take a few moments to read.

I personally have known that using "-m state --state 
ESTABLISHED,RELATED" was not the most secure thing to use for returning 
traffic.  Namely this will allow you to make a valid connection to a web 
server, say to retrieve a picture.  Then said web server could send 
malicious traffic back to your computer and pass through your firewall. 
  This is because the traffic coming from the web server to your 
computer is now deemed as RELATED.  Previously I have written this off 
as not needing to worry about this (much) YET.  Yet being the operative 
word.  I have long known that I would, especially on more secure 
installs (read not SOHO) need to filter inbound traffic based on source 
/ destination port.  I just have not thought that it was important 
enough to do presently for my clientele.  Unfortunately, the day where 
we do as much filtering on related traffic as we do on non related 
traffic may be closer at hand than we all would like to admit.  :(



Grant. . . .


(1) Is a /. article "How Skype Punches Holes in Firewalls" 
(http://it.slashdot.org/article.pl?sid\x06/12/15/191205)
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Interesting article about punching holes in firewalls...

[Grant Taylor]

I ran across an interesting article 
(http://www.heise-security.co.uk/articles/print/82481) (1) that I think 
any and all firewall administrators should take a few moments to read.

I personally have known that using "-m state --state 
ESTABLISHED,RELATED" was not the most secure thing to use for returning 
traffic.  Namely this will allow you to make a valid connection to a web 
server, say to retrieve a picture.  Then said web server could send 
malicious traffic back to your computer and pass through your firewall. 
  This is because the traffic coming from the web server to your 
computer is now deemed as RELATED.  Previously I have written this off 
as not needing to worry about this (much) YET.  Yet being the operative 
word.  I have long known that I would, especially on more secure 
installs (read not SOHO) need to filter inbound traffic based on source 
/ destination port.  I just have not thought that it was important 
enough to do presently for my clientele.  Unfortunately, the day where 
we do as much filtering on related traffic as we do on non related 
traffic may be closer at hand than we all would like to admit.  :(



Grant. . . .


(1) Is a /. article "How Skype Punches Holes in Firewalls" 
(http://it.slashdot.org/article.pl?sid=06/12/15/191205)

Re: Interesting article about punching holes in firewalls...

[Cedric Blancher]

Le dimanche 17 décembre 2006 à 20:51 -0600, Grant Taylor a écrit :
> I personally have known that using "-m state --state 
> ESTABLISHED,RELATED" was not the most secure thing to use for returning 
> traffic.  Namely this will allow you to make a valid connection to a web 
> server, say to retrieve a picture.  Then said web server could send 
> malicious traffic back to your computer and pass through your firewall. 
>   This is because the traffic coming from the web server to your 
> computer is now deemed as RELATED.

How ? Afaik RELATED is used for two types of packets:

	. ICMP errors matching previously seen IP flow
	. First packet of expectations created through a helper

HTTP does not have any helper, this let ICMP goes through. Is it a
vuln ? I don't think so. However, remote server can refuse to close
connection and send further data using ESTABLISHED state. Well, how do
you prevent that from the firewall perspective ?

I must admit I quite don't see your point here. Can you elaborate a bit
please ? Thx.


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: Interesting article about punching holes in firewalls...

[Martijn Lievaart]

Cedric Blancher wrote:

>Le dimanche 17 décembre 2006 à 20:51 -0600, Grant Taylor a écrit :
>
>
>>I personally have known that using "-m state --state
>>ESTABLISHED,RELATED" was not the most secure thing to use for returning
>>traffic.  Namely this will allow you to make a valid connection to a web
>>server, say to retrieve a picture.  Then said web server could send
>>malicious traffic back to your computer and pass through your firewall.
>>  This is because the traffic coming from the web server to your
>>computer is now deemed as RELATED.
>>
>>
>
>How ? Afaik RELATED is used for two types of packets:
>
>	. ICMP errors matching previously seen IP flow
>	. First packet of expectations created through a helper
>
>

One can think about spoofed ICMP errors, but there really is not a lot
we can do about that. (And for tcp they SHOULD be ignored anyhow. OTOH
an atacker can spoof a RST packet.)

I do assume in all this that the only ICMP traffic matching RELATED are
true ICMP errors (afair host/net unreachable and fragmentation needed).
If this also opens up say ICMP redirect[1] we may have a slight problem.
It is possible netfilter does this to accomodate bridging setups. Anyone
can comment on this? If this opens up the connection for any other ICMP
traffic, I think that's a bug. But I cannot imagine netfilter does this,
anyone know for sure?

M4

[1] redirect in Linux is also sanity checked, so the risk is not even
that great, but still.

Re: Interesting article about punching holes in firewalls...

[Cedric Blancher]

Le mardi 19 décembre 2006 à 10:42 +0100, Martijn Lievaart a écrit :
> One can think about spoofed ICMP errors, but there really is not a lot 
> we can do about that. (And for tcp they SHOULD be ignored anyhow. OTOH 
> an atacker can spoof a RST packet.)

Yes, true. But that's bound to the protocol. And our firewall has to
show a minimum compliance to it. There's a few papers to read around on
ICMP spoofing based DoS.

> I do assume in all this that the only ICMP traffic matching RELATED are 
> true ICMP errors (afair host/net unreachable and fragmentation needed). 

They should. Check is done on ICMP payload which contains header of
original packet that raised the error. Inverting this header allows you
to browse conntrack table and see if it fits one existing state. If so,
it's considered as valid and it's flaged RELATED, if not, it's INVALID.
But the thing is we can't do much more...
On (good) idea was to check TCP sequence number when applicable, but
it's limited to TCP. Better than nothing however.

> If this also opens up say ICMP redirect[1] we may have a slight problem.

An ICMP redirect should not come from an outer network. So, as you imply
below, this issue would be limited to bridges.

> It is possible netfilter does this to accomodate bridging setups. Anyone 
> can comment on this? If this opens up the connection for any other ICMP 
> traffic, I think that's a bug. But I cannot imagine netfilter does this, 
> anyone know for sure?

We also have a protocol problem here. However, as Pascal stated before,
you can explicitly deny ICMP redirects.

As a more general matter, ICMP filtering is tricky:

	. ICMP filtering can (and do) break connectivity: PPPoE users
	  with broken PMTUD knows about it...
	. ICMP messages authentication is weak.

On one hand we have a protocol we have to implement because we need it
for IP to work smoothly, and on the other hand, it's quite easy to
abuse. And we have to cope with it.

> [1] redirect in Linux is also sanity checked, so the risk is not even 
> that great, but still.

echo 0 > /proc/sys/net.ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net.ipv4/conf/all/send_redirects


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: Interesting article about punching holes in firewalls...

[Martijn Lievaart]

Cedric Blancher wrote:

>>It is possible netfilter does this to accomodate bridging setups. Anyone 
>>can comment on this? If this opens up the connection for any other ICMP 
>>traffic, I think that's a bug. But I cannot imagine netfilter does this, 
>>anyone know for sure?
>>    
>>
>
>We also have a protocol problem here. However, as Pascal stated before,
>you can explicitly deny ICMP redirects.
>
>As a more general matter, ICMP filtering is tricky:
>
>	. ICMP filtering can (and do) break connectivity: PPPoE users
>	  with broken PMTUD knows about it...
>	. ICMP messages authentication is weak.
>
>On one hand we have a protocol we have to implement because we need it
>for IP to work smoothly, and on the other hand, it's quite easy to
>abuse. And we have to cope with it.
>  
>

ICMP filtering is not tricky. Just remember the rules.
1) NEVER, EVER, EVER filter out fragmentation needed.
2) You may filter out ping, and the various destination unreachables, 
the consequences are yours.
3) Everything else can be filtered without consequences.

If you mean, it is hard for a firewall to filter malicious ICMPs but not 
beneign ICMPs, the we agree. I have not heard of an fragmentation needed 
attack yet, but I can imagine it happening (analogous to the zero 
windowsize attack).

But as Jozsef explained, iptables does check what it is possible, for 
the rest we mostly have to live with it.

M4

Re: Interesting article about punching holes in firewalls...

[Cedric Blancher]

Le mardi 19 décembre 2006 à 19:53 +0100, Martijn Lievaart a écrit :
> ICMP filtering is not tricky. Just remember the rules.
> 1) NEVER, EVER, EVER filter out fragmentation needed.

;)

> 2) You may filter out ping, and the various destination unreachables, 
> the consequences are yours.

Actually, Fragmentation Needed is one of various Destination Unreachable
message... Type 3, code 4.

> 3) Everything else can be filtered without consequences.

Time Exceeded ?

> If you mean, it is hard for a firewall to filter malicious ICMPs but not 
> beneign ICMPs, the we agree. 

That was my point.

> I have not heard of an fragmentation needed attack yet, but I can
> imagine it happening (analogous to the zero windowsize attack).

You can use Frag Needed to degrade performances. See section 7 of:

http://www.gont.com.ar/drafts/icmp-attacks/draft-ietf-tcpm-icmp-attacks-01.txt

You can also use Source Quench.


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: Interesting article about punching holes in firewalls...

[Jozsef Kadlecsik]

Hi,

On Tue, 19 Dec 2006, Martijn Lievaart wrote:

> I do assume in all this that the only ICMP traffic matching RELATED are
> true ICMP errors (afair host/net unreachable and fragmentation needed).
> If this also opens up say ICMP redirect[1] we may have a slight problem.
> It is possible netfilter does this to accomodate bridging setups. Anyone
> can comment on this? If this opens up the connection for any other ICMP
> traffic, I think that's a bug.

The ICMP types for which the packet may be flagged as RELATED are

- destination-unreachable
- source-quench
- time-exceeded
- parameter-problem
- redirect

*if* the inner packet corresponds to an already existing connection.

But he hole punching technique described in the article[1] has nothing to 
do with RELATED connections. There are applications running on the client 
machines which do initiate the connections from behind the firewall and if 
any outgoing connection is allowed by the local policy, the "punching" 
naturally succeeds.

If the "enemy" behind the (fire)walls, nothing much can be done.

The article must be corrected at one place: the claim: "After an 
outgoing SYN packet the firewall / NAT router will forward incoming 
packets with suitable IP addresses and ports to the LAN even if they fail 
to confirm, or confirm the wrong sequence number (ACK). Linux firewalls at 
least, clearly fail to evaluate this information consistently." is 
outdated and not true for 2.6 kernels.

[1]: http://www.heise-security.co.uk/articles/print/82481

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Interesting article about punching holes in firewalls...

[Pascal Hambourg]

Jozsef Kadlecsik a écrit :
> 
> The article must be corrected at one place: the claim: "After an 
> outgoing SYN packet the firewall / NAT router will forward incoming 
> packets with suitable IP addresses and ports to the LAN even if they fail 
> to confirm, or confirm the wrong sequence number (ACK). Linux firewalls at 
> least, clearly fail to evaluate this information consistently." is 
> outdated and not true for 2.6 kernels.

For *recent* 2.6 kernels, with "recent" meaning 2.6.9 and above.

Re: Interesting article about punching holes in firewalls...

[Martijn Lievaart]

Grant Taylor wrote:

> I ran across an interesting article 
> (http://www.heise-security.co.uk/articles/print/82481) (1) that I 
> think any and all firewall administrators should take a few moments to 
> read.
>
> I personally have known that using "-m state --state 
> ESTABLISHED,RELATED" was not the most secure thing to use for 
> returning traffic.  Namely this will allow you to make a valid 
> connection to a web server, say to retrieve a picture.  Then said web 
> server could send malicious traffic back to your computer and pass 
> through your firewall.  This is because the traffic coming from the 
> web server to your computer is now deemed as RELATED.  Previously I 
> have written this off as not needing to worry about this (much) YET.  
> Yet being the operative word.  I have long known that I would, 
> especially on more secure installs (read not SOHO) need to filter 
> inbound traffic based on source / destination port.  I just have not 
> thought that it was important enough to do presently for my 
> clientele.  Unfortunately, the day where we do as much filtering on 
> related traffic as we do on non related traffic may be closer at hand 
> than we all would like to admit.  :(
>
>

Well, this only works for UDP, and only if you allow everything out. 
Fortunately, on any non-soho setup, you should not allow everything out, 
only what you really need to leave the network. problem solved.

(Well the only problem solved is hole punching, not that skype, 
messenger, etc can use about any transport that is open. The only thing 
they don't do yet is tunnel over DNS I think :-).

HTH,
M4

Re: Interesting article about punching holes in firewalls...

[Pascal Hambourg]

Hello,

Grant Taylor a écrit :
> 
> I personally have known that using "-m state --state 
> ESTABLISHED,RELATED" was not the most secure thing to use for returning 
> traffic.  Namely this will allow you to make a valid connection to a web 
> server, say to retrieve a picture.  Then said web server could send 
> malicious traffic back to your computer and pass through your firewall. 
>  This is because the traffic coming from the web server to your computer 
> is now deemed as RELATED.

I do not agree with this. AFAIK the only traffic that can be labelled 
RELATED to an HTTP connection or any "simple" TCP or UDP or whatever 
connection (not special protocols such as FTP) is some ICMP signalling 
messages. This said, I do filter out some RELATED ICMP types I do not like.

"Hole punching" is a completely different thing and requires active 
cooperation from the inside.

Re: [LARTC] Interesting article about punching holes in firewalls...

[Stephen Hemminger]

On Sun, 17 Dec 2006 20:51:44 -0600
Grant Taylor <gtaylor@riverviewtech.net> wrote:

> I ran across an interesting article 
> (http://www.heise-security.co.uk/articles/print/82481) (1) that I think 
> any and all firewall administrators should take a few moments to read.
> 
> I personally have known that using "-m state --state 
> ESTABLISHED,RELATED" was not the most secure thing to use for returning 
> traffic.  Namely this will allow you to make a valid connection to a web 
> server, say to retrieve a picture.  Then said web server could send 
> malicious traffic back to your computer and pass through your firewall. 
>   This is because the traffic coming from the web server to your 
> computer is now deemed as RELATED.  Previously I have written this off 
> as not needing to worry about this (much) YET.  Yet being the operative 
> word.  I have long known that I would, especially on more secure 
> installs (read not SOHO) need to filter inbound traffic based on source 
> / destination port.  I just have not thought that it was important 
> enough to do presently for my clientele.  Unfortunately, the day where 
> we do as much filtering on related traffic as we do on non related 
> traffic may be closer at hand than we all would like to admit.  :(
> 
> 
> 
> Grant. . . .
> 
> 
> (1) Is a /. article "How Skype Punches Holes in Firewalls" 
> (http://it.slashdot.org/article.pl?sid\x06/12/15/191205)
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

This isn't new, it STUNT (Simple Traversal of UDP through NAT
and TCP).  See:
	http://nutss.gforge.cis.cornell.edu/stunt.php

It has been studied by Internet researchers for a while. But for most
users, NAT is an impediment to connectivity, and STUNT is a good thing.

You should be able to block it with netfilter connection tracking.

-- 
Stephen Hemminger <shemminger@osdl.org>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: Interesting article about punching holes in firewalls...

[Stephen Hemminger]

On Sun, 17 Dec 2006 20:51:44 -0600
Grant Taylor <gtaylor@riverviewtech.net> wrote:

> I ran across an interesting article 
> (http://www.heise-security.co.uk/articles/print/82481) (1) that I think 
> any and all firewall administrators should take a few moments to read.
> 
> I personally have known that using "-m state --state 
> ESTABLISHED,RELATED" was not the most secure thing to use for returning 
> traffic.  Namely this will allow you to make a valid connection to a web 
> server, say to retrieve a picture.  Then said web server could send 
> malicious traffic back to your computer and pass through your firewall. 
>   This is because the traffic coming from the web server to your 
> computer is now deemed as RELATED.  Previously I have written this off 
> as not needing to worry about this (much) YET.  Yet being the operative 
> word.  I have long known that I would, especially on more secure 
> installs (read not SOHO) need to filter inbound traffic based on source 
> / destination port.  I just have not thought that it was important 
> enough to do presently for my clientele.  Unfortunately, the day where 
> we do as much filtering on related traffic as we do on non related 
> traffic may be closer at hand than we all would like to admit.  :(
> 
> 
> 
> Grant. . . .
> 
> 
> (1) Is a /. article "How Skype Punches Holes in Firewalls" 
> (http://it.slashdot.org/article.pl?sid=06/12/15/191205)
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

This isn't new, it STUNT (Simple Traversal of UDP through NAT
and TCP).  See:
	http://nutss.gforge.cis.cornell.edu/stunt.php

It has been studied by Internet researchers for a while. But for most
users, NAT is an impediment to connectivity, and STUNT is a good thing.

You should be able to block it with netfilter connection tracking.

-- 
Stephen Hemminger <shemminger@osdl.org>

Re: [LARTC] Interesting article about punching holes in firewalls...

[Peter Surda]

Grant Taylor schrieb:
> I personally have known that using "-m state --state 
> ESTABLISHED,RELATED" was not the most secure thing to use for returning 
> traffic.
Actually, what the described method accomplishes is not defeating the 
"firewall" part, but the "NAT" part. If one of the hosts was not behind 
a NAT, the traffic would flow even with ESTABLISHED,RELATED, because it 
belongs to active "connection".

>  Namely this will allow you to make a valid connection to a web 
> server, say to retrieve a picture.  Then said web server could send 
> malicious traffic back to your computer and pass through your firewall. 
Please note it does not allow you to create a new connection, just use 
POTENTIAL connections that wouldn't work due to NAT.

> Grant. . . .
Yours sincerely,
Peter

-- 
http://www.shurdix.org - Linux distribution for routers and firewalls
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Interesting article about punching holes in firewalls...

[Carl-Daniel Hailfinger]

Grant Taylor wrote:
> I ran across an interesting article
> (http://www.heise-security.co.uk/articles/print/82481) (1) that I think
> any and all firewall administrators should take a few moments to read.

The article only reiterates the same old stories and FUD which have been
known for years.

> I personally have known that using "-m state --state
> ESTABLISHED,RELATED" was not the most secure thing to use for returning
> traffic.  Namely this will allow you to make a valid connection to a web
> server, say to retrieve a picture.  Then said web server could send
> malicious traffic back to your computer and pass through your firewall.
>  This is because the traffic coming from the web server to your computer
> is now deemed as RELATED.  Previously I have written this off as not

This is wrong on so many levels. Please reread the article. Then read
the source code of your favourite firewalling system. All of those
"attacks" require cooperation from your side. And if you (or someone
using the computer you try to protect) are actively cooperating with
the attacker, "fixing" the firewall should be the least important of
your problems.
A small hint about the most obvious problem in your web server example:
HTTP does not have any concept of RELATED connections. You could claim
FTP was used to download the image, but then your scenario would require
a FTP server instead of a web (HTTP(S)) server.
I'm still seeing people who absolutely want to deploy the iptables
UNCLEAN match to "make their network more secure".


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: Interesting article about punching holes in firewalls...

[Carl-Daniel Hailfinger]

Grant Taylor wrote:
> I ran across an interesting article
> (http://www.heise-security.co.uk/articles/print/82481) (1) that I think
> any and all firewall administrators should take a few moments to read.

The article only reiterates the same old stories and FUD which have been
known for years.

> I personally have known that using "-m state --state
> ESTABLISHED,RELATED" was not the most secure thing to use for returning
> traffic.  Namely this will allow you to make a valid connection to a web
> server, say to retrieve a picture.  Then said web server could send
> malicious traffic back to your computer and pass through your firewall.
>  This is because the traffic coming from the web server to your computer
> is now deemed as RELATED.  Previously I have written this off as not

This is wrong on so many levels. Please reread the article. Then read
the source code of your favourite firewalling system. All of those
"attacks" require cooperation from your side. And if you (or someone
using the computer you try to protect) are actively cooperating with
the attacker, "fixing" the firewall should be the least important of
your problems.
A small hint about the most obvious problem in your web server example:
HTTP does not have any concept of RELATED connections. You could claim
FTP was used to download the image, but then your scenario would require
a FTP server instead of a web (HTTP(S)) server.
I'm still seeing people who absolutely want to deploy the iptables
UNCLEAN match to "make their network more secure".


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: [LARTC] Interesting article about punching holes in firewalls...

[Torsten Luettgert]

On Do, 2006-12-21 at 08:57 +0100, Carl-Daniel Hailfinger wrote:
> Grant Taylor wrote:
> > I ran across an interesting article
[...]
> This is wrong on so many levels. Please reread the article. Then read
> the source code of your favourite firewalling system. All of those
> "attacks" require cooperation from your side. And if you (or someone
> using the computer you try to protect) are actively cooperating with
> the attacker, "fixing" the firewall should be the least important of
> your problems.

Very true... the described method isn't an "attack", it's just a way to
facilitate connections between two NATed partners.

> I'm still seeing people who absolutely want to deploy the iptables
> UNCLEAN match to "make their network more secure".

This makes me curious: wouldn't UNCLEAN improve security? Afair, the
main argument against UNCLEAN (and grounds for its removal) was that
it broke ECN at some time in the past, and that "something like this
could happen again".

Personally, I like the idea of rejecting anything that violates the
existing standards.

Regards,
Torsten

Re: [LARTC] Interesting article about punching holes in firewalls...

[Grant Taylor]

Carl-Daniel Hailfinger wrote:
>> I personally have known that using "-m state --state
>> ESTABLISHED,RELATED" was not the most secure thing to use for returning
>> traffic.  Namely this will allow you to make a valid connection to a web
>> server, say to retrieve a picture.  Then said web server could send
>> malicious traffic back to your computer and pass through your firewall.
>>  This is because the traffic coming from the web server to your computer
>> is now deemed as RELATED.  Previously I have written this off as not
> 
> This is wrong on so many levels. Please reread the article. Then read
> the source code of your favourite firewalling system. All of those
> "attacks" require cooperation from your side. And if you (or someone
> using the computer you try to protect) are actively cooperating with
> the attacker, "fixing" the firewall should be the least important of
> your problems.

I have read the article.  I suspect that my uncertainty has to do with 
lack of how the SPI portion of the code works.  I am not qualified to 
read the source code to make an informed opinion.  I was (mis)believing 
that the SPI was very simple in the fact that it would classify any 
returning traffic coming back from a host as related.  Now, I'm getting 
the impression that this is not the case and that only specific packets 
are considered related.

Can / will someone that is more versed in programming / reading source 
code please give me a brief overview of how the kernel decides what is 
and is not related.



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Interesting article about punching holes in firewalls...

[/dev/rob0]

On Thursday 21 December 2006 09:37, Grant Taylor wrote:
> I have read the article.  I suspect that my uncertainty has to do
> with lack of how the SPI portion of the code works.  I am not
> qualified to read the source code to make an informed opinion.  I was
> (mis)believing that the SPI was very simple in the fact that it would
> classify any returning traffic coming back from a host as related. 
> Now, I'm getting the impression that this is not the case and that
> only specific packets are considered related.
>
> Can / will someone that is more versed in programming / reading
> source code please give me a brief overview of how the kernel decides
> what is and is not related.

That is not me, but I have in the past had the same question answered  
on the netfilter list. The protocol-specific helper drivers such as 
ip_conntrack_$PROTOCOL are the ones that defined state "RELATED". If 
you're not using a "helped" protocol, you will have no RELATED packets.
-- 
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc