Home > Support > HOWTO List > Linux > Securing your server

Securing your server

Server security requires diligence, and it's not just a list of steps you do once and then forget about.  It's an ongoing process by which you monitor what's going on with your server. The below tips are meant as rough guidelines for getting your configuration to be more secure while still keeping a relative amount of convenience for you in your day-to-day server operation. Certainly there are more things you can do, but the following should be a good start.

The most secure server is one that is stored in a locked vault with no connection to the internet. Practical security is a tradeoff against usability. The tips below could help you make those choices.

Eliminate unnecessary services

One of the most important steps to take when securing your server is to make sure that only necessary services are running.  The fewer services you have running, the smaller the attack surface the server has. For tips on how to do that, take a look at Managing services

In many cases you may prefer to completely remove unused services, this will reduce the maintenance overhead of your server.

Often services are used internally only, but may be exposed to public connections, it is usually possible to disable the visibility by tweaking the service configuration. To check the current visibility of your server, or verify any changes, try the techniques described on ... Securing your server: is your port showing?.

If a service can not be hidden consider firewalling it off completely to the outside world using iptables.

Keeping Your Server Patched

As new vulnerabilities are found, each distro releases updates to existing packages which incorporate security fixes.  All of our installs include a reliable package manager for updating and maintaining packages. This makes it very simple to check for and install new updates.

In our opinion, updating is something which should be done at least weekly. If you're not going to patch on a regular basis, you should at least monitor the mailing lists where security announcements are made and then you can be informed when you are facing a vulnerability in software you are running.  Here are a few key security mailing lists:

http://www.redhat.com/mailman/listinfo
http://www.debian.org/MailingLists/subscribe
http://lists.ubuntu.com/
http://www.us-cert.gov/cas/signup.html

From time-to-time, you might find that a vulnerability exists, however no patch has been made public.  In this case, disabling affected services until a patch is available might be your best bet to remain secure.

For specific directions to help you keep your server updated, see "package managment with Debian/Ubuntu" and package management on CentOS.

Configuration management

If you have multiple servers with us you may want to consider using some kind of configuration management. This might be as simple as using a tool like "etckeeper" to keep a history of changes. More advanced tools like "puppet" or "ansible" can help you do the same thing and also let you automate service setups and package management on a continuous basis. By using these tools, you can track changes and receive alerts on things that do not match.

User/Account Security

Keeping tabs on system users can help you prevent unauthorized access, for example via an account with a weak password (or no password).  It's also important to keep in mind which users actually need shell access; you should eliminate shell access when it is not needed for a particular user. For details on how you can do that see "Managing User Accounts"

All our servers come with ssh access. By default ssh is pretty secure, however there may be a few measure you can take to improve on the defaults, especially in older installs.  Configuring ssh is described in depth at "SSH management"

Logging System Events

Keeping an eye on what's going on via system logs is a good way to stay informed whether or not your system is an active target of hacking attempts.  They are a good indicator that your system is being actively attacked.

Just be aware that once a system has been compromised, system logs may prove meaningless as they can be easily manipulated.

Syslog is the tried-and-true Unix logging facility.  It accepts log information from the kernel, local processes and can even be configured to accept messages from remote systems.  Its flexibility is one of its greatest assets and you can configure it to record only the information in which you are interested (which makes it easier to parse logs later).

When a logging message is received, syslog uses the values specified in /etc/syslog.conf in order to determine whether or not that message should be logged.  Here is an example excerpt from a syslog.conf file:

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

Logging preferences are defined via the use of facilities and priorities.

Facilities: auth, auth-priv, cron, daemon, kern, lpr, mail, mark, news, syslog, user, uucp, local{0-7}, *
Priorities: debug, info, notice, warning, err, crit, alert, emerg

When selecting a logging priority, your selection refers to that priority and any higher priority as well.  For instance, mail.warning would log all information for (mail.warning, mail.err, mail.crit, mail.alert as well as mail.emerg).

Managing Log Files

Logging all this information is useful for keeping informed of what is going on with your server, but all this information is useless if you don't keep it organized.  Limiting the amount of data you have on-hand can keep your searches for useful information as quick as possible.

