Chapter 22 – Deployment Review

  • Article

 

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

patterns & practices Developer Center

Improving Web Application Security: Threats and Countermeasures

J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan
Microsoft Corporation

Published: June 2003

Last Revised: January 2006

Applies to:

  • ASP.NET version 1.1
  • .NET Framework version 1.1
  • Internet Information Services (IIS) version 5.0
  • Microsoft® Windows® 2000 operating system

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for the starting point and a complete overview of Improving Web Application Security: Threats and Countermeasures.

Summary: This chapter shows you how to perform a deployment review to identify potential security vulnerabilities in your ASP.NET Web applications. The deployment review questions cover the configuration of the network and host, which includes Windows 2000 / Windows Server 2003 and, depending on the server role, IIS, the Microsoft ®.NET Framework, Enterprise Services, and SQL Server.

Contents

In This Chapter
Overview
Web Server Configuration
IIS Configuration
Machine.Config
Web Services
Enterprise Services
Remoting
Database Server Configuration
Network Configuration
Summary

In This Chapter

  • Reviewing network and host configuration
  • Reviewing base Windows 2000 / Windows Server 2003™ configuration
  • Reviewing IIS and .NET Framework configuration
  • Reviewing Web application and Web service configuration
  • Reviewing Enterprise Services configuration
  • Reviewing Remoting configuration
  • Reviewing SQL Server configuration

Overview

Web application security is dependent upon the security of the underlying infrastructure on which the application is deployed. Weak network or host configuration settings result in vulnerabilities that can and will be exploited. The deployment review covered in this chapter inspects the configuration of the network and host. The host includes Windows 2000 / Windows Server 2003 and, depending on the server role, it can also include IIS, the Microsoft .NET Framework, Enterprise Services, and SQL Server.

The main configuration elements that are subject to the deployment review process are shown in Figure 22.1.

Ff648642.f22thcm01(en-us,PandP.10).gif

Figure 22.1

Core elements of a deployment review

Web Server Configuration

The goal for this phase of the review is to identify vulnerabilities in the configuration of the base operating system on your Web server. This does not include IIS configuration, which is dealt with separately. For further background information about the issues raised by the review questions in this section, see Chapter 16, "Securing Your Web Server."

To help focus and structure the review process, the review questions have been divided into the following configuration categories:

  • Patches and updates
  • Services
  • Protocols
  • Accounts
  • Files and directories
  • Shares
  • Ports
  • Registry
  • Auditing and logging

Patches and Updates

Verify that your server is updated with the latest service packs and software patches. You need to separately check operating system components and the .NET Framework. Review the following questions:

  • Have you run MBSA?

    Make sure you have run the MBSA tool to identify common Windows and IIS vulnerabilities, and to identify missing service packs and patches.

    Respond to the MBSA output by fixing identified vulnerabilities and by installing the latest patches and updates. For more information, see "Step 1. Patches and Updates" in Chapter 16, "Securing Your Web Server."

  • Have you installed .NET Framework updates?

    To determine the current version of the .NET Framework, see Microsoft Knowledge Base article 318785, "INFO: Determining Whether Service Packs Are Installed on .NET Framework." Then compare the installed version of the .NET Framework against the current service pack. To do this, use the .NET Framework versions listed in article 318836, "INFO: How to Obtain the Latest .NET Framework Service Pack."

Services

Make sure that only the services that you require are enabled. Check that all others are disabled to reduce your server's attack profile. To see which services are running and enabled, use the Services and Applications Microsoft Management Console (MMC) snap-in available from Computer Management. To disable a service, make sure it is stopped and set its startup type to manual.

Review the following questions to verify your services configuration:

  • Do you run unnecessary services?

    Review each service that is running by using the Services snap-in and confirm that each service is required. Identify why it is required and which solutions rely on it. Make sure all unnecessary services are disabled.

  • Have you disabled the Telnet service?

    Telnet is often used for remote IIS administration. However, it is an insecure protocol susceptible to many attacks. Check that the Telnet service is disabled. For a more secure administration solution, use Terminal Services.

  • Have you disabled FTP, SMTP, and NNTP services?

    These services are not secure protocols and have known vulnerabilities. If you do not need them, disable them. If you use them, find secure alternatives. These services are listed in the Services MMC snap-in as FTP Publishing Service, Simple Mail Transport Protocol (SMTP) and Network News Transport Protocol (NNTP).

    Note   IISLockdown disables these services. By default, these services are disabled when IIS 6.0 is installed on Windows Server 2003.

  • Do you use the ASP.NET session state service?

    To see whether your applications use this service, review the <sessionState> element in your application's Web.config file. If Web.config does not contain this element, check its setting in Machine.config. You use the session state service on your Web server if the mode attribute is set to "StateServer" and the stateConnectionString points to the local machine, for example with a localhost address as shown below:

    <sessionState mode="StateServer"
          stateConnectionString="tcpip=127.0.0.1:42424" />

    If you do not use the service on the Web server, disable it. It is listed as "ASP.NET State Service" in the Services MMC snap-in.

    For more information on how to secure ASP.NET session state, refer to "Session State" in Chapter 19, "Securing Your ASP.NET Application and Web Services."

Protocols

Review which protocols are enabled on your server and make sure that no unnecessary protocol is enabled. Use the following questions to help review protocols on your server:

  • Do you use WebDAV?

    If you use the Web Distributed Authoring and Versioning protocol (WebDAV) to publish content then make sure it is secure. If you do not use it, disable the protocol.

    For information on how to secure WebDAV, see Microsoft Knowledge Base article 323470, "How To: Create a Secure WebDAV Publishing Directory." For information about disabling WebDAV, see article 241520, "How To Disable WebDAV for IIS 5.0."

    Note   By default, this protocol is disabled when IIS 6.0 is installed on Windows Server 2003

  • Have you hardened the TCP/IP stack?

    Make sure the TCP/IP stack is hardened to prevent network level denial of service attacks including SYN flood attacks. To check whether the stack is hardened on your server, use Regedt32.exe and examine the following registry key:

    HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

    The presence of the following child keys indicates a hardened TCP/IP stack: SynAttackProtect, EnableICMPRedirect, and EnableDeadGWDetect.

    For a full list of the required keys and the appropriate key values for a fully hardened stack, see "How To: Harden the TCP/IP Stack" in the "How To" section of this guide.

  • Have you disabled NetBIOS and SMB for internet facing network cards?

    Check that NetBIOS over TCP/IP is disabled and that SMB is disabled to prevent host enumeration attacks. For more information, see "Step 4. Protocols" in Chapter 16, "Securing Your Web Server."

Accounts

