Security is a popular topic among Linux system administrators. Every forum I read, every conference 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 my inability to keep from eavesdropping on tech conversations about Linux is the origin of this article. These are my five recommendations for starting with a more secure Linux installation right out of the box.
[Want to try out Red Hat Enterprise Linux? Download it now for free.]
Keep it minimal
When I install Linux, I always install the smallest version possible. For CentOS or 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 argue 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. Finally, your system's performance might (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. Hang a sign just above your monitor(s) in your cubicle that reads, "CHECK THE FIREWALL," and you'll be fine.
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. And if you have an intrusion prevention script or service installed, repeated attempts automatically result in a new DROP rule or the creation of an /etc/hosts.deny
entry.
Check to see if remote root logins are enabled:
$ sudo grep -i root /etc/ssh/sshd_config
PermitRootLogin yes
# the setting of "PermitRootLogin without-password".
#ChrootDirectory none
If you see PermitRootLogin yes
, then the root user can log in remotely via SSH. Edit the /etc/ssh/sshd_config
file and place a #
to comment out the line, or change yes
to no
. Restart the sshd
service to accept the new configuration:
$ sudo systemctl restart sshd.service
The root user will no longer be able to log in via SSH.
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.
About the author
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.
Follow him on Twitter: @kenhess for a continuous feed of Sysadmin topics, film, and random rants.
In the evening after Ken replaces his red hat with his foil hat, he writes and makes films with varying degrees of success and acceptance. He is an award-winning filmmaker who constantly tries to convince everyone of his Renaissance Man status, also with varying degrees of success and acceptance.
More like this
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit