It's been a while since the big-name websites got DDOS'ed, but some large data centers I know of still see hosts on their networks getting DDOS'ed once or twice a day. It's not uncommon for those with only DS3 connections to get them completely clogged for several minutes with attack traffic. If it happens on the UUNet connection then it can get blocked quickly but other NOCs often take a half hour or more to answer. And as discussed earlier on this list, the major players will NOT maintain access lists on their routers for their customers. (At least, that's what they tell their DS3-and-smaller customers). One thing I've recommended to my clients is to temporarily add a (shorter prefix) route through one of their upstream providers who _will_ maintain access lists for them. For example, 1.2.3.4 is under attack. 1.0.0.0/8 is the netblock being advertised through teir 1 providers, and the DS3's to those major providers is being swamped with attack traffic. Quickly modify the BGP advertisement through ???.net to advertise 1.2.3.0/24 as a route. Since that is a shorter prefix, it becomes the preferred route to 1.2.3.4, and since ???.net will maintain access lists providing, let's say, CAR for UDP and ICMP, that's all that needs to be done to block that particular attack. That plan quickly falls apart if several hosts are getting attacked at once, though if your total NORMAL inbound traffic is smaller than the committed rate on ???.net, you can split all your netblocks into two subnets and advertise those through ???.net for the duration of the attacks. Or if it's an ACK attack, or something else that can't easily be rate-limited or blocked, you're still screwed until you can reach the provider and have the target null-routed. I know this causes the global routing tables to increase temporarily, BUT it keeps the datacenter's routes from flapping due to losing the BGP sessions with the upstreams, which often happens if nothing is done about the attack. Another interesting point to note is that lately, most attacks have been for the age-old purpose of taking over IRC channels by knocking out the host on which the operator's bot is running. At least, none of my clients have seen their websites getting attacked lately. Maybe the calm before the storm? Of course, there is also the option of stopping them at the source, which is time-consuming and is usually done after it has been blocked via other means. And for every compromised server or workstation (usually on .edu domains) that gets fixed, two more take its place. Plus, we rarely get helpful responses from non-US domains (primarily because we're unwilling to make the international long-distance calls and find out we don't have any languages in common). It's looking like the only way to improve is to buy bigger connections; but in light of the Yahoo attack (800Mbps was the last word I guess?) how big is big enough? How many OC48 connections can _your_ data center afford? jcomeau@world.std.com aka John Otis Lene Comeau Home page: http://world.std.com/~jcomeau/ Disclaimer: Don't risk anything of value based on free advice. "Anybody can do the difficult stuff. Call me when it's impossible."
On Sat, Aug 19, 2000 at 08:27:13PM -0400, John O Comeau wrote:
Another interesting point to note is that lately, most attacks have been for the age-old purpose of taking over IRC channels by knocking out the host on which the operator's bot is running. At least, none of my clients have seen their websites getting attacked lately. Maybe the calm before the storm?
Hence, if all the IRC networks would implement Chanserv, and educate users, these attacks would decrease.
On Sun, 20 Aug 2000, Shawn McMahon wrote:
Hence, if all the IRC networks would implement Chanserv, and educate users, these attacks would decrease.
... or even better, we could all try to work together to take away the attack tools from the kiddies. As long as they have the tool, they'll find some reason to use it. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Sun, Aug 20, 2000 at 02:38:09PM +0200, Mikael Abrahamsson wrote:
... or even better, we could all try to work together to take away the attack tools from the kiddies. As long as they have the tool, they'll find some reason to use it.
Since the attack tool is "knowledge about TCP/IP, and access to the Internet", taking the tool away from them is not possible nor desirable. Our focus should instead be on figuring out ways to make the user of the tool accountable, and implementing appropriate punishment for misuse. Sometimes the tool is "ping". Do you really want to eliminate it? Do you really think we *CAN* eliminate it? Or, to put it another way: If you outlaw ping, only outlaws will have ping.
On Sun, 20 Aug 2000, Shawn McMahon wrote:
... or even better, we could all try to work together to take away the attack tools from the kiddies. As long as they have the tool, they'll find some reason to use it.
Our focus should instead be on figuring out ways to make the user of the tool accountable, and implementing appropriate punishment for misuse.
In my world this is included in "taking their tool away", which also include making an effort to discover when their tools are used somewhere (the source) and make an effort to trace it all back to whoever is controlling the tools and nail this person to the wall.
Sometimes the tool is "ping". Do you really want to eliminate it?
Of course not. But the question is if 10mbit of echo requests can be descibed as "ping".
Do you really think we *CAN* eliminate it?
We can never eliminate it, but we can make it harder to use and make an effort to nail the ones abusing it. A start would be to make it criminal negligence worldwide to operate a network that can be abused even after several notices about this fact. If you are a smurf amplifier and have been for quite some time after several notices, you should be punished. If you have rooted machines on your network that are used for DDOS attacks and you do nothing about it, you should too be nailed to the wall. Most of what is done is mostly temporary patches (access lists when an attack is under way) which never solves the problem, just the immediate issue. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Sun, Aug 20, 2000 at 03:00:18PM +0200, Mikael Abrahamsson wrote:
A start would be to make it criminal negligence worldwide to operate a network that can be abused even after several notices about this fact.
This would be approximately equivalent to making it criminal negligence to build a street wide enough to accomodate two car bombs at once. Except, of course, that the latter case is far more important than some search engine's web page. The current move to try to improve traceability of packets is the right solution. Any solution that involves worldwide laws is a non-starter.
On Sun, 20 Aug 2000, Mikael Abrahamsson wrote:
On Sun, 20 Aug 2000, Shawn McMahon wrote:
Our focus should instead be on figuring out ways to make the user of the tool accountable, and implementing appropriate punishment for misuse.
In my world this is included in "taking their tool away", which also include making an effort to discover when their tools are used somewhere (the source) and make an effort to trace it all back to whoever is controlling the tools and nail this person to the wall.
Person? Are you referring to the individual who wrote the original snipit of code? That sucks for Robbie Pointer. I've seen eggdrop code in 80% of the DoS-script source we've captured. Use of the DoS is the problem.
Sometimes the tool is "ping". Do you really want to eliminate it?
Of course not. But the question is if 10mbit of echo requests can be descibed as "ping".
Last time I checked that exceeded the thresholds set up on every router I know of run by "responsible" network operators.
A start would be to make it criminal negligence worldwide to operate a network that can be abused even after several notices about this fact. If
And who enforces this? Hell, we can't manage effectively punish Saddam Insane and the last time I checked, he did a bit more than pingflood an IRC server.
you are a smurf amplifier and have been for quite some time after several notices, you should be punished. If you have rooted machines on your network that are used for DDOS attacks and you do nothing about it, you should too be nailed to the wall.
How about this: You're a smurf amplifier, your provider unplugs you until you fix it. You're a provider? Your peering sessions go into administrative shutdown until you fix it. Same goes for rooted machines.
Most of what is done is mostly temporary patches (access lists when an attack is under way) which never solves the problem, just the immediate issue.
Just like the "lists" used in the email end of things, if we make it "painful" for the networks who are facilitating the lil' bas...er...PUNKS, they'll listen, eventually. When the lose complete network connectivity, I believe it will get their attention much quicker than not being able to send email to ISP X. --- John Fraizer EnterZone, Inc
On Sun, 20 Aug 2000, Mikael Abrahamsson wrote:
On Sun, 20 Aug 2000, Shawn McMahon wrote:
Hence, if all the IRC networks would implement Chanserv, and educate users, these attacks would decrease.
... or even better, we could all try to work together to take away the attack tools from the kiddies. As long as they have the tool, they'll find some reason to use it.
-- Mikael Abrahamsson email: swmike@swm.pp.se
How exactly do you propose that we take away code from them? John Fraizer EnterZone, Inc
That is completly NOT the case. Once they cannot take over channels they just like to cause havoc. We run a server on the Dalnet IRC Network and see SYN floods, Smurfs (Decreasing in frequency), fraggle, modified varients of pepsi and a number of other attacks. Other servers have reported attacks upto 150mbs. Only way to deal with it is with the FBI really. You can't effectivly filter it as it's normall spoofed. Best you can do is drop udp and icmp at the border (Even better if you can get your transit providers to drop it to that host at their meeting point with you), and deny all traffic locally on the machine except open ports. Even doing this, we still get taken down for maybe 5 minutes once a month. Jason --- Jason Slagle - CCNA - CCDA Network Administrator - Toledo Internet Access - Toledo Ohio - raistlin@tacorp.net - jslagle@toledolink.com - WHOIS JS10172 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GE d-- s:+ a-- C++ UL+++ P--- L+++ E- W- N+ o-- K- w--- O M- V PS+ PE+++ Y+ PGP t+ 5 X+ R tv+ b+ DI+ D G e+ h! r++ y+ ------END GEEK CODE BLOCK------ On Sun, 20 Aug 2000, Shawn McMahon wrote:
On Sat, Aug 19, 2000 at 08:27:13PM -0400, John O Comeau wrote:
Another interesting point to note is that lately, most attacks have been for the age-old purpose of taking over IRC channels by knocking out the host on which the operator's bot is running. At least, none of my clients have seen their websites getting attacked lately. Maybe the calm before the storm?
Hence, if all the IRC networks would implement Chanserv, and educate users, these attacks would decrease.
Hot Diggety! Jason Slagle was rumored to have wrote:
That is completly NOT the case. Once they cannot take over channels they just like to cause havoc.
We run a server on the Dalnet IRC Network and see SYN floods, Smurfs (Decreasing in frequency), fraggle, modified varients of pepsi and a number of other attacks. Other servers have reported attacks upto 150mbs.
Only way to deal with it is with the FBI really. You can't effectivly
Doesn't really scale well. Will the FBI go after those of international origin (non-US) ? They have limited resources, as with any federal agency. 5 years ago, when a former employer called the FBI...they'd laugh if the damage incurred wasn't at least USD $1 million. While they do have more funding now for pursuing computer crime - they're still rather stretched, and what does this mean for the smaller sites? Simply that they're screwed with this current model and style of DDOS attacks. Wish I knew what worked for DDOS attacks - conventional techniques doesn't seem to work :( Calling in the FBI is a little like trying to clean up the spilt milk -- doing it well after the damage has already been done. So you bust the perp...someone sitting at a computer on a power trip that got carried away. What then? How are you going to recover >$1M from a single individual (or even a few)? There are *plenty* more waiting in the wings. The numbers just aren't on the side of network operators, alas. Is it also economically feasible to pursue and sue every single perp? No. Will all the NOCs of ISPs along the path help trace in time to bust perps? No. Etc... Difficult problem. More easily solved with better tools to detect along with some inter-provider cooperation, for the short term. Along with things such as ISPs filtering their egress traffic to avoid rogue spoofing - that has been well known for some time now, but how many are *actually* doing it? Good thing this isn't wartime, or I'm sure we'd see a dramatic upswing in DOS attacks in general ;) -Dan
On Sun, Aug 20, 2000 at 08:24:43AM -0400, Shawn McMahon wrote:
Hence, if all the IRC networks would implement Chanserv, and educate users, these attacks would decrease.
Actually, then they get directed at the services, their upstream hubs, etc. Trust me on this. As long as IRC is running in some way, shape, or form, you have a very big bullseye placed on your network. --msa
On Sun, Aug 20, 2000 at 10:43:10AM -0700, Majdi S. Abbas wrote:
Hence, if all the IRC networks would implement Chanserv, and educate users, these attacks would decrease.
Actually, then they get directed at the services, their upstream hubs, etc. Trust me on this. As long as IRC is running in some way, shape, or form, you have a very big bullseye placed on your network.
I did say "decrease" not "stop entirely". Every argument I'm getting thrown back at me is arguing against the latter, instead of what I actually said. If even one person doesn't attack because he can't take over the channel, and brief service interruption doesn't cut the mustard for him, then using Chanserv was a good tool, and that's the only claim I made. If you want to argue that the attacks won't decrease, fine; but everybody please stop telling me that they won't cease, because I KNOW THAT ALREADY.
'Chanserv decreases nothing' and IRC has long been abandoned by most packetpoopbuttwarriorkiddies, now its networks, 'ISP's' competing with each other for customer share in a failing market place. Shawn McMahon wrote:
On Sun, Aug 20, 2000 at 10:43:10AM -0700, Majdi S. Abbas wrote:
Hence, if all the IRC networks would implement Chanserv, and educate users, these attacks would decrease.
Actually, then they get directed at the services, their upstream hubs, etc. Trust me on this. As long as IRC is running in some way, shape, or form, you have a very big bullseye placed on your network.
I did say "decrease" not "stop entirely".
Every argument I'm getting thrown back at me is arguing against the latter, instead of what I actually said.
If even one person doesn't attack because he can't take over the channel, and brief service interruption doesn't cut the mustard for him, then using Chanserv was a good tool, and that's the only claim I made.
If you want to argue that the attacks won't decrease, fine; but everybody please stop telling me that they won't cease, because I KNOW THAT ALREADY.
------------------------------------------------------------------------ Part 1.2Type: application/pgp-signature
-- Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | |--------------------------------| Henry R. Linneweh
It's looking like the only way to improve is to buy bigger connections; but in light of the Yahoo attack (800Mbps was the last word I guess?) how big is big enough? How many OC48 connections can _your_ data center afford?
In dealing with DDoS attacks, it is good do remember that altough channel capacity is a number of bits per second, router capacity is packets per second and server performance is requests per second. Very powerful DDoS streams containing thousands of small packets per second from random spoofed sources can put many routers, firewalls and servers down with no more than a DS3 of bandwidth. Rubens Kuhl Jr.
participants (9)
-
Dan Foster -
Henry R. Linneweh -
Jason Slagle -
John Fraizer -
John O Comeau -
Majdi S. Abbas -
Mikael Abrahamsson -
Rubens Kuhl Jr. -
Shawn McMahon