Some Tips for Passwords and Logins
Legend:
- R : Root, user role
- S : System Accounts
- U : User Accounts
In general order of increasing security.
Do not send passwords in clear text over the network
[RSU]
As a general rule no protocol that transmits unencrypted authentication data over a network should be used. Examples of insecure protocols are telnet, ftp and the r* tools. All modern Unix and Linux systems ship with secure alternatives as default, and either no longer contain or require manual intervention to enable legacy protocols.
Where legacy applications demand use of insecure protocols, they should be armoured by using tcp_wrappers or iptables to restrict the communication to only known “safe” systems. Interactive use by users should be avoided at all times, minimizing the risk associated with transmission of authentication data over unsecured channels.
Constant policy across systems
[RSU]
Because of implicit trust relationships between development, quality and production servers, and commonality of implementation, it is unwise to allow insecure policies on development systems, as compromise of a development system may lead to easy compromise of a production system.
In general it is also easier and safer to use one secure suite of tools when dealing with all systems, than a two different families of tools for each class of system.
Disable or lock unused system accounts
[S]
Most legacy Unix and some early Linux system ship with many system accounts enabled and remotely accessible. As a general rule most of these accounts should be either deleted or disabled from login.
Do not allow remote login for the root user
[R]
As a general rule there is no requirement to ever remote login as the super user. Remote root login should be disabled by default – even when using secure login, and users should login as users, and change to the root user as required. Remote root login is disabled by default on many modern Linux systems.
root_squash should be enabled on NFS, preventing root on one system behaving as root on a remote file system. nosuid should be enabled on NFS preventing remote files from running with root privileges on local systems.
Protect NFS at both the client and server side
[RU]
There is no security in this protocol at all. The client system mounts the remote file system without verifying that the remote system is the correct one. The server system allows the remote system to modify it’s file system without checking that it is the correct one, or attempting to verify the authenticity of the remote user. For this protocol to function at all it is essential that users have exactly the same UID and GID numbers, which normally requires a NIS or LDAP server, though it is possible to maintain by hand.
Modern Linux and Unix systems now run with sane defaults (see above), and it is advisable to protect components of the NFS system with tcp_wrappers or iptables, as the built in security is too weak to be relied upon.
Sound Password Policy
[RU]
Passwords should be easy to remember and hard to guess. Most modern Linux/Unix systems check passwords by default and complain if they are based on a dictionary word. Passwords should be longer than 8 characters, and contain numbers and punctuation. Password ageing is a poor security policy in general, and pointless unless implemented within a broader security framework – indeed it can tend to less secure systems because of the constant change in passwords.
OpenSSH key based login
[U]
Correct configuration of the SSH system allows for logins without the use of passwords. This method of login is both significantly more secure, and more convenient than password based logins. OpenSSH is standard on most modern Linux/Unix systems, and is recommended by most vendors as the default method of login on, and copying files between systems.
OpenSSH offers several security hardening options, for example limiting remote logins to only specified users.
Lock root account
[R]
As a general rule on modern Unix and Linux systems there is no reason at all to permit interactive use of the root account. In fact several popular systems ship with root disabled by default, e.g. Mac OSX and ubuntu. Most root functions can be carried out via the sudo command, which has the advantage that the user never becomes root. It is possible with the sudo command to limit which commands specific users can execute with root privileges, and an audit trail of every command issued is created by default. When necessary it is possible to become the root user using the sudo.
See also:
These guidelines are based on guidelines I put together for work. They were discussed on the email list, and as promised I’ve turned them into a Wiki page – AdamTrickett
Leave a Reply
You must be logged in to post a comment.