A couple of years ago at DefCon 18, a security-focussed conference in the US, a presenter called Zoz told the story of when his computer was stolen from his flat – and how he used his expertise to punish the thief.
Ironically, the hacker’s computer was stolen due to a classic physical security fail: he may have had locks everywhere, but one weak link allowed the thief to simply bypass the majority of them. Losing his computer was a disaster, said Zoz, and it got worse; all of his religiously made backups were taken as well, as they were stored on portable hard disks kept in the same room.
I was reminded of that presentation when I returned home from a weekend away to find that my own apartment had been burgled, a very similar crime scene to the one mentioned above. I had nice-looking but obviously pointless locks on the windows, and even a chain on the front door which was inherited from the previous person renting this apartment. Instead of protecting me though, that very chain was used to stop me, the legitimate owner, from entering my own place. According to the police that's a common thing to do: If the owner happens to arrive home while they're still searching the place, they have enough time to escape through the window – even before you have a chance to figure out what happened!
Both stories highlight one important piece of advice that you should always consider: It's always the weakest link that gets you. That means if you as a web developer did a good job, the weakest link is not going to be the website itself, but the infrastructure it is running on. This may be the database server that is, despite knowing better, not hidden on a private network, but publicly reachable for "administrative purposes". Or the backup you have stored on a physical machine owned and operated by the ISP or by someone else.
Let's start at the beginning: By default most Linux distributions ship the Apache web server with PHP installed as a module and MySQL added to the mix, forming the classic LAMP stack. Securing – or as the security industry calls it "hardening" – a multi-purpose server is not easy and might require you to make various trade-offs in order to actually be able to get it working. Whoever said "everything has to run on the same machine" isn’t telling the truth, though: it doesn't have to. Especially with virtual environments, and even the cloud setting up dedicated machines, it is not much more of an effort. Splitting up a complex system into individual server makes securing each machine a lot easier, especially when having every server (except the web server) run on private IP addresses only. So instead of running an all-in-one server, your secure environment would be comprised out of three machines: The web server, a PHP server and a dedicated database server.
Wait a second; did I just say splitting up the web server and PHP? How is that supposed to work? For quite a while now, PHP can be run as a service that implements the FastCGI protocol. PHP-FPM, the FastCGI Process Manager, is run independently of any web server, either locally or remote. Installing PHP-FPM on an individual server – or on multiple servers in case one single machine cannot handle the full load – eliminates the need to have the PHP interpreter as well as PHP source files on the web server. This leaves only static files like images, CSS, or JavaScript code.
Reducing the amount of public facing services to HTTP only and not having any source code at easy reach means that attackers are going to have a hard time gaining access to any PHP code. There are of course many more things you can do to secure the infrastructure, but considering what the weakest link could be and how to tighten it is the key factor for a really secure system. Having a secure environment from a technical perspective turns the physical hosting into the weakest link. This is no surprise; physical access has always been the main problem for any IT infrastructure.
So whenever you plan the infrastructure consider not just the amount of CPU, RAM, or form factor, but also the hosting location, their backup mechanisms as well as the security protocols. It may not even be an attack that can cost you your servers. If you have a shared rackspace and someone else needs access to it, you might lose connectivity or your hard drives by mistake. In this case, it is human error which would be the weakest link – something that is very hard to plan for as well as to counter.
If you decide not to trust any ISPs, and instead host everything yourself, be aware that implementing and enforcing physical access control yourself is not an easy task. And merely locking doors, 19" racks and servers in one place doesn't help if an intruder has all the time in the world – for instance over the weekend. As a last resort, you should choose a place which has encrypted backup at a remote location. You know, just in case!