There’s no grassy knoll and no book depository, but that hasn’t stopped the conspiracy theorists having a field day. The news that SCO’s website was taken down by a denial of service (DoS) attack – or more accurately, several DoS attacks brought the paranoiacs out of the closet.

The debate can be reduced to simple terms: was the SCO site targeted by hackers or did the company bring down its own site itself in an attempt to discredit the open source community?

It’s a simple question but the answer is anything but simple.

The first indication that things might be going awry was when website Groklaw reported some security experts’ concerns that things weren’t what they seemed.

Australian security professional Steve McInerney doubted that the company had suffered a DoS attack and said on the website that “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 (sic) socket or similar. Or a HDD failure or....”

But other security experts hit back. The evidence to support SCO’s assertion (apart from the site being down, of course) is that the cooperative association for internet data analysis, CAIDA, an independent organisation that provides tools and analyses for the Internet infrastructure found that the SCO webserver had indeed been subjected to a DoS attack.

The trouble is that when two sides are operating from such entrenched positions, it is difficult to come to any firm conclusions. Certainly, the degree of animosity towards SCO from the open source adherents has reached a fever pitch in the past few weeks – it’s come to the situation where if a Linux programmer had one bullet and had Bill Gates and (SCO CEO) Darl McBride in front of him, it would be a difficult choice whom to shoot.

But let’s try to untangle some of the claims and counter-claims.

McInerney’s original statement on Groklaw was that SCO’s claim that, "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,” was nonsensical.

He pointed out that if SCO’s bandwidth was consumed, then any servers nearby would also be inaccessible. “That is, has the IP address of and has the IP address of so the two servers are side by side, probably even on the same physical network hub/switch…Unfortunately for SCO, from Australia, is highly responsive.”

But McInerney is mistaken: DoS attacks don't necessarily saturate the network bandwidth - you only need a few thousand packets to bung up the incoming connection queue on the average IP stack. So it's perfectly believable that one machine might be getting DoS'ed but everything else is behaving OK.

But, we can go further than that. The Groklaw article appears to miss a trick. If these machines are both behind the same firewall (which their consecutive IP addresses suggest to be the case) it is actually the firewall itself that is being subjected to the DoS attack - it's the firewall's IP stack that is getting its connection queue filled up. So if there was an attack coming in from outside, one would expect all services to be inaccessible, not because of bandwidth saturation but because the firewall was being DoS'ed.

The case for the defence of SCO is supported by CAIDA when it reported that the UCSD Network Telescope began to receive backscatter traffic indicating a distributed denial-of-service attack against the SCO Group. Early in the attack, unknown perpetrators targeted SCO's web servers with a SYN flood of approximately 34,000 packets per second.

In addition, the attacker(s) began to attack SCO's ftp (file transfer protocol) servers in addition to continuing the web server attack. Together and experienced a SYN flood of over 50,000 packets-per-second. The CAIDA website reported that “In spite of rumors that SCO has faked the denial-of-service attack to implicate Linux users and garner sympathy from its critics, UCSD's Network Telescope received more than 2.8 million response packets from SCO servers, indicating that SCO responded to more than 700 million attack packets over 32 hours”. CAIDA’s conclusion is that such an intensity of an attack demonstrated that this could not have been faked.

All this is true of course, but one thing that CAIDA cannot comment on is the provenance of those attacks. Although the server was bombarded with packets, what’s there to say that those packets didn’t emanate from SCO, or a party friendly to SCO?

Nothing at all, although it must be said that such an action is unlikely. There is no evidence whatsoever that SCO initiated the attacks themselves. A more plausible option is that SCO accidentally ‘on purpose’ left the backdoor open, while there was no protection against a DoS assault. It’s true that there is an easy way to do this. On a Redhat or fedora box you add the following into /etc/sysctl.conf net.ipv4.tcp_syncookies=1

Not all Linux distros use /etc/syscrtrl.conf but you can turn it on any Linux by enabling syn_cookies in the /proc virtual filesystem. However, while this is a useful tool, it does not stop all attacks so to claim that there is a way to do so is, at best, disingenuous and, at worst, rabble-rousing.

That’s not to say that SCO’s reputation is completely unsullied. If not guilty of faking an attack on itself, it’s at least guilty of appalling negligence. If there is little evidence to suggest that SCO has perpetrated an attack on itself, there’s plenty to suggest that the company was aware that it could hacked into (and indeed, given the number of enemies that SCO had, was likely to be).

There is another element of the attack that is worth thinking about. If SCO is receiving 34,000 packets a second this is about 18Mbit/s of traffic (assuming 68-byte packets, the minimum with IP). Because the connection setup packets are likely to have no payload, they're likely to mostly be small packets of this type. In a DoS attack (as opposed to a DDoS attack) you would expect all packets to have the same sender address, which they do in this case. This leads to the conclusion that (a) the attacking machine had an Internet connection capable of sending at least 18Mbit/s. This does tend to suggest the DoS attack was not carried out by some lone herbert sitting in his bedroom but emanated from an organisation with some considerable resources.

But there’s something else strange. How come SCO could be brought down by such a low-level attack? One would expect an organisation like SCO to have an infrastructure that could handle more than 18Mbit/s. It’s certainly weird that that volume of bandwidth could bring SCO to its knees.

How do we sift through all this information? On balance, the evidence points to SCO knowing about the attack on itself and doing little, either deliberately or through incompetence. It’s not an edifying spectacle. How can we deduce that? Let’s assume that SCO has a firewall on its server farm Internet connection. Therefore the firewall's "outside" port (the one with its Internet connection) would be what gets attacked by the DoS.

If the firewall can identify DoS/DDoS attacks then it will know to reset connections immediately, and all services will stay up ELSE all services will be unavailable. This is contrary to the observation that some services were available and some weren't, but the latter observation would be consistent with an internally-originated attack.

If the perpetrator of the attack were outside SCO, there is at least an even chance that a router somewhere on the Internet between him/her and SCO's world would have spotted the spoofed addresses and blocked the connections. So, the obvious inference is that the perpetrator was at least known to SCO, even if there’s no evidence that SCO instigated the attack itself. But this is pure conjecture. There is nothing to tie SCO to this attack – and there probably never will be. When faced with a situation like this, it’s always best to go for the Occam razor approach – that the simplest explanation is the likeliest.

Of, if you prefer, that cock-up takes precedence over conspiracy. The trouble with that explanation is that it doesn’t show SCO in particularly good light. It’s a near Richard Nixon-defence. “I am not a crook” but I might be incompetent. With professionalism like that, there’s no need for someone to pull the trigger, SCO could screw it up for themselves. And no Warren commission needed.