IIS Security SettingsA Refresher

for RuBoard

IIS Security Settings ”A Refresher

At its lowest level, IIS, like any other Web server, is basically a file server. A client, usually a Web browser, makes a request and the server sends the file. What happens between these two actions can vary widely. Looking at IIS in this way, it becomes easy to understand that the basis for IIS Security is the way you have configured file access permissions on your server. Only through proper file access configuration will any of the features of IIS, and for that matter ASP.NET, be as effective as they were intended. Right-clicking a file, directory, or drive and selecting Properties from the menu allows easy access to the settings referred to in this paragraph. Files and directories should only have users and groups allowed to perform any action ”read, write, or execute ”if they need it. Setting a global policy that allows everyone full access to every resource unless otherwise noted is not a good policy.

The next consideration is the permissions required by the files themselves . These settings are most easily accessed through the IIS Management Console. What is meant here is that at the directory level, you should not over allow on permissions. If you have a directory that is full of static HTML pages, that directory should have read access only to all users and groups with the possible exception of authors changing content, automated or otherwise. In a directory containing either all Active Server Pages and/or a mix of Active Server Pages and static content, the only permissions needed are read and script. Unless you have a directory that contains active .dll and/or .exe files that should execute on the server, you should have read and execute permissions enabled. This setting has confused some developers as they place COM/COM+ objects in a directory on the Web server and mark it with execute. This is not necessary because COM/COM+ objects can live anywhere on a Web server. This is mostly intended for directories where ISAPI extensions exist and are called through the URL.

The final basic consideration for refresher is authentication. While the use of authentication with ASP.NET is adequately explained in Chapter 14, it can never be underrated how helpful it can be in securing a site by requiring users to log in. Be it through Integrated Windows authentication or a SQL Server database containing encrypted user information accessed over SSL, keeping users out of your site is often more important than letting users in.

for RuBoard