Every system object in Windows 2000 and Windows NT has a unique security descriptor that includes an ACL. An ACL is a list of entries that grant or deny specific access rights to users or groups. The Windows object-based security model lets you grant access rights to a user or group—rights that govern who can access a specific object, a group of properties, or an object's individual properties. Access rights on a per-property level provide the highest level of permission granularity. Each ACL has one or more access control entries (ACEs) that include the name of a user or group of users. For each of these users and groups, the access privileges are stated in a string of bits called an access mask. The ACL (and its associated ACEs) is the basic unit of file-system security. Generally, the systems administrator or the object owner creates an object's ACL.
You can use GUI tools such as My Computer or Windows Explorer to set or edit ACLs. Simply right-click any file or folder resource from one of these tools, select Properties, then click the Security tab. You'll see a graphical representation of the ACL on the resource you chose. From this dialog box, applying or removing group or user permissions to system resources such as files and folders is easy. You can also use a command-line utility (e.g., cacl.exe) to display or modify file ACLs.
You must make careful security considerations when you implement and maintain your Web sites. Here are three ACL-based security measures to consider for your IIS sites:
- Work with your developers to structure the Web application folders in a logical manner. You're better off creating new directories for each file type, setting ACLs on each directory, and letting the files inherit the ACLs. Managing and maintaining a Web application with individual ACLs for each file in the system is more difficult. For example, a directory structure might look like this:
C:\inetpub\wwwroot\interknowlogy\static (.html)
C:\inetpub\wwwroot\interknowlogy\include (.inc)
C:\inetpub\wwwroot\interknowlogy\script (.asp)
C:\inetpub\wwwroot\interknowlogy\executable (.dll)
C:\inetpub\wwwroot\interknowlogy\images (.gif, .jpeg)
In all these cases, you'll probably set the ACL at Everyone (X), Administrators (Full Control), System (Full Control). In a Web-site structure similar to the example above, you can isolate separate folders that might need read-write access from anonymous users, which gives you greater control.
Pay special attention to the FTP and SMTP folders (C:\inetpub\ftproot and C:\inetpub\mailroot, respectively). By default, the ACLs on these directories are Everyone (Full Control); depending on your implementation, consider modifying these ACLs with tighter security. To avoid running out of space on your IIS volume (which, of course, would bring your IIS server down), I recommend that you place the FTP and SMTP folders on a different volume than the IIS server if you want to support Everyone (Write). An alternate strategy is to use Win2K disk quotas to limit the amount of data you can write to the FTP and SMTP folders.
- Make sure that you mark the ACLs on the IIS-generated log files (%systemroot%\system32\logfiles) Administrators (Full Control), System (Full Control), Everyone (Read-Write Control). Setting permissions on the log files in this manner helps prevent intruders from deleting information that might cover their tracks.
- Disable or remove all the IIS-installed sample Web applications. This advice isn't an ACL-based security measure, but it's an important security step. Sample sites are just that—samples that help developers learn. They aren't installed by default, but many developers can't resist installing them. Never install sample sites on a production server because of the many and well-identified security risks they present. Some sample Web applications are installed so that you can access them only from http://localhost or IP address 127.0.0.1. Nevertheless, you should remove the sample sites. The IISSamples, IISHelp, and Data Access virtual directories and their associated folders are good examples of sample sites that should not reside on production servers.
Typically, developers don't think of security first; they're pressured to believe that going live quickly is their top priority. The marketing people or managers often create that pressure, and we all know that security isn't their first priority. So it's usually up to you, the IIS administrator, to intervene by setting security-based, architectural precedents for production environments.
End of Article
