I just read a surprisingly stupid and inaccurate article regarding “IPv6 [being a] gateway to hackers.” Aside from the obvious fact that they meant “crackers” and not “hackers,” (because crackers are the people that break security with malicious intent, while hackers are the people that create software programs and systems like operating systems, Web browsers, email clients, and so forth), Wired’s Threat Level blog is spreading FUD about IPv6, and to top it all off, giving bad advice (never, ever listen to anyone that seriously believes that software like Zone Alarm is going to protect you; only the operating system itself can do that, as Microsoft Corporation can attest to). Not to mention, the basic principle of separation of privileges pretty well mandates that if a given machine x needs to be protected by any given threat Y, that a third system, Z, should provide that protection. Routers are what need to be charged with protecting networks, not client workstations. Server machines that house data that cannot be leaked, should not be on publicly facing Internet machines. As an example, any site that regularly performs customer transactions via the Web should routinely clean their database on the Web server and move the database’s sensitive content to an internal system that isn’t accessible from the Web site nor the Internet, thereby mitigating what can be stolen in the event that there is a vulnerability lying around somewhere that can be exploited.
In any case, I was going to comment on the blog, but the comment got long-winded, so I am posting it here instead. You might want to head over and read the article first, of course.
I am not quite sure how to even begin responding to this article.
This piece stretches the truth a little bit. While many appliances and devices and even operating systems have support for IPv6, it’s only enabled by default when it’s possible to use. Many firewalls on networks like corporate networks use a whitelist policy to determine what goes in and out, for starters. Secondly, most organizations have not yet deployed Windows Vista, which has IPv6 enabled by default. Windows XP has a broken IPv6 implementation anyway, and while it’s possible to add functionality for tunneling into it, either protocol 41 is going to be blocked, or the strange-looking UDP tunnels will be; they’re not going to be part of the whitelist.
Furthermore, you seem to have neglected the fact that the application software which opens ports has to support IPv6 — and have that support turned on — in order for it to expose any sorts of vulnerability. Lastly, you call upon software firewalls functioning on known-insecure operating systems as a means of protection.
Were you on any TCP/IP networks before 1993? NAT hasn’t been around for a very long time, and NAT only came about due to the foresight of the industry realizing that IPv4 address space was shrinking too quickly. IPv6 won’t have NAT, to be sure, but IPv4 networks didn’t use to have it, either; they relied upon packet filtering at the edge of the network in order to maintain security. Network security will shift back to that model, just as it was back pre-NAT.
Any operating system secure enough to provide such services already does so, and this includes any sort of embedded devices which run those operating systems. For example, a router that is running any variant of the GNU/Linux operating system that has support for IPv6 enabled will be able to perform packet filtering for the internal network. This means that the router will have the ability to block packets based on the same criteria that NATs do. It can look for related connections, for example, and permit packets to and from. Networks which require machines to be segregated from the Internet will still have to be segregated in the most cautious of ways, nothing will change there.
It doesn’t matter if you’ve IPv4 machines behind a NAT that have external ports forwarded to them, or if you have a fully functional IPv6 network; the weakest link is still going to be the weakest link. ZoneAlarm and friends aren’t going to provide any level of real protection, and if they’re being trusted to do so, the person(s) implementing these solutions are of questionable network security background. In fact, they’re probably management types, and the decision to do it was probably based on advice from friends, advice from fellow managers, or buzzword compliance, or some mixture of the three.
Also, consider that most home and small office appliances do not have, and will not have, support for IPv6 tunneling through them. Special support has to be present for VPN passthrough on such commodity devices; support for Protocol 41 would be required, as well. For clients that use UDP tunneling, UDP with the external Internet has to be permitted, and that’s the same as VPN passthrough with the way many VPN clients are implemented these days; so, if people are using VPNs, they are already aware of the fact that they’ve opened up their networks to be creating tunnels to and from other networks.
The only way to keep a network secure is to use operating systems which are audited and reviewable systems, combined with software of the same caliber, combined with a router that knows how to drop packets that are harmful based on (in order of preference) whitelisting, greylisting, blacklisting, or even heuristic analysis. Combine with with strong, complex passphrases, and you have a secure system.
As for what is considered to be audited and reviewable, I would say that a GNU/Linux system would fit that bill. Considering that the average privilege escalation exploit in the kernel is closed anywhere between 6 to 36 hours after it is found, compared with Apple or Microsoft’s turnaround time on security-critical bugs (remember MS06-032?) which range from several weeks to several months, it seems fairly obvious what systems should be trusted to perform network routing and security functions… but I wouldn’t risk a network buy having weak links even close to attached to an outside, known-hostile network. If I have systems which _must_ be protected from the Internet at all costs, then the only thing that is going to move data back and forth between those systems and the Internet is the tried-and-true method of sneakernet. There is also the ability to have private nodes on an IPv6 network that do not have globally routable IPv6 addresses; combine that with a totally different Ethernet segment, and you can implement a single machine which acts as a gateway between the two networks, letting data flow in one direction but not the other. It’s not terribly hard to come up with secure solutions, given that simplicity and (what should be) common sense tend to make security a (relatively) easy thing to combat.
If you want to write a piece that will make people aware of security issues on their networks, why not write up a piece on the importance of open systems which are peer reviewed? Why not talk about the known benefits of such systems, and show how it’s worked in the world of academia for so long? Nary a thing is published in academia without peers performing reviews and fact-checking on it. The code that goes into operating systems can (and should!) be proofread in the same way, for the same reasons. After all, you wouldn’t trust papers published in a journal without them having cited sources and provided data such that you could verify the information yourself… why should you trust your operating system to do exactly what (and no more than) it claims to do, without seeing the references and data that is part of the system itself? Well, not everyone would—but when it’s possible, people *do*, and *that* is what increases the security of a system.