As promised in episode #22, here are some simple but useful things you can do with IPv6 Autoconfiguration but can’t do with DHCP.
Table of Contents
00:00:27 My test setup
00:01:50 Redundant router failover using Autoconfiguration
00:08:25 The high end alternative: First Hop Router Redundancy using HSRP, VRRP, CARP etc.
00:10:50 Fighting rogue (advertising) routers
00:12:52 Detour: DHCP Guard and RA Guard running on switches
00:14:02 Why rogue routers are easier to handle than rogue DHCP servers
00:15:05 The ramond tool
Thank you for mentioning RAMOND. I generally dislike “network security” software, because either you solve the problem once and for all with cryptography or you try to play cat and mice with attacker and use “network security” software. However, using RAMOND to avoid problems due to misconfiguration seems reasonable. I doubt that it works in all situations and I guess that if you want to play cat and mice with the rogue router you can probably start a DOS attack by sending RAs as fast as you can and thus insert and delete the default route of computers in the network over and over again. But as you said, you could insert use scripts to create ACLs in your switches or access points to temporarily block the rogue router (I would just log the rogue RA to syslog and use SEC to block it on another computer that also analyses other logs for SSH bots and so on and responds to these kinds of attacks).
Hi Matthias,
glad you found ramond helpful. Just to put this a bit more into perspective however, I mostly consider it a useful tool against the occasional mishap, especially in weakly managed environments where you don’t have administrative control over all devices.
If we talk actual security threats due to malicious attackers, relying on ramond is in my opinion rather naive. What you want to do in that case is to split up your network in as many subnets as possible; I’ll see if I can do another episode on that over the weekend or so.
Cheers,
Benedikt
I watched BIVBlog #24 and I just wanted to clarify what I was trying to say.
There are two types of rogue RAs that I also pointed out in epsiode #24: an attacker and misconfiguration. Ramond seems to be a great solution to protect a network against misconfiguration. If your network is attacked, however, I don’t think that “network security” software is helpful against the attacker.
By “network security” software I mean things like DHCP guards, IP and MAC address filtering, network scanner/monitoring software and so on (if you are willing to spend money in this area, you can probably find more; I didn’t do any research and the mentioned types are software are what I found to be offered in practice). “Network security” software often also means security through obscurity, because it tries to solve authentication problems, like rejecting the RA from an unauthorized router or granting access to a particular user, by some combination of network filtering and monitoring and not cryptography, which is the proper solution to the problem.
To give a recent example of “network security” software: Recently a datacenter upgraded all their racks to a Rittal KVM solution. The KVM (probably some embedded Linux hardware that never receives security updates) has a web interface that launches a Java applet that redirects mouse, keyboard and screen. The web interface is accessible over HTTPS. Rittal ships the same default X.509/PKIX certificate with every device (if you search for the fingerprint of the certificate, you find other people using it). The administrator asked for the IPv4 address of my workstation (the CIO of the organization has a vague idea what IPv6 is, but no intention of deploying it in the near future – different sad story). I had a fight with the administrator about why he considers some VLAN and IPv4 address filtering mechanism superior to cryptography and why he doesn’t replace the default X.509 certificate on the devices (several thousand other customers also have the private key). It would have taken him almost no effort and would have meant no costs, because the organization runs it’s own certificate authority that is accepted by all computers of the organization. In his mind, the static allocation of IPv4 addresses by the DHCP server (they do this for every machine) and some filtering by routers and switches is more secure than cryptography. I can only speculate why this is the case (perhaps he doesn’t know what cryptography is or doesn’t understand it). So I had to resort to the old method of connecting mouse, keyboard and screen on a mobile desk when I need to configure machines when the operating system is not available, because the organization uses Active Directory for single-sign on (giving a lot of devices, that need to do authentication and don’t support Kerberos or where the administrator doesn’t know what Kerberos is, access to plain-text passwords) and I don’t want the password I use for a lot of things because of Active Directory to transmitted without encryption.
In the end “network security” software may work against a clueless attacker (e.g. an office worker inside the company), but generally is as good as no security. However, I don’t want to say it is useless, especially against DoS attacks which cannot be prevented with cryptography, and that it doesn’t defend against all attacker. If you can separate groups of machines in subnets and VLANs and filter out unwanted DHCP messages or RAs, you should probably do it. It costs next to nothing to implement and raises the bar for attacks. But solely relying on it, like in the mentioned KVM example, is certainly wrong.
Hi Matthias,
sorry for the delay, I just got back from the RIPE meeting in Warsaw last night (and I’ll see if I can do another episode on what happened there).
I fully agree that ramond is of little if any use in an environment where serious attacks are an issue. However, in those environments even DHCPguard/RAguard and MAC address filtering, and to a reasonably sophisticated attacker even 802.1x port based network access control is of limited use because they can be circumvented one way or another; they do raise the bar quite significantly, but if we deal with industrial (or not so industrial) espionage, DoS-related blackmail or whatever, then they are of rather limited use. In that case, segmenting the network into multiple subnets, possibly on separate (sets of) switches is the only option.
As far as encryption goes the situation is slightly more complex. I’ve done a 90 minute talk on that at the last EasterHegg in Stuttgart; the video is available at ; and yes, the issue with updates on embedded devices is mentioned there. That said, real “crypto hardware” is even worse when it comes to updates.
Just one thing I should probably clarify in return: When I talk of “malicious attackers” I generally assume they are reasonably skillful (in the broadest sense of that word). And even script kiddies don’t have to understand the tools they use to attack your network, so it is a matter of prudence to assume that any attack is sort of skillful.
Now as far as your reasoning about relying solely on network segmentation goes, it simply didn’t cross my mind that anybody could seriously think of this. Segmentation protects against attack vectors that are only available within the network, but nothing more. If a machine is accessible from another subnet using some sort of protocol/application, then obviously that protocol/application must be properly set up to handle potential attacks. The example you give pretty much shows all the signs of “security wherever convenient (or ‘cool’)” rather than a systematic security approach. And using the same private key for multiple users (or generally “principals” in Kerberos terminology) is grossly negligent.
Cheers,
Benedikt