|
SCO is Down Again |
|
Saturday, December 13 2003 @ 11:16 AM EST
|
I am getting reports that SCO's web site appears to be down again. More news as it comes in. Netcraft's dynamically updating graph tells the sad story. It could just be maintenance. Happily, if it's an attack, this time CAIDA is likely watching closely and the authorities are too, so I hope that means they will soon identify the guilty party, who is clearly no friend of Linux. This is probably not a good time to visit their site, and the authorities are already in place, so no need to figure this one out, I'd say. Netcraft will have it when they come back up and I'll report any other news I receive. Personally, I'm going offline to enjoy some Saturday time off.
|
|
Authored by: gvc on Saturday, December 13 2003 @ 11:31 AM EST |
Since Sat Dec 13 11:06:18 EST 2003 I've been doing traceroutes every 5 minutes
to www.sco.com and I'll continue to do them every 5 minutes.
So far, they all get this far with excellent response time:
p0-0.CHR1.SaltLake-UT.us.xo.net (207.88.83.42) 104.237 ms 118.850 ms 106.039
ms
But beyond there is no response.
Note that this is different from yesterday in which xo.net reported "no
route to host." This is consistent with www.sco.com being down or failing
to repond for whatever reason.[ Reply to This | # ]
|
|
Authored by: Jude on Saturday, December 13 2003 @ 11:37 AM EST |
Maybe it's just maintenance? I don't think SCO has any home user market, so
weekends would be a likely time for them to do planned shutdowns.
Just speculation, no evidence to support it.
[ Reply to This | # ]
|
|
Authored by: photocrimes on Saturday, December 13 2003 @ 11:38 AM EST |
And once again the FTP site is still up and very responsive.
Just as a side note, why is there no lull in the attack? Most DOS attacks that I
have had to deal with fade in and out. They seldom look like they do in SCO's
case, I believe someone said it looked like "they kicked a cable
out" or something. It does look as though they just turned off the web
server.
Like I said, it doesn't seem to be doing anything to the other sites. If they
were to target a SCO subnet, surely the FTP server would be getting hit just as
bad regardless if it's on the same hub/switch or not don't you think?[ Reply to This | # ]
|
|
Authored by: Alex on Saturday, December 13 2003 @ 11:39 AM EST |
Here's my traceroute for what it's worth.
Alex
traceroute to sco.com (216.250.128.12), 30 hops max, 38 byte packets
1 adsl-67-122-191-254.dsl.lsan03.pacbell.net (67.122.191.254) 13.992 ms
13.770 ms 13.328 ms
2 dist1-vlan50.lsan03.pbi.net (64.161.163.214) 14.280 ms 14.840 ms 16.631
ms
3 bb1-g9-1-0.lsan03.pbi.net (67.116.100.131) 15.588 ms 15.596 ms 15.706 ms
4 bb1-p9-1.eqlaca.sbcglobal.net (66.123.41.150) 16.058 ms 17.319 ms
16.422ms
5 asn2828-xo.eqlaca.sbcglobal.net (151.164.248.2) 15.782 ms 15.766 ms
15.789 ms
6 p4-0-0.RAR2.LA-CA.us.xo.net (65.106.5.49) 25.651 ms 16.765 ms 15.760 ms 7
p4-0-0.MAR2.SaltLake-UT.us.xo.net (65.106.5.74) 28.603 ms 27.892 ms 28.793
ms
8 p4-2-0.MAR1.SaltLake-UT.us.xo.net (207.88.83.37) 56.419 ms 55.754 ms
55.647 ms
9 p0-0.CHR1.SaltLake-UT.us.xo.net (207.88.83.42) 58.367 ms 56.505 ms 55.450
ms
10 * * *
---
Hey Darl!! Did Ross Perot draw your chart?"[ Reply to This | # ]
|
|
Authored by: surak on Saturday, December 13 2003 @ 11:45 AM EST |
I can't get through by going to www.sco.com, but interestingly enough
www2.sco.com appears to be operational, as does this ip address which I
couldn't reverse-lookup: 216.250.128.20. I got that here on Groklaw from
another reader, not sure where he/she got that from. Similiarly, ftp.sco.com
seems to be getting through.
All in all, simiiliar results from the last time.
[ Reply to This | # ]
|
|
Authored by: miss_cleo_psy4u on Saturday, December 13 2003 @ 11:47 AM EST |
SCO web server <a
href="http://216.250.128.20/">http://216.250.128.020</a> is
still accessible using IP. [ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, December 13 2003 @ 11:48 AM EST |
I think it's important to note that the CAIDA report only mentions the web and
ftp servers, while SCOG's press releases also says that their mail servers
where brought down as well.
Time to put on my tin foil hat here..
There's been talk on the Yahoo financal message forums that there is a
possiblity that SCOX DOS'd themselves and sent false ACKs to the CAIDA's
monitoring servers to make it look like they where attacked.[ Reply to This | # ]
|
|
Authored by: rjamestaylor on Saturday, December 13 2003 @ 11:49 AM EST |
MX mail.ut.caldera.com 216.250.130.2
[root@myserver root]# tracepath mail.ut.caldera.com/25
1?: [LOCALHOST] pmtu 1500
1: ip68-xx-xx-xx.oc.oc.cox.net (68.xx.xx.xx) 16.267ms
2: ip68-xx-xx-xx.oc.oc.cox.net (68.xx.xx.xx) asymm 1 45.042ms
3: ip68-4-14-137.oc.oc.cox.net (68.4.14.137) asymm 2 44.399ms
4: ip68-4-14-197.oc.oc.cox.net (68.4.14.197) asymm 3 53.100ms
5: rsmtbbrc02-pos0101.rd.oc.cox.net (68.1.0.188) asymm 4 39.673ms
6: rsmtbbrc01-pos0100.rd.oc.cox.net (68.1.0.182) asymm 4 49.509ms
7: so-4-0.hsa2.Tustin1.Level3.net (65.59.168.1) asymm 5 40.122ms
8: so-2-0-0.mpls2.Tustin1.Level3.net (209.244.27.145) asymm 7 46.178ms
9: so-6-2-0.bbr2.LosAngeles1.Level3.net (209.247.8.113) asymm 8 44.931ms
10: unknown.Level3.net (209.247.9.142) asymm 8 45.312ms
11: xo-level3-oc12.LosAngeles1.Level3.net (209.0.227.34) asymm 9 45.920ms
12: p4-0-0.RAR2.LA-CA.us.xo.net (65.106.5.49) asymm 11 42.176ms
13: p4-0-0.MAR2.SaltLake-UT.us.xo.net (65.106.5.74) asymm 19 101.079ms
14: p4-2-0.MAR1.SaltLake-UT.us.xo.net (207.88.83.37) asymm 18 69.890ms
15: p0-0.CHR1.SaltLake-UT.us.xo.net (207.88.83.42) asymm 18 68.764ms
16: 205.158.14.114.ptr.us.xo.net (205.158.14.114) asymm 19 71.451ms
17: c7pub-216-250-136-254.center7.com (216.250.136.254) asymm 20 74.687ms
18: no reply
---
SCO delenda est! Salt their fields![ Reply to This | # ]
|
|
Authored by: gvc on Saturday, December 13 2003 @ 11:54 AM EST |
You can connect to ftp.sco.com with ftp, but it doesn't respond to ping or
traceroute. This implies they've
put some sort of filter in.
cormack.uwaterloo.ca 177>ftp ftp.sco.com
Connected to ftp.sco.com (216.250.128.13).
220 ftp.caldera.com Ready.
Name (ftp.sco.com:gvcormac):
331 Password required for gvcormac.
Password:
530 Login incorrect.
Login failed.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
ftp>
ftp>
ftp>
ftp>
ftp> 221 Goodbye.
cormack.uwaterloo.ca 178>ping ftp.sco.com
PING ftp.sco.com (216.250.128.13) from 192.168.1.11 : 56(84) bytes of data.
--- ftp.sco.com ping statistics ---
3 packets transmitted, 0 received, 100% loss, time 2018ms
cormack.uwaterloo.ca 179>/usr/sbin/traceroute ftp.sco.com
traceroute to ftp.sco.com (216.250.128.13), 30 hops max, 38 byte packets
1 10.67.128.1 (10.67.128.1) 23.946 ms 15.283 ms 21.180 ms
2 cgowave-0-85.cgocable.net (24.226.0.85) 16.355 ms 22.624 ms 15.467 ms
3 cgowave-0-205.cgocable.net (24.226.0.205) 13.585 ms 38.246 ms 17.710 ms
4 cgowave-0-101.cgocable.net (24.226.0.101) 24.626 ms 17.133 ms 23.660 ms
5 ra1sh-pos7-2.mt.bigpipeinc.com (66.244.223.149) 93.197 ms 239.571 ms
350.858 ms
6 rc1sh-ge9-0.mt.shawcable.net (66.163.66.9) 23.741 ms 26.505 ms 23.144 ms
7 66.163.76.74 (66.163.76.74) 39.088 ms 40.756 ms 38.923 ms
8 rc1ar-pos10-0.ed.shawcable.net (66.163.76.78) 180.379 ms 156.246 ms
88.181 ms
9 rc1bb-pos13-0.vc.shawcable.net (66.163.76.161) 70.094 ms 70.249 ms 89.279
ms
10 rc1wh-pos13-0.vc.shawcable.net (66.163.69.66) 71.011 ms 71.379 ms 70.507
ms
11 POS5-0.GW3.VAN1.ALTER.NET (205.150.222.125) 75.167 ms 75.628 ms 76.648
ms
12 0.so-1-0-0.XL2.VAN1.ALTER.NET (152.63.137.134) 75.835 ms 75.319 ms 75.812
ms
13 0.so-7-0-0.TL2.VAN1.ALTER.NET (152.63.138.90) 104.064 ms 80.973 ms 95.048
ms
14 0.so-5-0-0.TL2.SCL2.ALTER.NET (152.63.1.34) 164.030 ms 85.331 ms 85.133
ms
15 0.so-1-0-0.XL2.SCL2.ALTER.NET (152.63.1.46) 96.681 ms 85.115 ms 83.959
ms
16 0.so-5-1-0.BR1.SCL2.ALTER.NET (152.63.48.9) 85.326 ms 85.653 ms 84.093
ms
17 204.255.174.254 (204.255.174.254) 115.896 ms 98.900 ms 101.376 ms
18 p5-0-0.RAR1.SanJose-CA.us.xo.net (65.106.5.173) 99.371 ms 111.713 ms
159.980 ms
19 p6-0-0.RAR1.Denver-CO.us.xo.net (65.106.0.22) 93.196 ms 116.460 ms
110.896 ms
20 p4-0-0.MAR1.SaltLake-UT.us.xo.net (65.106.6.74) 108.792 ms 127.591 ms
111.650 ms
21 p0-0.CHR1.SaltLake-UT.us.xo.net (207.88.83.42) 110.705 ms 112.139 ms
119.111 ms
22 205.158.14.114.ptr.us.xo.net (205.158.14.114) 210.838 ms 129.820 ms
128.101 ms
23 * * *
24 * * *
25 * * *
26 * * *
[ Reply to This | # ]
|
|
Authored by: Alex on Saturday, December 13 2003 @ 11:57 AM EST |
I can also reach SCO at 216.250.128.20. I wonder if they've fouled up the
routing tables, because I can't reach them as www.sco.com.
I can also reach Center 7, Noorda Family Trust, and Canopy. More as I get it.
Alex
---
Hey Darl!! Did Ross Perot draw your chart?"[ Reply to This | # ]
|
|
Authored by: freeio on Saturday, December 13 2003 @ 12:01 PM EST |
I hate to be the curmudgeon in all of this, but quite frankly, other than
watching for disappearing or modified content (i.e. looking for them attempting
to make evidence change or disappear), this is entirely their problem. Why give
them the added publicity? Furthermore, Knowing these fine folks, every
traceroute and ping we might use to check what is going out is likely being
logged and considered a DDOS all by itself.
My advice: Let the matter drop. Now.
The only thing I qualify for in all of this is the ultimate cynic. I do not
trust TSG at all, and assuming that they are indeed having a real externally
caused, real internally caused, or imaginary problem, these are the kind of
folks who will try their hardest to place the blame on us. Thus I repeat my
advice.
My advice: Let the matter drop. Now.
I once worked for a very litigous man, who believed in using and abusing the
courts to make his perceived enemies pay, right or not. He bragged about his
legal conquests, and all of the fine folks he had quite legally beaten up using
the court system. Having seen this occur elsewherre, I suspect we may see it
here. Once again:
My advice: Let the matter drop. Now.
---
73 de w4ti[ Reply to This | # ]
|
|
Authored by: renef on Saturday, December 13 2003 @ 12:08 PM EST |
Apparently the SCO ship is taking on water
RF[ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, December 13 2003 @ 12:10 PM EST |
For three reasons:
<P>
1) Folks were able to connect to the ftp subnet address
with no delays. If the bandwidth were saturated by 34,000
packets/sec there should/would have been considerable ftp
acess delays, if a reply would have been sent at all.
<P>
2) The uptime.netcraft chart shows no significant
response time hash during the two weeks prior to the
'attack', right up to the instant sco.com was turned off.
The Network Telescope graphs of examples of SYN flooding
show large response time hash amplitudes during an attack.
Notice the response times on the uptime.netcraft dynamic
graph during the two day period they were up after the
first 'attack' -- averaging 0.4 second response times,
just as they had for the previous TWO weeks.
<P>
3) "Network Telescopes" work on the assumption that the
spoofed address of a syn flood packet is bogus, so the
possibility exists that a portion of them will cover a
range of IP addresses where little or no network traffic
can be expected. The bigger the range of unused IP
addresses that is monitored the bigger the 'lens" of the
"Telescope". This 'back scatter' the telescope 'sees' is
the victim's box responding with SYN_ACK packets to the
spoofed addresses. The Network Telescope cannot
distinquish between true and pseudo backscatter. Pseudo
backscatter would be SYN_ACK packets that the 'victim'
spews out to random IP addresses to make it look like
their site is under attack. They turn off normal SYN_ACK
handshaking so the site appears 'down'. While they are
doing this on one box other boxes on their subnet will be
able to response to the normal handshake without any undue
delay because the number of valid SYN packets remains the
same - hence the lack of hash on uptime.netcraft graphs.
Someone at SCO monitored GrokLaw to see the effect of
their PR predicting a "12 hour outage" and noticed folks
mentioning the fact that the FTP site on the same subnet
and, according to ARIN the same location, was not
experiencing any delays that would be associated with a
massive SYN flood attack, especially one at 34,000/sec.
According to SCO, not only did the attack knock their site
off line, it also messed up their email, internal
databases, and their phones!
<P>
I believe SCO committed this 'attack' as a pretext to
modify their website by removing some pages and adding
others. More significant will be the claims they will
make later regarding the availability of documents the
court has ordered them to produce. [ Reply to This | # ]
|
|
Authored by: rjamestaylor on Saturday, December 13 2003 @ 12:10 PM EST |
[root@myserver root]# telnet ftp.sco.com 21
Trying 216.250.128.13...
Connected to ftp.sco.com.
Escape character is '^]'.
220 ftp.caldera.com Ready.
quit
221 Goodbye.
Connection closed by foreign host.
[root@myserver root]# telnet 216.250.128.14 21
Trying 216.250.128.14...
Connected to 216.250.128.14.
Escape character is '^]'.
220 ftp.dev.caldera.com Ready.
quit
221 Goodbye.
Connection closed by foreign host.
That subnet looks pretty good, aggregate bandwidth-wise I mean
---
SCO delenda est! Salt their fields![ Reply to This | # ]
|
|
Authored by: Bob Miller on Saturday, December 13 2003 @ 12:25 PM EST |
One of the primary characteristics of collaborative development is
that people
try different approaches to solving a problem. Eric
Raymond coined a slogan
about the approach as applied to debugging:
"Many eyeballs make all bugs
shallow." Most of the time, the "Try
Everything and See What Works" approach
works very well.
When Mindcraft released its flawed webserver benchmarks, I
noticed
that we can and do use the same approach to defending ourselves
against
our enemies. Many different groups responded, each in a
different way. Some
critiqued the methodology, others traced
Mindcraft's funding, and others started
reworking some Linux
performance bottlenecks. Some just posted, "Yeah? Well,
your
momma!" on Slashdot. The "Your momma!" approach didn't work,
but some did,
and Mindcraft was discredited.
I suspect the Mindcraft fiasco was a wake-up
call for Microsoft, They
learned that The Linux Movement isn't a single entity,
and we don't
have a single response to any attack. That makes us much harder
to
FUD than other competitors. We might be the first competitor they've
come up
against that can usually outmaneuver them.
If you're reading Groklaw, and
especially if you're a regular here,
you probably believe in and respect the
law. We're self-selected for
that trait. But the trait is by no means
universal among Linux
lovers. It stands to reason that while we're trying to
destroy SCO by
find every fact that can be used against them in a court of
law,
others would try different approaches. Even ineffective approaches.
Even
illegal approaches.
So there you have it. If you cross a collaborative
development group,
you should expect them to fight dirty and fight clean at the
same
time. Most of us abhor the D?DoS attacks (assuming they're real --
there's
some puzzling evidence there...) and denounce the attackers.
The thing is, our
denunciation carries exactly as much weight with
the attackers as Blake
Stowell's.
DISCLAIMER: My postings may ask or implictly raise
questions about the
law, its practice, or its interpretation. Although I am not
a lawyer,
these questions do not signal intent to enter into a
client-attorney
relationship with any lawyer(s) who answer said questions.
All
answers and subsequent discussion shall be regarded solely as for
the
edification of myself and other readers. They will not be construed
as
legal advice. Hi, Darron!
[ Reply to This | # ]
|
|
Authored by: Alex on Saturday, December 13 2003 @ 12:25 PM EST |
Here's something really interesting. As I stated before, I'm restricting
myself to http/ftp types of investigation from now on. I started at the bottom
of the stack, and worked my way up. So far I've found SCO's web page at:
216.250.128.4
216.250.128.5
216.250.128.10
216.250.128.20
216.250.128.21
216.250.128.22
216.250.128.23
216.250.128.24
Is this really weird, or am I missing something?
I'm going to give it up for the day, but maybe someone else can follow up on
this stuff.
Alex
Alex
---
Hey Darl!! Did Ross Perot draw your chart?"[ Reply to This | # ]
|
|
Authored by: rjamestaylor on Saturday, December 13 2003 @ 12:26 PM EST |
Who owns the IP address for ftp.sco.com? Canopy.com.
[root@myserver root]# nslookup -sil 216.250.128.13
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
13.128.250.216.in-addr.arpa name = ftp.sco.com.
Authoritative answers can be found from:
128.250.216.in-addr.arpa nameserver = ns.calderasystems.com.
128.250.216.in-addr.arpa nameserver = ns1.canopy.com.
128.250.216.in-addr.arpa nameserver = ns2.calderasystems.com.
ns1.canopy.com internet address = 216.250.129.1
Let's ping/path to the last listed nameserver:
[root@myserver root]# tracepath 216.250.129.1
1?: [LOCALHOST] pmtu 1500
1: ip68-96-72-1.oc.oc.cox.net (68.96.72.1) 17.141ms
2: ip68-96-72-1.oc.oc.cox.net (68.96.72.1) asymm 1 40.533ms
3: ip68-4-14-137.oc.oc.cox.net (68.4.14.137) asymm 2 47.227ms
4: ip68-4-14-197.oc.oc.cox.net (68.4.14.197) asymm 3 44.597ms
5: rsmtbbrc02-pos0101.rd.oc.cox.net (68.1.0.188) asymm 4 56.583ms
6: rsmtbbrc01-pos0100.rd.oc.cox.net (68.1.0.182) asymm 4 39.186ms
7: rsmtbbrc02-pos0102.rd.oc.cox.net (68.1.0.187) asymm 5 41.595ms
8: fed1bbrc01-pos0200.rd.sd.cox.net (68.1.0.193) asymm 7 52.809ms
9: f0.pao1.verio.net (198.32.176.14) asymm 8 44.435ms
10: p16-0-1-1.r21.plalca01.us.bb.verio.net (129.250.3.84) asymm 8 51.828ms
11: p64-0-0-0.r21.mlpsca01.us.bb.verio.net (129.250.5.49) asymm 9 36.192ms
12: p16-3-0-0.r00.mlpsca01.us.bb.verio.net (129.250.2.240) asymm 11 46.827ms
13: p4-1-0-0.a00.dnvrco02.us.ra.verio.net (129.250.16.52) asymm 12 80.679ms
14: p1-0-2-0.a00.dnvrco02.us.ce.verio.net (198.173.159.254) asymm 12 72.637ms
15: border3.ge2-0-bbnet.den.pnap.net (216.52.40.7) asymm 13 69.578ms
16: viawest-3.border3.den.pnap.net (216.52.42.22) asymm 12 71.218ms
17: gige-04-00.crrt01.den01.viawest.net (216.38.220.209) asymm 12 64.734ms
18: pos-06-m00-00.crrt01.den05.viawest.net (216.87.89.6) asymm 12 69.789ms
19: gige-00-m00-00.crrt02.den05.viawest.net (64.78.227.14) asymm 12 68.957ms
20: pos-03-01.crrt01.slc03.viawest.net (64.78.227.10) asymm 13 82.027ms
21: c7pub-216-250-136-74.center7.com (216.250.136.74) asymm 14 81.410ms
22: c7pub-216-250-142-154.center7.com (216.250.142.154) asymm 15 87.147ms
23: no reply
Look down! But wait:
[root@myserver root]# telnet 216.250.129.1 53
Trying 216.250.129.1...
Connected to 216.250.129.1.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
Nope, the nameserver is fine. It's not responding to random "you
there?" requests (or a filter is not letting the request get there).
There is no indication from the rest of the subnet that there are bandwidth
constrictions...not that I've seen this morning.
But why else could a web server not respond? Millions of reasons. Most of which
have nothing to do with attacks.
There MAY be an attack in progress but using the Razor approach...www.sco.com is
likely offline or blocked -- not enough evidence to support jumping to the
conclusion they're under attack.
P.S. Theories that SCO is sending fake ACK packets to CAIDA are silly. Stop it.
MORE:
216.250.128.13-17 are FTP servers and are responding great:
[root@myserver root]# telnet ftp2.sco.com 21
Trying 216.250.128.17...
Connected to ftp2.sco.com.
Escape character is '^]'.
220 ftp2.caldera.com Ready.
^]
telnet> quit
Connection closed.
[root@myserver root]# telnet ftp.iso.caldera.com 21
Trying 216.250.128.16...
Connected to ftp.iso.caldera.com.
Escape character is '^]'.
220 ftp.iso.caldera.com Ready.
quit
221 Goodbye.
Connection closed by foreign host.
[root@myserver root]# telnet ftp.beta.caldera.com 21
Trying 216.250.128.15...
Connected to ftp.beta.caldera.com.
Escape character is '^]'.
220 ftp.beta.caldera.com Ready.
quit
221 Goodbye.
Connection closed by foreign host.
[root@myserver root]# telnet ftp.dev.caldera.com 21
Trying 216.250.128.14...
Connected to ftp.dev.caldera.com.
Escape character is '^]'.
220 ftp.dev.caldera.com Ready.
quit
221 Goodbye.
Connection closed by foreign host.
[root@myserver root]# telnet ftp.sco.com 21
Trying 216.250.128.13...
Connected to ftp.sco.com.
Escape character is '^]'.
220 ftp.caldera.com Ready.
quit
221 Goodbye.
Connection closed by foreign host.
---
SCO delenda est! Salt their fields![ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, December 13 2003 @ 12:32 PM EST |
With all due respect, I'm not really that interested in this story. If this
goes on for a while (site up, down, up, etc.) I can see this being all we end up
discussing.
If SCO's down because of some kind of attack, that's bad, and whoever is doing
it should stop. In the interim, dealing with it really is SCO's/SCO's ISP
problem, and if applicable law enforcement.
If SCO's down because of some technical fubar, well that's SCO and SCO's ISP
problem.
Anyway, IMHO it's silly for SCO to be issuing press releases about this stuff,
and it's silly for us to waste too much time discussing it.
Personally I'm much more interest in, for example:
- The 89-2 filing (has anybody got it??? please ??) which has the court going
back over some older motions
- Did SCO file a 2nd amended complaint (wouldn't they have to ask the court's
permission first??)
- Any more comments on the transcripts
- The SCO motion to compel discovery in context of the last hearing
- etc
IANAL, IA Quatermass[ Reply to This | # ]
|
|
Authored by: Beyonder on Saturday, December 13 2003 @ 12:33 PM EST |
the FTP is up and fine, just checked.
and btw, for whatever it's worth, there are 23 other IPs still active on that
LAN, still live and functioning, these other systems have never been affected
all this time.
There's a "colo" customer on that net, still live, near as I can
tell, "j2.net", whoever they are. Their registrar (ISP) is in
Germany (joker.com or nrw.net). Which I find a bit odd, but then, customers are
allowed to be "odd" :)
ping/scans are not illegal, but be careful of your UAPs/EULAs etc... different
ISPs may have different policies.
Please don't over-saturate their network with scans/pings/etc. Such things
could be misconstrued, and could cause the "slashdot" effect.
For whatever it's worth, I'm not seeing any latency, timing is within
acceptable limits.
If I didn't know any better, I'd say it was network maintenance... However,
this is all speculative, as it's always been. Without hard facts (which SCO or
their ISP only know) we're just grasping at straws in the dark...[ Reply to This | # ]
|
|
Authored by: iZm on Saturday, December 13 2003 @ 12:37 PM EST |
I can access www.sco.com server via telnet but cannot get
any other response.
---
Stupidity, like virtue, is its own reward.[ Reply to This | # ]
|
|
Authored by: belzecue on Saturday, December 13 2003 @ 12:46 PM EST |
PJ's original article is here --
http://www.groklaw.net/article.php?story=20030924003650326
OpenUnix8 documentation online is here -- http://216.250.128.246/
-----
http://216.250.128.246/LX_uw/LKP_intro.html
says (and this is Caldera, not SCO, so why should they lie?):
Differences from Linux
The Linux Kernel Personality for Open UNIX 8 provides a Linux application
runtime environment along with Linux libraries and user-level commands, but the
LKP uses the Open UNIX 8 kernel. There is no Linux code in the Open UNIX 8
kernel. Rather, Linux kernel functions are provided by the Open UNIX 8 kernel.
Most Linux applications will run properly in the LKP, but only Open UNIX 8
kernel and data structures are used. This means that most system administration
must be performed using Open UNIX 8 tools and commands, and Linux applications
that depend on a Linux kernel module will not work. See ``Limitations''.
http://216.250.128.246/LX_uw/CTOC-LKP_works.html
How the LKP works
The LKP provides a Linux kernel interface to Open UNIX 8. The LKP is not an
emulator; rather, Linux kernel functions are mapped into equivalent Open UNIX 8
kernel functions. The LKP runtime environment, from an application
point-of-view, is the same as as a Caldera OpenLinux runtime environment --
Linux applications do not ``know'' that they are running on a Open UNIX 8
kernel. The LKP includes standard Linux libraries, runtime components and user
commands.
The main differences between native Linux and the LKP are in the kernel and data
structures themselves, which are based on Open UNIX 8 for the LKP.
[ Reply to This | # ]
|
|
Authored by: belzecue on Saturday, December 13 2003 @ 12:53 PM EST |
Info taken about 1:15 - 1:30am GMT+8, Sunday, 14 Dec.
-----
216.250.128.20
Initiating server query ...
Looking up the domain name for IP: 216.250.128.20
(The domain name for the specified IP address could not be found.)
Connecting to the server on standard HTTP port: 80
[Connected] Requesting the server's default page.
The server returned the following response headers:
HTTP/1.0 200 OK
Date: Sat, 13 Dec 2003 17:04:08 GMT
Server: Apache
X-Powered-By: PHP/4.3.2
Content-Type: text/html
Age: 330
X-Cache: HIT from trapdoor2.arach.net.au
X-Cache-Lookup: HIT from trapdoor2.arach.net.au:8080
Connection: close
Query complete.
-----
216.250.128.20
Initiating server query ...
Looking up the domain name for IP: 216.250.128.12
The domain name for the IP address is: www.sco.com
Connecting to the server on standard HTTP port: 80
[Connected] Requesting the server's default page.
The server's response did not contain the expected 'Server:' header to
identify itself. Therefore, server's identity can not be determined.
Query complete.[ Reply to This | # ]
|
|
Authored by: PolR on Saturday, December 13 2003 @ 12:53 PM EST |
The most likely scenario that occurs to me is they may connect multiple sites
using VPN tunnels over the same Internet link than their other servers. If there
is trouble over that link the VPN tunnels may be affected.
The fact that www is down but not ftp goes against that hypothesis.
This is all speculative. We don't know if they use VPN and we don't know what
their VPN server and bandwidth might be. Perhaps their VPN server has been down
as well and we didn't notice.[ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, December 13 2003 @ 12:56 PM EST |
From the Netcraft page:
OS Server Last changed IP address
Netblock Owner
Linux Apache 12-Dec-2003 216.250.128.12 NFT
unknown Apache
11-Dec-2003 216.250.128.12 NFT
Linux Apache 3-Sep-2003 216.250.128.12
NFT
Anyone else find it interesting that they are changing the
reported OS?[ Reply to This | # ]
|
- SCO is Down Again - Authored by: Anonymous on Saturday, December 13 2003 @ 01:19 PM EST
- SCO is Down Again - Authored by: Anonymous on Saturday, December 13 2003 @ 04:51 PM EST
|
Authored by: penguinroar on Saturday, December 13 2003 @ 12:57 PM EST |
As the cynic i am i have a hard time imaging someone close to the OSS movement
doing something as stupid as this. Not only should it be very counter productive
but it would also feed SCO's need to postpone the delivery of the documents
requested by IBM. The only one that would benefit out of this would be SCO and
possibly Microsoft in the form of a prolonged trial.
If someone near the OSS camp broke into SCO servers and did some datamining i
would have an easier time believing it but a brute force DoS? I really, honestly
dont think so.
There is now a huge need for this attack to be traced down to the originator.
Either by the feds or by us in the OSS community. If it is a fraud by SCO then
the feds will most likely find that out pretty easy. If its not well then we
will atleast know whos behind theese stupid attacks wich do not gain the OSS
community in any way.
Step one would be for either SCO or anyone else to get the feds started on this
right away. There are no doubts that this will be used in the courtroom so we
have only 30 days to refute this if it is a bogus claim.
Anyone at SCO who might know the truth to this please help by either confirm or
deny, it would make all the differance.
---
Free market != greed.[ Reply to This | # ]
|
|
Authored by: belzecue on Saturday, December 13 2003 @ 01:06 PM EST |
Maybe they just forgot to renew their domain name? :-)
What a shame that www.scumgroup.com is already taken.
[ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, December 13 2003 @ 01:06 PM EST |
I'm not sure if anyone else has considered this but:
Scenario:
i) SCO is hit by a DOS attack
ii) Has to focus on getting the servers back up
so they don't
a) Get hit by various lawsuits from clients, etc.
Question: Could they use this as a valid reason why they
don't have the information for Judge Wells after the 30
day time frame?
For those that wear tinfoil hats, please don't use the
above to jump to another conspiracy theory, there's enough
of those going around already.
I'm simply curious what affect the DDOS will cause to the
recent court decision.
[ Reply to This | # ]
|
|
Authored by: hugorune on Saturday, December 13 2003 @ 01:44 PM EST |
I just saw this article which icludes the following statement
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...
That's a pretty impressive hourly rate![ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, December 13 2003 @ 01:45 PM EST |
This thread is getting too silly.
Scc.com up, sco.com down. Someone is attacking them, they are faking it. WHO
CARES?
This site is supposed to be dedicated to discussion of SCO's legal tactics (or
lack thereof). There is a slashdot and a myriad of other Internet security sites
dedicated to the technical intricacies of this attack.
On a side note, I must add that as a $200,000,000 high-tech corporation SCO must
have been prepared to guard against such an event as SYN flood. Nonetheless, if
they don’t use this is court we should not waste time discussing it here.
[ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, December 13 2003 @ 01:47 PM EST |
SCO's web server (http://www.sco.com) appears to be under a DDOS attack again.
And you can watch the attack on your very own server.
If you run Linux with
state-based firewall rules that log rejected packets,
you can see the SCO
attack backscatter by grepping for the SCO web server address
in your
firewall logs.
With my servers this looks like:
grep 216.250.128.12 /var/log/messages*
I have servers in
co-lo with connections to six seperate address ranges. So
far, the
backscatter has showed up on Level-3 in Philadelphia, Verio in Philadelphia,
and AT&T is Costa Mesa, CA. I have seen packets from port 80 (web) and 21
(ftp) with the latest packet about 30 minutes ago. The rate is pretty low, but
I am only a little sliver of the internet. [ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, December 13 2003 @ 02:15 PM EST |
Folks,
Since I and my rather well known Internet security oriented site
(http://www.grc.com) have more experience than we need being the target of many
years of DDoS attacks, I have received a number of notes from people are the
situation with SCO.
The fact that only SCO's web server is inaccessible, while the immediately
adjacent FTP server, and the rest of their network remains online has confused
people. There have also been comments like "they appear to have kicked the
cable out of the wall" because the web server is down so completely.
What SCO has done is to have their ISP, XO, "null route" (also
called "black hole" by network engineers) any and all packets which
are aimed at the IP of their web server. This has two effects:
First, it "absorbs" the attack completely in XO's strong backbone
router network so that no portion of the attack bandwidth can reach SCO's own
intranet.
Second, it quite effectively holds SCO's web servers located at that address
completely off the Net.
People are also being somewhat confused by the use of "ICMP" or
"UDP" protocol tools such as Ping and TraceRoute. The problem with
these tools is that since they use a protocol other than the protocol being used
by the web server (TCP) their packets are prone to "filtering" at
any stage upstream of their destination. In order to get accurate
"traces" into SCO's network you'll need to use a TCP tracing
program which can generate expiring TCP packets aimed at port 80 (HTTP). Such
packets can NOT be filtered since they are the same packets needed for SCO's
web servers to function with the outside world. A very nice, multiplatform TCP
protocol tracing tool is LFT, available here: (http://www.mainnerve.com/lft/).
Though I have no direct evidence of this myself, I have absolutely no doubt that
SCO is the target of one or more DDoS attack fleets. Launching DDoS attacks is
so easily done that little provocation is needed and such attacks are becoming
increasingly commonplace. Just as the RIAA was "punished" and
DDoS'd off the Net for their very vocal support of very bad anti-file sharing
legislation, the SCO Group has generated enough negative publicity with their
recent actions and stated intentions to "get themselves DDoS'd" off
the Net. This attack will last -- literally -- as long as the attackers want it
to, or until their fleets of remote control attack Zombies are aimed somewhere
else.
If you are unfamiliar with my work in this area, you might find my write-up of
my own experiences worth reading: http://www.grc.com/dos/grcdos.htm
All the best,
Steve Gibson
GIBSON RESEARCH CORPORATION
[ Reply to This | # ]
|
|
Authored by: Cableguy on Saturday, December 13 2003 @ 03:11 PM EST |
I went and looked at the NetCraft logs, however, did any one else find it odd
that they happened about the same time in the day?
Cableguy.[ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, December 13 2003 @ 03:29 PM EST |
Notice that all the attention given in the press to the alleged attacksdiverts
from stories about how SCO lost in court last week, and also from stories about
how RBC restructured the $50 million deal because it mistrusted what SCO was
going to do.
Expect more diversions in the coming weeks, as SCO gets closer to the fatal Jan
11 date. [ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, December 13 2003 @ 03:31 PM EST |
Is there anybody else out there who feels the same way that I do? Isn't it just
great timing that this is happening right when they need to produce a ton of
information within a 30 day period? Doesn't this just sound like a great reason
to give to the judge for an excuse to prolong the date required to compel
discovery? hmm :/[ Reply to This | # ]
|
|
Authored by: pixitha on Saturday, December 13 2003 @ 04:10 PM EST |
so they can pay their lawyer $750 bucks an hour....and give him 20% of the
profit they make if they win...
they lose 300,000 bucks for being offline....
they have lots of money....
why can't they pay someone to do this? why can't they pay a couple of people
to say or do something.... It sounds a lil hollywood, but come on...its surly
possible....
-pix[ Reply to This | # ]
|
|
Authored by: zzzcust on Saturday, December 13 2003 @ 04:17 PM EST |
I find it interesting that www.sco.com has been hosted on a Linux box since
August of 2002, with the brief exception of a few hours on 11 December, 2003,
when netcraft lists the OS as "unknown". Did SCO perhaps try to
rehost on a less embarassing OS and fail miserably--perhaps because the other OS
was susceptible to Syn attacks?
-Z[ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, December 13 2003 @ 04:43 PM EST |
I know all the readers here want to find out the truth, but maybe it's best if
we just left it all alone.
I'm imagining the quotes from Darl McBride: "Yes, that's right Dr
journalist: our website was under attack again, and look at our logs! We've
traced all these "crusty" attackers and found out what they have in
common - they all read Groklaw! I'm going to talk to Pres Bush and get him to
outlaw the site as they are clearly linked with terrorism..."
Okay, I'm being faecetious, but you get the meaning. If their website is down,
leave it alone. There's no point in hundreds of us replicating each others
work.
[ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, December 13 2003 @ 04:51 PM EST |
SCO has hired or persuaded someone to stage these attacks, in a last, desperate
attempt to get Congress to outlaw open source and the GPL.
No proof, sorry. But do you believe in coincidences? How will anyone identify
the perps? A perfect cover.
We know SCO is sleazy enough to do this.
[ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, December 13 2003 @ 05:10 PM EST |
Can I suggest tha twe do soem investigative work rather than ponder?
Okay I will start with the first investigatve question..
What were the times and duration of each DDos attack and what Server services
were attacked(ie ftp, www and etc)?
Next question, what other events occur during the same time frames such as pr
rleases , filings, and etc?
I think this would benefit us more than mere speculation, don't you?
just my 2 cents..
Fred Grott
ShareMe Technologies-The Mobile Future
http://www.jroller.com/page/shareme/Weblog
[ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, December 13 2003 @ 09:44 PM EST |
Hopefully IBM reads down this far.
Should SCO try to use this to delay discovery, IBM
should reply with a motion which says
"It is insufficient for plaintiff to make claims of
being harrassed. Defendant requests that plaintiff
produce the reports of appropriate law enforcement
agencies."[ Reply to This | # ]
|
|
Authored by: Anonymous on Sunday, December 14 2003 @ 03:08 AM EST |
I think that it is interesting that SCO cannot seem to recover from their
problems with their website. Or, perhaps they can and they have chosen not to.
They will be using this in their favor when it comes time to produce for IBM.
Mark my words. They will say that all aspects of their business came to a stand
still while this was going on making it impossible for them to gather the
information required for IBM.
Any other business would have shaken this off by now but these guys seem to be
dragging it out like a Pro Football player faking injury to try to get the
referee to call a foul.[ Reply to This | # ]
|
|
Authored by: Anonymous on Sunday, December 14 2003 @ 07:06 AM EST |
DOS attacks, SCO Politicians or Saviors? SCO cohorts.
DOS attacks,
What is most troubling to me about this, and earlier (SCO claimed) DOS attacks,
is that all press coverage (including from inside the Linux community) assumes
as a foregone conclusion that, if in fact, SCO has been attacked, it was
perpetrated by someone from within the Linux community. Tactically speaking, a
DOS attack from the community now, makes no sense at all, and would be akin to
IBM mooning, and flipping the bird to the judge, after getting a favorable
judgement from the court. When you are winning, you celebrate with cocktails,
not by launching malicious code. No, the only ones who benefit by this most
recent attack is SCO, and the public relations subterfuge it would buy to cover
up and marginalize their recent defeat in the courts. In fact, a self inflicted
attack orchestrated by SCO and company should be the assumed foregone conclusion
at this point because they have motive, and have shown by their previous
loathesome actions, that engaging in a hagelian dialectical act of attacking
oneself and placing the blame on their enemies is great strategy (It worked for
Hitlers Nazi party), and would not cause any of these moral reprobates to lose
any sleep.
Ground Rules,
The open source community press needs to learn to recognize a curve ball, PR
scams, and subterfuge, and stop assuming that an attack on SCO would by default,
be comming from one of us, or, accepting double blind anonymous phone calls of
addmission as proof (E.S.R. last time). Nor, should we apologize for doubting
statements comming from known pathalogical liars and FUD meisters. We should
also consider speculation regarding SCO tactics, including attacks on
themselves, as fair game, leaving no possible stone unturned. In all
probabillity, if we could pull back the curtain, SCO is a hired gun of
Microsoft, whose monopoly status precludes them from openly attacking perceived
enemies of their hegemony. So they hire punk, failure, CEO's of dying, failing
software companies and their likewise, useless underlings, to do in the open,
what they can't. Shame on you both Darl and Blake.
Attempt at Humor,
SCO Politicians or Saviors?
They tell me that Jesus fed Five Thousand with a "few" loaves and
fishes.
Darl (the high priest of unrightious mammon) Mcbride, has him beat by a lot in
this department. Like most politicians, he has shown the ability to feed many
millions from "One" bottomless bucket of (sh-t) crap.
SCO cohorts,
David (contingencies or billable hours, what's the difference ?) Boise, who
refuses to be bested by Darl, will be taking a break from plundering widows
houses to appropriately feed many millions from "One" bottomless box
of (fa-ts) bad, smelly wind. While orchestrating the orderly transfer of wealth
from the SCO (mom and pop) stock holders pockets, to his and his cohorts.
Including Darl's brother Kevin.
Open Content Zeek Greko...[ Reply to This | # ]
|
|
Authored by: belzecue on Sunday, December 14 2003 @ 10:13 AM EST |
So Netcraft monitoring is a pay service, I presume. They have a vested interest
in keeping their client SCO happy. Nothing wrong with that, of course. I
wonder when SCO started having their site monitored in this public manner.
-----
Performance Monitoring
Network performance measurements every 15 minutes
Outage notification by electronic mail when all measurement points are unable to
reach the site
Four measurement points on separate networks (Washington, Texas, New York and
London)
Detailed graphs on availability and server uptime
20 day data history
View Example Reports
Netcraft is a subscriber to the CESG CHECK Service
The service costs £1,200 + VAT Per Annum (approx $1,800 US).
[ Reply to This | # ]
|
|
Authored by: olly on Sunday, December 14 2003 @ 11:59 AM EST |
Noticed a news item on Yahoo! news.
Doubts Linger About SCO's Cyber-Attack
Claims. Seems to be an informative and balanced review. It also mentions
Groklaw several times.
I also like this quote:
Carlon said SCO has not investigated whether its web hosting
company has a clean Linux license. [ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, December 15 2003 @ 05:14 PM EST |
Call me a conspiracy theorist, but this looks to me like SCO is setting the
stage for an argument to the judge along the lines of "we can't produce
the discovery by the deadline because our file servers have been shutdown by
malicious Linux hackers." I certainly hope the judge doesn't buy it.[ Reply to This | # ]
|
|
|
|
|