Review the use of all the Windows accounts on the server to make sure that no unnecessary accounts exist, and that all of the necessary accounts are configured with the minimum privileges and the required access rights. The following questions help you identify account vulnerabilities:

  • Have you deleted or disabled all unused accounts?

    Perform an audit to verify that all your accounts are used and required. Delete or disable any unnecessary accounts. The local administrator account and Guest account cannot be deleted. You should disable the Guest account and rename the Administrator account, making sure it has a strong password.

  • Have you disabled the Guest account?

    To check if the Guest account is disabled, display the Users folder in the Computer Management tool and check that the Guest account appears with a cross icon next to it. If it is not disabled, display its Properties dialog box and select Account is disabled.

  • Have you renamed the default administrator account?

    The default local administrator account is a prime target for attack. Verify that you have renamed the administrator account and given it a strong password.

  • Have you created a custom anonymous Web account?

    Check that the default IUSR_MACHINE account is disabled and that you have configured an alternate anonymous user account for use by your Web applications.

  • Do you use strong password policies?

    Use the Local Security Policy tool to review password policy. For information about the recommended password policy, see "Step 5. Accounts" in Chapter 16, "Securing Your Web Server."

  • Do you restrict remote logons?

    Check the user rights assignments within the Local Security Policy tool to ensure that the Everyone group is not granted the "Access this computer from the network" user right.

  • Have you disabled null sessions?

    Check that null sessions are disabled to prevent anonymous (unauthenticated) sessions from being created with your server. To check this, run Regedt32.exe and confirm that the RestrictAnonymous key is set to 1 as shown below.

    HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous=1

Files and Directories

The following review questions enable you to verify that you have used NTFS permissions appropriately to lock down accounts such as the anonymous Web user account.

  • Is IIS installed on an NTFS volume?

    This allows you to use NTFS to configure ACLs on resources to restrict access. Do not build a server that uses FAT partitions.

  • Have you restricted the Everyone group?

    Use Windows Explorer to ensure that the Everyone group does not have access to the following directories:

    • Web site root directory and all content directories (default is \inetpub\*)

  • Have you restricted the anonymous Web user account?

    Make sure that the anonymous Internet user account does not have the ability to write to Web content directories. Use Windows Explorer to view the ACL on each content directory. Also check the ACL on the %windir%\system32 directory to make sure that it cannot access system tools and utilities.

    Note   If you ran IISLockdown, the Web Anonymous Users group and the Web Applications group can be used to restrict access. By default, the Web Anonymous Users group contains the IUSR account and the Web Applications group contains Internet Web Application Manager (IWAM). From an administrative perspective, restricting access to a group is preferred to individual account restriction.

  • Have you secured or removed utilities and SDKs?

    Verify that you have no utilities or software development kits (SDKs) on your server. Make sure that neither Visual Studio.NET nor any .NET Framework SDKs are installed. Also make sure that you have restricted access with NTFS permissions to powerful system tools such as At.exe, Cmd.exe, Net.exe, Pathping.exe, Regedit.exe, Regedt32.exe, Runonce.exe, Runas.exe, Telnet.exe, and Tracert.exe. Finally, make sure that no debugging tools are installed on the server. IISLockdown automatically restricts access to system tools by the Web Anonymous Users group and the Web Applications group.

  • Have you removed unused DSNs?

    Verify that all unused data source names (DSNs) have been removed from the server because they can contain clear text database connection details.

Shares

Review the following questions to ensure that your server is not unnecessarily exposed by the presence of file shares:

  • What shares are available on your server?

    To review shares and associated permissions, run the Computer Management MMC snap-in and select Shares beneath SharedFolders. Check that all the shares are required. Remove any unnecessary shares.

  • Can the Everyone group access shares?

    Verify that the Everyone group is not granted access to your shares unless intended, and that specific permissions are configured instead.

  • Have you removed the administration shares?

    If you do not allow remote administration of your server, then check that the administration shares, for example, C$ and IPC$ have been removed.

Ports

Review the ports that are active on your server to make sure that no unnecessary ports are available. To verify which ports are listening, run the following netstat command.

netstat -n -a

This command generates the following output:

Ff648642.f22thcm02(en-us,PandP.10).gif

Figure 22.2

Netstat output

This output lists all the ports together with their addresses and current state. Make sure you know which services are exposed by each listening port and verify that each service is required. Disable any unused service.

To filter out specific string patterns from netstat output, use it in conjunction with the operating system findstr tool. The following example filters the output for ports in the "LISTENING" state.

netstat -n -a | findstr LISTENING

You can also use the Portqry.exe command line utility to verify the status of TCP/IP ports. For more information about the tool and how to download it, see Microsoft Knowledge Base article 310099, "Description of the Portqry.exe Command Line Utility."

Also review the following:

  • Internet-facing ports are restricted to TCP 80 and 443.
  • Intranet traffic is restricted or encrypted.

Registry

Review the security of your registry configuration with the following questions:

  • Have you restricted remote registry administration?

    Use Regedt32.exe to review the ACL on the WinReg registry key, which controls whether or not the registry can be remotely accessed.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg

    By default in Windows 2000, remote registry access is restricted to members of the Administrators and Backup operators group. For maximum security, restrict all remote access to the registry by using an empty Discretionary Access Control List (DACL).

    Note   Some services require remote access to the registry. See Microsoft Knowledge Base article 153183, "How to Restrict Access to the Registry from a Remote Computer," to see if your scenario demands limited remote registry access.

  • Have you secured the SAM?

    This only applies to stand-alone servers. Check that you have restricted LMHash storage in the Security Account Manager (SAM) database by creating the key (not value) NoLMHash in the registry as follows:

    HKLM\System\CurrentControlSet\Control\LSA\NoLMHash

Auditing and Logging

Review your use of Windows auditing with the following questions.

  • Do you log all failed logon attempts?

    Use the Local Security Policy tool to check that you have enabled the auditing of failed logon attempts.

  • Do you log all failed actions across the file system?

    Use the Local Security Policy tool to check that you have enabled object access auditing. Then check that auditing has been enabled across the file system.

IIS Configuration

By reviewing and improving the security of IIS configuration settings, you are in effect reducing the attack surface of your Web server. For more information about the review points covered in this section, see Chapter 16, "Securing Your Web Server."

The review questions in this section have been organized by the following configuration categories.

  • IISLockdown
  • URLScan
  • Sites and virtual directories
  • ISAPI filters
  • IIS Metabase
  • Server certificates

IISLockdown

The IISLockdown tool identifies and turns off features to reduce the IIS attack surface area. To see if it has been run on your server, check for the following report generated by IISLockdown:

\WINNT\system32\inetsrv\oblt-rep.log

For more information about IISLockdown, see "How To: Use IISLockdown.exe" in the "How To" section of this guide.

Note   By default, IIS 6.0 has security-related configuration settings similar to those made by the IIS Lockdown Tool. Therefore, you do not need to run the IIS Lockdown Tool on Web servers running IIS 6.0. If you are upgrading from a previous version of IIS (5.0 or lower) to IIS 6.0, it is recommended that you run the IIS Lockdown Tool to enhance the security of your Web server.

