Completely Disable IPv6 in FreeBSD 10

C

Caleb Payne

I've just about pulled all of my hair out trying to figure this out. I vaguely recall (several months ago now) absentmindedly consenting to "configure this interface for IPv6" or to "enable IPv6" during installation. I really hadn't given it a lot of thought, though I've recently read the spec for it and find it atrocious and, from a security standpoint, heart-stoppingly-horrifying. That, of course, is only tangentially related to the post.

Having spent the better part of the past two days trying, in vain I might add, to completely disable IPv6 in the kernel, I can't seem to do it. I've added the obligatory lines to /etc/rc.conf:
Code: 
ip6addrctl_enable="NO"
ip6addrctl_policy="ipv4_prefer"
ipv6_activate_all_interfaces="NO"
ipv6_network_interfaces="none"
Those were selected from a handful of online posts that seemed related, and from running through the /etc/defaults/rc.conf file and finding any seemingly relevant IPv6 settings and saying "NO!"

However, these haven't achieved the desired goal. Essentially, what I would like to see when I check the sysctl for the kernel ipv6 feature is as follows:
Code: 
sysctl -n kern.features.inet6
0

Short of that, I would at least appreciate it if, after booting, I can do a netstat -nr and not see a handful of IPv6 routes. (I'd also very much appreciate not seeing two inet6 addrs for lo0 -- ::1 and some link-local junk that it adds.) (For clarification, yes, even after appending the aforementioned lines in rc.conf loopback still comes up with a pair of inet6 addresses, my tun0 address adds one (link local) and there are about a dozen or so routes in my routing table which I would have posted had I not immediately gone through and manually deleted them -- along with the inet6 entries for all interfaces -- after I booted.)

If this requires a custom kernel, then so be it -- I'm sure there's a way to undefine INET6 and leave it all out of the kernel. If that's not possible and there's really no easy way to do it, then I will write a kernel module to kill as much of it as is possible, though I highly doubt it'll come to that. I'm hoping for someone to say, "hey, idiot, add this to loader.conf or set this in rc.conf, sysctl.conf or some other one-liner."

Any help would be greatly appreciated!
 
I've not played with IPv6 but the thing that strikes me about your post is you are checking a sysctl(8) relating to available kernel features. Surely this will only report IPv6 being unavailable if it actually isn't built into the kernel in the first place. In this case you probably want to look into the /etc/make.conf option to disable IPv6 in the kernel, then rebuild.

A quick search suggests the following: (I'm not in a situation where I can easily find references at the moment, but someone else on the forum will probably know for sure)
Code: 
WITHOUT_IPV6="YES"
Edit, as per getopt 's response, it looks like src.conf is the better place to put this.

I'm intrigued by your complete insistence that it is switched off though. What's your source behind it being "heart stoppingly worrying from a security standpoint"?
 
There's no reason to turn off IPv6 if all you have is the link local addresses (fe80::/10) prefix), they can not be used for attacking your system from the outside anymore than with the standard IPv4 addresses. IPv6 is secure and a huge improvement over IPv4 in all aspects, stop believing the FUD that goes around about IPv6's supposed security problems.
 
getopt, yeah I updated my post after seeing yours. The first info I came across mentioned make.conf. I suspect using make.conf works, but as it applies to everything that uses make, it's more "correct" to put these system/kernel options in src.conf where they can only affect src builds.
 
getopt said:
I do not buy it, unless you you enlighten us. :)
Click to expand...

For starters:

- You have endless number of prefixes and possible routable addresses. We will never run out of IPv6 addresses even if we try really hard.

- You have official prefixes for link-local and multicast addresses. You no longer have broadcast addresses that you have to worry about.

- IPSEC is an official part of the IPv6 spec.
 
Maybe you should disable IPv4 in your kernel as well then. It looks like you actually have that configured with routes through to the Internet. ;)
 
kpa said:
There's no reason to turn off IPv6 if all you have is the link local addresses (fe80::/10) prefix), they can not be used for attacking your system from the outside anymore than with the standard IPv4 addresses. IPv6 is secure and a huge improvement over IPv4 in all aspects, stop believing the FUD that goes around about IPv6's supposed security problems.
Click to expand...

In fact, I have intentionally shied away from the /. and arstechnica and (insert-your-online-armchair-expert-publication-here) threads on IPv6 for that very reason (FUD). Instead, what I read that inspired fear came from the wikipedia article. Auto-configuration seems like a Charlie Foxtrot of epic proportions. The thought of a "more flat" address space (versus a hierarchical address space provided through NAT) is, based on my experience, dumb. Then, there's IPv6 mobility: http://www.ietf.org/rfc/rfc3775.txt

Link-local (and any other "restricted" address, such as IPv4 private address space addresses 10.0.0.0/8, 192.168.0.0/16, etc.) can be leaked by misconfigured routers. It happens all the time with IPv4 -- a protocol that is well known and, for the most part, well managed. Imagine what's to come when sites running IPv6 start leaking their mess onto the internet (due to a lack of understanding of a massively complex new protocol with some very, very distinct and significant differences from IPv4). Its cases like those that have brought me to the "let's remove it entirely from the kernel" decision -- if the kernel doesn't know what it is, doesn't know what to do with it, then it can drop it on the floor and it isn't an issue.

