Introduction
That’s a nice new Linux server you’ve got there… it’d be a shame if something happened to it. It might work out of the box, but before you put it into production, there are 10 steps you should take to make sure your configuration is secure. The details of these steps may vary from distribution to distribution, but the concept applies to any Linux distribution. By going through these steps on new servers, you can ensure that they have at least basic protection against the most common cyberattacks.
1 – User configuration
The first thing you'll want to do, if it's not already part of your operating system settings, is change the root password. This should be obvious, but can be surprisingly overlooked during a typical server setup. The password should be at least 8 characters long and use a mix of uppercase and lowercase letters, numbers, and symbols. Also, if you're going to use local accounts, you should set up a password policy that specifies age, lockout, history, and complexity requirements. In most cases, you should disable the root user entirely and create non-root accounts with sudo access for those who need elevated privileges.
2 – Network configuration
One of the most basic configurations you need to do is enable network connectivity by assigning an IP address and hostname to the server. For most servers, you will want to use a static IP so that clients can always find the resource at the same address. If your network uses VLANs, consider how isolated the server section is and where it would be best to place it. If you are not using IPv6, turn it off. Set up the hostname, domain, and DNS server information. Two or more DNS servers should be used for redundancy, and you should test nslookup to make sure name resolution is working properly.
3 – Package Management
You are probably setting up your new server for a specific purpose, so install any packages you might need if they are not part of the distribution you are using. These could be utility packages like PHP, MongoDB, ngnix, or support packages like pear. Likewise, any extra packages installed on your system should be removed to minimize the server footprint. All of this should be done through your distribution's package management solution, such as Yum or apt, for easier management down the road.
4 – Update installation and configuration
Once you have the right packages installed on your server, you need to make sure that everything is up to date. Not just the packages you have installed, but also the kernel and default packages. Unless you need a specific version, you should always use the latest production version to keep your system secure. Usually, your package management solution will provide the latest supported version. You should also set up automatic updates in your package management tool if doing so works for the service(s) you host on this server.
5 – NTP configuration
Configure your server to synchronize its time with NTP servers. This can be done if your environment has internal NTP servers, or external time servers that are accessible to anyone. What is important is to prevent clock drift, where the server clock deviates from the real time. This can cause a lot of problems, including authentication problems where the time deviation between the server and the authentication infrastructure is measured before granting access. This should be a simple trick, but a reliable infrastructure is critical.
6 – Firewall and iptables
Depending on your distribution, the tables may be completely locked down and ask you to open what you need, but regardless of the default configuration, you should always take a look and make sure it is set up the way you want. Remember to always use the principle of least privilege and only open the ports you need for the services on that server. If your server is behind a dedicated firewall, make sure to deny everything except what is needed there. Assuming your iptables/firewall is restrictive by default, don't forget to open what you need to make your server work!
7 – Securing SSH
SSH is the primary method of remote access for Linux distributions and as such needs to be properly secured. You should disable root's ability to SSH remotely, even if you have disabled the account, so that if root is enabled on the server for some reason, it can still not be exploited remotely. You can also restrict SSH to specific IP ranges if you have a fixed set of client IPs that are connecting. Optionally, you can change the default SSH port to make it obfuscated, but honestly, a simple scan will reveal the new open port to anyone who wants to find it. Finally, you can disable password authentication altogether and use certificate-based authentication to further reduce the chances of SSH being exploited.
8 – Daemon configuration
You've cleaned up your packages, but it's also important to set the right programs to start automatically on reboot. Make sure to shut down any daemons you don't need. One of the keys to a secure server is to reduce the active footprint as much as possible, so the only surface areas available for attack are those required by the application(s). Once this is done, the remaining services should be hardened as much as possible to ensure resiliency.
9 – SELinux and further hardening
If you've ever used a Red Hat distribution, you may be familiar with SELinux, a kernel hardening tool that protects the system from various operations. SELinux is great at protecting against unauthorized use and access to system resources. It's also great at breaking applications, so make sure you test your configuration with SELinux enabled and use the logs to make sure nothing legitimate is being blocked. Beyond that, you should research hardening applications like MySQL or Apache, as each has its own set of best practices to follow.
10 – Login
Finally, you need to make sure that the logging level you need is enabled and that you have enough resources for it. You will eventually get to troubleshooting this server, so do yourself a favor now and create the logging structure you need to quickly resolve issues. Most software has configurable logs, but you will need to do some trial and error to find the right balance between not enough and not enough information. There are a number of third-party logging tools that can help with everything from aggregation to visualization, but each environment should be considered for its needs first. Then you can find the tool(s) that will help you fill them.
Result
Each of these steps can take some time to complete, especially the first time. But by creating an initial server configuration routine, you can ensure that new machines in your environment are resilient. Failure to complete any of these steps can have very serious consequences if your server ever becomes the target of an attack. Following them doesn’t guarantee security – data breaches happen – but it does make it much more difficult for malicious actors to overcome, and it requires a degree of skill to overcome.
