From: Subject: Solaris User Accounts Date: Wed, 14 Nov 2001 09:01:26 +0100 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.usenix.org/sage/sysadmins/solaris/solaris/accounts.html X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Solaris User Accounts

Solaris User Accounts

Password Settings

Entries = in both of=20 the following files affect the use of passwords. The first two are = particularly=20 critical to forcing good password discipline on a system.

/etc/default/login=20
Make sure the entry PASSREQ=3DYES = exists and=20 is not commented out

/etc/default/passwd=20
Set PASSLENGTH=3D8 to establish a = safer=20 minimum length for user passwords. Set to a greater length as = required by=20 your security policy.

Consider setting MAXWEEKS to = implement a=20 password aging scheme

[=20 Back to Checklist ]

Unnecessary = Accounts

The general=20 rule is to minimize the number of active accounts on your host. You = should=20 always delete accounts such as guest  = &=20 visitor  because they offer crackers an easy way to use = known or=20 newly discovered exploits to gain root access to your host. If you must = use=20 accounts created by installation programs, change the default passwords = for=20 these accounts.=20

For Solaris 2.x, the following userids are created during = installation, and=20 are required by the operating system. You should lock these accounts or = assign=20 an invalid shell to prevent crackers from using them to log in to = your=20 system:

The following account is for backward compatibility and should be = deleted=20 unless you must support access from SunOS (Solaris 1.x) systems.

[=20 Back to Checklist ]

Give disabled accounts an invalid=20 shell

The operating system will prevent log in for an = account=20 that is assigned an invalid shell. This is a good "defense in depth" = strategy to=20 prevent crackers from using default accounts to gain access to your = host.=20

Assign the shell /bin/true or /bin/false as = the=20 shell for accounts that should never be allowed to log in. A better = solution is=20 to use a locally compiled version of the = noshell =20 program.

[=20 Back to Checklist ]

Prevent ftp Access With Disabled userids

Create = the file=20 /etc/ftpusers and add the following default Solaris = accounts to the=20 file.=20 [=20 Back to Checklist ]

Final Checks
  • Verify that all who have accounts have a valid need to access the=20 system
  • Verify that access to the root  account is = restricted
    We recommend that no more than 3 to 4 people have access = to the=20 root password. Further, all authorized users should be forced to log = in with=20 their non-privileged userid and use su to access the = root=20 account.
  • Make sure all accounts have an x in the password = field in=20 /etc/passwd to force the use of Solaris' shadow password = file
  • Check /etc/shadowto make sure disabled accounts have = either=20 NP or *LK* in the password field
  • Check that no accounts other than root and smtp have the user id = (UID) of=20 0 (zero)
  • Use the command logins -p to check = for=20 accounts that do not require a password to log in
  • Check /etc/group for the presence of a wheel group = (group 0).=20 If supported, the list of users for this group should not be null=20
    Note that only those users shown in the user list for the = wheel=20 group will be allowed to su to root. All other users will be denied = access,=20 even if they enter the correct password.
  • Run COPS or Tiger to verify that all default passwords have been=20 changed
[=20 Back to Checklist ]

Good Passwords
  • Contain at least eight characters
    When properly derived, longer passwords are more difficult = to=20 guess. For maximum security, ALL passwords should contain at least = eight (8)=20 characters.
  • Are not words in any language
    Passwords constructed from words are vulnerable to=20 dictionary-based attacks. Tools to automate dictionary-based attacks = are=20 readily available making it easy for crackers to discover such = passwords.=20 Passwords that consist of concatenated short words (e.g. goodtime) = or words=20 with numbers concatenated are also vulnerable to dictionary-based = attacks,=20 and should be avoided.=20

    One recommendation for generating secure passwords is to use the = leading=20 letters from poems or song lyrics, with non-alphanumeric characters = (e.g. -,=20 *, {, }) thrown in. This should help create a mnemonic strategy to = make the=20 password easy to remember, thus avoiding the need to have it written = down in=20 some convenient place. One should also make the constructed password = easy to=20 type to make it harder for shoulder surfers  to learn = the=20 password by observing you as you enter it.

  • Are changed on a regular basis
    One recommendation is to use password aging to force a = change=20 every 6 months.
[=20 Back to Checklist ]=20
Last Update: 1998 November 27