Securing your hosts

Here are a couple of pointers in securing your hosts.

Application Code

The easiest way for an attacker to gain unauthorized access to your hosts is through web application vulnerabilities. These kinds of vulnerabilities bypass entire operating system security mechanisms.

If you are confident of your code’s quality, watch out for vulnerabilities in 3rd-party libraries. These libraries are usually missed in system upgrades since they are tightly coupled with your applications. You should subscribe to security updates for these libraries.

A prime example of a dangerous and easily exploitable application vulnerability of yore was one found in Action Pack (CVE-2013-0156 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0156).

 

Open Ports

The next possible point of intrusion are open ports of services or server software. Pretty sure you do not intend to open up services such as MySQL to the Internet. Do not rely on firewall rules or functionality such as security groups.

If a bug was introduced that inadvertently disabled these then there’s nothing to prevent an attacker from directly connecting to your services. Once they have access to the service they can use exploits or tools that may result in a breach.

To demonstrate the dangers of unintentionally opening up services to the internet, please read this post concerning Redis (http://antirez.com/news/96).

 

System Software

Not every service can be isolated. Therefore, it is important to keep software up to date for security vulnerabilities. For server software, examples are Nginx, Apache, OpenSSH, Postfix. These kind of software are supposed to be open to the Internet so it is important to keep them patched with the latest security updates.

Similar to the situation with 3rd-party libraries in your application code, some system software includes libraries that can be missed by upgrades. If security is of the utmost importance then is advised to be very familiar with every piece of software installed in your hosts.

Subscribe to security feeds of software you use or mailing lists such as the Open Source Security Mailing List (http://seclists.org/oss-sec/).

 

SSH keys

Everyone knows it is better to use public key authentication with SSH so we won’t rehash why it should be mandatory. The next step for making it more secure is by periodically auditing the active keys on your hosts.

Authorized users may have their private keys lying around in various places ready to be picked up by an attacker or if the user added a bad passphrase or worst no passphrase at all.

You can also go further with securing passphrase protected private keys if you recommend your users to convert their keys to the PKCS#8 format (http://tools.ietf.org/html/rfc5208 https://github.com/BrendanThompson/keycrypt).

1

Please sign in to leave a comment.