Recovering from an IIS hack requires serious refortifying

Normally, I don’t deal much with Microsoft’s IIS, except when it’s used to run a distributed application behind the firewall. That’s the luxury of being a network integrator instead of someone in the Web hosting business. But in all our lives some rain must fall, so when a client called regarding a compromised IIS server, I had to respond.

The client hadn’t done badly, considering the circumstances. This server wasn’t part of my company’s service contract with him, so he was administering it himself. He noticed some flaky performance during business hours on Monday, so he activated a system audit for the previous 48 hours and found that someone had compromised his system over the weekend.

Using System Audit is certainly a good start when sniffing the tracks of hacker vermin, and he came up with useful information. The attacker had modified a number of CGI scripts he had running on the site, activated a guest account, and added a new “mystery” user account off the login script. The hacker boosted several account permission levels to Administrator and also enabled the remote registry service.

All in all, my client figured this had been a reconnaissance mission for either a hard-line future attack or some long-term monitoring or mischief-making. What he wanted from me was help in reconfiguring the server to repair the damage and plug the existing security holes. That’s where the bad news starts.

First off, while none of the information from the audit was wrong, it probably didn’t tell the whole story. Anyone with that kind of access to the system and with even the possibility of long-term monitoring on his or her mind would have left additional malware hidden on the machine that System Audit simply would have missed. There’s no way to fix such a situation and then feel comfortable in your Web server’s security.

Safety requires not only a reinstall of IIS but also a low-level reformatting of the disk. Hopefully, you have a semirecent version of your Website that’s stored on a disk, not the version your tape drives backed up the day before. If not, it’s best to put in the required time to build such a site version, using your site developer’s versions of the code. Securing associated databases, if one was connected to your Web site, is even trickier and will require some quality time with your database administrator.

Once these untarnished code packages have been compiled, the machine needs to be reformatted and then IIS reinstalled before the clean site code packages can be loaded. You’re looking at a day of downtime at the minimum.

The good news is such an attack can usually be used as leverage with senior management to spring for more effective server and Web link protection. I recently reviewed a great IIS protection tool, SecureIIS from eEye Digital Security. Additionally, Microsoft has done some good work in protecting IIS as well. You’ll need to pay extra for it, but Microsoft’s ISA (Internet Security and Acceleration) Servergoes a long way toward protecting your Web server from unwanted tampering. By installing ISA Server in front of your IIS server and publishing your site to it, ISA can then act as a flexible firewall in addition to delivering your site to authorized users. This has the added benefit that hackers never even touch the IIS server directly; they simply bounce off the much more secure skin of ISA.

ISA Server is certainly not the be-all and end-all of IIS server security, but it’s a great start that can be implemented quickly with clean integration into an existing Windows and IIS environment. A full security audit is still required after a successful attack, but ISA is a great way to add new security fast, while buying you enough time to develop a more effective Web server security solution.