Thumbnail image

Server Hardening Strategies

Fri, Mar 31, 2017 3-minute read

Staying secure is a full-time gig. It doesn’t matter whether we’re talking a datacentre or your smartphone, there are always steps to be taken to keep your machines and your data as safe as possible. With the increasing popularity of virtualization for applications and services and the ability for people to “roll your own” cloud comes the need to secure those machines. This becomes increasingly challenging when you consider the fact that by their very nature these machines are constantly exposed to the Internet.

Minimize Your Attack Surface Don’t install it unless you need it One of the best things you can do to harden a server environment is to take a minimalistic approach. Don’t install components that you think you “might need” somewhere down the road, or things that are optional or unnecessary.

Do you need a database? Do you need to install PHP or ASP.NET? What do you need for your project? Take stock of all the components you need to have to implement your solution or your project and install just those pieces.

Uninstall it when you’re done with it If you have components that are no longer needed, remove them. Old versions of tools or frameworks, services or server components that are no longer required, or documentation and information which no longer needs to be published, are all examples of things that can be removed.

Understand how to secure it Know your tools. Become a professional. If you’re going to install something, take a few minutes and just search for “how to secure [insert application name here].” This will inevitably give you a ton of solutions and options for securing tools.

Secure Remote Access Being able to access your server or environment remotely is key, particularly in this age of cloud-based virtual environments. To that end there are three things you can do to help secure that remote access and reduce the attack surface.

Change SSH port Security by obscurity. On its own this isn’t a valid strategy, but as one more measure for helping to secure the machine it is certainly helpful. By changing away from the default SSH port you make it that much harder for attakers to determine what services are exposed on your server and where they might be hiding.

Disable root SSH access The root account does not need to access your server over SSH. Period.

Require key-based access Securing access over SSH with a public/private key pair makes accessing an account over ssh much more challenging. Only the best passwords are even remotely secure, but those strong complex passwords are frustrating to use and often lead to insecure shortcuts to make data entry easier.

If you go the extra step of also requiring a passphrase for that key you have, for all intents and purposes created two-factor authentication for your server without having to implement any third part token systems or have a complicated keying setup.

Read Your Logs Your system will log a whole bunch of information day in and day out. There is potentially a lot of information in these logs that just goes unnoticed unless someone actually reads it. Think of it as Schroedinger’s logs – the data about problems or possible attacks both exists and doesn’t simultaneously. We won’t know for sure until we look.

Some key log files to monitor are: * /var/log/auth.log or /var/log/secure * /var/log/faillog * /var/log/boot.log * /var/log/httpd/*

Go forth. Secure your server(s). Look after yourself.

Image credit: Blue Coat Photos on Flickr