Security: 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Â
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.
passwd <username>Â (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 <username>
- M: Minimum of days required between password changes
- m: Maximum days the password is valid
- w: The number of days before password will warn of expiration
4. Disable Root Login
As Lee suggested in the last blog, you shouldÂ Stop Using Root!
- When you need super-user permissions, useÂ
sudoÂ instead ofÂ
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)
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Â
#PermitRootLogin yesÂ and change toÂ
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:Â
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 <package-name>
- Remove the package:Â
yum remove <package-name>
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, run
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 <hostname>. All connections are being monitored and recorded.â€ť
- I recommendÂ
10. Monitor Your Logs
Monitor logs whenever you can. Some example logs that you can audit:
- System boot log:Â
- Authentication log:Â
- Log in records file:Â
/var/log/utmp or /var/log/wtmp:
- Where whole system logs or current activity are available:Â
- Authentication logs:Â
- Kernel logs:Â
- Crond logs (cron job):Â
- Mail server logs:Â
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.
– Darrel Haswell