decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
Security Experts Doubt SCO Was Attacked as Claimed
Wednesday, December 10 2003 @ 04:37 PM EST

SCO has reported that they are experiencing an attack on their servers. Groklaw has been flooded with information that indicates their story doesn't add up.

The consensus of what I am hearing is: That it is probably not an attack. That their description of the "attack" makes no sense. And that if what they are saying were true, SCO would be admitting to gross negligence.

First, I'm being told that Linux has a very simple preventative built in. Linux comes with the ability to block ALL SYN attacks. End of story. All major firewalls can do so also. They run their web site on Linux. CISCO routers can protect against SYN attacks too, I have been told, if properly enabled. Why does SCO persist in having such problems?

I knew one of Groklaw's readers is a security professional in Australia, so I wrote to him and asked if he'd take a look and give me his opinion.

Steve McInerney describes himself like this: "I worked for six years as the Technical Security member of the IT Security team for Australia's Department of Defense. Also I did IT Security policy writing/advice. More recently I was one of the senior designers/firewall/security experts at a company that manages Australia's largest federal government-certified Internet gateway." He just sent me his opinion:

"SCO has released a press release stating that their web site www.sco.com has come under a Distributed Denial of Service Attack (DDoS), specifically a SYN flood.

"Before we show how silly this statement is, let's explain SCO's position. A 'SYN Flood' attack is an attack that attempts to stop a server from accepting new connections. It's quite an old attack now, and has been relegated to the 'That was interesting' basket of attacks.

'A very simple analogy of a SYN attack: You have two hands, you are thus able to shake hands with at most two people at any one time. A third person who wants to shake your hand has to wait. Either you or one of the first two people can stop shaking hands so as to be able to accept the third person's handshake.

"In this instance SCO are claiming that 'thousands' are doing something similar to their web server. This is, in and of itself, plausible. Unfortunately if we look closer there are a few problems with this claim of SCO's.

"As stated above, the attack is quite an old one. Patches to all Operating Systems that I'm aware of, do exist to stop this sort of attack. For instance, a CISCO document: http://www.cisco.com/warp/public/707/4.html describes the attack and provides ways to stop it. Note the lines: 'Employ vendor software patches to detect and circumvent the problem (if available).' This means, quite simply, that patches exist to mitigate this attack.

Why hasn't SCO applied them?

Further SCO States:

"'The flood of traffic by these illegitimate requests caused the company's ISP's Internet bandwidth to be consumed so the Web site was inaccessible to any other legitimate Web user.'

"Interesting. If their bandwidth is consumed, then any servers nearby will also be inaccessible. That is www.sco.com has the IP address of 216.250.128.12 and ftp.sco.com has the IP address of 216.250.128.13 so the two servers are side by side, probably even on the same physical network hub/switch. Note that there is no room for a broadcast, etc., address - these servers are on the same subnet - i.e., on the same network device (hub/switch).

"Unfortunately for SCO, from Australia, ftp.sco.com is highly responsive. No bandwidth problems there that I can see - even though www.sco.com is still unavailable.

"The evidence then, is that their bandwidth is fine.

"So what about just the SYN flood? Well, even with patches, to successfully conduct a SYN flood you would tend to chew up available bandwidth anyway, which we aren't seeing. So I have quite strong doubts about the accuracy of this information.

"I feel quite comfortable in stating that SCO are NOT suffering a DDoS attack. Specifically not one that they have described. It looks to me like someone has accidentally kicked a cable out of it's socket or similar. Or a HDD failure or....

"Speaking as a Sysadmin/Firewall guy, my first priority in any attack is to solve the problem - not issue a press release.

"Dealing with an DDoS atack when your bandwidth is NOT eaten up is fairly simple. A quick and dirty script to read your firewall log(s) for incoming addresses that are trying the SYN attacks is fairly easy. Adding those IP addresses to a quick block list is also easy.

"Problem just goes away."

