Useful info. Right now I just fully permit ICMP, because I never could be sure which to block. This gives me something to play with, so thanks for that.
I suspect that this only applies to end nodes (servers), is that right? Could you also elaborate on which types you would permit in case of routers, and clients?
Since we’re just talking about filtering on the ICMP types and not on the source/destination addresses, I think you can safely ignore the difference between end nodes (both clients and servers) and routers.
For that v4 list, I would only filter out 5 (redirect message) if I was 100% certain that there were no other gateway routers on the local segment, otherwise for performance I’d let it pass. I’d probably let 12 (parameter problem) go through in general.
I think the v6 list is good, but might be missing some important ones depending on how the network is set up. Check out RFC4890 “Recommendations for Filtering ICMPv6 Messages in Firewalls” for a (longish) summary.
I think the v6 list is good, but might be missing some important ones depending on how the network is set up.
100, 101, 127 are reserved. I don’t do multicast with v6, so 130 - 132 are out. 137 is a redirect, which I don’t allow intentionally. Everything higher than 137 is for routers, reserved/experimental, or for mobile.
As for v4: I can’t currently locate my documentation about the potential exploits involved in the other icmp types.
Filtering out ICMP is still a very common newbie mistake among firewall admins. It even still happens from time to time with some bigger providers (I’m lookin' right at you, AT&T U-verse in Florida!)
You can’t filter out ICMP error messages and expect the ‘net to work. Dump echo reqs/resps if you want to, but the frag needed messages have to flow or you are going to have a bad time.
This is a great article, and precisely the kind of networking bug hunt that shuts down newbies or folks without a really solid understanding of what’s going on down hard.
It’s always seemed to me that the assertion of “I don’t allow ICMP packets through for security reasons” might be a bit specious - sure, I can detect that a given host is at IP address blah, but that’s about it, and I’ve always felt the debugging value alone was worth the price of admission.
Naw, its been happening for twenty years. Its just an easy mistake to make when applying the ‘anything not specifically allowed should be dropped’ network security philosophy.
“blocking ping” is the advice of someone who has no idea what Path MTU Discovery is, or has never had to actually diagnose network problems.
edit: of course you should filter out most types. On servers I only permit
v4: 0,3,8,11
v6: 1,2,3,4,128,129,133,134,135,136
Useful info. Right now I just fully permit ICMP, because I never could be sure which to block. This gives me something to play with, so thanks for that.
I suspect that this only applies to end nodes (servers), is that right? Could you also elaborate on which types you would permit in case of routers, and clients?
Since we’re just talking about filtering on the ICMP types and not on the source/destination addresses, I think you can safely ignore the difference between end nodes (both clients and servers) and routers.
For that v4 list, I would only filter out 5 (redirect message) if I was 100% certain that there were no other gateway routers on the local segment, otherwise for performance I’d let it pass. I’d probably let 12 (parameter problem) go through in general.
I think the v6 list is good, but might be missing some important ones depending on how the network is set up. Check out RFC4890 “Recommendations for Filtering ICMPv6 Messages in Firewalls” for a (longish) summary.
100, 101, 127 are reserved. I don’t do multicast with v6, so 130 - 132 are out. 137 is a redirect, which I don’t allow intentionally. Everything higher than 137 is for routers, reserved/experimental, or for mobile.
As for v4: I can’t currently locate my documentation about the potential exploits involved in the other icmp types.
Filtering out ICMP is still a very common newbie mistake among firewall admins. It even still happens from time to time with some bigger providers (I’m lookin' right at you, AT&T U-verse in Florida!)
You can’t filter out ICMP error messages and expect the ‘net to work. Dump echo reqs/resps if you want to, but the frag needed messages have to flow or you are going to have a bad time.
This is a great article, and precisely the kind of networking bug hunt that shuts down newbies or folks without a really solid understanding of what’s going on down hard.
It’s always seemed to me that the assertion of “I don’t allow ICMP packets through for security reasons” might be a bit specious - sure, I can detect that a given host is at IP address blah, but that’s about it, and I’ve always felt the debugging value alone was worth the price of admission.
The crappy scanners used by everyone in penetration testing will flag “server responds to ICMP timestamp”, so I expect it partially stems from that.
Of course, they don’t flag that you can get the exact same data from the httpd running on the same machine.
Naw, its been happening for twenty years. Its just an easy mistake to make when applying the ‘anything not specifically allowed should be dropped’ network security philosophy.