Skip to main content

Linux Security – Server Hardening

Posted on February 9, 2013 by TerryCoxTerryCox

One of the most common areas in Linux that gets overlooked during a production deployment is overall security. Specifically, the hardening of the operating system against common exploits (and hardening can encompass both policy and configuration for both internal and external use). We are going to talk about some common ways to protect our server from both the inexperienced as well as the malicious users it will be exposed to.

Protect Yourself From Prying Eyes

First and foremost, avoid using all services that allow unencrypted or unobfuscated traffic whenever possible (with HTTP being the notable exception for obvious reasons). This means not installing or configuring (and for goodness sake, not opening the associated ports on the local or enterprise firewall) for the following:

  • telnet
  • ftp
  • rlogin
  • rsh/rcp
  • vnc
  • tftp

There are perfectly acceptable and much more secure substitutes for each of these options: ssh, sftp, scp, etc. I included vnc in our list because setting it up by itself is just hanging a sign on your server that says, “please break in.” Run vnc over ssh for a secure method of managing your system remotely. Better yet, run it over ssh and connect via VPN to your network so even that is not exposed outside your firewall(s).

Put Your System on a Diet

Just because your repository or installation media comes with 4,123,432 packages does NOT mean you have to install them all. In addition, there are many services that get installed and started that you do not need in a server environment (bluetooth anyone?). The more packages you have, the more services you have running, the more likely something can be exploited.
There was a time when it was necessary (financially) to run multiple network services on a single system (maximizing infrastructure investment). However, with the vast improvements in virtualization, you can now segregate your services better to limit potential compromises per system (i.e. web services can be separated from caching, proxies or databases).

Security by Abstraction

One of the strongest methods of protecting your systems is through abstraction. This consists of maintaining an intelligent firewall zoning configuration (web servers are in an “untrusted” zone that can only communicate one zone down to the application services in a “trusted” zone and finally they communicate directly to the “data” zone where your databases are – each one is restricted to the one directly above and/or below). This type of configuration makes it less likely that a compromised system can be used to attack resources in other zones since another firewall interface would have to be defeated.

Account Security

Although this should be an obvious place to harden your server, it is an unpopular one. It is sometimes hard to strike a balance between being secure and making access so difficult no one wants to use the system. Your password policy in general should be strong enough that it is barrier to general access, as inconvenient as that may sometimes be.
Enforce a password policy that absolutely requires a password of at least eight characters, one capital letter, one number and one special character. Encourage passwords that are even longer and more complex by setting those passwords to expire less often. You can set the policy in the following location with the following fields:

  • /etc/shadow
    • Format: [username]:[password]:[lastpasswdchanged]:[minimum days]:[maximum days]:[warn]:[inactive]:[expire]
  • Note: you can use the chage command rather than editing the shadow file directly

I also highly recommend that you disable root login completely. All activities that need elevated privileges should be executed using sudo. Finally, don’t disable the password prompting during a sudo command (which can be disabled by adding NOPASSWD: ALL to that user’s entry in the /etc/sudoers file). Yes it is sometimes a pain to retype your password, but it is one final poke by the system that may save you from running something unintentionally.

What Did You Say Again?

Just when you think that you have scaled back on your packages and services, stop and listen, or rather find out what your server is listening for. Many times you will find you missed an unintended application or service that is listening on a port it does not need to. You can get a list of everything your server is listening for by port as follows:
netstat -tlupn
nmap -sT -O localhost
Both commands will let you know what your server is listening for so you can enable it in your firewall(s) or remove it from the the system.

How Did That Happen?

Make sure your system is logging appropriately. Most of the default logs will appear in /var/log and will either have an appropriately named file or subdirectory containing the pertinent logs (/var/log/http for apache for example).
The last thing you want is to be caught flat footed by the boss when he comes by–you really do not want to be in this position and not know what happened.
Use logwatch or logcheck to help you audit those logs or monitor suspicious log activity. You can configure them to send you local system mail or, with exim/sendmail/another mail service, send alerts to one or more email addresses.

Final Thoughts

This is by no means intended to be a comprehensive list of hardening procedures or tools. This is meant as a beginning, to get you thinking about what you need to do to secure your server and infrastructure. There are a number of other topics we could discuss (system accounting, intrusion detection systems, no owner or world readable files and directories, kerberos, centralized authentication, etc). If the topic is popular enough, we can go into some of those other areas or do a deeper dive in any of the categories above, including specific tutorials. Leave a comment below and let me know!


