Hosts on "minimum security" networks: Difference between revisions

From Security Wiki
Jump to navigationJump to search
No edit summary
No edit summary
Line 70: Line 70:


----
----
In addition adminstors must comply with the [[https://security.sdsc.edu/wiki/index.php/Acceptible_Use]]SDSC Acceptable use policy.
In addition adminstors must comply with the [[https://security.sdsc.edu/wiki/index.php/Acceptible_Use|SDSC Acceptable use policy]].


----
----

Revision as of 00:46, 9 February 2007

Draft (this has not been approved -jd)

SDSC Administrator Security Guidelines

The following are recommended guidelines for securing your ServerNet 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.

-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. ]

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.

-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.

-Do understand and use TCP Wrappers for access control to your ServerNet system. Perform, maintain and audit your backups. You may need them to restore your system back to a known state.


In addition adminstors must comply with the [Acceptable use policy].