SCO Group Web Site Attacked Again
FreeLinux writes "With not much SCO news today, it seemed that this story was needed - Reuters is reporting that, SCO is again suffering under a DDoS attack that has crippled their web site and email system since Wednesday morning. For the third time this year, the SCO Group's Web site came under attack, apparently by hackers unhappy with the company's legal threats against users of the Linux operating system. The denial-of-service attack started at 6:20 a.m. EST Wednesday and continued through the day, said Blake Stowell, spokesman for the Lindon-based company."
...and the happy folks at Groklaw already have a statement up with arguments to effect that SCO is fibbing. They think the attack could be a hoax.
You say
There's been a ton of discussion of this on Groklaw today -- consensus is that either this is no attack, or their network is run by doofuses.
http://www.groklaw.net/article.php?story=200312101 63721614
If it is a DDoS attack, SCO are incompetent for not blocking it. Or it is just more FUD.
Head over to Netcraft News and see how this server "died". If this is a DDOS attach I am Queen of Spain.
Help fight continental drift.
This is a load of rubbish. See Groklaw for a much deeper and more insightful look at what really happened, a full explanation of the technicalities of the DDOS attack (claimed as a SYN attack that took up all the bandwidth and flattened their e-mail - and yet you can still get to ftp.sco.com (on same subnet), smtp.sco.com all other XO.net fed servers. Groklaw also noticed that the machine was down well before the press release claims and that it went straight down - no hiccups or other indications of a DDOS attack, just a straight gone - switched off or unplugged most likely.
See the netcraft stats for that little bit. If SCO make any claim that this is a DDOS, they are lying through their teeth and the evidence was collected as it happened - see the members zone at Groklaw for the raw Traceroute returns.
An infinite number of monkeys will eventually come up with the complete works of
> Grow up. Settle it by the law.
Yes. SCO should do that instead of lying about their downtime
RST
I expect the blatient misuse of hacker as a synonym for computer criminal in the mainstream press, but I woulda hoped that Slashdot would do better.
"Mission Accomplished" -- George W. Bush May 1, 2003
According to Groklaw, not only is it implausible that this is a real attack, it's not even competently done. SCO blames a SYN flood, which is trivial to ignore. Their ISP hasn't had anything to do about it. While they say their email server was down, it actually wasn't. Their FTP server on the next IP over (and on the same block of addresses) had no problems. Their internal network almost certainly isn't anywhere near their Web server, network wise, and, if it was, it would almost certainly have a firewall that's not the web server.
It's clear that SCO's run out of technical people; not only are they faking technical problems, they can't even make up a technically sound attack on their own systems.
I work in the Canopy Group office buildings at another (non-evil) company. We're all serviced by Center7 and the last time there was the confirmed/acknowledged DDOS attack we felt it hard. Getting to hosts outside of the building was very difficult all day.
No hiccups today. Center7 did promise last time that they could and would isolate everyone else from SCO, so there is another explanation, but...
Tweet, tweet.
ftp.sco.com is 216.250.128.13. www.sco.com is 216.250.128.12. They are on the same network segment. However, the first is completely and normally responsive, while the second is entirely unresponsive. This is not in any way characteristic of any sort of modern flood-type denial-of-service attack -- that is, a DDoS aimed at flooding the network itself. Whatever is disturbing SCO, it is not a DoS of the sort they evidently believe it to be.
Unfortunately, SCO has taken the "cargo cult security" measure of blocking pings, so it is not possible to gather any information about their disturbance in that fashion. I suspect that the best method to gather information about SCO's disturbance is, in fact, for SCO to fully and legally respond to IBM's discovery requirements.
("SYN flood" is obviously wrong. Although some firewalls and IDS still report TCP-based DoS floods as "SYN floods", the condition that used to be associated with SYN floods has been fixed in current operating systems. Unless they are running a system old enough to be called grossly negligent, they aren't susceptible to TCB starvation. The current unavailability of www.sco.com looks more like someone tripped over the Ethernet cable.)