IIS
Internet Information Server, Web-server, part of the Windows NT Server, supports ISAPI.

IIS (Internet Information Server)
Microsoft's high-performance, secure, and extensible internet server based on Windows NT Server. IIS supports the world wide web, FTP, and gopher protocol.

IIS
Internet Information Server. A Web server program that is included by Microsoft when you purchase the Windows NT Server operating system. As Larry Ellison notes, this is not the same as "free". Rather than compete with other vendors of Web server programs, Microsoft puts its product into the operating system that everyone has to buy (unless they free themselves with Linux) and then raises the price of the operating system. The best part about IIS is Active Server Pages (ASP), described in the server programming chapter. The worst part about IIS is the comparative unreliability of Windows NT.
 

Limiting CPU Usage of IIS on the Server

Within IIS 6, you can use Enable CPU monitoring (show below) which permits limited control of an application pools CPU use.

When set to No action, an event viewer message is recorded when the application pool's CPU use exceeds the designated threshold. When set to Shutdown, the application pool is shut down for the interval designated in Refresh CPU usage number.




While this may be useful in a limited number of circumstances, true CPU throttling can be achieved with the Windows Services Resource Manager (WSRM) available with Windows Server 2003 Enterprise Edition. This jewel allows you to not only constrain any application's CPU use to a predefined amount, but to schedule such constraints and assign them to specific users and groups.

Shown below is the Add Running Process form in WSRM that allows you to designate a running process, including any instance of W3WP.exe (your application pool).





In this way, you define a rule known as the “Process Matching Criteria.” This rule is used by WSRM in choosing what processes WSRM. Then you create a “Resource Allocation Policy” that enforces your designated CPU limits on the processes identified in the Process Matching Criteria.

Restricting Specific User Permissions for Multiple Web Sites

If the users have Windows accounts that are used to authenticate to the server, then access is controlled through NTFS, the same way you harden a file server. This requires judicious use of the large groups like Everyone, Users, Authenticated Users, Domain Users, and the Network groups. Anytime you use one of these big buckets for permissions, you give access to most users that authenticate including the anonymous user.

One of the first things you have to decide is if you need a unique anonymous user for each site. This will provide the highest degree of isolation between web sites, but is more difficult to administer. With a unique anonymous user, you ensure that someone who is permitted to browse content anonymously in one web site cannot access directly or indirectly content on another web site (while in the security context of the anonymous account).

I recommend you manage permissions for web sites you want to isolate from each other using groups. Create a group for “class” of users for the web site and assign users to the group. This method is one of the best practices for managing permissions on a local server and makes it easier to change who can have access to the files by simply controlling group membership. For example, you can create a group called Web Site A Browsers and assign to it “Read” permissions for static content and scripts and “Read and Execute” to .dll and .exe programs. Next, consider applying the “Deny Write” permission for this group to the entire webcontent directory tree to ensure that anonymous users cannot write to the web server. This protects you in the event that someone applies the “Write” permission to a group such as Users or Authenticated Users, both of which include the IUSR_<servername> account. Of course, this will disable writing on locations where the web application attempts to write content to the server using the anonymous user account, such as an Access database; so you will need to explicitly assign the “Write” permission for any such locations and remove the “Deny Write” permission if you implemented that suggestion. Be sure you don’t assign “Execute” and “Write” permissions to any location that a non-trusted user can access!

Depending on the degree of security you require, you may want to create a unique anonymous user account for each web site. Place the account you use for anonymous access into the Web Site A Browser group and you have a site that is properly configured for your anonymous access. One of the advantages of securing with groups in this way is that if you have other users that have authenticated accounts, but you want to treat them as if they were anonymous users, you can make them “anonymous equivalents” by adding them to the Web Site A Browser group.

Next, create a Web Site A Authors group and place users into the group that you want to publish to the web site. Assign this group “Write” permissions to the entire web site directory tree.

Finally, you should consider using Domain local groups and users rather than local groups for permissions. The primary reason for this is that local users and groups cannot be copied to another server. In the event that you need to upgrade to a new operating system by doing a clean installation and moving your web sites, you would need to completely rebuild your users, local groups, and permissions. For some servers, this is a complex and error-prone task. If you copy files with permissions assigned to domain groups and user accounts, the new server is able to enforce those permissions presuming it is a member of the domain or trusted domain. This can also be an issue during disaster recovery. As usual, this is a tradeoff of functionality versus security as it is not recommended from a security perspective that your anonymous user be a domain based account. However, for some setups, such as a trusted intranet or stand-alone forest in the DMZ or web farm, a domain based anonymous user is an acceptable risk.

These suggestions permit you the greatest flexibility when managing your web server so that users from one site do not have privileges on another site. For even higher security with IIS 6.0, you may need to have unique application pool identities. For details on how to create a high degree of isolation, see the white paper Configuring Application Isolation on Windows Server 2003 and Internet Information Services (IIS) 6.0 at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/appisoa.mspx.