Hosts on "minimum security" networks
Draft (this has not been approved, Created 2/07/07 -jd)
SDSC Administrator Security Guidelines
The following are recommended guidelines for securing your Server host from unauthorized access. Following these guidelines will not guarantee your host will not be compromised, but are useful in reducing your risk.
Privilege (root) access
-*NO* remote root logins. PERIOD. No excuses. Log in as a user and use sudo or su, or equivalent.
-If direct root login is required, then do it at the console. There should not be an excuse for remote root access.
-Minimize and keep track of the number of people who have and use the root password. Use sudo where possible to give privileged access to others outside your work group.
-Admin access should be from "secure" locations. Root password is changed whenever anyone who had it leaves the job or changes roles and no longer needs it on the server host.
-Do seperate user login authentication from privileged access authentication. In other words, the user password MUST be different from the privileged access password (su or sudo password).
-Any activity that might inadvertently expose the root password, e.g. accidentally typing it in as a username, *must* be followed by a root password change.
Accounts and Authentication
-Require strong passwords for accounts, even when initally creating accounts. SSH scanners regularly attacks systems looking for easily guessed passwords. A system with PAM can implement these controls very easily.
-Any network services which provide authenticated access to resources must use an encrypted transport or other means (Kerberos, token authentication) to prevent interception and replay of passwords, (SSH2 instead of telnet, HTTPS instead of HTTP, Imap/ssl instead of imap).
Files and File Systems
-Audit all setuid root binaries and remove the setuid bits from unnecessary programs. Unnecessary programs include ones that you do not know what they are or do.
find / -mount -perm -004000 -user root -exec ls -lg {} \;
All world writable directories should have the sticky bit set.
drwxrwxrwt 4 root sys 571 Apr 13 15:17 /tmp/
-In general, files owned by root should not be world writable, and usually not group writable.
-Most current day operating systems have this but, audit root's path, make sure dirs are owned and only writable by root. minimize as much as possible, e.g. /sbin:/usr/sbin:/bin:/usr/bin
-Use RCS, Revision Control System, to maintain important configuration files, such as, hosts.allow, inetd.conf, hosts, sshd_config, etc.
-DO NOT mount file systems with SETUID enabled. DO NOT export file systems with root user privileges. Export your NFS file systems to specific hosts, do not export to the world or use wildcards in the config files.
-Output from mount command:
/usr/local on mynfs:/usr/local/generic remote/read only/nosuid/vers=3/bg/intr/xattr on Tue Apr 13 07:47:32 2004
-Example entry for fstab file:
mynfs:/usr/local/generic - /usr/local nfs - yes rw,bg,intr,nosuid,quota
Other
-Machines should be installed off the network until they are fully and safely configured to be on the network.
-Automate, or at least document, the build process so that it can be repeated, as comprimised machines should be reinstalled from scratch. Having an automated build process will minimize the downtime due to system recovery.
-It is very important to keep up-to-date with security patches. Most systems are compromised by obtaining privileges through known exploits for which there already exists a patch.
-Log your syslog data to local disk and to @lager.sdsc.edu. Security Technologies can help monitor your system for known bad guys and signs of intrusion. (For now this service is free!) Here is an example syslog entry:
- .debug /var/log/messages
- .debug @lager.sdsc.edu
-These log files should only be root readable, owned by root with permissions of 600. If you must, allow the root group or some other group you create to read the log files and put only necessary users in this group.
-Use NTP to keep the system time accurate. This will help with the accuracy of timestamps in the log files, and it is important if you are usingNFS.
-Turn on process accounting. You will also need to enable rotating of the account file as is not done automatically.
-Do understand and use TCP Wrappers for access control to your Server system. Perform, maintain and audit your backups. You may need them to restore your system back to a known state.
-Pay attention to what is going on in your systems. Know what services are running. Run PS and lsof regularly and understand what is running that is not familar.
end