RE: DDoS attacks

Mailman List Mirror (Read Only)
1

I happen to agree, if only because; when script kiddies don't have IRC to
play with they'll start looking elsewhere. I'd rather them have an IRC net
to play with while they're being hunted. Wouldn't you?

From: Scott Francis [mailto:darkuncle@darkuncle.net]
Sent: Wednesday, July 11, 2001 7:24 PM
To: Richard A. Steenbergen
Cc: Ariel Biener; nanog@merit.edu
Subject: Re: DDoS attacks

On Wed, Jul 11, 2001 at 07:40:45PM -0400, Richard A.
Steenbergen exclaimed:
> Hrm you may have an idea there. Since so many attacks are related to
> EFNet, and there are so many possible reasons for it to be
impacting the
> rest of the internet, I propose we introduce a new ICMP
type, ICMP EFNet.
> This message type could be used to convey all kinds of important
> information about why things are broken, for example:
>
> ICMP EFNet code 1 - Smurfing
> ICMP EFNet code 2 - SYN Flooding
> ICMP EFNet code 3 - Channel takeover
> ICMP EFNet code 4 - Warring botnets
> ICMP EFNet code 5 - Dianora
>
> and many other useful messages.

regardless of one's opinion on the usefulness/validity/point
of IRC, I think
some respect is due EFnet simply considering the antiquity of
the network, and
the sheer volume of communication, good bad and indifferent,
that has flowed
over it since its inception. I'm sure I'll be flamed for my
(mis)use of
'antiquity', but I think IRC has been, and continues to be, a valuable
communication tool. Like any useful tool, it tends to be used for both
beneficial and nefarious purposes.

And let's not forget that any network attack, regardless of
the target or
purpose, is a Bad Thing and responsible netizens should do
their part to help
eliminate such abuses.

I'm done preaching now; I'm sure those who agree with me
didn't need a rehash,
and those that don't are unlikely to change their minds. Just
wanted to
provide a counterpoint to the "since $service has no business
function and
doesn't increase profits, there's no point in supporting it" crowd.

(not that RAS is necessarily in that crowd; he just happened
to be the first
to respond.)

Sometimes things are worth doing, even if doing them causes
you some grief. I'm
sure cynicism will eventually overwhelm me and I will realize
that there's no
point in sticking one's neck/network out to provide a useful
service to the
community.

okay, I'm ready for the flames now.

> --
> Richard A Steenbergen <ras@e-gerbil.net>

http://www.e-gerbil.net/ras

2

] I happen to agree, if only because; when script kiddies don't have IRC to
] play with they'll start looking elsewhere. I'd rather them have an IRC net
] to play with while they're being hunted. Wouldn't you?

Agreed. Keep in mind that when the kiddies really want to test something
nasty, they simply build their own (hidden and secured) IRC servers in
which to park the zombies. So a paucity of IRC servers/networks isn't an
issue to them.

Eradicating IRC isn't the solution. IRC is the "SOSUS net" of DDoS. It
would be wise if everyone paid close attention to what is discovered
therein.

Just my $.02.

3

Ariel:

If you don't have these links already, they contain many resources for DDoS attack prevention and protection:
http://staff.washington.edu/dittrich/misc/ddos/
http://www.cisco.com/warp/public/707/22.html
http://www.denialinfo.com/

The only few things you can do on your end are:
  TCP Intercept
  Rate-limiting
  Conacting your upstream ISP
  Contacting ISP managing the sources of the attack

Other people might have more/other suggestions.

You initial email asked for AboveNet contact. Did you get some assistance and if so what was the resolution? This is very important for us to know so we can kind of keep track of cooperative ISPs and the ones that just ignore these problems.

Thanks,
Jon

4

Ariel:

If you don't have these links already, they contain many resources for DDoS attack prevention and protection:
http://staff.washington.edu/dittrich/misc/ddos/
http://www.cisco.com/warp/public/707/22.html
http://www.denialinfo.com/