URLScan

URLScan is an ISAPI filter that is installed with IISLockdown. It helps prevent potentially harmful requests from reaching the server and causing damage. Check that it is installed and that it is configured appropriately.

To see if URLScan is installed

  1. Start Internet Information Services.
  2. Right-click your server (not Web site) and then click Properties.
  3. Click the Edit button next to MasterProperties.
  4. Click the ISAPIFilters tab and see if URLScan is listed.

To check the URLScan configuration, use Notepad to edit the following URLScan configuration file.

%WINDIR%\System32\Inetsrv\URLscan\Urlscan.ini

For more information about URLScan, see "How To: Use URLScan" in the "How To" section of this guide.

Note   IIS 6.0 on Windows Server 2003 has functionality equivalent to URLScan built in. Your decision whether to install UrlScan should be based on your specific organizational requirements. For more information, see "Installing UrlScan 2.5". For more information, see https://technet.microsoft.com/en-us/security/cc242650.aspx.

Sites and Virtual Directories

The review questions in this section relate to the specific configuration of your Web sites and the virtual directories of your applications. In this section, you review the following categories:

  • Web site location
  • Script mappings
  • Anonymous Internet user accounts
  • Auditing and logging
  • Webpermissions
  • IP address and domain name restrictions
  • Authentication
  • Parent path setting
  • Microsoft FrontPage Server extensions

Web Site Location

Check that your Web site root directory is installed on a non-system volume. By relocating your Web site root to a non-system volume, you prevent attackers who use directory traversal attacks from accessing the system tools and executables such as Cmd.exe.

Script Mappings

Check that you have mapped all unnecessary file extensions to the 404.dll, which is installed when you run IISLockdown.

To review script mappings

  1. Start Internet Information Manager.
  2. Right-click your Web site and click Properties.
  3. Click the Home Directory tab and then click the Configuration button within the Application Settings group.

Anonymous Internet User Accounts

Verify that your application is configured to use a non-default anonymous Internet user account. If you have multiple Web applications on your server, check that each application is configured to use a separate anonymous account. This allows you to configure permissions and to track activity on a per Web application basis.

Auditing and Logging

Check that you have configured IIS auditing to help detect attacks in progress and to diagnose attack footprints. The following review questions help identify vulnerabilities in IIS auditing:

  • Are log files located on a separate non-system volume?

    Right click your Web site in IIS and click the Web Site tab. Click the Properties button to check the log file location. Check that the log files are located in a non-default location using a non-default name, preferably on a non-system volume.

  • Do you restrict access to the log files?

    Use Windows Explorer to view the ACL on the log files directory. Check that the ACL grants Administrators and System full control but grants access to no other user.

Web Permissions

Review the default Web permissions configured for your Web site and for each virtual directory. Check that the following conditions are met:

  • Include directories restrict Read permissions.
  • Virtual directories for which anonymous access is allowed are configured to restrict Write and Execute permissions.
  • Write permissions and script source access permissions are only granted to content folders that allow content authoring. Also check that folders that allow content authoring require authentication and Secure Sockets Layer (SSL) encryption.

IP Address and Domain Name Restrictions

Do you use IP and domain name restrictions to restrict access to your Web server? If so, have you considered the risks of IP spoofing?

Authentication

Check the authentication settings for your Web sites and virtual directories. Ensure that anonymous access is only supported for publicly accessible areas of your site. If you are selecting multiple authentication options, thoroughly test the effects and authentication-precedence on your application.

If Basic authentication is selected, check that SSL is used across the site to protect credentials.

Parent Path Setting

Check that you have disabled the parent path setting to prevent the use of ".." in script and application calls to functions such as MapPath. This helps prevent directory traversal attacks.

To review the parent paths setting

  1. Start Internet Services Manager.

  2. Right-click your Web site, and click Properties.

  3. Click the HomeDirectory tab.

  4. Click Configuration.

  5. Click the AppOptions tab.

  6. Check that the Enableparentpaths check box is clear.

    Note   Enable parent paths is disabled by default in IIS 6.0 on Windows Server 2003.

FrontPage Server Extensions (FPSE)

FrontPage Server Extensions are used for accessing, authoring, and administering the FrontPage-based Web site. Use the latest versions of these extensions to avoid security vulnerabilities. If you do not use FPSE, disable them to reduce the attack surface.

For more information, see "Step 11. Sites and Virtual Directories" in Chapter 16, "Securing Your Web Server."

ISAPI Filters

Make sure that no unused ISAPI filters are installed to prevent any potential vulnerabilities in these filters from being exploited.

To review ISAPI filters

  1. Start Internet Information Manager.
  2. Right click your server (not Web site) and then click Properties.
  3. Click the Edit button next to MasterProperties.
  4. Click the ISAPIFilters tab to view the installed filters.

IIS Metabase

The IIS Metabase contains IIS configuration settings, many but not all of which are configured through the IIS administration tool. The file itself must be protected and specific settings that cannot be maintained using the IIS configuration tool should be checked. Review the following questions to ensure appropriate metabase configuration:

  • Have you restricted access to the metabase?

    Check that the ACL on the metabase file allows full control access to the system account and administrators. No other account should have access. The metabase file and location is:

    %windir%\system32\inetsrv\metabase.bin

  • Do you reveal internal IP addresses?

    By default, IIS returns the internal IP address of your server in the Content-Location section of the HTTP response header. You should prevent this by setting the UseHostName metabase property to true. To check if it has been set, run the following command from the \inetpub\adminscripts directory:

    adsutil GET w3svc/UseHostName

    Confirm that the property value has been set to true. If the property is not set, this command returns the message "The parameter 'UseHostName' is not set at this node." For more information, see "Step 14. IIS Metabase" in Chapter 16, "Securing Your Web Server."

Server Certificates

If your applications use SSL, make sure that you have a valid certificate installed on your Web server. To view the properties of your server's certificate, click View Certificate on the Directory Security page of the Properties dialog of your Web site in IIS. Review the following questions:

  • Has your server certificate expired?

  • Are all public keys in the certificate chain valid up to the trusted root?

  • Has your certificate been revoked?

    Check that it is not on a Certificate Revocation List (CRL) from the server that issued the certificate.

Machine.Config

The .NET Framework configuration for all applications on your server is maintained in Machine.config. For the purposes of the security review, this section examines the settings in Machine.config from top to bottom and considers only those settings that relate to security.

The majority of security settings are contained beneath the <system.web> element, with the notable exception of Web service configuration and .NET Remoting configuration. The review process for Web services and .NET Remoting configuration is presented later in this chapter.

Note   In .NET 2.0, the ASP.NET-related settings are in the machine-level Web.config file, located in the same folder as the Machine.config file. While performing your security review, you will need to review both the Machine.config and machine-level Web.config files.

For more information and background about the issues raised by the following review questions, see Chapter 19, "Securing Your ASP.NET Application and Web Services." The following elements are reviewed in this section:

  • <trace>
  • <httpRunTime>
  • <compilation>
  • <pages>
  • <customErrors>
  • <authentication>
  • <identity>
  • <authorization>
  • <machineKey>
  • <trust>
  • <sessionState>
  • <httpHandlers>
  • <processModel>

<trace>

Make sure tracing is disabled with the following setting.

<trace enabled="false" ... />

<httpRunTime>

Verify the value of the maxRequestLength attribute on the <httpRunTime> element. You can use this value to prevent users from uploading very large files. The maximum allowed value is 4 MB.

<compilation>

Check that you do not compile debug binaries. Make sure the debug attribute is set to false.

<compilation debug="false" ... />

<pages>

The <pages> element controls default page level configuration settings. From a security perspective, review the view state and session state settings.

  • Do you use view state?

    If enableViewState is set to true, make sure that enableViewStateMac is also set to true to protect the view state over the network. Also make sure that you review the <machineKey> configuration because this specifies the encryption and hashing algorithms to use together with the associated keys.

  • Do you use session state?

    If enableSessionState is set to true, make sure you review the <sessionState> element configuration.

<customErrors>

Make sure that the mode attribute is set to On to ensure that detailed exception information is not disclosed to the client. Also check that a default error page is specified via the defaultRedirect attribute.

<customErrors mode="On" defaultRedirect="/apperrorpage.htm" />

<authentication>

This element governs your application's authentication mechanism. Check the mode attribute to see which authentication mechanism is configured and then use the specific review questions for your configured authentication mode.

<authentication mode="[Windows|Forms|Passport|None"] />

Forms Authentication

Review the following questions to verify your Forms authentication configuration.

  • Do you encrypt the authentication cookie?

    Cookies should be encrypted and checked for integrity to detect tampering even over an SSL channel because cookies can be stolen through cross-site scripting (XSS) attacks. Check that the protection attribute of the <forms> element is set to All.

    <forms protection="All" .../>   All indicates encryption and verification

  • Do you use SSL with Forms authentication?

    SSL prevents session hijacking and cookie replay attacks. Check the requireSSL attribute of the <forms> element.

    <forms requireSSL="true" ... />

  • Do you limit authentication cookie lifetime?

    Minimize the cookie timeout to limit the amount of time an attacker can use the cookie to access your application. Check the timeout attribute on the <forms> element.

    <forms timeout="10" ... />

  • Do you use sliding expiration?

    Check the slidingExpiration attribute. slidingExpiration="false" means that the cookie expires at a fixed duration after its initial duration. The timeout clock is not reset after each request. Use of a sliding expiration is particularly recommended for applications that do not use SSL on all pages to protect the cookie.

  • Do you use unique cookie paths and names?

    Check that you use a separate cookie name and path for each Web application. This ensures that users who are authenticated against one application are not treated as authenticated when using a second application hosted by the same Web server. Check the path and name attributes on the <forms> element.

    <forms name=".ASPXAUTH" path="/" ... />

  • Do you use the <credentials> element?

    You should not use the <credentials> element on production servers. This element is intended for development and testing purposes only. Credentials should instead be stored in Microsoft Active Directory® directory service or SQL Server.

  • How do you store credentials?

    If your application uses Windows authentication, credentials are stored in Active Directory, which passes the credential management issue to the operating environment. If your application uses Forms authentication, make sure you use a SQL Server or Active Directory credential store.

  • Do you store password hashes?

    Make sure passwords are not stored in the database. Instead, store password hashes with added salt to foil dictionary attacks.

  • Do you use strong passwords?

    Your application should enforce the use of strong passwords. A good way to do this is to use a regular expression in the Forms logon page.

<identity>

The following questions help verify your impersonation configuration specified on the <identity> element:

  • Do you impersonate the original caller?

    If the impersonate attribute is set to true and you do not specify userName or password attributes, you impersonate the IIS authenticated identity, which may be the anonymous Internet user account.

    Make sure that ACLs are configured to allow the impersonated identity access only to those resources that it needs to gain access to.

  • Do you impersonate a fixed identity?

    If you impersonate and set the userName and password attributes, you impersonate a fixed identity and this identity is used for resource access.

    Make sure you do not specify plaintext credentials on the <identity> element. Instead, use Aspnet_setreg.exe to store encrypted credentials in the registry.

    On Windows 2000 this approach forces you to grant the "Act as part of the operating system" user right to the ASP.NET process account, which is not recommended. For alternative approaches, see Chapter 19, "Securing Your ASP.NET Application and Web Services."

    Note   If you are running .NET Framework 2.0, you can use the new Protected Configuration feature, which allows you to encrypt sensitive configuration file data by using a command line tool (aspnet_regiis.exe). For more information, see "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI" and "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA."

<authorization>

This element controls ASP.NET URL authorization and specifically the ability of Web clients to gain access to specific folders, pages, and resources.

  • Have you used the correct format for user and role names?

    When you have <authentication mode="Windows" />, you are authorizing access to Windows user and group accounts.

    User names take the form "DomainName\WindowsUserName". Role names take the form "DomainName\WindowsGroupName".

    Note   The local administrators group is referred to as "BUILTIN\Administrators". The local users group is referred to as "BUILTIN\Users".

    When you have <authentication mode="Forms" />, you are authorizing against the identity that is authenticated by the application. Normally, you authorize against the roles that are retrieved from the database. Role names are application specific.

<machineKey>

This element is used to specify encryption and validation keys, and the algorithms used to protect Forms authentication cookies and page level view state.

  • Do you run multiple applications on the same server?

    If so, use the IsolateApps setting to ensure a separate key is generated for each Web application.

    <machineKey validationKey="AutoGenerate,IsolateApps"
            decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>

  • Do you run in a Web farm?

    If so, make sure that you use specific machine keys and copy them across all servers in the farm.

  • Do you protect view state?

    If you protect view state, for example, by setting enableViewSetMac="true" on the <pages> element, set validation="SHA1" (Secure Hash Algorithm) or "3DES" on the <machineKey> element. The Triple Data Encryption Standard (3DES) setting is required if you also encrypt the Forms authentication cookie by setting protection="All" on the <forms> element.

<trust>

The <trust> element determines the code access security trust level used to run ASP.NET Web applications and Web services.

  • What version of the .NET Framework do you run?

    If you run .NET Framework 1.0 then the trust level must be set to Full. For versions equal to or greater than 1.1, you can change it to one of the following:

    <!--  level="[Full|High|Medium|Low|Minimal]" -->
<trust level="Full" originUrl=""/>

  • What trust level do you use?

    Based on security policy and the agreement with the development team; set an appropriate trust level for the application either in Web.config or in Machine.config (or the machine-level Web.config file if you are running .NET 2.0).

<sessionState>

