Tips to secure your linux server

These are mainly ideal for redhat based distros i.e: fedora, rhel, centos, etc. And they will help anyone from the novice user up to the seasoned pro implement some good security practices and configurations.

These alone will not secure your server for you, there is basic admin practices you must follow in order to stay secure such as using good passwords, changing them every so often, and not using the same pass for everything. Usually people don’t learn this lesson until its too late.

Assuming you have a fresh system or are willing to make a lot of changes to an existing system here goes. This all will work best and provide the best results on a cpanel server.

First you want to start off with your server software. Make sure everything is up to date by updating with your package manager. I do not advise using the yum packages for php or mysql because they tend to be outdated and lacking new features. So you will need to build your own php and install mysql manually. If you are using directadmin or cpanel then you will already have a build system in place for doing this.

Php/HTTP Server

After your base software is updated and its time to compile php You can follow this guide HERE which is mainly for litespeed but you can skip the lsapi parts and compile for others. This tutorial includes patching php with suhosin as well as compiling and installing the suhosin extension. You can also use the cpanel or directadmin apache/php build system but you will not be able to apply the base suhosin patch with it unless you go manually into the php source and patch it before it builds.

Always use the latest stable version of php at all costs. Do not compromise security because you or your users have a crappy script that is not yet php5 compliant. There is no excuse for this at this time. Php4 is end of life and if the developer of the script you are using still hasn’t learned php5 then it is time to move on to a better script. There is not many different coding practices that are different, from what Ive read there is very little to do to make a script php5 compliant.

Also if possible compile and install your php so it runs as suexec. this way you will be able to track resource usage as well as have more secure permissions on files. There is a drawback to this on the user level though. If a user is compromised by a php shell or something they can have their entire site deleted just like a user logging in ssh or ftp. But the compromise can be contained to the user only so it is much better for the server as a whole. This can happen too with php running as nobody but running as nobody it can only access, write, or alter files that have the proper chmod for world privileges. If you are running a server for just one site then running php as nobody would be the better option.

When you have your php compiled and ready a few good configurations to use are

allow_url_include=off , allow_dl=off , and disable_functions=system,passthru,show_source.

There are plenty other configurations you can use or functions/classes to disable, it depends on what your scripts need or don’t need. As far as your suhosin configuration this is really something you will have to experiment with as it can interfere with scripts such as vbulletin. So you will have to raise some limits for example on vbulletin:

suhosin.post.max_vars = 2048
suhosin.request.max_vars = 2048

As far as your http server it is entirely up to you just try to go with the latest stable version of whatever you choose to use. I will always recommend litespeed but some people just don’t like it. One of the major advantages of litespeed is the lsapi php can be run as suexec without changing all your permissions, it will not error on permissions like apache php suexec does. Also you can always switch back and forth from suexec to nobody.

Mod_security - can be used with litespeed or apache. There are tutorials everywhere for installing mod_security, the best one is probably at eth0.us/mod_security. Just follow his tutorial and include a ruleset. Here are 2 light rulesets I have been using the past year or so, they cover most common exploits but by any means does not block everything. These rulesets were made to be light and not interfere with web apps. So this is another thing you can experiment with - using more extensive and custom rulesets.

Kernel

In an ideal setup you would be able to use a grsecurity patched kernel with any system type or hardware but after 2 years of using and experimenting with grsecurity I know this is not the case. Some systems you can install on and not have a problem, others you will get oops and panics on a daily basis. I have found out though it may be related to the pre-set security levels.

So this is something you may have to experiment with different versions to find the one that works with the least problems. I can say though that I have only had major problems out of servers with over 2 cores. Anyway follow this tutorial here, replace the version numbers with either the version of the latest test patch you wish to install or the latest stable.

When you configure it make sure you have selected all modules you need for your hardware and netfilter/iptables. When you get to security settings you can either do as you like or feel whats best. Now a lot of people will tell you different things, what I am advising is a light setup that will work with most systems and not cause problems on shared hosting or shell servers. If you wanted you could lock it down as much as possible but you will be doing some trial and error for sure.

I will advise to do this:

First in security level select custom then in Address Space Protection select [*] Deter exploit bruteforcing and leave the other ones unchecked. In Role Based Access Control Options make sure these are the only two checked with values- (3) Maximum tries before password lockout and (30) Time to wait after max password tries, in seconds.

