Date: Wed, 24 Sep 2003 17:01:05 -1000 From: Clifton Royston <cliftonr@tikitechnologies.com> To: Jesse Guardiani <jesse@wingnet.net> Cc: freebsd-security@freebsd.org Subject: Re: unified authentication Message-ID: <20030924170103.A3892@tikitechnologies.com> In-Reply-To: <20030924190048.D69EA16A53C@hub.freebsd.org>; 12:00:48PM -0700 References: <20030924190048.D69EA16A53C@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030924170103.A3892>