The only few things you can do on your end are:
        TCP Intercept
        Rate-limiting
        Conacting your upstream ISP
        Contacting ISP managing the sources of the attack

Other people might have more/other suggestions.

You initial email asked for AboveNet contact. Did you get some assistance and if so what was the resolution? This is very important for us to know so we can kind of keep track of cooperative ISPs and the ones that just ignore these problems.

And then what? Suppose you had a list of non-cooperative ISPs? What then? Experience has shown that the ISPs that don't care, won't care no matter what you say or do (those who follow FIRST know I have a lot to say on this matter, but have been holding back to give those non-cooperative ISPs time to make matters right - we are now on day 5 of a continuous non-spoofed 20Mb/sec dDoS attack :-)). Convince me why a list of non-cooperative ISPs is a thing that would help.

-Hank

5

behavior modification is sometimes achieved by bad PR.

They might blow off some individual isp, "eat your pingflood, we
will shut down our smurf amps when we feel like it". I would imagine
their attitude might change when reporters start calling, "when are you
planning on shutting down your 10mb/s smurf amps?"

-Dan

6

>Ariel:
>
>
>
>You initial email asked for AboveNet contact. Did you get some assistance
>and if so what was the resolution? This is very important for us to know
>so we can kind of keep track of cooperative ISPs and the ones that just
>ignore these problems.

And then what? Suppose you had a list of non-cooperative ISPs? What
then? Experience has shown that the ISPs that don't care, won't care no
matter what you say or do (those who follow FIRST know I have a lot to say
on this matter, but have been holding back to give those non-cooperative
ISPs time to make matters right - we are now on day 5 of a continuous
non-spoofed 20Mb/sec dDoS attack :-)). Convince me why a list of
non-cooperative ISPs is a thing that would help.

Well, the way I see it this internet thing is new to a lot of companies. Some are finding out the hardway what works, what doesn't. Quite a bit of the normal controls to prevent bad service, etc. are not in place.

I'm sure you've heard of the Better Business Burea, The Chamber of Commerce, etc? Well, I wan't suggesting making a list, I was suggesting he report his interaction with that company to you guys. This might allow NANOG to know how this or that ISP is responding to requests. You can sit by and say experience has shown and you're right. However, that is because no one is calling for any responsibility. There is no review and no drawbacks to acting with complete disregard. Well, just reporting that I spoke with X ISP and they attempted to cooperate or they didn't care at all is a small first step. If someone then took these reports and passed them to Boardwatch, or whatever the ISP might end up answering to someone.

There is quite a bit of helplessness and inaction going on when it comes to these types of situations and BIG ISP can get away with whatever they want. Well, experience has shown that if you organize the "little" people can influence the BIGGER.

7

[snip]

> >You initial email asked for AboveNet contact. Did you get some assistance
> >and if so what was the resolution? This is very important for us to know
> >so we can kind of keep track of cooperative ISPs and the ones that just
> >ignore these problems.
> And then what? Suppose you had a list of non-cooperative ISPs? What
> then? Experience has shown that the ISPs that don't care, won't care no
> matter what you say or do (those who follow FIRST know I have a lot to say
> on this matter, but have been holding back to give those non-cooperative
> ISPs time to make matters right - we are now on day 5 of a continuous
> non-spoofed 20Mb/sec dDoS attack :-)). Convince me why a list of
> non-cooperative ISPs is a thing that would help.

Well, the way I see it this internet thing is new to a lot of companies. Some are finding out the hardway what works, what doesn't. Quite a bit of the normal controls to prevent bad service, etc. are not in place.

I'm sure you've heard of the Better Business Burea, The Chamber of Commerce, etc? Well, I wan't suggesting making a list, I was suggesting he report his interaction with that company to you guys. This might allow NANOG to know how this or that ISP is responding to requests. You can sit by and say experience has shown and you're right. However, that is because no one is calling for any responsibility. There is no review and no drawbacks to acting with complete disregard. Well, just reporting that I spoke with X ISP and they attempted to cooperate or they didn't care at all is a small first step. If someone then took these reports and passed them to Boardwatch, or whatever the ISP might end up answering to someone.

