Hi, On 15 May 2014, at 16:53, Enno Rey <erey@ernw.de> wrote:

Benedikt,

thanks for that info; seems like an interesting tool. Still, some comments here:

On Thu, May 15, 2014 at 02:28:32PM +0000, Benedikt Stockebrand wrote:

...

Hi folks,

after his presentation learned from Niall that he didn't actually know about the ramond, so here's some quick info for all who have a similar situation like him:

Ramond is a little tool that listens for RAs and then matches the source MAC address or whatever with a list of authorized routers.

given current attacks tools (both fake_router from THC-IPV6 and ra6 from the SI6 Networks' toolkit) can easily send packets with spoofed source MAC address, such a tool+list doesn't really help against a "skilled & motivated attacker". It would help against accidentally brought-in/fired-up systems emitting rogue RAs (which, admittedly, in quite some networks constitute a bigger risk than said attacker) but that threat/risk can easily be addressed with stuff like "router-preference high" (or its equivalents) on the infrastructure side. and this type of stuff/mitigation is available to _most_ networks in the interim.

more importantly I'd like to ask you another question: how many environments do you know which have a "mature network incident response process" which would have to be followed once ramond "alerts $ADMIN of $VIOLATION"? unfortunately there's usually a strong correlation between "lack of appropriate tools" and "lack of process maturity" so those environments where ramond could make sense will not be able to make reasonable use of it anyway.

In general, the "detection/reaction type of tools" (as opposed to a "prevention-oriented" security approach) haven't proven their usefullness too much in the past.

The reason we knocked up RAmond was to handle accidental rogue RAs, usually caused by Windows ICS at the time. I think we saw that over the course of a year there was a rogue RA somewhere on our WLAN around 50% of the time. So I would say it was very useful, for that type of incident. This was around the time RFC6104 was in its first draft state. Tim

best

Enno

It can clean

...

up after rogue router RAs by sending a follow-up RA with router lifetime of 0 and deprecating all the advertised prefixes, and it can also run some external programs/scripts to do additional clean up (like an automated retaliation strike). It's open source and should run on all standard Unixes (so far I've only tested it on Linux myself), and of course it can be combined with 802.1Q.

I've also covered it in the second half of my video blog episode at http://www.stepladder-it.com/bivblog/23 with the most relevant parts starting at about 15:00 into the video.

If you handle networks with a potential for rogue advertising routers and don't know about the tool, I recommend you take a look at it.

Cheers,

Benedikt

-- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/

Business Grade IPv6 --- Consulting, Training, Projects

BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/

-- Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902

Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey

======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================

Hi Enno and list, I'll skip my comments on the contexts where ramond is useful or not, as Tim has already pointed that out, but there are a couple more aspects in your posting I consider very important (and unsuitable for a quick reply from a conference auditorium): Enno Rey <erey@ernw.de> writes:

It would help against accidentally brought-in/fired-up systems emitting rogue RAs (which, admittedly, in quite some networks constitute a bigger risk than said attacker)

That's the point: It is a tool for dealing with BYOD style ("guest" or whatever) networks where you have rather limited control over the devices being connected and your main concern are broken configurations on guest devices rather than malicious attackers.

but that threat/risk can easily be addressed with stuff like "router-preference high" (or its equivalents) on the infrastructure side. and this type of stuff/mitigation is available to _most_ networks in the interim.

That approach has the drawback that it doesn't let you prioritize your default routers. That's not an issue if you run a first hop redundancy protocol like VRRP/HSRP/CARP/..., but not everybody does that. Additionally, it doesn't provide two features I consider rather useful: If you hook up the ramond logging output to your monitoring, then you can keep an eye on the relevance of this issue in your particular networks. And if you actually use a proper response script so that offending devices are disabled, by shutting down the switch port in question or by locking the matching entry in your WiFi's Radius DB, you can actually make people contact your first level support/conference NOC/whatever so their misconfiguration can be fixed by people who know---which is of course For the Good of the Internet in General[TM].

more importantly I'd like to ask you another question: how many environments do you know which have a "mature network incident response process" which would have to be followed once ramond "alerts $ADMIN of $VIOLATION"? unfortunately there's usually a strong correlation between "lack of appropriate tools" and "lack of process maturity" so those environments where ramond could make sense will not be able to make reasonable use of it anyway.

There's a third aspect in here that you make assumptions about: What degree of authority does $ADMIN have to deal with $USER, or more specifically, with $DEVICE? If you run an 802.1x managed network with devices that you control through some sort of orchestration tool (puppet, cfengine, or whatever), that's a completely different situation than a $COFFEESHOP WiFi where people show up, turn on their own misconfigured devices, expect to get half an hour's worth of work done before they leave again, and your job is to keep them happy without. In a coffeeshop style environment you can define all the processes you like, but if the business case is not to step on any customer's toes (unless they intentionally did something seriously malicious and you can produce legal grade evidence and whatnot), your options are extremely limited.