Roland Buresund, who has spent some 20 years in security (latest as Global Head of Information Security at Scandinavia's largest Investment Bank), including being a member of the POSIX and X/Open securirty groups as well as being a former chairman of the Swedish NSA's InfoSec group, told Groklaw he agrees with Steve's conclusions.

Denis Hammond, who says he has been "happily writing kernel and network code for thirty years now" contributes his opinion:

"Was there a denial of service attack against the SCO Group today?

"I certainly doubt it. When I first heard of the 'DoS' against SCOG, about 8 or 8:30 AM PST, I pointed a browser at www.sco.com and got a time out, the same happened with other SCOG websites like www.sco.de. SCOG hosts many of their 'national' sites on 216.250.128.12. So, I then ran a traceroute on 216.250.128.12, and found that the trace stopped at the gateway to SCOG's network, always. I tried their ftp site, 216.250.128.13 and had no problems accessing it either with ftp or by traceroute. And there was no untoward latency noticed. Other systems on this netblock also showed no access issues.

"Later in the day SCOG issued a press release claiming that they had experienced a 'syn flood' attack, that 'flooded their servers' denying service to 'their intranet, mail servers, etc.' OK, I'm paraphrasing. I did not see any indication of an DoS of any type, but I was willing to give them the benefit of (minor) doubt. Until the press release.

"If they truly were the victims of a syn flood, then they are grossly negligent. Mitigation tools for this type of attack have been available since 1999 and earlier. For the Linux Kernel, commercial firewalls and routers. These tools called syn_cookies are routinely applied by all sites that are even moderately concerned about basic security, and this is why we don't hear about eBay or Yahoo! or other well known sites suffering from syn flood attacks."

Others confirm that the ftp server was up and accessible from the US as well. This wouldn't be the case in a real DDoS attack, according to Steve and everyone else I have been hearing from. Various people monitoring their network to try to determine the reason for the webserver outage were able to successfully connect to many other services. Linux (which is used to run the SCO website) has built-in protection against these sorts of attacks, as mentioned, and simply has to be enabled. SCO can look at this page for how to enable it.

This will protect against attacks which do not saturate network bandwidth. But apparently their bandwidth was fine, since people were able to connect to various other services - interestingly, according to one report on Yahoo, including email, which SCO claimed was disabled, as well as their ftp server.

Because everybody looking into this found that a traceroute ended at X0.net, I called them and spoke with tech support. I was told it couldn't reasonably be a DDoS, because he showed the ftp server still up. X0.net was not the block, in any case. "Everything is pointing to calderasystems.com," I was told.

There will be more information to come, I have no doubt. But this is enough to raise questions in any reasonable person's mind. If there is an attack, where is the proof? Did SCO SYN attack itself? A single attacker can mount a SYN flood, I'm told. They are claiming the attack affected their intranet. I am hearing that is unlikely in the extreme. Here is how Jason Fordham explained it to me:

"An Intranet should be designed so that all traffic on that net can get to anywhere on that net. It's open; it's inside the citadel. You can look out, and pull data in from outside, but you don't let anyone straight in. Anything outside comes through another server - email to a mail server, or submitted to a webpage, like a GROKLAW post. These act as control points – outside the citadel.

So why would SCO’s intranet be accessible? Even if they were so negligent as to leave it accessible, is there nothing they could do? Jason explains:

"You design for that. if you need to pull up the drawbridge and shut out the rest of the world, you don’t depend on the usual, external, public hosts: you switch to alternate paths to the services you need. Lost an external mail server? No problem! Set up a second mail server for the same domain. It's something you can do in the DNS setup: a domain can have several Mail eXchanger (MX) records. In order to sort out which server you should try first when sending email, there's a numeric preference field. 10 is high, 20 lower, and so on. You can have multiple web servers set up on different addresses, alternative DNS setups you switch to, so that you Never Appear to Be Down, even when you're under attack."

Is their ISP so incompetent it can't prevent and/or handle a SYN attack? If so, maybe they should make some adjustments. Why doesn't SCO do these simple things? We've done our part by providing them a How To. Why they haven't done it already? Your guess is as good as mine. And I'll bet I could guess what you're thinking, too.

There is help available from the Linux community for any newbies. One Groklaw reader thinks SCO is speaking out of ignorance, and he has a suggestion:

"There are many types of DoS and DDoS attacks, each type targeting a different resource. Blake Stowell is confusing a SYN flood (an attack against the TCP port resource on a host) with a brute-force DDoS against a bandwidth resource. This simply demonstrates that BS is not a techie and that the difference has not been explained to him.

"Dear Mr. BS: . . . A SYN-flood attack probably consumes 1 Kbps or less. Everybody else in the known universe can communicate with all of your externally-visible machines except www.sco.com. If the (alleged) attack on www.sco.com has affected any other machines, your network is very poorly administered. I suggest you avail yourself of the vast array of of volunteer expertise that is ready to help any user of a Linux system.

"Even you."

UPDATE 12/12/03:

I found a CAIDA report which gives strong support to SCO's claims of having experienced some kind of attack. I am posting the link in order for you to have a complete picture. Unfortunately, there are conclusions presented, but no logs, for example, to make it possible to evaluate their results. The paper also does not answer the biggest question: the lack of mitigation. There are other questions still in the air, but in the interests of honesty and openness, I wanted to post this paper when I found it. I have sent it to various security experts to evaluate as well.


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )