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 220.127.116.11 and ftp.sco.com has the IP address of 18.104.22.168 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
"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 22.214.171.124. So, I then ran a traceroute on
126.96.36.199, and found that the trace stopped at the gateway to SCOG's
network, always. I tried their ftp site, 188.8.131.52 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.
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.