Tips on Linux Security
Security is a popular discussion topic with Linux system administrators. Every discussion I read online, every meeting I attend, and every IT-centric discussion I’m part of always turns to security, and then the conversations turn, inevitably, to Linux security. This is my experience and these are my five recommendations for starting with a more secure Linux installation right out of the box.
Minimal Installations
When I install Linux, I always install the most minimal version possible. For Red Hat Enterprise Linux, this means a minimal installation. I prefer to start small and then add what I need rather than to remove what I don’t need. The added benefit to selecting a minimal install is that the system’s footprint is also minimal. Disk space is cheap, but who wants to waste disk space on superfluous applications that might come back to haunt us later with security issues? All I need initially is a base install with an SSH server so that I can connect to it and manage it remotely. I can add whatever I need through DNF later.
Servers are GUI-free zones
If your Linux system will live life as a server, don’t install a graphical user interface. Several people are against this point. From a security standpoint, installing a GUI—even a small one—requires a lot of extra software packages. Any of these could be susceptible to security problems. Some GUI packages can open ports on your system, which is undesirable because that action increases the attack surface. Ultimately, GUI means using graphics which means your system’s performance will suffer from having a graphical interface, because GUIs consume a lot of system resources.
Leave the GUIs to the desktop. Learn the command line.
Firewalls are mandatory
On Red Hat-based systems (Red Hat Enterprise Linux, Fedora, and CentOS), firewalld is your default firewall. Use it. This host-based firewall protects your system from unwanted intrusions through all port, except for those you have explicitly allowed. You can also selectively limit outgoing traffic through the firewall.
However, the most secure method for limiting outgoing traffic is to have an internal internet proxy server set up, and only allow outgoing traffic to that system. You can also allow SSH traffic to your local subnet in case you need to connect from one system to another. Host-based firewalls can be frustrating when testing connectivity between systems, especially for newly configured services, but it’s well worth the few moments of frustration.
SELinux is worth learning
Ah, the much-loathed and misunderstood SELinux. Typically, system administrators disable or remove SELinux altogether rather than dealing with the extreme security-enhanced angst that it produces. My advice is to leave this service on, enabled, and set to enforcing.
SELinux uses what’s known as mandatory access control (or MAC), whereas firewalls use rules-based access control, and the standard *nix permissions are known as discretionary access control. Before giving up and disabling SELinux, please read some documentation on its configuration. Since most systems only run a small set of services, configuring is not that big of a hassle as opposed to the danger of not having this service enabled.
SELinux has to be set up in a particular way, allowing files to be labeled, set up in security contexts, and rebooted a couple of times to get things going. Read the documentation. SELinux, contrary to popular belief, is NOT a firewall (or a replacement for one), an anti-malware solution, a replacement for authentication mechanisms such as multi-factor authentication, or a security panacea by any stretch of the imagination.
SELinux is a defense against privilege escalation from services that run as the root user. Turning it off is probably is a bad idea. Using SELinux correctly is an added layer of protection needed in these days of advanced persistent threats and smarter malware.
Remote root logins are a bad idea
By default, on Red Hat-based systems, the root user may log in remotely via SSH. I can understand why this feature is set by default on newly installed systems, but it should be disabled once the system is up and operable, and accounts with sudo access have been created.
Disabling remote root login prevents an attacker from using brute force methods to guess your root password. Attempts are logged but will have no effect on your security because the root account cannot log in remotely.
Wrapping up
Read any survey for the past ten years and you’ll see that security is the top priority or concern for system administrators. Make it your priority to secure a system with at least these five tips before your systems go live into production. Security is not something you can put off or relax on. These five tips will help you bring a more secure system online and make your network a safer place to work.
More Knowledge
Looking to learn Linux? Start with RHCSA and RHCE
Want to get into Cloud? Why not AWS?
Find Devops Interesting? Learn Devops
Recent Comments