Permissions


Two types of permissions apply to IIS: IIS and NTFS. And IIS has two types of permissions: IIS permissions and Execution permissions. Share permissions do not affect IIS, although they could be used to access IIS files over NetBIOS connections (if allowed).

IIS Permissions

IIS has its own permissions that apply to each web site, virtual directory, folder, and file. These permissions are normally set under the Home Directory tab in IIS Admin (see Figure 12-8) after first selecting the web object focus (i.e., web site, virtual directory, folder, or file).

image from book
Figure 12-8

The IIS permissions are:

  • Script source access

  • Read

  • Write

  • Directory browsing

Script source access allows the client to read the web page's source code. This is normally okay, but might be disallowed if revealing the web page's source code or scripts can inadvertently reveal sensitive information (such as passwords). The connecting client must have Read or Write permissions in order for this permission to work.

Read permissions allow a client to download a web page, view or download files, navigate folders, or run scripts. Read is the default permission for all web sites, pages, files, and folders. If you disable this permission, the web page will not be displayed, although scripts and other executables will still be active and able to render. Write allows the connecting user to upload and modify content. This permission should not be given unless writing and modifying content (via HTTP PUT verb or WebDAV) is allowed. In some cases, Write permissions may not be required when using a program specifically designed for this purpose, such as FrontPage Server Extensions.

The Directory browsing permission is a unique one. If selected, clients will not download and display HTML content as they normally would. Instead, when the default document requested is not available, the directory is shown along with a listing of its contained files and folders (much like an FTP virtual directory might be displayed). Normal web sites normally do not have this permission enabled. However, enabling directory browsing is a convenient way to allow users to view, upload, and download files. You can also disable this permission, but allow Write, to create a "blind drop."

Administrators looking for an alternative to secure FTP should consider using directory browsing instead. Secure FTP clients and servers that talk to one another without issues are hard to find. Instead, enable directory browsing on an HTTPS web site containing the needed files and folders. Every user's browser will be able to connect and the content and authentication credentials will be authenticated and encrypted by default. Users will be able to right-click and Save As any file, and they can drag and drop uploaded files (or save directly to the web site using their local application if WebDAV is also enabled). Table 12-4 summarizes IIS permissions and their customary use.

Table 12-4

Permission

Description

Read

Users can view the content and properties of directories or files, and execute script content. This permission is set by default and required for web sites that have static content. If all of your content is scripted, such as a web site that only uses ASP content, you can remove the Read permission, but this is not generally recommended as it may interfere with rendering static content that may be mixed with the web site's application.

Write

Users can create, upload, modify, and delete content.

Script Source Access

Users can access source files and scripts. If the Read permission is set, then users can read source or script files; if the Write permission is set, then users can modify source or script files. You must have either the Read or Write permissions set to enable. Set this permission when using WebDAV. If enabled, make sure that you require authentication for this site and that your file permissions are set correctly.

Directory browsing

Users can view file lists and collections, and download files. Enable Write permissions, too, to allow file uploading.

Execute Permissions

Execute permissions can be set on each web site, folder, and virtual folder (but not file). Execute permissions determine whether or not scripts or executable content can be executed, and define whether or not the script source code can be viewed. The Execute permissions can be seen at the bottom of Figure 12-8. Table 12-5 explains the permissions.

Table 12-5

Execute Permission

Description

None

Enable if you only want clients to access static content, such as HTML and picture files. Will not run scripts or programs.

Scripts only

Default setting. Enable to allow clients to run scripts, such as ASP, ASP.NET, and PHP (not installed by default).

Scripts and Executables

Enable to run both scripts and executable programs on the server

NTFS Permissions

NTFS permission play a huge role in IIS. Ultimately, if the connecting client "breaks out" of IIS, the NTFS permissions assigned to the web pool identity and impersonated user account are the security mechanism of last resort. All of this assumes you install IIS and the web site content on a NTFS partition. And you should never install IIS on anything but an NTFS partition!

NTFS permissions need to be set on two major categories of files: IIS server application files and web site content. IIS's application files are located in a folder called %windir%\system32\inetsrv. By default, only the System and Administrators security principals have Full Control to the folder and its contents. Users (and sometimes the Everyone group) normally only have Read & Execute permissions.

Because the IUSR anonymous account is a member of the Users group, it means anonymous connections would have Read & Execute permissions to this folder (and many others on the server) if the IIS engine were to allow remote users to put in URLs that could access these directories. IIS stops them, luckily, after years of early exploits. However, if a hacker learns how to break out of the site locations authorized by IIS, they could potentially have Read & Execute permissions all over the web server. I'm not sure why Microsoft places the IIS anonymous user in the Users and Guests groups, but I hope they have a good reason. Of course, the lack of IIS 6 exploits reinforces the fact that the offsetting defenses must be working.

Web server content files are installed to \Inetpub\wwwroot by default. Default permissions are as follows:

  • System and Administrator have Full Control

  • Users group has Read & Execute

  • IIS_WPG group has Read

  • The IUSR_<computername> anonymous user has Delete-Deny, Delete-Create, and Write-Deny permissions. Coupled with the permissions it gains from being part of the Users group, this account essentially has Read & Execute permissions but nothing else.

When creating any web site, the NTFS permissions assigned should be the bare minimum needed by the connecting user, impersonated account, and web application pool identity to reflect the web site accurately and thoroughly. Although this might seem confusing at first, the effective permission security of any IIS web site is determined by the union of the following:

  • The NTFS permissions given to the application pool identity account

  • The NTFS permissions given to the user account the client uses to authenticate to the web server (e.g., anonymous or an authenticated user account)

  • The IIS permissions set on the web site, virtual directory, folder, or file

  • The IIS execute permissions set on the web site, virtual directory, or folder

IIS 7 will introduce role-based security and delegation. It will define various common web server roles and NTFS permissions that can be given to each role. Then user accounts are added to each role, inheriting the appropriate permissions.

Understanding the effective outcome of these permissions on each folder and file in each IIS web site is essential to being a knowledgeable IIS administrator. Read-only web sites should be restricted by Read-only NTFS permissions. If executable program files are not needed, the Execute permissions should not be set to Scripts and Executables. Permissions are at the core of IIS security, but which features and functionality that IIS is running also plays a huge part.

Web Service Extensions

Microsoft intended IIS to be extensible by default. For example, an ISAPI filter (usually a Dll or program file) can be launched to handle specific types of content, or a PHP scripting engine can be added to handle PHP scripts.

When IIS 6 is installed, all web service extensions are disabled (called prohibited). Many built-in web service extensions can be installed and enabled if their functionality is desired. These will be covered below. Web service extensions should only be installed after thoughtful consideration. Each additional web service extension is a potential place for a vulnerability. Now that we have some of the basics covered, let's discuss how to take those same principles to harden IIS against malicious attack.



Professional Windows Desktop and Server Hardening
Professional Windows Desktop and Server Hardening (Programmer to Programmer)
ISBN: 0764599909
EAN: 2147483647
Year: 2004
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net