When you publish files to your Web directories, you must understand how permissions change when you copy or move files. When you copy files, they always inherit the target directory's permissions. But when you move a file to a new location within the same NTFS volume, the permissions remain the same. When you move a file to a different NTFS volume, the file inherits the destination folder's permissions. So, double-check file permissions after you publish Web content.
Setting Web content files as read-only is a technique that isn't directly related to file permissions but is worth mentioning. Anyone can change these attributes, but doing so will complicate an attack. For example, if intruders can write files but can't execute programs, they can't change the read-only attributes to overwrite or modify existing files.
Because the webroot is such a sensitive area, fully auditing changes to those files and directories is a vital step. Audit all failed access and successful actions except reads. Doing so might lead to larger event logs, but the detailed activity record can be an advantage. I recently gathered evidence for a client after an intruder penetrated the client's internal database and gained access to sensitive customer information. I found evidence that the intruder had placed certain files in the client's Web directories and had later deleted the files. If the client had audited the Web directories, I could have determined exactly when the intruder created and deleted the files and the filenames and user account the intruder used.
The System Root
By default, everyone has full control of the root directory of the system partition, partially because the Windows swap file is created in that directory. If a user logs on and doesn't have full access to the directory, virtual memory operations won't work properly. Because members of the Web Anonymous Users group never actually log on locally to the Web server console, they don't need such liberal permissions to this directory. Give this group read-only permissions on the root directory.
System Executables
Because researching the effects of limited permissions on the thousands of files under the \winnt directory is a huge task, let's look at denying access to specific files that we know can cause problems. Many system executables that are typically used for legitimate purposes can also be used to facilitate attacks on a Web server. Programs such as cmd.exe, tftp.exe, and telnet.exe pose a significant risk if an outsider gains access to these commands. For example, some attacks involve using cmd.exe to run commands on the server, whereas other attacks use tftp.exe to upload files to the Web server. By default, the system has few restrictions on who can execute these programs.
To secure these files, remove all permissions and add only those users who will specifically use the files. For example, you might give only the Administrator account full control of the files and completely deny all other users access. Remember to specifically list the Administrator user, not the Administrators group; the System account is a member of the Administrators group and would therefore inherit that group's permissions.
Program Files
Most applications in the Program Files directory are intended for only local users and administrators and should be appropriately secured. Server applications, such as mail and database servers, and administrative applications, such as backup software, are of special concern. By default, the Users group has Read and Execute access to all Program Files directories. Deny the Web Anonymous Users group access to all these application directories except the Common Files directory, which contains system components that your Web application might need to use and Web applications that use COM components (such as an SMTP mailer).
Prev. page
1
2
[3]
4
next page 
