[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

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: [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: [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