On 12/16/2012 04:49 PM, Robert Williams wrote:
Hi,
I'm sensing a lot of frustration / anger / hatred for NLB, having
never really used it myself I'll just back away from that quietly :)
Hehe...
Unfortunately the test is valid because the situation actually arose
when a Windows NLB cluster went offline and there was a load of DDoS
traffic heading to it. The whole reason I'm even working on this is
because it 'did' happen, unfortunately...
Sure. However, a couple of things to note:
1. You haven't specified if you're using static ARP *and* static mac
address table entries for the MS NLB MACs, as per the URL Tony linked
to. This is essential, and note the 6500-specific items at that URL.
I'm assuming you have the static ARP entries because IOS won't respond
to a dynamic ARP with a multicast mac, but maybe you don't have the
static MAC entries, which was causing the CPU punt?
2. In response to your more general question about how to block this
kind of thing, it's worth noting that there are more types of ACL on the
box than CoPP! Specifically CoPP has limitations on the sup720 that mean
it can only do unicast IPv4 in hardware.
You may find an actual ACL on an physical interface fares better; since
you said you didn't want multicast at all, possibly a MAC ACL blocking
the IPv4 and IPv6 multicast MACs?
However, aside from <cough> NLB, what stops a compromised device from
being used to emit such traffic maliciously?
Nothing. Sadly, every router in the world can be destroyed with a little
ingenuity by a directly-attached client. This annoys me - it doesn't
seem so terribly hard to stop this. But hardware-based platforms are
often not fully general, and aren't flexible enough to do what is needed
(essentially microflow policing of all CPU-punts with a "key" of input
interface, source mac/ip/port).
However, an alternative way of answering that question is: you stop it,
by way of your operations, administration and management, and your
policies stop it, by way of letting you disconnect the host.
Unsatisfactory I know - where is the "Cisco self-defending network" when
you need it ;o)
In the colocation world we have seen examples where the attacker just
rents a couple of VPS instances with the same provider as their
target and uses it to take down the target from the 'inside' by
messing with the providers' infrastructure.
That is genuinely interesting and scary. Particularly given the woeful
security features on most equipment, that is very hard to defend against
in general. I don't suppose there's any public write-up of such an
instance, that you know of?
It goes without saying that untrusted customers should be on separate
layer2 networks, but that only solves some problems.
The (two lines in linux) example I was testing with would be a nice
way to do this, at least until the provider tracks it down and pulls
it. Which in itself could be tricky if the CPU is maxed out and/or
your traffic graphing shows only 'unicast' traffic PPS, thus is blind
to multicast.
These are all excellent points, and I share your frustration - network
devices that crap out inexplicably due to external load, and don't even
log info that hints at the cause, drive me crazy.
But they're in the majority, sadly :o(
Cheers,
Phil
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
