4.2.3 Authentication
Good security requires secure accounts.
- Make sure that all OS accounts are hard to guess. To ensure that the passwords are not guessable, use crack or john-the-ripper (password cracking tools) on a regular basis. Use password cracking tools on a regular basis to ensure password complexity. Often, people use passwords associated with them: license plate numbers, children's names or a hobby. A password tester may check for these. In addition, change passwords from time to time
- Automatically disable accounts after several failed login attempts.
- .netrc files weaken security.
- The fewer people with root access, the easier it is to track changes.
- The root password must be a strong, hard to guess. In addition, change the root password every three (3) months and whenever an administrator leaves company. Always logout of root shells; never leave root shells unattended.
- Limit root to console login, only (specified in /etc/security).
- Root, and only root, should have UID 0.
- Check root ‘.*’ files for security holes. The root ‘.*’ files SHOULD have 700 or 600 permissions.
- umask for root is 022 (rwxr-xr-x). A umask of 077 (rwx------) is best, but often not practical.
- To avoid trojan horse programs, always use full pathnames including aliases. Root should NEVER have “.” in path.
- NEVER allow non-root write access to any directories in root's path.
- If possible, do not create root's temporary files in publicly writable directories.
Do not share user accounts. Remove or disable user accounts upon termination. Disable login for well known accounts that do not need direct login access (bin, daemon, sys, uucp, lp, adm). Require strong passwords and, in some cases, a restricted shell.
It is hard to imagine what kind of guests should have access to a production system. For this reason do not allow guest access.
Parent topic: Database Operating Environment Security