Re: IW: Tools Stunt DoS Attacks
This sounds like just a short term work-around, easily countered by the DoSers. Rather than fix the problem, they propose to try to detect "unusual activity" and block the IPs. I'm not sure what "trace" means either -- identify IPs and hunt down the perpetrators? It's predictable low tech approach to all net problems -- identify undesirable behavior, trace it, complain to ISPs, block it, form coallitions against the behavior with central clearing houses of people to block. Ultimately you can't distinguish between DDoS and popular content. They're just pushing the DDoS crowd to the next obvious and easy level -- bypass their fingerprinting of unusual behavior. They can't counter-escalate much futher because they'll start getting into false positives and rejecting legitimate traffic. Any robust long term solution to DDoS needs to defend against DDoS with Distributed Service. If content can be mirrored and cached reactively to traffic, mature versions of systems like FreeNet could be built to cope with DDoS. If requests are routed to local caches there is no longer a central server taking all the traffic, which is the basic problem these people are trying to kludge around. They might want to look at Hash Cash and Client Puzzles for systems which can't be easily distributed (web apps with central database needing to be updated). Adam
Roughly a year after cyber-terrorists paralyzed some of the Web's most trafficked sites, technology is finally emerging to stop such distributed denial-of-service attacks before they ever reach their target sites.
[...]
To combat such attacks on routers, a new company called Arbor Networks--funded by Cisco and Intel--this week will launch a managed availability service that aims to detect, trace and block DoS attacks.
http://update.internetweek.com/cgi-bin4/flo?y=eCNx0Bd6gU0V30DDqD
Unfortunatly DDOS Attacks seem to be here to stay... There are a LOT of ways to bypass detection, one of them would be something to this effect... I wrote this to test something after reading the original post, this took 10 minutes, and it is a simple proof of case that there ARE ways around "Abnormal activity". What is attached is very very simple, its your basic syn flooder with large packets (8k per packet), each packet coming from a different ip address (spoofed), obtained from a spoof file, this spoof file is then reused x number of times as specified by the cycle parameter. Please note: I didnt write this to use myself, I wrote this to test something and as a proof of case, and believing in total disclosure security policies and freedom of information Ive decided to open the code to see if anyone can find a way around this type of thing. The thing with this code, is that it is virtually impossible to block, along with the actual DOS code is a thing called resetgen.c, that resetgen.c generates another 1000 spoofed ips, if each host were to cycle their spoof files once, run that, cycle again, in a loop, and you ran this from a number of hosts at a time, the only way to block the traffic would be to firewall out the port in question completely, because the packet type is of type syn, if you block syn, nothing can connect to the port in question. Basically, people who claim to be able to stop DDOS/trace DDOS/etc etc I believe are playing on the public, making money out of a situation that unfortunatly has no end in site, due to the fuckups made in the IP protocol by the department of defense when they released the RFC. Cheers Andrew Alston On Mon, 5 Feb 2001, Adam Back wrote:
This sounds like just a short term work-around, easily countered by the DoSers.
Rather than fix the problem, they propose to try to detect "unusual activity" and block the IPs. I'm not sure what "trace" means either -- identify IPs and hunt down the perpetrators?
It's predictable low tech approach to all net problems -- identify undesirable behavior, trace it, complain to ISPs, block it, form coallitions against the behavior with central clearing houses of people to block.
Ultimately you can't distinguish between DDoS and popular content. They're just pushing the DDoS crowd to the next obvious and easy level -- bypass their fingerprinting of unusual behavior. They can't counter-escalate much futher because they'll start getting into false positives and rejecting legitimate traffic.
Any robust long term solution to DDoS needs to defend against DDoS with Distributed Service. If content can be mirrored and cached reactively to traffic, mature versions of systems like FreeNet could be built to cope with DDoS. If requests are routed to local caches there is no longer a central server taking all the traffic, which is the basic problem these people are trying to kludge around.
They might want to look at Hash Cash and Client Puzzles for systems which can't be easily distributed (web apps with central database needing to be updated).
Adam
Roughly a year after cyber-terrorists paralyzed some of the Web's most trafficked sites, technology is finally emerging to stop such distributed denial-of-service attacks before they ever reach their target sites.
[...]
To combat such attacks on routers, a new company called Arbor Networks--funded by Cisco and Intel--this week will launch a managed availability service that aims to detect, trace and block DoS attacks.
http://update.internetweek.com/cgi-bin4/flo?y=eCNx0Bd6gU0V30DDqD
Andrew Alston wrote:
Basically, people who claim to be able to stop DDOS/trace DDOS/etc etc I believe are playing on the public, making money out of a situation that unfortunatly has no end in site, due to the fuckups made in the IP protocol by the department of defense when they released the RFC.
Spoofed source-addresses can be (and often are) blocked at the access ISP. RFC 2267, Ingress filtering. DDOS trojans on ISDN/xDSL/Cable home user boxes will have to use their real (or at least same subnet) source addresses on datagrams, or run the risk of having the traffic dropped silently at the first router. There is also work being done on tagging and tracing datagrams. http://www.cs.washington.edu/homes/savage/traceback.html This won't stop DDOS attacks, but it will make it a lot harder to mount an attack without exposing many of the DDOS trojans participating. -- "I'm rather jubilant now. What Judge Kaplan did was blow away every one of these brittle and fragile rebuttals. He threw out fair use; he threw out reverse engineering; he threw out linking." - Jack Valenti, president of the Motion Picture Association of America.
So this is the kind of thing I was talking about -- it just moves things to the next obvious escalation from which there is no obvious way to go further down this dead end route of trace, block, track down and prosecute, etc. So what if you couldn't send a packet without revealing a source address. There are numerous ways to reveal someone else's source address, which is a real source address, just not yours. I'm not even sure it's a step forward to paint yourself into a corner where there is no way to fix the induced escalation of attack sophistication. Adam On Wed, Feb 07, 2001 at 05:16:13PM +0100, Lars Gaarden wrote:
Andrew Alston wrote:
Basically, people who claim to be able to stop DDOS/trace DDOS/etc etc I believe are playing on the public, making money out of a situation that unfortunatly has no end in site, due to the fuckups made in the IP protocol by the department of defense when they released the RFC.
Spoofed source-addresses can be (and often are) blocked at the access ISP. RFC 2267, Ingress filtering.
DDOS trojans on ISDN/xDSL/Cable home user boxes will have to use their real (or at least same subnet) source addresses on datagrams, or run the risk of having the traffic dropped silently at the first router.
This won't stop DDOS attacks, but it will make it a lot harder to mount an attack without exposing many of the DDOS trojans participating.
Folks should take a look at the work Bindview did on the Naptha family of dos attacks. Basicly, they found ways to move up the application stack, consuming CPU, without a serious comitment of resources on the client side. razor.bindview.com/publish/advisories/adv_NAPTHA.html Adam On Wed, Feb 07, 2001 at 02:29:56PM -0400, Adam Back wrote: | | So this is the kind of thing I was talking about -- it just moves | things to the next obvious escalation from which there is no | obvious way to go further down this dead end route of trace, | block, track down and prosecute, etc. | | So what if you couldn't send a packet without revealing a | source address. There are numerous ways to reveal someone | else's source address, which is a real source address, just | not yours. | | I'm not even sure it's a step forward to paint yourself | into a corner where there is no way to fix the induced | escalation of attack sophistication. | | Adam | | On Wed, Feb 07, 2001 at 05:16:13PM +0100, Lars Gaarden wrote: | > | > Andrew Alston wrote: | > | > > Basically, people who claim to be able to stop DDOS/trace DDOS/etc etc I | > > believe are playing on the public, making money out of a situation that | > > unfortunatly has no end in site, due to the fuckups made in the IP | > > protocol by the department of defense when they released the RFC. | > | > Spoofed source-addresses can be (and often are) blocked at the | > access ISP. RFC 2267, Ingress filtering. | > | > DDOS trojans on ISDN/xDSL/Cable home user boxes will have to use | > their real (or at least same subnet) source addresses on datagrams, | > or run the risk of having the traffic dropped silently at the first | > router. | > | > This won't stop DDOS attacks, but it will make it a lot harder to | > mount an attack without exposing many of the DDOS trojans | > participating. -- "It is seldom that liberty of any kind is lost all at once." -Hume
Coincidentally, or perhaps not given my recent comments about the dumbness of tracing and blocking as a strategy, someone appears to be syn flooding my cable modem right now. Tons of TCP connections from a bank of IP addresses slowly changing. Adam Adam Shostack wrote:
Folks should take a look at the work Bindview did on the Naptha family if dos attacks. Basicly, they found ways to move up the application stack, consuming CPU, without a serious comitment of resources on the client side. razor.bindview.com/publish/advisories/adv_NAPTHA.html
At 05:16 PM 2/7/01 +0100, Lars Gaarden wrote:
Andrew Alston wrote:
Basically, people who claim to be able to stop DDOS/trace DDOS/etc etc I believe are playing on the public, making money out of a situation that unfortunatly has no end in site, due to the fuckups made in the IP protocol by the department of defense when they released the RFC.
Spoofed source-addresses can be (and often are) blocked at the access ISP. RFC 2267, Ingress filtering.
DDOS trojans on ISDN/xDSL/Cable home user boxes will have to use their real (or at least same subnet) source addresses on datagrams, or run the risk of having the traffic dropped silently at the first router.
Most DDOS attacks forge their source address, changing between large numbers of forged addresses, so the site under attack can't defend itself by blocking the addresses that attack it. If a Bad Guy has thousands of slave machines, they can still launch a big attack, but if they need to use their own addresses, the target can block the attackers (still not easy for large numbers, but at least it's possible.) Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
If the attacker has a large number of slave machines, each machine is spoofing from 1000 addresses (I.E sending 1000 packets each one from a different address, and then cycling these addresses or generating another 1000 different addresses), it becomes VERY VERY difficult to block. Look at it this way... 1000 machines, each sending 1000 packets, from 1000 spoofed addresses, each packet is 8k big... 7812meg is therefore sent in payload size (as with my example code), per cycle, from a total of 1 million addresses. Because each packet is a SYN packet, probably aimed for a legit opened port (like port 80) and it looks like a standard normal start of a connect, the firewall will never block these packets, if the firewall DOES attempt to auto shun these packets at the address level, the firewall will attempt to insert 1 million rules in the space on under 5 minutes, its almost sure to fall over. If the firewall doesnt fall over and DOES succeed in these rule insertions, it will have effectively blocked a fairly major part of the internet from ever accessing your server that is being DoS'ed. With 1000 machines, each sending 10 8k packets per second (80k/sec), you are running at 80000k/sec, that is to say almost 80gigabit, enough to kill an OC-48 dead in the water. At this point, to stop and block and trace is almost impossible, and there are still PLENTY of places you can send spoofed packets from that arent blocking these things, besides, if you block them, unless you block them VERY high up, your ISP is gonna be dead in the water anyway and your blockage is gonna do nothing to stop it anyway If anyone has other opinions on what Ive said above, please let me know :) Thanks Andrew -----Original Message----- From: owner-cypherpunks@minder.net [mailto:owner-cypherpunks@minder.net]On Behalf Of Bill Stewart Sent: Friday, February 09, 2001 4:46 AM To: cypherpunks@cyberpass.net Subject: Re: CDR: Re: IW: Tools Stunt DoS Attacks At 05:16 PM 2/7/01 +0100, Lars Gaarden wrote:
Andrew Alston wrote:
Basically, people who claim to be able to stop DDOS/trace DDOS/etc etc I believe are playing on the public, making money out of a situation that unfortunatly has no end in site, due to the fuckups made in the IP protocol by the department of defense when they released the RFC.
Spoofed source-addresses can be (and often are) blocked at the access ISP. RFC 2267, Ingress filtering.
DDOS trojans on ISDN/xDSL/Cable home user boxes will have to use their real (or at least same subnet) source addresses on datagrams, or run the risk of having the traffic dropped silently at the first router.
Most DDOS attacks forge their source address, changing between large numbers of forged addresses, so the site under attack can't defend itself by blocking the addresses that attack it. If a Bad Guy has thousands of slave machines, they can still launch a big attack, but if they need to use their own addresses, the target can block the attackers (still not easy for large numbers, but at least it's possible.) Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
At 09:08 AM 2/9/01 +0200, Andrew Alston wrote:
If the attacker has a large number of slave machines, each machine is spoofing from 1000 addresses (I.E sending 1000 packets each one from a different address, and then cycling these addresses or generating another 1000 different addresses), it becomes VERY VERY difficult to block. 1000 machines, each sending 1000 packets, from 1000 spoofed addresses, each packet is 8k big...
Agreed - if the ISPs aren't spoof-proofing, it's very tough to defend against, as Lars and I noted. But if ISPs, particularly the cable and DSL ISPs, are spoof-proofing their outgoing packets, there won't be an unblockably large 1,000,000 addresses, just a still-annoying 1000 addresses, and the addresses you'll be blocking are mostly sites you won't miss (cable, DSL, and dial-up subscribers) rather than a random scatter of probably-useful systems and networks around the net.
Because each packet is a SYN packet, ... the firewall will attempt to insert 1 million rules in the space on under 5 minutes.
The magic of SYN attacks is that you don't have to accept more than one SYN from a given machine at a time, at least for a given port, so you don't have to use firewall rules except to limit the range of ports that are being targeted, and when you start to build rules, you only need 1000 of them.
With 1000 machines, each sending 10 8k packets per second (80k/sec), you are running at 80000k/sec, that is to say almost 80gigabit, enough to kill an OC-48 dead in the water.
Fortunately, that's only 80 Megabits, not Gigabits, so it's only a T3-killer, not an OC-768-killer :-) Still annoying. You can fill the T3 with about 1500 dialup users, and about 5 times as fast with cable modem or IDSL, 15-30 with faster DSL, and of course much faster with university machines (where you're limited by the university's aggregate outgoing bandwidth rather than the individual smurves' bandwidth.) Of course, if you've only got a T1/DSL/Cable line, you're toast. But there are several different attacks here - I'd be surprised if there's a legitimate use for 8KB SYN packets, though I'm not sure any current firewalls have an easy way to detect and block that, so it may work. Some attacks are likely be blocked by firewalls - ports you don't want, UDP packets and traffic pretending to be from open TCP connections when you haven't done a SYN first. Those still flood your incoming pipe - some ISPs are offering network-based firewalls that can do simple filtering at the upstream end of the connection to reduce the bandwidth you spend on anklebiters. But still, a 1000-machine attack is hard to do much about by yourself, and as you say, the upstream providers will get swamped also until you go out smurf hunting and get the things killed off. There have been some proposals to add various tracing to the backbone networks that may be of some help in the future. Things could be far worse, though - imagine if some popular software package that people installed on purpose had DDOS capabilities, like a hacked Napster client or Quake Performance-Booster or Netscape Foobar-Graphics plug-in or a more clever than usual MSWord virus. Bad stuff. Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
participants (6)
-
Adam Back -
Adam Back -
Adam Shostack -
Andrew Alston -
Bill Stewart -
Lars Gaarden