In general, the "detection/reaction type of tools" (as opposed to a "prevention-oriented" security approach) haven't proven their usefullness too much in the past.

If you have RA guard or similar available, by all means use it. But some people don't have that option. And beyond that, I think you still remember that I strongly promote to segment networks wherever feasible (and actually that's one of the reasons why I do that multicast routing presentation at the IPv6-Kongress in Frankfurt next week). But sometimes that's not an option either, and that's where the ramond becomes rather useful. Which brings us back to the beginning of the thread: I don't know Niall's setup itself, but from similar ones I've seen elsewhere, he might well run an environment where ramond is extremely useful. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/

Niall, On Fri, May 16, 2014 at 03:18:14PM +0200, Niall O'Reilly wrote:

The problem it addresses seems to be parallel to the one which has my main attention at the moment. I need to track NAs (including legitimate ones) rather than RAs.

So far, I'm aware of the following two potential solutions whose trails seem worth following to find out more:

https://nav.uninett.no/wiki/navfaq https://6mon.iit.cnr.it/

I'll be glad to learn of others.

tools that work similarly to ramond (monitoring the local link as opposed to infrastructure-based), but do so for NAs, include: ipv6mon (http://www.si6networks.com/tools/ipv6mon/), NDPmon (http://ndpmon.sourceforge.net/). not sure about your use case, but you might furthermore find this post helpful: http://blog.webernetz.net/2014/03/17/monitoring-mac-ipv6-address-bindings/ Crossposting to IPv6hackers mailing list as guys over there might have other/better suggestions. apologies in advance for this! have a great weekend everybody Enno

ATB, Niall

-- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================

Hi, On 17 May 2014, at 11:11, Benedikt Stockebrand <bs@stepladder-it.com> wrote:

Hi Niall, Enno and list,

I've just taken a bit of a look at these, and this is what I think:

Enno Rey <erey@ernw.de> writes:

...

On Fri, May 16, 2014 at 03:18:14PM +0200, Niall O'Reilly wrote:

...

The problem it addresses seems to be parallel to the one which has my main attention at the moment. I need to track NAs (including legitimate ones) rather than RAs.

So far, I'm aware of the following two potential solutions whose trails seem worth following to find out more:

https://nav.uninett.no/wiki/navfaq

That seems to be quite the beast. It sounds interesting, but it may be way overkill if you only want to use it to monitor ND.

The point is that NAV does many very useful functions for an enterprise. It’s produced by the Norwegian NREN people, and actively supported, with version 4.0 just out. We’ve found it very good, at least with Cisco devices. The address tracking is one very useful feature of it. If you just want to track addresses, then it’s probably overkill.

...

...

https://6mon.iit.cnr.it/

On that page it says:

] 6MoN version 2.2 Released ] ] Improvements in RA analysis: ] ] Multiple IPv6 prefixes are now recognized ] ] Optional fields are handled properly

Doesn't really make me feel that confident...

...

ipv6mon (http://www.si6networks.com/tools/ipv6mon/), NDPmon (http://ndpmon.sourceforge.net/). [...] http://blog.webernetz.net/2014/03/17/monitoring-mac-ipv6-address-bindings/

...

From what I've read, these seem to do the job Niall needs. However, the way they work it isn't perfectly reliable: They all work by attaching a listening device to the subnet, which is generally fine, but may be insufficient.

An orthogonal approach might actually be to use information from the various routers in the network. These may not show who is doing things within the subnet only, but as soon as they send anything through a router, they can be tracked there.

...

Crossposting to IPv6hackers mailing list as guys over there might have other/better suggestions. apologies in advance for this!

No reason to apologize, it makes perfect sense.

There have been some other interesting ND tracking tools posted here. I’m sure someone will remind us of them soon :) Tim

Cheers,

Benedikt

-- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/

Business Grade IPv6 --- Consulting, Training, Projects

BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/

Hi list members, i worked with nav the last three months in an environment with many vlans. With the virtual appliance you only have to prepare your files for the seed database. The whole process can be done in one day - in my experience. The results including prefixes, network map, ... are worth the effort. As stated - it's not a small tool - but the web interface let you get to results quickly. Greetings to All Max Am Montag, den 19.05.2014, 10:55 +0000 schrieb Benedikt Stockebrand:

Hi Tim and list,

Tim Chown <tjc@ecs.soton.ac.uk> writes:

...

...

That seems to be quite the beast. It sounds interesting, but it may be way overkill if you only want to use it to monitor ND.

The point is that NAV does many very useful functions for an enterprise. [...]

that's what I meant. It has a whole pile of interesting features, but if all you want is ND monitoring *only*, then it may be overkill.

Cheers,

Benedikt