[ipv6-wg] Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon)

Hi,

On 15 May 2014, at 16:53, Enno Rey <erey at 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
> =======================================================
>