There is quite a bit of helplessness and inaction going on when it comes to these types of situations and BIG ISP can get away with whatever they want. Well, experience has shown that if you organize the "little" people can influence the BIGGER.
> -Hank
> >Jon

Here are my thoughts on DDoS:

-The problem should not be addressed by going after the
originators of the attacks, rather a real-time targeting
system for those 'compromised' client computers with zombies
installed. It seems to me that no matter the use, a
computer that is attached to a global network which is
compromised in such a way, should be forced to correct the
problem prior to continued participation in that network.

With that said- it also appears there are two steps which
need to be taken place for proper implementation of such a
system. Detection and elimination.

As for the detection. Well- that is the hard part. As I
understand these zombies, they are just irc clients inbeded
in the compromised machine. And nothing stops irc clients
from connecting on just about any port available, so
port-based scans or blocks is not going to cut it.
So- if we can not scan for compromised machines, we need to
be reactive to their attacts. Finding out which IPs are
involved in a DDoS attack is not too hard. Hell- just last
week I was hit by a DDoS of 220 individual IPs from
different networks. All IPs were recorded for future use.
(and the target was a web server, not a IRC server/client)

How do we use this data to our advantage? What can we do
with it to 'verify' a bad client? Should there be a
time-limit for denial (for dynamically assigned members)?
Once a attack has started, what mechanisim can be in place
to stop it?

Clearly there are a lot of unanswered questions. I hope
this post spins-off some constructive discussion.

8

I think this approach, while helpful, isn't going to solve anything. I
seem to recall an RBL of sorts (Denninger?) for networks that had routers
that allowed directed broadcasts, and thus smurf attacks. Cisco also
(finally) put it in their default config.

Problem solved? Well, smurf attacks are down, but DDoS attacks are way
up. Why? Well, you can put a big part of the blame on M$, but my guess
is that many of the same perpetrators of those smurf attacks are now
operating these bots. I can't help but believe that if even 20% of them
were caught and had to spend just a little time (even hours) with the
cops, and had their peecees confiscated, you'd not be seeing nearly the
problems we are now.

Yes, going after vulnerabilities are good, but you'll never get them all.
If you were to go after the source of the attacks, and just got enough to
demonstrate that this is a much riskier activity than it is now, I think
it would be much more effective.

7-11's aren't built like banks, but those cameras (and tanacious
investigations) have drastically reduced holdups.

James Smallacombe PlantageNet, Inc. CEO and Janitor
up@3.am http://3.am

9

> Here are my thoughts on DDoS:
>
> -The problem should not be addressed by going after the
> originators of the attacks, rather a real-time targeting
> system for those 'compromised' client computers with zombies

I think this approach, while helpful, isn't going to solve anything. I
seem to recall an RBL of sorts (Denninger?) for networks that had routers
that allowed directed broadcasts, and thus smurf attacks. Cisco also
(finally) put it in their default config.

Thanks for the post James.

Well- I think we are dealing with different issues which
seem to change things a bit.. Putting in 'no ip
directed-broadcast' in a cisco interface is a one-time quick
and easy fix for all of those problems. Therefore- calling
the admin of a network who is allowing directed broadcasts,
and even helping them to fix it for good, has been a good
and easy task. However, the problem here is not-so easy to
take care of on the provider(s) end. I tend to see this
problem more-like open-relay issues. A open-relay SMTP
server is just-as much a pain in the rear as a compromised
windoze box (if not more) and we have several ways to combat
open-relay issues currently through various testing and
filtering systems.

Problem solved? Well, smurf attacks are down, but DDoS attacks are way
up. Why? Well, you can put a big part of the blame on M$, but my guess
is that many of the same perpetrators of those smurf attacks are now
operating these bots. I can't help but believe that if even 20% of them
were caught and had to spend just a little time (even hours) with the
cops, and had their peecees confiscated, you'd not be seeing nearly the
problems we are now.