The sessionState element configures user session state management for your application. Review the following questions:

  • Do you use a remote state store?

    Check the state store by examining the mode attribute.

    <sessionState mode="Off|Inproc|stateServer|SQLServer" ... />

    If you use a remote state store and the mode attribute is set to stateServer or SQLServer, check the stateConnectionString and sqlConnectionString attributes respectively. So that credentials are not included in the database connection string, make sure the connection strings are secured in encrypted format in the registry using the Aspnet_setreg.exe tool (or in the configuration file using aspnet_regiis.exe if you are running .NET 2.0), or that Windows authentication is used to connect to the SQL Server state store.

  • Do you use Windows authentication to the state database?

    If you use the SQL Server state store, check to see if you use Windows authentication to connect to the state database. This means that credentials are not stored in the connection string and that credentials are not transmitted over the wire.

    If you must use SQL authentication, make sure the connection string is encrypted in the registry and that a server certificate is installed on the database server to ensure that credentials are encrypted over the wire.

<httpHandlers>

This element lists the HTTP handlers that process requests for specific file types. Check to ensure that you have disabled all unused file types.

Map unused file types to System.Web.HttpForbiddenHandler to prevent their HTTP retrieval. For example, if your application does not use Web services, map the .asmx extension as follows:

<httpHandlers>
  <add verb="*" path="*.asmx" type="System.Web.HttpForbiddenHandler"/>
</httpHandlers>

<processModel>

The identity under which the ASP.NET worker process runs is controlled by settings on the <processModel> element in Machine.config. The following review questions help verify your process identity settings:

  • What identity do you use to run ASP.NET?

    Check the userName and password attributes. Ideally, you use the following configuration that results in the ASP.NET process running under the least privileged ASPNET account.

    <processModel userName="Machine" password="AutoGenerate" . . ./>

  • Do you encrypt the <processModel> credentials?

    If you use a custom account, make sure that the account credentials are not specified in plaintext in Machine.config. Make sure the Aspnet_setreg.exe utility has been used to store encrypted credentials in the registry. If this has been used, the userName and password attributes look similar to the settings shown below:

    <processModel
        userName="registry:HKLM\SOFTWARE\YourSecureApp\processModel\
                  ASPNET_SETREG,userName"
        password="registry:HKLM\SOFTWARE\YourSecureApp\processModel\
                  ASPNET_SETREG,password" . . ./>

    **Note **  By default, IIS 6.0 on Windows Server 2003 runs applications inside application pools, and the identity configured in the IIS Metabase determines the process identity. You only use the <processModel> element to store account credentials if your application runs on IIS 5.0, or if IIS 6.0 is configured for IIS 5.0 compatibility mode.

  • Do you use a least privileged account?

    The default ASPNET process identity account is a least privileged local account designed to run ASP.NET. To use it for remote resource access, you need to create a duplicate account on the remote server. Alternatively, you can create a least privileged domain account.

    Check that the account is not a member of the Users group, and view the user rights assignment in the Local Security Policy tool to confirm it is not granted any extended or unnecessary user rights. Make sure it is not granted the "Act as part of the operating system" user right.

Web Services

The goal for this phase of the review is to identify vulnerabilities in the configuration of your Web services. For further background information about the issues raised by the review questions in this section, see Chapter 17, "Securing Your Application Server," and Chapter 19, "Securing Your ASP.NET Applications and Web Services."

Use the following questions to help review the security configuration of your Web service:

  • Have you disabled the Documentation protocol?

    If you do not want to expose your Web services endpoints, then you can remove the Documentation protocol from the <protocols> element in Machine.config and manually distribute the .Web Services Description Language (WSDL) file to specific Web service consumers.

  • Have you disabled the HTTP Get and Post protocols?

    By disabling (commenting) HttpGet and HttpPost protocols from <protocols> element in Machine.config file, you help to reduce the attack profile for your Web services.

  • Do you restrict access to WSDL?

    If you store the generated .WSDL files on the Web server to distribute them to the consumers, make sure that the files are protected by an appropriate ACL. This prevents a malicious user from updating or replacing the WSDL so that it points to endpoints that differ from the intended URL.

  • Do you pass sensitive data in SOAP requests or responses?

    If your Web service handles sensitive data, how do you protect the data over the network and address the network eavesdropping threat? Do you use SSL or IPSec encrypted channels, or do you encrypt parts of the message by using XML encryption?

  • How do you authenticate callers?

    If your Web service exposes restricted operations or data, it needs to authenticate callers to support authorization. Review how the Web service authenticates its clients.

  • Do you pass credentials in SOAP headers?

    If you pass credentials in SOAP headers, are they passed in plaintext? If they are, make sure an encrypted channel is used.

Enterprise Services

This section identifies the key review points that should be considered when you review your Enterprise Services applications and components. For more information about the issues raised in this section, see Chapter 17, "Securing Your Application Server."

When you review Enterprise Services applications consider the following issues:

  • Accounts
  • Files and directories
  • Authentication
  • Authorization
  • Remote serviced component

Accounts

If you use an Enterprise Services server application, check which account you use to run the application. This is displayed on the Identity page of the application's Properties dialog box in Component Services. Review the following questions:

  • Do you use a least privileged account?

    Check the account that you use to run your Enterprise Services server applications to ensure they are configured as least privileged accounts with restricted user rights and access rights. If you use the process account to access a downstream database, make sure that the database login is restricted in the database.

  • Do you use the Interactive account?

    Do not use the Interactive account on production servers. This is only intended to be used during development and testing.

Files and Directories

Review the following questions to ensure that you are using NTFS permissions appropriately to secure the various files associated with an Enterprise Services application:

  • Is the COM+ catalog secured?

    The COM+ catalog maintains configuration data for COM+ applications. Make sure that the following folder that maintains the catalog files is configured with a restricted ACL.

    %windir%\registration

    Configure the following ACL:

    Administrators: Read, Write
System: Read, Write
Enterprise Services Run-As Account(s): Read

  • Are the CRM log files secured?

    If your application uses the Compensating Resource Manager, the CRM log files (.crmlog) should be secured with NTFS permissions because the log files may contain sensitive application data.

  • Are your application DLLs secured?

    Make sure that the folder used to hold the DLLs of your application is configured with the following restricted ACL.

    Users: Execute
Application Run as account: Execute
Administrators: Read, Write and Execute

    For more information, see Chapter 17, "Securing Your Application Server."

Authentication

Serviced components can be hosted in a library application that runs in the client's process address space or in a server application that runs in a separate instance of Dllhost.exe. This is determined by the activation type specified on the Activation page of the application's Properties dialog box in Component Services. The client process for an Enterprise Services library application is usually the ASP.NET Web application process.

The settings discussed below are specified on the Security page of the application's Properties dialog box in Component Services.

Server Applications

If the Activation type is set to Server application, review the following questions:

  • Do you prevent anonymous access?

    Check that your application uses at least call level authentication to ensure that clients are authenticated each time they make a method call. This prevents anonymous access.

  • What impersonation level do you use?

    Check to make sure that you use at least identify level impersonation to allow downstream systems to identify your serviced component. By default, this is the process identity determined by the run-as account of the application. If your serviced components use programmatic impersonation, this may be an impersonated identity. Use delegate level only if you want the downstream system to be able to access remote resources using your serviced component's identity.

Library Applications

If the activation type is set to Library application, the authentication and impersonation settings are inherited from the host process. The review questions in this section assume the ASP.NET process is the host process.

  • Have you disabled authentication?

    To check, view the Enable authentication check box setting on the Security page of the application's Properties dialog box. You should not disable authentication unless you have a specific requirement such as handling unauthenticated callbacks from a remote serviced component.

  • What authentication level do you use?

    The authentication level specified on the <processModel> element in Machine.config governs the authentication level used for outgoing calls to remote serviced components or DCOM components. The higher of this value and the value configured at the remote server is used. Check the comAuthenticationLevel setting on the <processModel> element:

  • What impersonation level do you use?

    This affects outgoing calls from the library component to other remote components. Check the comImpersonationLevel attribute on the <processModel> element in Machine.config.

    <processModel comImpersonationLevel=
              "Default|Anonymous|Identify|Impersonate|Delegate" .../>

Authorization

Serviced components in Enterprise Services applications use COM+ role based security to authorize callers. Review the following issues to ensure appropriate authorization:

  • Are access checks enabled?

    This controls whether or not COM+ authorization is enabled or not. Check that Enforce access checks for this application is selected on the Security page of the application's Properties dialog box in Component Services.

  • What security level do you use?

    Check the Security level specified on the Security page of the application's Properties dialog box in Component Services. Applications should use process and component level access checks to support granular authorization. This allows the application to use roles to control access to specific classes, interfaces, and methods.

    Note   Process and component level access checks must be enabled for library applications or you will not be able to use role-based authorization.

  • Do you enforce component level access checks?

    To support authorization checks at the component, interface, and method levels, each component must be appropriately configured in the COM+ catalog. Check each component in your application to ensure that Enforce component level access checks is selected on the Security page of the component's Properties dialog box.

Remote Serviced Components

The following issues apply if you use remote serviced components, and communication is across a network. A typical scenario is an ASP.NET client communicating with an Enterprise Services application on a remote application server.

  • Do you pass sensitive data?

    If so, what mechanism is in place to address the network eavesdropping threat? Make sure the link between client and server is encrypted at the transport level, for example, by IPSec. Alternatively, make sure your Enterprise Services application is configured for Packet Privacy level authentication, which forces the use of RPC encryption for all data packets sent to and from the application.

  • Do you communicate through a firewall?

    Enterprise Services uses DCOM, which in turn uses RPC communication. RPC communication requires port 135 to be open on the firewall. Review your firewall and Enterprise Services configuration to ensure that only the minimal additional ports is open.

    The range of ports dynamically allocated by DCOM can be restricted or static endpoint mapping can be used to specify individual ports. For more information, see Chapter 17, "Securing Your Application Server."

Remoting

This section identifies the key review points that should be considered when you review your application's use of .NET Remoting. For more information about the issues raised in this section see Chapter 17, "Securing Your Application Server."

When you review your .NET Remoting solution, start by identifying which host is used to run your remote components. If you use the ASP.NET host with the HttpChannel, you need to check that IIS and ASP.NET security is appropriately configured to provide authentication, authorization, and secure communication services to your remote components. If you use a custom host and the TcpChannel, you need to review how your components are secured, because this host and channel combination requires custom authentication and authorization solutions.

Note   In .NET 2.0, TcpChannel supports authentication and encryption, so you do not need a custom solution.

Port Considerations

Remoting is not designed to be used with Internet clients. Check that the ports that your components listen on are not directly accessible by Internet clients. The port or ports are usually specified on the <channel> element in the server side configuration file.

Hosting in ASP.NET with the HttpChannel

If you use the ASP.NET host, review the following items:

  • How do you protect sensitive data over the network?

    Do you use SSL or IPSec? Without SSL or IPSec, data passed to and from the remote component is subject to information disclosure and tampering. Review what measures are in place to address the network eavesdropping threat.

  • How do you authenticate callers?

    Make sure that anonymous access is disabled in IIS for your application's virtual directory. Also check that you use Windows authentication. The Web.config of your application should contain the following configuration.

    <authentication mode="Windows" />

  • Do you use ASP.NET file authorization?

    If not, why? You can use ASP.NET file authorization to control access to the endpoints of your remoting application by creating a .rem or .soap file and configuring the NTFS permissions on the file. The ASP.NET FileAuthorizationModule will then authorize access to the component. For more information, see "Authorization" in Chapter 13, "Building Secure Remoted Components."

  • Do you use URL authorization?

    Check your application's use of the <authorization> element. Use the ASP.NET UrlAuthorizationModule by applying <allow> and <deny> tags.

  • Do you prevent detailed errors from being returned to the client?

    Check the configuration of your application to make sure that you have correctly configured the <customErrors> element to prevent detailed errors from being returned to the client. Make sure the mode attribute is set to On as shown below.

    <customErrors mode="On" />

  • What identity do you use to run ASP.NET?

    Check that you use a least privileged account to run ASP.NET, such as the default ASPNET account, or Network Service account on Windows Server 2003.

Hosting in a Custom Process with the TcpChannel

If you use a custom host process such as a Windows service, review the following items.

Note   In .NET 2.0, TcpChannel supports authentication and encryption, so you do not need a custom solution.

  • How do you protect sensitive data over the network?

    Have you secured the channel from client to server? You may use transport level IPSec encryption or your application may use a custom encryption sink to encrypt request and response data.

  • How do you authenticate callers?

    The TcpChannel provides no authentication mechanism, so you must develop your own. Review how your application authenticates its callers.

  • Do you restrict your clients?

    Remoting with the TcpChannel is designed to be used in trusted server scenarios, where the remote components trust their clients. Do you restrict the range of clients that can connect to your remote components, for example, by using IPSec policies?

  • Do you use a least privileged process identity?

    Review which account you use to run your custom host process and ensure it is configured as a least privileged account.

Database Server Configuration

The goal for this phase of the review is to identify vulnerabilities in the configuration of your SQL Server database server. For further background information about the issues raised by the review questions in this section, see Chapter 18, "Securing Your Database Server."

To help focus and structure the review process, the review questions have been divided into the following configuration categories:

  • Patches and updates
  • Services
  • Protocols
  • Accounts
  • Files and directories
  • Shares
  • Ports
  • Registry
  • Auditing and logging
  • SQL Server security
  • SQL Server logins, users, and roles

Patches and Updates

Check that your server is updated with the latest service packs and software patches. This includes service packs and patches for the operating system and SQL Server.

