Protect web servers
Update Date: April 12, 2004
This page
This module Content Target Application Scope How to Use this module Overview Threats and Countermeasures Methods for Web Server Security IIS and .NET Framework Installation Precautions Requirements Make sure to step 1: Patch and Update Step 2: IISLOCKDOWN Step 3 : Service Step 4: Protocol Step 5: Account Step 6: Files and Directory Step 7: Share Step 8: Port Step 9: Registration Table Step 10: Audit and Log Record Step 11: Site and Virtual Directory Step 12: Script Mapping Step 13 : ISAPI Filter Step 14: IIS metadata Base Step 15: Server Certificate Step 16: Machine.config Step 17: Code Access Security Security WEB Server Snapshot Safety Remote Management Simplified and automatically sets security Summary Other resources
This module content
The web server is located at the front end of the host infrastructure. It is directly connected to the Internet, which is responsible for receiving a request from the client, and a dynamic web page is created and responds to the requested data.
A secure web server provides a reliable basis for host environments that plays an important role in the overall security of web applications. But how do I ensure the security of the web server? Make sure one of the security challenges of Web Server is to clarify their goals. Only understand what is safe web server, you can learn how to apply the configuration settings you need for this purpose.
This module provides a systematic and repeatable way you can use it to successfully configure secure web servers. The module also introduces a method of ensuring the security of the web server, which divides the configuration of the server into twelve security zones. Each security area is composed of a series of advanced steps. These steps are modular and introduce the ways to put methods into implementation.
Back to top
aims
Using this module can be implemented:
• Understand what is safe web server. • Use the proven to ensure the Web Server is safe. • Understand the full installation of IIS in Windows 2000 Server by default and .NET Framework installation content. • Understand the service that can be disabled in the secure web server. • Security Configure web servers, including operating system protocols, accounts, files, directory, sharing, port, registry, audit, and logging. • Security Configure Web Server Applications (this example is IIS) component, including web site, virtual directory, scripting mapping, ISAPI filter, metabase, and server certificate. • Security Configuration .NET Framework settings, including Machine.config files, and code access security. • Install and use secure terminal services for remote management. • Understand common countermeasures to resolve common Web server threats (including configuration processing, denial, unauthorized access, free code execution, privilege, viral, worm, and Trojan horse).
Back to top
Scope of application
This module is suitable for the following products and technologies:
• Microsoft Windows Server 2000 and 2003 • Microsoft .NET Framework 1.1 and ASP.NET 1.1 • Microsoft Internet Information Services (IIS) 5.0 and 6.0
Back to top
How to use this module
In order to fully understand the contents of this module, you should:
• Read module 2 threats and countermeasures. This helps you understand the potential threat of web applications more broadly. • Use snapshots. The secure web server snapshot part lists and illustrates the properties of the secure Web server. It reflects input from various sources, including customers, industry experts and internal Microsoft Development and Support Groups. Please refer to the snapshot table when configuring the server. • Use the checklist. This guide "Checklist" section checklist: Protecting the web server provides a printable job help, you can use it as a quick reference. Use task-based checks to quickly evaluate the necessary steps, and then help you gradually complete your steps. • Use the "How to" section. This guide "How" section includes the following guidance articles: • How to use Urlscan • How to: Using Microsoft Benchmark Security Analyzer • How to: Use IISLockDown
Back to top
Overview
What kind of Web server is just right? Make sure one of the security challenges of Web Server is to clarify your goals. Only understand what is safe web server, you can learn how to apply the configuration settings you need for this purpose. This module provides a systematic and repeatable way you can use it to successfully configure secure web servers.
This module first reviews the most common threats affecting the Web server. Then, create a corresponding method using the above views. Finally, the module puts this method into implementation and gradually explains how to improve the security of the web server. Although the basic method can be multiplexed across different technologies, the focus of this module is how to ensure the security of the Microsoft Windows 2000 operating system and resides in Microsoft .NET Framework's Web server.
Back to top
Threat and countermeasure
The web server is often an attack object due to an attacker remote attack. If you understand the threat of the web server and strive to develop the corresponding countermeasures, you can preview a lot of attacks, which prevents increasing attackers.
The main threat to the web server is:
• Configuration Processing • Denial of Service • Unauthorized access • Free code execution • Privileges • Virus, worm and Trojan horse
Figure 16.1 Summarizing current epidemic attacks and common vulnerabilities.
Figure 16.1Web server main threats and common vulnerabilities
Configuration processing
Configuration processing or host enumeration is a probe process for collecting Web site-related information. An attacker can use this information to attack known weak points.
Vulnerability
Cause the server easily configured with the configuration of the attack, including:
• Unnecessary protocol • Opened port • Web server provides configuration information in the banner
attack
Common configuration processing attacks include:
• Port Scan • Ping Sweep • NetBIOS and Server Message Block (SMB) enumeration
Countermeasure
Effective countermeasures have, block all unnecessary ports, block Internet Control Message Protocol (ICMP), disable unnecessary protocols (such as NetBIOS and SMB).
Reject service
If the server is flooded service request, a denial of service attack occurs. The threat at this time is that the web server cannot respond to legitimate client requests due to heavy loads.
Vulnerability
Possible vulnerabilities resulting in denial of service attacks include:
• Weak TCP / IP Stack Configuration • Unpuffed Server
attack
Common denial of service attacks include:
• Network-level SYN FLOOD • Buffer overflow • Using a request from a distributed location to submerge a web server
Countermeasure
Effective countermeasures have, enhance TCP / IP stack, and always apply the latest software patches and updates to system software.
Unauthorized access
If the user has accessed the restricted information or performs a restricted operation, unauthorized access is performed.
Vulnerability
Common vulnerabilities leading to unauthorized access include:
• Weak IIS web access control (including web privileges) • Weak NTFS permissions
Countermeasures Effective Countermeasures, using secure web privileges, NTFS permissions, and .NET Framework access control mechanisms (including URL authorization).
Free code execution
If an attacker runs malicious code in your server or initiates an additional attack downstream system, code execution attack occurs.
Vulnerability
Vulnerabilities that can lead to malicious code include:
• Weak IIS configuration • Unpuffed server
attack
Common code execution attacks include:
• Path traversal • Buffer injection caused by code injection overflow
Countermeasure
Effective countermeasures have, configure IIS reject URLs with ".." (prevent path traversal), use restrictive access control list (ACL) to lock system commands and utilities, install new patches and updates.
Privilege
If an attacker runs code using a privileged process account, privileged attacks appear.
Vulnerability
Common vulnerabilities that cause web servers are privileged to enhance attacks include:
• Excessive Authorization Process Account • Over-Authorized Service Account
Countermeasure
Effective Countermeasures, use the least privileged account running process, use the least privilege of the least privilege and the user account running process.
Virus, worm and Trojan horse
There are several variants of malicious code, including:
• Virus. That is, a malicious operation is performed and the program is caused by an operating system or application interrupt. • Worm. Programs that can be copied and self-maintained. Trojan horse. Users on the surface but actually bring damage.
In many cases, malicious code is exhausted until the system resources are exhausted, and then it is discovered after slowing or termination of other programs. For example, "red code" is one of the notorious worms that endanger IIS, depending on the buffer overflow vulnerability in the ISAPI filter.
Vulnerability
Common vulnerabilities leading to virus, worms, and Troima attack include:
• Unpryled server • Run unnecessary services • Use unnecessary ISAPI filters and extensions
Countermeasure
Effective countermeasures have, prompting the application to install the latest software patches, disable useless features (such as useless ISAPI filters and extensions), using the least privileged account running process to reduce the destruction range when the hazard occurs.
Back to top
Make sure the web server security
To ensure the security of the web server, many configuration settings must be applied to reduce the vulnerability of the server attack. But where is it, when is it? The best way is to classify the precautions that must be taken and the necessary configuration. By classification, you can arrange a protection process from top to the system or select a specific category to complete a specific step.
Configuration category
The safety method of this module is classified into the category shown in Figure 16.2.
Figure 16.2Web Server Configuration Category
The basic principles of classification are as follows:
• Patches and updates Many security threats are caused by extensive release and well-known vulnerabilities. In many cases, if a new vulnerability is found, the probe code that successfully initiated the attack will be announced in the Internet within a few hours. If you do not patch and update the server, you will provide an opportunity for the attacker and malicious code. Therefore, patches and update the server software is the first important step of the protection of the web server. • Services are the most important vulnerability points for the privileges and functions of the capable detection service, and to access the attackers of the local Web server or other downstream servers. If a service is not a web server, do not run it in the server. If the service is required, make sure the service is safe and maintained. Consider monitoring all services to ensure availability. If the service software is not safe, you need this service, try looking for a security service that can replace its. • Agreement avoids the use of unsafe protocols. If you are unable to avoid using these protocols, take appropriate action to provide secure authentication and communication. For example, use IPSec policies. Unsafe plaintext protocols include Telnet, post office protocol (POP3), Simple Mail Transfer Protocol (SMTP), and File Transfer Protocol (FTP). • Account accounts can grant the computers to authenticate access rights and must be reviewed. What is the use of a user account? What kind of access is there? Is there a common account that can be used as an attack target? Whether it belongs to a service account that can be disclosed (and therefore must be included)? Use the least privilege to configure accounts to avoid privileged possibilities. Delete all unwanted accounts. Use a strong password policy to mitigate a powerful attack and dictionary attacks, and then review and alarms the failed login. • File and directory use limited NTFS permissions (only allowing access to the required Windows service and user account) to ensure all files and directory security. Using a Windows auditing detects when suspicious or unauthorized operations. • Sharing All unnecessary file sharing, including default management sharing (if you don't need them). Use limited NTFS permissions to ensure the remaining shared security. Although sharing is not directly displayed in the Internet, if there is a vulnerability, a defensive policy that provides limited and secure sharing can alleviate the risk. • The service running in the port can listen to a specific port to respond to incoming requests. Regular audit servers portable ensuring that unsecure or unnecessary services cannot be activated in your web server. If the active port is detected, it is not an administrator to open, indicating that there must be unauthorized access and security vulnerabilities. • Many of the registry are saved in the registry, so the registry must be protected. You can apply limited Windows ACLs and block remote registry management to do this. • Audit and logging review is an important tool that is the main role is to determine the invader, in progress, the evidence of the attack has occurred. Please configure the review of the web server in connection with Windows and IIS audits. Event logs and system logs help you solve security issues. • Site and virtual directory sites and virtual directory are shown directly in the Internet. Although secure firewall configuration and defense ISAPI filters (such as URLSCANs, such as IISLOCKDOWN tools) prevent requests for restricted configuration files or programs, but it is recommended that you use deep defense strategies. Re-assign the site and virtual directory to the non-system partition, then use IIS web privileges to further restrict access. • Script Mapping If all unnecessary IIS scripts that delete an optional file extension, prevent attackers from using any bugs in the ISAPI extension that handles these file types. The unused extension maps are often ignored, and they are representative of major security vulnerabilities. • ISAPI Filter attackers have successfully utilized vulnerabilities in the ISAPI filter. Remove unnecessary ISAPI filters from the web server. • IIS metadata IIS metadata can maintain IIS configuration settings.
You must ensure proper configuration and security-related settings to ensure that the metadfuse file is used to use the enhanced NTFS permission. • The machine.configmachine.config file saves the computer-level configuration settings that are applied to the .NET Framework application (including ASP.NET Web applications). Modifying settings in Machine.Config ensures that secure default values are applied to all ASP.NET applications installed in the server. • Code Access Security Restriction Code Access Security Policy Settings Make sure that the code downloaded from the Internet or intranet is no permissions, so it is not possible. Back to top
IIS and .NET Framework installation considerations
Before ensuring the Web Server Security, you must first know the components that appear in the Windows 2000 server after installing IIS and .NET Framework. This section describes which components are installed.
What components have IIS installed?
IIS has a lot of services, accounts, folders, and web sites. Some components are not used by web applications. If you are not deleted in the server, it may cause the server to be vulnerable. Table 16.1 lists the services, accounts, and folders created after the IIS (selected all components) in the Windows 2000 Server system.
Table 16.1: IIS installation default value
Item Details defaults service IIS Admin Service (managing Web and FTP services) World Wide Web Publishing ServiceFTP Publishing ServiceSimple Mail Transport Protocol (SMTP) Network News Transport Protocol (NNTP) Installation installation installing account and the group IUSR_MACHINE (anonymous Internet users) IWAM_MACHINE (Process ASP web application; no ASP.NET application running in the ASP.NET application; your web server should not be a domain controller) Add to Guest group to Guest Group Folder% WINDIR% / System32 / INETSRV (IIS Program File)% WINDIR% / System32 / IneTSRV / IISADMIN (for remote management IIS)% WINDIR% / HELP / IISHELP (IIS Help File)% SystemDrive% / INETPUB (Web, FTP and SMTP Root Folders) Web Site Default Web Site - Port 80:% SystemDrive% / INETPUB / WWWROOT Management Web Site - Port 3693:% SystemDrive% / System32 / InetSrv / Iisadmin Allow anonymous access to local computers and Administrator
What components have .NET Framework installed?
If you install .NET Framework, .NET Framework, .NET Framework will register asp.net. As part of this process, the system will create a local account that is a privilege called ASPNET. This will run the ASP.NET_WP.exe and Session Status Services (ASPNET_STATE.exe), which can be used to manage user session status.
Note: In Server computers running Windows 2000 and IIS 5.0, all ASP.NET web applications run in a single instance of the ASP.NET work process, which is isolated by the application domain. In Windows Server 2003, IIS 6.0 provides process level isolation by using the application pool. Table 16.2 Displaying the .NET Framework version 1.1 default installation service, account, and folder.
Table 16.2: .NET Framework installation default value
Project Details Default Service ASP.NET State Service: Provides processes for processes for processes for ASP.NET. Manually start the account and group ASPNET: The account running the ASP.NET Job Process (ASPNET_WP.exe) and Session Status Service (ASPNET_STATE.EXE) account. Add to the User Group Folder% Windir% / Microsoft.Net / Framework / {Version} / 1033 /ASP.NetClientFiles/config / MUI / TEMPORARY ASP.NET FILES ISAPI Extension ASPNET_ISAPI.DLL: Processing an ASP.NET file type request. Reverse the request to the ASP.NET work process (ASPNET_WP.EXE). ISAPI Filter ASPNET_FILTER.DLL: Only for a session state without cookies. Run in the inetinfo.exe (IIS) process. Applications Mapping Asax, ASCX, ASHX, ASPX, AXD, VDISCO, REM, SOAP, CONFIG, CS, CSPROJ, VB, VBPROJ, WebInfo, Licx, Resx, Resources /Winnt/Microsoft.Net/framework/ {Version} ASPNET_ISAPI. DLL
Back to top
Installation advice
By default, the Windows 2000 Server installer will install IIS. However, it is recommended not to install IIS as part of the operating system installation, preferably update in the future and patches the basic operating system and then install. After installing IIS, you must re-apply the IIS patch and enhance the IIS configuration to ensure that IIS accepts complete protection. Only in this way is safe to connect the server to the network.
IIS installation advice
If you want to install and configure a new web server, perform the following steps overview.
• Build a new web server
1. Install Windows 2000 Server, but IIS is not part of the operating system installation. 2. Apply the latest service packs and patches to the operating system. (If you want to configure multiple servers, see "In the Basic Installation, including Service Pack" behind this section.) 3. Install IIS separately using the Add / Remove Programs in the Control Panel. If you don't need the following services, do not install them when installing IIS:
• File Transfer Protocol (FTP) Server • Microsoft FrontPage® 2000 Server Extensions • Internet Service Manager (HTML) • NNTP Services • SMTP Services • Visual InterDev RAD Remote Deployment Support Note: Installing in a fully puffed and updated operating system IIS, prevents attacks from using a patched existing vulnerability (such as NIMDA).
.NET Framework installation advice
Do not install the .NET Framework Software Development Kit (SDK) in the production server. The SDK contains many utilities that are not required for many servers. Once an attacker gets access to the server, you can use some of these tools to help initiate additional attacks.
The correct approach is to install re-distributed packages. To get the package, you can access the .NET Framework site of Microsoft.com, whose URL is http://www.microsoft.com/china/net/, click the Downloads link. In the basic installation include Service Pack
If you want to build multiple servers, you can enter your service pack directly into your Windows installation. Service Pack includes a program called Update.exe, which is combined with your WINDOWS installation file.
• To combine the service pack with the Windows installation, do the following:
1. Download the latest service pack. 2. Start the service pack installer from the -X option, extract Update.exe from the Service Pack, as shown below: W3Ksp3.exe -x 3. Integrate Service Pack with Windows Installation Source, the method is to run Update using the -s option. EXE (Passing Windows Installed Folder Path) as follows: Update.exe -sc: / YourWindowsInstallationsource
For more information, see MSDN Article "Customizing Unattended Win2k Installations", URL is http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2kmag01/html/customsTall.asp English).
Back to top
Ensure steps to secure the Web server
The following sections will guide you to complete the process of protecting the web server. These content use this module to ensure the configuration category described in the method of Web Server Security. Each advance step contains one or more operations that make sure a specific area or functionality.
Step 1 Patch and Update Procedure Step 10 Audit and Logging Step 2 IISLOCKDOWN Step 11 Site and Virtual Directory Step 3 Services Step 12 Script Mapping Step 4 Protocol Step 13 IIS Pixabay Filter Step 5 Account Step 14 IIS Database Step 6 Files Step 15 Server Certificate Step 7 Sharing Step 16 Machine.config Step 8 Port Step 17 Code Access Security Step 9 Registry
Back to top
Step 1: Patch and update
Update the server with the latest service packs and patch. All Web server components must be updated and picked, including Windows 2000 (and IIS) ,. Net Framework, and Microsoft Data Access Components (MDAC).
In this step, you have to do the following:
• Detect and install the required patches and updates. • Update .NET Framework.
Detect and install the patches and updates
Use the Microsoft Benchmark Security Analyzer (MBSA) to detect patchs and updates that may be missing in the current installation. MBSA will compare your installation with the currently available update list maintained in an XML file. You can download the XML file when scanning the server, or manually download the XML file to the server, or save it in the web server.
• Detect and install the patch and update
1. Download and install MBSA. To do this, you can access the MBSA home page Microsoft Boundation Security Analyzer. If you can't access the Internet when running MBSA, MBSA will not be able to retrieve the XML file containing the latest security settings of Microsoft. You can use another computer to download the XML file. Then, copy it to the MBSA program directory. The XML file can be downloaded from http://download/xml/security/download/xml/security/1.0/nt5/en-us/mssecure.cab. 2. Double-click the desktop icon (or select "MBSA" from "Programs" menu) to run MBSA. 3. Click Scan A Computer to scan your computer. By default, MBSA will scan local computers. 4. Uncheck all check boxes, except "Check for Security Updates" (check security updates). This option detects missing patches and updates. 5. Click Start Scan to start scanning. At this point, your server will analyze your server. After completing the scan, MBSA will display a security report and write the report to the% UserProfile% / SecurityScans directory. 6. Download and install the missing update. Click on the "Result Details" link next to each failure check to view the missing security update. The result will appear a dialog box for Microsoft Security Reference Number. Click the reference number to learn more about check information and download the update. For more information on using MBSA, see how this guide "How" section: Use the Microsoft Boundary Security Analyzer. Update .NET Framework
When writing this guide (May 2003), MBSA could not detect the update program and patch of the .NET Framework. Therefore, you must manually detect the update of the .NET Framework.
• Manually update .NET Framework version 1.0
1. Determine which version of the .NET Framework Service Pack for your web server to install. To do this, see Microsoft Knowledge Base Article 318785 Info: Determining WHether Service Packs Are Installed on The .NET Framework. 2. Compare the installed .NET Framework version with the current Service Pack. To do this, use Microsoft Knowledge Base Article 318836 Info: How To Obtain The .NET Framework version listed in the Latest .NET Framework Service Pack.
Back to top
Step 2: IISLOCKDOWN
IISLOCKDOWN Tools help you perform certain security steps. This tool greatly reduces a lot of vulnerabilities in the Windows 2000 web server. You can choose a specific type of server role and then use a custom template to increase the security of this particular server. These templates or disables different features, or protect different features. In addition, IISLOCKDOWN has also installed URLSCAN ISAPI filters. Urlscan allows Web site administrators to restrict the type of HTTP request that the server can process based on a set of yourself-controlled rules. By blocking a specific HTTP request, the URLSCAN filter prevents the possible detrimental request to arrive in the server and therefore causes damage.
In this step, you have to do the following:
• Install and run IISLOCKDOWN. • Install and configure URLScan. Install and run IISLOCKDOWN
IISLOCKDOWN can be downloaded through the Microsoft website, the URL is http://download/iis50/utility/2.1/nt45xp/en-us/iislockd.exe (English).
Save IISLOCKD.EXE in the local folder. IISLOCKD.EXE is the IISLOCKDOWN wizard, it is not an installer. Any changes to IISLockDown can be revoked by running IISLOCKD.EXE again.
If you want to lock the Windows 2000-based computer resident ASP.NET page, select the Dynamic Web Server Template when you appear IISLockDown tools. Once the "Dynamic Web" server is selected, IISLOCKDOWN will do the following:
• Disable Unsafe Internet services:
• File Transfer Protocol (FTP) • Email Service (SMTP) • News Services (NNTP) • Map the following file extension to 404.DLL to disable script mapping:
• Index Server • Web Interface (.idq, .htw, .ida) • The server side contains files (.shtml, .shtm ,.stm) • Internet Data Connector (.IDC) • .htr script (.htr), Internet Print (.printer) • Delete the following virtual directory: IIS Samples, Msadc, Iishelp, Scripts, and Iisadmin. • Restrict anonymous access system utilities, limit the permissions that use web permissions to write to the Web Content Directory. • Disable Web Distributed Creative and Version Control (WebDAV). • Install URLSCAN ISAPI filter.
Note: Do not use a static web server template if you do not use traditional ASPs. This template deletes the basic features necessary for the ASP.NET page, such as the post command.
Log file
The IISLOCKDOWN Tool will create the following two reports listing the applicable changes:
•% windir% / system32 / inetsrv / oblt-rep.log: which contains advanced information. •% Windir% / System32 / IneTSRV / OBLT-LOG.LOG: which contains low-level details, such as which program files are configured with the Deny Access Control (ACE) (to prevent anonymous Internet user accounts). The log file can also be used to support the "Undo Change" feature of IISLockDown.
Web Anonymous Users Group and Web Application Group
IISLOCKDOWN Tools will create a web anonymous user group and a Web Application group. The Web Anonymous users group contains IUSR_MACHINE accounts. The Web Application group contains the IWAM_MACHINE account. Various permissions are allocated to the system tools and content catalogs based on these groups, not directly assigned to IUSR and IWAM accounts. Specific permissions can be checked by viewing IISLOCKDOWN Log% WINDIR% / System32 / IneTsrv / Oblt-Log.log.
404.dll
The IISLOCKDOWN tool will install 404.DLL to map the client to the file extension. For more information, see Step 12: Script mapping.
Urlscan
If you install a URLSCAN ISAPI filter as part of IISLockDown, the URLSCAN settings are integrated with the selected server role when the IISLockDown tool is run. For example, if a static web server is selected, the URLSCAN will block the post command. Undo ISLOCKDOWN changes
To undo the changes to IISLOCKDOWN, run IISLOCKD.EXE again. This will not delete the URLSCAN ISAPI filter. For more information, see "How to Use: Use the Urlscan" section of this guide "" Delete Urlscan ".
other information
For more information on IISLOCKDOWN Tools, see the following article:
• For more information on running IISLOCKDOWN, see how to "How" in this guide: Use IISLOCKDOWN.EXE. • For IISLOCKDOWN troubleshooting, see Microsoft Knowledge Base Article 325864 How To: Install and Use The IIS Lockdown Wizard. (The most common problem is: After running IISLockDown, you receive an unexpected "404 file not found" error message.) • For information on automatic run IISLOCKDOWN, see Microsoft Knowledge Base Article 310725 How To: Run The IIS Lockdown Wizard Unattended IIS (English).
Install and configure urlscan
Urlscan is installed when you run the IISLOCKDOWN tool, although you can download and install it separately.
• To install URLScan without running IISLOCKDOWN, do the following:
1. Download IISLOCKD.EXE, the URL is http://download/iis50/utility/2.1/nt45xp/en-us/iislockd.exe (English). 2. Run the following command to extract the URLSCAN installer: IISLOCKD.EXE / Q / C
Urlscan blocks requests that contain unsafe characters (eg, like using ".." character traversal directory). Urlscan can record requests that contain these characters in the% windir% / system32 / inetsrv / urlscan directory.
You can configure URLSCAN using .ini file% windir% / system32 / inetsrv / urlscan / urlscan.ini.
In addition to preventing malicious requests, you can also prevent the server from being denialful service attacks before the request arrives in ASP.NET. To do this, set limitations in the maxallowedcontentLENGTH, MAXURL and MAXQUERYSTRINGTH, MAXURL, and MaxQueryString parameters of the Urlscan.ini file. For more information, see how this guide "How" section: use Urlscan.
Changes to URLSCAN
Delete urlscan has no automatic operation. If you encounter problems when using Urlscan, you can delete URLSCAN from IIS, or will record the rejected request for analysis. To do this, use the option rejectResponseURL = / ~ * in the Urlscan .ini file.
For more information on how to delete the ISAPI filter, see Step 13: ISAPI Filters in this module.
other information
For more information on the URLSCAN tool, see the following article: • For information on running Urlscan, see how "How to" section of this guide: Use Urlscan. • For information on URLSCAN configuration and URLSCAN.INI file settings, see Microsoft Knowledge Base Article 326444 How To: Configure The Urlscan Tool (English).
Back to top
Step 3: Services
The services that do not authenticate the client, using unsafe protocols, or too many services that are privileged will bring risks. If you don't need these services, please don't run them. By disabling unnecessary services, you can quickly easily reduce the attack surface. Moreover, you can also reduce the overhead of maintenance (patches, service accounts, etc.).
If you want to run a service, make sure it is safe and has certain maintenance. To do this, use the least privileged account to run the service and then keep the service up to date by applying the patch.
In this step, you have to do the following:
• Disable unnecessary services. • Disable FTP, SMTP, and NNTP (unless you need). • Disable ASP.NET State Service (unless you need).
Disable unnecessary service
Faced with attackers who try to detect service privileges and functions to obtain local and remote system resource access, Windows services are relatively fragile. As a defense measure, disable the Windows services that are unnecessary for systems and applications. You can use the "Services" MMC management unit in the Administrative Tools program to disable Windows services.
Note: Before disabling an item, make sure you first test your impact in the test environment or temporary environment.
In most cases, the web server does not require the following default Windows services: Alerter, Browser, Messenger, Netlogon (required only in the domain controller), Simple TCP / IP Services and Spooler.
The Telnet service is installed with Windows but is disabled by default. IIS administrators generally enable Telnet. But it is indeed an easy to detect unsafe protocol. Terminal services provide safer remote management. For more information on remote management, see Remote Management behind this module.
Disable FTP, SMTP and NNTP (unless you need)
FTP, SMTP and NNTP are often abuse of unsafe protocols. If you don't need these services, please don't run them. If you are currently running, try to find a safe alternative service. If you must run, make sure it is safe.
Note: IIS LockDown provides all options for disabling FTP, SMTP, and NNTP.
To eliminate the possibility of FTP being detected, disable the FTP service (if not using it). If FTP is enabled, and an attacker can use FTP to upload files and tools from an attacker's remote system to the web server. Once these tools and files are located in your web server, the attacker can attack the web server or other connected systems.
If the FTP protocol is used, the username and password of the FTP site are accessed, and the data transmitted is not encoded or encrypted. IIS does not support SSL of FTP. If secure communication is very important, you use FTP as a transfer protocol (rather than using SSL's World Wide Web Distributed Creative and Version Control (WebDAV), consider the encrypted channel (such as using point-to-point Tunneling Protocol (PPTP) or Internet Protocol Security (IPSEC) Protection Virtual Dedicated Network (VPN)) uses FTP.
Disabling ASP.NET State Service (unless you need) .NET Framework installed ASP.NET STATE Service (ASPNET_STATE.EXE) to manage ASP.NET web applications and web services processes outside user sessions. By default, the service is manually started and runs with a local ASPNET account with a minimum privilege. If your application does not use the service saved, disable it. For more information on ensuring ASP.NET session status, see Module 19 Make sure that "session status" in the security of the ASP.NET application and Web services.
Back to top
Step 4: Agreement
Avoid using unnecessary protocols to reduce the possibility of attacking attacks. .NET Framework provides granularity control of the protocol through the settings in the machine.config file. For example, you can control whether Web services use HTTP GET, POST or SOAP. For more information on configuring protocols in a Machine.config file, see Step 16: Machine.config.
In this step, you have to do the following:
• Disable or protect WebDAV. • Enhance TCP / IP stack. • Disable NetBIOS and SMB.
Disable or protect WebDAV
IIS supports the WebDAV protocol, which is the standard extension of HTTP 1.1 for publishing collaboration. If this protocol is not used, disable it in the production server.
Note: IISLOCKDOWN provides options that delete WebDAV support.
From a security perspective, WebDAV is more desirable than FTP, but you must ensure that WebDAV is safe. For more information, see Microsoft Knowledge Base Article 323470 How To: Create A Secure WebDAV Publishing Directory.
If you don't need WebDAV, see Microsoft Knowledge Base Article 241520 How To: Disable WebDAV for IIS 5.0 (English).
Strengthen TCP / IP stack
Windows 2000 supports granular control of the parameters implemented for many configuration TCP / IP. Some of these default settings provide server availability and other specific features.
For information on how to strengthen TCP / IP stack, see how this guide "How" section: Enhance TCP / IP stack.
Disable NetBIOS and SMB
Disable all unnecessary protocols, including NetBIOS and SMB. The web server (NIC) is not required to NetBIOS or SMB. Disabling these protocols can fight against host enumeration.
Note: The SMB protocol can return a large number of computer information to an unauthenticated user through an empty session. You can block empty sessions, the method is to set the restrictanonymous registry key, see Step 9: Registry.
Disable NetBIOS
NetBIOS uses the following ports:
• TCP and User Dataset Protocol (UDP) Port 137 (NetBIOS Name Service) • TCP and UDP Port 138 (NetBIOS Datashers) • TCP and UDP Port 139 (NetBIOS Session Service)
To disable SMB communication, only NetBIOs is not enough. The reason is: If the standard NetBIOS port is not available, the SMB will use the TCP port 445. (This port is called "SMB direct host".) Therefore, you must disable NetBIOS and SMB, respectively.
• Disable TCP / IP NetBIOS Note: This process will disable the NBT.sys driver and request to restart the system.
1. Right click on "My Computer" on the desktop, and then click Manage. 2. Expand System Tools, select Device Manager. 3. Right-click Device Manager, point to View, and then click Show Hide Devices. 4. Expand "Unsettled Drivers". 5. Right-click "NetBIOS over TCPIP" and click Disable. This will disable the NetBIOS direct host listener in TCP 445 and UDP 445.
Disable SMB
SMB uses the following ports:
• TCP port 139 • TCP port 445
To disable the SMB, use the TCP / IP Properties dialog box in the Local Connection property to release the SMB and the binding of the port to the Internet.
• To unlock the SMB with the binding of the port-oriented port, do the following:
1. Click the Start menu, point to Setup, and then click Network and Dial-up. 2. Right-click the connection to the Internet and click Properties. 3. Clear the "Microsoft Network Client" box. 4. Clear the "File and Printer Sharing" box of the Microsoft Network.
Note: The "WINS" tab of the Advanced TCP / IP Settings dialog contains a "NetBIOS" radio button on TCP / IP. Select this option to disable the NetBIOS session service using TCP port 139, which does not completely disable SMB. To do this, please use the above process.
Back to top
Step 5: Account
Unused accounts must be deleted because attackers may discover these accounts and utilize. Strong password must be used. The weak password adds the success of a strong attack or a dictionary attack. Use least privileges. An attacker can use more privileged accounts to access unauthorized resources.
In this step, you have to do the following:
• Delete or disable unused accounts. • Disable the guest account. • Rename the Administrator account. • Disable the IUSR account. • Create a custom anonymous web account. • Force strong password strategy. • Restrict remote login. • Disable empty sessions (anonymous login).
Delete or disable unused accounts
An attacker can use unused accounts and their permissions to access the access server. Audit the local account in the server and disable those unused accounts. If you disable your account does not create any problems, remove the account. (The deleted account is unable to recover.) Before disabling the account in the production server, disable these accounts in the test server. Ensure that the disabled account will not have a negative impact on the application operation.
Note: The Administrator account and guest account cannot be deleted.
Disabate GUEST account
The Guest account is used when the user is anonymous to connect to a computer. To limit the anonymous connection of your computer, disable the account. By default, Windows 2000 systems disable guest accounts. To check if it is enabled, view the User folder in the Computer Management tool. Where the guest account should have a fork icon. If it is not disabled, the Properties dialog box is displayed, and then "Account has been discontinued".
Rename the Administrator account
The default local Administrator account is often the target utilization of attackers due to high computer control permissions. To enhance security, rename the default Administrator account and set strong passwords.
If you plan to perform local management, configure this account to reject network login permissions and ask an administrator to log in in interactive. This will prevent users from using the Administrator account to log in from the remote location from the remote location. If the local management strategy is not flexible, implement a secure remote management solution. For more information, see Remote Management behind this module. Disable IUSR account
Disable default anonymous Internet user account IUSR_MACHINE. This account is created during the IIS installation process. When installing IIS, the server's NetBIOS name is Machine.
Create a custom anonymous web account
If the application supports anonymous access (for example, when a custom authentication mechanism using a table single authentication), create a custom, privileged anonymous account. If you are running IISLOCKDOWN, add a custom user to the created Web Anonymous users group. IISLOCKDOWN refuses to access the system utility and refuses to write to the web content directory of the Web Anonymous users group.
If you want to reside multiple web applications in the web server, you may want to use multiple anonymous accounts (one for each application) to separately protect and review the operation of each application.
For more information on multiple web applications, see Modules 20 Resident Multiple web applications.
Forced strong password strategy
In order to confirm the attacker's password guess and strong dictionary attack, please apply a strong password policy. To force a strong password policy, do the following:
• Set the password length and complexity. Make strong passwords to reduce the threat of password guess or dictionary attacks. The strong password consists of eight or more characters, and there must be both letters and numbers. • Set the password expiration time. Regular expiration passwords can reduce the possibility of an old password being unauthorized access utilization. Typically, expiration frequencies follow the company's security strategy.
Table 16.3 lists the default and suggested password policy settings.
Table 16.3: Default settings and suggestions for password policies
Password Policy Default Settings Recommendation Minimum Setting Force Password History 1 memory password. 24 remembered passwords. Password longest use deadline 42 days 42 days password shortest use deadline 0 days 2 days shortest password length 0 characters 8 characters password must meet complexity requirements. Disable Enableable encryption to store passwords (for all users in the domain). Disable disable
In addition, login attempts to record can detect and track malicious behaviors. For more information, see Step 10: Audit and Logging.
Limit remote login
Remove the "Accessing this computer" privilege from the EVERYONE group, limit users who can remotely log in to the server.
Disable empty session (anonymous login)
In order to prevent anonymous access, disable empty sessions. These sessions are unauthenticated sessions or anonymous sessions established between two computers. An attacker can connect anonymity (without authentication) unless disabled.
Once an attacker has established an empty conversation, he (or her) can implement various attacks, including the use of enumeration techniques to collect information related to the system in the target computer (this greatly helps the attacker launched a follow-up attack). The information type returned by empty session includes domain, trust details, sharing, user information, including group and user rights), registry item, and so on.
If the "RestrictAnonymous" is set to "1" at the following subkey of the registry, you can limit empty sessions:
HKLM / System / CurrentControlSet / Control / LSA / Restrictanonymous = 1
For more information, see Microsoft Knowledge Base Article 246261 How To: Use The Restrictanonymous Registry Value in Windows 2000 (English). Other considerations
Below is a list of other steps to further improve the security of Web Server:
• Require the approval account delegation. Do not mark the domain accounts in Active Directory as trusted (unless the first approval is obtained). • Do not use shared accounts. Don't create an account for multiplayer sharing. Get an authorized person must have its own account. Personal operations can be reviewed separately and assign the corresponding group membership and privileges. • Limit local administrators group membership. Try to limit the management account in two. This helps to strengthen responsibility. In addition, the password is not shared (it is also for responsibility). • Require Administrator to log in to interactively. If only local management is implemented, the Administrator account can be required to log in to interactively, and the method is to delete "Access this computer from the network" privilege.
Back to top
Step 6: Files and directories
Installing Windows 2000 in the NTFS file system partition helps to limit access by using NTFS permissions. Use powerful access control ensures that the files and directories are not attacked. In most cases, the license access to a specific account is more efficient than the rejection access to a specific account. Please set access to the directory level as possible. Once the file is added to the folder, the corresponding permissions of the folder are inherited, so you don't have to complete any settings.
In this step, you have to do the following:
• Limit the EveryOne group. • Limit an anonymous web account. • Protect or delete tools, utilities, and SDK. • Delete sample files.
Limit the Everyone group
The default NTFS permission for Windows 2000 can grant the EVERYONE group member fully controls the permissions of many critical locations (including root directory, / inetpub, and / inetpub / scripts).
First, a full control permission of the root directory (/) is granted to the Administrator account and then delete access permissions from the Everyone group from the following directory.
• Root Catalog (/) • System Directory (/ WinNT / System32) • Framework Tool Directory (/Winnt/Microsoft.Net/framework/ {version}) • Web site root root directory and all content directories (default is / inetpub / * )
Restriction access IIS anonymous account
An anonymous account is well known. An attacker can use this well-known account to perform malicious operations. To ensure the security of an anonymous account, do the following:
• Refuse to write access to the web content directory. Make sure the account cannot be written to the content directory (for example, to destroy the website). • Restrict access to system tools. In particular, the access to the command line tool in / Winnt / System 32 is restricted. • Assign permissions to groups instead of separate accounts. A preferred approach is to assign users to groups and apply permissions to groups and not separate accounts. For an anonymous account, create a group and add an anonymous account to the group, and explicitly reject the group to access the key directory and files. By assigning permissions to groups, you can easily change an anonymous accounts or create additional anonymous accounts (because you don't have to recreate these permissions). Note: IISLOCKDOWN refuses to write access to the content directory by applying the Refused Write Control Item (ACE) to Web Anonymous Users and Web Applications groups. In addition, it also adds refusing to execute ACLs in the command line tool. • Use different accounts in different applications. If you want to reside multiple applications in the web server, use different anonymous accounts in each application. Add an account to an anonymous web user group, such as the web anonymous user group created by IISLockDown, and then use the group to configure NTFS permissions. For more information on using multiple anonymous accounts and resident multiple applications, see Modules 20 Resident Multiple ASP.NET applications. Protect or delete tools, utilities and SDK
The SDK and Resource Kit should not be installed in the web production server. If you exist, remove it.
• Make sure that only the .NET Framework can be resembled in the server without installing any SDK utility. Do not install Visual Studio .NET in the production server. • Ensure that access to powerful system tools and utilities (such as system tools and utilities in / program files directory) have certain restrictions. This can be done using IISLockDown. • The debugging tool should not be available in the web server. If you must perform production and debug, you should create a CD that contains the necessary debugging tools.
Delete sample file
Typically, sample applications are not configured with higher levels of security settings. An attacker is likely to use the example application or the vulnerability to configure itself to attack your Web site. Deleting an example application reduces the area of affected Web servers.
Other considerations
In addition, consider deleting unnecessary data source name (DSN). These data sources include applying a clear text connection details for connecting OLE DB data sources. Only the required DSN required for the web application should be installed in the web server.
Back to top
Step 7: Sharing
Delete all unused shares and then enhance the required share of NTFS permissions. By default, all users have permissions that fully control the newly created file shared. Enhance these default permissions ensures that only authorized users can access files in the shared. In addition to obvious sharing rights, NTFS ACLs can also be used to share files and folders in sharing.
In this step, you have to do the following:
• Delete unnecessary shares. • Restrict access to the desired shared.
Delete unnecessary sharing
Delete all unnecessary shares. To view shared and associated permissions, run the Computer Management MMC snap-in, then select "Share" in Share Folders, as shown in Figure 16.3.
Figure 16.3 "Computer Management" MMC Management Unit Shared
Restrict access to required sharing
Delete the Everyone group and grant specific permissions. If you do not limit accessible users, use everyone.
Other considerations
If the remote management server is not allowed, delete unused management sharing, such as "C $" and "Admin $".
Note: Some applications may require management sharing. For example, Microsoft Systems Management Server (SMS), and Microsoft Operations Manager (MOM). For more information, see Microsoft Knowledge Base Article 318751 How To: Remove Administrative Sharees in Windows 2000 or Windows NT 4.0 (English). Back to top
Step 8: Port
The service running in the server will use a specific port to provide services for incoming requests. Turn off all unnecessary ports, then perform a regular auditing to detect a new port in the listening state (these port points out unauthorized access and security vulnerabilities).
In this step, you have to do the following:
• Limited the port-oriented port to TCP 80 and 443. • Encrypt or restrict intranet communication.
Limited the port to the Internet to TCP 80 and 443
The outbound communication uses port 80 (for http) and port 443 (for HTTPS (SSL)).
For the outlet (for Internet) NIC, use IPSec or TCP screening. For more information, see how this guide "How" section: use IPSec.
Encrypt or restrict intranet communication
For internal (facing intranet) NIC, if you don't have a secure data center, you have to deliver sensitive information between computers, you must consider encrypted communication, or limit web servers and downstream servers (such as application servers or database servers). Communication. Encrypted network communication can solve the threat of network eavesdropping. If the risk is considered small, you can choose not to encrypt the communication.
The encryption type used will also affect the type of threat to be resolved. For example, SSL is an application level encryption, and IPSec is a transport layer encryption. Therefore, SSL can counter data tamper or information leakage threat from the other process of the same computer, especially the process that runs with different accounts (compared to the network eavesdropped account).
Back to top
Step 9: Registration
The registry is a repository for many important servers configured. Therefore, you must ensure that only authorized administrators can access it. If an attacker can edit the registry, he (or her) can reconfigure your server and then destroy its security.
In this step, you have to do the following:
• Restrictions to remotely manage the registry. • Make sure SAM secure (stand-alone server only).
Restrict remote management for the registry
The WinReg key can determine if the registry key can be used for remote access. By default, the key prevents users from remotely viewing most of the registry, only high privileges can modify it. In Windows 2000, remote registry access is limited by default to members of the Administrators and Backup Operators groups. The administrator has full control permissions, and the backup operator has read-only access.
The relevant permissions of the following registry locations determine those who can access the registry remotely.
HKLM / System / CurrentControlSet / Control / SecurePipeServers / WinReg
To view the permissions of the registry key, run regedt32.exe, find the key, then select "Permissions" from the Security menu.
Note: Some services require remote access to the registry. Please refer to Microsoft Knowledge Base Article 153183 How To Restrict Access To The Registry from A Remote Computer (English), know if your situation is to restrict remote access to the registry. Make sure SAM security (stand-alone server only)
The standalone server can save an account name and a one-way (irreversible) password hash value (LMHASH) in the Local Security Account Manager (SAM) database. SAM is part of the registry. Typically, only members of the Administrators group can access account information.
Although the password is actually not saved in SAM, the password hash value is not reversible, but if an attacker gets a copy of the SAM database, the attacker can use strong password technology to obtain a valid username and password.
By creating a key (not value) nolmhash in the registry, the LMHASH is stored in SAM, as shown below:
HKLM / System / CurrentControlSet / Control / LSA / NOLMHASH
For more information, see Microsoft Knowledge Base Article 299656 How To Prevent Windows from Storing A Lan Manager Hash of Your Password In Active Directory and Local Sam Databases.
Back to top
Step 10: Audit and logging
The audit process cannot prevent system attacks, but it is an important aid for clarifying the invaders and attacks in progress, and can help you diagnose the attack trail. Enable the minimum audit in the web server, then use the NTFS permission to protect the log files, ensure that the attacker cannot delete or update the log file with any way to achieve the purpose of covering the trace. Use the IIS W3C extended log file format review.
In this step, you have to do the following:
• Record all failed login attempts. • Record all failed operations in the file system. • Relocate and protect the IIS log file. • Archive log files supply offline analysis. • Audit Access to Metabase.bin files.
Record all failed login attempts
Only login attempts that fail to fail can detect and track suspicious behaviors.
• To review the failed login attempt, do the following:
1. Start the local security policy tool from the Administrative Tools program. 2. Expand "Local Policy", then select "Audit Policy" 3. Double-click "Audit Account Log in Event". 4. Click "Fail" and click OK.
Login failure will be recorded in the Windows security event log as an event. The following event ID is suspicious:
• 531: Indicates that you log in with the disable account. • 529: Indicates a valid user account that is invalid using an unknown user account or password. The unexpected increase in the number of audit events indicates that the password guess is attempt.
Record all failed operations in the file system
Using NTFS audits in the file system can detect malicious attempts. This process includes two steps.
• Enable logging
1. Launch the Local Security Policy tool from the Manage Tools program group. 2. Expand "Local Policy" and select "Audit Policy" 3. Double-click Review Object Access. 4. Click "Fail" and click OK.
• To review failure operations in the file system, do the following:
1. Start the Windows Explorer and locate the root directory of the file system. 2. Right-click and click Properties. 3. Click the Security tab. 4. Click Advanced, and then click the Audit tab. 5. Click Add, then enter Everyone in the Name field. 6. Click OK, select all "failed" checkbox to review all failed events. By default, this applies to the current folder and all subfolders and files. 7. Click OK three times to close all open dialogs. Failure audit events will be recorded in the Windows security event log. Relocate and protect the IIS log file
By moving and renaming the IIS log file, attackers can make the attacker cover their own traces. Attackers must first find the log file before you can change the log file. To make the attacker's task is more difficult to execute, use the NTFS permission to protect the log file.
Move the IIS log file directory to a variety of volumes in the web where the Web site is located, then rename it. Do not use system volumes. Next, apply the following NTFS permissions to the log file folder and subfolders.
• Administrators: Full Control • System: Full Control • Backup Operators: Read
Archive log file supply alternative analysis
To make it easy to analyze the IIS log files offline, you can use scripts to automatically remove log files from IIS servers while secure. A log file must be deleted at least every 24 hours. Automated scripts can transmit log files from the server computer using FTP, SMTP, HTTP, or SMB. However, if you want to enable one of the protocols, make sure you have enabled security to avoid any other attacks. Use the IPSec policy to protect ports and channels.
Access to Metabase.bin files
Review all failed access to the IIS Metabase.bin file (located on / Winnt / System32 / IneTsrv /). The same operation is performed on the / Metabase backup folder (backup copy of the metabase).
Other considerations
In addition, you can configure an IIS W3C extended log file format review. In the "Web Site" tab of the Web Site "Properties" dialog box, select "W3C Extended Log File Format". Then, select "extended properties" such as "URI Resources" and "URI queries".
Back to top
Step 11: Site and virtual directory
Locate the web root directory and virtual directory to non-system partitions to prevent directory traversal attacks. These attacks of attackers can perform operating system programs and utilities. Cross-drive traversal is impossible. For example, this method ensures that all normalized worms that allow attackers to access system files will fail. For example, if an attacker gives a URL containing the following path, the request will fail:
/scripts/..\../winnt/system32/cmd.exe
In this step, you have to do the following:
• Move the Web site to a non-system volume. • Disable the parent path settings. • Delete possible virtual directories. • Delete or protect RDS. • Set web privileges. • Delete or protect FrontPage Server Extensions.
Move Web site to non-system volume
Do not use the default / inetpub / wwwroot directory. For example, if the system is installed in a C: drive, move the site and content directory to D: drive. Doing so can alleviate the risk of unpredictable standardization and directory traversal attack risk.
Disable parent path settings
The IIS metadata setting is forbidden to use ".." in scripts and application calls similar to mappath. This helps prevent directory traversal attacks.
• To disable the parent path, do the following:
Start IIS. 2. Right-click the root directory of the Web site and click Properties. 3. Click the Home Directory tab. 4. Click Configure. 5. Click the Application Options tab. 6. Clear the Enable Parent Path. Note: If you use the Application Center 2002 management site, see Microsoft Knowledge Base Article 288309 PRB: Disabling Parent Paths Breaks User Interface.
Delete possible virtual directories
The sample application is not installed by default and should not be installed in the web production server. Delete all sample applications, including only HTTP: // localhost or http://127.0.0.1 sample applications accessed from the local computer.
Remove the following virtual directory from the production server: Iissamples, Iisadmin, Iishelp, and Scripts.
Note: IISLOCKDOWN provides an option to remove Scripts, Iissamples, Iisadmin, and Iishelp virtual directories.
Delete or protect RDS
Remote Data Services (RDS) is a component that allows Internet access to remote data resources via IIS. The RDS interface is provided by Msadcs.dll, Msadcs.dll is located in: Program Files / Common files / system / msadc.
Delete RDS
If the application does not use RDS, delete it.
• To delete RDS support, do the following:
1. Remove / MSADC virtual directory mapping from IIS. 2. Delete the RDS file and subdirectory in the following locations: / Program Files / Common Files / System / Msadc 3. Delete the following registry key: HKLM / System / CurrentControlSet / Services / W3SVC / Parameters / Adclaunch
Note: IISLOCKDOWN provides an option to delete the MSADC virtual directory. Note that iislockdown only deletes virtual directories, it does not delete files or registry entries.
Protect RDS
If the application requires RDS, make sure security.
• To make sure RDS security, do the following:
1. Delete the example in the following position: / progam files / common files / system / msadc / cases 2. Delete the following registry key: HKLM / System / CurrentControlSet / Services / W3SVC / Parameters / AdClaunch / Vbbusobj.vbbusobjCls 3. Anonymous access to the MSADC virtual directory is disabled in IIS. 4. Create a HandlerRequired registry key in the following position: HKLM / Software / Microsoft / DataFactory / Handlerinfo / 5. Create a new DWORD value to set it to 1 (1 represents security mode, 0 represents unsafe mode).
Note: You can use the registry script file handsafe.reg to change the registry key. This script file is in the MSADC directory:
/ Program Files / Common Files / System / MSADC
For more information on ensuring RDS security, see:
• MS99-025 Microsoft Security Program: Unauthorized Access To IIS Servers Through ODBC Data Access with RDS, URL is http://www.microsoft.com/technet/security/bulletin/ms99-025.asp (English). • MS98-004 Microsoft Security Program: Microsoft Security Bulletin: Unauthorized ODBC Data Access with RDS and IIS, the URL is http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ MS98-004.ASP (English). • Microsoft Knowledge Base Article 184375 PRB: Security Implications of RDS 1.5, IIS 3.0 OR 4.0, And ODBC (English). Set web permissions
Web permissions are configured in the IIS management unit and maintained in the IIS metadata. Web permissions are not NTFS permissions.
Please use the following web privileges:
• Read permissions. Limit the read permissions in the include directory. • Write and execute permissions. Limit write and execute permissions to allow an anonymous access to a virtual directory. • Script source access. Skin source access is only configured in folders that allow content creation. • Write. Writing permissions are only configured in folders that allow content creation. Just write access to access authority. Note: The folder that supports the content creation should be configured to require authentication and use SSL encryption.
Delete or protect FrontPage Server Extensions
If you don't use FrontPage Server Extensions (FPSE), disable it. If you use FPSE, perform the following steps to improve security:
• Upgrade the server extension. Please refer to the MSDN article "Microsoft FrontPage Server Extensions 2002 for Windows" (URL is http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservext/html/fpse02win.asp Safety issues in. • Use FrontPage security to restrict access. The group installed by the FPSE has access to websites configured with the server extension. The role of these groups is based on user roles to limit accessible access. For more information, see Assistance Center, the URL is http://office.microsoft.com/assistance/2002/Articles/fp_colmanageigurecurity.aspx (English).
Back to top
Step 12: Script mapping
Script mapping can associate a particular file extension (such as .asp) with the ISAPI extension that processes its ISAPI (such as ASP.DLL). IIS configuration To support a variety of extensions, including .asp, .shtm, .hdc, etc. The ASP.NET HTTP handler is approximately equivalent to ISAPI extensions. In IIS, the file extension (such as .aspx) is mapped to the ASPNET_ISAPI.dll first, then ASPNET_ISAPI.dll will forward the request to the ASP.NET work process. After that, the actual HTTP handler for processing the file extension is determined by the
• An attacker can use the vulnerability found in the extension. This problem may occur if the vulnerability in the extension is still not repaired. Reserved unused extensions will increase the area that may be attacked. For example, if you don't use an extension, it is possible not to pay attention to related updates. • Server-end resources can be downloaded by the client. The file extension mapping is incorrect and this problem may occur. For files that should not be directly accessed by the client, they should be mapped to the corresponding handler according to the extension, or delete them.
In this step, you have to do the following:
• Map the IIS file extension. • Map the .NET Framework file extension.
Map IIS file extension
In Windows 2000, important IIS file extensions include: .sp, .asa, .cer, .cdx, .htr, .idc, .shtm, .shtml, .stm, and .printer.
If you do not use any of the above extensions, map the extension to 404.dll provided by IISLockDown. For example, if you don't want to provide an ASP page for the client, map .asp to 404.dll.
What map of IISLOCKDOWN changes depends on your selected server template:
• Static web server. If you run IISLOCKDOWN and select the Static Web Server option, all the above extensions will be mapped to 404.dll. • Dynamic Web Server. If you select the "Dynamic Web Server" option (the preferences for processing the ASP.NET page), map .htr, .stc, .shtm, .shtml, .stm, and .printer map to 404.dll, don't be .asp , .Cer,. Cdx and .asa map to 404.dll. At this time, it should be manually mapped to 404.dll. If you don't use .asp, you can also map it.
Why is you mapped to 404.dll?
By mapping the file extension to 404.dll, it is possible to prevent returning and download files via HTTP. If the extension of the request file is mapped to 404.dll, the system displays a web page, which contains the message "HTTP 404 - File". It is recommended that you map unused extensions to 404.DLL instead of deleting mapping. If the mapping is deleted, the file is noted in the server (or the wrong place in the server), the system can display the file as a file when the file is requested, as IIS does not know how to handle it.
• To map the file extension to 404.dll, do the following:
Start IIS. 2. Right-click on the server name in the left window and click Properties. 3. Make sure "WWWService" is selected in the Primary Attribute drop-down list, and then click the adjacent "Edit" button. 4. Click the Home Directory tab. 5. Click Configure. The tab page shown in Figure 16.4 will appear. Figure 16.4 Mapping Application Extension 6. Select an extension from the list, and then click Edit. 7. Click "Browse" and navigate to /winnt/system32/inetsrv/404.dll. Note: This step assumes that you have run IISLOCKD.EXE because 404.dll is installed by the IISLockDown tool. 8. Click Open, and then click OK. 9. Repeat steps 6, 7 and 8 for all remaining file extensions. Mapping .NET Framework file extension
The following .NET Framework file extensions are mapped to Aspnet_isapi.dll: .asax, .ascx, .ashx, .smx, .aspx, .axd, .vsdisco, .jsl, .java, .vjsproj, .rem,. SoAP, .config, .cs, .csproj, .vb, .vbproj, .webinfo, .licx, .resx and .resources.
The file extension protected by .NET Framework should not be called directly by the client, and the practice is to associate them with the System.Web.httpForbiddenhandler in Machine.config. By default, the following file extensions will be mapped to System.Web.httpForbiddenHandler: .asax, .ascx, .config, .cs, .csproj, .vb, .vbproj, .webinfo, .asp, .licx, .resx And .resources.
For more information on the HTTP handler, see "Step 16: Machine.config".
Other considerations
Since IIS first processes web requests, you can map directly to 404.DLL you do not want the client call. This should be implemented two tasks:
• Pass the request to ASP.NET (before the ASP.NET work process processing request), first by 404.DLL and reject these requests. This eliminates the unnecessary handling of the ASP.NET work process. In addition, blocking requests as soon as possible is a better security approach. • 404.DLL Return Message "HTTP 404 - File", System.Web.httpForbiddenHandler Return Message "This type of page cannot be provided. "Did not find the file" message is less information, which can be considered safer (there is controversial).
Back to top
Step 13: ISAPI Filter
In the past, vulnerabilities in the ISAPI filter can lead to major IIS utilization attacks. After installing IIS, there is no more ISAPI filter, although .NET Framework is installed (ASPNET_FILTER.DLL) (this filter is loaded to IIS process address space (inetinfo.exe), the role is Supports session state management without cookie).
If the application does not need to support the Cookie session state, the filter can be deleted.
In this step, please delete the unused ISAPI filter.
Remove unused ISAPI filters
Delete all the ISAPI filters that are not used, as described in the following section.
• To view the ISAPI filter, do the following: 1. To start IIS, select Internet Services Manager from the Administrative Tools program group. 2. Right-click on the computer (non-Web site, because the filter is a computer range), and then click Properties. 3. Click Edit. 4. Click the ISAPI Filter tab. The tab page shown in Figure 16.5 will appear. Figure 16.5 Remove Unused ISAPI Filters
Back to top
Step 14: IIS metadata
Security and other IIS configuration settings are maintained in the IIS meta database file. Enhances NTFS permissions for IIS metadata (and backup meta database files) to ensure that an attacker cannot modify your IIS configuration in any way (for example, for authentication for a specific virtual directory).
In this step, you have to do the following:
• Use NTFS permissions to limit access to dollars. • Restrict the banner information returned by IIS.
Use NTFS permissions to limit access to metabases
Set the following NTFS permissions in the IIS metabase.bin located in the / Winnt / System32 / IneTsrv directory.
• Local system: Fully control • Administrators: Fully control
Restrict banner information returned by IIS
Banner information can display software versions and other information that attackers. Banner information shows your running software, which allows attackers to use known software vulnerabilities.
If you want to retrieve static pages (for example, .htm or .gif files), the content location header will be added to the response. By default, the content header references the IP address, but is not a fully qualified domain name (FQDN). This means that your internal IP address is unexpectedly open. For example, the following HTTP response header displays the IP address in a bold:
HTTP / 1.1 200 ok
Server: Microsoft-IIS / 5.0
Content-location: http://10.1.1.1/default.htm
Date: Thu, 18 Feb 1999 14:03:52 GMT
Content-Type: Text / HTML
Accept-ranges: Bytes
Last-modified: Wed, 06 Jan 1999 18:56:06 GMT
ETAG: "067D136A639BE1: 15B6"
Content-Length: 4325
You can hide the content location returned in the HTTP response header, and the method is to modify a value in the IIS metabrary, change the default behavior from the public IP address to send the FQDN.
For more information on hiding the content location in the HTTP response, see Microsoft Knowledge Base Articles 218180 Internet Information Server Returns IP Address In Http Header (English).
Back to top
Step 15: Server Certificate
If the web application supports HTTPS (SSL) through port 443, the server certificate must be installed. This requirement is part of the session negotiation process (when the client is established a secure HTTPS session).
A valid certificate provides secure authentication, and the client therefore trusts the server that communicates with it. In addition, effective certificates can provide secure communication to ensure that sensitive data transmitted in the network is still secret and will not be tampered with.
In this step, you will verify the server certificate.
Verify server certificate
Check the following four items to confirm that the Web server certificate is valid:
• Check the valid start date and a valid deadline. • Check if the certificate is properly used. If the certificate is issued as a server certificate, it should not be used for email. • Check that the public key in the card book chain is valid until the trusted root directory is valid. • Check if the certificate is not revoked. The certificate must not be located on the certificate revocation list (CRL) of the servers issued by the certificate. Back to top
Step 16: Machine.config
This section describes the enhanced information of the computer-level settings to be applied to all applications. For application-specific enhancement settings, see Module 19 Make sure the ASP.NET application and Web services are secure.
Machine.config files maintain a large number of computer range settings for .NET Framework, many settings will affect security. Machine.config is located in:
% WINDIR% / Microsoft.Net / Framework / {version} / config
Note: You can edit the XML configuration file using any text or XML editor (such as Notepad). XML tags are case sensitive, be sure to use the correct case.
In this step, you have to do the following:
• Map protected resources to HTTPFORBIDENHANDLER. • Verify that tracking is disabled. • Verify that debug compilation is disabled. • Verify that the ASP.NET error is not returned to the client. • Verify the session status settings.
Map protected resources to httpForbiddenhandler
The HTTP handler is located in Machine.Config, below the
The following file extensions in Machine.config are mapped to the HTTP handler:
• .aspx is used for ASP.NET Pages • .rem and. SoAP for remote processing • .asmx is used for web services • .asax, .ascx, .config, .cs, .csproj, .vb, .vbproj, .webinfo , .Asp, .licx, .resx and .resources are protected resources that are mapped to System.Web.httpForbiddenhandler.
For the .NET Framework resource, if you do not use a file extension, map the extension to System.Web.httpForbiddenhandler in Machine.config, as shown in the following example:
At this point, map the .vbproj file extension to System.Web.httpForbiddenhandler. If the path of the client request is ended in .vbProj, ASP.NET returns a message, indicating that "this type of page cannot be provided".
The following criteria apply to handling the .NET Framework file extension:
• map unused extensions to httpForbiddenhandler. If you do not use the ASP.NET page, map .aspx to HTTPFORBIDENHANDLER. If you don't use a web service, map .asmx to HttpForbiddenhandler. • Disable remote processing in the web server for the Internet. The remote processing extension (.soap, and.rem) in the web server to the Internet is mapped to HttpForbiddenhandler.
Disable .NET remote processing
To disable the .REM and .SoAP extension .NET remote processing disable request, use the elements in
Note: This does not prevent web applications from using the web application from using the remote processing infrastructure to connect downstream objects. However, it will prevent the client from connecting to the object in the web server.
Verify that the tracking is disabled
Use the
Use the following configuration in the production server:
RequestLimit = "10" tracemode = "sortbytime" /> Set enabled = "false" in the production server. If you really track the problem of the actual application, simulate the problem in the test environment, or enable tracking and set localonly = "true" to prevent tracking details from returning to the remote client. Verify that the debug compilation is disabled Use the Verify that the ASP.NET error is not returned to the client Use the Be sure to set the mode property to "Remoteonly", as shown in the following example: Once the ASP.NET application is installed, you can configure this setting to point to your custom error page, as shown in the following example: Verify session status settings If you don't use a session state, verify that the session status is disabled in Machine.config, as shown in the following example: In addition, make sure to disable the ASP.NET State Service. The default session status mode is "inproc", and the ASP.NET State Service is set to "Manual". For more information on protecting the session status (if you install the ASP.NET application), see Module 19 Make sure that "session status" in the security of the web service. Back to top Step 17: Code Access Security The computer-level code access security policy is determined by the settings in the security.config file, which is located in:% windir% / microsoft.net / framework / {version} / config Run the following command to make sure you enable code access security in your server: Caspol -s on For more information on configuring code access security for ASP.NET Web Application, see Module 9 ASP.NET Code Access Security. In this step, you have to do the following: • Delete all permissions from the local Intranet area. • Delete all permissions from the Internet area. Delete all permissions from the local Intranet area Local intranet area applies permissions to code running in a UNC shared or within the internal Web site. Associate this area with the "Nothing" permission set, which can be reconfigured to not grant permissions. • To delete all permissions from the local Intranet area, do the following: 1. Start the Microsoft .NET Framework 1.1 version of the configuration tool from the Administrative Tools program group. 2. Expand "Running Security Policy", expand "Computer" and expand "Code Group". 3. Expand "All_code" and select "LocalIntraNet_zone". 4. Click Edit Code Group Properties. 5. Click the Permissions Set tab. 6. Select "Nothing" from the "Permissions" drop-down list. 7. Click OK. The dialog shown in Figure 16.6 will be displayed. Figure 16.6 Setting "LocalIntranet_zone" code permissions to "Nothing" Delete all permissions in the Internet area The Internet area applies code access to code downloaded through the Internet. In a web server, the area should be reconfigured to not grant permissions, and the method is to associate it with the "Nothing" permission set. Repeat the steps in the "All Permissions to Delete Local Intranet Area", just set "Internet_zone" to "Nothing" permission set. Back to top Safe Web server snapshot In the snapshot view of the Security Web Server Properties, you can easily compare the settings with the web server quickly and easily. Table 16.4 The corresponding web server shown is located in a Web site that is strong and safe measures. By performing the previous steps, you can generate a server that is identical in security. Table 16.4: Safety Web Server Snapshot Component feature patches and updates Windows, IIS, and .NET Framework applied the latest service packs and patches. Service disables unwanted services. NNTP, SMTP and FTP are also disabled (unless they are required). Disable or protect WebDAV (if used). The service account is the least privileged. If you don't need ASP.NET Session State Service, disable it. The NetBIOS and SMB protocols are not enabled. The TCP stack has been enhanced. Accounts have deleted unused accounts. Disable guest account. The default administrator account is renamed and uses a strong password. Disable the default anonymous account (IUSR_MACHINE). Custom anonymous accounts are used for anonymous access. Force strong password strategy. Limit remote login. Disable empty sessions (anonymous login). The account delegation is required to approve the account. Do not use a shared account. Restrict the members of the local Administrators group (ideal is two members). Require administrators to log in to interact (or implement a secure remote management solution). Documents and Contents Everyone groups have access to the system, web, or tool directory. Anonymous accounts do not have access to Web Site Content Directory and System Utility. Delete or protect tools, utilities and SDK. Delete sample files. Delete unwanted DSNs. Sharing has deleted unused shares from the server. Access to the required shared has been protected (unless necessary, no sharing is enabled in the "EVERYONE" group). If you don't need to manage sharing (C $ and Admin $), you can delete them. The port blocks all ports other than 80 and 443 (SSL), especially those with vulnerable attacks, 135 - 139, and 445. Registry prevents remote management of the registry. SAM (stand-alone server only) has been protected. Audit and logging will log in to log in to log in. Record the failure of the Everyone group access object. Relocate the log file from% SystemRoot% / System32 / logfiles and protect them with ACL: Administrators and System have full control permissions. Enable IIS logging. Regular archive log files supply offline analysis. A review of the situation accessed by the Metabase.bin file. Configure IIS for W3C extended log file format review. IIS Site and Virtual Directory Web Root Catalog and Virtual Directory are located in different volumes with system volumes. Disable the parent path settings. Deleted Dangerous Virtual Directory (IIS Samples, Msadc, Iishelp, Scripts, and Iisadmin). The RDS has been deleted or protected. Web permissions restrictions inappropriate access. Limit the incline directory Use "Read" web privileges. Limit anonymous access folder Use "Write" and "Execute" Web permissions. The security folder that allows content creation can use "Script Source Access" Web permissions, but all other folders cannot use these privileges. If you don't need FPSE, it deletes it. Script mapping is not used by script maps to 404.dll: .idq, .htw, .ida, .shtml, .shtm, .stm, IDc, .htr, .printer. Note: 404. DLL is installed when running the IIS LockDown tool. The ISAPI filter has deleted unused ISAPI filters. The IIS meta database has been restricted using NTFS permissions to limit access to IIS metadata. Banner information has been restricted; hidden the content location in the HTTP response header. Machine.config httpforbiddenhandler protected resources are mapped to System.Web.httpForbiddenHandler Remote Processing has been disabled .NET remote processing. TYPE = "System.web.httpForbiddenHandler" /> TYPE = "System.web.httpForbiddenHandler" /> Track tracking information and detailed error messages do not return to the client: Compile Disable debug compilation CustomerRors does not return the error details to the client: The general error page will write an error to the event log. SessionState If you don't need a session state, disable it: Code Access Security Code Access Security has enabled code access security in your computer. Caspol -s on localintranet_zone Local intranet area No permission: permissionset = Nothing Internet_zone internet area No permission: permissionset = nothing Back to top stay safe The security status of the server must be monitored and updated regularly to prevent new discovered vulnerabilities from being used by others. To ensure that the server has been safe, do the following: • Audit group member identity. • Monitor the audit log. • Apply the latest service packs and patches. • Implement a security assessment. • Use security notice services. Review group member identity Track the member identity of the user group, especially the privileged group (such as the Administrators group). The following command lists members of the Administrators group: Net localgroup administrators Monitor audit log Regularly monitor audit logs and analyze log files, the method is manually viewed, or refer to Microsoft Knowledge Base Article 296085 How to: Use SQL Server to Analyze Web Logs (English). Apply the latest service packs and patches Develop plans to analyze server software and subscribe to security alerts. Use the MBSA to periodically scan the server to confirm which patches are missing. The following links provide the latest updates: • Windows 2000 Service Packs. The latest service pack is located at http://www.microsoft.com/windows2000/downloads/servicePacks/default.asp. • .NET Framework Service Pack. For information about getting .NET Framework latest update, see the MSDN article "How to get the microsoft .net framework", the URL is http://msdn.microsoft.com/netframework/downloads/howtoget.asp. • Key update program. These updates help solve known issues and help you patch your computer's known security vulnerability. For the latest key update, please refer to "critical updates", the URL is http://www.microsoft.com/windows2000/downloads/critical/default.asp (English) • Advanced Security Update. For information on other security updates, please refer to "Advanced Security Updates", the URL is http://www.microsoft.com/windows2000/download./security/default.asp. These updates help you patch the known security vulnerability of your computer. Executive safety assessment Use MBSA to periodically check security vulnerabilities, confirm which patches and updates are missing. Arrange MBSA run once a day, then analyze the results and take action as needed. For more information on automatic running MBSA, see how to "How" in this guide: Use MBSA. Use security notice service Use the Microsoft services listed in Table 16.5 to obtain security checks and understand the possible system vulnerability notifications. Table 16.5: Safety Notice Service Service Location TechNet Security Website http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/current.asp (English) Use this page to view system available security checks. Microsoft Security Notification Service http://register.microsoft.com/subscription/subscribeMe.asp?id=135 (English) Use this service to register a regular email check and get notified when new fixes and updates are available. In addition, please subsequently subscribe to the industry security alert service shown in Table 16.3. This allows you to threaten the exploitation of the patch is unavailable. Table 16.4: Industry Safety Notice Service Service location CERT consulting mailing list http://www.cert.org/contact_cert/certmaillist.html (English) If a vulnerability is reported, the user can receive the consultation information. Windows and .NET Magazine Security Update http://email.winnetmag.com/winnetmag/winnetmag_prefctr.asp (English) Announce the latest security violations and determine the fix. NTBUGTRAQ http://www.ntbugtraq.com/default.asp?pid=31&sid=1#020 (English) This is an open discussion for Windows security vulnerabilities and probes. Here will discuss the vulnerability of the currently no patch. Back to top Remote management Typically, the administrator wants to manage multiple servers. Make sure that the requirements for remote management solutions do not compromise security. If you need a remote management function, the following suggestions help to improve security: • Restrict the number of management accounts. This includes restricting the number of management accounts and restrictions allow which accounts are allowed remotely. • Restrict the use of tools. It mainly includes Internet Service Manager and Terminal Services. Another option is Web Management (using Iisadmin virtual directory), but it is not recommended (because it has been deleted by IISLOCKDOWN.EXE). Internet Service Manager and Terminal Services use Windows security. The main considerations here are to limit the Windows accounts and ports you use. • Limit the computer that allows the management server to be managed. Which computers can be restricted using IPSec to connect to the web server. Ensure the security of the terminal service You can safely use Microsoft Terminal Services to remotely manage your web server. The terminal service is based on Microsoft proprietary protocol called Remote Desktop Protocol (RDP). RDP uses TCP 3389 ports and supports two concurrent users. The following sections describe how to install and configure terminal services for security management: • Install the terminal service. • Configure Terminal Services. Install terminal service To install a terminal service, do the following: 1. Use the Add / Remove Programs in the Control Panel to install the terminal service. Use the Add / Delete Windows Components option. You don't have to install the Terminal Services licensing service for remote management. 2. Configure Terminal Services for remote management mode. 3. Delete the TSITUSER account (created during the installation terminal service). This account is used to support anonymous Internet access to the terminal service, and it should not be enabled in the server. Configure terminal services Use the "Terminal Services Configuration" MMC management unit in the Administrative Tools program to make the following configuration: 1. Connecting the terminal services There are three encryption levels (low, medium and high) available. Set the encryption to a 128-bit key. Note that the Windows advanced encryption package should be installed in the server and client at the same time. 2. Configure the terminal service session to disconnect it over the idle connection time limit. Set it to terminate the disconnected session. If the user turns off the terminal service client application (do not log out within ten minutes), it is considered that the session is disconnected. 3. Finally, limit access to terminal services. Use the RDP Permissions tab in the RDP dialog. By default, all members of the Administrators group are allowed to access terminal services. If you do not want all members of the Administrators group to access the terminal service, delete the group, then add a separate account you need to access. Note that the SYSTEM account must be included in the list. Use the secure VPN connection between the client and the server to enhance security. This method provides mutual authentication, and the RDP payload is encrypted. Copy file via RDP Terminal services do not provide built-in support for file transfer. But you can install the File Copy tool from the Windows 2000 Server Resource Toolkit to add file transfer capabilities to the clipboard redirection feature of the terminal service. For more information on this utility and installation instructions, see Microsoft Knowledge Base Article 244732 How To: Install The File Copy Tool Included with The Windows 2000 Resource Kit. Back to top Simplify and automate security This module has explained you how to manually configure security settings for the ASP.NET Web server. The manual process helps you understand the configuration, but it is time consuming. Use the following resource to automatically perform the steps provided by this module: • For information on how to run IISLOCKDOWN, see Microsoft Knowledge Base Article 310725 How To: Run The IIS Lockdown Wizard Unattended IIS (English). • Create and deploy security policies using security templates. For more information, please see the following Microsoft Knowledge Base articles: • 313434, "How To: Define Security Templates in the Security Templates Snap-in in Windows 2000 (English) • 309689,." How To: Apply Predefined Security Templates in Windows 2000 (English). • 321679, "HOW TO: Manage Security Templates in Windows 2000 Server (English). • For detailed guides for customization and automatic settings security templates, see" Microsoft Patterns & Practices, Microsoft Solution for Securing Windows 2000 Server ", the URL is http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/Prodtech/windows/secwin2k/default.asp (English). "Microsoft Solution for Securing Windows 2000 Server" introduced the most Common server roles, including domain controllers, DNS servers, DHCP servers, IIS web servers, and files and print servers. Through this guide, you can perform the default installation of Windows 2000, then create a secure server, server details The configuration varies with role. Since then, administrators can consciously weaken security to meet the needs of a particular environment. This guide provides basic knowledge related to the reference security recommendations such as service accounts, Group Policy, etc. You can use them as common The starting point of the server role type. Back to top summary A secure web server provides a security basis for residing web applications. This module illustrates the main threats that may affect the ASP.NET Web server and provide the security steps to ease these risks to perform. By implementing the enhancement steps provided in this module, you can create a secure platform and host infrastructure to support the ASP.NET web application and web services. The method used by this module is available to build a secure web server from beginning to enhance the security configuration of existing web servers. The next step is how to ensure proper configuration of all deployed applications. Back to top Other resources For other related reading materials, see: • For information on the protection of developer workstations, please refer to how to "How" section in this guide: Protect developer workstations. • For more information on ensuring ASP.NET web application and Web service security, see Module 19 Make sure the ASP.NET application and Web services are safe. • For information on configuring the Open Hack application, see the MSDN article build and configure a more secure website. • For secure resources in TechNet, see the TechNet Security page, the URL is http://www.microsoft.com/china/technet/security/default.asp (English). • For information on print checklists, see Checklist: Protecting the web server. Back to top
