Securing the Ramparts With IIS

Imagine you live in a medieval kingdom, and you’re the poor sap the king just named to design his new castle.

Tightening up IIS security takes a little work. Here’s a primer to get you started.

“A nice one,” he says, “and make sure it’s impenetrable!”

(Stick with us 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 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 the network, minimizing the possible damage. More than likely, that machine will need to interact with very sensitive data 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, odds are pretty good your Web server of choice is Internet Information Services (IIS). Although Apache is far and away the top software responding to the billions of HTTP requests floating around every day (owning more than 50 percent of the market according to the monthly Netcraft survey), IIS is 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, from its inception, hasn’t exactly provided the level of security desired in a Web server, so those who choose to use it must be on guard.

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 better off with a properly configured Windows Server 2003/IIS 6 box than you are with any of its predecessors.

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 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 in the first place.

Whenever possible, see to it that the server is serving only Web pages. If it’s in the budget, you should try to separate duties as much as possible. For example, make another box the domain controller, another your SQL server, and so on. 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 comfy new home in your DMZ. That’s a great start, but you’re not done yet.

By default, IIS 6 is relatively locked down. Although a default installation will serve only static content to visitors (ASP.NET and FrontPage Server Extensions, among other bells and whistles, have to be manually enabled), 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.

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 we’re talking about a publicly available Web server. If your machine should be accessed only 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 the Wizard in Oz before they discovered he was 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 have 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 example, 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 it launches am attack, and if someone has to scan every port on your machine to find IIS it might buy you some extra time to detect and thwart the assault.

This article was originally published on Enterprise Networking Planet.