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/12/15/191205)
_______________________________________________
LARTC mailing list
[email protected]
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Quoted 7 lines · Grant Taylor
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.
Signature · 2 lines
http://sid.rstack.org/ PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
Quoted 2 lines
Quoted 2 lines
Hi! I'm your friendly neighbourhood signature virus. Copy me to your signature file and help me spread!
Quoted 13 lines · Cedric Blancher
Quoted 9 lines · Grant Taylor
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.
Quoted 6 lines
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.
Quoted 3 lines · Martijn Lievaart
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.
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 4 lines
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.
Quoted 2 lines
[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
Signature · 2 lines
http://sid.rstack.org/ PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
Quoted 2 lines
Quoted 2 lines
Hi! I'm your friendly neighbourhood signature virus. Copy me to your signature file and help me spread!
Quoted 9 lines · Cedric Blancher
Quoted 3 lines
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:
Quoted 9 lines
. 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
Quoted 2 lines · Martijn Lievaart
ICMP filtering is not tricky. Just remember the rules.
1) NEVER, EVER, EVER filter out fragmentation needed.
;)
Quoted 2 lines
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.
Quoted 1 line
3) Everything else can be filtered without consequences.
Time Exceeded ?
Quoted 2 lines
If you mean, it is hard for a firewall to filter malicious ICMPs but not beneign ICMPs, the we agree.
That was my point.
Quoted 2 lines
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.
Signature · 2 lines
http://sid.rstack.org/ PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
Quoted 2 lines
Quoted 2 lines
Hi! I'm your friendly neighbourhood signature virus. Copy me to your signature file and help me spread!
Hi,
Quoted 6 lines · Martijn Lievaart
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 : [email protected], [email protected] 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
Quoted 2 lines · Jozsef Kadlecsik
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.
Quoted 5 lines · 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. :(
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
Hello,
Quoted 4 lines · Grant Taylor
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.
Quoted 24 lines · On Sun, 17 Dec 2006 20:51:44 -0600 Grant Taylor <[email protected]>…
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. . . .
Quoted 6 lines
(1) Is a /. article "How Skype Punches Holes in Firewalls"
(http://it.slashdot.org/article.pl?sid/12/15/191205)
_______________________________________________
LARTC mailing list
[email protected]
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.
Signature · 5 lines
Stephen Hemminger <[email protected]> _______________________________________________ LARTC mailing list [email protected] http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Quoted 3 lines · Grant Taylor
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".
Quoted 3 lines
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.
Quoted 1 line
Grant. . . .
Yours sincerely,
Peter
Signature · 5 lines
http://www.shurdix.org - Linux distribution for routers and firewalls _______________________________________________ LARTC mailing list [email protected] http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Quoted 3 lines · 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.
The article only reiterates the same old stories and FUD which have been known for years.
Quoted 7 lines
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
Signature · 5 lines
http://www.hailfinger.org/ _______________________________________________ LARTC mailing list [email protected] http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Quoted 2 lines · Carl-Daniel Hailfinger
Quoted 1 line · Grant Taylor
I ran across an interesting article
[...]
Quoted 6 lines
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.
Quoted 2 lines
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
Quoted 8 lines · Carl-Daniel Hailfinger
Quoted 7 lines
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
Quoted 6 lines
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
[email protected]
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Quoted 11 lines · Grant Taylor
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.
Signature · 6 lines
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
_______________________________________________
LARTC mailing list
[email protected]
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc