Securing Your Server

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 service ports you have exposed to outside connections, the smaller your attack surface is.

Checking Which Services Are Running

To check what services you are currently running, type:

[root@server ~]# ps -ax

On a Redhat-based distro, you can examine the services configured to automatically start at boot time via:

[root@server ~]# chkconfig --list | grep 3:on

On a Debian-variant, you can view which startup scripts are enabled via:

[root@server ~]# ls /etc/rc3.d/

Managing Which Services Automatically Start Via Chkconfig

You might want to stop a service from running without removing the package from your system. In that case, managing the startup scripts will allow you to stop or start a service from automatically running at boot time. On Redhad-based distros, you can accomplish this with chkconfig:

#prevent iptables from starting at boot time
[root@server ~]# chkconfig iptables off
#start postfix automatically at boot time
[root@server ~]# chkconfig postfix on

Debian variant startup scripts can be managed via update-rc.d or directly by manually adjusting the startup scripts located in /etc/rc3.d/.

Keeping Your Server Patched

As new vulnerabilities are found, each distro releases updates to existing packages which incorporate security fixes. All of the distros we offer are configured to use apt-get to update and maintain your packages which makes it very simple to check for and install new updates.

When To Patch?

In my opinion, updating is something which should be done at least weekly because new security flaws are found all the time. 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. See the following link for some tips which involved a recent webmin exploit:

http://bliki.rimuhosting.com/space/knowledgebase/filtered+webmin

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 the service until a patch is available might be your best bet to remain secure.

Manual Updates

To manually update your system, do the following from the command line:

#install new updates
[root@server ~]# apt-get update
[root@server ~]# apt-get upgrade

Automatic Updates

As I mentioned, it's best to stay on top of updates as frequently as possible. One way to do this is to configure your system to automatically update itself via a cron job.

Place the following in a file called 'apt-upgrade' located in /etc/cron.daily

#!/bin/bash
apt-get update
apt-get -y upgrade > /var/log/apt-upgrade.log

Change the permissions to make it executable:

[root@server ~]# chmod +x /etc/cron.daily/apt-upgrade

This will automatically run each day and log any automatic upgrades in a log file so you can inspect it at a later date to see what was done.

User Account Security

Keeping tabs on system users can help you prevent unauthorized users from gaining access to your system via an account with a weak password (or no password). It's also important to keep in mind which users actually need shell access to your system; you should eliminate shell access when it is not needed for a particular user.

Disable Unnecessary Accounts

An annoying inclusion with many distros is the presence of a log list of entries in /etc/passwd for application user accounts. Sometimes these users will exists for packages that you don't even have installed. Leaving these users around will probably not result in an attacker gaining access, however, it is often to be on the safe side in regards to security.

If you don't know whether or not an account is active, you can try to determine this by searching for files owned by that user and checking their last modified date.

Finding files owned by a user:

#print file names/locations
[root@server ~]# find / -user USER
#check last modified date
[root@server ~]# ls -lu FILENAME

If the user doesn't own any files or if the files haven't been modified by many months, it might be a safe bet to go ahead and remove that user from your system. You can do so via:

Remove user

[root@server ~]# userdel USER

At the very least, if you don't remove the user you can disable shell access by changing the last field in /etc/passwd from their current shell to /sbin/nologin. Another option would be to add a line explicitly granting SSH access to certain users directly to your ssh configuration file.

[root@server ~]# echo ?AllowUsers USER1 USER2 USER3 USER4? >> /etc/sshd/sshd_config
[root@server ~]# /etc/init.d/sshd restart

Restrict shell access to a particular group of users by adding an AllowGroup directive to etc/sshd/sshd_config

#create new group
[root@server ~]# groupadd shellusers
#add members to group
[root@server ~]# usermod -a -G shellusers USER
#add directive to ssh configuration
[root@server ~]# echo "AllowGroups shellusers" >> /etc/sshd/sshd_config

Checking For Users With No Password

Even worse than a weak password is no password at all. Application accounts without shell access probably don't have existing passwords so the following script will turn up some users without passwords which are perfectly safe. (i.e. the postfix user would be an example of that).

Check for missing passwords

[root@server ~]# awk -F: '$2 == "!!" { print $1, "has empty password!" }' /etc/shadow

SSH Security

By default ssh is pretty secure, however there are a few measure you can take to step up the security a bit. You can find various settings located in /etc/ssh/sshd_config.

#disable protocol 1
Protocol 2
#reduce maximum login attempts
MaxAuthTries 4
#move ssh from default port (22)
Port 2022
#decrease time user has to authenticate
LoginGraceTime 30s
#deny root user to authenticate without ssh keypair
PermitRootLogin without-password
#throttle concurrent login attempts
#allow 3 concurrent connections and randomly reject connetions (75% probability)
#until 10 connections are running concurrently.  anything beyond 10 is rejected
MaxStartups 3:75:10

Generating SSH Keypairs

