Educause Security Discussion mailing list archives
Re: IPv6 and DHCP and ICMP
From: John Ladwig <John.Ladwig () SO MNSCU EDU>
Date: Thu, 24 May 2012 14:24:10 +0000
The point of this thread is, if you "block most or all ICMP traffic in order to eliminate an attack surface," and you are running an IPv6 network and expect it to communicate with the rest of the IPv6 Internet, YOU WILL BE DISAPPOINTED. The phone WILL ring, when some intermediate carrier decides that they're doing a code upgrade which happens to break jumbo frame support, and you have a researcher talking to a computing grid halfway across town or he world, and there's jumbo frame capability otherwise on the path, but now there's no possibility of IPv6 nodes discovering the path MTU. Then, the network guys will have the day they enjoy so much, blaming the security guys for making them adhere to a policy that is in violation of how the network *must* be configured in order to work. And then you'll get all the invective that that carrier so richly deserved. The message is, you have to learn more about what ICMPv6 messages and codes than you did with IPv4 before you set up a traffic policy. Start with RFC4890 and have a series of unrushed discussion with your IPv6-literate network architects and engineers. -jml From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Everett, Alex D Sent: Thursday, May 24, 2012 8:16 AM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] IPv6 and DHCP and ICMP Very good points and I agree with them. However, for some important systems the concept of least functionality may need to be applied. An extension of that may be to block most or all ICMP traffic in order to eliminate an attack surface. For example, you may be concerned about exploits over IP/ICMP such as CVE-2011-1871, either before they are published or after. Another example, it would be hard for an attacker to conduct a ping flood against this server if an ACL drops pings for that server. Sincerely, Alex Everett, CISSP, CCNA University of North Carolina Chapel Hill On May 23, 2012, at 10:31 PM, randy marchany wrote: One of the "prime directives" in any security strategy is asking a) what is the purpose of a particular security control b) how effective is the control? Which brings me to ICMP blocking? I believe it's totally ineffective for the reasons below. What is the purpose of ICMP blocking? To keep someone from mapping your network? Do you think someone can't map your net if ICMP is blocked? Do you have wireless nets? Yes? Then your network is mapped. Do you have web servers? Yes? Then your net can be mapped. Do you have stateless firewalls at the border? Yes? Your net can be mapped by inverse mapping. Do you prevent "outbound" connections? Yes? then why not disconnect from the Internet :-)? No? your net has been mapped. IMHO, blocking ICMP v4 or v6 accomplished nothing from a security perspective. There are far more effective strategies to accomplish the same goals. Our preliminary work with v6 (and by extension v4) is shows you can't hide a machine on the net if there's wireless connectivity. So why bother? Accept the fact that a machine can be identified on the net and change your focus to protecting the data on a machine rather than the machine itself. So to answer the 2 initial questions I raised at the beginning of the post: 1. What is the purpose of ICMP blocking? To keep someone from mapping your net. 2. How effective is the control? Not effective at all because there are multiple ways to map a network and we cannot block all of them without interfering with the "business" purpose of your organization. My personal opinion is that I don't care what comes into my net. I care about what "leaves" my net. Protect the data. -r. On Wed, May 23, 2012 at 8:10 PM, Michael Sinatra <michael () rancid berkeley edu<mailto:michael () rancid berkeley edu>> wrote: On 05/23/2012 14:22, John Ladwig wrote: ICMPv4 should **never** have been "completely eliminated" from public network (interacting with local network), but there's only a small set of messages that **need** to pass an Internet/local policy boundary. Limited, yes, but I've seen way to many blanket drop policies that I'm a little touchy on the subject. There's a slightly larger set of required ICMPv6 messages that must cross an Internet/local policy boundary to enable, for example, path-MTU discovery. Our current proposals, LAN and WAN testbed configurations follow RFC 4890 ICMPv6 recommendations for firewall transit "must not be dropped" and "normally should not be dropped" pretty closely, although we're not currently testing mobile IPv6, and haven't decided whether to support it in the near term. +1 on RFC 4890--it's a really good resource both for firewalls and router ACLs. Keep in mind that blocking all ICMPv6 means blocking all IPv6. You simply won't have connectivity if you block ND, for example. michael Sincerely, Alex Everett, CISSP, CCNA Information Security Office University of North Carolina at Chapel Hill 919.445.9393
Current thread:
- Re: IPv6 and DHCP and ICMP Manjak, Martin (May 23)
- Re: IPv6 and DHCP and ICMP Morrow Long (May 23)
- Re: IPv6 and DHCP and ICMP John Ladwig (May 23)
- Re: IPv6 and DHCP and ICMP Michael Sinatra (May 23)
- Re: IPv6 and DHCP and ICMP randy marchany (May 23)
- Re: IPv6 and DHCP and ICMP John Ladwig (May 24)
- Re: IPv6 and DHCP and ICMP Everett, Alex D (May 24)
- Re: IPv6 and DHCP and ICMP John Ladwig (May 24)
- Re: IPv6 and DHCP and ICMP Michael Sinatra (May 23)