10 Tips for Hardening a Linux Server

In light of all the complex and specialized attacks on Internet-facing servers, it’s very important to protect your cloud assets from malicious assailants whose sole purpose is to leach, alter, expose, siphon sensitive data, or even to shut you down. From someone who does a lot of Linux deployments, I like to have handy a Linux template with some extra security policies configured.

Securing your environment starts during the ordering process when you are deploying server resources. Sometimes you want to deploy a quick server without putting it behind an extra hardware firewall layer or deploying it with an APF (Advance Policy Firewall). Here are a couple of security hardening tips I have set on my Linux template to have a solid base level of security when I deploy a Linux system.

Note: The following instructions assume that you are using CentOS or Red Hat Enterprise Linux.

1. Change the Root Password

Log in to your server and change the root password if you didn’t use a SSH key to gain access to your Linux system.

• passwd – Make sure it’s strong.
• Don’t intend on using root.

2. Create a New User

The root user is the only user created on a new Linux install. You should add a new user for your own access and use of the server.

• useradd
• passwd (Make sure this is a strong password that’s different from your root password.)

3. Change the Password Age Requirements

Change the password age so you’ll be forced to change your password in a given period of time:

• chage –M 60 –m 7 –w 7
  • M: Minimum of days required between password changes
  • m: Maximum days the passworwed is valid
  • w: The number of days before password will warn of expiration

4. Disable Root Login

When you need super-user permissions, usesudo instead of su. Sudo is more secure than using su: When a user uses sudo to execute root-level commands, all commands are tracked by default in /var/log/secure. Furthermore, users will have to authenticate themselves to run sudo commands for a short period of time.

5. Use Secure Shell (SSH)

rlogin and telnet protocols don’t use an encrypted format, just plain text. I recommend using SSH protocol for remote log in and file transfers. SSH allows you to use encryption technology while communicating with your sever. SSH is still open to many different types of attacks, though. I suggest using the following to lock SSH down a little bit more:

Remove the ability to SSH as root:

• vi /etc/ssh/sshd_config.
• Find #PermitRootLogin yes and change to PermitRootLogin no.
• Run service sshd restart.

Change the default SSH 22 port. You can even utilize RSA keys instead of passwords for extra protection.

6. Update Kernel and Software

Ensure your kernel and software patches are up to date. I like to make sure my Linux kernel and software are always up to date because patches are constantly being released with corrected security flaws and exploits. Remember you have access to SoftLayer’s private network for updates and patches, so you don’t have to expose your server to the public network to get updates. Run this with sudo to get updates in RedHat or CentOS: yum update.

7. Strip Your System

Clean your system of unwanted packages. I strip my system to avoid installing unnecessary software to avoid vulnerabilities. This is called “reducing the attack surface.” Packages like NFS, Samba, even the X Windows desktops (i.e., Gnome or KDE) contain vulnerabilities. Here’s how reduce the attack surface:

• List what is installed: yum list installed
• List the package name: yum list
• Remove the package: yum remove

8. Use Security Extensions

Use a security extension such as SELinux on RHEL or CentOS when you’re able. SELinux provides a flexible Mandatory Access Control (MAC); running a MAC kernel protects the system from malicious or flawed applications that can damage or destroy the system. You’ll have to explore the official Red Hat documentation, which explains SELinux configuration. To check if SELinux is running, runsestatus.

9. Add a Welcome/Warning

Add a welcome or warning display for when users remote into your system. The message can be created using MOTD (message of the day). MOTD’s sole purpose is to display messages on console or SSH session logins. I like for my MOTDs to read “Welcome to . All connections are being monitored and recorded.”

I recommend vi /etc/motd

10. Monitor Your Logs

Monitor logs whenever you can. Some example logs that you can audit:

• System boot log: /var/log/boot.log
• Authentication log: /var/log/secureLog in records file: /var/log/utmp or /var/log/wtmp:
• Where whole system logs or current activity are available: /var/log/message
• Authentication logs: /var/log/auth.log
• Kernel logs: /var/log/kern.log
• Crond logs (cron job): /var/log/cron.log
• Mail server logs: /var/log/maillog

You can even move these logs to a bare metal server to prevent intruders from easily modifying them.

This is just the tip of the iceberg when securing your Linux server. While not the most secure system, it gives you breathing room if you have to deploy quick servers for short duration tests, and so on. You can build more security into your server later for longer, more permanent-type servers.