Amos Repairs

This is a boring post about server security. Security is a naturally boring subject, however you are really interested to keep it that way because security excitement means trouble. Especially so if you run a web server with sensitive data on it.

Lately I've been doing some basic security auditing of my web servers. I run 2 servers, one of them is a locally hosted Debian Stretch (a fresh install from just a week ago) that serves a web application for my internal use, the other one is a public-facing Ubuntu web server (which currently has absolutely nothing on it besides an "under construction" landing page) hosted on amazon AWS. Looking at the logs, turns out that lots and lots of things out there are probing these servers for vulnerabilities. There is no reason to think I present a special interest to any particular attacker - these are just bots. However, that doesn't make them harmless - logs show evidence of all sorts of automated attacks, from brute-force password guessing to attempts at remote code ex*****on attacks. Luckily, my passwords are strong enough, I routinely patch servers against software vulnerabilities and run the absolute minimum of required software, so their chances are slim. Yet, I decided to take additional steps to harden security on my servers, and invested quite a bit of time to research how to do this right and make the most out of it. Here are some links to guides that proved valuable.

These guides can not replace thinking (and in fact, the 3rd one contains some errors), and they overlap, however they are recent enough to be relevant and help making sense of the available tools and practices.

https://github.com/imthenachoman/How-To-Secure-A-Linux-Server

https://www.vpsbasics.com/tutorials/hide-apache-and-php-version-on-ubuntu-centos/

https://blog.rapid7.com/2017/04/09/how-to-configure-modsecurity-with-apache-on-ubuntu-linux/

https://webologix.com/en/blog/configurer-fail2ban-sous-debian-stretch.html?Itemid=162