We recently added a new Active Server Pages (ASP) application to our company's public Web server. In the past, we've been able to tightly lock down the server, but this externally developed application requires some loosening of security, and I'm not confident the application code itself is that secure. The application doesn't have confidential data or handle business transactions, but other areas of the Web site do, and of course I think about the home page itself. How can I best isolate the new application from the rest of the Web site in case the app gets hacked?
Excellent thinking! The best isolation of course would be hosting the application on a different server (and in a different forest, if the server is a member of a domain). But if that isn't an option, several features in Microsoft IIS were originally envisioned for ISPs hosting multiple Web sites–you can make use of these to implement some isolation so that if your new application does not get hacked, the intruder doesn't automatically gain access to the rest of your site.
First, if the application allows anonymous connections at the IIS level, create a new user account for IIS to impersonate when servicing these connections. Restrict the user's group memberships, NTFS permissions, and user rights so that the account has the fewest privileges possible. Then configure IIS to use this account on the Directory Security tab of the application folder's Properties dialog box in IIS.
IIS 6.0 also allows you to control the identity of the actual worker processes that service HTTP and HTTP Secure (HTTPS) requests. Create another new user account with minimal authority. Then, create a new application pool in the Microsoft Management Console (MMC) Internet Information Services snap-in. On the Identity tab of the application pool's Properties dialog box, configure the pool to run under the second account you just created. Back on the application folder's properties in IIS, select the Directory or Virtual Directory tab (depending on the type of folder in which the application resides). Under Application Settings, click Create and name the application. Now, in the Application Pool drop-down box, select the new pool you just created.
Now the application is running as a separate account both at the impersonation and worker process levels. An attacker who might compromise the application at the application level or even within IIS through a buffer overflow shouldn't have access to other parts of the Web site. To make sure, though, create a group and add both new accounts as members. Then explicitly deny the group access to other folders in your Web site.
