Slashdot Mirror
Obsession With Firewalls Could Hinder IPv6
DosIgriegas writes "The obsession with firewalls in IPv6 may result in some of the quirks of IPv4 reappearing. Ars Technica has an article looking at the topic in depth, exploring the technical challenges of securing the new protocol, and looking a the re-emergence of old problems in new guises. 'Ironically, what's required to make IPv6 work through a stateful firewall is almost identical to what's required to make IPv4 work though NAT. This means the IETF's efforts to keep IPv6 NAT-free in order to make protocols do their job without messy workarounds are defeated by the notion that everything should be firewalled.' If we decide to stick with firewalls in IPv6, we'll see many of the same hard-to-diagnose network problems that we have with IPv4."
The old-style stateless firewall will work just fine.
Mea navis aericumbens anguillis abundat
So, they're saying the way to get security in IPv6 is to throw away the whole concept of firewalls and hope that the protocol won't leave us with out collective bums hanging out in the wind.
Not at all. The idea is to get rid of the hack that is NAT (as there are plenty of address to go round), and keep the firewall. However, it might not be that much of an improvement because troubleshooting a firewall router isn't that much different from troubleshooting a NAT one.
But, who is going to trust an application to determine network policy? The first malicious application to come along will bork the whole system, won't it? I mean, 'random' hosts is the perfect invitation for badness.
Maybe I'm just (once again) demonstrating my ignorance of such things, but this sounds like it will introduce more problems than it fixes.
Cheers
Lost at C:>. Found at C.
I agree. This article is FUD. The problem the article claims is in the fact that it is desirable to restrict traffic to only that which is initiated from the inside. Of course protocols like FTP and BitTorrent will always have a problem with this whether it's IPv6 or IPv4. Such protocols are in direct conflict with the "internal initiation" paradigm. I don't see the value of this article beyond, "Firewalls are suxx0rs!!".
This seems to be the kindergarten introduction to firewalls, written by someone who is feeling around in the dark, and doesn't really know what he's talking about...
So what's the point of the pages full of irrelevant details about how Vista and ZoneAlarm works?
Stateful firewalls require you to explicitly allow incoming connections certain ports, even with IPv6. That's it. Nothing else there.
What he completely misses is that this is worlds better than NAT, which also requires assigning a unique port on the single IP address... You're screwed if you want more than one machine to access the same service, which doesn't allow you to use a non-default port.
Want two web servers running (on port 80)? Want two machines to be able to receive VoIP calls? Want multiple machines to be able to play some online game? Too bad. It's only with the multiple addresses IPv6 offers that it's really possible.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
I do not believe they are saying that we should have NO FIREWALLS at all. I think the idea is to have more permissive firewalls since with that many IP addresses available in IPv6 the odds someone will be RANDOMLY scanning and hitting something for someone is so remote that it is almost a guarantee that they're specifically looking for you.
The current scanning networks and such works because of one thing, you can almost count on hitting some IP addresses at any given block on the IPv4 network. Also because like 90% of computers are running windows you can probably scan for vulnerabilities and attack almost as quickly.
09F911029D74E35BD84156C5635688C0
+2 Troll is Slashdot's way of saying groupthink is confused
There are also some features of NAT that I would like to keep even when using IPv6, the main one being the ability to hide the topology of my networks from the outside world. So in a way, I do want to have some connectivity issues.
For example, I currently maintain a firewall and NAT box that has a pool of several public IP addresses (Internet access) on one of its interfaces, and 3 additional network cards connected to different networks. Each of these 3 networks contains a number of machines and some servers for various protocols that are mapped to some of the public IP addresses. One of these private networks is rather open (with protocols such as NIS and NFS used by most hosts) and another one is rather secure (no host trusts any other host on the same subnet). I do not want to allow an external attacker to guess on which network a given server could be. Maybe this extra level of security through obscurity is not really necessary, but I want to maximize my chances in case of an attack (e.g., zero-day exploits). Some services that I mapped to an external IP address and port may go to a server on one network, while the same IP address but a different port may go to a different network. I do not want to reveal too much information about the topology of my networks, that's why I like NAT.
NAT causes some connectivity issues, but I consider some of them as features, not problems. Oh, and I know that some people claim that the network hiding brought by NAT is just some false security and that IPv6 with its much larger address space will also make it difficult to scan hosts on a network. But that's not the point here: hiding the topology is just one of the many layers of security that I use, and the larger address space of IPv6 will not prevent some information from being disclosed in routing table updates, etc.
-Raphaël
Right...so, a VoIP phone (running SIP or H323, which do this sort of dynamic port-allocation) is not something useful for work?
If you take the firewall out of the equation, there is still one bit of evil left with NAT - applications that may want to set up and announce a listening port don't know what the correct IP address is. Often times they have to resort to bizarre workarounds, like asking a known external service what their own address is. Very byzantine. If nothing else, moving to IPv6 removes that headache. And if you have two machines behind a 1:n NAT that want to open up port 80, you're hosed. Without NAT, that's not a problem anymore. You'll have to tell your firewall that connections to port 80 on those machines are OK, but that's nothing more than what you would have had to do to your NAT box anyway (except that one of them would have to be port 81 or 8080 or some such nonsense).
I can't wait for the home networking routers that are so popular to implement 6to4. There's no reason they can't do that right now. Even if it were off by default, having it there would give people more options at little or no cost to the manufacturers. All of the major OSes out there shipping today support IPv6 natively.
"What'sdriving it now that wasn't driving it five years ago?"
Virtualization. Where you once had one machine serving several applications, it's now become trivial to separate applications into differing vm's for security, simplicity and scalability. You'll still want to adress the unique vm's, and ipv6 is a great way to do it.
Fast forward ten years and you'll have applications the way you have VM's today. Instead of deploying an app on a specific platform, you'll be able to deploy a VM image like you fork a process today. If you thought you needed IP's today, wait 'til your processes not only require their own PID but also their own IP address.
Actually, the inability for the small guy to get an IPv6 allocation from ARIN is more than a bit annoying. I was willing to pick up a block of IPv6 addresses to built out my data center on, and then use IPv4 tunnelling where required. I couldn't get an allocation unless I had enough customers to use a full (IPv6) /32, which of course I don't. We're just starting out, so they basically force the little guy to use IPv4, and then do a migration later. This is LAME. They don't even charge for IPv6 allocations, so far as I can tell there's a monetary sub-motive here to squeeze as much money out of IPv4 as they can, and if you're big enough, they'll let you have IPv6 for free. If you're too small, either buy an IPv4 block, or go buy an IPv6 block from one of the big guys that got it for free. :\
Karma: Chameleon (mostly due to the fact that you come and go).
First, stateful filtering is stateful filtering. Although NAT's have to be stateful in some way, they are not stateful filters by themselves as you correctly point out.
However, ipv6 has a major change which can cause massive headaches for firewall administrators: IPSec is now mandatory. IPSec provides two optional means of security: AH (which provides antitampering) and ESP (which provides encryption and antitampering). Neither of these were designed to pass through a NAT. The reason is not that NATs are bad design but rather that they break the end-to-end security that IPSec offers (i.e. any packet tampering invalidates the packet, and NATs by definition tamper with the packets).
Sounds all right so far, but with ESP, the entire payload is encrypted. This means that a party in the middle cannot evesdrop on the connection (including the TCP headers). You don't know what ports are involved. You just know what two computers are involved. If you try to use FTP over an ESP-protected connection, however, the firewall will not be able to determine the state of the data connection. Same with H.323 (though I for one welcome the death of any OSI-decended protocol). In fact H.323 would become essentially impossible to allow via ESP to arbitrary hosts without opening up the whole network because of how the control protocol works.
Hence you run into stateful filtering issues with ESP which are not possible to sort out. In practice, you have the choice of simply allowing ESP as a protocol or not allowing it, or possibly allowing it to a whitelisted set of end-points.
Oddly enough this was not discussed in the article, which seemed to spend way too much time confusing NAT and stateful filtering.
LedgerSMB: Open source Accounting/ERP