RE: UUNet Offer New Protection Against DDoS

Mailman List Mirror (Read Only)
21

Date: Sun, 7 Mar 2004 02:13:38 -0500 (EST)
From: Sean Donelan

Has the number of DDOS attacks increased or decreased in the
last few years has uRPF has become more widely deployed?

Number of life guards on duty increases in the summer. So does
drowning. Therefore, having life guards on duty is not an
effective measure to prevent drowning.

Ice cream consumption increases in the summer. So does drowning.
Therefore, it is ice cream consumption that causes drowning.

(Time for arguments over who has the best and worst analogies!)

Do you have any evidence the number of attacks are decreasing?

Is "number of attacks" the sole metric? Are all attacks created
equal?

Eddy

22

> > Try saying that after running a major DDoS target, with "HIT ME" your
> > forehead.
> > No offense Sean but I'd like you to back your claim up with some
> > impirical data first.
>
> Has the number of DDOS attacks increased or decreased in the last few
> years has uRPF has become more widely deployed?
> Do you have any evidence the number of attacks are decreasing?

Without any data to back this up, I'm estimating based on the attacks
I've dealt with.
I don't believe the number have gone down at all. If it has, it's done
that for someone else, not me,

Is this attacks on 'known magnets' or 'random stuff'. From what I've seen
the frequency of attacks on 'all customers' seems to be slowing SOME.
There are the normal nuisance points which attract attacks for whichever
reason. So, Avleen, can you seperate the 'known magnets' from 'random
stuff' and say which direction the trend is moving?

As to the 'strength' of attacks. It seems that bandwidth and pps rates
have incresed over time. This COULD BE because you can own up 10,000 xp
machines in a heartbeat, or it could be a reflection of
bigger/better/faster single hosts being taken over. It's hard to tell from
my end of the party :frowning:

I don't have any evidence. Nor do I *believe* the number of attacks is
decreasing. If anything, its staying the same or going up, as more
people decide it's fun to take networks offline through the greater and
greater number of compromised hosts.

The greater number of compromisable hosts seems to be the constant in this
arguement. So, like we've said for several years, until the end station is
secured 'better' the consistency and strength of attacks will continue
that upward trend.

23

just a question

why is DDoS the only issue mentioned wrt source address validation?

its easier to discuss than other things... for instance the number of
broken vpn/nat systems out there that uRPF will break. Also, the folks
with private addressed cores that will start appearing 'broken' when
traceroute/unreachables stop working across their networks...

i'm sure there's other reasons to make sure your customers can't send
spoofed packets. they might not always be as news-worthy, but i feel it's
a provider's duty to do this. it shouldn't be optional (talking
specifically about urpf on customer interfaces, loose where needed)

I'm not sure that anyone would argue that uRPF is bad, the arguement is in
it's placement. I do think that part still needs to be worked out, that
and making sure that your equipment can handle the task. There are
certainly some people hampered by early adoption of some technologies
which they can't get out from under in any reasonable fashion.

--Chris
(formerly chris@uu.net)

24

fingers wrote:

> just a question
>
> why is DDoS the only issue mentioned wrt source address validation?
>
> i'm sure there's other reasons to make sure your customers can't send
> spoofed packets. they might not always be as news-worthy, but i feel it's
> a provider's duty to do this. it shouldn't be optional (talking
> specifically about urpf on customer interfaces, loose where needed)

Because _Distributed_ is the hot buzzword of the day.

and people offten seperate 'ddos' from 'dos', even though the end is the
same as far as your customer is concerned... it's kinda funny really :slight_smile:

At least one of us thinks clean traffic is a Good Thing all the time.

Packets that can't possibley be used for anything ought to be dumped at
the earliest possible opportunity as soon as it is apparent (or could
be if anybody looked) that they are "from" addresses that can't be
reached or have any other obviously fatal defect.

Here is a sticky point... There are reasons to allow 10.x.x.x sources to
transit a network. Mostly the reasons come back to 'broken' configurations
or 'broken' hardware. The reasons still equate to customer calls and
'broken' networking fromm their perspective. I think the thing you are
actually driving at is the 'intent' of the packet, which is quite tough
for the router to determine.

--Chris
(formerly chris@uu.net)

25

[two responses here]

-------- 1 of 2

fingers@fingers.co.za (fingers) writes:

why is DDoS the only issue mentioned wrt source address validation?

i'm sure there's other reasons to make sure your customers can't send
spoofed packets. ...

yes. for example, most forms of dns cache pollution rely on the ability
to forge a udp source address on a well-timed response. several of you
have pointed out that as long as at least one edge network is free from
uPRF, then something like dnssec will still be vitally necessary -- and
that's true. but, if the places where forged-source were possible could
be enumerated, then the fact of the forgery would be useful to a victim.
right now those places are innumerable, and so, anonymity is complete.

-------- 2 of 2

hackerwacker@cybermesa.com (James Edwards) writes:

uRPF, strict mode, is how I control 1000+ DSL pvc's from leaking private
address space via broken NAT. ...

