more xyplex commentary

From: Matthew G. Harrigan (matthat_private)
Date: Tue Dec 02 1997 - 16:24:51 PST

  • Next message: Bill Paul: "Re: an detailed explaination why land attack works?"

    comments from Michael Johnson, an experienced (frustrated :) ) xyplex admin:
    
    
    This sounds like the problem that we faced with the Xyplex Terminal Servers
    and people getting in with "guest" access to our modempool.
    
    Our problem:
    
    Our guest access dropped people to a prompt and let them go anywhere in our
    domain, but no where else.  This was so people could access our library and
    such.  We used the script services of the Xyplex Terminal server to allow
    this "guest" access and to setup their permissions.
    
    About a month ago, we officially turned off guest access, but people were
    still getting in by putting a "/" anywhere in the login name.
    
    ex:
    Username:name/ssn
    
    This is what was happening:
    The terminal server would attempt to get a script from the script server
    that you have defined (if you are using scripts).  When an attempt is made
    to get a script, it first tries (using the above example)
    "/tftpboot/name/ssn/login", if that doesn't work it backs off one directory
    (and does this incorrectly in my opinion).  Instead of trying
    /tftpboot/login (taking out the login name of "name/ssn" it only backs off
    to /tftpboot/name/login).  After this failure it assumes a
    misconfiguration, gives a script server timeout(?) error and gives the
    person default access.
    
    Note that this is only if you have
    DEFINE PORT ports SCRIPT LOGIN ENABLED
    
    If instead you use
    DEFINE PORT ports SCRIPT LOGIN REQUIRED
    the same thing happens only the user does not get default access, instead
    they are logged out.
    
    
    I see this as a bug in the xyplex code where it assumes the directory and
    file to tftp is part of the login name, but doesn't correctly "back-off"
    using the full login name (only up to the "/") and trying again.
    
    It does this so that you can setup special logins that auto-telnet to
    certain hosts or somesuch.  Its a great feature, but when it fails it does
    not correctly retry like it does, its a menace.
    
    In order, it searches for a login script like this:
    
    1. searches for "/tftpboot/loginname/login"
    2. removes the loginname portion of "/loginname"
    3. searches for "/tftpboot/login"  <-- which exists and runs correctly for us.
    
    however, if you put a / in the login name it does this:
    
    1. searches for "/tftpboot/login/name/login"
    2. removes only "/name" not "/login/name" like it should
    3. searches for "/tftpboot/login/login"
    4. dies with script error and if not "required" gives a person default access.
    
    
    Wierd huh?
    
    I'm not saying this will fix your problem, but perhaps if you try
    "REQUIRED"ing whatever option you have turned on instead of just
    "ENABLED"ing it, this may fix your problem.
    
    Are you requiring radius authentication or just enabling it?  There is a
    BIG difference.  If radius is enabled and a person enters an invalid
    login/password sequence and radius fails authentication then it works
    properly, but if radius just fails with another type of error and since
    radius is only enabled, not required, you get default access (whatever that
    may be?).
    
    Anyway, its an idea.
    
    
    Matthew G. Harrigan
    CEO, Microcosm Computer Resources
    http://www.mcr.com
    matthat_private
    415-333-1062
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:34:06 PDT