Sysadmin security: 8 Linux lockdown controls
Security is a perennial topic of interest for sysadmins. And securing new systems always presents a challenge because there really are no set standards for doing so. I'm pulling this article's list of security measures and controls from a variety of sources, including personal experience, DISA STIGs, and recommendations from other system administrators and security folks. While these security measures are good, they're only a first step toward better system security. These eight system controls are in no particular order of importance.
SSH keys
Configure passwordless authentication using SSH key pairs. Check the article by Susan Lauber for instructions: Passwordless SSH using public-private key pairs. Passwords are not a good security measure, no matter how long or complex they are. Using SSH key pairs and a single jump box, you can establish a high level of secure access to your systems.
SSH authentication
Once you've set up SSH key pairs for authentication, you'll need to configure SSHD
to accept them for remote login. The /etc/ssh/sshd_config
file is the central location for securing SSHD
on your systems. Notable options to check and change are:
Original Setting | Change To |
---|---|
#PermitRootLogin yes | PermitRootLogin no |
#PubkeyAuthentication yes | PubkeyAuthentication yes |
#PermitEmptyPasswords no | PermitEmptyPasswords no |
PasswordAuthentication yes | PasswordAuthentication no |
You must restart SSHD
after you make changes to the configuration file so that your changes take effect.
NULL passwords
Check that all accounts use a password for authentication. Don't allow any account to have a null or blank password. Setting up key pairs is a good defense against null passwords. Remove any instances of the "nullok" option in /etc/pam.d/system-auth
and /etc/pam.d/password-auth
to prevent logins with empty passwords.
Remove nonsecure services
To better secure your systems, remove any nonsecure services (those that send passwords in plain text over the network or those that allow anonymous (non-authenticated) connections). Remove the following packages:
- ypserv
- rsh-server
- vsftpd*
- telnet-server
- tftp-server
File transfers and interactive connectivity between systems should be done using SSH
. There's no need for rsh-server
, vsftpd
, and telnet-server
. You should substitute LDAP or Active Directory for ypserv
(NIS/NIS+). As for tftp-server
, if you must use it, dedicate one system or virtual machine to it and install it into a chroot
jail for better security.
*While vsftpd
encrypts communications, this function is better handled by SSH/SFTP/SCP
.
Disable host-based authentication
Remove all instances of host-based authentication in the form of .shosts
and shosts.equiv
files. Host-based authentication is insufficient for preventing unauthorized access to a system, because it doesn't require interactive identification and authentication of a connection request, or for the use of multi-factor authentication.
SNMP version and community name
Use SNMP version 3.x for user authentication and message encryption. Change the default community string from public
or private
to a different string value.
X11 Forwarding
Be sure that if you use the X protocol on your network that it is secured by SSL. Edit the /etc/ssh/sshd_config
and set the X11Forwarding parameter as follows:
X11Forwarding yes
If the parameter exists but is commented with a leading #
, then remove the #
and restart SSHD.
Securing GNOME
If you use GNOME on your server systems, secure it with the following settings in the /etc/gdm/custom.conf
file. Add or edit the line for the AutomaticLoginEnable
parameter in the [daemon]
section of the custom.conf
file to false, as shown below.
[daemon]
AutomaticLoginEnable=false
And add or edit the line for the TimedLoginEnable
parameter in the [daemon]
section of the /etc/gdm/custom.conf
file to false, as shown below.
[daemon]
TimedLoginEnable=false
Some security advisors warn again using graphical user interfaces (GUIs) on server systems because of malware that targets them.
[ Further enhance your system security with Antimalware software: 3 antimalware solutions for Linux systems ]
Wrap up
Although its Unix-like security is very good, Linux isn't 100 percent secure after an install. And there's no such thing as 100 percent secure, but you can set some controls and perform some basic tasks to secure a system better. I'm in the process of bringing you more articles like this that are system security-focused.
[ Want to learn more about security? Check out the IT security and compliance checklist. ]
Ken Hess
Ken has used Red Hat Linux since 1996 and has written ebooks, whitepapers, actual books, thousands of exam review questions, and hundreds of articles on open source and other topics. Ken also has 20+ years of experience as an enterprise sysadmin with Unix, Linux, Windows, and Virtualization. More about me