so what you're saying is, these packets (captured on one of the f-root
servers just now) wasn't from your network? THANKS! (anybody else here
want to claim this slackage?)

tcpdump: listening on fxp0
21:06:42.331994 192.168.15.3.1053 > 192.5.5.241.53: 15396 A? wustat.windows.com. (36)
21:06:42.349184 10.1.0.15.1025 > 192.5.5.241.53: 6182 NS? . (17)
21:06:42.427980 10.10.1.1.1041 > 192.5.5.241.53: 53830 NS? . (17)
21:06:42.559860 10.19.1.101.1032 > 192.5.5.241.53: 8434 [1au] A? SPPOLCD01.POL. (42)
21:06:42.688972 192.168.7.76.1036 > 192.5.5.241.53: 14986 A? rsthost2.ods.org. (34)
21:06:43.793914 192.168.160.252.1024 > 192.5.5.241.53: 28233 MX? jimaz.cz. (26) (DF)
21:06:44.048702 10.10.10.250.53 > 192.5.5.241.53: 2051 A? tock.usno.navy.mil. (36)
21:06:44.123787 10.101.58.16.1120 > 192.5.5.241.53: 9741 PTR? 169.16.187.208.in-addr.arpa. (45)
21:06:44.394578 10.8.0.22.1036 > 192.5.5.241.53: 15001 A? mail.inf101.net. (33)
21:06:44.578893 10.8.0.22.1036 > 192.5.5.241.53: 15002 MX? ezrs.com. (26)
2027 packets received by filter

note that this particular box has dropped a fair amount of this crud since
its last reboot:

rule# packets octets ----------------rule-----------------

00400 27149821 1707500202 deny ip from 10.0.0.0/8 to any in
00500 1710989 109992242 deny ip from 172.16.0.0/12 to any in
00600 6144955 392168290 deny ip from 192.168.0.0/16 to any in

9:16PM up 37 days, 15:55, 1 user, load averages: 0.04, 0.01, 0.00

also note that it's only one of about fifty similar servers. i don't have
an easy way to aggregate the slackage numbers yet, but i sure would like
them to be zero or at least lower. (and, for my part in rfc 1918, i now beg
forgiveness.)

Based on my limited experience with all of this it seems the place for
uRPF is not at the core (core in the context of the Internet backbone)
but at the customer edge, where the problem starts.

that's sort of what http://www.icann.org/committees/security/sac004.txt says.

26

> Without any data to back this up, I'm estimating based on the attacks
> I've dealt with.
> I don't believe the number have gone down at all. If it has, it's done
> that for someone else, not me,

Is this attacks on 'known magnets' or 'random stuff'. From what I've seen
the frequency of attacks on 'all customers' seems to be slowing SOME.
There are the normal nuisance points which attract attacks for whichever
reason. So, Avleen, can you seperate the 'known magnets' from 'random
stuff' and say which direction the trend is moving?

If we class "popular websites", "servers / networks at major ISPs", "IRC
servers" and "the latest popular thing" as magnets, and "small business
sites", "personal pages" etc as the random stuff, then I don't believe
attacks on magnets have gone down at all.
On the random stuff I cannot comment, as I've had surprisingly little
dealing with that.

As to the 'strength' of attacks. It seems that bandwidth and pps rates
have incresed over time. This COULD BE because you can own up 10,000 xp
machines in a heartbeat, or it could be a reflection of
bigger/better/faster single hosts being taken over. It's hard to tell from
my end of the party :frowning:

I don't think it would be unfair to assume it is both. Again that stands
to simple logic. More hosts on the internet = more potential drones.
More availible global bandwidth = larger volume output from each drone.

> I don't have any evidence. Nor do I *believe* the number of attacks is
> decreasing. If anything, its staying the same or going up, as more
> people decide it's fun to take networks offline through the greater and
> greater number of compromised hosts.

The greater number of compromisable hosts seems to be the constant in this
arguement. So, like we've said for several years, until the end station is
secured 'better' the consistency and strength of attacks will continue
that upward trend.

Indeed. I believe the ISP of the end user is the party responsible here.
If the ISP is allowing access through their network, they need to be
responsible for the data leaving their networl which originates in their
network.

27

Putting rubber to the road eventually, we actually went ahead and
packetfiltered rfc1918 space on our edge. I know paul and stephen
will be crowing with joy here, as we had several arguments about
it in previous lives, but having gone ahead and filtered it,
nothing appears to have broken, or at least nothing got called
in. We've been doing it for several months now.

/vijay

28

vgill@vijaygill.com (vijay gill) writes:

Putting rubber to the road eventually, we actually went ahead and
packetfiltered rfc1918 space on our edge. I know paul and stephen
will be crowing with joy here, as we had several arguments about
it in previous lives, ...

fwiw, in retrospect you were right at the time, but in my defense it
was only because of things neither of us could have known. given only
what we actually knew and could prove, you were deadass wrong :-).