Balancing Linux security with usability

The internet is full of people who want to destroy your stuff. Some of them are just curious, some are seeking a thrill, others are trying to steal your data, and some just want to watch things burn. Whatever their motive, it's your job as a sysadmin to keep these attackers out of your servers. If you're running a Linux system, this article is for you. We're going to run through some of the reasons why you need to harden your systems and other high-level considerations.

Operating systems are a balance

Building an operating system is a difficult balance, and a Linux distribution is no different. You need to consider the out-of-the-box functionality that most people are going to want, and accessibility for a wide swath of administrators' skillsets. If you make your distro very secure, but a newbie sysadmin can't figure out how to work with it…well, they're going to find an easier distribution to go learn on, and now you've lost that admin to another distribution. So it's really no surprise that, right after install time, most Linux distributions need a little bit of tweaking to lock them down. This has gotten better over the years, as the installers themselves have gotten easier to use and more feature-rich. You can craft a pretty custom system right from the GUI installer. A base Red Hat Enterprise Linux (RHEL) system, for example, if you've chosen the base package set, is actually pretty light on unnecessary services and packages.

There was a time when that was not true. Can you imagine passwords being hashed, but available in /etc/password for any user to read? Or all system management being carried out over Telnet? SSH wasn't even on, by default. Host-based firewall? Completely optional. So, 20 years ago, locking down a newly installed Linux system meant a laundry list of tasks. Luckily, as computing has matured, so has the default install of just about any operating system.

What is system "hardening?"

Hardening a system is the act of making the system more secure—a more difficult target for the bad guys. Imagine you had a white picket fence protecting your home. It's probably enough to keep the honest people honest—they see the fence and the nice little latch on your gate and decide to respect the fact that you obviously don't want people in your yard. You feel safe knowing that no one is going to come into your yard and trample your flowers because people respect that boundary of your property. All it takes, though, is one kid who doesn't care about any of that to cut through your yard because they can't be bothered to go around. Your white picket fence and flimsy latch are nothing for them to flip open and run right through.

Hardening would be like upgrading the white picket fence to a six-foot-tall chainlink one and adding a latch with a lock on it. Someone determined enough could still climb over the fence, but that kid who was cutting through your yard probably isn't going to bother anymore, because it's a little too much work.

See, computer security isn't about being completely unbreakable, unless you're Oracle; it's about being just secure enough to be difficult to break in, while still open enough that your system can actually do what it's designed to do. A web server so locked down that you can't run a website on it isn't a very good web server—like a chainlink fence with no gate.

Hardening tips

Below is not a step-by-step how-to, but rather, some general points to consider as you work to harden your system.

Ditch the GUI

Are you running a workstation? Or a server? Servers don't need GUIs. It's just one more thing eating up space and CPU. When I install a system, I install it with the absolute smallest footprint the installer allows. That means no GUI. You just don't need it. There are some applications that need an X environment to install and manage (which is just silly in today's era, but it does happen). If you're not running one of those, however, don't bother installing a GUI or worrying about any of their requirements.

Unnecessary services

Depending on your distro, you may have some services installed as part of the base that are just not needed, like in those Telnet days I referenced earlier—when distros were still transitioning from Telnet to SSH for management, you'd get both enabled from a base install. You got to choose which one you wanted to keep, so you'd likely want to disable Telnet or at least firewall it off. Today, those services might be something more like the CUPS printing service or maybe the system's Mail Transfer Agent (MTA). They could be configured out of the box to listen for incoming connections. While you likely do need an MTA, you don't need it to accept external connections. On a systemd system, you can list all active services pretty easily. You can also review the output of netstat or ss to see what services are listening for connections. If you don't know what a service is, now's a great time to do some reading.

User access

Unless you're running a shell server, where people actually do need access, you'll probably want to think hard about who you give a shell account on your systems. This isn't necessarily a hardening practice as much as just good administration. The more accounts there are, the larger the footprint of accounts that can be compromised is. It's also a great idea to be VERY careful how you hand out sudo privileges. No one should ever have root's password, aside from maybe the systems administration team (and even they shouldn't be using it unless absolutely necessary). Sudo is there for a reason; use it.

Host-based firewalls

I talked about this quite a bit in my series on defense in depth. The host-based firewall is the final line of network defense; use it. Out of the box, your distro may have a wide-open firewall, or maybe it has some default ports open. How are the firewall rules terminated? Is this a default open or default closed system? I never saw a reason, aside from maybe troubleshooting, to have a default open firewall. I could see how a base install might have the firewall configured that way, though, so it's good to know or find out. All the crafty firewall rules in the world don't do a bit of good if your firewall defaults to open. Software should be open; firewalls should be closed.

Secure protocols

There was a time when you only encrypted traffic that had a reasonable chance of exchanging private data, like passwords. This was because encryption came at a cost. Crunching numbers is what computers are good at, but encrypting every bit of communication added latency. Not much, but it adds up. Well, that's not really the problem that it used to be. We're at a point now where there's really no reason not to encrypt the traffic coming to and from your system. You can TLS encrypt with LetsEncrypt for free, and management over SSH is not even a question anymore. I'm sure there are edge cases here, but I'm betting that, the majority of the time, the answer to "Should this be encrypted?" is likely "yes."

Remember the balance

Remember that security is a balance between accessibility, usability, and restriction. Too far in any of those directions, and you're in for trouble.

[ Free download: Advanced Linux commands cheat sheet. ]