Re: Help with audit/password needs on Solaris 8

From: K7MEM (k7mem_at_myrealbox.com)
Date: 10/30/04 

Date: Sat, 30 Oct 2004 10:51:00 -0700

Red Rogers wrote:
> Hi,
>
> In Solaris 8, how do you do the following?
>
> 1. User ID/Password are automatically disabled after five (5)
> consecutive unsuccessful attempts to login.

As someone else has said, real bad idea. I believe this can be done
from the "/etc/default/login" file, but I don't remember the
entry off hand. But the disabling works for "root" as well as any other
user, so someone could easily shut out the root admin.

We run a minimal auditing and repeated unsuccessful attempts will
show up in the daily review. See "/etc/security" and "man audit".
The fact that a user has exceeded the specified number of tries
will be recorded in the audit file.

> 2. Inactive User IDs are disabled after 45 days or deleted after the
> 120 days

Here, a account is only considered inactive after the password expires.
We run a perl scrip that processes the password and shadow files every
day. It uses the password change date field in the shadow file to tell
how old it is. At 55 days old it starts to send out notices to the user
that he/she has N days to change their password before it expires. If
they ignore it, the users login shell is changed to point to a script
that generates a notice, if he tries to log in. The notice directs him/her
to call the help desk.

After 120 days the account is disabled by changing the shell to "/bin/false",
the "/dev/null", and putting a "X" in front of the users name.

After the 120 days the users login account can be archived to CD and
removed from the system. Backups on tape are kept for 2 years and the
CD are archived forever. We never really delete user data.

We also never reuse a UID. There are more than enough numbers to go around.
Keeping them in the password file gives you tracability to previous
users, especially if you use any configuration control software that
relays on the UID number.

> 3. Passwords should have a min 6 char, must include a combination of
> alpha, numeric, and special characters.

This is already part of the of the "passwd" command. The combinations are
built in and the minimum number characters is controlled by the
"/etc/default/passwd" file. Most secure areas are set to 8.

> 4. When a password is changed, the old password must not be reused
> until at least four (4) other passwords have been used.

I think this only works for your last password. We don't worry about this
much because we run a password cracker on a weekly basis, and ferret out
the users with weak passwords.

> 5. Pre-assigned or temporary passwords/PINs associated with User IDs
> are aged to force the user to change the password with the first login,
> and are disabled after 14 days of inactivity

We only give them a week to 10 days. If we set a temporary password for
a user we adjust the password change date, in the shadow file, to "now - 10"
so that our password aging script will automatically detect it and
expire it, if the user doesn't change it.

> 6. Passwords are aged to expire at every 30 days

IMHO 30 days is too often. Our requirements are for changing the root
passwords every 30 days but users have 65 days.

> 7. Successful Logins supply the date and time of last login

You can log all successful and unsuccessful logins if you use auditing.
See the man page on "audit" to learn how to enable, control, and process
audit logs. Just remember, any log file you create is useless, unless
you have someone to read them. For this we run scripts that process the
audit files nightly, collect the information we want to see, and then
send email to root. We only send to root because users are not allowed
to even view the audit data.

As an extra added bonus, we use eprom passwords so that users can not
boot single user to a CD and gain access to the system. This doesn't
affect normal booting. In even more secure environments, we don't allow
the users access to any removable media.

Martin 

-- 
Martin E. Meserve - K7MEM
http://www.k7mem.150m.com
Quantcast