I would agree that if we actually caught and punished the
attackers, the number of attacks would go down.. But there
are a lot of issues with doing that. You have to wait till
the attacker actually takes down and causes $$ damages to
your network/company prior to even being looked at by a
court. In this industry, many companies may not survive
long if such an attack took place, and would most likely not
be able to front attorney fees to go after a 15-year old who
could questionably be tried and punished after the fact.

Yes, going after vulnerabilities are good, but you'll never get them all.
If you were to go after the source of the attacks, and just got enough to
demonstrate that this is a much riskier activity than it is now, I think
it would be much more effective.

I like your feedback. Maybe we can do both :slight_smile:

7-11's aren't built like banks, but those cameras (and tanacious
investigations) have drastically reduced holdups.

I dont know :wink: They both have non-removable time-lock
safes, security systems, cameras, magnetic-locking doors,
panic-buttons, etc, etc... :slight_smile:

10

Jon O. writes:

There is quite a bit of helplessness and inaction going on when it
comes to these types of situations and BIG ISP can get away with
whatever they want.

Sooner or later, this is going to end up in civil litigation, and
unfortunate as that will be, it may help throttle these attacks a bit.
When a small ISP is taken down for days at a time due to a DDoS attack,
and a significant portion of the attack comes from one big ISP, and the
big ISP is unwilling to take any action to slow or stop the attack,
the small ISP has a credible claim for damages against the big ISP.
If a pattern of gross negligence could be shown, punitive damages could
potentially be a multiple of actual damages.

Jim Shankland

11

No kidding? Your somewhat twisted "re-education" approach finds
it perfectly normal to liken an illegal hacker activity (DDoS)
with a perfectly legitimate business operation of an ISP, for
the "crime" of simply having an open relay SMTP server.

Well, I happen to think that communications blackholing enterprises
such as the one run by former Abovenet boss Dave Rand and Metromedia
employee Paul Vixie are to be likened to denial of service attacks.

There should be no question that the guilty party is the actual
hacker or spammer. If the legal system doesn't provide ISPs adequate
protection under current laws, then new ad-hoc laws should address
the problem.

--Mitch
NetSide

http://www.dotcomeon.com

12

I thought only spammers and incompetent admins felt this way...

James Smallacombe PlantageNet, Inc. CEO and Janitor
up@3.am http://3.am

13

*plonk*

There is absolutely no relation whatsover between MAPS and DDoS attacks,
at least in the reality of every NANOG subscriber who's not named Mitch
Halmu, and trying to turn completely unrelated NANOG threads into your
personal soapbox is, IMHO, in extremely poor taste and professional
judgement. Remember, there are people here who make hiring decisions. You
never know when you might find yourself interviewing with one of them.

When you stop trying to turn every thread into whining about MAPS and
your god-given right to run an open relay and every mail server
admin's divine duty accept email from said open relay, let me know.

From a different email address, of course.

-C

14

Mitch-

My post is not intended to get in a war about open-realy
issues, but to rather put it in perspective from how *I*
view the problem. I certainly think that a compromised or
insecure machine should be addressed and the legal issues of
hosting such a machine due to clear negligence of a problem
which can (and does) cost other people a *lot* of money in
damages or 3rd-party fees is a concern that any legitimate
business-owner should be aware of. Furthermore- I am
attempting to find a way to stop DDoS attacks without legal
action (though- it should be taken also) and this seems to
be the best way (so far). I am open to suggestions you
may have to reduce/stop DDoS attacks as they happen.

15

Some lawyers feel that way too, but they charge a fortune for their
legal services...

--Mitch
NetSide

16

<SNIP>

Please quit feeding the trolls. It makes my kill file useless when you
reply and quote the messages from the troll. Its been well established
that conversing with Mitch on this subject is a waste of time and
bandwidth.

andy

17

On Thu, Jul 12, 2001 at 01:05:54PM -0400, Mitch Halmu exclaimed:

No kidding? Your somewhat twisted "re-education" approach finds
it perfectly normal to liken an illegal hacker activity (DDoS)
with a perfectly legitimate business operation of an ISP, for
the "crime" of simply having an open relay SMTP server.

One flame topic at a time, please. We haven't reached the requisite 30 days
since the last ORBS/RBL/SMTP/relay flamefest.

18

*plonk*

There is absolutely no relation whatsover between MAPS and DDoS attacks,
at least in the reality of every NANOG subscriber who's not named Mitch
Halmu, and trying to turn completely unrelated NANOG threads into your
personal soapbox is, IMHO, in extremely poor taste and professional
judgement.

Now I remember: you're the semihuman.com centaur, half man and half horse!
How's the nose, still brown? :wink:

Remember, there are people here who make hiring decisions. You
never know when you might find yourself interviewing with one of them.

What makes you think that I may need a job? Judging from the stock market
conditions, your friends at Metromedia may come knocking first.

When you stop trying to turn every thread into whining about MAPS and
your god-given right to run an open relay and every mail server
admin's divine duty accept email from said open relay, let me know.
>From a different email address, of course.

-C

The comment was on topic, inspired by remarks likening open SMTP relays
to DDoS.

--Mitch
NetSide

19

I've created a yahoo group for this type of purpose.

It can be found here:
http://groups.yahoo.com/group/dos_reports

The goal of this group is to provide a medium for sharing
information about DoS attacks. This includes current attacks
on your network, a phonebook with ISP contact information,
reporting ISP cooperation levels, etc.

The quality of this tool is dependent upon the quality of
the members. Please bear this in mind when posting. Please
do not send single line remarks about someone else's comments,
or generally be unhelpful. I've seen too much of that on this list.
This tool is not to replace the function of the NANOG list,
but to provide organized data that can easily be parsed and used.

We all know that many large ISPs are uncooperative when dealing
with DDoS attacks and responding to complaints. Well, a public forum
with peer review might help this situation.

If you want things to change you have to take action. Please
participate in this first small action toward a solution.

Any comments or suggestions are welcome. If you have some
documentation to add, or anything send it my way.

Thanks,
Jon

20

Please quit feeding the trolls.

The past few years have shown several DDOS attacks
aimed at subscribers of the NANOG mailing list.

As soon as someone brings up nearly any subject,
their thread is pulverised by no end of messages
on 'why Paul Vixie is the antichrist', 'how ARIN
ate my hamster', 'how ICANN is in league with
the devil', or copious other similar byte
arrangements. Though each attack is similar in
nature, they are sufficiently different in
byte content (but not semantic content) that they
are hard to automatically filter.

The attack appears to work by overloading mailing
lists with large amounts of mail message with
little relevance to the purpose of the group.
During the attack, because of the large volume
of superfluous messages, subscribers can no longer
use the list for operational purposes.

Such attacks are invulnerable to source tracing,
and filtering via .procmailrc access lists, as the they
appear to be spoofable from an almost infinite number of
source mail addresses. Users around that world, who
are not clue protected, can easilly read one
such message, and taken over by the idea they know
something about one such subject, become zombies,
and flood mailing lists with large quantities
of trite or misguided rubbish.

Several solutions have been suggested, including
border clue filtering. This would involve all ISPs
preventing clueless users from sending emails.
However, this has proved impractical to implement.
Apparently some ISPs may have clueless staff.

A second suggesting is 'blackholing' mailing lists
whilst they are under attack. This can be achieved
by simply not reading messages posted to the list
during the period of attack, or setting a .procmailrc
to redirect to /dev/null. However, this has the
side-effect of dropping operational traffic as well.

Whilst the SMTP protocol does not carry secure clue
authentication, it will be difficult to prevent
malicious or incompetent users from injecting
clueless messages into otherwise clueful data streams.

In the mean time, mailing list users will have to
apply ad-hoc mechanisms to reduce the impact of
such attacks.

Do not feed the trolls.