Hello to the list and RA guard evasion technique

[Mark Smith]

On Sun, 29 May 2011 17:52:08 -0400
Martin Millnert <martin at millnert.se> wrote:

> On Sun, 2011-05-29 at 19:04 +0200, S.P.Zeidler wrote:
> > Thus wrote Ben Jencks (ben at bjencks.net):
> > 
> > > [..] -- if the attacker is going to this length to bypass RA guard, then there's no room for plausible deniability, and you can terminate the subscriber on the spot. Only really applicable to ISP-type networks, though.
> 
> Well, is it in an ISPs or company's interest to lose a subscriber or
> employee based on the above? The person's computer may have been
> compromised, etc.
> 

Yes, in the interests of the greater good. It is quite reasonable to
quarantine the subscriber or employee if the damage they can cause is
greater than the value they add (revenue in the case of the subscriber,
work the employee continues to perform while compromised).

> > s/subscriber/employee/ too.
> > 
> > The more difficult case is probably if you are an internet cafe or hotspot
> > with wireless services.
> 
> Most universities and companies i know have enabled ethernet ports
> sitting around just about everywhere. From my experience, in reality,
> few manage their ports completely.
> 

I think the technology to manage them i.e. 802.1x has become more
widely available in the last 5 or so years, generally because of
upgrade cycles. Enabling it may not be much of an effort. So perhaps
that means that people aren't really concerned about these threats.
After all, fairly similar ones have existed in IPv4, such as those
implemented in ettercap.

> For enterprise networks, another approach is to not rely on L2 or L3
> security, but end-to-end via TLS/SSH etc between servers and user
> systems. An approach which seems increasingly reasonable to me.
> 

I agree, although if the network layer is down the upper layers don't
work ;-)

Technologies exist to address these issues, such as IPv6 SEND, 802.1x
and network virtualisation, we just need them to be more widely
available.

Regards,
Mark.