Obsession With Firewalls Could Hinder IPv6 278
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."
Translation (Score:5, Informative)
Sigh.
This is a non-issue.
What IS an issue are the new IPv6-specific things related to security. You cannot do a network scan anymore since even a
There are some implementation issues, such as anycast addresses and stuff like that you need to take into account.
However, this "getting rid of connectivity issues due to no longer having to NAT" has NEVER been expected by anyone who knows even a bit about networking. Because we're not returning to an un-firewalled world.
Re:NAT needed? (Score:2, Informative)
It has already happened (Score:5, Informative)
I suspect that commercial firewalls will probably follow suit.
Re:Its ridiculous even having to rely on firewalls (Score:2, Informative)
stateless firewalls (Score:5, Informative)
For the home user, being able to assign a routable IP to every PC has other advantages. Do you have multiple PCs with Remote Desktop running that you want to access remotely? NAT makes this difficult since all the PCs share the same IP address and need to listen for connection requests on the same port. Assigning every machine a routable address makes this problem go away. Don't like that example? The same applies to a web server, or SIP phone, or Bittorrent, or a myriad of other applications.
Re:IP6 is too complicated (Score:4, Informative)
I know you must be trolling, since configuring IPv6 is mostly identical to setting up IPv4. Type an address, a prefix length, and a gateway and go. What's so tricky about that?
Re:In order to help technology progress (Score:2, Informative)
Re:Defective by design? (Score:5, Informative)
The advantage to IPv6 is that you can have more fully routable addresses, to the point where there wouldn't be any NAT anymore -- you might still have dynamically assigned addresses, but they'd still be fully routable across the entire network. This makes firewalling a lot simpler, because you can have more than one DMZed device.
Devices which are known to be relatively secure and are designed to sit out in full view of the public -- for instance, maybe a VoIP appliance that by definition has to accept incoming traffic, but rejects everything else (but which needs lots of ports and can't tolerate NAT or much 'dumb' firewalling), could be easily put into its own DMZ without compromising the rest of your LAN. Right now, with IPv4 and only one shared IP address per household, this is fairly difficult -- all firewall rules need to be port-based. With IPv6, you can also do more complex address-based routing.
So, let's say you have a network consisting of four devices and an IPv6 firewall; you have two highly insecure Windows boxes (for whatever reason) which aren't designed to and consequently cannot safely be exposed to the world, plus a hardened BSD machine which can have certain ports exposed (say, for email and SSH), and an VoIP appliance which needs to be able to make whatever connections it wants. You configure the firewall (which all traffic passes through) to not perform any packet filtering on the VoIP appliance's address, effectively leaving it outside the perimeter. (Hopefully the manufacturer of the appliance knows what they're doing. But, to be safe, you could set it up so that traffic from it doesn't get let in to the firewalled zone, so someone couldn't compromise it and use it to get in to the rest of your network.) The BSD machine's address gets only the necessary ports opened, with everything else to it automatically rejected. And the Windows boxes are totally firewalled, with all incoming connections rejected unless a port is specifically requested open.
The firewall required to do this isn't any less complex than a current NAT/stateful-firewall, but it provides several advantages. Rather than having only one externally-facing address for the entire LAN, and routing traffic based on the port or TCP connection, you can just route based on the IPv6 address, and create all sorts of (in)flexible rules based on how much trust you have in the destination device, which can include creating further subnets that are isolated from each other, for security purposes.
IPv6 isn't "insecure," in fact I think its wide adoption will greatly enhance end-user security, once people start figuring out how to work with it, and the Linksys and Netgear-type manufacturers start building inexpensive boxes to do the job.
The main difference between v4 and v6 is that with v4, there's a clear demarcation between "LAN" and "WAN." With IPv6, this isn't quite as true; rather than thinking of security in terms of castle walls, you need to use a more fluid metaphor. Everything in your house is part of the "WAN," in terms of addressing, but parts of it may be more secure than others.
The headline is dead on (Score:3, Informative)
Computers sitting behind a NAT router, which is pretty much all the firewall most machines need, come factory-loaded with Norton Internet Security or McAfee Security Center. This makes it nearly impossible for the average home user to share files and printers, and (especially with Norton) makes it very likely that they will answer some of the hundreds of pop-up questions wrong and break something they want:
"MSIMN.exe is trying to access the Internet!
What do you want to do:
1. Permanently block it?
2. Dial 911?
3. Buy even more Norton crapware?
I try to explain to my customers that they want a hardware firewall (the router) and don't really need a software firewall other than the one-way jobbie that ships inside Windoze.
OTOH, one customer this morning still has an XP SP1 machine plugged directly into her cable modem... guess what happened to her machine?
Oh, well, I get paid to fix these kind of problems, so I guess I don't mind. God forbid they ever get it right!
Re:IPv6 is comming, very soon now... (Score:3, Informative)
It's not like anyone is expecting an overnight change, as IPv6 was designed to co-exist with IPv4 for some years. But once the number of IPv6 sites reaches some critical mass, abandonment of IPv4 will be quick. Early adopters of IPv6 will absolutely not find themselves penalized, assuming that their ISP does in fact support IPv6, as they can do everything they can currently do with IPv4 with IPv6 and possibly more.
Re:Defective by design? (Score:3, Informative)
Basically, it's just like an Ethernet VLAN, except it would be as part of a router, not a switch, because you're one level higher on the OSI model. (Ethernet is Layer 2, IP is Layer 3.) But fundamentally it's a similar idea; a subnet is really just a Layer 3 VLAN. (In actuality, I think on most networks there is a 1:1 relationship between Ethernet MACs and IPv6 addresses, so the difference between routers and switches will probably become even more nuanced.) But it's not hard to set up, it's just a matter of configuring the firewall-box's routing table appropriately. (Which in a consumer appliance would be set up already, probably with a clearly marked plug on the back for them to attach their VoIP ATA into.)
Basically you could just tell your home-router to route all traffic destined (based on the IPv6 address) for your VoIP box directly to its destination, unfiltered, but also to not treat traffic coming from that VoIP box any differently from traffic coming from anywhere else on the net. It would effectively be walled off in its own logical network. Someone who compromised it would still be able to use your WAN connection to send out viagra spam, but they wouldn't have any access to the rest of your network, any more than they already do from the outside.
Re:NAT needed? (Score:1, Informative)
Think about it - your firewall is usually a different machine than the one the, er, less than technically savvy users, are using to run their applications on. Say one of them gets a virus or trojan that is able to exploit a hole and create a hole in the local firewall. *poof* you are toast.
With an external firewall box, you have limited your exposure, since that trojan more than likely is not going to break into that box from the outside, or even the inside, should it get in. So, it *still* can't get out to the network.
It's called "don't put all your eggs in one basket." Think a little next time...
Re:NAT needed? (Score:5, Informative)
Such a NAPT does offer security because it disallows all uninvited incoming connections and thus shields "services" running on systems inside of the NAPT from access from the Internet.
Sure. But what they're really describing isn't NAT, but rather the stateful firewall that's inherent in all non-trivial implementations of NAT.
Since you can take just the stateful firewall part, and use it with IPv6, there's no security disadvantage there. All you lose is the kludgy NAT parts, and in trade you gain the ability to do much more complex and useful routing -- creating various subnets with different security levels, etc. It's nothing that hasn't been going on with big corporate networks for years (those companies that have Class A blocks and can afford to give every workstation a 'real' IP still have firewalls and security policies), but now home users can have the same flexibility, if they want it.
One word: (Score:4, Informative)
SIP [wikipedia.org].
Right now, most people haven't run into it, but there's no easy way to have multiple SIP VoIP "lines"* into your house, when you only have one IP address.
* I mean "lines" in the POTS sense, of independent full-duplex telephone circuits, each with their own numbers. And yeah, I know you can get this if you use protocols other than SIP, but they have their own problems.
IPv6 offers that. (Score:4, Informative)
You might want to read this document from the IETF regarding privacy and IPv6. Ensuring privacy, or at least not eliminating it, was a major concern of theirs during the design of v6, and I think you'll find that your privacy is protected just as well or better than it is under IPv4 (which is to say, not really all that well, but if it gives you a warm fuzzy feeling to think so, enjoy).
http://playground.sun.com/ipv6/specs/ipv6-address
Multiple reasons. (Score:3, Informative)
A good example could be synergy. Let's say I'm a user interested in the program. I'm semi-lazy so I like the quicksynergy front end. If you ever use synergy, you know that it doesn't in and of itself bother with meaningful authentication or encryption. Also, while the daemon itself supports being explicit in terms of which IP interfaces to bind to, the quicksynergy frontend does not expose the relevant configuration options. So while I know how to make use of ssh to port forward and authenticate for me, out of the box I still may leave synergy hanging out accepting any connections on the IP network. Considering synergy could effectively be a means to do keylogging (if user accidently moves mouse to wrong place for example), this is highly dangerous. Now, my distribution being fairly restrictive had placed hard and fast firewall rules in place to only allow blessed applications access in, except on lo. If I wanted to shoot myself in the foot with synergy, I'd now have to jump through some hoops and hopefully in the process learn why it's a bad idea. There probably exist poorly designed but useful network daemons that don't even allow interface-specific binding, in which case firewall rules bridge the gap. You can't always shut down a process that does foolish things in terms of listening on sockets you don't like without configurability to get around it, sometimes you need that process to run and the network to be denied by a layer the process can't mess with and even is unable to absolutely confirm exists.
Yes, well-written applications should not do inappropriate things with listening sockets without the ability to lock it down. However, the world is full of not-so-well-written applications. The key is letting those apps think they are doing what they want with the firewall ruleset under the covers establishing the reality in ways the application cannot see or change. Good frontends for 99% of usage out there exist (OSX I believe makes it obvious when enabling a service it is also futzing some firewall rule to complement that, so it is intrinsically linked in the dialog most anyone will deal with).
This is one aspect where I disagree with Ubuntu philosophy. Ubuntu philosophy is along your lines (don't bother with iptables rules by default, they just get in the way and the user knows what they are doing). This seems incongruous with the whole mission of linux for the masses that Ubuntu is about.
Re:NAT needed? (Score:2, Informative)
Re:One word: (Score:3, Informative)
I have this going on about 5 servers, each with several SIP registrations (often to the same service) in place.
SIP is idiotically complex, that is why IAX was invented, which all happens on one port.
But the people writing clients, servers, and client/server combos (eg Asterisk) are actually more clueful than
the vested interests that keep pushing IPv6 to a disinterested world. IPv6 reminds me of the Bell System's Picturephone, which
I used decades ago. It worked fine. Many other video-phone solutions exist. The bottom line is, there's no screaming need for it.
NAT is here to stay, just as is substandard overpriced 'broadband' service, at least here in Freedomland.
Re:stateless firewalls (Score:3, Informative)
This is totally correct, but there are also other problems with stateless firewalls...
Let me explain what a stateful firewall does (not to you obviously, but I'm reading comments from lots of people that do not seem to fully understand the issue).
A stateful firewall can filter traffic not by just "blocking" some protocols or addresses/ports.
It can police traffic using the abstraction of "connections": you are able to tell it "allow NEW connections to this service, but not to that. And please let come in all traffic that pertains to already ESTABLISHED connections. Discard all INVALID - not NEW or ESTABLISHED - traffic" (yes, I'm taking the terms directly from linux's iptables/netfilter).
This is not simple as it seems... first, there are lots of problems with defining what a "connection" is just by looking at the traffic from the kernel's POV because is usually an application's (user space) work to make sense of all those bytes carried in the payload of TCP/UDP packets.
For plain old tcp session, like the ones used by SMTP or HTTP, this is easy: the protocol itself has the concept of "sessions" (every packet carries a "sequence number" that is used to identify the packet as part of a "session" - yes, this is a possible attack vector, and no, it's not _that_ easy to guess/brute force them. Not anymore). So, HTTP/SMTP and the like are EASILY firewalled and NATted.
But with ICMP or UDP? You have to do some smart tricks in order to implement the "connection" concept, for example: ok, we do not have session numbers, but if you send an ICMP echo request to an IP address, we should expect an ICMP echo reply to come back sooner or later from that same IP address, so here is your ICMP "session" (almost). Sending an ECHO request and receiving (or not) an ECHO reply is what actually happens when you use the "ping" command.
And beasts like FTP or SIP, H323, PPTP... the lot? Those nasty guys generally work by opening a TCP "control" connection, where protocol commands and responses are expected to travel... at some point during the conversation someone issues a command telling the other part(s) to expect a new connection on some other port and maybe with some other protocol... this command means something only to the high-level applications implementing these high-level protocols. It doesn't mean shit to the kernel, because this is not IP, TCP, UDP or ICMP: it's an higher level abstraction.
This is why you have to write special "helpers" for these protocols to bridge the gap and make things work: the "helpers" can intercept and understand the high level protocol commands and manipulate the kernel's notion of what low level traffic is RELATED to an already ESTABLISHED connection, because the kernel can't tell by itself.
In the case of FTP, the corresponding helper looks for the command "open new connection on port xxxrandomxxx for data transfer" (actually, the PORT and PASV commands) in the traffic travelling through the firewall, it figures that the important part is "port xxxrandomxxx" and then marks as "RELATED" traffic coming/going to port xxxrandomxxx (yes, "helpers" are another attack vector, and no... they are generally smarter than in my description, I am oversimplifying... (*)).
The same tricks are needed for some forms of NAT: specifically, the one when you have many hosts/PC on the "inside" and just one public routable address on the "outside" - Cisco calls this "PAT" - so the firewall needs to track "connections" to succesfully map traffic between external and internal hosts. Other forms of NAT includes the much simpler 1:1 (you have 'n' internal addresses and 'n' external addresses) and do not _require_ the tricks.
Having said all that...
Accepting ESTABLISHED tcp connections from port 80 (http) is a LOT different than just allowing generic tcp packets whose source is port 80 to come in, for example.
In the first case you're allowing only legal traffic that constitutes a response to your requests, as per th
Congrats. (Score:3, Informative)
IPv4 is going to die, and NAT along with it, it's just going to take a very, very long time. The main problem with IPv6 has nothing to do with its core functionality, the problem is that it had a serious case of featureitis (e.g. IPSec); if the IETF cut out the crap and just let people implement the long addresses without the rest of the stuff better left to the application layer, it would probably get implemented a lot faster.
Re:Defective by design? (Score:3, Informative)
NO!
Firewall != NAT
NAT != Firewall
Please move along.
Re:Security by obscurity doesn't work (Score:5, Informative)
However, I don't think the argument is "the large IPv6 address space provides robust security" but rather "it's an extra roadblock to attackers."
Switching to the large IPv6 address space doesn't mean that we can get lazy with patching our boxes, surfing safely, blocking ports, having strong passwords, and so on. However, it does mean, at least, that one vector of attack (port scanning) is no longer possible, or at least very difficult.
All the workarounds and attacks you describe are certainly possible, but they mean extra effort on the part of the attacker, which induces a corresponding decrease in the frequency and success rate of attacks. And it's worth noting that in addition to the workarounds that the attackers will no doubt employ, there may very well be some clever usages of IPv6 to counter them. For instance, if I'm in control of 10^20 addresses, I may run my web browser from a VM whose IP address changes on every connection. So knowing the IP of my web-browser doesn't give you the IP of my file server, etc. Similarly the 10^20 - 4 addresses that I'm not using can be a very efficient honeypot for detecting attackers.
To re-iterate: the large address space of IPv6 should not be viewed as "killer security"... but nor should we ignore that it will provide a (arguably minor) security advantage.
Re:Security by obscurity doesn't work (Score:3, Informative)
And on a dense IP space like IPv4, it's also the fastest method of scanning and spreading. For a worm propagating in its initial phases, its rate of growth is determined by how many "hits" it gets over N probes. By moving from IPv4 to IPv6, the search space goes from "very dense" to "highly sparse". If the worm still propagated by random probes, its growth rate would decrease by a factor of ~ 2^96 -- to essentially nil.
This means that a hypothetical IPv6 worm would have to use some sort of passive scanning. This algorithm is much harder to implement, and it also implies that there must be a continuous connection path for the worm to spread. Since, for example, web connections (between servers) are isolated (foobar.com does not talk to yahoo.com does not talk to google.com), this implies that entire categories of worms are essentially impossible to develop.
Re:IPv6 Needed? (Score:2, Informative)
The process for getting v4 IP's directly from ARIN complicates [arin.net] that a bit...
The minimum allotment is a
ARIN also demands that before you can qualify, you must use 75% of the allocation within 90 days of it being assigned to you, otherwise you run the risk of having the IP's revoked.
If you're Multi-Homed (multiple carriers terminating at the same endpoint [your network] using BGP) than the minimal is a
Article is misleading (Score:3, Informative)
The problems that the article describes — FTP, IM file transfers, etc. — have exactly the same problems under NATless IPv4 stateful firewalls. The Internet hasn't fallen over yet, therefore the problem is overblown.
The solution in Linux has generally been application-specific kernel modules (ip_conntrack_ftp, ...) that tell the state engine (ip_conntrack) to expect related traffic. They might've finally added a user-mode interface since last time I looked, but that doesn't actually solve the problem since any user-mode program is still forced to sniff forwarded traffic for known applications.
The more elegant solution would be for each application to indicate a related connection in a way that all stateful firewalls along the route could understand. Sort of like UPnP, except UPnP only talks to a single local NAT, not every firewall along the route. However, this more elegant solution hasn't yet been invented, for IPv4 or IPv6.