There are three main stages in a servers lifetime; building/configuring, usage, and being decommissioned, with the usage section usually being by far the largest section in terms of time. For this reason, it’s obviously important to make sure that the server is optimally configured, secure and able to be reproduced/replaced easily in the event of a disaster.
Depending on the company owning/running them, servers can range from clean and efficient pieces of machinery, to rusty old lawnmowers that need a bit of coaxing to start. There are some quick wins that offer a chance to move yourself from the second extreme into the first. By carrying out a fairly quick audit covering some main areas, you can get yourself some great returns for not much work.
If you are running an insecure server on today’s internet, it’s not a question of if you have a system security compromise, it’s a matter of when. One of the first things we check upon carrying out a server audit is if the system is being actively patched, what levels of patch are being applied (all updates vs just security vs none at all), and how often the system is being patched. Furthermore, we also check the if non-system software, such as CMSs like WordPress/magento, or other utilities like phpMyAdmin, are being kept up to date. Actively keeping all system software up to date is one of the easiest things you can do in keeping systems secure, but it makes the job of a potential attacker much, much harder.
Another easy-win for security is the use of a firewall. Firewalls provide a set of rules determining who may connect to your server and on what ports/protocols. This allows you to greatly reduce your attack surface, by only exposing services that absolutely need to be exposed. For example, on a web server, you’d really want to expose ports 80 and 443, for HTTP and HTTPS respectively. However you may also want to expose port 22 (SSH) for remote management. This can be locked down to only allow certain IP addresses for this management. Depending on how security conscious you are, outbound firewalling can also be implemented, allowing you to control what other systems on the internet your server may talk to.
Everybody knows what backups are, but sadly not everyone understands their importance. Backups are critically important, as they allow you to retrieve your data should the worst happen with your server and it becomes inaccessible. Mistakes also happen, and having easy to access backups can save your so much time by allowing you to just roll back your changes, instead of taking a long time trying to unpick your errors and rectify them, often whilst under the pressure of having a broken server/websites/application etc.
The granularity of backups is also an important aspect to consider. Many server providers offer a backup service, but what people often fail to realise is that if you want to restore these backups, you have to restore everything, you don’t get to decide what’s rolled back and what’s kept. This can be a real pain if you have to lose a weeks worth of work just because you updated the wrong row in a table. This is why we also recommend that separate backups are kept for each “area” of data. For simple web server builds, we would typically configure backups of a sites web directory, and separate backups of the site’s MySQL databases(s).
It’s also important to keep these off-site; backups aren’t much use if they’re stored on the same server they’re backing up.
There are a huge number of configuration tweaks and changes that can be made in order to get more performance from your server, some being one-line changes, some involving a complete rebuild of your infrastructure. There are some however that can be done in a matter of minutes that can have huge benefits going forward. The main one we’re going to mention is resource limits.
Popular web-servers, such as Apache and nginx, allow you to set how much of the total system resources they are allowed to consume. In some cases it may seem obvious that you want them to be able to consume as much as they want for the best performance right? Wrong. If a server gets really busy, say your cat video has gone viral, there is a good chance people are going to be asking your server to work harder than it’s able. If you do not set appropriate resource limits, your server is going to use up every last drop of available memory/CPU, which results in it becoming unusably slow, and processes often get killed in order to free up memory.
We’ve quite often seen the MySQL database server process get killed, as it can use up a lot of memory. If your database goes offline, you’re gonna have a bad day.
If any of the above sounds like something you want to do, but you’re not sure where to start, then contact us and we can certainly help you with the points mentioned, along with many other aspects that we check in our server audits.