Most distros come with a pre-configured logrotate scheme.  Usually the default configuration will be sufficient for your needs, but you might want to configure it to rotate more often in order to conserve disk space.

When logrotate is run, it evaluates all scripts located in /etc/logrotate.d.  When a package is installed, quite commonly the package author has included a default logrotate script which should be place in /etc/logrotate.d automatically for you.

Here is a simplified version of your typical /etc/logrotate.conf file

# Global options to rotate logs monthly while saving last 4 copies.
# Error messages will be sent to 'root'.  If no log exists, a new
# file will be created (via touch)
monthly
rotate 4
errors root
create
   
# Watch on /var/log/messages
/var/log/messages {
   size 200k
   create
   postrotate
      /bin/kill -HUP `cat /var/run/syslog-ng.pid 2> /dev/null` 2> /dev/null || true
   endscript
}

These directives will function as the default rotate scheme for any logfiles not explicitly included by its own logrotate file.  The logrotate script can be found in /etc/cron.daily.  If you would like to run this less often, you might consider moving that script to /etc/cron.weekly, but anyting less often is not recommended.

Firewall Configuration

Restricting traffic to and from your server via a firewall (typically iptables) is a great way to limit the access others have to your server.  There's not enough room here to go over all the possible options you could explore with iptables, but I'll provide a simple script to setup some basic firewall rules for your server.

Chk out out instructions for setting up a firewall. We also have a number of handy blog posts

Checking website security

A reality of having publicly visible services is that hackers will scan your server for open ports and other vulnerabilities, and you should too as a preventative measure.  By monitoring which ports you have exposed to outside access, you can keep track if anything suddenly changes (such as an irc daemon being installed to control botnets).

Nmap (http://insecure.org/nmap/) is the gold standard for port scanning.  You can often find it in the repository for your distro and install it via:

[root@server ~]# apt-get install nmap
#run a sample scan to see visible ports
[root@server ~]# nmap -sTUR -F -P0 <yourserverip>

If you see anything out of the ordinary, you can investigate that yourself or pop in a support ticket and have us take a look for you if you're not sure what a particular service might be.

There are basic tools like 'ab' (apache bench) that can be used to test your site under load to make sure you don't see unexpected behaviour.

Nessus (http://www.nessus.org/) is a security scanner/analysis tool.  The authors maintain an up-to-date security vulnerability database which can be updated so that you stay on top of announced vulnerabilities.  There are clients for Windows and Linux and scans can be ran remotely or on the local machine.  For instructions on how to use this tool, visit the homepage.

Chkrootkit (http://www.chkrootkit.org/) is a tool for scanning your system's files to look for traces of an installed rootkit.  New releases are out with fair regularity so you should make sure that you're always using the latest release.  Below is some sample code which will download, unpack and run the application:

[root@server ~]# wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz
[root@server ~]# tar xvfz chkrootkit.tar.gz
[root@server ~]# ./chkrootkit*/chkrootkit

The OWASP top 10 is a good start for pen testing, but it is missing specifics. You really want someone with experience in that specialty to probe your site, most automated tools do not look beyond the surface.

ref Owasp top 10 cheat sheet

Having said that, if you want to have a go yourself the metasploit framework might be a good place to start, it has a rich history and is constantly being updated, and can check for old issues as well as new ones. The same company also provides a product called nexpose that might be a better fit for your requirements. Find them at Metasploit and Nexpose

Another option is to have a PCI compliance test run, this is especially relevant if you are providing ecommerce or data retention services, but can be useful in other cases to. For example check out Security Metrics

If you need a hand doing anything specific in relation to this article, please open a support ticket and we can help.

Additional Resources

Keeping up-to-date on the latest security trends/vulnerabilities is crucial to your long term success in keeping your server secure.  I've listed a few of the top security resources below.  I recommend subscribing to the relevent security mailing lists (especially the security announce lists) listed below.

Security-related websites:
http://www.securityfocus.com/
http://www.sans.org/
http://www.redhat.com/security/resources/
http://www.cert.org/

Security-related mailing lists:
http://www.redhat.com/mailman/listinfo
http://www.debian.org/MailingLists/subscribe
https://lists.ubuntu.com/
http://www.us-cert.gov/cas/signup.html