On 12/9/11 1:41 PM, "Donald Clark"
All
In the piece of work I'm doing for the IPv6 TaskForce, a recurrent theme has been problems around firewalling / security in general with IPv6. This has raised its head in three variations:
1 - my kit doesn't support it / well 2 - I don't know what v6 policies to turn on, or off / how should I setup rules by range 3 - we don't have any v6 rules (but it may be turned on by default)
Does anyone have any examples of attacks, exposures, policy challenges around v6?
Cheers DC
Well, there is the NIST document, "Guidelines for the Secure Deployment of IPv6" I have reservations about this document, but it is probably a useful starting point. At least it gets them on the way to understanding what they don't know. Another approach I think might be useful from conversations I've had is in pointing out a few headline adjustments they need to make in their thinking. (Note the statements are somewhat dogmatic, by design. Think of them as IPv6 Koans: mental tools to create a right world-view) * NAT does not exist. If your application requires NAT (e.g. load balancing) it's broken under IPv6. There is no workaround. This is a feature. NAT is gone. [I found this probably the biggest mind-blow for some people] * ICMP is not optional. Blocking ICMPv4 indiscriminately was always a bad idea, now it's a terminal idea. * ARP is gone. * Multicast is not optional * An interface WILL have multiple IPv6 addresses * DHCP is optional. If you think you need DHCP, then re-evaluate very, very carefully. * That best practice of providing reverse DNS entries for all possible addresses on your LAN? Not possible. Gone. * Reverse DNS as a way of encoding useful information is probably not very useful anymore. Find a better way. * Address scanning your own LAN to find things? Yeah, no. -- Michael Newbery IP Architect TelstraClear Limited TelstraClear. Simple Solutions. Everyday Residential 0508 888 800 Business 0508 555 500 Enterprise & Government 0508 400 300 This email contains information which may be confidential and subject to copyright. If you are not the intended recipient you must not use, distribute or copy this email or attachments. If you have received this email in error please notify us immediately by return email and delete this email and any attachments. TelstraClear Limited accepts no responsibility for changes made to this email or to any attachments after transmission from TelstraClear Limited. It is your responsibility to check this email and any attachments for viruses. Emails are not secure. They can be intercepted, amended, lost or destroyed and may contain viruses. Anyone who communicates with TelstraClear Limited by email is taken to accept these risks.