Re: unified authentication

From: Clifton Royston (cliftonr_at_tikitechnologies.com)
Date: 09/25/03

  • Next message: Jacques A. Vidrine: "Re: NTP common code base ?"
    Date: Wed, 24 Sep 2003 17:01:05 -1000
    To: Jesse Guardiani <jesse@wingnet.net>
    
    

    On Wed, Sep 24, 2003 at 12:00:48PM -0700, freebsd-security-request@freebsd.org wrote:
    > Date: Wed, 24 Sep 2003 10:27:37 -0400
    > From: Jesse Guardiani <jesse@wingnet.net>
    > Subject: unified authentication
    > To: freebsd-security@freebsd.org
    > Message-ID: <bks9kq$46u$1@sea.gmane.org>
    > Content-Type: text/plain; charset=us-ascii
    >
    > Howdy list,
    >
    > Sorry if this is a frequently discussed topic,
    > or an off-topic question, but I couldn't find much
    > info about my question by performing quick searches
    > in the archives, and my question is pretty tightly
    > related to security...
    >
    > Background:
    > ===========
    > I have a number of FreeBSD machines. Most are 4.x,
    > but a few are 5.x (mainly the testing/devel machines).
    >
    > I also have a single Red Hat Linux machine (mostly
    > a former employee's play toy), a legacy BSDi 4.1
    > machine, and a single Windows 2000 Server.
    >
    > And, of coarse, I have a number of Cisco routers of
    > all shapes, sizes, and capacities.
    >
    > I have recently been plagued by the security audit
    > woes, as employees have left the company and new
    > employees have come in. The former Sys Admin didn't
    > keep a list of places where passwords are stored,
    > and the company really has very little in the way
    > of a security policy, so I'm having to audit and
    > document as I go.
    >
    > The motivation behind this email is simply that I am
    > seeking to end my security woes. I'd like to be able
    > to quickly (10-30 minutes) setup and remove employees
    > from the various servers/routers and have the knowledge
    > that I haven't missed anything.

      One approach to quickly get you off the ground from your current
    situation (where everything is a mess and you don't know who has access
    to what.)

    1) Establish classes of servers (e.g. production, test, development,
       play) and other equipment (e.g. production routers, learning
       routers, terminal servers, switches.)
     
    2) Each *class* of server or device gets a different root password (or
       enable password for Ciscos) and every server/device in each class of
       server or device gets the same password.

    ** At this point you can do a first sweep through and change all the
       root/enable passwords, and have a bit less worry about ex-employees.

    3) Give users logins only on the systems they reasonably need access
       to. (E.g. only developers and the top sysadmins have logins on
       development machines, only sysadmins have logins on routers.) You
       may need to remove people's access to some machines they were used
       to doing stuff on; be kind but firm.

    4) Give admins logins only on the routers they need access to; you can
       configure the Cisco routers to access a RADIUS server with a db file
       of authorized admins as a fairly quick and easy authentication
       setup. (If you decide you have multiple classes of Ciscos, you can
       point them to separate Radius instances running off of separate
       admin db files.)

    5) Require ssh-only access for all network devices which support it,
       and of course for all servers. That reduces sniffing impact.

    6) Put sudo onto all servers, and require your staff (including
       sysadmins) to use sudo in place of su on those servers. Configure
       sudo to provide "sudo power" access to only limited commands for non
       sysadmins, via using their own passwords, and full access to senior
       sysadmins but only via the root password for that server. (That
       last doesn't improve security per se, but gives you some logging.)

    ** Now you should be able to cut down on the number of employees who
       need root access, to just the more seasoned sysadmins.

    > I've been thinking about it, and it seems like it
    > would be beneficial to define "security clearances"
    > and possibly different passwords for each employee
    > at each security clearance level. That way, if one
    > password was somehow sniffed or stolen, the security
    > breach might stand a better chance of being contained.

      The separate login/sudo passwords above help cover that, plus the
    separate passwords for separate classes of machines. I think classes
    of machines, and then groups of users who should have access to each
    class, is an easier way to think about it.
     
    7) When a user leaves, you need to change only the root passwords which
       affect the classes of machines they had access to; this only has a
       big impact when your top sysadmins leave, not whenever every
       employee leaves.

      Now you can start worrying about setting up central authentication
    systems so that you can pop users in and out more readily, and you
    should have an easier time deploying one because you'll know what
    classes systems fall into, who should be in each class, etc. This is
    just basic getting organized stuff it will help you to clear away
    first.

      All IMHO,
      -- Clifton

    -- 
              Clifton Royston  --  cliftonr@tikitechnologies.com 
             Tiki Technologies Lead Programmer/Software Architect
    Did you ever fly a kite in bed?  Did you ever walk with ten cats on your head?
      Did you ever milk this kind of cow?  Well we can do it.  We know how.
    If you never did, you should.  These things are fun, and fun is good.
                                                                     -- Dr. Seuss
    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
    

  • Next message: Jacques A. Vidrine: "Re: NTP common code base ?"

    Relevant Pages

    • Re: Automatic Client Login
      ... client data, I was hoping there was at least a way to allow printing (the ... I am terribly new to server based networks and SBS is my first experience ... manner as the other four machines) that I can't join the Pro box to the ... physical security if you save the passwords on the machines. ...
      (microsoft.public.windows.server.sbs)
    • yp troubles
      ... I've tried several times to get NIS to allow me to update passwords ... from any of my machines and I still haven't gotten it to work. ... On a client machine, I can run yppasswd and update ... Problem two occurs on the server. ...
      (comp.os.linux.networking)
    • Re: Automatic Client Login
      ... You then set up workstations with usernames/passwords that match the usernames/passwords on the server. ... I have a hardware firewall and then my SBS still has two nics and does another firewall duty. ... I just tried connectcomputer on the Pro machine, and it seems due to the topology of my network between the WAN and the LAN (the server is physically connected to the router in the same manner as the other four machines) that I can't join the Pro box to the domain. ... You run the risk of lack of physical security if you save the passwords on the machines. ...
      (microsoft.public.windows.server.sbs)
    • NT 4.0 Workstations unable to change passwords
      ... mode (Not Mixed Mode) with one global catalog server at each of 10 ... if they are not in the same subnet/site/branch as the server running ... machines on the same subnet have no problem changing passwords. ...
      (microsoft.public.win2000.active_directory)
    • NT workstations unable to change domain password.
      ... mode (Not Mixed Mode) with one global catalog server at each of 10 ... if they are not in the same subnet/site/branch as the server running ... machines on the same subnet have no problem changing passwords. ...
      (microsoft.public.win2000.general)