Server Security Checklist: Are you at risk?
CEO & Founder of Server Density.
Published on the 14th October, 2015.
Last week we covered some essential API security checks. In this third installment we turn our focus to server security.
Securing your server is at least as important as securing your website and API. You can’t have a secure website (or API) if the infrastructure they rely on is not solid. What follows is a server security checklist with 5 risks you need to consider.
1. Security Updates
Many vulnerabilities have a zero-day status, i.e. the vulnerability is discovered (and disclosed) before a software vendor gets a chance to plug the hole. A race to a patch then ensues (see shellshock example). It’s often just a matter of a few hours before a public vulnerability turns into a malicious automated exploit. Which means, it pays to be “on the button” when it comes to getting your security updates.
You may want to consider automatic security updates (here is how to do this for Ubuntu, Fedora, Red Hat & Centos 6, and Centos 7). However: note that automatic updates can cause problems if they happen when you’re not expecting them or if they cause compatibility issues. For example automatic update of MySQL will cause MySQL to restart, which will kill all open connections.
We recommend you configure your package manager to only download the upgrades—i.e. without auto-installation—and then send regular notifications for your review. Our policy is to monitor security lists and apply updates at a set time every week. Unless the vulnerability is critical and we have to react immediately.
2. Access Rights
Rationalising access rights is a key security step. It prevents users and services from performing unintended actions. This includes everything from removing the “root” account to login using SSH, to disabling the shells used for default accounts that’s not normally accessed. For example:
- Does PostgreSQL really need /bin/bash?
- Can privileged actions be accomplished through sudo?
- Are cron jobs locked down so that only specific users may access them?
3. SSH Brute force
A very common point of attack is for bots to brute force accounts through SSH. Some things to look at:
- As per previous section, it’s essential to disable remote login for the root account as it’s the most common account to be attacked.
- As these bots focus on passwords specifically, you can reduce the attack surface by employing public/private keys instead of passwords.
- You can go a step further by changing the SSH port from the default 22 to something else. The new port can, of course, be revealed with a port scanner (you may consider port knocking add-ins for this), however internet wide sweeping bots are opportunistic and don’t go that far.
- A more drastic measure is to block all traffic and whitelist specific IPs. Ask yourself, does the entire internet need access to your servers?
As a general note, security through obscurity is never a good goal, so be conscious of introducing unwarranted complexity.
4. File System Permissions
Consider this scenario. Someone finds a remote code execution vulnerability in some PHP script of a web app. The script is served by the www-data user. Consequently, any code injected by the hacker will also be executed by www-data. If they decide to plant a backdoor for persistence, the easiest thing to do is write another PHP file with malicious code and place at the root of the web site.
This could never happen if www-data had no write access. By restricting what each user and service can do (least privilege principle) you limit any potential damage from a compromised account (defense in depth).
File system permissions need to be granular. Some examples to consider:
- Does www-user need to write files in the webroot?
- Do you use a separate user for pulling files from your git repository? (We strongly advise against running your website from a github checkout.)
- Does www-user need to list files in the webroot?
We suggest you spend some time reviewing your file system permissions on a regular basis.
5. Server Monitoring
Any anomalous server activity can indicate a breach. For example:
- A peak in entries for an error_log can be the result of an attacker trying to fuzz a system for vulnerabilities.
- A sudden, but constant increment in network traffic can be the result of an on-going DDoS (Distributed Denial of Service) attack.
- An increase in CPU usage or disk IO can indicate the exfiltration of data. Such as the time when Logica got hacked, affecting the tax authorities of Sweden and Denmark. Ouch.
- An increase in disk usage is yet another sign. Once a server is compromised, hackers use as an IRC and torrent server (adult content and pirated movies), et cetera.
When something does go wrong and your server is affected, time is of the essence. That’s where reliable alerting and server monitoring (that’s us!) come in handy.
In our next security dispatch we’re going to take a broader look at how to become proactive about security, and discuss ways to instill a security-conscious culture in your organisation. To make sure you don’t miss a beat, sign up here. You should also read the other articles from our security month, including the website security checks you should be considering, and how to secure your API.