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."
poor little darl..... :)
. . . that's just the slashdot effect. . .
Great! now they get headlines simply by *not* lying
.... where did the synflood come from?
Jaysyn
There is a war going on for your mind.
Ha-ha!
Quick! Someone start knitting Satan a sweater!
libertarianswag.com
SCO's like the boy who cried wolf too much. Why should people care when he actually gets bitten?
If any authorities look into this, I am gonna be pissed. I mean, if they can't bother to do anything when the anti-spam sites get attacked, then they better damn well not do anything now.
Of course, I am of the paranoid type who assumes that SCO would stage a DDoS against themselves just for the publicity, so what the hell do I know?
WWJD?
JWRTFM!
Well I guess the lying or incompetent question has been settled.
You say
It's hard to have much sympathy, even though this is a dirty trick played by some h@xtor D00d that has nothing better to do with his time. The only way to beat a scurrilous bunch of deadbeats like SCO is to show to the public the kind of people they really are. Attacking them in this way only makes the Open-Source people look like a bunch of teenage kids that want to take on "The Man".
Stay tuned for new sig...
...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.
Drill baby drill - on Mars
CAIDA Analysis of SCO DoS Please use this link, the other one goes to a slow XML server.
Why on earth did SCO respond to 700 million syn packets? if there was even a moderate level of syn protection turned on they would have just droped the majority of those packets. and the bandwith usage would be half.
The cause that fits much better with their general operating pattern is that they purposely left themselves open to this attack to present themselves as the poor, innocent victims of the evil, Constitution-burning, enemy combatant, Open Source villans.
I'd buy that one.
SCO was hit with a 50,000 packet-per-second SYN flood peak
...
If their servers died from a synflood attack, there are 3 possible reasons:
- The IT guy is a monkey (likely, but still, he would have to be a really daft monkey)
- The IT guy has time-travelled from the mid-nineties and didn't know about synfloods
- The IT guy was told to compile a kernel without the synflood protection, so that Caldera/SCO would look like the poor company hit by naughty hackers.
Also, I might add, there are another aspect to consider : whoever hit SCO with a synflood attack has either:
- the brain of a monkey
- time-travelled from the end of the nineties and attacked SCO with what he thought was a really cool unbeatable DoS
- been told to attack SCO so that SCO looks like the poor company hit by naughty hackers.
Conclusion: The cause of this DoS was either:
- 2 particularly stupid monkeys
- 2 time-travellers
- 2 suckers paid by SCO
Dunno for you, but I know where my money would go if I had to bet
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
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
Well, we can tell people we didn't want it.
You don't win arguments by silencing your opponent (which is what DDoS is), you win them by being right. All evidence so far is the OSS community is right.
Whoever launched these attacks has made everybody look bad. Annoying SCO isn't going to make them say "Hey! Let's be nice now!". Their business model is now suing people. It's not as if their software was selling much.
If you're reading this DDoS dude, don't do it again, mmkay?
I'm scared of numbers that can't be written as a fraction. It's an irrational fear.
eems 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."
And how, exactly, would you prepare for this? Ignoring syn-floods is very simple when it comes to keeping your server alive, but how do you deal with the bandwidth saturation?
The "each way" would indicate the syns were being replied to (dumb), but they still would have clogged the pipe.
My question is how this is possible without killing the bandwidth other servers on the subnet, namely ftp.sco.com and others? That was the original reason for the conclusion that SCO was lying, and I've yet to see something that refutes it
The other question, of course, if it was a DDOS, who did it? A group, or one person slaving many connections? Maybe somebody with a DS3 or two available to spare?
With the last two, one would think that the outgoing results of such an attack would be noticed?
Also, again with the main arguement that the ftp was online whilst the www was offline... why does the article say the FTP was down (and first to be attacked)??
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!
Man, this whole thing sure is a lot of shoes in a lot of Slashdotters' mouths.
"Sufferin' succotash."
This statement is false.
What a nice place to say that, isn't it?
The CAIDA article states: "The current attack successfully blocked access to SCO web and ftp servers"
I find that difficult to believe. The Groklaw article mentioned successful access to the FTP server for a few HOURS while the WWW server was not available.
Then, suddenly, the FTP server was also down, which was after the Groklaw article appeared.
So basically there two things which makes me wonder about this whole situation:
If the main reason for the service being denied was actually the traffic generated by this attack, which is basically what the CAIDA article seems to claim, then there is no indeed no distinction to be drawn between the two servers, and so should have gone down simultaneously.
It was bound to happen eventually, if only by random chance - as much as they talk, sooner or later they were bound to say something true.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
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.
Is every Christian responsible for the bombing of abortion clinics? Is every Muslim responsible for honor killings? Is every Linux user responsible for these attacks?
I have little doubt that they were attacked. What seems strange to me though is that they were entirely giddy over the affair. They even went as far as issuing press releases about it. I haven't heard of any company that jumps to release PR about DDOS attacks so quickly. When forced to explain reports of DDOS attacks, a company may release a statement that clears the issues. But the first reports of these attacks came from SCO themselves. This is what raised suspicion, justifiably.
But people shouldn't jump to conspiracy theories so quickly. Doubt of their veracity, sure? Conviction that they are lying--not justified.
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/
That it wasn't customers rushing to pay their linux liscense fees because the court case is going so well?
and Daryl wouldn't lie either.
Professional Politicians are not the solution, they ARE the problem.
Pardon my ignorance, but if they took the web server offline at 10-something am, then what was producing the backscatter of ack packets? Was the ISP doing this for them? Why on earth would they bother? And if there was no machine there to respond to the syn flood for hours, then where was the backscatter coming from?
Also, I thought most zombie machines were compromised MS boxes. Are there networks of thousands of 0wned linux boxes out there that script kiddies are nuking each other with?
Wating for enlightnement...