Posted by Robert Schifreen on October 23, 2015.
I spent some time last weekend building a new web server. Actually, I lie. I spent pretty much all weekend building it. I haven’t named it yet but this machine will probably be the exception to my normal rule of calling machines after Radio 4 shipping forecast areas. This one, because it wasn’t built in a day, will be called Rome.
Turning a brand new, naked install of Ubuntu Server into a functional and secure web server shouldn’t be hard, but it is. You should be able to do it with a single command, but sadly that’s not the case. Which means trawling web sites, books, magazine articles, forums and blogs in order to sort the leets from the noobs. Neither of whom, it so happened, gave me the definitive answer I was looking for.
Sure, the world is full of people who happily regurgitate what every other Tom, Dick or blogger has been telling us for years. Sometimes it’s because they believe in it. Occasionally they’re actually right. But I wanted something that fitted my particular, specific needs, and I ended up having to come up with the answer myself. Which also meant deciding to reject some of the received wisdom and old wives’ tales. I feel slightly unclean and ashamed at having done that (there’s probably a special sign I’m supposed to hang on the front door of the office), but I’m running with it for now. I’ll review my choices as time goes on, and revise them if necessary.
I should start by saying that the needs of this particular web server are quite specific. Only one person (or maybe 2 at the most) will be updating the files on it, and those 2 people inherently trust each other. They don’t need separate accounts in order to satisfy any auditors. And while this isn’t yet a production machine, it needs to be regarded as such during development because, frankly, it’s a sensible thing to do.
I’m not going to share the precise details here as you’re probably not interested. If you are, drop me a line and I might change my mind. What I want to talk about right now is the code that will end up on this server, rather than the how the server itself is architected.
The server will be hosting a MySQL/PHP application which is going to be written in-house for my company. I don’t (he whispers quietly) like, or use, object-oriented coding. As a concept I think it’s great. It means that you can write a library once and then reuse it, adapting it as necessary, as much as you like. But we now appear to live in a world of component-based software, where calling one part of a 5000-line open source project is preferable to writing 6 lines of your own procedural code that could do the same job more quickly and doesn’t need updating every 2 weeks. So a project that should really comprise no more than a few thousand lines of code actually ends up containing half a million, and you’ve no idea what most of them do. Which doesn’t particularly matter because, as far as your project is concerned, they do nothing at all and are just taking up space on your disk.
So why am I ranting about this now, particularly? Because the latest news to come out of the rumour mill surrounding the TalkTalk breach (which, you’ll recall, might well have leaked the personal details of 4 million people) is that it was caused by a SQL injection attack. This is hugely significant because, like so many other hacks that have happened before, it is probably the fault of the code running on that server rather than the security of the server itself. It doesn’t matter how strong the root password for the machine is, and how tightly the ports are locked down, or how long you ban a user for if they try unsuccessfully to telnet into your server. If the application code, accessible to everyone in the world with nothing more than a web browser, is insecure then the hackers will find a way in. And there’s very little that you can do to shut that particular stable door until the horse has well and truly bolted.
If you really do take security seriously, you need to look not just at your server infrastructure but also the code that runs on it. Every line. Every single line. Because one trivial mistake, one tiny omission in calling the correct input sanitization routine, can open up your database to a SQL injection attack. Something which is the high-tech equivalent of a nightclub doorman asking “are you on the guest list?”, and you saying that you are, and him believing you.Share This: Submitted in: Robert Schifreen |