Using cryptographic keypairs for authentication makes authentication much easier for you and allows you to completely disable password authentication on your server (if you wish) which is a much more secure way of handling authentication since password guessing is rendered useless in that case.

#generate public/private keypair
[root@server ~]# ssh-keygen -b 1024 -C user@domain.com
#copy contents of public key to your list of authorized keys
[root@server ~]# cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys

The above command will also generate a private keyfile (id_rsa by default) and you'll want to make sure to protect that key. Do not leave it on your server if it is also used to authenticate to your server.

If your home system is running Linux, you can use that keyfile directly to authenticate via ssh. If you are connecting through Putty, you'll want to download a copy of Puttygen and use that to convert your private key into a format which is compatible with Putty.

Logging System Events

Keeping an eye on what's going on with your system via system logs is a good way to stay informed whether or not your system is an active target of hacking attempts. Once a system has been compromised, system logs may prove meaningless as they can be easily manipulated, however they remain a good indicator that your system is being actively attacked.

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.

The following code should be placed in a file such as /root/firewall.sh and chmod'd as executable via chmod +x firewall.sh. After that you can run ./firewall.sh and you'll have yourself a capable, if not basic, firewall in place.

#!/bin/bash
# Flush default chains
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
# Allow ssh connections
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Allow ssh connections from only specific IPs (must comment above rule)
#iptables -A INPUT -p tcp -s YOURIP --dport 22 -j ACCEPT
# Individual ip address rejects
#iptables -A INPUT -s BLOCKEDIP -j DROP
# Allow traffic for established connections
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
# Allow traffic over the loopback interface
iptables -A INPUT -i lo -j ACCEPT
# Allow incoming pings
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
# Allow email MTA (Postfix/Sendmail)
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
# Allow IMAP/IMAPS/POP3/POP3S
iptables -A INPUT -p tcp --dport 143 -j ACCEPT
iptables -A INPUT -p tcp --dport 993 -j ACCEPT
iptables -A INPUT -p tcp --dport 110 -j ACCEPT
iptables -A INPUT -p tcp --dport 995 -j ACCEPT
# Allow http requests (standard & ssl)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# GLOBAL REJECTS
iptables -A INPUT -j DROP
iptables -A FORWARD -j REJECT
# Save this settings so that they are applied during the next reboot:
iptables-save > /etc/sysconfig/iptables

I've placed comments above each firewall rule in the above script so that you can comment out any rules you do not want. The script will save the rules and they will be active even after you reboot your server (as long as the rules are being restored properly by your system).

To ensure that iptables runs by default at boot time, enter the following command (on a Redhat-based system):

[root@server ~]# chkconfig iptables on

For a Debian-variant (Debian/Ubuntu), you might want to roll your own init script for iptables. Below is a sample init script you could place in /etc/init.d/iptables

#!/bin/sh
# Uncomment either iptables or ipchains
PROGRAM=/usr/sbin/iptables
FIREWALL=`/bin/basename $PROGRAM`
RULES_FILE=/etc/sysconfig/${FIREWALL}
LOADER=${PROGRAM}-restore
FORWARD_BIT=/proc/sys/net/ipv4/ip_forward
if [ ! -f ${RULES_FILE} ]
then
        echo "$0: Cannot find ${RULES_FILE}" 1>&2
        exit 1
fi
case "$1" in
        start)
                echo 1 > ${FORWARD_BIT}
                ${LOADER} < ${RULES_FILE} || exit 1
                ;;
        stop)
                ${PROGRAM} -F                   # Flush all rules
                ${PROGRAM} -X                   # Delete user-defined chains
                echo 0 > ${FORWARD_BIT}
                ;;
        *)
                echo "Usage: $0 start|stop" 1>&2
                exit 1
                ;;
esac

Then modify it to be executable.

[root@server ~]# chmod +x /etc/init.d/iptables

You can then start/stop your firewall via /etc/init.d/iptables start|stop. It will automatically read your firewall rules from /etc/sysconfig/iptables upon initialization. To automatically load that at boot time, enter the following commands:

#start iptables on runlevels 2,3,4,5
[root@server ~]# ln -s /etc/init.d/iptables /etc/rc2.d/S08iptables
[root@server ~]# ln -s /etc/init.d/iptables /etc/rc3.d/S08iptables
[root@server ~]# ln -s /etc/init.d/iptables /etc/rc4.d/S08iptables
[root@server ~]# ln -s /etc/init.d/iptables /etc/rc5.d/S08iptables
#stop iptables on runlevels 0,1,6
[root@server ~]# ln -s /etc/init.d/iptables /etc/rc0.d/K92iptables
[root@server ~]# ln -s /etc/init.d/iptables /etc/rc1.d/K92iptables
[root@server ~]# ln -s /etc/init.d/iptables /etc/rc6.d/K92iptables

check security with scanner

Hackers scan your server for open ports and other vulnerabilities (exploitable services) and you should too. 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 SERVER

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.

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

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