Slashdot Mirror
SCO Not Lying About DoS Attack
Licensed2Hack writes "The Cooperative Association for Internet Data Analysis (CAIDA), part of the San Diego Supercomputer Center at the University of California, San Diego has an analysis of the recent DDOS on SCO.com. Netcraft also has more information in their article and analysis graphs. Seems SCO was hit with a 50,000 packet-per-second SYN flood peak, which yields approximately 20 Mb/s each way, or about the capacity of a DS3 line."
...SCO Must Prove Existence Of Santa Claus in Thirty Days
I'm scared of numbers that can't be written as a fraction. It's an irrational fear.
CAIDA Analysis of SCO DoS Please use this link, the other one goes to a slow XML server.
The attack was just short of half a DS3 Line.
DS3 Line = 44.736Mbps for those of you who need a definition
-Certified TechnoWeinie
No.
DS1 is the circuit either a T1 or E1 rides on. E1's are the european equivelent to at T1. DS1 is the raw circuit.
If you need web hosting, you could do worse than here
it's said to be a D[istributed]DOS attack -- that means it came from all over, no?
who's moderating the meta-moderators?
For the mathematically challenged:
20mbit up + 20mbit down = 40mbit
Or 20mbit x 2 = 40mbit
20mbit comes into to SCO web server a second
20mbit goes out of SCO web server a second
Now, how much traffic was there in that second?
I'm not sure I can make it any clearer.
Once upon a time, a T1 was 24 multiplexed analog telephone circuits plus some control channels.
DSx is the digital version with the same capacity. The analog infrastructure is mostly gone now, so the terms are used interchangably in most conversations.
Conformity is the jailer of freedom and enemy of growth. -JFK
Provided that the bandwidth to the load balancer did not get saturated in the DDoS, and the attack was targetted at a specific IP then it is perfectly possible for adjacent IPs to be fine. I and several others pointed this out as a possibility out in the original story and either got modded to oblivion or called idiots for it. C'est la vie.
UNIX? They're not even circumcised! Savages!
Ummm. No. A DS3 (or T3, or T1 for that matter) is full-duplex. A DS3 supports up to 45 megabits/second in BOTH directions. Read your own link a little more closely... "A DS3 is capable of moving over 5.5 Megabytes per second (45Mbps) in one direction - ***twice that when upload and download performance are combined***."
Maybe nowhere. The analysis methodology used could be spoofed by SCO by them running a program on their respective servers that sends out SYN-ACK and SYN-RST to random IP addresses.
CAIDA would just assume it's a real DDOS attack. Remember "backscatter analysis" analyzes the response from the "target" site. They don't see and cannot prove the existance of the actual SYN flood.
Liberty you never use is liberty you lose.
Yes, SCO are pretty low on the karma totem, however the 'experts' quoted on groklaw, as well as the far more numerous 'experts' who replied that yes they must be faking it .... were drawing their speculations on very little data.
If you cared to measure you sure didn't need to be CAIDA, many snort, pf and netfilter logs are showing the backscatter of this attack.
And to all the experts who've been holding that a large synflood is easy to fix by blocking the attacker IPs: get a fscking clue.
Both syn and bandwidth attacks use forged addresses children (which is why there is backscatter), each incoming syn is from a random IP, the ack goes to the forged addr, not the originator.
The best way I've seen to handle this involves sensors at enough upstream locations to measure the packet count ratio skewing which results. This isn't generally deployed
Now technically SCO could probably manage to forge that kind of data (just send out all the expected response traffic) but again there are enough sensor platforms out there now that such a deception would certainly be unmasked eventually.
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
In fact... a lot of SYN attacks don't use comprimised hosts at all! They actually send the request to a bunch of computers that are just running webservers, that's all. They spoof the destination IP and change it to the IP of the target to be attacked and all those webservers (usually ~40,000) respond at once to the host, essentially knocking it offline. It's happened to me before. :P
So you can use even a secure (but not 100% properly configured) server to launch an attack with... Intersting stuff.
With syncookies.
Wastes bandwidth sending the replies back, and wastes resources on the host making and sending the replies. Once you've determined a DoS is underway, drop the offending packets and be done with them.
The whole point of a DDOS is that you can't recognize which packets are the offending ones. Sure, at some point a human is going to look at the situation and say, OK, we're going to shut down this machine until the DDOS has subsided, but it would be stupid to shut down a machine automatically whenever you're getting attacked.
Wasting bandwidth is irrelevant if you're going to shut down the machine anyway.
DS3 is ~45Mbit/sec bi-directional
(so 20 is about 44% utilized)
Take a look at the graph at CAIDA. The web server takes a beating for about an hour around 4am PST, and again for a bit longer around midnight. Just as the latter is leveling off, an even bigger spike hits the FTP server which lasts about an hour and then tails off over the next several. All in all a pretty poor DDoS attack if they couldn't sustain it for more than a few hours so the originator can't have been too smart. Bit bit like the victim that failed to have adequate SYN attack protection really... do you suppose there is a connection?
UNIX? They're not even circumcised! Savages!
I have no idea if SCO is using Cisco routers on their permiter, but I guess its not too unreasonable to assume this is a possibility. With a Cisco on the permiter, preventing a SYN attack requires all of 3 additional lines to the configuration. I'm guessing it also doesn't take too much more than this on any enterprise-class router.
p s2 120/products_configuration_guide_chapter09186a0080 0b6f0e.html
Configuring a Cisco perimeter router to prevent SYN flood attack against web server:
(config)#access-list 151 permit tcp any host
(config)#ip tcp intercept list 151
(config)#ip tcp intercept mode intercept
With Intercept mode enabled, all incoming SYN are held by router which proxy-answers w/syn-ack. Won't forward to server if Ack not recieved.
http://www.cisco.com/en/US/products/sw/secursw/
This claim from netcraft bugged me since the first time I read it when it was linked to the last sco story. Let's spend some time debunking it.
Let us assume that the resolution of netcrafts measurements has a resolution of 1 minute, hell, make it 10 seconds. How long do you think it takes for an average zombie machine to start churning out syn packets at full speed? I'd say after maybe a second or two, and I'm being generous. There's a >90% chance the zombies are all recieving commands through IRC or a similar set-up, this adds maybe 2 to 3 seconds to the response time. All in all it's fair to assume that within 5 seconds of the attackers push of the button all zombies will be spewing syn packets at their maximum rate.
So in conclusion; Any attacker with a sufficient amount of zombies can push an amount of traffic into any network enough to saturate its bandwidth contraints within a mere *5* seconds. There is no reason *at all* why an attack like this should always look like a slow (1 - 10 minute) degradation of network performance, it can be done close to instantanious.
Of course depending on your relation with your backbone provider you can always try to block it higher-up. Although, don't be surprised when some attackers actually saturate gigabit links...
-- Witty saying #52; 404: file not found
That both sites have published this retraction, after having previously published the original stories about the DDOS being a fabrication. Many, more "mainstream" and "credible", news sites probably would not have done so, or would have published the retraction loaded with "spin."
Worse, many other sites would have tried to cover up the truth, rather than risk suffering a little "egg on the face."
To the credit of both Groklaw and Slashdot, both have said "Oops, we were wrong," and handled things in a very mature fashion.
Good job, guys.
// TODO: Insert Cool Sig
T1 stands for Trunk Level 1 and is a digital transmission link with a total signaling speed of 1.544Mbps. T-1 is a standard for digital transmission in North America (USA & Canada). T-1 is part of a progression of digital transmission pipes - a hierarchy known generically as the DS (Digital Signal Level) hierarchy.
T1 was originally supplied on two pairs of copper wire (transmit and recieve pairs), but is often delivered via multiplexed fiber optic cables. A T1 can be multiplexed into 24 64Kbps channels for telephone trunking (compatible with the analog phone system), but are still digital signals between the PBX and the ILEC/CLEC's phone switch.
The E1 is a standard in Europe (and UK) which is capable of 2.048Mbps and can be channelized into 32 64Kbps channels for phone trunking.
**most of this is paraphrased from Newton's Telecom Dictionary 16th Ed.