Odd DDoS, anyone else seen this?

Mailman List Mirror (Read Only)
1

Hi,
we had a large DDoS over the weekend, I wondered if anyone else has seen this
and knows what software is behind it.

We saw many hundred thousand packets per second entering our network from
various international peers, each packet was tcp destined to a single real end
user IP address and sourced from a /16 network address eg 61.254.0.0, where the
src was random and different on each packet but always x.x.0.0

I was unable to find out more about the data within the packet, the sheer volume
made diagnosis impossible without killing the routers.

Steve

2

We saw many hundred thousand packets per second entering our network
from various international peers, each packet was tcp destined to a
single real end user IP address and sourced from a /16 network address
eg 61.254.0.0, where the src was random and different on each packet but
always x.x.0.0

Yes. We've asked all our upstreams to block it completely (with varying
degrees of success from it being permenantly blocked at their borders to
"we can't apply filters on your interface").

For Junos (I was informed that this is only available in 5.5), you can
filter using:

0.0.0.0/0.0.255.255

On a cisco you can block using:

deny ip 0.0.0.0 255.255.0.0 any

I was unable to find out more about the data within the packet, the
sheer volume made diagnosis impossible without killing the routers.

Looked just like a regular SYN flood to the target IP. Not sure why they
picked source addresses that were so obviously bogus though.

Can anyone think of a reason why this sort of traffic should be routed at
all? Does anyone actually drop hosts on to addresses ending in x.x.x.0?

Rich

3

Glad to know its not just me..

FYI x.x.0.0 is a valid host address as is x.x.x.0 and it would be technically
incorrect to block it assuming it to be a network address and therefore bogon.

However this may be a way to do it if we see another attack, altho I would
strongly recommend against filtering x.x.x.0 I would doubt that there are any
valid x.x.0.0 host on the internet so could filter on that..

Steve

4

Glad to know its not just me..

DDoS is a problem for everyone, but only a few people seem to be trying to
do anything about it.

FYI x.x.0.0 is a valid host address as is x.x.x.0 and it would be
technically incorrect to block it assuming it to be a network address
and therefore bogon.

Agreed, but did a we quick risk analysis and we thought blocking the DDoS
was the lesser of the two evils. Again, if anyone is actually using
x.x.0.0 addresses for hosts it would be useful to know.

However this may be a way to do it if we see another attack, altho I
would strongly recommend against filtering x.x.x.0 I would doubt that
there are any valid x.x.0.0 host on the internet so could filter on
that..

That's what I expected, but wanted to see what effect it would have on
legitimate traffic first. Again, it would be useful to know if anyone is
dropping hosts on to x.x.x.0 as well.

I know that these are both legitimate IP addresses, but if they are only
being used for DDoS then surely we should look at locking them down (in
the same way as broadcast packets have been)?

Rich

5

I've seen cable modem users have .0 ips.

6

We should look at locking them down the same way we've looked at locking
down broadcast packets? Or am I incorrect, and in fact Smurf attacks have
become so rare that they are once again only of theoretical interest?

7

DSL ports too. I was spammed today from a Verizon DSL IP of 4.46.3.0.

8

if you have a subnet larger than /24 not using .0 and .255 gets somehwat
wasteful...

we have observed some versions of windows having trouble connecting to
hosts ending in .255.

<SNIP>

>
> I've seen cable modem users have .0 ips.

DSL ports too. I was spammed today from a Verizon DSL IP of 4.46.3.0.

if you have a subnet larger than /24 not using .0 and .255 gets somehwat
wasteful...

we have observed some versions of windows having trouble connecting to
hosts ending in .255.

9

Generally not for end-stations since end-users tend to have broken
software with lousy assumptions, but I've seen and used all of the
last octect for infrastructure elements, especially loopbacks and
point-to-point /31s. Only problems have been in people's heads.

Cheers,

Joe