What's new in 2.1?
-
IPv6 is anyway a nightmare, because everyone pushed it out as long as they could (OS vendors, ISPs, etc.) that I expect quite a few hidden bugs and tons of exploits as IPv6 gets battle-hardened. So IPv6 in a firewall is extra trouble.
Not sure if I completely agree with "everyone". FreeBSD (the OS basis for pfSense) has had IPv6 support in its base system for over ten years now, and this support originally came from the KAME IPv6 stack, which is one of the oldest production IPv6 stacks on the net. Much of the FreeBSD Project's infrastructure has been dual-stack for at least five years. One of my ISPs offered IPv6 to its customers starting around 2003.
So while it's probably true that a lot of people ignored IPv6 for much longer than they should have, this isn't universally true.
Bruce.
PS. The FreeBSD examples I cited above are not intended to detract from any other open-source project. It's just that those are the cases with which I happen to have personal experience.
-
IPv6 is anyway a nightmare, because everyone pushed it out as long as they could (OS vendors, ISPs, etc.) that I expect quite a few hidden bugs and tons of exploits as IPv6 gets battle-hardened. So IPv6 in a firewall is extra trouble.
Not sure if I completely agree with "everyone". FreeBSD (the OS basis for pfSense) has had IPv6 support in its base system for over ten years now, and this support originally came from the KAME IPv6 stack, which is one of the oldest production IPv6 stacks on the net. Much of the FreeBSD Project's infrastructure has been dual-stack for at least five years. One of my ISPs offered IPv6 to its customers starting around 2003.
I'm aware of that, but my point is a different one. e.g. Mac OS X has been around for a while, and while it's in many respects indeed more secure than say Windows, the fact that there were close to zero exploits was less a function of it being more secure, than of it not being widely enough used to be an attractive target. Now, that it's getting more and more wide-spread, one hears more and more about exploits, and that even though OS X is getting more secure than it used to be. So the security of a product is only one part, the other is whether it's commonly used enough to make an attractive target.
I believe that there will be a similar dynamic with IPv6: right now there are just not enough attractive targets for IPv6, and whatever targets there are pretty much all run dual-stack connectivity, so they might as well be attacked over the known IPv4 access.
The expertise on IPv6 is much more thinly spread, on both sides of the cat & mouse game, than IPv4.
So in that sense even the old IPv6 stacks in BSD haven't seen the kind of attention from hackers as IPv4 has seen over the years, and so I expect vulnerabilities of which currently nobody even thinks about to rear their ugly heads as IPv6 becomes common and starts to become the norm.
I bet, there will be exploits that are even based on things like people not being familiar with the IPv6 address format, where people get duped into entering false information, etc. Heck, I might be a good target, because IPv6 address to me still look strange… Got catching up to do, I'm sure I'm not the only one out there.But that's just my guessing, based on historical patterns, so I may be totally off...
-
I dont know….for me its only a public IP address problem....
I think IPv4 would exist for many years on internal networks and be translated to IPv6 when passing through a firewall or router.
-
I believe that there will be a similar dynamic with IPv6: right now there are just not enough attractive targets for IPv6, and whatever targets there are pretty much all run dual-stack connectivity, so they might as well be attacked over the known IPv4 access.
The expertise on IPv6 is much more thinly spread, on both sides of the cat & mouse game, than IPv4.I'd agree with most of that. Past experience shows that those operating on the black hat side of things are able to move much faster than those trying to stop them.
I suspect that right now there are large number of juicy misconfigured IPv6 targets out there. There have got to be plenty of people running IPv6 who don't even know they are.Steve
-
IPv6 is anyway a nightmare, because everyone pushed it out as long as they could (OS vendors, ISPs, etc.) that I expect quite a few hidden bugs and tons of exploits as IPv6 gets battle-hardened. So IPv6 in a firewall is extra trouble.
Not sure if I completely agree with "everyone". FreeBSD (the OS basis for pfSense) has had IPv6 support in its base system for over ten years now, and this support originally came from the KAME IPv6 stack, which is one of the oldest production IPv6 stacks on the net. Much of the FreeBSD Project's infrastructure has been dual-stack for at least five years. One of my ISPs offered IPv6 to its customers starting around 2003.
I'm aware of that, but my point is a different one. e.g. Mac OS X has been around for a while, and while it's in many respects indeed more secure than say Windows, the fact that there were close to zero exploits was less a function of it being more secure, than of it not being widely enough used to be an attractive target. Now, that it's getting more and more wide-spread, one hears more and more about exploits, and that even though OS X is getting more secure than it used to be. So the security of a product is only one part, the other is whether it's commonly used enough to make an attractive target.
So that's true, but I just didn't want you to forget that there have been developers, admins, and users deploying and running IPv6 for a number of years now, and some of us actually have real operational experience with it. We have learned some things along the way (such as the "type 0 routing header" issue). I appreciate your comparison with MacOS and visibility.
The fact that there are some different attacks against IPv6-connected targets is a reason why having IPv6 support in your firewall is actually a good thing (I'm thinking of your comment along the lines of "IPv6 in a firewall is extra trouble"), assuming you have IPv6 connectivity or think you might be getting it. It's useful to mitigate against some of these attacks (note I didn't say "prevent", just as I wouldn't say that an IPv4 firewall makes you completely safe from IPv4-based attacks). As I'm sure you know there are quite a few attacks against users ("click on the link in this email!") that are independent of what layer 3 network protocol you have.
Bruce.
-
Thats why you need L7 firewall as a complement to you normal frontend!
-
Thats why you need L7 firewall as a complement to you normal frontend!
Maybe so. Anyway, we probably dragged this conversation way too far afield from what new features there are in pfSense 2.1. :-)
(To sort of bring things back on track, I upgraded to a snapshot from a couple days ago…I very much like the change from openntp to the stock ntp.org ntpd daemon, at least I can understand what it's doing now, especially with the new status page...thanks developers for making that switch.)
Bruce.
-
I'm happy with the change to ntpd also (and I'm the one that did it :-) but I did hit some issues along the way. OpenNTPD had been causing us more and more trouble lately, and this way we not only get a good status output, but also it's IPv6-ready. (There may be a new version of open that is as well, but given the choice I'd rather go the way we did).
Still planning on adding support for the new per-interface listen/binding options that are in the ntpd from ports, haven't gotten to that yet. Also the status page uses ntpq now, but I was toying with the idea of using ntpdc instead.
They seem to provide different status code for the same peers at the same time, though. I need to read more on ntpdc to find out why.
-
I'm happy with the change to ntpd also (and I'm the one that did it :-) but I did hit some issues along the way. OpenNTPD had been causing us more and more trouble lately, and this way we not only get a good status output, but also it's IPv6-ready. (There may be a new version of open that is as well, but given the choice I'd rather go the way we did).
Thanks Jim. :-)
And yes the NTP-over-IPv6 is nice too…one of my timeservers is dual-stack and that works just great. I also liked the way you interpreted the various ntpdc status characters in the NTP status display for a more user-friendly interface...I wish the NTP status display in my product at ${REALJOB} looked this good.
Bruce.
-
I'm still trying to poke at ntpdc a little and figure out why the status is different. Still using ntpq now, and it's tally codes don't line up 100% with ntpdc's peer modes.
For instance:
From ntpdc(8):
The character in the left margin indicates the mode this peer entry is operating in. A `+' denotes symmetric active, a `-' indicates symmetric passive, a `=' means the remote server is being polled in client mode, a `^' indicates that the server is broadcasting to this address, a `~' denotes that the remote peer is sending broadcasts and a `*' marks the peer the server is cur- rently synchronizing to.And from ntpq(8):
Tally Codes The character in the left margin in the `peers' billboard, called the tally code, shows the fate of each association in the clock selection process. Following is a list of these characters, the pigeon used in the rv command, and a short explanation of the condition revealed. space (reject) The peer is discarded as unreachable, synchronized to this server (synch loop) or outrageous synchronization distance. x (falsetick) The peer is discarded by the intersection algorithm as a falseticker. . (excess) The peer is discarded as not among the first ten peers sorted by synchronization distance and so is probably a poor can- didate for further consideration. - (outlyer) The peer is discarded by the clustering algorithm as an outlyer. + (candidat) The peer is a survivor and a candidate for the combin- ing algorithm. # (selected) The peer is a survivor, but not among the first six peers sorted by synchronization distance. If the association is ephemeral, it may be demobilized to conserve resources. * (sys.peer) The peer has been declared the system peer and lends its variables to the system variables. o (pps.peer) The peer has been declared the system peer and lends its variables to the system variables. However, the actual sys- tem synchronization is derived from a pulse-per-second (PPS) sig- nal, either indirectly via the PPS reference clock driver or directly via kernel interface.So while the ntpq codes give more accurate information on some areas, ntpdc seems to give more in others. I think we'll stick with ntpq for now, though I do need to see a little more about how both of them give info about clients syncing from this ntpd as a server.
…and now we're straying properly off topic. :-)
