Imagine you live in a medieval kingdom, and you’re the poor sap the king just named to design his new castle.
“A nice one,” he says, “and make sure it’s impenetrable!”
Stick with me here, this’ll get relevant soon.
You might build walls so tall and thick that no machine can penetrate them, stock the mote with alligators, and keep the oil boiling for any barbarian hordes passing by. Keeping people out of the castle isn’t hard … until the king mentions he’s after a drawbridge, too.
“What’s the fun of having a castle if no one can get in to spend money? But the impenetrable part? Keep that part.”
Welcome to the world of Web hosting.
Securing a Web server can be one of the most frustrating tasks on the IT department’s to do list. The idea of opening up a hole in your defenses to intentionally allow the collective “them” access to your company’s network and data goes against every instinct you have to lock down the entire show as much as possible. And it’s not like you can just take this one box and isolate it completely from the rest of your network, minimizing the possible damage. More than likely, that machine will need to interact with very sensitive data that you wouldn’t normally dare to put in harm’s way. What’s a geek to do?
If you’re working in a Microsoft shop, the odds are pretty good that your Web server of choice is Internet Information Services (IIS). While Apache is still far and away the top software responding to the billions of HTTP requests floating around every day (owning 58.86% of the market according to Netcraft’s April 2007 survey.), IIS can still be found on nearly one-third of all Web servers.
The flip side of using popular, readily available, and easily installed software, of course, is that every hacker, script kiddie, and ne’er-do-well on the planet has ready access to it, and each seemingly has nothing better to do that try to find new ways to exploit every vulnerability found in it. Unfortunately, IIS hasn’t exactly been the bastion of security we all would like in a Web server from its inception, so those of us who choose to use it need to be on guard.
More Windows Security:
We’ll assume that you’re using IIS 6.0 on a Windows Server 2003 installation, and if you aren’t you should be. You’re going to be better off with a properly configured Windows Server 2003/IIS 6 box than you would with any of its predecessors.
The Basics
Some things should go without saying, but when it comes to securing IIS you just can’t be too careful. Start with the basics, the same rules you know you should be following for all your servers. For example, make sure you have good backup and restore procedures for your Web server to minimize downtime and that your Web server is behind a solid, monitored, and updated firewall. Monitor the server logs regularly and install any security updates as soon as they’re available.
Of course, the most important rule is the simplest: if you don’t need it, don’t use it! Long gone are the days when Microsoft would install IIS by default, so you can’t go crying to Bill if someone hacks your poorly maintained server by exploiting a service you shouldn’t have installed to begin with.
And whenever possible, see to it that this server is only serving Web pages. If it’s in the budget, you should try to separate duties as much as possible. For instance, make another box the domain controller, another your SQL server, etc. And if it isn’t in the budget, make sure The Powers That Be are fully aware of what their penny pinching might cost them in the end.
The Not So Basics
Ok, so you need to a host a publicly accessible Web site and you’re using IIS to server it up. You’ve installed all the available patches, changed the administrator login to something obscure, created a password Ken Jennings would have a hard time remembering, uninstalled anything you absolutely don’t need, and found the box a comfie new home in your DMZ. That’s a great start, but you’re not done yet.
By default, IIS 6 is relatively locked down. For example, a default installation will only server static content to visitors (ASP.NET and FrontPage Server Extensions, among other bells and whistles, have to be manually enabled). That said, though, the downside of an easy to use, GUI driven OS like the Windows line is that it’s all too easy for someone to screw things up, whether out of ignorance or malice. To help, download and run the Microsoft Baseline Security Analyzer (MBSA). MBSA will take a look at the box and help you find any blatantly wrong security settings, hopefully before someone else discovers them.
Remember that IIS isn’t just a Web server, but rather an entire suite of Internet services. FTP, SMTP, NNTP and others are all included in the package. In the next part of this article, we’ll look more closely at those ancillary services, but in the mean time just remember that security commandment and don’t install them if you don’t need them.
By default, anonymous users are going to access your system as a user called IUSR_yourcomputername. Make sure you’re using NTFS (much more secure than FAT32) and that the NTFS permissions for that user are as strict as possible. We don’t want to give anonymous write access when we don’t have to, right?
All this assumes that we’re talking about a publicly available Web server. If your machine should only be accessed by known users, you should, of course, disable anonymous access altogether and consider allowing connections only from certain IP addresses. Don’t know how? Microsoft provides some pretty good and easy to follow documentation.
Security by Obscurity
First, I’m definitely not advocating obscurity as the only means of defense. By itself, it’s barely better than no security at all. However, when teamed up with the other practices described in this article, it’ll definitely help. Remember how afraid everybody was of Oz before they discovered the old man hiding behind the curtain? If you can dissuade 25 percent of your would be attackers with a little obscurity, doesn’t it make sense to do so?
Keep in mind that the exploits attackers will use will usually be specific to the version of the Web server detected. If you can hide the fact that you’re using IIS, then, you’ll fend off some of those attackers before they even start. It’s much, much better to prevent an attack from starting than to defend against it later.
Thankfully, IIS 6 doesn’t explicitly tell remote users the version number through a simple telnet request to port 80 any longer, but there are still a few areas that at least confirm you’re using IIS. For instance, the default “Under Construction” page created when IIS is installed mentions IIS by name, as do the default error pages (404, etc). Modify those files immediately and hide that bit of information.
Also, if this isn’t a publicly available Web server, consider binding IIS to a non-standard port. A lazy script kiddy might only look for an open port 80 when he launches his attack, and if someone has to scan every port on your machine to find IIS it mind by you some extra time to detect and thwart the assault.
Next time, we’ll talk more the ancillary services briefly mentioned in this article and steps you can take to lock them down.
