Re: [LARTC] Interesting article about punching holes in firewalls...
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...
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
Re: [LARTC] Interesting article about punching holes in firewalls...
On Sun, 17 Dec 2006 20:51:44 -0600 Grant Taylor [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ___ 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 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...
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
[LARTC] 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) ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
