SCO Not Lying About DoS Attack

Licensed2Hack writes "The Cooperative Association for Internet Data Analysis (CAIDA), part of the San Diego Supercomputer Center at the University of California, San Diego has an analysis of the recent DDOS on SCO.com. Netcraft also has more information in their article and analysis graphs. Seems SCO was hit with a 50,000 packet-per-second SYN flood peak, which yields approximately 20 Mb/s each way, or about the capacity of a DS3 line."

Comments

In other news...

[kirun]

...SCO Must Prove Existence Of Santa Claus in Thirty Days

Correct URL

[DavidMoore]

CAIDA Analysis of SCO DoS Please use this link, the other one goes to a slow XML server.

DS3 Line stats

[Lipongo]

The attack was just short of half a DS3 Line.

DS3 Line = 44.736Mbps for those of you who need a definition

Re:T1?

[man_of_mr_e]

No.

DS1 is the circuit either a T1 or E1 rides on. E1's are the european equivelent to at T1. DS1 is the raw circuit.

Re:Then please explain

[Zocalo]

Because only in el cheapo hosting can you make the assumption that two adjacent IPs are on the same switch. It's quite common for high capacity corporate sites to have a load balancer of some kind in front of them that redirects to other IPs that you never see. Some of the more sophisticated devices even fiddle the TTL and other settings so they are totally invisible and what appears to be a single IP could easily be a distributed cluster of servers in every continent of the globe.

Provided that the bandwidth to the load balancer did not get saturated in the DDoS, and the attack was targetted at a specific IP then it is perfectly possible for adjacent IPs to be fine. I and several others pointed this out as a possibility out in the original story and either got modded to oblivion or called idiots for it. C'est la vie.

denial is the most predictable of human emotions

[fw3]

First, by all means mod me down it's only /.

Yes, SCO are pretty low on the karma totem, however the 'experts' quoted on groklaw, as well as the far more numerous 'experts' who replied that yes they must be faking it .... were drawing their speculations on very little data.

If you cared to measure you sure didn't need to be CAIDA, many snort, pf and netfilter logs are showing the backscatter of this attack.

And to all the experts who've been holding that a large synflood is easy to fix by blocking the attacker IPs: get a fscking clue.

Both syn and bandwidth attacks use forged addresses children (which is why there is backscatter), each incoming syn is from a random IP, the ack goes to the forged addr, not the originator.

The best way I've seen to handle this involves sensors at enough upstream locations to measure the packet count ratio skewing which results. This isn't generally deployed

Now technically SCO could probably manage to forge that kind of data (just send out all the expected response traffic) but again there are enough sensor platforms out there now that such a deception would certainly be unmasked eventually.

Actually, it goes deeper than that

[klasikahl]

In fact... a lot of SYN attacks don't use comprimised hosts at all! They actually send the request to a bunch of computers that are just running webservers, that's all. They spoof the destination IP and change it to the IP of the target to be attacked and all those webservers (usually ~40,000) respond at once to the host, essentially knocking it offline. It's happened to me before. :P

So you can use even a secure (but not 100% properly configured) server to launch an attack with... Intersting stuff.

Re:Actually, it goes deeper than that

[anthony_dipierro]

They spoof the destination IP and change it to the IP of the target to be attacked and all those webservers (usually ~40,000) respond at once to the host, essentially knocking it offline.

That wouldn't really be a SYN attack, as the response packets would have SYN and ACK set. It would also be much easier to protect against, as these bogus SYN/ACK packets could be dropped. But most importantly, there wouldn't be any backscatter, and certainly not the backscatter that CAIDA was seeing.

So you can use even a secure (but not 100% properly configured) server to launch an attack with...

Improperly configured so as to be able to launch an attack isn't secure. But, I'm really not sure how you could configure a machine not to respond to HTTP requests, anyway. Fortunately, as I mentioned above, this type of attack is much easier to ignore than a true SYN attack.

Preventing SYN attacks using a Cisco router

[WolfTattoo]

I have no idea if SCO is using Cisco routers on their permiter, but I guess its not too unreasonable to assume this is a possibility. With a Cisco on the permiter, preventing a SYN attack requires all of 3 additional lines to the configuration. I'm guessing it also doesn't take too much more than this on any enterprise-class router.

Configuring a Cisco perimeter router to prevent SYN flood attack against web server:
(config)#access-list 151 permit tcp any host
(config)#ip tcp intercept list 151
(config)#ip tcp intercept mode intercept

With Intercept mode enabled, all incoming SYN are held by router which proxy-answers w/syn-ack. Won't forward to server if Ack not recieved.

http://www.cisco.com/en/US/products/sw/secursw/p s2 120/products_configuration_guide_chapter09186a0080 0b6f0e.html