Your assertion that IPv6 is "secure and a huge improvement over IPv4 in all aspects" is 100% subjective. Your stated reasons for believing in its superiority are not convincing (at least not to me).
 
getopt said:
See src.conf(5) for INET6 and edit /etc/src.conf accordingly.
In /etc/rc.conf I have the same.
Item kern.features.inet6 does not exist anymore here :)
Click to expand...

I actually just went in and did make buildkernel KERNCONF=<my new conf> with the options INET6 commented out. In fact, it just finished compiling, so I'll install it, reboot and see how it goes. Thanks for your help!
 
Caleb Payne said:
Link-local (and any other "restricted" address, such as IPv4 private address space addresses 10.0.0.0/8, 192.168.0.0/16, etc.) can be leaked by misconfigured routers. It happens all the time with IPv4 -- a protocol that is well known and, for the most part, well managed. Imagine what's to come when sites running IPv6 start leaking their mess onto the internet (due to a lack of understanding of a massively complex new protocol with some very, very distinct and significant differences from IPv4). Its cases like those that have brought me to the "let's remove it entirely from the kernel" decision -- if the kernel doesn't know what it is, doesn't know what to do with it, then it can drop it on the floor and it isn't an issue.
Click to expand...

I here challenge you to prove that "leaking" link local addresses can be used for attack purposes. Also I challenge you to show how exactly such "leaking" of the mentioned addresses happens. References to good quality research that demonstrates such scenarios pretty please.
 
kpa said:
I here challenge you to prove that "leaking" link local addresses can be used for attack purposes. Also I challenge you to show how exactly such "leaking" of the mentioned addresses happens. References to good quality research that demonstrates such scenarios pretty please.
Click to expand...

How do you leak a private address?

netstat -nr (results edited to remove all but the networks and gateways)
Code: 
Kernel IP routing table
Destination     Gateway
10.4.0.9        0.0.0.0
192.168.50.13   0.0.0.0
10.4.0.1        10.4.0.9
172.16.1.0      192.168.50.13
192.168.4.0     0.0.0.0
192.168.50.0    192.168.50.13
192.168.122.0   0.0.0.0
10.20.30.0      0.0.0.0
10.20.30.0      0.0.0.0
172.31.16.0     10.4.0.9
169.254.0.0     0.0.0.0
10.8.0.0        192.168.50.13
0.0.0.0         192.168.4.1

Here's a network I don't know about, so it's going to go through my default gateway (where, incidentally, I have just temporarily removed my DROP statements for outbound addresses in the private address spaces, including those that I know nothing about):
traceroute 192.168.3.5
Code: 
traceroute to 192.168.3.8 (192.168.3.8), 30 hops max, 60 byte packets
1  192.168.4.1 (192.168.4.1)  0.522 ms  0.508 ms  0.493 ms
2 [BLOCKED]
3  10.242.21.33 (10.242.21.33)  1.983 ms  1.977 ms  1.971 ms <-- This isn't in my facility!!
4  [MY ISP] (x.24.99.54)  2.447 ms  2.653 ms  2.379 ms
5  10.242.95.6 (10.242.95.6)  6.134 ms  6.379 ms  6.377 ms <-- More 10.0.0.0 addrs ...
6  (x.145.84.46)  8.040 ms  7.451 ms  7.726 ms
7   (x.145.84.47)  5.472 ms  5.430 ms  5.418 ms
8   (x.145.84.46)  7.830 ms  8.217 ms  8.477 ms
9   (x.145.84.47)  5.836 ms  5.339 ms  5.814 ms
10  (x.145.84.46)  8.743 ms  7.306 ms  7.295 ms
11  (x.145.84.47)  5.537 ms  5.537 ms  5.527 ms
12  (x.145.84.46)  7.508 ms  7.820 ms  7.768 ms
13  (x.145.84.47)  5.468 ms  5.467 ms  5.806 ms
14  (x.145.84.46)  8.100 ms  8.360 ms  8.353 ms
15  (x.145.84.47)  5.730 ms  5.728 ms  5.405 ms
16  (x.145.84.46)  7.999 ms  7.997 ms  7.681 ms
17  (x.145.84.47)  5.447 ms  5.638 ms  5.625 ms
18  (x.145.84.46)  7.733 ms  7.737 ms  7.731 ms
19  (x.145.84.47)  6.142 ms  6.140 ms  5.188 ms
20  (x.145.84.46)  7.654 ms  7.988 ms  7.944 ms
21  (x.145.84.47)  5.608 ms  5.405 ms  5.388 ms
22  (x.145.84.46)  7.909 ms  7.883 ms  7.878 ms
23  (x.145.84.47)  5.632 ms  5.621 ms  5.608 ms
24  (x.145.84.46)  7.798 ms  8.126 ms  7.580 ms
25  (x.145.84.47)  5.566 ms  5.487 ms  5.452 ms
26  (x.145.84.46)  7.420 ms  7.884 ms  7.920 ms
27  (x.145.84.47)  5.424 ms  5.669 ms  5.657 ms
28  (x.145.84.46)  7.885 ms  8.282 ms  8.281 ms
29  (x.145.84.47)  5.864 ms  5.699 ms  5.689 ms
30  (x.145.84.46)  7.844 ms  7.841 ms  7.819 ms

