Home • About • Contact
Login • Page Content • Site Map

Search
GH.com   GH.com dir
Wikipedia   Web

Exploring security issues in IIS.

• Apps
• IIS Administration
• IIS Access Security

Apps

Let us assume that there are three levels of applications: 

• Desktop
• Distributed (on a network)
• Net (Intranet or Internet)

For desktop apps, physical security is dominant. Quite simply: don't let anyone else use your computer.

For distributed apps, three other factors usually apply:

• Users will need to be given network permissions to the access the app or the network resources used by the app.
• The database components compromising the app need to have access rights to the database. This is usually done by making a user account for the app on the DBMS.
• The app can control the user's access. This is usually done by having the user login, and then authenticating the user against data in the database.

Net apps have the same problem as distributed apps. However, net apps must have pretty strong network security. The network security is achieved through the normal mix of routers, gateways, firewalls, etc.

• If an intranet web is part of network A, then network A must only have users from within network A.
• If an Internet Web is part of network A, then network A must allow non-network A users to access only specific parts of network A.

IIS Administration

FPSE (FrontPage Server Extensions) can be administered to IIS on a per site or per sub-site basis. Actually if a "sub-site" has its FPSE removed, then it is no longer a sub-site, but instead has become a directory.

FPSE extends IIS in many ways, including enabling two Microsoft site content development tools, FrontPage and Visual InterDev, to form ACLs (from NT users and groups) of who can browse, author, or administer a web site. 

In FrontPage this is through the Security selection under the Tools menu.

In Visual InterDev this is through the Web Permissions selection under Web Project under the Project menu.

As a side, if Visual InterDev is used in a team development environment, then MS Visual SourceSafe can sort of control content by forcing the checking in and checking out of portions of the site.

IIS Access Security

The Directory tab on the property page of a site or directory can be used to set RWSX- permissions for the site or directory. Here are a few rules of thumbs as to how permissions for different directories should be set:

• All scripts should be set in a directory with -WS-- permissions.
• All executables should be set in a directory with -WSX- permissions.
• All other files should be set in a directory with RW--- permissions.

The Security tab on the property page of site, directory, or file can modify three aspects of security:

1. Anonymous Access and Authentication Control. This establishes how a users name and password are acquired.
2. Secure Communications. This establishes asymmetric encryption of data passed between the item and the client by the use of digital certificates of authenticity that can be purchased from companies like VeriSign.
3. IP Address and Domain Name Restrictions. This sets which IPs or domains can or cannot access the item.

Here are some additional notes on Anonymous Access and Authentication Control:

• Anonymous authentication. This usually allows anyone to access the object having IIS impersonate a user name and password of IUSR_ComputerName on behalf of the user. IUSR_ComputerName and IWAM_ComputerName are NT global user accounts in the security database of the local machine, and are automatically created by IIS upon installation for anonymous users and application owners respectively. IUSR_ComputerName is a member of the NT local Guests group.
• Window NT Challenge/Response authentication, aka NTCR. The resource will invisibly acquire the users user name and password. This will only work if the user has logged on with a Windows NT user name and password, and the browser is MS IE 2 and greater. As such this option is only feasible for intranets. 
• Basic authentication. The resource will ask the user to provide a user name and password. The info will be sent in clear text, thus a hacker could theoretically sniff out the data. This is also good for IIS to access remote machines since IIS would have the client's actual password. (See MSDN for problems with password hash and delegation.) 

If anonymous is not selected but both basic and NTCR are, then NTCR takes precedence.

Once the user name and password is acquired, it is checked against the object's NTFS sharing ACL to see if the user has permissions to the resource. Note that NTFS permissions and the permissions set for sites or directories within IIS are different but simultaneously applied. NTFS partitions allow files and folders to be shared with NT users and groups.

Here are some examples of possible security configurations:

• Internet Web.
  • Select all three authentication methods in the Security tab.
  • For restricted directories, remove IUSR_ComputerName from the ACL and add specific users as needed.
  • Place no restrictions on IPs or domains. You can block IPs or domains as needed later.
• Intranet web.
  • Remove anonymous authentication. For restricted directories, add specific users as needed.
  • If all users have IE 2 and above, then enable NTCR authentication. Otherwise enable both both basic and NTCR authentication.
  • Restrict all IPs or domains except for those on your intranet.

Page Modified: (Hand noted: 2007-11-04 13:26:17Z) (Auto noted: 2007-11-04 13:28:40Z)