Make sure you have run the Microsoft Baseline Security Analyzer (MBSA) tool to identify common Windows and SQL Server vulnerabilities, and to identify missing service packs and patches.

Respond to the MBSA output by fixing identified vulnerabilities and by installing the latest patches and updates. For more information, see "Step 1. Patches and Updates" in Chapter 18, "Securing Your Database Server."

Services

Make sure that only those services that you require are enabled. Check that all others are disabled to reduce the attack surface of your server.

  • Which SQL Server services do you run?

    SQL Server installs four services. If you require just the base functionality, then disable Microsoft Search Service, MSSQLServerADHelper, and SQLServerAgent to reduce the attack surface of your server.

  • Do you use distributed transactions?

    If your applications use the transactional services of COM+ to manage transactions with SQL Server, then the Microsoft Distributed Transaction Coordinator (DTC) service is required on the database server.

    If you do not use distributed transactions, ensure that the DTC service is disabled.

Protocols

By preventing the use of unnecessary protocols, you reduce the attack surface area. Review the following questions:

  • For which protocols is SQL Server configured?

    SQL Server supports multiple protocols. Use the Server Network Utility to check that only TCP/IP protocol support is enabled.

  • Have you hardened the TCP/IP stack?

    To check whether the stack is hardened on your server, use Regedt32.exe and examine the following registry key:

    HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

    The presence of the following child keys indicates a hardened TCP/IP stack: SynAttackProtect, EnableICMPRedirect, and EnableReadGWDetect.

    For a full list of the required keys and appropriate key values for a fully hardened stack, see "How To: Harden the TCP/IP Stack" in the How To section of this guide.

Accounts

Review the accounts used on your database server by answering the following questions:

  • Do you use a least privileged account to run SQL Server?

    Review which account you use to run SQL Server and make sure it is a least privileged account. It should not be an administrative account or the powerful local system account. Also make sure that the account is not a member of the Users group on the local computer.

  • Have you deleted or disabled unused accounts?

    Audit local accounts on the server and check that all unused accounts are disabled.

  • Have you disabled the Guest account?

    Check that the Windows Guest account is disabled to restrict anonymous connections to your database server.

  • Have you created a new administrator account?

    The default local administrator account is a prime target for attack. To improve security, check that you have created a new custom account for administration and that the default Administrator account has been disabled.

  • Do you use strong password policies?

    Use the Local Security Policy tool to review password policy. For information about the recommended password policy, see "Step 4. Accounts" in Chapter 18, "Securing Your Database Server."

  • Do you restrict remote logons?

    Check the user rights assignments within the Local Security Policy tool to ensure that the Everyone group is not granted the "Access this computer from the network" user right.

  • Have you disabled null sessions?

    Check that null sessions are disabled to prevent anonymous (unauthenticated) sessions from being created with your server. To check this, run Regedt32.exe and confirm that the RestrictAnonymous key is set to 1, as shown below.

    HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous=1

  • Do clients connect by using Windows authentication?

    If so, check that the strongest version of NTLM authentication (NTLMv2) is enabled and enforced. To check that NTLMv2 authentication is enforced, use the Local Security Policy Tool. Expand LocalPolicies and select SecurityOptions and then double-click LAN Manager Authentication Level. Verify that Send NTLMv2 response only\refuse LM & NTLM is selected.

Files and Directories

The following review questions enable you to verify that you have used NTFS permissions appropriately on your database server.

  • Have you configured permissions on the SQL Server install directories?

    Review the permissions on the SQL Server installation directories and make sure that the permissions grant limited access. For detailed permissions, see "Step 5. Files and Directories" in Chapter 18, "Securing Your Database Server."

  • Have you removed Everyone permissions for SQL Server files?

    Review the permissions on the SQL Server file location (by default, \Program Files\Microsoft SQL Server\MSSQL) and check that the Everyone group has been removed from the directory ACL. At the same time, make sure that full control has been granted to only the SQL Service account, the Administrators group, and the local system account.

  • Have you secured setup log files?

    If you have installed SQL Server 2000 Service Pack 1 or 2, the system administrator or service account password may be left in the SQL installation directory. Make sure that you have used the Killpwd.exe utility to remove instances of passwords from the log files.

    For information about obtaining and using this utility, see Microsoft Knowledge Base article 263968, "FIX: Service Pack Installation May Save Standard Security Password in File."

Shares

Review the following questions to ensure that your server is not unnecessarily exposed by the presence of file shares:

  • What shares are available on your server?

    To review shares and associated permissions, run the Computer Management MMC snap-in and select Shares beneath SharedFolders. Check that all the shares are required. Remove any unnecessary shares.

  • Can the Everyone group access shares?

    Check that the Everyone group is not granted access to your shares unless intended, and that specific permissions are configured instead.

  • Have you removed the administration shares?

    If you do not allow remote administration of your server, then check that the administration shares, for example, C$ and IPC$, have been removed.

    Note   Some applications may require administrative shares. Examples include Microsoft Systems Management Server (SMS) and Microsoft Operations Manager (MOM). For more information, see Microsoft Knowledge Base article 318751, "How To: Remove Administrative Shares in Windows 2000 or Windows NT4."

Ports

Review the ports that are active on your server to make sure that no unnecessary ports are available. For more information about using the netstat command to do this, see the "Ports" subsection in "Web Server Configuration," earlier in this chapter. Then review the following questions:

  • Have you restricted access to the SQL Server port?

    Review how you restrict access to the SQL Server port. Check that your perimeter firewall prevents direct access from the Internet. To protect against internal attacks, review your IPSec policies to ensure they limit access to the SQL Server ports.

  • Have you configured named instances to listen on the same port?

    If you use named instances, check with the Network Server Utility to verify that you have configured the instance to listen on a specific port. This avoids UDP negotiation between the client and server, and means you do not need to open additional ports.

Registry

Review the security of your registry configuration with the following questions:

  • Have you secured the SQL Server registry keys?

    Use Regedt32.exe to check that the Everyone group has been removed from the ACL attached to the following registry key.

    Administrators: Full Control
SQL Server service account: Full Control

  • Have you secured the SAM?

    Check that you have restricted LMHash storage in the Security Account Manager (SAM) by creating the key (not value) NoLMHash in the registry as shown below.

    HKLM\System\CurrentControlSet\Control\LSA\NoLMHash

    For more information, see Microsoft Knowledge Base article 299656, "New Registry Key to Remove LM Hashes from Active Directory and Security Account Manager".

Auditing and Logging

Review the following questions to check whether or not you have used appropriate auditing and logging on your database server.

  • Have you enabled SQL Server auditing?

    Check that SQL Server auditing is enabled. Make sure that the Audit level setting on the Security page of the SQL Server Properties dialog box in Enterprise Manager is set to either All or Failure.

  • Do you log all failed logon attempts?

    Use the Local Security Policy tool to check that you have enabled the auditing of failed logon attempts.

  • Do you log all failed actions across the file system?

    Use the Local Security Policy tool to check that you have enabled object access auditing. Then check that auditing has been enabled across the file system.

