Locking Down Web Servers

posted on 06/05/08 at 08:00:00 pm by Joel Ross

At about 2:00 PM on the Friday before Memorial Day Weekend, I talked to a client who was frantic over an issue where a part of their system appeared to be compromised. I spent the better part of the afternoon and evening with him trying to figure out what happened and how it can be prevented in the future.

We still don't know how it happened - it doesn't look like the server was hacked and looks more and more like it was a third party service that was actually compromised. But we couldn't be sure, so we went through and did a few things to lock it down a bit more. After we were done, he mentioned this should be part of our standard project plan. And he's right, it should. So I figured I would list out what we did, what we talked about doing on a longer term basis, and why.

  • Disable the administrator account. If someone is trying to get into your computer and the administrator account is enabled, you're giving them one piece of information. By creating your own admin user who isn't "administrator", you're making them obtain two pieces of information before they can gain access to the box.
  • Use a pass phrase over a password whenever possible. There's two reasons for this. First, if you have a truly complex password, you won't remember it. You'll end up writing it down. And most likely, it'll be less than 10-15 characters, meaning it's potentially susceptible to a brute force attack. a pass phrase (for example, "Frankly my dear, I don't give a damn!") is much better because it's much, much longer. It's also easy for you to remember, because you pick a phrase you're familiar with.
  • Different passwords for everything! This can get a little daunting to manage, but ideally, you should have different passwords for all accounts. In the end, we now have a different password for the system's user account, the database, and all third party integrated services. Now if one of those passwords is compromised, they don't have access to everything.
  • Don't tell anyone your passwords. If you have secure passwords, but then the whole team knows them or you leave sticky notes everywhere, then your password isn't secure at all. It's a difficult balance to have complicated enough passwords, yet still be able to remember them. For me, I like to use KeePass to manage my passwords. This way, I only have to remember one password, and then I can get access to all of my passwords. I especially like that I can share the same file between my laptop and my Axim using the mobile version.
  • Disable everything you don't need. Close all the ports you can. When we were originally developing the site, we used FTP to get the files up to the server. We no longer do it that way, but the FTP service was still on, as well as the port being open. We turned FTP off and closed the port. This left just 80 and 443, which we need for the website.
  • Patch the box regularly. We originally deployed the site three years ago. A few patches had been applied, but when we went onto the box, a LOT of updates were pending. We applied all of the ones directly related to Windows 2003 (which included a service pack!). There's a reason those updates are pushed out like they are - they're meant to be applied. We coordinated with the hosting provider to have those installed periodically.
  • No passwords in source control. Any place that you store your password is one more location that can be compromised. The less points of failure, the better. I usually keep staging login information in my config files that are checked in, and when I deploy, I either don't touch the config files if there haven't been any changes, or I update the one deployed with just what has been updated. This way, my login information is only stored on the production server.
  • While we're at it, encrypt your config files. Or at least the pertinent sections - usually connection strings and app settings. This way, even if the server is compromised, the file is encrypted and they most likely won't get what they are looking for.

This is by no means a comprehensive list, but these are some very simple things that you can do to ensure a bit more security for your applications. I think it's a good start, but I know there's parts I'm missing, so that's where I'll look to the comments to help fill this in.

Tags: |

Categories: Consulting, Development, Software