Building

IPv6 Security Part 2, RA Guard – Let’s get practical

Hi everybody,

this post is the sequel of this one on the IPv6 security feature called “RA guard”. As announced in that post I recently got a 4948 on ebay. After installing the appropriate image and noticing that RA guard was still unavailable I found out it should have been a 4948E which is capable of “doing IPv6 in hardware” (as opposed to the “simple 4948” only supporting IPv6 in a “software switched” way. and pls note there’s also the informal term 4948-E denoting a 4948 running an “enhanced image”).

Well… we’ll certainly find some useful function for that device – and I just initiated the acquisition of a 4948E – but I was just eager to get my hands on the practical use and implications of RA guard. Looking at the Cisco Feature Navigator for “IPv6 Basic RA Guard” it seems that it’s still the same platforms supporting it as eight weeks ago, so there was only one option left: get one of our Cat 65Ks from the basement and perform the testing with it.

Given ERNW’s strong emphasis on sports pretty much immediately some kind-of “strong man contest” evolved going like “who can lift and carry the device without further assistance”

so we had quite some fun just putting the box into operation.

[for those interested we can provide the number and nature of modules installed at the time of that contest ;-)]

Ok, back to the technical side of things. Here’s what we did:

Step 1) Perform RA based attacks with “RA Guard” being absent.

For that purpose we used Van Hauser’s THC-IPV6 attack suite (which can be found here) and performed two specific attacks.

1a) Use

fake_router6 eth0 2001:db8:dead:beef::/64

to send spoofed RAs which resulted in an additional prefix and associated default gateway being learned on the victim system (default install of current MS Windows).

It should be noted that the additional (“spoofed”) default gateway had a better (= lower) metric in the routing table.

1b) Use

flood_router6 eth0

to send arbitrary spoofed router advertisements (with the eventual purpose of a DoS condition). This worked equally well. Right after starting the attack the CPU load of the attacked system ‒ and for that matter, the load of other systems on the local link as well ‒ went to 100% (and stayed there for hours after stopping the emanation of packets on the attacker’s host).

[you might notice that this is not the “oldest and weakest laptop we took from our lab shelf”…]

In short: both RA based attacks we tried worked like a charm.

So this is absolutely something every security responsible of a IPv6 enabled network should be concerned about…

Step2: put lab device into action, enable RA guard and check if it helps.

At the time of our testing the box was running

Cisco IOS Software, s3223_rp Software (s3223_rp-IPBASEK9-M), Version 12.2(33)SXI5, RELEASE SOFTWARE (fc2)

[which, btw, “silently ignores”  any WS-X6248-RJ-45 modules present in the box. Of course, I’m aware that all of you valued readers always carefully read the release notes of this (or other) images before deploying them…]

We then enabled RA guard on the access-ports to-be by

Router(config)#int range f1/24 – 36

Router(config-if-range)#switchport

Router(config-if-range)#switchport mode access

Router(config-if-range)#ipv6 nd raguard

and performed the attacks again.

Without success! Seemingly the box efficiently (and silently) discarded all RA packets arriving on those ports.

So we can certainly state that RA guard fully performs as expected. One minor annoyance we noticed: there seems no log message of any kind while the attack is in progress.

However, earlier – when performing step 1a – we had noticed sth like this on the router legitimately serving the local network with RAs:

Thus there might still be a way to detect RA based attacks. It’s just not on the box providing protection from them but on another one.

If you want to see these attacks (and the – quite simple – configuration of RA guard) in practice you can do so either at our workshop on “IPv6 security in LANs” at Troopers or at the Heise IPv6 Kongress in May. At both occasions we’ll demonstrate this stuff.

We think that RA guard is pretty much the only way to protect against RA based attacks in an operationally feasible way (as opposed to, say, filtering ICMP type 134 by means of port based or VLAN ACLs).

To mitigate the risk of “RA interference” caused by potentially misconfigured systems (e.g. Windows systems running 6-to-4 with a public IPv4 address and Internet Connection Sharing enabled; more on this in a future post on IPv6 tunnel technologies) or by systems “accidentally inserted into the local network” (employee connecting SOHO DSL router. which, again, certainly never happens in your network…),  there might be another configuration tweak that could help. The standards track RFC 4191 on Default Router Preferences and More-Specific Routes introduced the concept of a preference assigned to router advertisements distributed by routers on the local link.

For that purpose the format of RA messages is extended and two of the previously unused bits within the byte containing the flags are used for a “Prf” (Default Router Preference) value.

The configuration is quite simple (on Cisco routers where the feature was introduced in IOS Version 12.4(2)T) and goes like this:

Router(config)# interface f0/1

Router(config-if)# ipv6 nd router-preference {high | medium | low}

Hosts receiving RAs tagged with a high preference flag will prefer them over RA messages emitted with the default value (“medium”). We’ll play around with this in a more detailed fashion at some occasion and keep you posted. In the interim you might look  here to get some background on the way router preference works.

The next post of our series is planned to cover the (in the current Windows world) ever-present tunnel technologies and their security implications.

Have a great weekend everybody,

Enno

Comments

  1. Dear Enno,
    I found your articles very interesting regarding IPv6 security.

    I am currently developping an IPv6 project study for University purposes in order to deploy a secure Wireless IPv6 Network.

    After reading the RFC-6105 (IPv6 Router Advertisement Guard), it seems being possible to configure Stateles Router Guard.

    I would like to know how to configure Stateless Router Guard in order to examines incoming RAs and decides whether to forward or block them based solely on information found in the message or in the L2-device configuration ??
    Which commands shoud we use in the L2 device ?

    Sincerely thanks in advance,
    Bruno

    1. Bruno,

      thanks for your mail. Unfortunately the RA guard feature (even though described in the – “informational” – RFC 6105) is currently only available on very few platforms. As for Cisco devices the configuration can be found in our presentation from the IPv6 Kongress. We have not yet extensively researched other vendors. What kind of hardware (vendor/model[s]) are you actually willing to configure RA guard on?
      Feel free to contact us directly (erey@ernw.de, cwerny@ernw.de) to discuss this further/in more detail.

      all the best for your research project, thanks

      Enno

  2. Hi Enno

    We are currently implementing FHS on our Cisco 2960X Access Layer switches. While configuring RA Guard I found out that this feature also blocks Router Solicitations and not only Advertisements.

    That is, an host attached to a port configured in RA Guard host mode needs to wait for the Router Advertisement in order to get its address information.

    I have test this on Cisco 2960X switches running IOS 15.2(3r)E1. It is also discussed in the Cisco forums:

    https://supportforums.cisco.com/t5/lan-switching-and-routing/ipv6-fhs-how-to-filter-only-ra-but-keep-rs/m-p/3297080/highlight/false#M399586

    Have you discovered this as well? This way, RA Guard is pretty much useless.

    Thanks
    Michael

Leave a Reply

Your email address will not be published. Required fields are marked *