Slashdot Mirror
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.
ain't no synflood at *.sco.com ... click me.
Comment removed based on user account deletion
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.)
ir.sco.com = 170.224.5.43
www.sco.com = 216.250.128.12
Your posting is NOT very informative, go back to MCSE school please.
Just because a system administrator has taken steps (SYN Cookies, kernel tweaking, etc.) to severely limit the SYN flood's access to a network service doesn't mean the box is impervious to this type of attack. The traffic alone when coming from many different hosts, likely including hundreds of university/cable drones, can overpower their bandwidth capabilities. Also lets not forget that they are trying to keep http open to legitimate connecting clients.
The DNS blacklists hosted at Osirusoft and monkeys.com were both shut down this year by DDoS attacks. Osirusoft was the most widely reported and probably the one you are thinking of.
There may be other shutdowns I'm unaware of. Many other DNSBLs are being subject to attacks, but several are handling them very well.
-Matt
The following machines are running currently-reachable FTP servers:
216.250.128.7
216.250.128.13
216.250.128.14
216.250.128.15
216.250.128.16
216.250.128.17
I was able to download /pub/ls-lR from ftp.sco.com (216.250.128.13) 74.91 KB/s (600 Kb/s). My broadband is rated at 640 Kb/s, so the bottleneck was likely at my end. These machines are almost certainly on the same subnet and are likely connected to the same gear (SCO's subnetting is their choice, but if ftp.sco.com and www.sco.com are on different subnets, their subnet masks are 255.255.255.254 and they must have only two IPs per subnet - I don't believe this is even possible as you need a network and a broadcast IP for each subnet).
The fact that all of these machines are reachable and that at least one of them can saturate a broadband link indicates that SCO is not having any bandwidth problems. I also performed some ICMP tests and the machine is not sending out port-unreachables, timestamp-replies or netmask-replies - these seem blocked upstream. I'm getting a little nervous sending out these funny packets as I don't want anyone to accuse me of anything, but everything indicates that the machine is completely offline. If they allowed some ICMP replies through upstream, receiving a reply would show that the machine is actually online, but somehow cannot handle TCP requests (and the problem is not bandwidth as shown, so it would have to be something wrong with the host, such as a firewall rule); if they allowed through ICMP replies and the machine did not respond whereas others on the subnet did respond, it would show that the machine is almost definitely offline unless it has a more restrictive firewall than the other machines (very unlikely given that this, as-claimed, could have been prevented with syncookies). As it stands, one can only say that the machine is very likely offline (unplugged or turned off).
SCO's incoming mail server seems to be working fine. They only have one MX record for sco.com and it resolves to 216.250.130.2 for me at the moment. I only connected to it and saw a banner, but easy way to test this further is to send a message to an invalid address @sco.com and see if a bounce gets back. I don't want to give them an email address.
All of this is current as of 2003-12-10 21:57, Mountain time (SCO is in Utah). Further investigation lead nowhere; thus the delay in the post.
Justin.
You're only jealous cos the little penguins are talking to me.
So, on those grounds, I'd be prepared to accept that SCO is telling the truth and they are indeed under a DDoS SYN attack against their webserver. However, as normal for SCO, they then go and overcook the situation and claim that their internal network and Intranet has been hit as well. The only possible way this could be the case is if they are using the same server(s) for their public web as their Intranet which is one of the dumbest possible things you could do.
That leaves us with three possibilities:
- SCO is simply lying and there is no DDoS at all.
- They are telling the truth about the DDoS, but have exaggerated the effects in a sympathy ploy, making themselves *look* clueless.
- They are telling the truth about the DDoS and the Intranet, meaning they *are* clueless.
Take your pick!UNIX? They're not even circumcised! Savages!
iptables -A OUTPUT -p tcp -d www.sco.com -j DROP
iptables -A OUTPUT -p udp -d www.sco.com -j DROP
OR
ipfw add 1 deny ip from me to www.sco.com
The analysis is written by yet another clueless fuck claiming to be a security or a network professional.
.12 and .13 adjacent on cheap low end bozo hosting.
You get
In real life they may be in different corners of the globe, because in real high end network installations people use loopback addresses and you never ever see the actual physicals. They may even be on martian networks (and usually are) that are uplinks to a firewall or load balancer which quite often does forwarding with no increment of TTL so that people do not know that it is there.
So the fact that ftp.sco.com is accessible while www is not does not mean a thing.
Same goes for SYN cookies and SYN floods. The part of the attack that brings the target machine down is now well mitigated and most systems are not vulnerable to it. This still leaves the service part. The bad thing about SYN floods is that in order not to go down the target site has to discard SYNs. This is usually done by rate limiting them. Once SYNs have been rate limited, a sufficiently thick flood of SYNs from random addresses will render the site unresponsive and inaccessible, no matter what patches have been applied, because for every legit SYN you will have up to hundreds of non-legit ones.
Note that I am not defending SCO.
I am simply sick of "security" and "network reliability" cretinoids that continue to make claims based solely on IP addressing. This claims are invalid, void and outright stupid.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/