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

Gear

Groklaw Gear

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


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
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.


  


Security Experts Doubt SCO Was Attacked as Claimed | 797 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Hackers help SCO restore web server!
Authored by: miss_cleo_psy4u on Wednesday, December 10 2003 @ 09:01 PM EST
Wouldn't the above be a great title of a news article?

Or:

SCO faking DOS attacks to make Linux community look bad!

[ Reply to This | # ]

The thrill of locking onesself out of a colo.
Authored by: freeio on Wednesday, December 10 2003 @ 09:01 PM EST
There are many explanations for this, but most include some duplicity on
someone's 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 system's 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!

---
73 de w4ti

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: cat_herder_5263 on Wednesday, December 10 2003 @ 09:12 PM EST
Can a qualified expert write a concise, layman's terms explanation of why The
SCO Group's accusations are false and release it to the media sources that
printed the sensational stories?

The SCO Group are getting a lot of favorable media attention from this.

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: Beyonder on Wednesday, December 10 2003 @ 09:13 PM EST
I too don't buy BS's BS.

before I begin, I'd like to clear up something, just so we don't mislead
readers. 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 can't 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), it's usually necessary to filter on the destination, and this can
be done quite easily.

However, there's 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. Might
as well put up a big neon sign saying "hack me!".

I'd like to note that another router company called "Foundry"
(which make far superior products to Cisco, at lower prices!) actually have
built-in command functions to specifically block DOS/flood type attacks. hrm,
someone was actually THINKING the day they decided to add those features. Yes,
that's right, no access-list, no twiddling, just a nice simple command to limit
this kind of stuff. Specifically designed for such occasions.

Whether it's a SYN flood or not doesn't really matter in the greater scheme of
things, as latency would show up, and it's not. What's latency? well, high
latency means the network is real real slow. And that's just not the case
here.

ftp.sco.com is performing rather normally, humming along without a hitch. If
there were an attack of DOS or DDOS, SYN or otherwise, we'd see the ftp being
slow, and it's not.

So to sum it up, as the main comment said, there is NO evidence that a SYN
attack, or any other type of DOS or DDOS attack is taking place.

Nope, I don't buy SCOs FUD...

[ Reply to This | # ]

Incompetence more likely than malice
Authored by: freeio on Wednesday, December 10 2003 @ 09:14 PM EST
Yes, I know what the press release said. 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, whether that employee is a sysadmin or not.

The less benign explanations involve deception at a much higher level than a
lowly sysadmin.

---
73 de w4ti

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: Anonymous on Wednesday, December 10 2003 @ 09:27 PM EST
When I first read their report that claimed a SYN flood, I almost fell off my
chair laughing. The claim of clobbering their bandwidth might have been true if
there server was dedicated to a ..um... dial up line, but probably even that
would be suspect. As this article points out, SYN flood... oh yeah... how
quaint. And ancient. And for most of the internet-connected world, ignorable,
or at least immediately controllable.

Their claim that their internal services were kaput as a result gave me even
greater rise, because that would mean that their internal services were exposed
on public addresses.

When I then heard that other addresses on the same subnet were available, I just
laughed harder. Such a great technology company they are, eh? As Bugs Bunny
would say... "what an ultra maroon"

...D

[ Reply to This | # ]

The SYN ate my homework
Authored by: Anonymous on Wednesday, December 10 2003 @ 09:29 PM EST
Shurely they aren't planning on using this as an excuse to avoid compliance
with the court, are they?

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: valdis on Wednesday, December 10 2003 @ 09:36 PM EST
I've been doing computer security for about 2 decades, and the only thing I can
say is...

If SCO really *was* the victim of a sucessful SYN-flood attack, they have *NO*
excuse.

http://www.sans.org/dosstep/roadmap.php

You'll notice that I helped write that almost 4 years ago, at the request of
SANS and the White House, in reaction to the DDoS attacks on Yahoo and other
places by so-called
"MafiaBoy". And even then, the only technically interesting thing
about MafiaBoy was that he had managed to collect a network of 800 to 1000
"zombie" machines infected with a Trojan program that let him launch
the attack.

In contrast, these days somebody with only 10,000 zombies is still a
"wannabe", 100K zombie nets are not uncommon, and nobody batted an
eyelash at a Polish spammer group that claimed to have 450K zombies.

As others have noted, SYN-floods are generally considered to be so
been-there-done-that as to be uninteresting except when they actually manage to
work. Real production sites should be taking steps to harden themselves against
the sort of attack a 100K zombie network can launch (yes, you too can suddenly
find 5 million packets/second trying to reach your site...)

[ Reply to This | # ]

Synflood clarificatiom
Authored by: Anonymous on Wednesday, December 10 2003 @ 09:38 PM EST
Synfloods don't really use a significant amount of bandwidth in most cases.
And, yes, despite such kernel features as syncookies, Linux systems can still be
susceptible to these attacks. Saw one attacking a shared web hosting box at the
ISP where I work NOC duty just last week. Some IP registered to the Army of
Slovakia attempted to open 480+ simultaneous connections. Went away after a few
minutes, but if it had persisted another minute I would have had the netengs
block the offending IP at our border routers. Now if it had been a distributed
attack with many source IPs, that could have been more difficult, but those
sorts of attacks are typically involve more traffic and would probably just be
raw UDP packets or big ICMP pings (since they'd be coming from involunatary
zombies, those attacks would have more bandwidth at their disposal and no likely
consequences for the originator).

[ Reply to This | # ]

Ways to investigate further now
Authored by: gdt on Wednesday, December 10 2003 @ 09:39 PM EST

People looking into the matter now should note that SCO seems to have asked its ISP to block web traffic to www.sco.com. The ISP seems to have done this at their network edge.

For example,

tcptraceroute www.sco.com

from Australia results in an ICMP Host Unreachable from the entry into X0.net in Palo Alto.

As a result, looking into the situation now is too late.

Most ISPs will only insert filtering upon customer request, and then only for a limited time. Many ISPs will look into the customer complaint first -- many "DoS attacks" reported to us are actually customer misconfiguration. It would be interesting to see XO.net's fault tracking system log for the incident.

A traceroute, and especially a firewall-penetrating "tcptraceroute", from before the ISP added the filters would be most useful in determining the cause of SCO's outage.

The lawyers might also want to note that DDoS attacks leave administrative by-product. Firstly, many ISPs use NetFlow records for billing or network monitoring purposes. These would show both DDoS and Syn attacks. The records may not be kept for a long time in the ordinary course of the ISP's business, as there is a lot of them. Further, there will be matching records at ISPs connected to XO.net (in case XO.net does not keep NetFlow records).

For a DDoS attack any of the largest 100 ISPs should have NetFlow records showing the attack (does IBM own an ISP?). This won't be so for a Syn attack.

Secondly, many networks are billed on "incoming traffic" or "95th percentile" contracts. A DoS attack is then visible in the ISP's accounting data, although a Syn attack is not. SCO would usually be sent a summary of the accounting data with their monthly bill.

Regards, Glen
a confused Network Engineer at an offshore ISP which is about 1% of the Internet

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: thinkliberty on Wednesday, December 10 2003 @ 09:39 PM EST
Doing a search on .sco.com on netcraft show that the following are up:


http://elearning.sco.com/
http://ir.sco.com/
http://register.sco.com/(But it gives a Forbidden page)

Why can't they filter and redirect according to ip adddress range ? 0 -
200.0.0.0 Go to 1 server 200-400 go to another, should be easy to filter it out
from there. while most of the net remains able to reach your website.

There were more .sco.com websites but I didn't check them all.

This DDOS claim is really lame.

[ Reply to This | # ]

Is This Intended to Become a Press Release??
Authored by: brice on Wednesday, December 10 2003 @ 09:41 PM EST
I've been following this all day and I think all the netadmins here are GREAT!

BUT... if this is intended to be a draft for some press release it is still too
technical to get any mainstream play. I mean this as sincereset constructive
criticism.

Do we have any gifted technical writers lurking around here? This is your
chance.

If there is solid bulletproof evidence that SCO is telling a stretcher then I
think the goal should not be to convince the techies - they are a minority in
the investment world. The goal I think should be to catch the imagination of the
broadest possible audience. I don't think we should count on journalists to
rewrite the story for us.

Unfortunately I am not a great tech writer. I only have my opinion to give.
Sorry!

I really like the explanation of SYN/ACK with human handshakes! I hope there are
equally friendly ways to explain the other salient points.

How bout "SCO: Attack? or Looking for Attention?"
-brice

[ Reply to This | # ]

Lets call the Law Enforcers!
Authored by: Whiplash on Wednesday, December 10 2003 @ 09:42 PM EST
So SCO are saying that they called in "Law Enforcement" to catch
these hippy commie anti-profit evil people.

Can we verify that? Someone want to ring the FBI or the Salt Lake police or
whoever?

I bet nobody has heard *anything* from SCO.

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: Anonymous on Wednesday, December 10 2003 @ 09:43 PM EST
I hate to add support to sco's story, but the analysis posted isn't
necessarily accurate.

First: it is possible for two machines, with adjacent IP addresses, to be in
completely different parts of the world. For example, you can have a
couple dozen machines with the IP address 1.2.3.4, place each of them
at various exchange points, and then announce a /32 route for that IP
address. That route announcement won't get carried very far, but the
local routers will be configured to recognize it.

In this case, I did a traceroute from my system to both www.sco.com and
ftp.sco.com, and got different routes.

Going to www, it hit 63.210.199.9, then 64.159.2.44, then
209.244.13.246, and that's as far as it got before I stopped it. Going to
ftp, however, it went 63.210.199.9, then 64.159.2.108, then
209.244.13.242, then 209.245.146.234, then 65.106.5.177, and went
on a few steps more.

So what does that mean? To be honest, I can't really say, because I don't
know the topology of SCO, Level3, or xo.net's networks. But it does tell
me a different route was being taken for two differnet IP, yet adjacent, IP
addresses. There are lots of reasons this can happen, including simple
load sharing, deliberate layout, accidental layout (aka "oops!"),
and an
outage.

And if the machines are colocated at the exchange point, then it would
still be possible to kill one without killing the other, provided they were
on a switch, and the total inbound bandwidth of the attack exceeded the
bandwidth of each segment of the switch.

But, again, I don't mean to add support to SCO; this is the fourth time
they've claimed this, and the evidence does seem pretty weak in general.
If they were a trustworthy company, I might be more sympathetic, but
they've lied far too often to take them at face value.

Sean.

[ Reply to This | # ]

SYN attack explanation
Authored by: mflaster on Wednesday, December 10 2003 @ 09:45 PM EST
Just to try to give a brief, simple-minded explanation of SYN attacks.

In order to open a connection to a web server (or any internet resource), you
send a SYN packet, which is essentially a "hello".

The web server responds with an "OK, please proceed", sent to the
return address specified by the "hello" message. The web server
needs to reserve some resources to handle the connection at this point.

The problem is that in a SYN attack, the "hello" has a fake
(possibly random varying) return address. The server sends the "OK,
please proceed" off to Lithuania or wherever. It doesn't get an answer,
so it sends "OK, please proceed!" again... And again... From a
Microsoft site (the first thing that I saw), the default configuration is that
it will keep retrying for a total of 189 seconds - which is essentially an
eternity, as these resources are reserved for this connection for that whole
time. Essentially, this means that someone with even a 56k modem can take down
any web site that doesn't pre-allocate large amounts of resources that are
needed in SYN attacks.

Mike

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: neilplatform1 on Wednesday, December 10 2003 @ 09:45 PM EST
SCO is a sister company of Center7, who have offices nearby in Lindon
Utah, and who are supposed to be hosting experts. They should certainly
know how to stop this kind of attack.

To have this happen to you once is unfortunate, twice is careless, three
times is just incompetent, or highly suspicious.

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: belzecue on Wednesday, December 10 2003 @ 09:54 PM EST
IBM should add SCO's ISP to their subpoena list. Immediately seeking an
affidavit from the ISP as to what is going on with all these alleged attacks
would be nice, too.

Let's see SCO spin it when their own ISP admits that the recent two 'attacks'
never happened.

[ Reply to This | # ]

More Technical data
Authored by: LinuxLobbyist on Wednesday, December 10 2003 @ 09:54 PM EST

PJ: I didn't see this covered by Steve McInerney or an others you cited, so I figured I'd give this little tidbit of information.

I have now tried doing a traceroute to both ftp.sco.com and www.sco.com from three different locations on the Internet. One from a Speakeasy DSL, one from a Comcast cable modem, and one from a Conversant DSL connection.

The Speakeasy DSL connection goes through Verio before it hits XO, Comcast goes through AT&T before hitting X0, and Conversant goes through Qwest before hitting X0. In all three cases, the traceroute stops dead and doesn't even show an X0 IP addresses when trying to get to www.sco.com, but when trying to get to ftp.sco.com, at least 7 XO IP addresses are traversed.

What I'm saying here is that it appears that packets trying to get to www.sco.com are blocked at the entrance to XO. There may still be a problem with the www.sco.com box itself, but there's no way to tell since packets destined for that address aren't even getting through XO's network. Could it be that XO has somehow messed up?

I'm not a network admin, I'm more of a system admin, so please, if you are a network admin, feel free to correct me if I'm misinterpreting something. If anyone's looking for it, I can post or email my traceroute results.

---
Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: Anonymous on Wednesday, December 10 2003 @ 10:10 PM EST
From internetnews.com:
Officials at the SCO Group (Quote, Chart) said a Denial of Service (define) attack took down its Web site at 4:20 a.m. Wednesday, and will remain inaccessible for at least the next 12 hours. The breach also took out its customer support and e-mail service.
Lets see here. They don't know who it is, but they do know how long it will last? Something's rotten in the state of Denmark.

[ Reply to This | # ]

I think this is intentional...
Authored by: cfitch on Wednesday, December 10 2003 @ 10:11 PM EST
Why? SCO needs new PR. Considering the events of the last week or so, SCO and
McBride have not had much to prop up the stock price.

As such, they could have very well pulled the "Let's call our standard
downtime maintenance a DDOS attack perpetrated by commie Linux users" PR
stunt in an effort to show the world how evil Linux users are.

Given how things are going, I would not put it past SCO to pull something like
this.

Just my opinion.

[ Reply to This | # ]

SCO: Incompetent or Lying. Which one?
Authored by: jmccorm on Wednesday, December 10 2003 @ 10:16 PM EST
This is a repost of my private forum comments. I think this spells out the other
side of the equasion. [Feel free to take ideas/comments with or without credit
and use them for yourself in whatever forum or medium.] Assume that SCO isn't
lying about the hacker attack. Let's assume that SCO has told us the truth!

I can't think of a situation which discredits an IT company much more than this
one. I mean, let's look at this from the 1000ft perspective.

They're an OS manufacturer. But they can't keep their server online, allegedly
because of a very old TCP/IP vulnerability which has been addressed in just
about every modern OS. (Including the one they appear to be running in their
own
web server, Linux.)

Their secondary product line has to do with web solutions. But they can't even
keep their own web server up and running.

They claimed to have been the victim of denial of service attacks in the past
(most recently in August), yet apparently, they were not capable of implementing
an enterprise grade firewall/connectivity solution.

Their executives claim they're being attacked, and in what appears to be a
first, their credibility is called into question!

Do you want THEM supporting YOUR business? Its no wonder that their only avenue
left is to sue for profits. They're incompetent in their own core business! How
sad is that?

[ Reply to This | # ]

SCO.com down, IR.SCO.com, end of story.
Authored by: Anonymous on Wednesday, December 10 2003 @ 10:22 PM EST
SCO.com is down, yet SCO's investor relationship site, ir.sco.com is up.

[ Reply to This | # ]

My personal theory on what happened.
Authored by: jmccorm on Wednesday, December 10 2003 @ 10:23 PM EST
Early in the morning, they found that someone hacked into their web server (as
in, obtained full root access). (No doubt, from a lack of correct security
precautions.) Immediate response? They shut down the entire network to the
outside world. (Explains email and everything else being gone.)

They did an internal survey of their systems and seemed, after some time, to be
confident that the break-in was limited to their web server. The web server was
pulled off of their internal network, and they restored their network's
connectivity to the Internet. "Internal mail and other services restored,
but the web server is under a Denial of Service attack."

And you may remember the "we expect the server to be back up in twelve
hours" quote given to one news outlet? "It'll take at least twelve
hours for us to restore a backup copy of the web server and get it set
up."

People tell me I'm part psychic. I just think that I can pierce through some of
the front-end bullshit and glimpse at what is going on at the other side.

PS: Calling it a "denial of service attack" is creative, but
technically somewhat correct. It just gives the wrong impression. Follows
exactly the kind of statements we continue to see from SCO executives.

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: hprx on Wednesday, December 10 2003 @ 10:35 PM EST
Wow. Maybe SCO should hire someone from this site to do their network admin.
I've never seen this many traceroutes in my life. Next time I need one, I'll
know where to post. :D

Correct me if I'm wrong, but is a SYN flood attack even possible nowadays?
IIRC, the BSD kernels just drop random syn connections when all the ports are
full, and I think the Linux 2.2 (maybe 2.0) kernel implemented SYN cookies so
they allow any amount of syn connections. And SCO's machine was running
Linux/Apache, right? Anyone know the default value of
/proc/net/ipv4/tcp_syncookies? Does any of SCO's blathering's make any sense
at all?

[ Reply to This | # ]

Genius, Incompetence or Flatulence
Authored by: mrallen on Wednesday, December 10 2003 @ 10:36 PM EST
It is highly suspect that a company who's web site was felled by an
ancient and easily defended 'attack' was able to so expertly and swiftly
identify the cause in time to write up and distribute a press release
before the close of business.

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: Anonymous on Wednesday, December 10 2003 @ 10:43 PM EST
Ha ha ha ha ha ha ha ha ha !!!! Ho ho ho ha ha ha hee hee hee. The Dum and
dummer duo have nothing on these guys!
Ha ha ha ha ha ha ha ha !!!!1

[ Reply to This | # ]

Did you notice
Authored by: mac586 on Wednesday, December 10 2003 @ 10:51 PM EST
Did you notice how quickly our attention was drawn away from the contingency
discussion?

What more could SCO be hiding if they felt compelled to use the DDoS trump card
to divert everyones attention?

Or are they trying to rescue the stock price which has fallen significantly
since Friday?

[ Reply to This | # ]

  • Did you notice - Authored by: pooky on Wednesday, December 10 2003 @ 10:59 PM EST
  • Stock Prices - Authored by: Anonymous on Thursday, December 11 2003 @ 09:34 AM EST
SCO's bandwidth is NOT flooded
Authored by: pooky on Wednesday, December 10 2003 @ 10:53 PM EST
It might be possible to put to adjacent IPs in the same range on opposite sides
of the world, but unless you were actively moving a host physically from one
location to the other, why would you do it?

In any event this argument is moot. I have run multiple traceroutes from 2
different ISPs and I get the same border router for both systems. They are on
the same subnet, period.

Tracing route to www.sco.com [216.250.128.12]
over a maximum of 30 hops:

1 5 ms 5 ms 7 ms 10.36.192.1
2 7 ms 5 ms 6 ms srp4-0.clmboh1-rtr2.columbus.rr.com
[24.95.81.143]
3 7 ms 5 ms 5 ms srp10-0.clmboh1-rtr4.columbus.rr.com
[65.25.129.100]
4 8 ms 7 ms 7 ms srp5-0.rdcoh-rtr2.columbus.rr.com
[65.25.129.102]
5 10 ms 9 ms 9 ms son0-1-1.mtgmoh1-rtr0.cinci.rr.com
[65.25.128.225]
6 10 ms 9 ms 11 ms pop1-cin-P2-0.atdn.net [66.185.133.5]
7 10 ms 9 ms 11 ms bb1-cin-P0-0.atdn.net [66.185.133.0]
8 16 ms 17 ms 17 ms bb1-chi-P3-0.atdn.net [66.185.153.50]
9 17 ms 17 ms 18 ms pop2-chi-P0-0.atdn.net [66.185.148.65]
10 32 ms 31 ms 32 ms XO.atdn.net [66.185.132.106]
11 33 ms 31 ms 31 ms p5-0-0.RAR1.Chicago-IL.us.xo.net [65.106.6.133]
12 50 ms 49 ms 50 ms p6-0-0.RAR2.Denver-CO.us.xo.net [65.106.0.25]
13 48 ms 50 ms 49 ms p0-0-0-2.RAR1.Denver-CO.us.xo.net [65.106.1.81]
14 61 ms 62 ms 62 ms p4-0-0.MAR1.SaltLake-UT.us.xo.net [65.106.6.74]
15 61 ms 62 ms 61 ms p0-0.CHR1.SaltLake-UT.us.xo.net [207.88.83.42]
16 205.158.14.114.ptr.us.xo.net [205.158.14.114]reports: Destination net
unreachable.

Trace complete.

Tracing route to ftp.sco.com [216.250.128.13]
over a maximum of 30 hops:

1 6 ms 5 ms 6 ms 10.36.192.1
2 5 ms 5 ms 7 ms srp4-0.clmboh1-rtr1.columbus.rr.com
[24.95.81.129]
3 6 ms 5 ms 6 ms srp10-0.clmboh1-rtr3.columbus.rr.com
[65.25.129.99]
4 9 ms 9 ms 9 ms son0-1-2.mtgmoh1-rtr0.cinci.rr.com
[65.25.128.229]
5 9 ms 10 ms 9 ms pop1-cin-P2-0.atdn.net [66.185.133.5]
6 11 ms 11 ms 11 ms bb1-cin-P0-0.atdn.net [66.185.133.0]
7 17 ms 15 ms 15 ms bb1-chi-P3-0.atdn.net [66.185.153.50]
8 17 ms 15 ms 15 ms pop2-chi-P0-0.atdn.net [66.185.148.65]
9 32 ms 31 ms 30 ms XO.atdn.net 66.185.132.106]
10 32 ms 32 ms 31 ms p5-0-0.RAR1.Chicago-IL.us.xo.net [65.106.6.133]
11 56 ms 49 ms 49 ms p6-0-0.RAR2.Denver-CO.us.xo.net [65.106.0.25]
12 49 ms 47 ms 48 ms p0-0-0-2.RAR1.Denver-CO.us.xo.net [65.106.1.81]
13 61 ms 60 ms 61 ms p4-0-0.MAR1.SaltLake-UT.us.xo.net [65.106.6.74]
14 60 ms 61 ms 62 ms p0-0.CHR1.SaltLake-UT.us.xo.net [207.88.83.42]
15 67 ms 67 ms 65 ms 205.158.14.114.ptr.us.xo.net [205.158.14.114]
16 * * * Request timed out.

The last hop fails because SCO is blocking ICMP requests from reaching this host
or blocking it from responding to the requests. ICMP Echos (pings) don't work
either.

The last router to www.sco.com, the one that reports the host is unreachable, is
205.158.14.114. The last router before the trace to ftp.sco.com dies is
205.158.14.114. They have the same number of hops from my location.

Both IPs are on the same physcial network, proof positive.

-pooky

---
IANAL, etc...

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: Scriptwriter on Wednesday, December 10 2003 @ 10:58 PM EST
Excellent work in putting this together, PJ. Now let's hope that this story
gets as much play as the "Woe is us, we're being attacked" stories
that came out of Lindon earlier today.

---
The clock is ticking, SCO. January 9th. Tick. Tock. Tick. Tock.

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: Anonymous on Wednesday, December 10 2003 @ 11:07 PM EST
I'm doing my best not to snicker.
We've been through this before.
Hasn't anyone told SCO not to repeat their acts ?

[ Reply to This | # ]

More information
Authored by: pooky on Wednesday, December 10 2003 @ 11:18 PM EST
NFT is the hosting provider, here's the ARIN output for the IP range SCO's web
server is in:

OrgName: NFT
OrgID: NFT
Address: 333 S 520 W Suite 300
City: Lindon
StateProv: UT
PostalCode: 84042
Country: US

NetRange: 216.250.128.0 - 216.250.143.255
CIDR: 216.250.128.0/20
NetName: CENTER7-BLK
NetHandle: NET-216-250-128-0-1
Parent: NET-216-0-0-0-0
NetType: Direct Allocation
NameServer: NS1.CANOPY.COM
NameServer: C7NS1.CENTER7.COM
NameServer: C7NS2.CENTER7.COM
NameServer: C7NS3.CENTER7.COM
Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
RegDate: 1999-11-04
Updated: 2002-05-19

TechHandle: ZC206-ARIN
TechName: Canopy Group
TechPhone: +1-801-229-2223
TechEmail: POC@canopy.com

# ARIN WHOIS database, last updated 2003-12-10 19:15
# Enter ? for additional hints on searching ARIN's WHOIS database.

Oooh look, it's Center7! They must have multiple uplinks to the Internet, they
were allocated the CIDR block by ARIN.

It looks like they may be AS13951. According to what I can find, AS13951
borders with the following providers:

ViaWest AS13649 (recognize that from the Canopy company page?)
Sento-Corp AS26069 (not sure who this is exactly, not on Canopy page anyway)

I don't see XO in this list? Interesting.

The contacting formaiton for AS13951 points to www.nft.com, Noorda Family
Trust.

-pooky


---
IANAL, etc...

[ Reply to This | # ]

If it's a hoax...
Authored by: Anonymous on Wednesday, December 10 2003 @ 11:29 PM EST
Question: Since the alleged Denial of Service attack would be considered a
criminal act, if it in fact was a hoax perpetrated by SCO management, could that
expose them to criminal liability?

[ Reply to This | # ]

  • SCP get a life - Authored by: Anonymous on Thursday, December 11 2003 @ 05:59 AM EST
  • If it's a hoax... - Authored by: Anonymous on Friday, December 12 2003 @ 09:32 AM EST
  • If it's a hoax... - Authored by: Anonymous on Friday, December 12 2003 @ 09:33 AM EST
SCO.COM down now as well.
Authored by: Anonymous on Wednesday, December 10 2003 @ 11:30 PM EST

Just did a check here, approximately 11:24pm EST, I am getting a time out when I attempt to reach http://www.sco.com.

Their press release said it was down for about 12 hours?

I did have a chance to check it after their "12 hours of outage" from their "start" time of about 4:30am PST(?).

Either it never came back up at all (yet) or it did for a brief period and it was taken back down.

I also tried their FTP site, and experienced a time out there.

Not sure what this means yet. Will try again after some badly needed sleep. :)

Regards,

Fredrick

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: Anonymous on Wednesday, December 10 2003 @ 11:40 PM EST
http://www.theage.com.au/articles/2003/12/11/1071086170827.html

A link to an article which picks up on the doubts over whether this attack is
fictional or not.

[ Reply to This | # ]

Is any of this relevant now?
Authored by: Bright Red Fish on Wednesday, December 10 2003 @ 11:43 PM EST
All this analysis is very nice, and interesting to boot. But I don't think
it's relevant to any of the current legal cases. It may become important in
some future investigation of SCO Group's PR campaign to pump their stock, but
this has little or nothing to do with their lawsuit against IBM, or IBM or Red
Hat's legal claims against SCO.

The current cases will (I hope) be decided based upon the claims being made in
court, and the evidence presented. Attacks upon SCO's network, real or not,
have no bearing upon the provenence of code in Linux, the contractual
obligations between SCO and licensees, or SCO's threatened litigation against
Linux distributors and users. SCO's servers being up or down matters little
within the context of the cases at hand. They may try to make it relevant, but
it doesn't relate to any case they're involved in now. They are just playing
martyr, and trying to put the blame on their legal opponents.

That said, I must admit to a bit of schadenfreude, along with everyone else
here.

And yes, I enjoyed the opportunity to use schadenfreude in a sentence :)

[ Reply to This | # ]

OR - SCO is just to DUMB to know how to replace a NIC
Authored by: Anonymous on Wednesday, December 10 2003 @ 11:45 PM EST
A bad NIC card can be a problem in more ways than just one!

Has SCO checked it's own hardware first?

or, maybe someone internal to SCO likes to cry Wolf every time that he or she
runs into a problem that this person can not solve? There are those who like to
do this type of thing to prove to their boss that they solved the problem
(proving to their boss that they are the man or woman for the job), sic? If
this is the case than SCO needs to hire a shrink for everyone from the top of
the company down to the admins...!


[ Reply to This | # ]

Darl's Other Brother Runs IT?
Authored by: Anonymous on Wednesday, December 10 2003 @ 11:45 PM EST
Well, I guess if Darl's brother is running his legal campaign, does he have
another one who runs SCO's network?

[ Reply to This | # ]

  • No, same brother - Authored by: Anonymous on Wednesday, December 10 2003 @ 11:48 PM EST
    • No, same brother - Authored by: Anonymous on Friday, December 12 2003 @ 04:59 PM EST
Out of the mothballs
Authored by: Tim Ransom on Wednesday, December 10 2003 @ 11:53 PM EST
Didn't they get the memo?


- 4 years ago?

[ Reply to This | # ]

Clarifications and a correction
Authored by: Anonymous on Thursday, December 11 2003 @ 12:02 AM EST
We denounce SCO for innacurate and misleading statements so let's extra hard
not to do that :)

Fist off, distributed packet floods and TCP SYN attacks are not mutually
exclusive. Certainly SCO's whole Internet connection would be affected by a
packet flood so that can be ruled out. But it is misleading to make a dichotomy
of the two attacks. All packet floods are DoS attacks. SYN floods are DoS
attacks. Packet floods can be initiated from many simultaneous sources which
would make them DDoS attacks.

Secondly you can't just add IP filtering rules to fend off SYN attacks in most
circumstances. If it is a DDoS SYN attack you certainly can't: the packets
will come from hundreds or thousands of sources. In any case, the packets
usually have forged source addresses. Remember that most ISPs do not do egress
filtering. The packets are likely to come from a random distribution of
addresses over the entire 32bit range -- even if only one host is involved.

Thirdly (is that a word?), you didn't play up the internal separation enough.
It is nearly unimaginable for the public web server and the internal network to
be connected in any way that would allow a packet flood (SYN attack,
distributed, or otherwise) to affect the internal network.

[ Reply to This | # ]

Classic scam
Authored by: Anonymous on Thursday, December 11 2003 @ 12:04 AM EST
Now the important names attached to the case are shown to
be bogus, now the actual evidence is to be produced,
investors are getting very nervous, having been sold
swampland somewhere, what next?

A fire. A disaster. Oh how terrible. Our web site, with
all the unfortunate evidence against us, is gone.

Do a search for Bre-X, a scam that cost billions and
suckered those who should have known better. The parallels
so far are quite remarkable. They had a fire that
destroyed the suspect core samples.

Derek

[ Reply to This | # ]

SCO's Attack Story Hiding Changes to Website?
Authored by: jack199 on Thursday, December 11 2003 @ 12:19 AM EST
When there was an earlier "DoS attack" on SCO's site, a lot of
stuff which would have become embarassing to SCO just happened to
"disappear". They had used the DoS Attack as an excuse to make
changes in pages on the website so that the pages would appear to agree with
SCO's public pronouncements.

It would be interesting to compare the differences, if any, between SCO's site
before and after the "attack", if anyone is able to provide the
relevant data.


[ Reply to This | # ]

Groklaw in the press: Doubt on DOS claims
Authored by: pannomatte on Thursday, December 11 2003 @ 12:23 AM EST
Kudos
http://www.theage.com.au/articles/2003/12/11/1071086170827.html
Kind Regards
PJ for president !

[ Reply to This | # ]

Silver Lining
Authored by: Anonymous on Thursday, December 11 2003 @ 12:39 AM EST
"Your Honor, the problem is that we can't guarantee accuracy of the court
requested documents because our servers have been compromised."

"We are still dealing with the aftermath and our internal investigations
have revealed that source code, emails, and financial records have been
affected. We've got a team of crack mathematicians (yes, the same ones we used
before) and forensic experts working as fast as they can."

"Our publicly traded lawsu -- err exemplary corporation has been
victimized by those bent on its destruction."

[ Reply to This | # ]

Email reporters when you see something wrong.
Authored by: Anonymous on Thursday, December 11 2003 @ 12:41 AM EST
I have to post this top-level, to make sure y'all see it.

at the moment, there are stories on theage.com.au and smh.com.au both
pointing to groklaw, with headlines of:

http://www.smh.com.au/articles/2003/12/11/1071086170827.html

and

http://www.theage.com.au/articles/2003/12/11/1071086170827.html

the headline is "Doubts cast on SCO claims of denial of service
attack"

Now, about 2 hours ago they were just copy stories of the others,
mentioning that sco was hit by a denial of service attack - no link to
SCO, and no hint that SCO may not be entirely above board. I emailed the
reporter at the link, and very soon after the story had the extra info
added. This isn't just small beans either, but one of the biggest news
sites in australia!

Our comments to reporters DO matter. If there's something odd going
on and the whole story isn't being presented, write them and let them
know. Let them see the side of the story as groklaw has seen it, and let it
go mainstream.

Personally, I have no tech skills and couldn't tell if a DDoS attack is real
or not by the description, or even how to detect which is which, but I
trust there's enough people here who DO know.

I emailed, and the info got through. I suggest we all do the same for our
regions knowing that it CAN make a difference, like groklaw.net itself

:)

[ Reply to This | # ]

No Email...
Authored by: trox on Thursday, December 11 2003 @ 12:43 AM EST
It just hit me. Different from the previous problems they have had, I keep seeing that there Email is also down.

Most large companys have a seperate server for Email but it's nagging at me that this time they have no Email access.

Could it be an accident that today is the day they are to recieve IBM's want(wish?) list.

"Sorry you honor but some bad Open Source people kept us from reading our Email", and the dog ate what we were ready and willing to submit, and our MIT guy's got abducted by a UFO "Please can we have an extension untill July 2024???".

[ Reply to This | # ]

Ideas on news outlets to work...
Authored by: jmccorm on Thursday, December 11 2003 @ 12:57 AM EST
I don't have much time left. If anyone want to chase news outlets which have
already run the hack story, or news outlets who generally carry SCO stories, go
here:
http://news.google.com/news?hl=en&edition=us&q=sco&btnG=Search+News

You know, if Groklaw discovers the secret of the Press Release (or hooks up with
another group who already has), this would be a whole lot easier.

[ Reply to This | # ]

slashdot snookered
Authored by: mojotoad on Thursday, December 11 2003 @ 01:02 AM EST
Dang. slashdot took the bait.

I guess the dander will fly now.

:(
Matt

[ Reply to This | # ]

Ok Lets Look at this SCO just turn it off
Authored by: kb8rln on Thursday, December 11 2003 @ 01:37 AM EST

I sorry I try to get this formated right I need tables!

> DiG
9.2.3 > -t axfr @ns2.calderasystems.com sco.com
;; global options: 
printcmd
sco.com. 21600 IN SOA ns.calderasystems.com.
hostmaster.caldera.com.
2003120401 3 600 900 604800 21600
sco.com.           21600  IN NS
ns.calderasystems.com.
sco.com.           21600  IN NS
ns2.calderasystems.com.
sco.com.           21600  IN NS nsca.sco.com.
sco.com.  
        21600  IN NS c7ns1.center7.com.
sco.com.           21600  IN MX 10
mail.ut.caldera.com.
sco.com.           60     IN A  216.250.128.12
 
# This is
strange only 60 second what are they doing.
 
websco.sco.com.    21600   IN A
132.147.210.9
biz.sco.com.       21600   IN NS
ns.calderasystems.com.
biz.sco.com.       21600   IN NS
ns2.calderasystems.com.
biz.sco.com.       21600   IN NS
nsca.sco.com.
biz.sco.com.       21600   IN NS nsuk.sco.com.
biz.sco.com.      
21600   IN NS c7ns1.center7.com.
www1.sco.com.      21600   IN A 
132.147.210.9
athena.sco.com.    21600   IN A  132.147.210.43
www2.sco.com.     
21600   IN A  216.250.128.33
www5.sco.com.      21600   IN A 
132.147.210.9
gandalf.sco.com.   21600  IN A  216.250.130.49
docdev.sco.com.   
21600   IN A  132.147.210.51
localhost.sco.com. 21600 IN A 
127.0.0.1
ftpput.sco.com.    21600 IN A  216.250.128.33
projectudi.sco.com.21600
IN A  132.147.210.13
crm.sco.com.       21600 IN A  216.250.130.13
sco.sco.com. 
     21600 IN A  132.147.210.109
osr5.updates.sco.com. 21600 IN A
216.250.128.33
scoxweb.sco.com.      21600 IN A
216.250.128.220
*.scoxweb.sco.com.    21600 IN A
216.250.128.220
newintranet.sco.com.  21600  IN A 216.250.130.1
no.sco.com.     
     60     IN A 216.250.128.12
www.no.sco.com.       60     IN A
216.250.128.12
crmdev.sco.com.       21600  IN A 216.250.130.52
mx.sco.com.     
     60     IN A 216.250.128.12
www.mx.sco.com.       60     IN A
216.250.128.12
rohan.sco.com.        21600  IN A 216.250.130.32
piedra.sco.com. 
     21600  IN A 216.250.134.38
shadowfax.sco.com.    21600  IN A
216.250.130.73
ns.sco.com.           21600  IN A 132.147.210.253
osr5.sco.com.  
      21600  IN A 132.147.67.194
host1.pcenter.sco.com.  21600  IN A
132.147.4.1
host2.pcenter.sco.com.  21600  IN A
132.147.4.2
host3.pcenter.sco.com.  21600  IN A 132.147.4.2
... etc 
...
host20.pcenter.sco.com.  21600  IN A 132.147.4.2
uw713doc.sco.com.      
21600   IN A 216.250.128.245
ftp-rsync.sco.com.      60      IN A
216.250.128.7
mail.sco.com.           21600   IN A 216.250.130.37
ca.sco.com.   
         86400   IN NS ns.calderasystems.com.
ca.sco.com.             86400   IN
NS ns2.calderasystems.com.
ar.sco.com.             60      IN A 
216.250.128.12
www.ar.sco.com.         60      IN A 
216.250.128.12
linuxupdate.sco.com.    21600   IN A   216.250.128.241
...
Stuff removed ...
ns1.sco.com. 21600   IN A 132.147.210.253
ns2.sco.com.
21600   IN A 192.102.82.254
public.sco.com. 21600 IN A
216.250.128.194
scerg.sco.com.  21600 IN A 132.147.67.53
docsrv.sco.com. 21600
IN A 216.250.128.247
osr5doc.sco.com. 60   IN A 216.250.128.12

I have been trying to connect to this whole list. I thing they just turn it off. All their dns server work. Look at this

dig @ns.calderasystems.com
www.sco.com
  
; > DiG 9.2.3 > @ns.calderasystems.com www.sco.com
;;
global options:  printcmd
;; Got answer:
;; ->>HEADER

[ Reply to This | # ]

New SCO's Attack Story
Authored by: Anonymous on Thursday, December 11 2003 @ 01:54 AM EST
As a result another attack in a series of attacks against SCO a SCO employee
has spilt his coffee. SCO has released a press statment saying that a passing by
Linux hacker posing as a motorist tooted his car horn in an effort to undermine
the SCO vs IBM legal challenge. A SCO spokesperson said that they will have the
whole mess cleaned up in 12 hours but the damage done to the vital documentation
that happened to be on the floor at the time may mean that SCO may require more
time than previously expected....

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: david_koontz on Thursday, December 11 2003 @ 01:55 AM EST
Last time SCO went around on a supposed DOS event I had just come accross a
paper on low bandwidth attacks after seeing something on the cryptography list.
The paper is entitled "Denial of Service via Algorithmic Complexity
Attacks" by Scott Crosby and Dan Wallach. They describe bringing a system
to its knees by giving an intruder detection system something tough to do,
eating host system resources.

The question is "Could someone being doing something similar to
SCO?"

Seems to strike a chord with the lack of visibility of high bandwidth traffic.

The paper can be found at:

http://www.cs.rice.edu/~scrosby/hash/

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: peterok on Thursday, December 11 2003 @ 01:57 AM EST
You know what always made me curious? What kind of tech people work at SCO and how are they planning their career after SCO? Surely, they don't expect to stay with the company forever.

One day they'll find themselves posting to hotjobs, monster or, may be, freelance bbs and ...... what will they write? "I developed innovative Linux software, reporting directly to the CEO?" or perhaps "I planned and engineered a simulated DOS attack?"

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: jkondis on Thursday, December 11 2003 @ 02:57 AM EST
www.sco.com is back up. Yay.

It is slower than the Slow Boat to Hell, though. Takes like a minute to load the homepage...

...J

[ Reply to This | # ]

someone tripped over ftp.sco.com?
Authored by: Anonymous on Thursday, December 11 2003 @ 02:57 AM EST
looks to me like someone from sco read some of the posts here and tripped over
the ftp.sco.com cable..

not reachable here in aus for me anymore

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: Fruny on Thursday, December 11 2003 @ 03:12 AM EST
LinuxWorld: SCO's "DDos Attack" - Was It or Wasn't It ?

[ Reply to This | # ]

No reboot shown on Netcraft for recent kernel patch
Authored by: phildriscoll on Thursday, December 11 2003 @ 03:37 AM EST
Given that all competent sysadmins should have patched
their linux kernels in the last week or so because of the
brk() vulnerability, I thought I'd take a look at the
netcraft uptime graphs for www.sco.com to see if there was
a restart on the webserver in the last week. Sadly, I can
only see an uptime graph that takes us up to the 3rd
December.

Perhaps someone is better at pushing the buttons on the
netcraft site and can get an uptime graph until the site
went down.

I had to do a 200 mile round trip drive last week to
one of the colocated servers I look after, in order to
bring the machine back to life after an usuccessful
application of the kernel brk() patch (on SuSE 8.0).

It seems not too unlikely that this problem may have
affected others, especially those on a similar (maybe
United Linux) platform.

Perhaps someone at SCO is a little slow at applying
patches, and it simply went wrong?

[ Reply to This | # ]

Security Expert Doubts SCO's Attack Story
Authored by: pixitha on Thursday, December 11 2003 @ 03:42 AM EST
nah, dont worry about the ftp server...its up and operational...and yes
very fast compared to the SLOW www of sco...
as of 12:40am PST on Thursday morning...

ftp> open ftp.sco.com
Connected to ftp.sco.com.
220 ftp.caldera.com Ready.
Name (ftp.sco.com:none): anonymous
331 Anonymous login ok, send your complete email address as your
password.
Password:
230- Welcome to SCO's FTP site!

This site hosts UNIX software patches, device drivers and supplements
from SCO.

To access Skunkware and Supplemental Open Source Packages, please
connect to ftp2.caldera.com.

230 Anonymous access granted, restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

----
the charade continues...

pix

[ Reply to This | # ]

While we talk, the site is up
Authored by: Anonymous on Thursday, December 11 2003 @ 03:42 AM EST
Seems like SCO's site is accessible again - just checked it out, and NetCraft
also reports it accessible (9am here in Macedonia = 8am GMT). Since I'm a
database programmer (not very skilled to networks), can somebody please explain
why NetCraft reports the site being accessible from certain points and not from
others?

Great work PJ - I don't post often, but I follow Groklaw since the beginning !

[ Reply to This | # ]

SCO Web site has been reworked
Authored by: blhseawa on Thursday, December 11 2003 @ 03:44 AM EST
It took awhile to figure it out.

But SCO has re-worked their web site again!

The first obvious thing missing is any reference to the TSG (SCO) - IBM
lawsuit.

All of the legal links to documents, etc. are gone.

The downlaod area has changed and the login page is gone.

There was some considerable restructing of the menu bars on all pages
as well as the overall look of most pages.

However the SCO Source page has been completely reworked to remove
any reference to IBM

And this rather interesting new qoute take for this page

http://www.sco.com/scosource/

"SCO is the owner of the UNIX Operating System Intellectual Property that

dates all the way back 1969, when the UNIX System was created at Bell
Laboratories. Through a series of mergers and acquisitions, SCO has
acquired ownership of the copyrights and core technology associated
with the UNIX System."

TSg appears to be rewriting history again, since they now seem to think
they own the original code from 1969 which was already placed in the
public domain. It looks to me like they really are trying to reverse the
USL/BSDI decision. How they think that is possible is beyond me. I
thought once you had a court approved settlement, you could not go
back and alter it.

For the other geeks out there, if you look at the source html for each
page on SCO sight it is pretty clear that there have been a lot of last
minute hacks added in.

Normally, with web sites, every so often, you go through and clean up
the web pages, and most shops, have pretty printing formating tools that
strip a lot of the white space and blank lines, etc.

After a couple of last minute hacks, pages tend to lose the formating and
indenting.

There is a lot more of that now.

Anyway, from some early diffs of their current source and several
archives they (TSG) made a number of very significant changes to their
web site. becuase they added a lot of flash and javascript, it looks to me
like they don't possess a developmet or test server, and have to roll all of
the changes directly into the web site.

I'm the Chief Engineer at and ISV here in Seattle, and we have three
seperate web farms, so that we don't have to take the production web
site down. All development is done on a internal development web site,
then through various scripts and programs, this gets replicated on to the
test web site, where various internal orgs test the site before it goes to
production. lastly, when if is approved, the is an automated process
consisting of scripts and programs that moves everything onto the
production web site, and the web iste is then running the new content.

This is done all the time by groups all over the web, only very small sites,
don't go through this kind of roll out.

So, since they had to take the web site down for more than 12 hours and
the site has some significant content changes, that does not appear to
be at all a restoration of a hacked site.

Also, they have changed the network architecture becuase even though
the web site www.sco.com is up, although running rather slowly, it does
not respond to ping or traceroute for some reason.

I don't have the energy tonight to track down all of the network changes,
but TSG has changed the way there netwrok behaves.

One of my own servers was misbehaving this evening so will it was being
restored from tape, I decided to see if TSG was up and if the web site had
changed, since that might better explain what is going on then anything.

So, it looks to me like SCO didn't want anyone to know they changed
their web site again.

Regards,

blhseawa

[ Reply to This | # ]

Linuxworld seem to have bought SCO's press release...
Authored by: talamacus on Thursday, December 11 2003 @ 03:44 AM EST
So, I sent them this:

To whom it may concern,

Dear Sirs,

I have to admit that I am utterly dismayed by your characterisation of your own
readership as the sort of people that would engage in the nefarious practice of
attacking the servers of SCO. I am even more puzzled that you would give SCO's
public claims any credence at all.

Given your positions as supposed experts on all things Linux (your own
self-proclaimed expertise being implicit in your publication's title), it is
astonishing that you would take SCO's claim at face value, apparently without
even the most cursory of investigation.

As a security professional myself, and having actually taken some time to weigh
the evidence of SCO's claims, I can find absolutely evidence that supports
their claims. There is a rather excellent summary of the situation available on
the Groklaw web site, here:
http://www.groklaw.net/article.php?story=20031210163721614

Your blatant juxtaposition of the justifiably aggrieved members of the open
source community, and the kind of people that might undertake a denial of
service attack in your "urgent appeal" leave the reader with the
very misleading impression that the open source community is responsible. Your
publication's position within this community only serves to provide an apprent
admission of guilt (or at least, knowledge of such).

Surely you can appreciate, that with Linux coming under attack from SCO, that
your apparent subservience to SCO's press department is only providing further
ammunition? Regardless of the complete lack of merit that these accusations
hold, the Open Source community still has to expend time and effort to prove the
facts of the situation.

I would be extremely interested to hear from you as to your position on this
matter.

Yours faithfully,

Sebastian Potter.

[ Reply to This | # ]

PROOF that SCO is NOT suffering a "SYN" attack. And probably never was.
Authored by: Mark Levitt on Thursday, December 11 2003 @ 04:03 AM EST

SCO is absolutly lying to say they are under a SYN attack.

TCP/IP is a "connection" oriented protocol. This means that, before two machines can start exchanging data, they must establish a connection between them, agreeing on certain parameters like, for example, how much data to send at once.

TCP/IP has a standard way for two machines to establish a connection. The sequence is as follows:

  1. Machine A sends a SYN packat to Machine B.
  2. Machine B replies with a SYN packet to Machine A
  3. Machine A acknowledges the SYN packet from Machine B.

Now, a SYN flood attack works because TCP/IP is designed to be robust and handles the possibility that some network glitch can happen at any point.

A SYN flood works like this: The target machine, having already received the first packet (#1) and sent a reply (#2) is waiting for the machine that initiated the connection to send the final acknowledgment that establishes a connection (#3). However, the attacking machine never does. The problem is that the machine waiting has already allocated various resource in anticipation of establishing a connection. And because TCP/IP is designed to handle network glitches, the target machine waits in anticipation of getting the acknowledgement eventually.

If you get enough attacking machine starting a connection but never actually completing them, you have a SYN flood attack. The target machine uses up all its resources waiting for the final connection acknowledgements that never come. Once that point is reached, no new connections can be started because the OS on the target machine has no "slots" left. Legitimate connections send packet #1, but they never receive packet #2.

Now, is this what happened to SCO? No. The OS running SCO's web server is perfectly capable of establishing connections.

Here is the output of sniffing the network packets from my machine to SCO's web server:

  1. 07:36:40.068702 sheryl.46702 > www.sco.com.http: S 3257175132:3257175132(0) win 5840
  2. 07:36:40.085872 www.sco.com.http > sheryl.46702: S 3322256980:3322256980(0) ack 3257175133 win 8568
  3. 07:36:40.085929 sheryl.46702 > www.sco.com.http: . ack 1 win 5840
  4. 07:36:40.128975 sheryl.46702 > www.sco.com.http: P 1:99(98) ack 1 win 5840
  5. 07:36:40.142052 www.sco.com.http > sheryl.46702: . ack 99 win 16384
  6. 07:36:52.105080 sheryl.46702 > www.sco.com.http: F 99:99(0) ack 1 win 5840
  7. 07:36:52.116928 www.sco.com.http > sheryl.46702: . ack 100 win 16384

First of all, I captured this sequence a few minutes ago. However, I tried it last night before I went to bed and saw the same thing.

This is the sequence of packets exchanged between my machine (sheryl) and www.sco.com's web server) (www.sco.com.http), captured by the tcpdump program.

Each line is a single packet. The important parts for this discussion are the first four fields:
Timestamp Sender:Port > Receiver:Port: Packet Type

Packet 1 is the initial connection request from my machine to the web server. It is a SYN packet from Sheryl's port 46702 to the web server machine's http port (80).

Now, packet 2 is the initial reply from SCO's web server. Notice the timestamp. The reply comes almost immediatly (in less than 1 second). The packet is a SYN packet in the normal connection sequence. If SCO was really suffering a SYN flood attack, I would expect to not receive packet #2. At the very least, I would expect some sort of delay because the machine was overloaded. As you can see, this is not happening.

OK, now in packet #3, the connection completes. My machine acknowledges the previous SYN packet from SCO's web server.

The TCP/IP connection is now established.

It is important to realize that, up to this point, the OS knows a connection is being established, but the applications (the web server software on SCO's machine and the browser on my machine) do not. Remember this fact for later.

At this point, the web browser on my machine is told a connection has been established to the web server. It sends a request for the web page in packet #4.

In packet #5, the TCP/IP layer of the web server OS acknowledges receiving the data.

It is at this point things stop. SCO's web server doesn't reply and, after 12 second, I manually stop the browser.

TCP/IP also has a standard sequence for ending a connection, allowing both sides to confirm that they are finished sending data and to clean up. Packet #6 is my machine ending the connection and packet #7 is the SCO machine acknowledging it.

Now, remember I said that the OS knows a connection is being established, but doesn't tell the higher level applications until it actually completes?

Well, there is one other interesting fact about the way TCP/IP works. When an application, like a web server, wants to listen for incoming requests for pages, it must tell the OS. Specifically, in the case of web servers, it tells the OS to accept connections on port 80 and that the web server is going to handle those connections.

So, the implication here is interesting. If the web server software was simply not running, the OS would not accept the connection to port 80 (the http port). As soon as packet #1 arrived, the OS would reply with a "connection refused" packet.

The fact that the OS allowed the connection to complete means that the web server software is running.

This is weird.

  • If someone had simply pulled the network cable on the machine, the connection wouldn't get past sending the first packet.
  • If the web server software was not running, packet #2 would be a connection refused packet the connection would stop.

So, it seems as if there is nothing at all wrong with SCO's internet connection or the OS running the web server software. I can only think of two possibilities:

  1. SCO's web server is badly misconfigured by accident.
  2. SCO has intentionally crippled there web server to not reply to request.

I'm not much for conspiracy theories, but I find I can't think of a normal failure mode or a DDOS attack where the OS would be perfectly capable of establishing a connection, the web server is running and accepting those connections, but doesn't actually send any data.

I can say that it is definitly not a SYN flood attack. I saw the same sequence of packets when it was first reported. SCO is lying. Why I cannot imagine.

[ Reply to This | # ]

SCO running Linux.
Authored by: Anonymous on Thursday, December 11 2003 @ 04:11 AM EST
Netcraft confirms that SCO is running Linux on their servers.

Can a kernel developer force SCO to stop running Linux, because by
attacking the GPL, they are clearly not accepting the terms of the GPL?

If I don't agree with the EULA from MS, I'm not allowed to run their
software either, am I?

[ Reply to This | # ]

Did anyone notice
Authored by: Captain on Thursday, December 11 2003 @ 04:23 AM EST
"SCO is working with law enforcement officials and gathering information through mechanisms that we have in place to help us identify the origin of these attacks," said company spokesperson, Blake Stowell.

Note that BS didn't say they notified the authorities for this specific "incident." Or even for any cyber attack. The only thing he says is they're working with law enforcement officials on an unspecified issue.

These two statements:
1. SCO is working with law enforcement on something (hypothetically something like unpaid speeding tickets of employees)
2. SCO is gathering information about cyber attacks

Could be completely unrelated. When used in the same sentence they just *sound* related.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 04:29 AM EST
I just sent the following e-mail to Internet Week in response to their article.
---------------------------------------------

Please... PLEASE... do some research on *anything* you find in SCO press releases before publishing as fact. Some serious doubts have been raised as to whether SCO is even being attacked.

If they are, the evidence seems to show it isn't a "large-scale" DoS attack as the article claims.

If the attack really is a "syn attack" as SCO claims, then poor techincal support inside SCO shares a large burden of blame. For some time now, these attacks have been easily preventable, or at the very least they can be minimized with little effort.

Also, if it is a syn attack, SCO has no way to know how many systems are really involved. These attacks by nature use forged IP addresses which would easily make a single PC appear to be sending packets from "several thousand" IP addresses. Therefore they can not claim to know how many attacking systems are actually involved.

Please take a look at http://www.groklaw.net/article.php?story=20031210163721614 for details.

The claim that the "attack" has "caused the company's Internet bandwidth to be consumed" is flat out refuted. Evidence provided does not back that claim.

Please check with SCO's ISP and with the "law enforcement officials" SCO says they are working with. See if they really have been contacted and are even aware of this "attack."

Also, you may want to look at the past attacks. It appears that at least one of them was actually the company taking the site down for a major update and not any type of DDoS attack as SCO had claimed. (Interestingly SCO's site changed while being "attacked" this time too. Not sure why tech staff is working on the site during a DDoS crisis.)

I'm not one for conspiracy theories, but I do think your sources should be checked a little better. Or at least preface your story with "SCO claims..."

I hope you check into this and release a follow-up article. You may just find an even bigger story to report than you realized you had.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: jobsagoodun on Thursday, December 11 2003 @ 05:06 AM EST
If you take a look @ http://uptime.netcraft.com/perf/graph?site=www.sco.com

you can see (esp the new york graph) no real hammering of their service. Whats
interesting though is the bit at the bottom - they've changed from linux/apache
to unknown/apache - either they've got apache to not disclose the type of OS
they're running, or they're trying to switch over to something else. Perhaps
they decided to switch over to UnixWare and it doesn't work properly! Hence the
outage. Of course, they aren't going to issue a PR saying 'our software is too
sh*t to use as a webserver' so they're running the ddos story....

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 05:29 AM EST
From The inquierer:

"Suddenly SCO has become the "victim" of another
"attack".

It might have worked, except this time Groklaw was watching the play."

Read all here:

http://www.theinquirer.net/?article=13131

[ Reply to This | # ]

Let them know!
Authored by: Anonymous on Thursday, December 11 2003 @ 05:39 AM EST
As I write,there is less than 4 hours before the NY stock exchange opens again.
It's about time shareholders and the financial world got some facts. I would
urge all those who have read this story and looked at the posts in response to
it to email any site that has put the SCO press release up as if it were
"factual". Point them to Groklaw, and suggest that it is a source
they should be consulting routinely for the latest analysis of the situation.
Include the links to The Age and/or The Sydney Morning Herald. Appeal to their
journalistic integrity, and suggest that there might be a more interesting story
to be published here than mere regurgitation of SCO's press releases.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: PenguinLust on Thursday, December 11 2003 @ 05:52 AM EST
This morning (5:50AM (GMT-5) www.sco is down again. I grabbed the current
netcraft image just in case.

Unfortunately I'm about to head to work, can anyone start analyzing the current
downtime.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: gbl on Thursday, December 11 2003 @ 05:57 AM EST
Netcraft is now reporting SCO down time with some nice graphs.

Of particular interest is the table at the end of the page which indicates that the web server operating system changed in some way on 11th Dec.

---
If you love some code, set it free.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 06:03 AM EST
PING ftp.sco.com (216.250.128.13): 56 data bytes

--- ftp.sco.com ping statistics ---
11 packets transmitted, 0 packets received, 100% packet loss

PING www.sco.com (216.250.128.12): 56 data bytes

--- www.sco.com ping statistics ---
13 packets transmitted, 0 packets received, 100% packet loss

So ftp is down as well.... I guess they decided to fix that little
peculiarity....

[ Reply to This | # ]

Proposed Press Release / Mainstream Article
Authored by: nealywilly on Thursday, December 11 2003 @ 06:05 AM EST
Here's my attempt to make the issue of whether SCO was actually attacked
palatable for mainstream media / non technical readers. I don't know how to
publish something like this, but I know even what PJ has summarized is too much
and too technical. Maybe adhering to (limitations of) the mainstream media
approach will best counter this recent FUD/Spin by SCO.
*******************************************************
Security Expert: SCO Web Attack Claims May Be False
By Author [if for News Article]
City, State, Date [if for Press Release]

Less than 24 hours after the SCO Group, Inc. announced that they
"experienced a large scale distributed denial of service (DDoS)
attack" of their Web site, a technology security expert and several
experienced information technology professionals have questioned the validity of
the company's claims.

Steve McInerney, a [Current Title for Employer] who was also a member of the IT
Security team for Australia's Department of Defense, stated, "I feel
quite comfortable in stating that SCO are NOT suffering a DDoS attack.
Specifically not one that they have described." [emphasis is his]
McInerney's confidence is grounded in the fact that other servers related to
the company's Web site (www.sco.com) remained accessible to the public (such as
ftp.sco.com), which is inconsistent with the specific "syn attack"
type of DDoS alleged by SCO.

These facts were further supported by several IT professionals who performed
tests to track their access to various SCO Web addresses, even as the company
declared it "remains unavailable". Other inconsistencies noted in
popular on-line discussion areas, such as www.groklaw.net and [Other Sites]
relate to the fact that it is very unlikely that any DDoS attack would have any
impact on a company's intranet site, as claimed by SCO, which should by
definition be only internally assessible.

While the depth of the arguments against the attack extend beyond the scope of
this article [or Press Release], there is a general concensus that the so called
"syn attack" has been known about for years and can very easily have
been avoided or quickly mitigated. Although the expert and professional
analyses are limited by the lack of more definitive support for SCO's claims,
adhering to reasonable and widely known security policies, especially in light
of the multiple prior attacks the company reported this year.

Given the inconclusivity of their claims, perhaps the press release was a tad
premature, if not innaccurate.

[ Reply to This | # ]

Mail the Wall Street Journal?
Authored by: Anonymous on Thursday, December 11 2003 @ 06:18 AM EST
I guess people aren't going to read it over breakfast this morning, but why not
write to the Wall Street Journal about this? I'm incensed at the way the media
are accepting SCO's assertions at face value. I'm looking for an editorial
email address this minute....

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: belzecue on Thursday, December 11 2003 @ 06:19 AM EST
http://www.techworld.com/news/index.cfm?fuseaction=displaynews&newsid=765

QUOTE
Raymond condemned Wednesday's attack. "The open-source community has
condemned crack attacks on SCO in the past, and I don't believe any of our
people are involved in this alleged attack," he said by e-mail. "No
point to it; SCO's case is sinking fast."
UNQUOTE

I'm not anti Raymond, but I do wish he'd stop feeding the FUD machine.

[ Reply to This | # ]

Inquirer Article & FTP Hack...
Authored by: Anonymous on Thursday, December 11 2003 @ 06:23 AM EST
About this article in The Inquirer...
http://www.theinquirer.net/?article=13131

Nice. But this paragraph concerns me:
> Especially since the "attackers" seem to have removed much of
the
> Linux source code from its FTP server in the meantime.

I think it was during this attack that we noticed that the source had gone
missing. But my look over the FTP site seemed to suggest that may have actually
happened December 2nd or so?

[ Reply to This | # ]

Explaining Traceroute via XO - not NFT / Center7
Authored by: Anonymous on Thursday, December 11 2003 @ 06:39 AM EST
(Sorry it's anon but I need to protect my employer. I'm a senior backbone
engineer at middle sized ISP for info)

The route to the ip range 216.250.128.0/20 is allocated to the Norda Family
Trust. The ARIN (American Registry for Internet Numbers) record stated that
the DNS is handled by Center 7.

The ip range is split into to blocks - the lower one
216.250.128.0/21 is contains sco's servers. The only ISP
that annouces that route anywhere in the world is XO.

The upper block 216.250.136.0/21 belongs to and is used
by CENTER7 so I assume that SCO purchases DNS, IP addresses & other services
from CENTER7.

Here is annoymised BGP route list from one of our exterior router. NOTE the AS
(Autonomous System) number for XO is 2828, 1239 is sprints so 1239 2828 in the
output below means the network path is Sprint then XO.

#show ip bgp 216.250.128.12
BGP routing table entry for 216.250.128.0/21, version 27394589
Paths: (3 available, best #3)
Not advertised to any peer
1239 2828
***.***.***.** from ***.***.***.** (***.***.***.**)
Origin IGP, metric 311, localpref 100, valid, external
Community: ****:****
1239 2828, (received-only)
***.***.***.** from ***.***.***.** (***.***.***.**)
Origin IGP, metric 311, localpref 100, valid, external
**** **** 2828, (received & used)
***.***.**.*** (metric 21) from ***.***.**.*** (***.***.**.***)
Origin IGP, localpref 120, valid, internal, best
Community: ****:1111


So you will all see the routes entering XO as the last ISP from wherever you
are. I have done traceroutes from 6 points on the globe and all reach the final
hope to SCO which is p0-0.CHR1.SaltLake-UT.us.xo.net (207.88.83.42).

XO is not blocking these IP ranges at the moment. One poster commented that
earlier XO appeared to blocking them at the entry points to their network - this
would be consistent with an ISP 'blackholing' the route - quite a common
technique in DDoS mitigation however what doesn't make sense is that it occured
*after* the event and only very briefly - did someone at SCO realise that
Groklaw was on to them and jump up and down at their service provider shouting
'please block all access to our IP addresses'? XO seeing that no DDoS was
occuring then lifted the blackhole route?

Regards

M

[ Reply to This | # ]

News article from Netcraft
Authored by: jmccorm on Thursday, December 11 2003 @ 06:43 AM EST
[lifted from Yahoo! message board]
http://news.netcraft.com/archives/2003/12/10/ddos_takes_sco_site_down.html

Times are in GMT. But the graph doesn't look like an attacked site. It simply
looks like it was taken down.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 06:49 AM EST
Correct me if I am wrong..

ws not SCO unixware not patched for sync flood attacks and oen of the complaints
that cusotmers cited in migration to other OS platforms?

sorry cannot recall the article where I saw it as of yet..


On stock pumping..

the ultimate benifcator is Noorda Trust as they own Canpoy shares do they not?
So why is Nooorda or Noorda Trust so quite? Has Canopy pumped up stock in one
division to benefit another division within the Canopy family of companies?
Yes, in fact the evidence is easy to find..although before FDU and outright lies
have not been used..





Fred Grott
ShareMe Technologies-The Mobile Future
http://www.jroller.com/page/sahreme/Weblog

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 07:01 AM EST
Before the alleged "attack" Netcraft showed the server as
Linux/Apache. It is now shown as unknown/Apache....so they weren't running
Unixware before and we don't yet know what they are running now. In fact they
are down again and so is ftp this time (see previous posts including recent
pings)

[ Reply to This | # ]

XO know more than they are saying
Authored by: nowster on Thursday, December 11 2003 @ 08:07 AM EST
PJ, in your conversation with XO's techies, they claimed that they weren't blocking a DDOS on SCO's behalf.

This is at variance with what us networking types see: XO are blocking all traffic to www.sco.com at the point at which it enters XO's network. This can only have been following a specific request from SCO, and XO should have records of this request.

This sort of behaviour is consistent with an ISP which has been asked to block a DDOS attack. Some part of XO must know what's going on.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 08:13 AM EST
Didn't SC0 claim they were working with law enforcement officials to track down
the cause ? Would it be possible to check to see if that were true or not ?

[ Reply to This | # ]

Back down again?
Authored by: Anonymous on Thursday, December 11 2003 @ 08:18 AM EST
04:51 Mountain (Utah) time, and I can't access www.sco.com from Denver.

Actually, traceroute ICMP or UDP don't even get out of Denver to www.SCO.COM - on two different backbones (InterNAP->Sprint and Level3). Odd.

Okay, then. Let's try ns.calderasystems.com (216.250.130.1). According to ARIN, it's in the same netblock, and you might theorize that it's routed the same. And in fact, further testing reveals that TCP traceroute on the InterNAP connection works for both sites and that they do follow the exact same path to XO.com in Salt Lake. (Must remember to hate InterNAP for blocking UDP traceroute and ICMP sometime...)

The Level3 connection is the interesting one - Level3 will kindly run a trace on the ns.calderasystems.com address, but won't give me any responses when testing www.sco.com - across their entire network. Even though they have the same routing assignment?!?!?! Looks like Level3 put in a network-wide ban of traceroutes and ICMPs to the SCO web server. ftp.sco.com seems to trace fine. (As I write this, some of Level3's blocks are disappearing and I can now hit everything before the Level3/XO border).

So someone doesn't want people probing that netblock anymore, I guess. Too many revealing facts.

And to put in my two cents, despite the interesting routing theory discussed earlier, I have to agree with the "experts"... This was not a bandwidth-eating DDoS.

  • No amount of routing trickery removes the fact that all SCO/Caldera address blocks go through the same (customer-level? hard to interpret their router naming) XO.com router in Salt Lake. If the DDoS was going to affect anything outside of SCO itself, that router would be it, and it performed admirably.
  • The rest of their systems responded quite well through the whole thing, including their DNS and FTP servers. Again, no amount of routing theory removes the bottleneck at the XO.com router. Additionally, I would be surprised if XO.com didn't pass the entire SCO.com (216.250.128) network on to the same Center7 router.
  • Their upstream (XO) still hasn't put in a block to the www.sco.com address at their border (if the attack is that bad, moving the web site to a different IP address and blocking all traffic to the old site is probably the fastest short-term solution).
  • And somehow they got an e-mail press release out. (Before you discount this, remember that they stated their internal systems were affected - why would outbound, internally-originated e-mail be immune to that? Dial-up account? Called up the PR agency with the news? Maybe.)

Nope. They took the site down themselves. And if reports of site changes are true, then I disagree with the "poor backup/hacked site" theory. (A) the FTP site changed at the same time (?!?!), and (B) the parts of the site that are changing do not correlate closely enough to the most recent changes. Poor backups usually mean either changes missing or entire sections missing. Sounds more like selective editing from here (can't see it, but from what someone else posted...). Add to that the change of OS fingerprint, and someone did some upgrades...

PS - As a ViaWest Denver customer, I was interested in the Canopy Group bit. If ViaWest runs the Center7 datacenter (as the press release might imply), I would count on the network techs having excellent skills. Even the overnight first-line Support Desk folks at the Denver centers have skills good enough to trust with full access to all routers. That points the blame back to SCO itself (not XO.com, not ViaWest/Center7 tech support, ergo SCO.)

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 08:25 AM EST
Was not Darl supposed to release another open letter today? I've been rather
looking forward to reading his latest work; this one addressing the GPL
explicitly, if memory serves. What a shame that their site is still down this
morning. Woe is me!

[ Reply to This | # ]

OT, but of interest to those who oppose software patents
Authored by: Anonymous on Thursday, December 11 2003 @ 08:29 AM EST
Check out this article

http://news.zdnet.co.uk/software/developer/0,39020387,39118430,00.htm

Seems M$ is at it again with browser deal.

[ Reply to This | # ]

Don't dismiss them out of hand
Authored by: dcs on Thursday, December 11 2003 @ 08:30 AM EST
People, I have seen all sorts of silly arguments here in denying SCO has had
their web server brought down by an attack. I don't know what is happening with
SCO, but I know the arguments I'm seeing are not valid. Let's go at them:

A: Linux has syn flood protection for a long time now.
R: It was not enabled by default for quite a while, even if it is today.

A: They should have enabled the syn flood.
R: If it did not have disadvantages, it should have been enabled by default, so
go blame Linux developers, not SCO web admins.

A: Well, they should keep the machine patched and secure, so it's their own
fault.
R: No, it is not THEIR fault that some is DoS them. It's the perpetrator's
fault. This is groklaw, right? Could the lawyers step forward and clarify this
point of law?

A: No one does SYN floods anymore.
R: Yes, they do. My firewalls logs prove it.

A: SYN flood is such an old attack it shouldn't affect anyone.
R: Well, maybe it wasn't a SYN flood. Since when have you gotten correct
technical descriptions from the common press?

A: If it wasn't a SYN flood, they should have gotten their fact straight.
R: Most people doesn't care what the attack really was, and would not
understand the fine distinctions between a SYN flood and a simple bandwidth DDoS
(which, btw, is most often done with SYN floods). Sorry, they do NOT need to
give precise and detailed information to the press, only to law enforcement and
the courts. Go back to criticizing their discovery.

A: The FTP site is right beside the web site and it is was fine.
R: For all we know they do 1-1 NAT on border router and the servers are in
completely different networks. I know *I* like to keep servers with distinct
vulnerabilities on distinct networks, so I can have a firewall prevent the
infection from spreading.


People, there are all sorts of attacks that can bring down the web server or
some element in front of it. Hey, maybe they hacked a non-patched Apache and
they used hping to lock down it's port on a non-patched Cisco. Maybe they
invaded their network through rsyncd bug (and a week is NOT time enough to patch
all servers on a large, 24/7 network), then got root through Linux do_brk() bug
(see above), and simply firewalled the server, so someone will have to go to the
remote location where the server is located, get a console on it, and then try
to figure out what the hell is going on.

I can think of all sorts of attacks that could result in this, and I can even
think of situations a SYN flood attack could cause this (I've see an OSPF
router poping in and out of the network because a traffic monitor tool got
overloaded during a SYN flood, leaving no CPU to the OSPF process, for example).
And if Debian and Gentool can get hacked, and you BET they are very security
conscious and up-to-date, then it's very spiteful of you to blame SCO for not
being able to withstand an attack.

That is, if they WERE attacked. Maybe they were not attacked, but no one here
can't say they were not.


---
Daniel C. Sobral

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 08:33 AM EST
Through all this, where are the SCO employees? You'd think that someone within
SCO would be reading Groklaw and would, anonymously, post their observations
(confirmations, denials, whatever). But I haven't seen anything indicating an
SCO presence on Groklaw at all. But then I can't read every posting ... there
IS more to life :-)

My experience is that IT folks are notoriously forthcoming. Take a look at
f*ckedcompany.com and the number of leaks they publicize!

I wonder what constraints SCO has put on their employees and, more
interestingly, employees that leave the company. "Say a word and you are
fired?". "Say a word and you are sued?"

The silence is deafening.

[ Reply to This | # ]

Mis-direction
Authored by: kberrien on Thursday, December 11 2003 @ 08:34 AM EST
Notice we/press are not talking about SCO's legal problems anymore, or their
voodoo accounting?

“In wartime, truth is so precious that she should always be guarded by a
bodyguard of lies.” – Winston Churchill

[ Reply to This | # ]

OT: No IBM order yet, but court transcript is up
Authored by: mnuttall on Thursday, December 11 2003 @ 08:36 AM EST

57 page court transcript here. Almost the first thing Judge Wells mentioned was that "certain representations have been made by SCO to the media." Heh.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 09:23 AM EST
P:\>ftp ftp.sco.com
> ftp: connect :Unknown error number

wtf does that mean?

Dave

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: BigTex on Thursday, December 11 2003 @ 09:37 AM EST
DARL: I am sorry your honour but the "DoS Attack" we delt with
caused us to lose all of the proof of IBM's misdeeds. We will need 6 mo to
recreate that data though our MIT Team now working in Area 57 on a new spectral
analysis.

$20 says I am going to hear this lame *ss excuse (or something close) in 30
days.

BigTEx

[ Reply to This | # ]

coincidence? OS changed with outtage
Authored by: mrallen on Thursday, December 11 2003 @ 09:45 AM EST
http://uptime.net craft.com/perf/graph? site=www.sco.com
go to the bottom of the page.

according to Netcraft, the underlying OS running SCO's web site changed from Linux to 'Unknown' since the start of the alleged attack. the system was back online for a while before going back offline which allowed the change to be noticed.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Beyonder on Thursday, December 11 2003 @ 09:52 AM EST
Now this thread is just downright scary, check it out...
keep that grain of salt handy though:

http://finance.messages.yahoo.com/bbs?.mm=FN&action=m&board=1600684464&a
mp;tid=cald&sid=1600684464&mid=69976&thr=69976&cur=69976&dir
=d

just because you're paranoid doesn't mean they aren't out to get you :)

[ Reply to This | # ]

Stock is up $0.45 at 09:36
Authored by: Anonymous on Thursday, December 11 2003 @ 09:53 AM EST
The fud machine is working or the tape is being painted.

Stock up 45 cents

[ Reply to This | # ]

SEC needs to get to SCO HQs
Authored by: Anonymous on Thursday, December 11 2003 @ 10:00 AM EST

Call me paranoid, but I figure that the SEC and other appropriate authorities need to quickly round up some search warrants, surround SCO headquarters and start saving some of the "evidence", which I suspect is "getting lost due to this DDoS attack".

If SCO's "intranet" was "affected", IMHO, you can bet "something" is going to be "lost" due to this "attack".

Regards,

Fredrick

[ Reply to This | # ]

Alternate SCO web server healthy
Authored by: Thomas Downing on Thursday, December 11 2003 @ 10:07 AM EST

SCO has a web server at stage-support.sco.com (216.250.128.10, as compared to wwww.sco.com at .12). This server responds quickly.

A quick look shows that only some of the www.sco.com content is mirrored here; some of the links are to www.sco.com. Also from a cursory look, this site has some modifications (IBM is less prominent, no mention at /scosource) but still has /ibmlawsuit, as well as links to there from /scosource.

---
Thomas Downing
Principal Member Technical Staff
IPC Information Systems, Inc.

[ Reply to This | # ]

OT right now but a little funny.
Authored by: ra on Thursday, December 11 2003 @ 10:08 AM EST
Kevin McBride at the motion to compel hearing:

"And by the way, your honor, I will proffer to the Court that we are
filing a second amended complaint that has copyright infringment claims, and
will be filed within the coming few days or no less than a week."

Is that statement a lie yet, or do we have to wait until tomorrow?

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Greebo on Thursday, December 11 2003 @ 10:14 AM EST
Hi,

I just got this http://news.zdnet.co.uk/internet/0,39020369,39118458,00.htm
news alert through Google about a story Zdnet are running.

They have picked up on the fact that SCO might have knobbled themselves
intentionally, and are letting people vote on who they think is responsible for
SCO's latest troubles.

To date SCO has 90% of the vote, and amusingly PJ has 2%. Seems like PJ is VERY
famous now!

Cast your vote now!

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Thomas Downing on Thursday, December 11 2003 @ 10:18 AM EST
<p>Must be bobbing up and down then, I just tried again and is was there
and fast.</p>
<p>I have not clue what that might mean...</p>

---
Thomas Downing
Principal Member Technical Staff
IPC Information Systems, Inc.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Greebo on Thursday, December 11 2003 @ 10:18 AM EST
Doh!

My mistake. I got 4 links to SCO related stories from the Google alert, and
posted the wrong one! Here's the correct one :

http://www.newsforge.com/business/03/12/11/1315246.shtml?tid=85

Sorry for any confusion.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 10:38 AM EST
Cnet is carrying the story supportin SCO claim of DDOS attack.
http://news.com.com/2100-7355-5119434.html

I've sen an e-mail to the author 5 hours ago .... ,o responce and no change of
the story


[ Reply to This | # ]

Paging a clue. Clue to the white courtesy phone, please.
Authored by: Anonymous on Thursday, December 11 2003 @ 10:56 AM EST
Does anybody remember the paper a while back on inferring DoS attacks by
reflection? Might have been presented at USENIX, but I can't seem to find it.

The study analyzed packets coming into a /8 to infer attacks on other networks
with randomly spoofed source addresses. For instance, if a syn flood directed
at SCO's web site was generated using randomly (flat distribution) spoofed
addresses, then a /8 should see a portion of the SYN-ACKs or RSTs generated as a
result of the attack.

What I'm wondering is if enough people keep detailed enough log info, so that
if we all looked for anomalous SYN-ACKs or RSTs from SCO, we could get a
statistically meaningful picture of a whether or not there's been a reflection
from this alleged attack.

My logs don't keep all the desirable detail... I only separate out SYN traffic,
and don't distinguish SYN-ACKs from RSTs, but I do take note of inbound
anomalies that would correspond to a reflection from a random source DoS.

Just a thought...

[ Reply to This | # ]

No Spike In Response Time Before Going Offline
Authored by: Anonymous on Thursday, December 11 2003 @ 11:00 AM EST

Perhaps someone has already noted this, but there was no spike in response times prior to going offline. That looks like SCO pulled it offline themselves, again.

http://uptime.netc raft.com/perf/graph?site=www.sco.com

[ Reply to This | # ]

OS Change; Coincidence, or the Groklaw effect?
Authored by: Anonymous on Thursday, December 11 2003 @ 11:01 AM EST
There is a post on <a
href="http://www.groklaw.net/article.php?story=20031209150025559#comments
">this</a> Groklaw page noting that www.sco.com is running
Linux/Apache. It was posted on 12/9 at 5:06PM EST.

The next morning www.sco.com is "attacked", and the OS is
"unknown" when it returns.

Hmmm.

[ Reply to This | # ]

evidence production unaffected
Authored by: RichMan on Thursday, December 11 2003 @ 11:01 AM EST
The production of evidence should proceed unaffected by the network outage. It
will be interesting to see if SCO claims that it is.

Work they need to do for the courts should be internal. Simply disconnect the
internal network from the external network. For any enterprise system this
should be as easy as pulling a plug (or two if they have redundant paths).
Internal data should not be on the systems used to serve external customers.
Even then the externally exposed systems should be fine once the attack source
is removed. SCO is claiming to supply enterprise systems, lets see them prove
the power of their systems and support.

So the people working on analyzing and producing the data for the courts can
continue while the sysadmin deals with the network problem.

The only excuse they might have is man power. If they are that low they are
going to have to hire external staff to fix their network problem while the
internal staff meet the courts requriements. As people have described, if it
truly is a SYN attack then the network people are at least somewhat negligent so
hiring external staff would be a good idea.

[ Reply to This | # ]

It can't be long until SCO mentions Groklaw
Authored by: Captain on Thursday, December 11 2003 @ 11:03 AM EST
With the rising exposure and news-coverage of this site, I'm waiting for
McBride to start making derogatory statements toward Groklaw. I'm guessing
he'll accuse us of lying, FUD, etc. It would be amusing to see.

[ Reply to This | # ]

larger context
Authored by: Anonymous on Thursday, December 11 2003 @ 11:06 AM EST
We need to look at this in the larger context. SCO is in a very tight situation.
It has to turn in a ton of discovery material 30 days from now, and it is
virtually certain this is going to be a disaster. It needs to keep its stock
price up, and so what we should expect is an escalation in its FUD campaign. The
"our website is being attacked by evil linux hackers" is one example
of this. Expect more in the next few weeks.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: mhoyes on Thursday, December 11 2003 @ 11:10 AM EST
You know, I've been watching all of this and it has been interesting.
Yesterday, when the announcement was made, I was able to get on the ftp server,
and the e-mail server. My traceroutes all showed a block at the same place, but
I have also seen traceroutes show different paths everytime I do it.

Anyway, this morning, I have noticed that the FTP and the SMTP servers are down
now. Does this mean that the "attack" is expanding or that they
realize that too many other machines were still available? The SMTP server is
at 216.250.130.2 and as I said, yesterday it was working fine each time I
checked it.

MEH

[ Reply to This | # ]

The Groklaw Effect
Authored by: Anonymous on Thursday, December 11 2003 @ 11:18 AM EST
As several posters have suggested previously, there may be a "Groklaw
Effect" at SCO. The fact that the ftp server was fine earlier and is now
unreachable is one example- as if they are scrambling to plug holes in their
case. Perhaps this is a stretch: - but I doubt that the SCO people are unaware
of the scrutiny...and it's real time, 24/7, by a lot of very well-informed
people.

[ Reply to This | # ]

Is this going to be their "Dog ate my Homework" excuse?
Authored by: sam on Thursday, December 11 2003 @ 11:25 AM EST
Any bets that the server outage lasts precisely 30 days?

[ Reply to This | # ]

OT- Transcript of hearing, groklaw comments?!?
Authored by: Anonymous on Thursday, December 11 2003 @ 11:30 AM EST
Because it is up now, how bout the groklaw crowd get to it???? I'm sure PJ's
workin on it, becauses she's rad like that.

In reading it all it seems like IBM is just really frustrated with the whole
thing. The judge seems like he wants things put together before he does much of
anything else and it seems like McBride et al are stretching here...

[ Reply to This | # ]

Reply to Reuters
Authored by: carlos on Thursday, December 11 2003 @ 11:43 AM EST
I just sent the editors of Reuters a note concerning their article found at:

http://www.reuters.com/newsArticle.jhtml?type=topNews&storyID=3973180

saying: "The quote from the Lindon based company, SCO, appears to be a
false statement."

I referenced the last two groklaw articles as part of my reply to the Reuters
article. We shall see if Reuters updates their article.

carlos

[ Reply to This | # ]

  • Reply to Reuters - Authored by: Anonymous on Thursday, December 11 2003 @ 12:19 PM EST
My exchange with "Computerworld"
Authored by: sphealey on Thursday, December 11 2003 @ 11:47 AM EST
Well, here is my exchange of letters with the on-line editor of Computerworld. I do not find the editor's response satisfying, but am a loss for a good, polite reply. Any suggestions?
Dear Mr. Mingis, As a longtime "Computerworld" reader (>20 years), I would like to suggest that you change the heading for your story
"SCO's Web site hit with DoS attack"

http://www.computerworld.com/softwaretopics/os/linux/story/0,10801,880 65,00. html

to
"SCO alleges Web site attacked"
as (1) there is no evidence that SCO's web site has in fact been attacked (2) following the so-called "second" attack in August, SCO claimed to have "contacted the FBI", but follow-up by third parties showed that SCO had in fact NOT contacted the FBI or any other law enforcement agency, thus casting doubt on whether or not an external attack had actually occurred. Given that the content of SCO's web site appears to have changed during the latest alleged "attack", I believe a bit more skepticism is warrented from a trustworthy publication such as yours.

Sincerely,

Steven Healey

Hi Steven: Thanks for writing. At this point, I plan to leave the headline as is, given that the Web site is still down and I have no evidence that there wasn't a DDoS attack. The implication behind changing it would be that SCO wasn't really hit by an attack, and issued a statement and took down its site to mislead people, or that something else is behind the site's disappearance and Computerworld isn't will to take the company's word for what happened. If, of course, this turns out to be a sham, we would do a story on it. Cheers, Ken Mingis Online News Editor Computerworld (508) 820-8545
=========================== Steven Healey on 12/11/2003 11:00:15 AM To: Ken Mingis/Computerworld@Computerworld cc: Subject: Request for headline change on SCO DOS story

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 11:49 AM EST
They're up at this ip:

http://216.250.128.20/

My guess is they moved servers and some idiot forgot to propagate the DNS change
before downing the old server.

[ Reply to This | # ]

How long before the editor censors this message too?
Authored by: Anonymous on Thursday, December 11 2003 @ 11:54 AM EST
When the "Heads up to journalists..." article came out I posted a
reply that was immediately censored and deleted by Groklaw. Well, I'm going to
say it all again.

SCO is going to use the current political paranoia in the United States to
characterize Linux advocates as terrorists. To associate Open Source with all
the things that make Americans wet themselves reflexively, like communism.

While this may sound like some sort of Mel Gibson'ish 'Conspiracy Theory'
rambling, it's all too likely.

Take a look at
http://www.internetwk.com/breakingNews/showArticle.jhtml?articleID=16700116
where Blake Stowell says "We deplore these activities by those who try to
intimidate or harass legitimate businesses through cyber terrorist tactics while
hiding their true identity."

SCO is smart enough to realize that these things can happen given the right
amount of fear. Americans would never have accepted the absolute contravention
of the Constitution that happened via the Patriot Act and other following laws
without the state of fear created around 9/11.

Hopefully one or two people will read this message and do something about it
before it gets deleted too.After all, free speech is next on the list. Ask
Eminem.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: pooky on Thursday, December 11 2003 @ 11:54 AM EST
Well, that was quite a read but several things jumped out at me:

McBride states that complaint is about "64-bit linux" and that is
SCO's technology. p 28, para 1

McBride states "There are trade secrets from Unixware" "System
5 is the book that Mr. Marriot referred to and properly so."
"There's nothing secret in there." p 46, para 1

On Page 47, McBride spells it out in full:
"And once we see AIX and all versions of it, then we will be in a position
to be able to say. Huh, you know what? This stuff you did in derivative works,
you own it, but you contributed it to Linux improperly, and therefore, we have a
claim in state law contract for breach of confidential information, which is
completely separate from trade secrets."

That sounds to me like he basically just admitted that SCO filed the suit solely
on the assumption that IBM did something improper and without evidence. SCO
needs IBM's discovery to define what charges exactly SCO should ammend their
complaint with.

Now Kevin McBride might not be totally informed on exactly what SCO has in
reality, but I'm really becoming more sure that SCO will not be able to comply
with IBM's request because they don't have a line by line "proof"
document as they "insinuated" they do.

-pooky


---
IANAL, etc...

[ Reply to This | # ]

Groklaw Censorship?
Authored by: Anonymous on Thursday, December 11 2003 @ 11:59 AM EST
I doubt very much that your post was censored. I will watch with interest
whether this one stays here.

[ Reply to This | # ]

A SCO stall attempt??
Authored by: Anonymous on Thursday, December 11 2003 @ 12:00 PM EST
Just a theory;
SCO could only get a delay in the deadline the judge stated, to comply with IBM,
IF there are valid reasons for it.

If SCO, on purpose, opens their security ports which benefits successful DOS
attacks, AND this would happen very frequently this month, they than can claim
that their technicals guys were busy with CSO's internal IT infrastructure, and
therefor waren't able to comply, in a timely matter, to IBM's notion to
compel.

Is this to far fetched?

greetings
Patrick

[ Reply to This | # ]

Starting to pay attention...??
Authored by: Anonymous on Thursday, December 11 2003 @ 12:16 PM EST
http://searchenterpriselinux.techtarget.com/originalContent/0,289142,sid39_gci94
0777,00.html

this appears on SearchEnterpriseLinux, from GoogleNews search on 'SCO'. At
least the claims are offset with coverage of the Groklaw discussion....

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 12:19 PM EST
I called SCO and asked specifically what Law Enforcement agencies were contacted
and what the FBI is doing. They have yet to return my call. There should be a
FBI Special Agent in Charge of the case. No local law enforcement is equipped
to handle a high tech case such as this. Only the FBI can truly handle a case
like this.

I suspect fraud on SCO's part. Sure, they could call the local police and
report something. However, the local law enforcement would not know what to do.
I believe this is why the Press Release is worded as "Law
Enforcement". If this was real, the FBI would want you to say nothing, so
that they could capture all the network traffic to bust somebody. This just
smells really bad. I think SCO again is pushing the bounds, teeter totering
between fraud and outright lies.

ByteEnable
www.linuxelectrons.com

[ Reply to This | # ]

All the google links reporting it as DDOS attack
Authored by: burySCO on Thursday, December 11 2003 @ 12:19 PM EST
Just checked news.google.ca, seems all the links from there at this time point
to articles that are describing this as a DDOS.

I used to know a journalist and I remember they get paid rather well. If all one
needs to do is retype corporate press releases to become a journalist (you see,
I can type too!), maybe it's time for me to make a career change.

Or are these people just paid to regurgitate corporate propaganda?



---
My jabber handle is burySCO@jabber.org

[ Reply to This | # ]

  • YES... - Authored by: SteveS on Thursday, December 11 2003 @ 12:54 PM EST
Look here at our DDOS, not at :
Authored by: jtsteward on Thursday, December 11 2003 @ 12:21 PM EST
Not at how we are paying our lawyers
Not at our products
Not at our lack of signed up licensees
Not at the fact that we lost a battle to IBM on Friday
Not at the fact that we delayed our earnings announcement

Groklaw, Yahoo and /. have all been distracted from the real issues while we
follow the bouncing SCO ball





---
-------------------------------------------------
Darl needs more bullets, he keeps hitting his foot but he won't go down

[ Reply to This | # ]

  • and also: - Authored by: Anonymous on Thursday, December 11 2003 @ 04:22 PM EST
Security Experts Doubt SCO Was Attacked
Authored by: jbellis on Thursday, December 11 2003 @ 12:26 PM EST
You can see an interesting and humorous NewForge poll concerning who might be (allegedly) DoSing SCOs site here.

They mention Groklaw in the text of the article and PJ made the list as a possible suspect. :-)

Jeff

[ Reply to This | # ]

  • DMCA? - Authored by: Anonymous on Thursday, December 11 2003 @ 01:12 PM EST
OT: Microsoft Beats down Lindows in Sweden
Authored by: mikebmw on Thursday, December 11 2003 @ 12:49 PM EST
From the Register Microsoft takes Lindows fight to Sweden I have to agree with Michael Robertson's quote "Microsoft is using lawsuits as a battering ram to smash Linux, to prevent it from reaching retail stores. We're hopeful that the Judge will see Microsoft's true intentions are to sustain their monopoly and will grant Swedish computer users the same choices that global computer users are benefiting from." The register also posted the Swedish court document filed against Lindows if you a interested.

[ Reply to This | # ]

AMAZING!! You Too Can Prop Up SCOX with ONLY $10k
Authored by: brice on Thursday, December 11 2003 @ 12:53 PM EST
Today's market is especially amazing to me. The trades that have propped up the stock have been microscopic. The daily volume hasn't even broken 50k shares. Yet the price has recovered from a fall back to it's openning and is now up a couple points. Check out charts at Yahoo and NASDAQ. Note how the volume is in Thousands and most trades don't break the low single digits!

I am not a market guru - I don't even play - but it continues to amaze me that if they just keep their name in the press, a few impulsive gullibles or a few compulsive gamblers will do SCO's dirty work for them and keep the price up. Millions of investors have $10k to play - SCO just plays that lottery with cheap PR. If for no other reason, that is enough motivation to stretch their DDoS story. They're all over the press today, aren't they? They're not even breaking a sweat in the markets.

Sickening,
-brice

[ Reply to This | # ]

WAS IT REPORTED BEFORE IT HAPPENED?!
Authored by: Anonymous on Thursday, December 11 2003 @ 12:59 PM EST
I noticed there was a lot of initial and early press by SCO
about this alledged attack on SCO, and this made me think:

First, it often takes some time to identify that a ddos
attach is actually occuring.

Then of course, one has to think about reporting it.

Next, it gets reported to some press contact, and they sit
on it a few hours or so (if web press), longer for print.
Usually you don't hear about such things until a day or two
later.

Yet, somehow the very first known publication of SCO's
story about their being under a ddos attack somehow
appeared very early on! Far too early for any, let all,
these things to have happened...

This makes me wonder; was this alledged attack reported
BEFORE it occured?! Who/where was the original source for
this story, and when did they announce it?



[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 01:09 PM EST
SCO Website Hacked by Vile Sandal-wearing bearded commies!
Pictures of assailents to follow!

SCO, the world leader in nebulous litigation, equivocal press releases, and
gargantuan intellectual property claims, announces it has for the third time
been the victim of a DoS attack on its website. The company quickly mobilized
all of its intellectual resources to produce a technically dubious analysis, a
totally unfounded charge of criminal behavior on unidentified parties, and, most
quickly of all, a glowing press release designed to further damage the
reputation of Linux developers.

An SCO spokesman noted that SCO's public relations office had already
photographed and identified thousands of alleged perpetrators, and offered to
divulge the hair color and dietary habits of certain assailants, to journalists
who would sign a non-disclosure agreement.

This would lead to exciting new opportunities for profit, analysts at Deutsche
Bank and the Royal Bank of Canada indicated. "Literally hundreds of
millions of people share hair color and potentially even fundamental dietary
requirements with our adversaries. Rather than forcing these people to dye their
hair and investigate alternative sources of MDAs, SCO plans on offering licenses
that will permit these people to continue their lives without fear of litigation
from SCO. Even people who don't realize how much basic genetic information they
share with the vile and violent anti-American extremist criminals, can buy that
most valuable commodity, peace of mind, from SCO. The opportunities are
unbounded!"

An SCO spokesman indicated that nobody needed to fear litigation. "We're
just rolling this scheme out," he noted. "We've already entered
into negotiations with several individuals who are very rich and very blonde.
We've sold three licenses already; Bill Gates and ... um, other parties who
wish not to be named yet."

Meanwhile, in the absense of more pressing duties, the company's janitorial
custodian and part-time webmaster took the opportunity to rearrange the
website's contents.

Have I got all the essential facts included and correct?

[ Reply to This | # ]

OT: The Globe and mail: SCO's chihuahuas
Authored by: rakaz on Thursday, December 11 2003 @ 01:15 PM EST
This showed up on Google News a couple of minutes ago:
http://www.globetechnology.com/servlet/story/RTGAM.20031211.gtletdec11/BNStory/T
echnology/

Go Gary!

[ Reply to This | # ]

Pamela, please consult someone should have explained it to you.
Authored by: bitserve on Thursday, December 11 2003 @ 01:34 PM EST
SYN-cookies can not prevent or stop SYN floods. TCP/IP has a limitation in that
it is susceptible to SYN floods because of the three way handshake. There is no
work around. SYN-cookies only aid in weathering a SYN flood attack.

When the host receives a SYN, it must send an ACK back out to the source IP
address of the SYN, whether it is spoofed or NOT. SYN flood attacks typically
will overwhelm your TCP stack by sending you so many SYNs that you reach the
maximum number of open TCP connections, as each connection sends out an ACK and
waits on a SYN ACK in return. When you hit that maximum, new connections are
going to be refused.

What a SYN-cookie does is not even consider it as a connection until the source
of the SYN replies to your ACK. It's still possible to get enough SYNs to cause
your kernel to not be able to keep up with this process. So your TCP stack could
still be too busy to accept any new connections and send out any new ACKS, even
though it will have available TCP connections becuase none have been ACKED yet.
SYN-cookies only increase the amount of SYNs that your host can weather.

If you don't believe it, enable SYN-cookies on a machine offering a service on
a TCP port and give me permission to DOS it. You'll quickly notice that others
trying to use the service are effected.

What you typically want to do to fight a SYN flood is to go to your router
upstream to determine where further upstream the packets are coming from
(because you can't tell based on the spoofed source addresses). Then follow the
path of routers until you get back to the source. This requires the cooperation
of whoever is maintaining each one of the Internet routers. So this never
happens, and if there is more than one source, good luck. So the only
alternative is to fight your DOS attack using an attack mitigator from Top Layer
or something similar. These specialized devices can move the burden of doing the
TCP handshakes away from the server and to themselves, and their specialized
hardware can do it faster and more efficient than your server.

Anyway, if SCO reported a SYN flood, and no one else could verify problem, then
it sounds like they WERE doing a good job at handling it. Without the specifics
of knowing what host and service or even router was being DOS'd I wouldn't try
to verify it and think I knew what I was talking about.

[ Reply to This | # ]

Pamela, someone should have explained it to you.
Authored by: bitserve on Thursday, December 11 2003 @ 01:37 PM EST
SYN-cookies can not prevent or stop SYN floods. TCP/IP has a limitation in that
it is susceptible to SYN floods because of the three way handshake. There is no
work around. SYN-cookies only aid in weathering a SYN flood attack.

When the host receives a SYN, it must send an ACK back out to the source IP
address of the SYN, whether it is spoofed or NOT. SYN flood attacks typically
will overwhelm your TCP stack by sending you so many SYNs that you reach the
maximum number of open TCP connections, as each connection sends out an ACK and
waits on a SYN ACK in return. When you hit that maximum, new connections are
going to be refused.

What a SYN-cookie does is not even consider it as a connection until the source
of the SYN replies to your ACK. It's still possible to get enough SYNs to cause
your kernel to not be able to keep up with this process. So your TCP stack could
still be too busy to accept any new connections and send out any new ACKS, even
though it will have available TCP connections becuase none have been ACKED yet.
SYN-cookies only increase the amount of SYNs that your host can weather.

If you don't believe it, enable SYN-cookies on a machine offering a service on
a TCP port and give me permission to DOS it. You'll quickly notice that others
trying to use the service are effected.

What you typically want to do to fight a SYN flood is to go to your router
upstream to determine where further upstream the packets are coming from
(because you can't tell based on the spoofed source addresses). Then follow the
path of routers until you get back to the source. This requires the cooperation
of whoever is maintaining each one of the Internet routers. So this never
happens, and if there is more than one source, good luck. So the only
alternative is to fight your DOS attack using an attack mitigator from Top Layer
or something similar. These specialized devices can move the burden of doing the
TCP handshakes away from the server and to themselves, and their specialized
hardware can do it faster and more efficient than your server.

Anyway, if SCO reported a SYN flood, and no one else could verify problem, then
it sounds like they WERE doing a good job at handling it. Without the specifics
of knowing what host and service or even router was being DOS'd I wouldn't try
to verify it and think I knew what I was talking about.

There is no such thing as a "Patch to all Operating Systems that I'm
aware of, .. to stop this sort of attack". Come on, get real! It's a
limitation in the protocol. There is not patch.

[ Reply to This | # ]

Site down
Authored by: Anonymous on Thursday, December 11 2003 @ 01:57 PM EST
I just noticed your site was down, giving a 'too many connections error'.

Quick somebody, issue a press release and blame SCO!!!

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: linuxbikr on Thursday, December 11 2003 @ 02:08 PM EST
Well, for what it is worth, I have some additional information to add:

I was in contact with some folks inside XO and they confirm the following for me:

  1. www.sco.com is not hosted on XO hardware. They have their own hosts outside of the XO network (this is also confirmed by the various traceroutes posted earlier).
  2. XO did not suffer any unusual network traffic yesterday on any of its network segments including the ones into SLC. This was mentioned by folks who called the support center but getting inside from folks at network operations only strengthens this since the tech support folks won't always tell the truth. ;)
Since reports indicate the traffic dumps into Center7 and disappears, the problem is clearly on SCO's side of the house. None of the networks are having trouble reaching out to *.sco.com, the sites themselves are simply not responding.

Nothing like catching SCO in a bald faced lie. They took themselves out or are having problems with their ISP (which is a Canopy Group company, BTW). No one in the open source community has attacked them in the past 24 hours.

For what it's worth.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: linuxbikr on Thursday, December 11 2003 @ 02:09 PM EST
Well, for what it is worth, I have some additional information to add:

I was in contact with some folks inside XO and they confirm the following for me:

  1. www.sco.com is not hosted on XO hardware. They have their own hosts outside of the XO network (this is also confirmed by the various traceroutes posted earlier).
  2. XO did not suffer any unusual network traffic yesterday on any of its network segments including the ones into SLC. This was mentioned by folks who called the support center but getting inside from folks at network operations only strengthens this since the tech support folks won't always tell the truth. ;)
Since reports indicate the traffic dumps into Center7 and disappears, the problem is clearly on SCO's side of the house. None of the networks are having trouble reaching out to *.sco.com, the sites themselves are simply not responding.

Nothing like catching SCO in a bald faced lie. They took themselves out or are having problems with their ISP (which is a Canopy Group company, BTW). No one in the open source community has attacked them in the past 24 hours.

For what it's worth.

[ Reply to This | # ]

Well some of the sco services are up
Authored by: iZm on Thursday, December 11 2003 @ 02:13 PM EST
The following servers are up:
projectudi.sco.com 216.250.128.13
artemis.sco.com 216.250.128.33
ftpput.sco.com 216.250.128.33
docsrv.sco.com 216.250.128.247
uw713doc.sco.com 216.250.128.245

I find the most interesting one is projectudi.sco.com.
This is the same server as their ftp server. The ftp is
down but http://projectudi.sco.com is very responsive.

---
Stupidity, like virtue, is its own reward.

[ Reply to This | # ]

Groklaw attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 05:28 PM EST
I saw the first page that replaced the site. It stated something about Groklaw
being Ddos'ed by slashdot crowd.

I am wondering if some of the statments made here are true now. It appears as
though Groklaw cannot defend it's self against Ddos attacks either. Does this
make Groklaw admins incompetent? After all, the defense for these types of
situations are built in to the Linux kernel or can be easily stopped by a
router, (So Grokkers say). I wish this wouldn't have happened to Groklaw
because it gives some substance to SCO's claims that someone is flooding their
webservers with requests.

I know what happened here. The DB just couldn't handle /. but it is a little
ironic. Don't you think?

At least you're back. :)

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 05:31 PM EST
For the record, all the following IPs are up and showing the SCO site:
http://216.250.128.4
http://216.250.128.5
http://216.250.128.10
http://216.250.128.20-25

I call BS on the DoS.

[ Reply to This | # ]

DOS explained: Charles
Authored by: Anonymous on Thursday, December 11 2003 @ 05:32 PM EST
I have leant a lot about the law, and stock manipulation from the site so I
thought I would try and return the favor by explaining DOS and DDOS attacks.

DOS = Denial of service.

To perform a successful DOS attack you have to be able to remotely consume one
of the resources needed by the server under attack. In this day and age a server
can be a very large distributed system spread over the world. Such a system is
very hard to attack, as the resources available to service the requests are
large. If the server is a single machine at the end of a single network
connection an attack can be mount and succeed.

Attack no 1.

Get a story that links to the machine accepted on slashdot.

I start with this example to illustrate the concept. Slashdot has a lot of
readers, Slashdot can service those readers. The resources available to service
the linked to story are not so deep so the Slashdot reader base can swamp the
resource of the linked to machine. A few of the readers get a slow response, the
rest get no response. While the Slashdot readers are trying to suck up info, all
other users are denied the linked to sites service. This is a legal distributed
denial of service attack. Distributed because it is caused by requests from all
over the place, denial of service because the normal user lost access to the
site.

Such an attack will bring all communication to the network segment to a crawl if
the limiting resource is network bandwidth. If the limiting resource is the web
server then services offered by other machines on the network segment will
continue to run ok while network recourses are available.

People have documented such &#8220;attacks&#8221; and given such
&#8220;attacks&#8221; a name, the Slackdot effect.

Attack no 2.

Ask a few users to download large files from the system.

An example, how about we all start downloading the linux kernel 10 times from
the sco file server starting now. Groklaw has a lot of readers, if enough
respond we should be able to swamp there bandwidth with linux download requests.
As the web server and the file server are on the same network segment this will
bring the SCO web server to a crawl. This is another form of legal distributed
denial of service attack. Distributed because it is coming from all over the
place, denial of service because our swamping of the network segments with
packets servicing our linux downloads is denying the normal user access to the
SCO web server.

This is not a very effective attack, humans lose interest in such juvenile
behavior pretty quickly. Computers however, mundane that is the stuff they
like.

Attack No 3

Now we get into the illegal version. The most affective attack first. You gain
access to random computers on the net, and run scripts to do exactly what was
done under attack number 2, but because a computer is now generating the request
you can go for files smaller than the linux kernel and still keep things busy.
The server under attack is now serving attack computers that are doing nothing
more that chucking away the served info. This is the classic distributed denial
of service attack. The attack just keeps adding requesting machines to the
attack until your server hits one of it's resource limits. You as the server
administrator start looking for the IP address of the machines doing the request
and start refusing to service such requests.

The computers performing the request will not belong to the attacker, as
mentioned they will be random computers on the net. The attacker will have
gained access to those computers using security flaws in the OS. Windows
machines have lots of holes in there OS but tend not to be well connected to the
net so you need a lot of window machines to mount an attack against a strong web
server. Unix boxes are harder to get control of, but tend to have good net
connections so a few Unix boxes can mount a good attack. Well connected Unix
boxes also tend to have good administrators who get really pissed off and start
looking at logs to try and track you down if you use their machine for such
purposes.

A serious DDOS will not even break into a machine using his own machine, that
will be done through a machine in a country that is unlikely to co-operate with
the victim in finding the culprit. If your attacking someone in the US you
collect you attack machines using a computer you broke into in IRAN, that sort
of thing.

The defense against this form of attack is to farm out your web hosting to
someone who has a system that can service the whole dam lot, the attack machines
no matter how many and how well connected and at the same time real users.
Akamai as an example claims to have 15000 servers world wide. You would need a
lot of resource to bring that lot down. This solution also deals with attack no
1 and attack no 2.

Attack number 4

SYN attacks

Now we get into the old hat small time stuff. A TCP connection is established in
4 stages. The user sends a SYN with a user sequence number, the server takes
note and sends the user a SYN with a server sequence number, the user ACKs the
server SYN, the server ACKs the user and away we go.

If the resources consumed by the server when it receives a user SYN are not
severly limited the attacker can bring the server down by sending a lot of
SYN's with different IP and port numbers. The server tries. It sends back
server SYN to all the IP addresses it can. Most just go nowhere but the server
is left with resources tied up waiting for the reply.

The solution is simple. Don't tie up resources until you have a reply to the
server SYN, all you need to keep from the user SYN is the users IP, the users
port, the users SYN number, the server port, the SYN value you sent out to the
user and when you did it. Thirty two bytes more than covers it.

If the server SYN is predictable the attacker could send the user SYN and the
user ACK to the server SYN. A server sending back predictable server SYN numbers
is a security hole so it just doesn't happen.

A modern TCP/IP stack will deal with a SYN attack as just descibed ( that is not
allocate a lot of resources until the user has responded to the server SYN) and
not raise a sweet. A SYN attack is old and ineffective.

Attack number 5

A distributed SYN attack

This has to be mentioned as this is what SCO claimed. If you have control of the
computers to perform a distributed attack you would go for attack no 3. I
suppose a distributed SYN attack would be many machines mounting a SYN attack.
Why would you do it, a good TCP/IP stack will use a little more memory no more.
If you have control of a distributed system you connect up to the server and
load the server until it dies.

Now when Groklaw recovers from attack no 1, I will post this.

Disclaimer

I should end this by pointing out that I do not mount server attacks. I know
about this stuff because I have written an embedded TCP/IP stack and have thus
read the RFC and thought about the issues.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 05:35 PM EST
Looks like www.sco.com (and ftp.sco.com) is down again.

traceroute www.sco.com
....
14 158 ms 158 ms 158 ms p4-0-0.MAR1.SaltLake-UT.us.xo.net [65.106.6.74]
15 161 ms 161 ms 161 ms p0-0.CHR1.SaltLake-UT.us.xo.net [207.88.83.42]
16 * * * Request timed out.
17 * * * Request timed out.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Markie1006 on Thursday, December 11 2003 @ 05:41 PM EST
First post from a lurker, but I found this while googling for something else and
thought I'd throw it into the pot.

Apparently they were very aware about SYN attacks, and have been since the CERT
bulletin in 2000.

This is a bulletin announcing various patch upgrades to Unixware, one of which
addresses this very issue - (dated 19 Apr 2000).

The original ican be found at http://www.aplawrence.com/News/sconews0052.html


From: Rhonda Powers <rhondap@caldera.com>
Subject: Network Maintenance Supp. for UW213
Date: Wed, 19 Apr 2000 15:45:39 GMT



The following Support Level Supplement (SLS) is available for downloading
from the "SLS" directory at ftp.caldera.com:

ptf4001o: Network Maintenance Supplement

URLs associated with this SLS are:

ftp://stage.caldera.com/SLS/ptf4001o.Z
ftp://stage.caldera.com/SLS/ptf4001o.txt


This SLS installs on the following platform(s):

SCO UnixWare 2.1.3

Description:

This SLS addresses a variety of problems that have been identified in the
networking components of this operating system.

This SLS can be installed on SCO UnixWare 2.1.2 provided
SLS ptf3280l has already been installed.

SLS ptf4001o corrects all of the following problems.

Problems corrected in SLS ptf4001b:

1. IP alias of name server fails.

2 In some cases, TCP does not return an ACK in response to a received
packet.

3. After days of heavy usage nfsd hangs. UDP performance is poor.

4. Various PANICs occur.

5. System can 'hang' on boot up.

6. There are locking problems in rawip and route.

7. Server application can receive a 'protocol error' when executing
accept(3N) which stops the server from accepting any new connections.

8. If installing a new NIC driver in IHV format, and the IHV diskette is an
S5 filesystem, the installation process will hang.

9. Data loss occurs on a socket when shutdown(3N) is called.

10. Missing SIGPOLL on close if using Unix Domain Sockets in async mode.

11. There is a memory leak in libnsl.

12. A system hang can occur if all ports are in use.

13. lockd performs timeout requests too slowly; it was hardcoded to 15
seconds. (A new environment variable, CLIENT_DG_CREATE_TIMEOUT, was created to
do this.)

14. SO_KEEPALIVE is not set by default on specific listening ports.

15. The system can hang after hours/days of heavy network usage on MP
systems.

Problems corrected in SLS ptf4001h:

1. Semaphores can be consumed by a server application.

2. If UW2compat is installed, a threaded server application can receive
spurious errors from socketpair(3N).

3. A Netscape client can receive 'connection reset by peer' when
downloading files from a Netscape server.

4. arp hangs during boot on multiprocessor UnixWare 2.1.3.

5. Configuring system as NIS client can cause a memory leak.

6. An application trying to make a connection to a non-existent service can
cause the application to receive an unexpected SIGPIPE signal.

7. There is vulnerability to TCP SYN Flooding Attack CERT* Advisory
CA-96.21.

8. There is vulnerability to LAND Attack CERT* Advisory CA-97.28.

9. If the DISPLAY variable is set to a remote machine, an X binary will
fail with "Error: Can't open display:".

Problems corrected in SLS ptf4001i:

1. A PANIC occurs in the function si_bcmp() under heavy use of UNIX domain
sockets.

2. A TLI application can hang trying to do a strgetmsg().

3. The system can potentially PANIC or hang due to incorrect locking code
in udpclose(), icmpclose() and ripclose().

4. Telnetting into a system takes longer after UnixWare 2.1.3 is
installed.

5. A new /etc/conf/pack.d/tcp/space.c tunable was introduced:

int tcp_out_size = 64;

6. SLS ptf4001i is now aware of UW2compat 7.1.0, and can be installed on
systems which have that package installed.

Problem corrected in SLS ptf4001j:

1. getsockopt(3N) TCP_NODELAY returns the opposite value compared to
UnixWare 7.

Problems corrected in SLS ptf4001k:

1. PANIC in getq_l() called from sockmodrsrv() under extreme
circumstances.

2. PANIC seen when TCP_NDEBUG is set in the etcp space.c file.

3. In a multithreaded server application that executes the setsockopt(3)
function, some of the threads can hang.

4. SLS ptf4001k is now aware of UW2compat 7.1.1, and can be installed on
systems which have that package installed.

5. Client processes can hang in getmsg() when trying to connect to a server
process running on the same machine.

6. Various system PANICs that were due to memory being reused. With the
KMA PARANOID driver installed these were seen as PANICs from tcp_freespc(), due
to the same TCP control block being freed twice.

7. A 'denial of service' PANIC when the KMA PARANOID driver is installed,
which was caused by an incorrect call of getsockopt().

Problems corrected in SLS ptf4001l:

1. rpc function core dumps.

2. t_snd() can return unexpected TSYSERR/EPROTO errors.

3. If you execute two remote commands in sequence to an SCO UnixWare 2.1.3
system, with ptf4001k installed, it can hang, for example:

rsh <UW213_machine> ls
rsh <UW213_machine> ls

or:

rcp <UW213_machine>/tmp/foo foo
rcp <UW213_machine>/tmp/foo foo

4. PANIC in do_ERROR().

5. Make writing greater than the MTU to a broadcast address configurable.

6. inetd loops on accept and reports accept: No such device or address.

Problems corrected in SLS ptf4001m:

1. Applications can experience memory loss if they continually call
connect(3).

2. Executing rsh continuously in a loop can result in the error:
"UX:rsh: ERROR: socket: protocol failure in circuit setup".

Problem corrected in SLS ptf4001n:

1. /var/adm/pmd.log grows exponentially with the following message:
APMT: Error during GetNextEvent. > (PM_THREAD_GETNEXT_FAILED) (856)

Additional problem corrected in SLS ptf4001o:

1. t_listen fails with t_error TBADQLEN. In a TLI/XTI application using
t_sync, the qlen value for the specified transport endpoint can be incorrectly
set to zero locally within the transport library.

[ Reply to This | # ]

Backscatter
Authored by: gvc on Thursday, December 11 2003 @ 06:09 PM EST
There's an article in Slashdot that suggests that "backscatter" evidence supports SCO's contention. The concept of backscatter is well founded but there isn't enough evidence presented in the article for me to form a conclusion.

Does somebody have the tools to evaluate this?

[ Reply to This | # ]

SLC FBI is on the case
Authored by: Anonymous on Thursday, December 11 2003 @ 06:15 PM EST
I am a member of the media in Salt Lake City. I contacted the Salt Lake office
of the FBI today and confirmed that SCO has been in contact with the FBI
regarding the alleged attack.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: snorpus on Thursday, December 11 2003 @ 06:38 PM EST
I don't think I've seen PJ quoted anywhere, accusing anyone, of DDoS or anything else. The site experienced a heavy load (I could practically hear that mySQL database groaning); as the load returned to normal levels, so did the response.

It remains to be seen what caused SCO's outage.

---
73 de KQ3T

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 06:41 PM EST
So here's my besst guess. Some Admin named Bob tripped over a cord, and
brought down the server. He gets a call from his manager, saying "what's
up over there?"
He says "not my fault. It was...an...attack....a...SYN DDOS attack...
yeah."
So the manager writes up the report, and somebody issues a press release.

[ Reply to This | # ]

Are SCO's net engineers really that stupid?
Authored by: jcomeau_ictx on Thursday, December 11 2003 @ 07:01 PM EST
216.250.128.12 may actually have been DDoS'd. Then SCO's net engineers would
have called XO's net engineers and asked them to null route 216.250.128.12.
That's what I would have done to protect the rest of my network.

XO's engineers may not have told the front-line customer support droids about
the null route. So when you called they thought the problem was at Caldera/SCO.

Does that not take Occam's razor to the story and shave all the unnecessary
growth? I'm not an SCO fan either but can't imagine everybody working there is
stupid.

If someone else has already posted this, sorry I didn't go through all the
replies.

[ Reply to This | # ]

Centershift
Authored by: Doitroygsbre on Thursday, December 11 2003 @ 07:12 PM EST
While trying to find info about the previous attacks SCO claimed to have suffered, i found this article referencing another company in Utah that suffers when SCO is attacked ...

to quote the article (8/27/03): "As neighbors on the Internet and within the same hosting facility, Centershift has been made to suffer greatly as SCO has battled with the Linux, Unix and open-source communities. Each DDoS attack aimed at SCO over the past 4 months has crippled not only SCO, but Centershift as well," James Hafen, Centershift's chief technical officer and senior vice president, told eWEEK in an e-mail on Wednesday

has anyone checked to see if they were having any problems? I know their web site is up now, but it's a day later.

also, I belive SCO has claimed three (maybe it was four) previous DoS attacks going back as far as May of this year. Don't you think they would have learned to protect their systems better than this?

[ Reply to This | # ]

Grim
Authored by: dmomara on Thursday, December 11 2003 @ 07:21 PM EST
http://linuxupdate.sco.com/scolinux/SRPMS/kernel-source-2.4.19.SuSE-340.nosrc.r
pm

[ Reply to This | # ]

  • Grim - Authored by: dmomara on Thursday, December 11 2003 @ 07:29 PM EST
Probably a real attack
Authored by: Anonymous on Thursday, December 11 2003 @ 07:22 PM EST
More comments on the SCO attack, sounds like they did/are experiencing a real attack.

News.com.com is reporting the attacks have increased, and quotes a source from CAIDA vouching that backscatter reports show SCO's website and FTP server were attacked;
A person at Linux Electronics is reporting that the FBI has commented that a complaint from SCO was recieved (no comment about investigation, though -- as would be expected)...

[ Reply to This | # ]

E-mail Center7 clients
Authored by: tichael on Thursday, December 11 2003 @ 07:24 PM EST
We should all contact these companies to see if they had bandwidth issues due to
this attack. These companies might also not be aware that they are being
associated with SCO. They might not be happy to hear that.

If we put pressure on Center7's clients, we might be able to get some more
information.

[ Reply to This | # ]

The Return of www.Sco.com
Authored by: LinkJunkie on Thursday, December 11 2003 @ 07:26 PM EST
They're baaaaaack...

Sco.com

I just brought up a page anyway

[ Reply to This | # ]

Neat Netcraft Graph
Authored by: snorpus on Thursday, December 11 2003 @ 07:34 PM EST
This link was posted much earlier, but the thread is so long, who reads the old stuff?

For a near-real-time graph of the SCO outage, check this graph at Netcraft.

www.sco.com becomes unavailable at about 1145Z on Wednesday (6:45am EST, 4:45am MST), is available for about a half hour at 1200Z Thursday, and has been offline since.

---
73 de KQ3T

[ Reply to This | # ]

  • Bad Link - Authored by: snorpus on Thursday, December 11 2003 @ 07:54 PM EST
A new version of history
Authored by: PJP on Thursday, December 11 2003 @ 07:51 PM EST
There is an interesting article about the attack on TechWeb. yhe first interesting part is:

    A special cyber-security unit within the U.S. Secret Service was investigating the attack

So is it the FBI or Secret Service? They don't even seem to get that story straight.

Next they say:

    With the company's Internet bandwidth consumed, the attack shutdown the company's mail, FTP (file transfer protocol) and intranet servers for about an hour and a half. However, when the company restarted the systems, the attacker located the Internet addresses of the mail and FTP servers and launched a new attack on those systems, Carlon said.

So those e-mail and ftp servers that people have been looking at were obviously the wrong ones... They must be because they go on to say:

    Because the assailant is capable of shifting the attack to counter any defensive action taken by SCO, the company has decided to keep the web site, e-mail and FTP servers offline until the attack subsides.

I never knew Linden existed in soma alternate reality, but obviously it does.

[ Reply to This | # ]

OT: Important - More trouble for SCO in court
Authored by: Anonymous on Thursday, December 11 2003 @ 07:52 PM EST
Okay, there's some new documents on the docket.

I am sure most of the attention will be on 88 (transcript of the hearing), and
93 (IBM reply brief in support of motion to strike affirmative defenses - this
is so good, and SCO's previous filing so bad, that's it's comical).

Anyway, there is an interesting and potentially important point in the summary
which is easy to miss:

89-2 Docket Text: Magistrate Notice of Hearing Motion hearing set for 10:00
1/23/04 for [83-1] motion to extend time for pla to respond to dft IBM's third
set of interrogatories and third request for production of documents, set for
10:00 1/23/04 for [73-1] motion to strike the 5th, 15th, and 19th affirmative
defenses asserted by the SCO Grp in its Answers to IBM' Amended Counterclaims,
set for 10:00 1/23/04 for [66-1] motion to Compel Discovery, set for 10:00
1/23/04 for [52-1] motion to extend time to 10/24/03 for pla to resp to
mot/compel, set for 10:00 1/23/04 for [51-1] motion to extend time to respond to
dft IBM's second set of interrogatories and second request for production of
documents, set for 10:00 1/23/04 for [44-1] motion to compel Discovery To be
held before Judge Wells cc:atty ( Ntc generated by: JD)


Now I'm racing ahead, but I'll assume the summary is correct (which it hasn't
always been) but this if correct, it's fascinating.

83-1 is the 3rd set of interrogatories, which is a new-ish issue - so not that
surprising that it's on the list

73-1 is the affirmative defense striking issue, which IBM just filed their reply
brief - so not that surprising that it's on the list

66-1 is SCO's motion to compel discovery - so not that surprising that it's on
the list

44-1 is IBM's motion to compel discovery - so not that surprising that it's on
the list


But here's where it gets INTERESTING:

51-1 is SCO's motion to extend time to respond to IBM's second set of set of
interrogatories. Now, I haven't checked the dates, but SCO have responded to
these by now, some considerable time ago, so SCO have probably (I haven't
checked the dates) treated this as if it was granted, not withstanding the fact
that IBM found their responses inadequate and filed a 2nd motion to compel
discovery (which has in part sort of been merged into IBM's first motion to
compel discovery).

Why is the court revisiting a SCO delay that took place weeks ago?

IANAL, but I don't see how this could be good for SCO.


And here's where it gets VERY INTERESTING

SCO's 52-1 motion (a motion to extend time) is also on the list.

Now IBM replied to this (53-1) opposing this, suggesting SCO may have an
improper purpose by extending time.

Then what happened was SCO filed a substitute motion (54-1) for the same
purpose, which was granted (55-1).

In other words, 52-1 seemed sort of moot.

Yet why is the court revisiting this?

IANAL, but I don't see how this could be good for SCO.

[ Reply to This | # ]

PJ and/or someone qualified
Authored by: moogy on Thursday, December 11 2003 @ 07:55 PM EST
While discussing the SCO [pseudo]-attack in my irc channel
I suggested some letter writing to web sites that were covering
the story by simply echoing SCO's Press Release.

One of my friends who did so (and who is also now
a happy groklaw reader :) got a reply from a
journalist asking his help to co-author an article
on the subject. My friend does not feel qualified
and turned it over to me, and I also do not feel
qualified and so I am turning to groksters.

I seek help from someone better qualified then myself.
Click on the "moogy" above and send me email.

---
Mike Tuxford - irc.fdfnet.net #Groklaw
First they ignore you, then they laugh at you,
then they fight you, then you win. --Gandhi

[ Reply to This | # ]

Theory - (devil's advocate)
Authored by: Anonymous on Thursday, December 11 2003 @ 08:04 PM EST
I think a more likely scenario is that:

1)SCO was hit by an attack
2)Their press release incorrectly identified it as a SYN attack because they
aren't techies, and the real message was lost in translation.
3)When the attack occured, they took sco.com off-line until things calmed down.
4) By the time the public got word of it, and people began to ping their servers
to see what was going on, the attack had already ended, so there was no longer
any "attack" evidence to be gleaned.

Does that sound plausible?

After all - let's admit. It is perfectly plausible that they WOULD get
attacked. I am afraid of being too hasty to jump to conclusions - that's all.
We have a reputation to uphold!

My2Cents - Mike A.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 08:04 PM EST
Ah yes, the SYN FLOOD attack - I'm sure that the world's foremost hackers went
out of their way to dust off that old chestnut, circa late-90s, just for SCO.
Maybe the hackers figured that a dated, obsolete company deserved a dated,
obsolete attack. I guess next we can expect to see a bitchslap attack, followed
by the Mitnick spoof and the Morris Internet Worm of 1988.

Fruity

[ Reply to This | # ]

Check This Out
Authored by: Alex on Thursday, December 11 2003 @ 08:12 PM EST
There are 16 comments as of my posting this. More than ten of them point to this
story. We are doing an excellent job people, and the press is starting to pick
up on it.

http://www.harktheherald.com/modules.php?op=modload&name=News&file=artic
le&sid=8620

Alex

---
Hey Darl!! Did Ross Perot draw your chart?"

[ Reply to This | # ]

New Document on TuxRocks
Authored by: rand on Thursday, December 11 2003 @ 08:18 PM EST
IBM's Reply Memorandum in Support of Motion to Strike Affirmative Defenses in PDF form.

---
IANAL, etc.

[ Reply to This | # ]

SCO -> Linux+Apache
Authored by: lpletch on Thursday, December 11 2003 @ 08:24 PM EST
Netcraft has SCO back with Linux and Apache Here

[ Reply to This | # ]

Where is the story of Charles?
Authored by: Anonymous on Thursday, December 11 2003 @ 08:26 PM EST
Can anybody tell me what happened to the comment of a person calling himself
Charles, posted just after groklaw went back to normal again? I read some
comment claiming the database choke was a result of link-hits by slashdot
readers, though I recall something like Charles claiming it personally (though
not by habit). For the ones who read it, I'm referring to the story explaining
different 5 types of DoS attacks, including the /. effect. Does anybody have a
clue? (db-rollback, censorship, handed over to the feds)

[ Reply to This | # ]

Indirect confirmation of backscatter
Authored by: Anonymous on Thursday, December 11 2003 @ 08:33 PM EST

The DShiel d summarary for 216.250.128.12 shows that logs have been submitted reporting "attacks" from www.sco.com on 2003-12-11.

These are unlikely to actually be malicious attacks by SCO against the DShield submitters, but instead are very probably backscatter from a DoS showing up in logs.

Unfortunately, we do not know how much IPv4 space is covered by the logs submitted to DShield, so this is just a qualitative indication.

Note similar reports for 216.250.128.13

[ Reply to This | # ]

SCO Grows Your Business??
Authored by: Anonymous on Thursday, December 11 2003 @ 08:41 PM EST
I wonder if its a result in the quality of their product?

[ Reply to This | # ]

Syn-FUD
Authored by: Sunny Penguin on Thursday, December 11 2003 @ 08:48 PM EST
I am sorry in advance if I offend anyone.
I was tracerouting with everyone else this morning.
That said, I have realised something:

SCO may have been attacked, or not.
This "attack" is not the issue.
Did SCO lie about this alleged attack is not the issue.

There are some people who believe America never went to the moon. We can look
very silly and argue with the public as to the moon landing being a lie. Most
people would understand the moon landing better than a TCP/IP attack, or why
this attack did not happen. Face it folks, we ARE geeks, we do stuff like this
before breakfast.

We revealed some things that SCO did not to want to ever be seen in the
spotlight of media attention.
The issue is SCO has had a major setback in their so called case against IBM.
The issue is SCO has delayed their 4th quarter finance statement.
(because SCO was so profitable, right?)

We have fallen for misdirection just as fast as the media fell for the FUD.
We have been led astray.
Keep your eye on the right hand, do not look at the left.
Nothing up my sleeve.

Let's get back to what we do best, What SCO would rather we did not do,
blasting apart the SCO legal FUD.

Once more, I hope I did not offend anyone.


---
Norman Madden
Chuluota, FL

[ Reply to This | # ]

  • Syn-FUD - Authored by: Jude on Thursday, December 11 2003 @ 09:14 PM EST
  • Syn-FUD - Authored by: Jude on Thursday, December 11 2003 @ 09:21 PM EST
  • Syn-FUD - Authored by: phrostie on Thursday, December 11 2003 @ 09:22 PM EST
  • Syn-FUD - Authored by: gvc on Thursday, December 11 2003 @ 09:26 PM EST
    • Syn-FUD - Authored by: kberrien on Thursday, December 11 2003 @ 09:33 PM EST
      • Syn-FUD - Authored by: Jude on Thursday, December 11 2003 @ 09:39 PM EST
  • Syn-FUD - Authored by: Anonymous on Thursday, December 11 2003 @ 10:31 PM EST
Syn-FUD
Authored by: Sunny Penguin on Thursday, December 11 2003 @ 09:31 PM EST
I am sorry in advance if I offend anyone.
I was tracerouting with everyone else this morning.
That said, I have realised something:

SCO may have been attacked, or not.
This "attack" is not the issue.
Did SCO lie about this alleged attack is not the issue.

There are some people who believe America never went to the moon. We can look
very silly and argue with the public as to the moon landing being a lie. Most
people would understand the moon landing better than a TCP/IP attack, or why
this attack did not happen. Face it folks, we ARE geeks, we do stuff like this
before breakfast.

We revealed some things that SCO did not to want to ever be seen in the
spotlight of media attention.
The issue is SCO has had a major setback in their so called case against IBM.
The issue is SCO has delayed their 4th quarter finance statement.
(because SCO was so profitable, right?)

We have fallen for misdirection just as fast as the media fell for the FUD.
We have been led astray.
Keep your eye on the right hand, do not look at the left.
Nothing up my sleeve.

Let's get back to what we do best, What SCO would rather we did not do,
blasting apart the SCO legal FUD.

Once more, I hope I did not offend anyone.


---
Norman Madden
Chuluota, FL

[ Reply to This | # ]

Embarassing html..
Authored by: kberrien on Thursday, December 11 2003 @ 10:32 PM EST
Now that SCO is back up, I popped back into the older stories, specifically the
"cross you heart and hope to die" duo, and tried out all the links
with, at least, embarassing SCO documentation.

All links still exist and provide the correct content. It's not an exhaustive
search, but it would appear that nothing has been "removed". Links
were for caldera.com, sco.com, ir.sco.com, etc...

Anyone check the ftp sites for source?

[ Reply to This | # ]

SCO Claims Serious Damage In DoS Attack
Authored by: Beam-me-up on Thursday, December 11 2003 @ 10:32 PM EST
http://www.techweb.com/wire/story/TWB20031211S0016

This Quote from a TechWeb Article

"I would say (the attack) has been extremely detrimental to our ability to
operate as a company," Jeff Carlon, director of IT infrastructure for SCO,
said. "It has significantly impacted our ability to support
customers."

Do SCO actually have customers ??

In other parts of the Story they have the Secret Service involved in
investigations of this latest "Attack", now I am not from the US,
but is this the normal agency to handle this type of investigation?

One other thing that comes to mind they claim thet the SYN-Flood took out there
Intranet? If so how could any IT company publish this in the press it is an
admission that they cant manage there own Infrastructure, or the Technology
that they claim is there IP.

Poor SCO they cant win, and continue to show they are not a technology company
any longer!!

---
Beam Me Up Scotty, There no Intelligent life in SCO

[ Reply to This | # ]

OT: Groklaw User Interface
Authored by: Anonymous on Thursday, December 11 2003 @ 11:02 PM EST
When a new story comes out, I find it fairly easy to read through Groklaw
comments. I select Oldest First/Nested and can pretty much read through the
threads in a reasonable, logical order.

However, once a story is mature, I find it very difficult to keep up with new
comments. When revisiting an article, I typically want to see the Newest
Articles first. However, Flat does not work because it shows the article
without context, and I have no way to get back to the thread or even the parent
article.

Nested does not work because although it shows the threads, its not easy to find
the newest comments in the threads. Very long threads make this even more
difficult.

Threaded is likewise unsatisfactory because it doesn't really show you the
newest first.

I am missing something? How do other folks navigate around articles which are
not new but which are still evolving.

What I want is basically Flat mode (Newest First) but with some way to get back
to the parent comment. I think the way Google presents groups is nearly ideal.
But even just a parent link would suffice.

Actually, what I /really/ would like is for this discussion to be relayed in a
newsgroup. Then I could use my choice of any of the excellent news readers
that exist to read the comments in virtually any order I please. No more
waiting for an entire (large) web page to be redisplayed to see if there are any
new articles. Well, I can dream, can't I?

I'm a confessed Groklaw addict. I need a more streamlined user interface so
that I can get my hit with less effort!

:)

P.S. Keep up the good work!

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 11:08 PM EST
I don't remember seeing SCO mentioning SYN flood attack, perhaps wasn't paying
too much attention, but virtually any service can be brought down by
illegitimate TCP connections. Plainly, use any tool that allows you to open a
TCP connection to any port, and open as many as you can. 'nc', for example,
can open TCP connection. If it is a WEB server that is being under attack - even
easier: usually APACHE has a limit of child processes set to something like
100-200 or so. If there is a cluster - then multiply that by the number of
servers, either way it's pretty easy to use up all available processes so that
server will not be responding to any other connections. No bandwidth consumption
- there just are a couple of hundred TCP connections opened, and nothing is
being transfered over them.

I think that's what could have happened to www.sco.com. The rest is just
exagerration.

[ Reply to This | # ]

OT, McBride: Felons pursuing him; Bonus still within reach?
Authored by: belzecue on Thursday, December 11 2003 @ 11:10 PM EST

McBride states that some opensource advocates are convicted felons:

SCO CEO Darl McBride told SearchEnterpriseLinux.com recently that the threats to SCO are not only of a digital nature. McBride said some executives have received death threats, angry late-night phone calls and challenges to fistfights.

"The vast majority of these [threats] have been of the crank-call variety," McBride said. "We have hired the best personal security team. They have worked through these threats and determined that some have come from people with records who have done time in the big house. We take these very seriously."

A comment attached to a Linuxjournal article suggests McBride may still get his 4-quarters bonus despite SCO posting a loss for the 4th quarter:

Re: SEC Filing Reveals Corporate Linux Users Are Ignoring SCO License Demands (Score: 0) by Anonymous on Thursday, December 11, 2003 Nice reporting, Don.

The company will post a huge loss under generally accepted accounting principles (GAAP) but it will no doubt also publish "pro forma" numbers which exclude the one-time charges in Q4 and will show a profit "similar to" 19 cents. This is a fairly common practice. It should post a GAAP loss and pro forma profit for the year.

The Deseret reporter was clearly a bit sloppy and said the combined $17.7 million charges were to pay Boies's firm. This is true of only half that amount, and the other half comes from the BayStar BCF accounting. Only $1 million of that total is actually paid out of SCO's cash.

You are absolutely right that in addition to the extraordinary legal fees, SCO has now disclosed it has hourly billings and smaller contingencies to pay Boies. The $1.6 million figure exactly accounts for the $8 million that Microsoft is scheduled to pay SCO in Q4.

McBride may be able to get SCO's board to forgive the GAAP loss and let him count Q4 among the series he needs based on the pro forma profit. If they don't, he might sue. Only a guess.

[ Reply to This | # ]

And we would have gotten away with it too, if it wasn't for you meddling security professionals
Authored by: BigTex on Thursday, December 11 2003 @ 11:12 PM EST
The word is out in the press:
http://www.siliconvalley.com/mld/siliconvalley/business/columnists/gmsv/7468711.
htm

Siliconvalley.com
Posted on Thu, Dec. 11, 2003

And we would have gotten away with it too, if it wasn't for you meddling
security professionals: Those among you hoping to use SCO CEO Darl McBride's
latest anti-Linux polemic as a sleep aid last night likely had a tough time
finding it (see "Fear and loathing in Lindon"). The company, which
has become a lightning rod for criticism by open source advocates infuriated by
its campaign against Linux, was struck Wednesday by another large-scale
denial-of-service attack. Besides its Web site, the assault also brought down
SCO's e-mail system, corporate intranet, and customer-support operations. Or so
the company claims. According to a number of security professionals, SCO's
story doesn't quite add up. In a post to Groklaw, Denis Hammond, explains why.


"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, 218.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."

[ Reply to This | # ]

Co-founder of Red Hat's open letter to McBride
Authored by: belzecue on Thursday, December 11 2003 @ 11:18 PM EST
An Open Letter to Darl McBride of SCO from Bob Young, Red Hat cofounder (As sent to the editors at G2News, a Linux newsletter, in response to an open letter from SCO defending, in one breath, the SCO suit, the Digital Millenium Copyright Act, and the Supreme Court Decision in the Eldred vs. Ashcroft case).

[ Reply to This | # ]

"SCO's chihuahuas of war"
Authored by: belzecue on Thursday, December 11 2003 @ 11:21 PM EST
"SCO's chihuahuas of war"

Thank you to Gary Layng of Toronto for making me laugh out loud. That image will be with me for days. :-)

[ Reply to This | # ]

Now this tell the real story of why they when down.
Authored by: kb8rln on Thursday, December 11 2003 @ 11:26 PM EST
Look at this SCO is back up.

Look at netcraft report it show that SCO went back to Linux from something unknown. Maybe a beta product called Unixware?

Enjoy,

Richard

[ Reply to This | # ]

SCO NEWS JOURNAL FOR 12/11/2003
Authored by: jmccorm on Thursday, December 11 2003 @ 11:44 PM EST
A light news day in the SCO Universe. Yesterday's speculation regarding the SCO
hacker attack spilled in today. Groklaw lead the charge, calling into question
SCO's account of what happened. Members quickly spread the word to the media,
some of which started carrying an alternative theory regarding the attack. Some
of the thrust into the media was blunted, however, when Groklaw itself
disappeared for a good portion of the day!

http://www.groklaw.net/article.php?story=20031210163721614

At this point, some of the critics are thinking that SCO *was* attacked, or
something happened, but it doesn't match the explanation SCO has told. And
retold. In any event, these news stories don't read as good PR for SCO this
time around.

http://www.techweb.com/wire/story/TWB20031211S0016
http://www.technewsworld.com/perl/story/32372.html
http://news.com.com/2100-7355-5120706.html

But of all the explanation we've seen, why don't they fit the Netcraft data?

http://uptime.netcraft.com/perf/graph?site=www.sco.com

Basic interpretation: Everything was wonderful (online, excellent performance)
until about December 10, 11:00 GMT. Then the SCO website disappeared. Around
December 11th 8:00 GMT, it appeared again for an hour (with fair response time
for the first 30 minutes, then excellent response time for the next 30 minutes).
Then it disappeared again. The web site finally came back up, working great, for
what appears to be to stay, on December 12th at 00:00 GMT. It just doesn't look
like a DDoS attack. It looks like someone simply pulled the plug. And that's
part of what has people wondering.

Back to the issue of the media, reader feedback is starting to enter into the
picture more and more. The affect of feedback on the SCO hacker attack stories
was plain to see. But even reader feedback regarding other issues, such as the
discovery hearing, are starting to get play. I have selected a personal favorite
as an example. Both for its title, "SCO's chihuahuas of war", and
for its very human sounding quality.

http://www.globetechnology.com/servlet/story/RTGAM.20031211.gtletdec11/BNStory/T
echnology/

This publication is not created for or by Caldera International, d/b/a
"The SCO Group". See http://www.sco.com/company/legal/ for a list of
all related trademarks claimed and not claimed by Caldera International.

Private comments, questions, criticisms? jmccorm@yahoo.com

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Thursday, December 11 2003 @ 11:59 PM EST
Not surprising. Have to admit, all this posturing in the press really amounts to
nothing more than hype and a smoke screen.

[ Reply to This | # ]

Closure: Can Blackhole Routing Explain Some Nagging Inconsistencies?
Authored by: brice on Friday, December 12 2003 @ 12:53 AM EST
The idea of sco.com having been "blackholed" has only come up a few
times in the entire past 2-3 days of Groklaw. (I flatlisted both this and the
members only log and searched for "black") I'll try to be brief,
but I think this may deserve a second look, ESPECIALLY from netadmins here who
actually have experience doing backscatter analysis of DDoS attacks.

David Moore at CAIDA has been quoted at
http://news.com.com/2100-7355-5120706.html as having backscatter data supporting
the occurence of a real DDoS attack. In the past couple hours I've decided
Moore is probably worth respecting. There are a few other recent posts here
citing good sources with various cold facts supporting a real DDoS.

This isn't my point.

My point came to me when I was reading some Cisco training stuff about
backscatter analysis (Google for "backscatter tcp udp icmp"). The
two documents I read both describe how backscattered packets need to be caught
using blackhole routers. Maybe there are other methods, but my take was you get
the best dataset this way.

When the victim gets switched over to the blackhole router it becomes
effectively inaccessible from the rest of the entire internet. This is the point
I think is important and I haven't heard about it here during the past two
days. The victim becomes instantly invisible while backscattered packets are
collected. All outbound packets from the victim go to the blackhole router - no
one else sees anything coming out. Effectively invisible. Instantly.

This reminded me of some of the observations that have been - and still are -
nagging netadmins here - about the inconsistencies of sco.com availabilities,
the sharpness of the drop on Netcraft charts, etc.

I am not a netadmin, so please don't flame me about inaccuracies. I am posting
this because recent news makes me wonder if some of the remaining
inconsistencies can't be explained - in part - by things that most netadmins
might not see on a daily basis.

How many of you have actual experience performing backscatter analyses using
blackhole techniques? No one can see what they're not familiar with. I'm not
trying to judge any of you - you're all great! But why waste your time chasing
inconsistencies if there exist - albeit unobvious - explanations? Catching a
blatent PR lie will not instantly throw out SCO's case - you've got lots more
battles to engage.

I'm also not trying to say I'm right. I understand this blackhole technique in
the abstract - I was a math major long ago & I Really Like complex
abstractions - but I have no actual experience doing this. I'm just trying to
bring to light something I think is worth considering again. Especially since it
has been mentioned only two or three times in the past two days. Not two or
three threads - two or three comments.

I'm going to finish this by sticking my head out a little further. This is not
meant as my theory of the "attack", just a thought experiment.
Suppose the FBI got involved last time. They contact a place like CAIDA to set
things up for tracing any future attack. Suppose yesterday's DDoS was real.
Sometime after the attack starts XO.net, SCO's pipe, contacts CAIDA and CAIDA
orchestrates the blackhole routing to collect backscattered packets for
analysis. Maybe CAIDA can even intervene without XO knowing? Suddenly
www.sco.com disappears into the blackhole (sounds nice doesn't it?) while the
attack persists.

Please don't focus on inaccurate details in my scenario just for the sake of
the inaccuracies. I am concerned that too much of everyone's energy is still
focussed on details without asking bigger questions, like are there ways this
SCO off-lining could happen that no one here is familiar with? I'm trying to
stir the pot a little bit.

Back to the FBI for a second and then I'll go hide from the flames.

People here that I have come to respect tried contacting XO both through the
front door and via inside contacts. XO seems to have denied any attack or any
data indicating an attack. Above I asked if sco.com could be blackholed without
XO knowing. Now I'll ask: if the FBI were already involved and had made prior
arrangements, would anybody at XO tell anybody anything?

O.K. I'll leave this post to die whatever horrible death awaits it. But please,
don't get hung up too long on details that won't bring down SCO's case.

Good people need to dog them at every step, and I think Groklaw is a good source
for that.

Peace,
-brice

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Ric on Friday, December 12 2003 @ 02:45 AM EST
But, more interesting, from the Netcraft website: OS, Web Server and Hosting History for www.sco.com
OS      Server Last changed
Linux   Apache
12-Dec-2003
unknown Apache 11-Dec-2003 
Linux   Apache  3-Sep-2003
Linux  
Apache 21-Aug-2003
I've dropped the IP and Netblock Owner for formatting. All IP's were 216.250.128.12, except for the 21-Aug, which was 216.250.140.112.
All Netblock Owners are NFT.
What date was the August "DOS"? And, did this "DOS" tie in with the change to Apache on the "unknown" OS?
If so, then this could have been a configuration issue... however that could happen.
Also interesting, of course, is it's still running on Linux. :)

[ Reply to This | # ]

Latest comment from SCO's sysadmin
Authored by: aug24 on Friday, December 12 2003 @ 06:55 AM EST
From CMPNetAsia
Because the assailant is capable of shifting the attack to counter any defensive action taken by SCO, the company has decided to keep the web site, e-mail and FTP servers offline until the attack subsides.

"Whatever we do the person will be able to modify (the attack) and chase us around, anyway," Carlon said. "When the illegal activity stops, then we can go back and operate normally as a company."

So, in other words, we can't, won't and don't do anything about it. We hope it'll go away. What kind of incompetent sysadmin is that?

Justin.

---
--
You're only jealous cos the little penguins are talking to me.

[ Reply to This | # ]

A special cyber-security unit within the U.S. Secret Service
Authored by: tgnb on Friday, December 12 2003 @ 07:24 AM EST
http://www.techweb.com/wire/story/TWB20031211S0016

"A special cyber-security unit within the U.S. Secret Service was
investigating the attack, and SCO was providing the agency with as much
information as possible, Carlon said."

[ Reply to This | # ]

SCO back online
Authored by: Anonymous on Friday, December 12 2003 @ 08:42 AM EST
http://www.sco.com/ is back online

but no explanation of why they down
http://ir.sco.com/releases.cfm

[ Reply to This | # ]

Hey SCO, Ever hear of a firewall?
Authored by: jerm on Friday, December 12 2003 @ 09:17 AM EST
I got this notice from my firwall this AM:

12/12/2003 04:10:07.016 - Possible SYN flood attack - Source:158.254.XXX.XXX, 53324 - Destination:192.168.XXX.XXX, 2280 - -

It's amazing how a $2300 USD device can protect you from a SYN Flood attack. I guess SCO spent all their money on legal fees?

jerm

---
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.

[ Reply to This | # ]

"Blame the crackers"
Authored by: Anonymous on Friday, December 12 2003 @ 12:38 PM EST
It is all too easy to blame an unknown, 3rd party when your network doesn't function like it should for whatever reason -- for companies have a reputation to held high.

Authorities and security services like this news (and about criminality in general) too. It is in their interest to receive funding and more power to repress/control.

Also see About the distributed denial of service attacks (fefe.de).

Don't get me wrong. I'm not trying to proof anything. Just another thought :)

[ Reply to This | # ]

Help wanted from the community
Authored by: Anonymous on Friday, December 12 2003 @ 01:39 PM EST
I got a reply to my e-mail to InternetWeek.com:
============================
I've looked into this a bit further and I'm in over my head technically. In
particular, I've read over the report on Groklaw.net. Do you have a lot of
Linux background yourself? Is it your assertion that the report on Groklaw is
substantially accurate?

In particular, where did you get the information that a previous outage, which
SCO claimed was a DOS attack, was in fact the site being taken down for
maintenance
=============================

Can somone (Pam?) help me collect a list of links to the best information and
any supporting data?

Here is my initial reply:
===============================
In the interest of giving you complete and accurate (or as accurate
as possible) information, please allow me a couple of days to respond
in full. In the mean time, maybe this will help:

To help explain some of the doubts, lets try an analogy.

Think of the Internet as our system of highways and roads, end user
computers as people's homes, and the end user themselves as the people
in their homes. The server (SCO's server in this case) is a business
who does all of their business strictly through automobile curiers
(packets) and paper (information in the packet.)

A typical business transaction goes something like this:
You send a messenger to SCO introducing yourself and telling them
that you want to make a purchase. The messenger drives to SCO
using whatever route is best (least congestions, road construction,
etc.) SCO acknowledges that you want to do business, records
your home address and sends the courier back to you and waits for
your order.

When the curier arives at your home, you give them a slip with your
order on it and they drive back to SCO. SCO gives your shipment to
the curier (or as much as they can carry) and they bring it to you..
they repeat their trip back and forth between your home and SCO
until you have the full shipment.

In a SYN flood attack, somone sends a lot of curiers to SCO with
fake home addresses. SCO records the address, sends them back to where
it THINKS they came from, and waits for the order. When the curier gets
to it's destination though he finds a empty building, a parking lot,
or somebody who doesn't know what the heck he's talking about... so he
never comes back to SCO. In the mean time, SCO's list of pending
customers starts getting long.. really long... too long. At some point
it can't add more names to the list. At this point all the legitimate
customers are out of luck.. they are lucky to ever see their messenger
again after they first send him out.

In this case, all these curiers may be causing traffic jams somewhere
near SCO. If you imagine cars driving from all around town and all
around the state to SCO, you can see that if there were traffic jams
it would be as they all started to come together (coming off the
Interstate or onto side roads especially) near SCO. In a SYN-Flood
attack, there doesn't have to be traffic jams... there just have to
be enough messengers to keep SCO too busy to do regular business.

Well, it didn't take Linux (and other OS) designers long to realize that
this was problem. So they quickly added options to allow the server
(SCO in this case) to recognize when they were being fooled and drop
the names and addresses of faked requests from their list instead of
just letting the list get bigger and bigger. Because of this a SYN-Flood
attack just shouldn't be very effective, especially against a company
who is supposed to be making it's living writing and selling operating
systems.

On the other hand, in a serious DDoS (Distributed Denial of Service) attack,
somone out there sends a lot of curiers (a LOT of them) to SCO from other
people's homes. Imagine a case where traffic right around SCO's
building is at a standstill. Obviously it would take a lot to clog
all of the main highway's coming into SCO's "town" but by the
time
you get into SCO's general neighborhood the streets are so crouded
it's hard for anybody nearby to do anything.

This is why it's not realistic to belive that SCO's web server was the
victim of a bandwidth-robbing attack. SCO's FTP server is at the very
next address (one door down) and would also certainly see a slowdown.

It appears that there was SOME kind of attack against the SCO web server
early Wednesday morning.
(See article here: http://www.caida.org/analysis/security/sco-dos/ )
You can see that the attack had dropped to very managable levels
by about opening of business. In this case the analysis is done by
counting all of those messengers returning from SCO only to find
no home to pick up their order from. This still doesn't in the least
show WHO is doing the attack.

Could it be a Linux user who is fed up with rediculous claims by SCO?
(See groklaw.net for a long list of claims which are refuted with
verifyable evidence to back up them up.) Sure. If that's the case
I (and most users of Linux and open-source) condemn the responsible
party's actions.

Could it be from SCO themselves in an effort to recover falling
stock prices? (Seems risky, but without help from their upstream
Internet provider, there is no way to say it was them.... and it did
seem to help falling stock prices.)

Could it be from one of the vendors who SCO has completely cut off?
Why not. They may have more to complain about than Linux users
(who in general do not see SCO's lawsuits as a threat.)

The point is that absolutely nobody knows unless someone comes forward
to claim responsibility or the FBI catches someone (which should have
happened by now.)

I hope this gives you a little insight into DDoS and SYN-Flood attacks.
I'll see if I can get you more information and specifics about this
"attack" and previous "attacks" against SCO if you are
considering doing a follow-up article.

[ Reply to This | # ]

CAIDA numbers are odd.
Authored by: Anonymous on Friday, December 12 2003 @ 01:58 PM EST
"Data collected by CAIDA's Network Telescope indicates that the sco.com
site responded to more than 700 million attack packets over 32 hours, according
to the analysis.

"Early in the attack, unknown perpetrators targeted SCO's web servers
with a SYN flood of approximately 34,000 packets per second," CAIDA said.
"Together www.sco.com and ftp.sco.com experienced a SYN flood of over
50,000 packets-per-second early Thursday morning."
---------------

Hmm... 32 hours = 115200 seconds. 700,000,000/115200 = 6076.4 packets per
second.

[ Reply to This | # ]

Summary of some key points
Authored by: UnixGuy on Friday, December 12 2003 @ 02:40 PM EST
Preamble: I posted approximately these comments earlier this morning on another site. (I've edited them a little bit.) Originally I was skeptical that there was any attack at all. Unfortunately this was before I saw the report from CAIDA, indicating that there may have been something to the initial claim. The CAIDA folks are sharp, no question, and that now leads me to think there probably was some attack. However, I still think there is some validity to these points in combination, in particular the point 4 I make about the combination of the outage followed by the OS fingerprint change. Even if there was a DDOS, the evidence suggests to me that any prolonged outage was caused not by that but by something that SCO did, either planned or in response. Anyway, for what it's worth, here you go...

I've spent over 9 years at an ISP, first as president and co-founder, then as head of the systems department. I've spent a lot of time on security in those years. I agree this is provably not a flood-type DDOS attack, and I have some doubts that it was an attack at all.

Four points jump out at me about this.

First, the point other Groklaw readers made immediately is correct - if you could get easy access to the other SCO servers with similar IP addresses, and hence in the same LAN, it nearly proves it was not a bandwidth flood type of DDOS - at least at that point in time - because in that case nothing would be reachable.

Second, if someone called up their Internet provider, XO.net and the XO admins said there was no sign of any bandwidth flood or DDOS going on, I'd believe it - ISPs are always monitoring the bandwidth on dedicated feeds and coloed servers, it's their lifeblood. (Note that this does absolutely not rule out other types of DOS or remote attacks, but it does rule out flooding.)

Third, if I'm reading these reports right, the outage started in the wee hours of the morning, Pacific time. (I saw 1:45am PST one place, 3:00am PST another.) That is pretty much the standard time to do server or network maintenance or a system upgrade, because the fewest people (in the US at least) will be wanting to access it. If you deal with a Tier 1 backbone carrier, or a high-quality ISP, you'll notice that any risky maintenance gets scheduled for around 2am-4am local time, usually 3am for quick stuff. No proof that a DOS could not have happened to start at that time, but it kind of makes you go "Hmmmmm...."

Fourth, and this to me is the clincher - when the server finally came back on line, the operating system identification had changed. According to those Netcraft reports, the SCO server used to be self-IDed as Linux (oh the irony!) now it shows up as something else. (I believe this ID at Netcraft is via low-level fingerprinting of the OS TCP/IP stack, by the way - not necessarily as crude as just looking at the return string from Apache.) Now I really don't think there is any kind of remote DOS which could upgrade their operating system for them!

A kernel upgrade (e.g. to compile in some new options) is not the only thing that could have changed the appearance of their stack. Setting up a very sophisticated or complicated firewall between their server and the net, or setting up some very tweaked firewall rules on the server could have the same result by changing what it does with weird or bogus looking packets. (I do some things like that on my network at home.) In any of those cases, the result is that it would respond to unusual packets (fragmented, weird TCP flag combinations, etc.) differently than before and it would look from the outside like an OS change. However, all these activities are high risk and even higher risk to do remotely. Screw up one line in the configuration, and you are off the network with no way to fix it until an experienced, senior UNIX or firewall guy is at the site sitting down at the console to figure out what went wrong.

My conclusion, therefore: SCO or a contract admin changed something - either upgraded the server remotely, or changed something about their network to enhance security - and when it took them down, they lied about it for the publicity. They might even have done the change in response to a real (but transient) DDOS, but have been mainly knocked down by the unexpected result of their own change. That's certainly happened before, to better folks than them.

Bonus P.S. It just occurred to me that if they did set up a blackhole route, on-site or upstream, that should have totally changed what CAIDA saw coming back in their backscatter analysis. (From SYN-ACK responses, to ICMP Host unreachable or Net unreachable responses.) Someone could ask CAIDA if they saw this change.

[ Reply to This | # ]

  • Fourth: - Authored by: lpletch on Friday, December 12 2003 @ 04:30 PM EST
Security Experts Doubt SCO Was Attacked
Authored by: colin.saxton on Friday, December 12 2003 @ 02:55 PM EST

Quote me within the next month but I believe that this is laying down the ground work in order to get more time to prepare info against IBM...

I could put odds on 2-1 that they are going to say that they have been stressed by the extra workload due to the dos attacks and will need more time to prepare the documents requested by IBM

No doubt they will continue with this story of being attacked through the rest of the year to middle of January

You can see it coming from a mile off!

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Friday, December 12 2003 @ 03:02 PM EST
http://www.caida.org/analysis/security/sco-dos/

caida says yes to whether or not there was a Ddos attack

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Friday, December 12 2003 @ 03:08 PM EST
From an article on Techweb.

"The company estimates the attack cost it about $300,000 in lost
productivity alone, based on estimates that the company pays as much as $25,000
an hour to employees, who were only able to achieve less than half their usual
output. SCO has about 300 employees worldwide."

So say 2 days completely stopped. That about 16 hours.
times 300 that's about 4800 man hours.

So 300000/4800 that's an average of 62$/hour.

Now does that make them the best paying company in the USA by any chance?

pfft!

\

[ Reply to This | # ]

Grok*LAW*
Authored by: djf on Friday, December 12 2003 @ 03:19 PM EST

I am a network engineer. I have worked for entities who have been on the receiving end of various types of DOS attacks. Even with significant hard evidence, it is often difficult to say what exactly has happened during DOS attacks. Most often it is only the symptoms which are visible. Rarely can definitive root causes be determined without a lot of luck and good instrumentation thoughout the network. Given the decentralized nature of the Internet, very few parties are in a position for credible and serious analysis.

I think that as SCO's legal shenanigans grind through the system, there is the danger of filling the lulls with increasing levels of unproductive group-think.

SCO has long ago squandered all goodwill in the Free/Open Software community. Signs are beginning to show that traditional media outlets are beginning to question and present SCO's claims more carefully. Even the tenor of the transcript in the 5 Dec 2003 hearing shows that the court may be leaning towards skepticism of SCO. Because credibility is a powerful advantage in this situation, I would prefer to have Groklaw sticking to facts rather than trading in what, frankly, amounts to wild speculation.

While CAIDA's report is (IMHO) far from absolutely definitive, it shows the subtlety which network analysis requires.

Groklaw should stick to the law, where it shines as a beacon through the bewildering place that is the US legal system.

[ Reply to This | # ]

CAIDA Network Telescopes, Blackholes & Grok*Law*
Authored by: brice on Friday, December 12 2003 @ 04:23 PM EST
This will be my last 2 cents on this DDoS topic. I think it is time to call off the dogs and move on. I especially agree with the "Grok*Law*" thread a few posts above.

For those wondering about CAIDA's backscatter techniques, here's a couple technical links from CAIDA's David Moore himself:

Network Telescopes:Observing Small or Distant Security Events
Inferring Internet Denial-of-Service Activity

I've read through the parts of these papers pertinent to my own interests only. I am not trying to summarize them for you. The second paper is very readable for the most part and I encourage people to look at it.

It looks like CAIDA collects their backscatter data without the use of the blackhole techniques I was posting about earlier. So if blackholing was involved it probably was done by XO.net.

CAIDA uses what they call a Network Telescope. Basically this means they watch for packets that show up at addresses that don't belong to anyone yet. They watch ALOT of dead-end addresses all over the entire internet. The assumption is that packets arriving at a dead-end were not sent there on purpose, but are the result of address spoofing from some sort of attack sequence. It makes sense to me, but there are caveats - and Moore is very well aware that his technique is not airtight. Read the paper.

The biggest assumption made in his backscatter analysis is that the arriving packets form a truly random distribution. There are many things that can skew the data - read his paper. The important point I think is that skewed backscatter data Can ONLY Cause an Underestimation of the attack. So for all those trying to tear appart CAIDA's numbers, SCO was probably hit harder than stated. CAIDA's techniques have difficulty nailing down the start and stop times of attacks. So trying to poke holes in the inconsistencies of CAIDA and Netcraft, etc. data is pointless.

I think SCO was hit, hit hard and I think that fact is incontestable at this point. How hard and with what technique are open questions.

That said, we all know SCO is not honnest, and most likely stretched the story and the situation to suit their needs.

But keep in mind, Honnest People Don't Have A Corner On The Truth.

Cheers,
-brice

[ Reply to This | # ]

Just how good are SYN defenses?
Authored by: Anonymous on Friday, December 12 2003 @ 05:17 PM EST
From PJ's story

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 did some poking around and here are the most common numbers thrown around on
the net. Cisco PIX and Checkpoints firewall-1 did poorly at 100 SYNs/sec and
500 SYNs/sec respectively. An unprotected unpatched Linux box does just less
than the PIX.

A Netscreen box can handle about 14,000 SYNs/sec and an AppSafe switch has able
to handle the 24,000 SYNs/sec threshold limit of one test.

Syn Cookies have been tested up to 32,000 SYNs/sec.

There are a variety of sites with these numbers, google syndefender maximum
connections for the links. Many seemed to be from the same test but there are
at least tthree separate tests if you wade through all the duplicates.

Hope that clearifies some of the FUD going both ways about what a SYS defense
can or can not do.

[ Reply to This | # ]

Security Experts Doubt SCO Was Attacked
Authored by: Anonymous on Friday, December 12 2003 @ 10:42 PM EST
Wow, these "SCO was not attacked" messages tapered off fast didn't
they? Here's a tip: SCOX=buy.

[ Reply to This | # ]

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 )