Image of Krasimir
7 years ago

This article was very intersting to me. I would be very happy if you cover the other mentioned topics – system accounting, intrusion detection systems, no owner or world readable files and directories, kerberos, centralized authentication, etc.

Image of TerryCox
7 years ago

Thanks for the feedback, part two of this article will indeed cover most of those topics.

Image of Bambalina
7 years ago

Hey, nice articles you got there. please keep going in details and deeper.

Image of creativeCMSdesigns
7 years ago

Definitely agree with Bambalina – excellent article. The related posts were also great to read through.

Image of Lazaro Vigoa
Lazaro Vigoa
7 years ago

Thank you very much!
This article is very useful.
Best Regards

Image of john j. hurley
john j. hurley
7 years ago

Let me preface with “you know a lot more than me.”
What I read however on passwords is that alone they are obsolete, no matter how made or how long. Serious crackers are using new open source apps designed to access video processors and ganged video processors with their lightning fast number crunching capabilities (even over the CPUs) to crack the best in 15 minutes or less. The only near-term hope is two factor authentication where you use the password but supplement with something like Google authenticate on your cell phone to act as the hardware token.
Thank you for the informative article!

Image of TerryCox
7 years ago

Well, I agree and disagree. Certainly for publicly available accounts (web sites for example), I believe you are right. Two factor authentication is the only way to truly protect your account and therefore your identity in general. Although, with so many sites using plain HTTP to POST the username and password, I am not sure how much good two factor authentication really does even then. As far as SSH, I would never recommend that SSH be open to the internet, ever. I would recommend that accessing systems requires VPN to a known location (Cisco, OpenVPN, etc.) and then SSH is only available then. At that point, having your security policy in place for password length and complexity serves as a deterrent to casual access but not a barrier. Ultimately, the server is there to use, but it is your job to balance that use with security.
Security is inconvenient at best for most people, but it is a very necessary evil that at the very least should be thought out. Thanks for the comments!

Image of Eddie G.
Eddie G.
7 years ago

“Please Sir…….May I have Some More?” Yes please continue this topic and go as in depth as possible, as I am attempting to get certified in REHL 6.3 and I need ALL the help I can GET! Interesting to me though is: I didn’t know that you could remove the prompting of passwords for accounts…but I’m TRULY shocked to know that it can be done with the sudoers file! I cannot imagine why this was allowed to be, I can’t think of a scenario where you’d want this kind of feature enabled and how it could be useful other than for hacking / intrusion. See?….I have SO much to learn! I ALSO just discovered that CEntOS and RHEL are SIMILAR….almost….I guess I WON’T have to buy that Study Version of RHEL!

Image of TerryCox
7 years ago

The password prompt I am talking about here is when you go to execute a command with elevated privileges. You still will have to enter your password once you first log in to the system, but if your account is in the ‘/etc/sudoers’ file (which means you can execute commands with root privileges), you would normally be prompted to enter your password again. If you add the :NOPASSWD directive as I lay out in my article, you can skip that part. I like to require that prompt as a gentle reminder that whatever you are about to do should get a second look.
I would certainly recommend you run CentOS in a virtual machine rather than spend money on RHEL. The commands are exactly the same in terms of system management, upgrades, etc. CentOS generally runs a ‘little’ ahead of RHEL, but since it is based on the RHEL core for each version release, anything you need to know for that exam you can practice in CentOS.
I plan on going into a lot more detail in the future on this topic as it has turned out to be one of our more popular articles. Thanks for the feedback.

Image of gabriel
7 years ago

well when it comes about private servers, it might be a good idea to change some of default ports. ssh to 20999 , ftp to 21000, and so on . of course , 80 , 25 , pop3 , etc. must remain by default .In this way will get over some infected machines probing default ports.
Install fail2ban and tweak some rules , aint working properly this days.Ban time 1 day at least and max 3 wrong logins.
Use only RSA/ DSA ssh private keys, no username/passwd/.
Use mod_security and mod_evasive for apache. Disable IPv6 to make it faster.
Do not allow remote SQL.
And the list will go on….

Image of TerryCox
7 years ago

Good points, many of which will be in my follow up on this topic. Stay tuned for more!


Leave a Reply

Your email address will not be published. Required fields are marked *