As a CTO, manager, or technical lead, what questions should you be asking when it comes to securing a Linux server?  Are Linux servers really as secure as everyone says?  What should be the focus of your team when securing servers for your company?  In this CTO Brief, we are going to try and answer some of these questions and possibly a little more.

Are Linux machines really more secure than other servers?

The answer to that question is that it depends.  No computer can ever be made to be completely secure.  Sometimes no matter how secure you make a computer, an inexperienced employee may hand over more information without even realizing what they are doing.  But that will be a discussion for another Brief, and we will now get back to the topic at hand.  Out of the box Windows machines used to be far more insecure than they are today. No matter what, there has always been a need for them to be secured. What has been an issue is that you had be a Windows guru to get it done and still have a stable machine.  Microsoft has worked hard to change this, but Linux started out with a sizable lead.  One of the things that Linux inherited from other forms of Unix was its powerful and mature security model.  If you ignore the basics of security, like weak passwords and opening up insecure services, a Linux machine can easily become a very insecure machine.  It is easy to avoid most of the pitfalls if your team takes their time and thinks through the issues you have to solve.

What questions should you be asking when it comes to securing a linux server?

What is each of your Linux servers going to be used for should be your first question.  Until you know and define what a particular machine is going to do, you cannot determine what needs to be running and which risks are justifiable.  There are no hard fast rules as to which services should go together with other services.  Each environment and situation will have its own unique challenges.  For the rest of the examples here, we will focus on a Web Server on the Internet that also serves as a back up DNS server.  The only service ports on this mythical machine that should be visible to the internet would be Port 80 and 443 for the web, 53 for the DNS service, and 22 so that you can login and manage the server.  All other services or daemons that expose or listen on an ip address available to people not on the machine, should be shut off or configured to listen to the internal ip address of 127.0.0.1(the servers local loopback address or internal address).

What if my team uses a Web Based administrative tool, or any other type of remote administration tool, and we cannot live without it.  What should we do?

If your team is using a web based solution to manage servers more effectively, the web server that service is running on should never be visible from the outside world.  How can that still be used then?  With SSH enabled it is easy to map a local port on the admin’s workstation to a remote port where the Web Based Administration software is running.  Once that mapping is established, the admin just points a web browser to the port on their workstation and all requests are forwarded over a secured ssh connection.  For this to be effective though, the management software must only listen to localhost(127.0.0.1) which is the machine internal address.

How do we audit what we did so far and make sure it doesn’t change?

Depending on the level of security you need, there are a wide range of both closed and open source solutions.  Before spending any money on a closed source tool, I strongly recommend investigating the open source tools available.  We have found tools like Puppet and Nessus, both open source, to be some of the best in the industry both paid and unpaid.  Both projects offer contract support and enterprise feature sets.  Puppet gives you the ability to check and update a systems local configuration.  Nessus on the other hand makes sure that only the services, ports and applications you want are accessible from outside of the machine.  This two factor approach along with service monitoring from a tool like GWOS or Zenoss and a rigorous software update process and schedule will give you a terrific base to start off from.

So what about anti-virus software for Linux.  I heard you don’t need it  Is that true?

Linux or any Unix for that matter are not immune from getting viruses.  There are just considerably fewer viruses that can exploit Linux and the services that run on it.  But the thing about Linux that makes it so hard to write a virus for, is that every person using the machine cannot do damage.  On most systems, only the root user can do the most damaging commands.  If the machine is serving as a file server, for say windows machines on the network, Linux can still pass an infected file around your network if you aren’t using anti-virus software.  ClamAV is the most widely known Anti-Virus tool for Linux.  The tool is opensource and lets you protect both Linux and Windows files from viruses.  Other options do exist and you should do some level of comparison and decide how your company should move forward.

So what’s next?

The next steps after this, is to keep closing any holes identified by Nessus.  Then start moving down through the OS and locking down the file and directory permissions.  If you still need more security, start using tools like app armor which place a shield around your exposed applications to protect the operating system.  From here, the goal of what you are attempting to do will lead you to the next set of tools.

The items we mentioned here are meant to be a base for you to build on.  By completing these steps, your machines will be more secure than than a default Linux machine.  What you need to do from here is up to your security officers, customers, and other businesses your company interacts with.