Supportable Linux Security

Computer security is once again becoming a hot topic for administrators.  There are dozens of new sites springing up around the web, and each is slinging their own ‘Perfect’ setup instructions.  They have the usual bell curve of good advice, okay advice, and advice that will effectively leave you with a smoldering pile of rubble where your data used to be. What disturbs me is the growing number of seemingly reputable Linux security websites pitching brittle security advice. I call it ‘brittle’ advice, because while your system is hardened over its previous state, it is also no longer supportable by your distribution.  There are several causes for this, but I’ll outline the top three reasons for this breach in support.

Bad Advice:
  Really, who didn’t see this coming as the #1 here? Ignoring the occasional typos, misprints and ramblings, there are quite a few security sites which just plain offer bad advice. Much of the advice has to do with offering incorrect permissions changes, which may inadvertently expose data, or cause system breakage.  Lets look at web hosting as a decent example:

There are loads of content management systems out there that detail the explicit permissions for their software: 777. I assume they do this mostly out of laziness due to the number of different hosting providers out there and assumptions of ownership might be sketchy. Still, 777 is pretty irresponsible in a world where SQL injection and website exploits are the norm.

Ignoring Distro Tools
  As we descend into flawed-security-advice hell, the next level we come to involves side-lining the distribution provided security tool-kits. This is commonly done through ignorance of their existence or operation, or just basic willful neglect.  Regardless of how it happens, the end result remains the same. If you bring your own toys to party, you’re responsible for them. Again looking to CentOS for the example, we find that a large number of websites will completely ignore the security tools default in the distribution. They ignore selinux, aide, audit, and pam restrictions, while touting things like grsec, and ossec.  I don’t want to turn this into a grsec vs selinux holy war ala vim-vs-emacs. Grsec is a good security tool, however it’s not what RHEL and CentOS have chosen to throw their weight behind. The further you stray from the tools which ship with the distro, the less the distro support mechanisms will be able to help you.

Providing Details
Perhaps the biggest issue I have with supposed security advice is the lack of detail as to what some of the options mean or do. For a rather glaring example,  we can use’s page on tuning sysctl.conf. They provide instructions to wget the sysctl.conf file they supply, however they don’t go into detail as to what they set, or what benefits the options provide. Teaching is (or should be) at the core of security. An admin should understand the changes they’re making to a system rather than blindly pecking at keys because someone told them to. To make matters worse, the provided sysctl.conf file doesn’t contain comments explaining the various options there either. A budding admin is going to have no idea what a martian is in terms of linux networking, or why it may be important to have rp_filter enabled. These sorts of things need to be documented to take the voodoo out of security for new admins looking to do the right thing.

Do the Right Thing

With the plethora of poor security advice showing up, and often interspersed with good advice how are admins supposed to know what to listen to?  There are a few guidelines to work with so that you keep your system secure, and still get support from your distribution channels. If you stick with these steps, you should be in good shape for having a supportable, secure system.
  1. Identify the areas to secure based on exposure.  (web server, file server, DNS, etc)
  2. Document the changes that you make. For support or duplication later on, it’s important to keep a record of changes you make to the default configurations.
  3. Ask your distribution what security tools are included.
  4. Use package management tools appropriate for your distro.
  5. Look to 3rd party repositories after examining what the distribution provides and/or recommends.  3rd party vendors may well be an excellent source of security tools, but look at what the distro offers first.
  6. Keep major modifications to core components to a minimum. Many distributions support only the software that they ship. If you replace core components like the kernel(for grsec) or go replacing distribution packages with external software, you may have to get your support from the external source. The more you deviate, the more places you’ll have to shop for support.
  7. Most importantly, understand the changes you make to the system. If you’re unsure about a particular security setting (I’m thinking of sysctl.conf here) or you don’t fully understand the option means, ask.  The worst thing you as an admin can do is modify a system without understanding the benefit or penalty for a particular change


Post a Comment

Copyright © Bit Integrity