Re: anycast and ddos

["Christopher L. Morrow" <christopher.morrow () mci com>]

On Fri, 6 May 2005, Randy Bush wrote:

> it seems that anycasting was quite insufficient to protect
> netsol's service from being severely damaged (udp dead, tcp
> worked) for a considerable length of time by a ddos [0] last
> week [1].  it would be very helpful to other folk concerned
> with service deployment to understand how the service in
> question was/is anycast, and what might be done differently
> to mitigate exposure of similar services.

was the service in question anycast'ed? I got the impression that the
worldnic servers were all NON-anycast... I only see the /21 covering these
servers through 10515 (which is verisign as I recall?)

Judging by latency I even think they are in the northern virginia area...
I also noted:

worldnic.com.           86400   IN      NS      ns1.netsol.com.
worldnic.com.           86400   IN      NS      ns2.netsol.com.
worldnic.com.           86400   IN      NS      ns3.netsol.com.

;; ADDITIONAL SECTION:
ns1.netsol.com.         86400   IN      A       216.168.229.228
ns2.netsol.com.         86400   IN      A       216.168.229.229
ns3.netsol.com.         86400   IN      A       216.168.229.229

why have 3 records and 2 ips? odd. You'd think they would have more ips in
that /21 or other /24's to allocate from, just in case they had to
jettison 1 address which was getting pounded :( (not that these were
getting attacked per-say, but still)

> [0] - as it seems that the ddos sources were ip address
>       spoofed (which is why the service still worked for
>       tcp), i owe paul an apology for downplaying the
>       immediacy of the need for source address filtering.

It's also not clear that the sources were spoofed, if as Patrick says they
put in a riverhead(s) (which isn't too far fetched) the normal mode for
'protection' of DNS is to:
1) truncate
2) rate-limit - and cache (I think it caches atleast, I know it will go
into proxy mode and rate-limit)

truncate forces TCP which allows RHG to verify the source address is
really asking to chat, rate-limit function keeps 'bad actors' from
beatting the hell out of the protected resource.

So, without more info from NetSol (seems not to be forthcoming?) about the
mix of attack traffic (which the RHG will provide) it's hard to state
definitively that the attack was 'mostly spoofed' :(