Re: How to tighten UNIX security
From: James T. Dennis (jadestar_at_idiom.com)
Date: 07/18/03
- Next message: Kelly Paletta: "Re: How to tighten UNIX security"
- Previous message: Schmuck: "HP FUDBusting"
- In reply to: Stephen: "How to tighten UNIX security"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 17 Jul 2003 22:40:26 -0000
Stephen <stephen.day@eps-hq.com> wrote:
> Hi there
> I am looking at the best methods or products that can be used to
> restrict access to UNIX machines. Does anyone have any recommendations
> that you might be able to supply me.
> i.e. programs that create limited life passwords
Most versions of UNIX (and distributions of Linux) support password
aging. In the case of Linux it's through the Shadow suite and PAM
(pluggable authentication modules). I think FreeBSD's PAM is a port
from the Linux code base. HP-UX 11.0 apparently integrated a port from
the Sun implementation.
PAM (supported by Linux and Solaris, at least --- though the implementations
are somewhat different) provides and API for administrator configurable
authentication. You can think of PAM as being a sort of modular "language"
in roughly the same sense that packet filtering rules are.
A user attempting to authenticate against a PAM linked service is
subjected to an arbitrary number of tests and directives. They fall
into categories such as: auth, account, session and password.
(This is the most confusing part of PAM, auth is used to prompt for
passwords, challenge for authentication responses, etc; "password"
type modules are for updating and manipulating the auth token --
forcing the user to change their password or checking and warning about
weak passwords, etc, account is for limiting and maintaining account
access in ways beyond authentication --- time of day/week, allowed
terminal or connection source address, etc.)
So, with PAM each service has a list of rules associated with it.
In *old* versions of Linux PAM there was a single /etc/pam.conf file
which had the service names as a prefix for each line. In more
recent versions there's an /etc/pam.d/ directory with a control file
for each service (with /etc/pam.d/other being a default for PAM
services lacking their own conf file. I suspect you could still use
the old pam.conf file if you wanted.
A typical PAM config file:
auth requisite pam_securetty.so
auth requisite pam_nologin.so
auth required pam_env.so
auth required pam_unix.so nullok
account required pam_unix.so
session required pam_unix.so
session optional pam_lastlog.so
session optional pam_motd.so
session optional pam_mail.so standard noenv
password required pam_unix.so nullok obscure min=4
(default for /etc/pam.d/login on a Debian Sarge system)
The first line implements the check for /etc/securetty --- root
can't directly login to "insecure" terminals. The next checks for
an /etc/nologin file. The next will set up a users environment
with the contents of /etc/environment (in a shell independent manner)
The next three lines, and the last line all refer to pam_unix.so;
thus all of them implement the normal UNIX account, authorization,
and session semantics --- reading account info from using getpwent()
using the MD5 password hash from /etc/shadow, and spawning a user's
shell based on the last field of the account info.
As for as I know it's all done by getpwent(), which automatically
merges /etc/shadow password hashes if the process can read /etc/shadow
at this point --- allowing for SGID shadow to work. This is important
because it means that various other NSS passwd, shadow, and group
backends like NIS, NIS+, even LDAP, etc. will automatically work with
pam_unix.so.
The next three modules display the last login info (including the
number of failed login attempts since the last login), the message of
the day, and the status of your mail.
As you can see, PAM breaks the process of "normal" login into
a number of other steps. It can apply similar handling to su, sudo,
the passwd command, ssh (if ssh is linked to it), rsh/rlogin,
or any other service or program that's linked against it's libraries
and written to its APIs.
The Linux version of PAM is documented primarily at:
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/
You can also limit access to services based on various networking
criteria; source IP address being the primary one. That is most
commonly done with Wietse Venema's TCP Wrappers and or by linking
against his "libwrap" libraries. This xinetd is normally linked
against libwrap; as is the Linux version of portmapper.
As for other "products" and methods for limiting access to your UNIX
machine; most of them depend on your version of UNIX. Since authentication
and authorization is done in userspace under UNIX, in general programs
and implement any policy the programmer wants given access to root or
to SUID helper utilities or root-run daemons. This is a bane and a blessing
since very few programs are robust enough to be trusted with root; set
a large number of programs need to access "root" powers under UNIX.
> etc
> Stephen
-- Jim Dennis, Starshine: Signed, Sealed, Delivered
- Next message: Kelly Paletta: "Re: How to tighten UNIX security"
- Previous message: Schmuck: "HP FUDBusting"
- In reply to: Stephen: "How to tighten UNIX security"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
