Skip to main content

Sysadmin security: 8 Linux lockdown controls

How to lock down your Linux system from unwanted access locally and across the network.
Linux lockdown controls

Image by Bob McEvoy from Pixabay

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.


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.


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

Topics:   Linux   Security  
Author’s photo

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

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.