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.
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.
Software:
========Here is a quick summary of the software we use:
Mail Server:
------------
qmail-1.03
MySQL (for vpopmail authentication)
vpopmail
qmailadmin
sqwebmail
Apache 1.3.28 (PHP4, mod_perl)
Web Server:
-----------
Apache 1.3.28 (PHP4, mod_perl)
MySQL
The mail server already has a robust, tightly integrated,
and very fast authentication system with vpopmail + MySQL.
And we are currently working on integrating this
authentication system into our billing system.
These facts lead me to believe that I would like
our mail server's auth system to be totally separate
from the "corporate" auth system. If we want an
employee to have an email account, we will either
set up an internal mail server, add the employee
to the billing system with a free rate code, or develop
some sort of automation system that takes the corporate
auth database and merges it with the billing system.
The web server, on the other hand, is a different
matter altogether. I would like to see some meshing
of the "corporate" auth system and the web server.
This way, I could define a certain website or web
page to be within a certain security clearance for
read access and/or write access, and the employee would
automatically have the appropriate access based on
security clearance.
Questions:
=========Anyway, I'm seeking more of a discussion than a single
definitive answer at this point. I'm ashamed to admit
it, but I'm really not aware of what my options are,
or what the strengths and weeknesses of each option
might be.
Listed below are the buzz words I've heard which I
think might be possible options:
1.) Kerberos
2.) PAM (Seems to be more of a library than a complete
solution.)
3.) LDAP
4.) RADIUS
5.) NIS/NIS+
We already use RADIUS to authenticate our dialup
pool, and I wouldn't mind using it to authenticate
employees, but I'm not sure if I can use RADIUS to
authenticate FreeBSD system logins and such. The rest
of the above items are relatively foreign to me.
At first, I thought Kerberos sounded like the best
solution, but the more I read about it, the more I
start to think it may be an aging solution and that
I might be better served to go with something else.
Then again, I think I've seen kerberos authentication
options in my Cisco routers... so maybe it's a good
choice after all...
In conclusion, I'd love to hear how other people have
defined and implemented their organization's security
model. Any personal stories, website links, or advice
would be welcome.
Thanks!
--
Jesse Guardiani, Systems Administrator
WingNET Internet Services,
P.O. Box 2605 // Cleveland, TN 37320-2605
423-559-LINK (v) 423-559-5145 (f)
http://www.wingnet.net
Jesse Guardiani wrote: If you'd like to help me work on my Active Directory Connector PAM module, I'd welcome it. ;-)
On Wednesday 24 September 2003 12:54, Matthew George wrote:> On Wed, 24 Sep 2003, Jesse Guardiani wrote: > > 1.) Kerberos > > krb is nice, but the problem with it is that all of your applications need > to be kerberized in order to support ticket validation from the krb > server. There is an interesting description (albeit slightly dated) of > how the system works at: > > http://web.mit.edu/kerberos/www/dialogue.htmlYes, I found that after I posted to the list. Very informative. I understand what you're saying when you say that all applications need to be kerberized in order to work, but isn't that true of any auth mechanism? Perhaps kerberization just isn't very widespread as something like LDAP?> > > 2.) PAM (Seems to be more of a library than a complete > > solution.) > > Indeed. PAM is a vehicle used to employ various authentication > mechanisms and not actually an authentication service by itself. For > example, you could specify that for login services to a machine, a user > must first attempt to authenticate via tacacs, but should that fail, > authentication against the system password file is sufficient. > > The following PAM support is available in FreeBSD (I'm running 5.1): > > mdg@mdg:/etc/pam.d> ls /usr/lib/pam*so > /usr/lib/pam_chroot.so /usr/lib/pam_opieaccess.so > /usr/lib/pam_deny.so /usr/lib/pam_passwdqc.so > /usr/lib/pam_echo.so /usr/lib/pam_permit.so > /usr/lib/pam_exec.so /usr/lib/pam_radius.so > /usr/lib/pam_ftp.so /usr/lib/pam_rhosts.so > /usr/lib/pam_ftpusers.so /usr/lib/pam_rootok.so > /usr/lib/pam_group.so /usr/lib/pam_securetty.so > /usr/lib/pam_krb5.so /usr/lib/pam_self.so > /usr/lib/pam_ksu.so /usr/lib/pam_ssh.so > /usr/lib/pam_lastlog.so /usr/lib/pam_tacplus.so > /usr/lib/pam_login_access.so /usr/lib/pam_unix.so > /usr/lib/pam_nologin.so /usr/lib/pam_wheel.so > /usr/lib/pam_opie.so > mdg@mdg:/etc/pam.d> ls -d /usr/ports/security/pam* > /usr/ports/security/pam-mysql /usr/ports/security/pam_ldap > /usr/ports/security/pam-pgsql /usr/ports/security/pam_pop3 > /usr/ports/security/pam_alreadyloggedin /usr/ports/security/pam_pwdfile > /usr/ports/security/pam_krb5 /usr/ports/security/pam_smb > > > 3.) LDAP > > LDAP is good because of the centralized directory services it provides. > You can store much more information about users other than their username > and password (such as addresses, job title, department, phone numbers, > location, public key, etc). I've seen documentation online (although the > specific location escapes me at the moment) about how to integrate UNIX > and Windows (active directory) authentication via LDAP (I believe the ADS > controllers become authoritative in this scheme ... not sure if openldap > can be used instead). This isn't something I'm familiar with first-hand, > but it's currently on my list of things to research. > > > 4.) RADIUS > > RADIUS is designed specifically for centralized user administration and > authentication. Support is available for a wide variety of devices (cisco > is included, but I'm pretty sure Windows isn't). pam_radius is included > in the FreeBSD base system and just needs to be enabled via PAM. > > > 5.) NIS/NIS+ > > My personal favorite, NIS can be used to provide many services to UNIX > hosts. NIS is at a bit of a disadvantage due to the unencrypted transport > of information. Although MD5 hashes in the passwd databases make > passwords harder to crack, usernames and group memberships may still be > retrieved with little difficulty if you have access to a network where NIS > is running. I definitely would not recommend running it on networks where > unknown / not-trusted users have access, but it has served me quite well > for access administration on internal servers / corporate networks. I'm > not familiar with a UNIX variant that does not support it, but you may > have problems with other network devices and Windows integration. > > > If you are running a Windows network with NT domain controllers, you may > want to look at pam_smb. > > Since you have cisco devices, you may want to look at pam_tacplus. > > Another alternative is OPIE (an S/Key derivative). This implements > one-time passwords, but will require much more support for users if they > aren't familiar with how it's supposed to work. > > I'm sure I'm forgetting something ...Well, I'm currently trying to decide between these then: Kerberos RADIUS LDAP (OpenLDAP only. I don't have a proprietary LDAP solution.) TACACS pam_smb, possibly. I'm ruling out NIS/NIS+ because: -------------------------------- 1.) I'd like something with decent cyptography built in. That's why I conceptually like Kerberos. 2.) AFAIK, no Cisco support. Now, I suppose the question is this: ------------------------------------ Will any of the above do ALL of the following? (The below is a prioritized list of the things I'd like to see in an authentication system:) 1.) Authenticate for ssh 2.) Authenticate for Cisco equipment 3.) Authenticate for Apache htaccess files 4.) Allow some way to easily set root passwords and su 5.) Do the above from a centralized location 6.) Do so with reasonable security/encryption 7.) Authenticate for Windows boxes And honestly, I could live with ditching the Windows Auth if a given solution works a lot better on *NIX. For example, I've heard that OpenLDAP is a real pain in the rear to install and configure. If that is true, and something like RADIUS or Kerberos would provide a better solution, then that's where I'd likely go. The other question I find myself asking is this: ------------------------------------------------ Once I get authentication working, how do I handle the creation of home directories and basic user files across multiple machines? Do I need to start running NFS, or is there a more elegant solution? Thus far, I've gotten a lot of great feedback from list members. Thanks! -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net
On Wed, 24 Sep 2003, Jesse Guardiani wrote:> The other question I find myself asking is this: > ------------------------------------------------ > Once I get authentication working, how do I handle > the creation of home directories and basic user > files across multiple machines? > > Do I need to start running NFS, or is there a more > elegant solution?www.openafs.org
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