SQL Server Security

Review which authentication mode your SQL Server is configured to use. You can see this by viewing the Security page of your server's Properties dialog box in Enterprise Manager. If your server is configured to support SQL Server and Windows authentication, check that your applications do require SQL authentication. If possible, use Windows only authentication.

If your applications do require SQL authentication, review how they manage database connection strings. This is important if they use SQL authentication because they contain user name and passwords. Also ensure that a server certificate is installed on the database server to ensure that credentials are encrypted when they are passed over the network to the database server, or that transport level encryption is used.

SQL Server Logins, Users, and Roles

Authorization in SQL Server is managed through SQL Server logins, database users, and a variety of different types of roles. Review the following questions to ensure these roles are configured appropriately:

  • Do you have a strong sa (system administrator) password?

    Make sure the sa account has a strong password.

    Important   The sa account is still active even when you change from SQL authentication to Windows authentication.

    Also make sure you have applied strong passwords to all database accounts, particularly privileged accounts, for example, members of sysadmin and db_owner. If you use replication, check that the distributer_admin account has a strong password.

  • Have you removed the SQL Server guest account?

    If when you installed SQL Server the Windows Guest account was enabled, a SQL Server guest account is created. Check each database and ensure that the SQL Server guest account is not present. If it is, remove it.

    Note   You cannot remove guest from the master, tempdb, and replication and distribution databases.

  • Have you removed the BUILTIN\Administrators server login?

    If your company differentiates the role of domain administrator and database administrator, remove the BUILTIN\Administrators SQL Server login. It is a good idea to create a specific Windows group containing specific database administrations in its place.

  • Have you removed permissions for the public role?

    Review the permissions granted to the public role in each database. Make sure it has no permissions to access any database objects.

  • How many members are there that belong to the sysadmin role?

    Check how many logins belong to the sysadmin role. Ideally, no more than two users should be system administrators.

  • Do you grant restricted database permissions to logins?

    Review the permissions granted to each database user account and make sure that each account (including application accounts) only has the minimum required permissions.

SQL Server Database Objects

Review the following questions to ensure that you have removed unnecessary database objects, including the sample databases, and that stored procedures are appropriately secured.

  • Have you removed sample databases?

    Use SQL Server Enterprise Manager to check that all sample databases, including Pubs and Northwind, have been removed.

  • Have you secured stored procedures?

    Check to make sure that neither the public role nor the guest user has access to any of your stored procedures. To authorize access to stored procedures, you should map the SQL Server login of your server to a database user, place the database user in a user-defined database role, and then apply permissions to this role to provide execute access to the stored procedures of your application.

  • Have you restricted access to cmdExec?

    The cmdExec function is used by the SQL Server Agent to execute Windows command-line applications and scripts that are scheduled by the SQL Server Agent. Check that access to cmdExec is restricted to members of the sysadmin role.

    To check this, use SQL Server Enterprise Manager to expand the Management node. Right-click SQL Server Agent and display the SQL Server Agent Properties dialog box. Click the Job System tab and check that Only users with SysAdmin privileges can execute CmdExec and ActiveScripting job steps is selected.

Network Configuration

The goal for this phase of the review is to identify vulnerabilities in the configuration of your network. For further background information about the issues raised by the review questions in this section, see Chapter 15, "Securing Your Network."

To help focus and structure the review process, the review questions have been divided into the following configuration categories:

  • Router
  • Firewall
  • Switch

Router

Use the following questions to review your router configuration:

  • Have you applied the latest patches and updates?

    Check with the networking hardware manufacturer to ensure you have the latest patches.

  • Do you use Ingress and Egress filtering?

    For more information, see "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing," at http://www.rfc-editor.org/rfc/rfc2267.txt.

  • Do you block ICMP traffic?

    Make sure you block Internet Control Message Protocol (ICMP) traffic at the outer perimeter router to prevent attacks such as cascading ping floods and other potential ICMP vulnerabilities.

  • Do you prevent time-to-live (TTL) expired messages with values of 0 or 1?

    This prevents information disclosure caused by route tracing.

  • Do you receive or forward broadcast traffic?

    Source addresses that should be filtered are shown in Table 22.1.

    Table 22.1   Source Addresses that Should Be Filtered

Source Address Description
0.0.0.0/8 Historical broadcast
10.0.0.0/8 RFC 1918 private network
127.0.0.0/8 Loopback
169.254.0.0/16 Link local networks
172.16.0.0/12 RFC 1918 private network
192.0.2.0/24 TEST-NET
192.168.0.0/16 RFC 1918 private network
224.0.0.0/4 Class D multicast
240.0.0.0/5 Class E reserved
248.0.0.0/5 Unallocated
255.255.255.255/32 Broadcast

  • Have you disabled unused interfaces?

    Make sure that only the required interfaces are enabled on the router.

  • Do you use strong password policies?

    You should use strong password policies to mitigate the risks posed by brute force and dictionary attacks.

  • Do you use static routing?

    By using static routes, an administrative interface must first be compromised to make routing changes.

  • Do you audit Web facing administrative interfaces?

    When possible, shut down the external administration interface and use internal access methods with ACLs.

  • Do you use the logging features of your router?

    Check that your routers log all deny actions.

  • Do you use an Intrusion Detection System?

    Intrusion Detection Systems (IDSs) can show where the perpetrator is attempting attacks.

Firewall

Use the following questions to review your router configuration:

  • Have you applied the latest patches and updates?

    Check with the networking hardware manufacturer to ensure you have the latest patches.

  • Do you log all traffic that flows though the firewall?

  • How often do you cycle logs?

    Ensure that you maintain healthy log cycling that allows quick data analysis.

  • Is the firewall clock synchronized with the other network hardware?

Switch

Use the following questions to review your router configuration:

  • Have you applied the latest patches and updates?

    Check with the networking hardware manufacturer to ensure that you have the latest patches.

  • Have you disabled factory default settings?

    To make sure that insecure defaults are secured, check that you have changed all factory default passwords and Simple Network Management Protocol (SNMP) community strings to prevent network enumeration or total control of the switch.

  • Have you disabled unused services?

    Make sure that all unused services are disabled. Also, make sure that Trivial File Transfer Protocol (TFTP) is disabled, Internet-facing administration points are removed, and ACLs are configured to limit administrative access.

Summary

When you perform a deployment review, make sure that you review the configuration of the underlying infrastructure on which the application is deployed and the configuration of the application itself. Review the network, host, and application configuration and, where possible, involve members of the various teams including infrastructure specialists, administrators and developers.

Use the configuration categories identified in this chapter to help focus the review. These categories include patches and updates, services, protocols, accounts, files and directories, shares, ports, registry, and auditing and logging.

patterns & practices Developer Center

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.