LARTC - Dec 2006 - Interesting article about punching holes in firewalls...

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)

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!

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

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>

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

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/

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. . . .

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