Security Conversions
There are two aspects to the security of Web sites?the physical access to the files and scripts being accessed by clients and the authentication of those clients to access the information in the first place.
In this section, I'll have a look at two specific areas: the basic permissions systems and how to translate permissions from the Unix and Apache sides over to the Windows and IIS equivalents.
Understanding NTFS/IIS Security
Apache under Unix uses both the underlying permissions on the file system and directory level settings within the Apache configuration to determine which files are served to a particular client. Authentication methods vary, but the standard solutions include basic and digest authentication and extensions provide access to external databases and sources such as LDAP for identification.
Often this difference between the systems can make it difficult to identify and repair security/access problems because the three systems are separate. The underlying filesystem bears no relation to the options within Apache, and the authentication system is not related to the same system used for the underlying filesystem.
IIS also uses a two-tier security system for controlling access to the underlying files using both the NTFS and IIS permissions to determine a user's access to the files in a given folder. However, because of the underlying filesystem (typically NTFS), IIS and the authentication system use the same Active Directory or local (server specific) authentication database for identifying users.
IIS also uses different methods for identifying and handling executable components (scripts, CGI, and so on) and more simplistic elements, such as directory browsing.
All these differences make migrating the settings from Apache to IIS more difficult. To add to the complication, the permissions on files in both the filesystem and IIS are also different. In most editions of Unix, the only system available for controlling access to the files is the user/group/other and read/write/execute model, where you can grant access to files and folders based on the combination of the preceding settings.
Within Windows and IIS, you can specify seven basic permissions, including read, write, and execute, on any user and group in any combination. This is better known as the Access Control List (ACL) method and is supported by some Unix flavors (for example, HP-UX) and some filesystem types, such as Andrew Filesystem (AFS). You can see an example of the access permissions window in Figure 8.5.
Figure 8.5. Access control list settings in Windows.
For example, under Unix you might have a file owned by wwwuser, group ownership is set to wwwgroup with permissions or rw-rw-r--, which provides read/write access to wwwuser and members of the wwwgroup, but with read-only access for everybody else. If I wanted to provide read/write access to another user, I'd have to add him to the group, which could then present problems because he could now be part of a group that also grants him access to other items.
Within Windows and NTFS, I could specifically provide read/write access to both the wwwuser and wwwgroup and read-only access to the Everyone special group, identical to the basic Unix permissions. If I wanted to provide additional access to another user, I would just add him to the access control list. His ability to access the file wouldn't provide him with any additional access or compromise the security of other objects.
MIGRATING ACLS
In most situations, you won't need to migrate access control lists from one platform to another, or indeed use the ACL features when migrating from a standard Unix permissions system, but you should be aware that such a system exists so that you can remove access from users and groups on default.
Translating Unix Permissions to NTFS
Most Unix platforms use a simple user/group/other and read/write/execute combination for setting permissions for a given file or directory. For example, it's possible to set a file as readable by everybody, but writable only by the user and group owner. There are also some specific behaviors?for example, only directories with execute permissions can have their directory contents (list of files/directories) accessed. Finally, the execute permission bit is used on files to identify those that can be executed. If the file is recognized as a binary file, it is executed as a native binary. If it's a text file, the first line is examined to check which application should be used to execute the file.
Windows uses a slightly different model, although the basics remain the same. Files and directories can have read and write permissions, but these are granted explicitly to individual users or groups of users, rather than the owner, group owner, or everybody else. You can also select whether to explicitly allow or deny this ability to this user or group. This model is similar to the Access Control List model used by some Unix variants. There are also specific permissions for listing directory content. There are no execute permissions on files. Windows uses the file extension to determine whether a file is executable, including script files.
The basic rules for translating these settings are as follows:
Read permission on a directory in Unix is the same as Read permission in Windows.
Write permission on a directory in Unix is the same as Write permission in Windows.
Read and Execute permissions on a file in Unix are the same as Read and Execute permission in Windows.
Write permission on a file in Unix is the same as Modify permission in Windows.
Execute permission on a directory in Unix is the same as List Folder Contents permission in Windows.
Read, Write, Execute permissions on a file or directory in Unix is the same as Full Control permission in Windows.
To set the permissions for a file or directory within Windows, follow these steps:
Use Explorer to locate the file or directory that you want to adjust permissions for.
Right-click on the directory and select Properties.
Click Security to change to the security panel.
To add a new access control setting to the directory, click Add. You will be asked to select the Users, Computers, or Groups that this access control setting will be applied to. Select the entries and click Add. Click OK when you have made your selection.
To remove an access control setting, click Remove.
To edit the permissions for any group, select the user or group and then use the corresponding check boxes in the Permissions panel.
Click OK to accept the settings. Click Cancel to cancel any changes you have made. Click Apply to apply the changes without closing the properties window.
Translating Apache Permissions to IIS
Within Apache, it is the underlying permissions of the Unix filesystem and the owner/group that the Apache server is being executed under that affect which objects can be accessed and which scripts can be executed.
Within Windows, IIS effectively executes as the administrator with potential access to any file within the tree of the home directory for a configured Web site. The underlying Windows permissions for a directory or file are ignored. Instead, a separate mechanism within IIS allows you to control and limit the types of access for a given object to clients.
The Read permission in IIS is directly analogous to the Read permission bit for file within Apache/Unix. The Write permission in IIS is used only when using ASP scripts or WebDAV to provide update facilities for a file, and is therefore analogous to the write permission in Apache/Unix for WebDAV only.
Execute permissions in Unix, combined with the AddHandler directive, indicate to Apache that a particular file is a script and should be executed rather than returned as a raw file. In IIS, execute permissions are granted on a Web site or directory basis only?individual files cannot be enabled or disabled as scripts in this way. However, the extension/handler combination does apply. You grant execute permissions for a directory, and then associate an extension with a specific scripting engine.
This has limitations because you cannot use a blanket .cgi extension and rely on the Unix header line to select the corresponding scripting language, which might cause problems during migration. Instead, you must, for example, associate the .pl extension for Perl scripts and .py extension for Python scripts.
Object-Level Security
Security within IIS is configurable on an object-by-object basis?that is, per file, as well as per directory and Web site.
To set the permissions for an object within IIS, follow these steps:
Right-click on the object and select Properties.
If setting the permissions for a Web site's home directory, select the Home Directory panel.
If setting the permissions for a directory within a Web site, select the Directory panel.
If setting the permissions for a file or script within a directory, select the File panel.
Click the corresponding permissions that you want to enable for the object concerned.
To enable script processing for a website or directory, select Scripts Only from the Execute permissions list. To disable script processing, select None.
Click OK to accept the Web site properties.
For more information on how the different permissions work and how they relate to their Apache/Unix equivalents, see "Translating Unix Permissions to NTFS," (p.149) and "Translating Apache Permissions to IIS," (p.150), earlier in this chapter.
Restricting by IP Address or Domain Name
Apache uses the Allow and Deny directives to determine which sites can and can't access a particular Web site or directory. The system provides discretionary access control?you must either deny all sites and provide a specific list of sites or IP addresses that can access a directory, or you allow all sites and deny only those you do not want to have access.
For example,
Deny from all Allow from .domain.com
would deny all clients access unless they were recognized as part of the domain.com domain.
The IIS system works in exactly the same way. All clients are specifically denied or granted access, except for those listed.
To define the access control for a given directory or site, follow these steps:
If you want to limit access for the entire site, select the Web site from the list of different served sites in the panel on the left. If you only want to limit access for a specific directory, choose the directory you want to control.
Right-click on the Web site or directory and select Properties.
Select the Directory Security panel.
If you want to limit access to a specific set of sites but deny it to all others, select Denied Access.
If you want to allow all clients by default but exclude a specific list of clients, select Granted Access.
To update the list of hosts or domains in the Except list, click Add.
To add a single computer to the list, click Single computer. Enter the IP address into the box and click OK.
To add a range of computers within a specific address range, click Group of Computers. Enter the IP address for the network and the subnet mask for the desired network range, and then click OK.
To add computers by their identified domain name, click Domain name. Enter the domain name.
Click Properties to open the Extended Properties dialog box. Enter the domain name and click OK.
Click OK to accept the security settings.
Click OK to close the Properties dialog box.
DOMAIN NAME RESTRICTIONS = OVERHEAD
Using domain name restrictions puts a heavy load on the server because it has to perform a reverse DNS lookup for each request to check the host's registered domain name. Try to use an IP address or network range where possible.
Authentication
If you are using Apache or httpd password files under Apache/Unix or are using the Unix authentication system (/etc/passwd), the user/group information is stored within a simple text file. All users under Windows must be created within the Windows Server 2003 directory, either local on the machine or as part of Active Directory, just as if they were standard users.
TRANSFERRING PASSWORDS
Doing this by hand would be time-consuming. A tool is in the Windows 2000 Resource Kit called AddUsers that will translate slightly modified Unix passwd and group files and transfer them to Active Directory. The same tool should be available for Windows Server 2003, although I haven't been able to confirm this. You can check Microsoft Knowledge Base Article #324222 for more information on this tool. Alternatively, use the Apache Migration Tool from the IIS 6 Resource Kit.
If you have users stored in NIS/NIS+ and you need to migrate them, you must use Services for Unix to perform the migration.
When your users are within the Windows authentication database, you can set authentication for a Web site or folder using the IIS MMC snap-in.
You need to refer to the instructions and guidance in Chapter 3, "Security," (p.39), for more information on the authentication options within IIS 6.
Typically the following rules apply when migrating the settings:
Standard (non-authenticated) access within Apache is equivalent to Anonymous access within IIS 6.
Standard and digest authentication within Apache are equivalent to Basic authentication within IIS 6.
Integrated Windows authentication enables a user logged in with an authenticated account on a Windows client into the site without a password prompt, providing that his account is within the authentication parameters (that is, member of an appropriate account).
Migrating .htaccess Data
Directory level configuration data, such as that supplied through an .htaccess file, is probably the hardest element to reproduce effectively within IIS.
Although IIS includes directory level configuration?as I've already demonstrated?it's not something that is typically available to end users, only administrators.
Some tricks, however, can be applied at a user level. For example, if the user has the ability to control permissions on the folder in which the files for his Web site or Web site directory are located, he can modify the properties. However, setting authentication and other options will have to be handled by an administrator.
Some additional options are often configured through .htaccess, even if they can't be user defined, and are discussed in the sections that follow.
Setting Directory Options
The basic options for a given directory that are normally set by the Apache Options directive are configured in a number of different places.
See "Directory Level Options," p. 142, for more information.
Restricting Access by IP Address
The .htaccess file uses the Order, Allow, and Deny directives to limit access by IP address or domain name. Unfortunately, it is not possible to control this at a user level. To limit by IP address or domain name in IIS, follow the instructions given earlier.
See "Restricting by IP Address or Domain Name," p. 151
Setting Authentication
To set the authentication options for a directory or file, you must first migrate your user's and group's information to your Windows Server 2003 host. Then follow the instructions given earlier in this chapter. Unfortunately, it is not possible to control this at a user level.
See "Authentication," p. 153, for more information.
Redirecting URLs
The .htaccess file uses the Redirect directive to redirect a file or directory to another URL. For example,
Redirect /oldfile.html http://www.domain.com/newdir/newfile.html
I've already described some methods for redirecting requests. For a user-defined solution, you can create a file called Default.asp in the directory where you want to redirect. Then use the Response.Redirect statement within ASP to redirect a request for a particular element. For example, we could rewrite the previous as
Response.Redirect /oldfile.html http://www.domain.com/newdir/newfile.html
You can repeat this as many times as you like to redirect different URLs.
