www.groklaw.net/article.php?story=20031210163721614
SCO has reported that they are experiencing an attack on their servers. Groklaw has been flooded with information that indicates their story doesnt add up. The consensus of what I am hearing is: That it is probably not an attack. And that if what they are saying were true, SCO would be admitting to gross negligence. First, Im being told that Linux has a very simple preventative built in. CISCO routers can protect against SYN attacks too, I have been told, if properly enabled. I knew one of Groklaws readers is a security professional in Australia, so I wrote to him and asked if hed 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 Australias Department of Defense. More recently I was one of the senior designers/firewall/security experts at a company that manages Australias largest federal government-certified Internet gateway.
Before we show how silly this statement is, lets explain SCOs position. A SYN Flood attack is an attack that attempts to stop a server from accepting new connections. Its 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. Either you or one of the first two people can stop shaking hands so as to be able to accept the third persons handshake. In this instance SCO are claiming that thousands are doing something similar to their web server. Unfortunately if we look closer there are a few problems with this claim of SCOs. Patches to all Operating Systems that Im aware of, do exist to stop this sort of attack.
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. Further SCO States: The flood of traffic by these illegitimate requests caused the companys ISPs Internet bandwidth to be consumed so the Web site was inaccessible to any other legitimate Web user. If their bandwidth is consumed, then any servers nearby will also be inaccessible.
Well, even with patches, to successfully conduct a SYN flood you would tend to chew up available bandwidth anyway, which we arent 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. It looks to me like someone has accidentally kicked a cable out of its socket or similar.
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 logs for incoming addresses that are trying the SYN attacks is fairly easy. 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?
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. I did not see any indication of an DoS of any type, but I was willing to give them the benefit of minor doubt. 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. These tools called syn_cookies are routinely applied by all sites that are even moderately concerned about basic security, and this is why we dont hear about eBay or Yahoo!
Others confirm that the ftp server was up and accessible from the US as well. This wouldnt 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. 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.
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 youre under attack. Is their ISP so incompetent it cant prevent and/or handle a SYN attack? 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.
I suggest you avail yourself of the vast array of of volunteer expertise that is ready to help any user of a Linux system. UPDATE 12/12/03: I found a CAIDA report which gives strong support to SCOs 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.
Other headlines took the DDoS attack story at face value and ran with it. May I suggest that when dealing with a claim that comes from SCO that you may wish to verify the claim before writing the story? So either SCO did not suffer from an attack today, or if they did it didnt match the symptoms that we all noticed, and would imply gross incompetence on SCOs part even if it were true. In either case, wouldnt that have made a much more compelling story to write, rather than just passing along SCOs press release information? Now that you have some excellent information posted here, and solid leads to follow up on, what will you do, journalists?
There are many explanations for this, but most include some duplicity on someones part. Personally, my favorite explanation is that, assuming that they have a colo at X0, that while doing remote administration, whoever was doing the administration fouled it up badly enough to not be able to get back into the box as root. In order to not look bad in front of the boss, she/he then lied to the boss about what has happened, and why they are suddenly down. It is much like the errors one can make when adjusting a systems firewall rules. It is entirely possible to remotely set them so that you thenceforth cannot administer the box remotely. The other explanations are not as benign as what I just described!
Cisco routers do NOT by DEFAULT stop SYN attacks or any other kind of DOS/DDOS attacks, access-lists must be manually configured to do this, and then, only for specific IPs you cant just say, stop SYN floods and nothing else, you actually have to specify the source or destination IPs. Since most of these types of attacks are spoofed come from forged source addresses, its usually necessary to filter on the destination, and this can be done quite easily. However, theres another issue, even with modern Cisco routers, the latest OS called IOS, or any other system, like Linux, BSD, whatever, they are all vulnerable if you can call it that to SYN flood, DOS or DDOS attacks, if not properly configured. Take any system, dump it on the net unprotected out of the box and see how quickly you get hit.
My point is that the releasers of this explanation may or may not know what happened. Assuming that the fine folks at SCO are forthright, then having an incompetent/dishonest employee is a simple explanation, whethe...
|
http://csua.com/feed/