RE: Counter DoS

Mailman List Mirror (Read Only)
1

Yes, lets allow the kiddies who already get away with as little work as
they can in order to produce the most destruction they can, the ability
to use these 'Security Systems' as a new tool for DoS attacks against
their enemies.

Scenerio:

Lets say my name is: l33th4x0r

I want to attack joeblow.cable.com because joeblow666 was upset that I
called his mother various inappropriate names.

I find IP for joeblow.cable.com to be 192.168.69.69

I find one of these 'security' systems, or multiple security systems,
and i decide to forge a TCP attack from 192.168.69.69 to these 'security
systems'.

These 'security systems' then, thinking joeblow is attacking their
network, will launch a retaliatory attack against the offender,
192.168.69.69 thus destroying his connectivity.

Kiddie 1 Joeblow 0 The Internet as a whole 0

Greg

2

Drew,

    While I believe something should be done, the fact is that two wrongs do not make a right. If I hit you, is it ok for you to hit me right back? This kind of retaliation takes the internet community into a grade school playground fight. What needs to be done, although easier said than done, is the following.

Companies producing software with serious security issues need to address those issues alot faster and more efficiently.
(i.e. Microsoft shouldn't push their OS's out the door until their code is audited and tested thouroughly.) If medicine had the same practices as alot of these software companies, there'd be a whole bunch of dead people out there.

The Federal agencies who deal with computer crimes need to step up and start putting people behind bars, for a loong time. Kiddies get away with DDoS attacks because they know they can. If even half of the kiddies were to get thrown into prison for their acts, it'd definately deter the other half. Maybe that wont stop the problem, but it would definately reduce it overall.

Networks that allow random host spoofing (or bogon headers) need to program their routers and border routers to filter or re-set the headers of TCP traffic outgoing and incoming to the correct source. This way a DDoS kiddie can only spoof at most, the subnet, thus leaving his DDoS net open to investigation and tracing.

Networks that knowingly house and harbor DDoS kiddies should take a pro-active role in turning them in, or kicking them off their networks. Just because they aren't launching attacks from your network doesn't mean they aren't coordinating the attacks from it.

Those networks that house DDoS networks need to maintain closer surveilance of their systems and customers and shut down any systems or networks hosting known DDoS nets.

Denial of Service is probably never going to go away, but while DDoS attacks are so easy to commit, the problem is only going to get worse until appropriate steps are taken to reduce the problem overall.

Greg

Drew Weaver wrote:

3

Here is a solution I would like to propose -- it is not as set-and-forget as network operators like, but we do know that some of our customers have a lot of expertise with this stuff, and taking advantage of that value helps. This is along the categories of collateral damage, scorched earth and generally punitive action for DDOS-compromised hosts. Because not everyone will read every line, I am going to say this twice. IF THE CUSTOMER ABUSES THIS FEATURE - TAKE IT AWAY FROM THEM. This will be backfire if its used for Spam blackholes, it will really only have an affect in the narrower DDOS space.

Along with the idea of blackhole communities. I do NOT recommend it be turned on across-the-board for every customer, and once it has reached penetration, say 20-30% of the internet backbones use this feature -- it should be phased back and only be an ICB item. (called Planned Obl.)

Just like the blackhole community routes, certain /32's (only, nothing shorter) can be exported from the customer to the backbone to be blackholed at the edges. The twist, is that instead of limited the customer announcement to the customer's IPs, you force only /32s to be announced for the blackhole prefixes and limit the total number of prefixes. Say 100 (or 10, or 1000 depends how much trust you have)

So say, joe-customer has identified his top 50 DDOS sources, he announces them to you, voila, DDOS gone. (even for spoofed traffic, depending on how your filters are set up) Obviously these would be no-export routes so no peer need be worried.

The theory - It creates an actual, measured response to customer machines being vulnerable. It makes parts ( ideally large parts ) of the internet unavailable to those with vulnerable computers.

The bad side - People could black hole important sites, until the ALL-CAPS rule is applied.

The somewhat less bad, bad side - Most of these /32s wouldn't be removed until cable provider called the blackholing provider.

The reality is that these filters are probably created today by backbone security folks, so the question is how fast you want the injections/rejections.

IF THE CUSTOMER ABUSES THIS FEATURE - TAKE IT AWAY FROM THEM.

Comments?

Deepak

4

1. Why is BGP the right tool for this?

2. Is your idea to block only packets destined for the customer making
the request, or to 0/0?

5

the thing is though, by allowing any /32's... what prevents
  /all/ customers from abusing it by curiosity of what would
  happen? :slight_smile:

  the fact that you are allowing any /32's (up to 100 or whatever
  max prefix lim. you set) is like giving a can of worms to your
  customers. i don't think its even worth the effort to bother when
  you have more than couple customers abusing it

  security for one, SLA for the other, thirdly i just don't trust
  customers injecting routes into my backbone w/o telling us.

  i don't think bgp or a routing protocol is the right way to solve
  infected-machines participating in ddos nets.

-J