Professional Web Applications Themes

More examples of SCO's stunning competence - SCO

Many people in this newsgroup have commented that SCO's management have been stupid about the way the IP issues have been handled. I showed last week how SCO' IT department had failed to perform a basic security measure when configuring SCO's nameservers (it's since been fixed). Now, let's look at marketing. If you want to establish a brand name, it's ususal to register the appropriate domain name, just as a defensive measure. So, let's look at some of the SCO's names: UNIXWARE: Unixware.com Registrant: Mindbank Developments 41035 Yokohl Dr Springville, California 93265 United States Registered through: GoDaddy.com Domain Name: UNIXWARE.COM ...

  1. #1

    Default More examples of SCO's stunning competence

    Many people in this newsgroup have commented that SCO's management have
    been stupid about the way the IP issues have been handled.

    I showed last week how SCO' IT department had failed to perform a
    basic security measure when configuring SCO's nameservers (it's since
    been fixed).

    Now, let's look at marketing. If you want to establish a brand name,
    it's ususal to register the appropriate domain name, just as a
    defensive measure. So, let's look at some of the SCO's names:

    UNIXWARE:
    Unixware.com
    Registrant:
    Mindbank Developments
    41035 Yokohl Dr
    Springville, California 93265
    United States

    Registered through: GoDaddy.com
    Domain Name: UNIXWARE.COM
    Created on: 27-May-98
    Expires on: 26-May-04
    Last Updated on: 27-Aug-03

    Clearly, not owned by SCO!

    OPENSERVER:
    Domain name: OPENSERVER.COM

    Administrative Contact:
    Superkay Worldwide, Inc. Hostmaster com
    PO Box 1027
    Seoul, NA 110-610
    KR
    +82-11-888-6005

    Again, not SCO. There seems to be some kind of search engine there.
    http://www.openserver.com

    SCOSOURCE:

    SCOSOURCE.COM
    Registrant:
    Domains by Proxy, Inc.
    15111 N Hayden Rd., Suite 160
    PMB353
    Scottsdale, Arizona 85260
    United States

    Well, since it is a proxy registration, can't tell immediately. However,
    if you look at the website:
    http://www.scosource.com it's clearly not owned by SCO.

    There you have it.
    Joe Guest

  2. #2

    Default Re: More examples of SCO's stunning competence

    Joe Dunning <invalid> wrote: 
     

    That is another area where SCO's performance has been less than
    stellar - though they are hardly unusual in that regard.
     

    SCO's "marketing" has historically been something you'd hold
    up as a shining example of incompetence.
     

    Well, they BOUGHT Unixware not so very long ago. It was not their
    product originally. Personally, I think tha
     
     
     
     

    And again, the "Openserver" name is fairly recent. Better than the
    prior "Open Desktop" (or "Open Dump Truck" as my ex-partner used
    to call it).
     

    There we have nothing that many of us would argue with. If you
    want to get y about SCO's alleged marketing, I could
    fill up a few pages.

    And the point would be.. what ? My web site is an ugly piece
    of crap because I have no artistic sense. Does that make me
    a bad person?

    --
    com Unix/Linux/Mac OS X resources: http://aplawrence.com
    Get paid for writing about tech: http://aplawrence.com/publish.html
    tony@aplawrence.com Guest

  3. #3

    Default Re: More examples of SCO's stunning competence

    On Thu, 30 Oct 2003 20:37:09 GMT, invalid (Joe Dunning)
    wrote:
     

    Novell bought the name from AT&T/USL. SCO bought it from Novell.
    Methinks it's Novell that forgot.
     

    Yep.
     

    Yep.
     

    Not quite. The real question is if SCO owns the trademark or service
    mark. If SCO does own the trademark, they can easily armtwist the
    various registrars into passing the domain ownership to the trademark
    owner.

    Go to the US Office of Patents and Trademarks search page at:
    http://tess2.uspto.gov/bin/gate.exe?f=searchss&state=vmsif9.1.1
    and try various trademarks.

    Unixware:
    Reg Number 2241666
    Transfered to SCO in Apr 1999.

    OpenServer:
    Abandoned by RETIX CORPORATION CALIFORNIA

    SCOSource:
    Not registered.

    I've mentioned indirectly to SCO management the issue of trademark
    registration, but nobody seems to care. At this point, I would agree
    as the value domain names isn't even worth the effort of trademark
    registration or litigation. Surely you don't think SCO's business is
    affected in any manner by a bunch of domain squatters?


    --
    # Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
    # 831.336.2558 voice http://www.LearnByDestroying.com
    # santa-cruz.ca.us
    # 831.421.6491 digital_pager com AE6KS
    Jeff Guest

  4. #4

    Default Re: More examples of SCO's stunning competence

    Joe Dunning wrote: 

    Taking this back to the technical, can you please explain to me (since
    you didn't in the first post). What exactly the security issue here is?

    Obscurity is not equivalent with security. I wouldn't give a flying
    if you'd got hold of our nameserver files or not - the *only* issue i
    can see in this is a possible DoS on the nameserver, and that only if
    your technically incompetent enough not to have this under control.

    --
    Med Venlig Hilsen / Regards

    Kim Petersen - Kyborg A/S (Udvikling)
    IT - Innovationshuset
    Havneparken 2
    7100 Vejle
    Tlf. +4576408183 || Fax. +4576408188

    Kim Guest

  5. #5

    Default Re: More examples of SCO's stunning competence

    On Fri, 31 Oct 2003 11:39:48 +0100, Kim Petersen <dk> wrote: 
    >
    >Taking this back to the technical, can you please explain to me (since
    >you didn't in the first post). What exactly the security issue here is?[/ref]

    If you look on ISC's web page:
    http://www.isc.org/products/BIND/contributions.html
    you will see a reference to this paper (in fact it's the FIRST paper
    referenced on that page):
    http://www.acmebw.com/resources/papers/securing.pdf

    Look at the FIRST thing it advises. As I said: standard procedure. If
    you think it is wrong, go argue with the author, or go argue with ISC.

    Incidentally, I note that some of the nameservers for kyborg.dk restrict
    zone transfers -- the nameservers that I think are outsourced?

    It seems you manage the nameservers for kyborg.dk, since the contact
    in the zone file is "kp.kyborg.dk".

    Given that:
    1. There is apparently authoritative advice to restrict zone transfers
    and
    2. there is no reason to not do this,

    It would seem that any prudent sysadmin would, in fact restrict zone
    transfers.


    Joe Guest

  6. #6

    Default Re: More examples of SCO's stunning competence

    Joe Dunning wrote: 
    >>
    >>Taking this back to the technical, can you please explain to me (since
    >>you didn't in the first post). What exactly the security issue here is?[/ref]
    >
    >
    > If you look on ISC's web page:
    > http://www.isc.org/products/BIND/contributions.html
    > you will see a reference to this paper (in fact it's the FIRST paper
    > referenced on that page):
    > http://www.acmebw.com/resources/papers/securing.pdf[/ref]

    Yes, and please read it ;-)

    It names some reasons for restricting access to your nameserver - lets
    take these one at a time:
    1. restrict taxing of nameserver [basically the DoS as i said].
    2. Hacker from listing the zone...

    a. to identify targets

    i won't go into this very deeply, but the argument here is basically
    obscurity=security, you would not claim that a hacker couldn't get at
    this info by other means - would you? (try host -t mx kyborg.dk - just
    to see if we can fetch the mailservers? try with -t ns and see if you
    can identify the nameservers?).

    b. host demographics

    again security==obscurity
    argument #2 isn't even valid, since its been a heck of a long time
    since i've seen anyone placing make/model in the TXT or other records.

    As for opposing views - he doesn't even mention them... like doing a
    host -l on a sister site (or a machine that needs the info - so that a
    local nameserver will function way above normal measures). Yes you *can*
    do this with private/public keys in bind - but this *really* opens a can
    of worms!

    The argument about topology is even outdated since CIDR is used so
    extensively today that a nameserver listing will *not* tell much about
    topology anymore.
     

    ISC? This is written by an independant consultant - besides ISC isn't
    the place i'd look for security information..... (for several reasons).
     

    Yep, highload domainservers where listing would effect the performance.

    --
    Med Venlig Hilsen / Regards

    Kim Petersen - Kyborg A/S (Udvikling)
    IT - Innovationshuset
    Havneparken 2
    7100 Vejle
    Tlf. +4576408183 || Fax. +4576408188

    Kim Guest

Similar Threads

  1. Replies: 2
    Last Post: October 22nd, 01:03 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139