In filesystem protections select [*] Proc restrictions and [*] Allow special group (1001) GID for special group . Leave the rest unchecked unless you plan on setting up a chroot environment you can add some restrictions to it. You shouldn’t have to mess with the settings for Kernel Auditing.
In Executable Protections select [*] Enforce RLIMIT_NPROC on execs and [*] Dmesg(8) restriction. In Network Protections check [*] Larger entropy pools. In Sysctl support check it and turn features on by default. The logging options is entirely up to you. As far as pax options I have had more problems with them then anything so Id advise against them unless you know what you are doing.

This basic configuration is just for people who want to patch up the kernel some and boot it and go. If you really have the time to learn all this there is much more you can do. But if you are a novice or are using this for a shared hosting server this is a viable setup.

Bastille

Bastille is a pretty handy hardening tool but if used incorrectly may cause problems. You just have to be careful what you select. To install bastille simply follow this tutorial on howtoforge. Don’t disable anything you will need and make extra sure you don’t password protect grub or single user mode if you are working on a remote server. If you have shell users you probably wont want to disable ping and other tools. Also make sure not to use the netfilter script, we will be setting that up next.

CSF

Probably the best security script/firewall ever made. I have used CSF since it has came out and it has been nothing but extremely useful. It has tons of useful features such as alerting on ssh login, alerts when users are sending mail - it can even disable the scripts sending the mail, it alerts you on high server load, it has connection tracking features to help resist ddos and socket flooding , has brute force protection, and more. These are all user configurable options so you really have to make sure everything is enabled and configured to your needs.

You can read about csf and download it HERE. Its simple to install first make sure you have the perl-libwww library, if not simply “yum -y install perl-libwww” then untar csf and run the install.sh.

This script and firewall is best and most useful for cpanel servers. It has a feature to check server security and offer suggestions on optimal configurations - even tells you how to do it. So if you are on cpanel as soon as you get the firewall up and running login WHM and do the check server security and display all comments.

From there it will basically tell you what to do even how to disable some unnecessary services you may have running. After you do this and have csf setup and running make sure all of the options you will need are selected. On the connection tracking for a basic shared server without regular ddos problems I would suggest setting ct_limit to 200 and leave permanent ban off. Also select skip_time_wait. This way not many legit users will get banned if any at all. If you do have a server with regular ddos problems you can tune these settings to your needs, just something you have to experiment with.

Mount Permissions

If you do not have cpanel/whm and are not able to run the csf check server security option then you can check and mount your filesystems accordingly with the most secure permissions. Here is a sensible /etc/fstab file. Keep in mind if you use pear, pecl, or anything else that must exec in /tmp you need to not use the noexec option.

I use noatime on my mount points as with this option, reading accesses to the file system will no longer result in an update to the atime information associated with the file like we have explained above. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive, this can result in measurable performance gains.

So if you like you can try noatime on all of your mount points to see if you can benefit. On your /tmp partitions i.e: /var/tmp, /dev/shm; simply add noexec,nosuid. On your proc partition you may also use nosuid flag on it, this can prevent some local root exploits but may cause some issues with some systems.

Unnecessary Services

For some reason almost all systems enable totally unneeded services default from printing services to laptop services none of these are needed in a typical webserver. If you are on cpanel/whm you should have already had most of these taken care of while running the check security option. Also you would have been able to disable some unnecessary services with bastille as well. This is mainly just some common services that are enabled default, you will get command not found on some of them and there are probably some not listed here. So you have to check your processes and investigate anything in question by simply googling it.

service cups stop ; chkconfig cups off

service atd stop ; chkconfig atd off

service rpcidmapd stop ; chkconfig rpcidmapd off

service bluetooth stop ; chkconfig bluetooth off

service anacron stop ; chkconfig anacron off

service gpm stop ; chkconfig gpm off

service acpid stop ; chkconfig acpid off

Also what you can do is ps aux, check out all the processes. Anything you are not sure about ls /etc/init.d and look for the one which belongs to the process. Google it and see what it is and if you can do without it. Just do the same as the ones listed above.

Conclusion

And there you have it. This is not a sure fire way to prevent from being compromised but it can help. Staying proactive, up to date, and secure admin practices is the most important part. Also backups are very important as well, never get caught with your pants down and without a backup. There is no hackproof server but if you stay at the top of your game you can sure make it harder for them.