As you can see, I have "leaked" a private address (I don't know what to do with it, so it goes through my default gateway) and my fiber provider doesn't block this private address space incoming (which they *should* be doing), so it bounces around inside their network for a little while until TTL has decremented to 0. Voila. Leaked a private address by a smidgin' of carelessness on my end and on the ISP's end. If a relatively large regional ISP can get that wrong with IPv4 which has been around for years, imagine what someone even less competent can do with IPv6.

As for how to be malicious with that, I'll leave it to the reader to be creative. Or to spend some time on google or where-have-you. Being new to the forums, I don't want to go way off-topic or step on too many toes ;)...
 
Uhm, no. You can trace a whole bunch of RFC1918/link-local addresses that seemingly are reachable with traceroute(8) because the routers just keep "passing the puck" and sending the packets to the next upstream router. However, the question is always: Is there actually a host somewhere with the traced address that can reply back to your system. The answer is almost 100% no because there's no routing set up back to your address and even if there was the multitude of routers in between you and the other host would have to allow RFC1918 addresses to pass trough. Maybe there is one router that is misconfigured in such a way but what are the odds of 10-14 routers in the chain having the same misconfiguration? Non-existent unless you're into conspiracy theories :p

As for your trace, your ISP seems to be using some clever routing tricks to save addresses and has placed RFC1918 networks in between you and the node holding the public IP and has done the same with the network between the public IP and the internet. I've seen similar configurations on mobile networks and it's nothing to worry about. There's no way to try to contact your system from the internet using those 10.*.*:* addresses because your ISP is doing NAT on the node that holds the public IP address. Even knowing the full details of what your ISP is doing with routing gives no additional attack surface.

By the way, what does it matter if your system is reachable with RFC1918/link-local addresses over the internet? You do have a properly configured firewall don't you?

If we go back to the IPv6, the IPv6 link-local addresses are even less useful for the potential attacker because they are valid only inside the same broadcast domain (an ethernet segment in other words) (just like MAC addresses in fact). IPv6 disables any possibility to route those addresses by design and it would take a very big effort to change the IPv6 stack on any OS to actually enable routing of IPv6 link-local addresses, it just doesn't happen.
 
In this particular case, I am NATting my internal 192.168.4.x address to my public address at the gateway. While the scenario above doesn't pose any immediate risks to me or my network, it potentially does for the ISP. I can simply issue requests on reserved ranges all day long and -- as long as my router is passing them out -- there *is* potentially someone on the other end who would listen (because my NATted address is routable all throughout their network -- its an address that they own). We discovered this a few months ago, nmapped a few of the hosts in the address spaces exposed and sent them an email with the results (some were listening on SSH, HTTP, SMTP, etc.) So, in my example -- no -- I didn't "leak" anything ... at worst I NATted for an address I shouldn't have and the ISP attempted to forward it, even though it likely shouldn't have.
 
kpa said:
By the way, what does it matter if your system is reachable with RFC1918/link-local addresses over the internet? You do have a properly configured firewall don't you?
Click to expand...

And this is the core of it -- I think we've kinda been on the same page for the whole thing here, the difference being my inability to express exactly what I was thinking and my greater degree of cynicism. I'm by no means a network guru -- I write daemons and kernel modules for everything from SoCs to distributed systems -- I'm a C developer, not a network admin. The only reason I've ever done any network administration is because our admin quit and I had the second most knowledge which isn't a whole heck of a lot. My whole point has been: the community is very, very intimate and familiar with IPv4, yet we still see all sorts of breaches stemming from misconfiguration (unintentional or otherwise, if you want to go down that conspiracy theory route). There is a lot to learn about IPv6, we have a fraction of a fraction of a fraction of the knowledge, experience, tools, etc. to work with it and -- at least for the foreseeable future -- there are likely going to be some very significant gotchas.

In my position with what I do, it is not a concern. We will not be supporting IPv6 any time soon (and quite possibly not even before I retire) so -- since I have the luxury of not having to think about it (or worry about the potential unintended consequences a bad configuration somewhere down the line) I have chosen to do so. Not due to FUD, nor a lack of comprehension of the protocol, but more out of a high level of distrust in those who are implementing it -- people who, like me, were tossed into the position because they had just enough knowledge to make things work.

Aside: as a developer I can say that the thought of dealing with 128-bit addresses is an uber-giant turnoff as well.
 
Caleb Payne said:
In my position with what I do, it is not a concern. We will not be supporting IPv6 any time soon (and quite possibly not even before I retire)
Click to expand...

I am not sure in which type of industry you work. But for me your product(s) would immediately be disqualified because IPv6 support is a must have.
 
You must log in or register to reply here.
Back
Top