How To: Secure Your Developer Workstation

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

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 How To helps you improve your development workstation security. Developers often have computers running software such as IIS, Microsoft SQL Server, or the Microsoft SQL Server Desktop Engine (MSDE.) For example, Microsoft Visual Studio® .NET is designed for local development with IIS, so it is common for a developer to run IIS locally. As a developer, you need to be able to secure these services against attack, even if your computer is in a protected local area network.

This How To provides quick tips to help you improve the security of your developer workstation, along with tips about how to keep it secure. It also helps you avoid common problems that you are likely to encounter when you secure your workstation. Finally, it provides tips about how to determine problems and to revert security settings if they prove too restrictive.

Note   This How To is not exhaustive, but it highlights many of the key issues.

Contents

Before You Begin Steps to Secure Your Developer Workstation Run using a least privileged account Patch and update Secure IIS Pitfalls Secure SQL Server and MSDE Evaluate your configuration categories Stay secure

Before You Begin

Before you begin securing your workstation, you need the following tools:

• Microsoft Baseline Security Analyzer (MBSA). Microsoft provides the MBSA tool to help analyze the security configuration of your computers and to identify missing patches and updates. You can download the MBSA tool from https://technet.microsoft.com/en-us/security/cc184924.aspx.

• IISLockdown. The IISLockdown tool reduces your computer's attack surface by hardening default IIS and Windows configuration settings and by removing unnecessary IIS extensions. IISLockown also installs the "404.dll" ISAPI filter, which is used to report "404 File Not Found" messages when disabled extensions are requested.

  You can download the IISLockdown tool from https://download.microsoft.com/download/iis50/Utility/2.1/NT45XP/EN-US/iislockd.exe.

• URLScan. URLScan is an ISAPI filter that rejects or allows HTTP requests based on a configurable set of rules. It is integrated with IISLockdown, although you can also download it separately. It comes with customizable templates for each supported server role.

  To install URLScan without IISLockdown, see Microsoft Knowledge Base article 307608, "INFO: Availability of URLScan Version 2.5 Security Tool," at https://support.microsoft.com/default.aspx?scid=kb;en-us;307608, in the Microsoft Knowledge Base.

Steps to Secure Your Developer Workstation

To secure your developer workstation, perform the following tasks:

• Run using a least privileged account
• Patch and update
• Secure IIS
• Secure SQL Server and MSDE
• Evaluate your configuration categories
• Stay secure

Run Using a Least-Privileged Account

You should develop applications using a non administrator account. Doing so is important primarily to limit the exposure of the logged on user and to help you to design more secure software. For example, if you design, develop, and test an application while you are interactively logged in as an administrator, you are much more likely to end up with software that requires administrative privileges to run.

You should not generally log on using the local administrator account. The account that you use on a daily basis should not be a member of the local Administrators group. Sometimes you might still need an account that has administrative privileges — for example, when you install software or edit the registry. Because the default local administrator account is well known, however, and it is the target of many attacks, create a non-standard administrator account and use this only when it is required.

To create accounts for development

1. Remove your current user account from the Administrators group if it is a member.
2. Create a new custom administration account using a nonstandard name and strong password.
3. Use your non-administrator account to logon interactively on a daily basis. When you need to run a command with administrative privileges, use your custom administration account with the Runas.exe command line utility.

Running Privileged Commands

To run a privileged command, you can use one of the following techniques to temporarily change your security context:

• Use the Runas.exe utility from a command line. The following command shows you how to use the Runas.exe utility to launch a command console that runs under your custom administration account.

  runas.exe /user:mymachine\mycustomadmin cmd.exe
  

  By executing Cmd.exe, you start a new command window that runs under the security context of the user you specify with the /user switch. Any program you launch from this command window also runs under this context.

• Use Run As from Windows Explorer. You can right-click an executable file in Windows Explorer and click Run As. To display this item on Windows 2000 or Windows Server 2003, hold down the SHIFT key and then right-click an executable file. When you click Run As, you are prompted for the credentials of the account you want to use to run the executable file.

• Use Run As shortcuts. You can create quick launch and desktop shortcuts to easily run applications using a privileged user account. The following example shows a shortcut that you can use to run Windows Explorer (Explorer.exe) using the administrator account:

  %windir%\System32\runas.exe /user:administrator explorer
  

Note   If using a non-administrator account proves impractical for your environment, still test your application or component while running as a least privileged user to catch and correct problems before deploying. For example, your application might incorrectly require administrator privileges without your realizing it, which would cause the application to fail when it is deployed in a production environment.

More Information

For more information about developing with a non-administrative account, see the following articles:

• "A .NET Developer's Guide to Windows Security," at http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook.HomePage
• "Developing Software in Visual Studio .NET with Non-Administrative Privileges," at https://msdn.microsoft.com/en-us/library/aa289173(VS.71).aspx

Patch and Update

Ensure that your workstation has the latest service packs and patches. Check the operating system, IIS, SQL Server, MSDE, Microsoft Data Access Components (MDAC), and the .NET Framework. Microsoft offers several tools and methods to help you scan and update your system. These include the Windows Update site, the Microsoft Baseline Security Analyzer (MBSA) tool, and the Automatic Updates feature.

Using Windows Update

You can use Windows Update (available from the Start menu) to scan for updates and patches for Windows. Alternatively, you can directly scan for updates at https://windowsupdate.microsoft.com.

Note   After you update your system using the Windows Update site, use MBSA to detect missing updates for SQL Server, MSDE, and MDAC.

Using MBSA

You can use MBSA to assess security and to verify patches. If you used automatic updates or Windows Update to update your operating system and components, MBSA verifies those updates and additionally checks the status of updates for SQL Server and Microsoft Exchange Server. MBSA lets you create a script to check multiple computers.

To detect and install patches and updates

1. Download MBSA from the MBSA home page at https://www.microsoft.com/technet/security/tools/mbsahome.asp.

   If you do not have Internet access when you run MBSA, MBSA cannot retrieve the XML file that contains the latest security settings from Microsoft. You can use another computer to download the XML file, however. Then you can copy it into the MBSA program directory. The XML file is available at https://technet.microsoft.com/en-us/security/cc184923.aspx.

2. Run MBSA by double-clicking the desktop icon or selecting it from the Programs menu.

3. Click Scan a computer. MBSA defaults to the local computer.

4. Clear all check boxes except for Check for security updates. This option detects which patches and updates are missing.

5. Click Start scan. Your server is now analyzed. When the scan completes, MBSA displays a security report, which it also writes to the %Userprofile%\SecurityScans directory.

6. Download and install the missing updates. Click Result details next to each failed check to view the list of missing security updates.

   The resulting dialog box displays the Microsoft security bulletin reference number. Click the reference to find out more about the bulletin and to download the update.

For more information about using MBSA, see "How To: Use Microsoft Baseline Security Analyzer (MBSA)," in the How To section of this guide.

Note   MBSA will not indicate required .NET Framework updates and patches. Browse the .NET Framework downloads page at https://msdn.microsoft.com/en-us/netframework/aa569263.aspx.

Using Automatic Updates

The Automatic Updates feature offers the easiest method to update your operating system with the latest critical security patches. The feature is built into Windows XP, Windows Server 2003 and is installed with Windows 2000 Service Pack 3.

To configure Automatic Updates with Windows 2000, click Automatic Updates in the Control Panel. For more information about Automatic Updates and Windows 2000, see Microsoft Knowledge Base article 327850, "How To: Configure and Use Automatic Updates in Windows 2000."

To configure Automatic Updates with Windows XP

1. Right-click the My Computer icon on the desktop or the System icon in Control Panel.
2. Click System Properties.

For more information about Automatic Updates and Windows XP, see Microsoft Knowledge Base article, 306525, "How To: Configure and Use Automatic Updates in Windows XP."

Note   For more information about Automatic Updates for Windows Server 2003, see Microsoft Knowledge Base article 327838, "How to schedule automatic updates in Windows Server 2003, in Windows XP, and in Windows 2000."

Automatic Updates scans and installs updates for the following operating systems (including the .NET Framework and IIS where applicable):

• Microsoft Windows 2000 Professional
• Microsoft Windows 2000 Server
• Microsoft Windows XP Professional
• Microsoft Windows Server 2003

In addition to using Automatic Updates, use MBSA to detect missing updates for SQL Server, MSDE and MDAC.

Secure IIS

You often need to run IIS locally for Web development. If you run IIS, secure it. IISLockdown and URLScan significantly reduce your Web server's attack profile. IISLockdown points unused or forbidden script mappings to 404.dll and helps secure access to system directories and system tools. URLScan blocks known dangerous requests.

Although IISLockdown improves IIS security, if you choose the wrong installation options or do not modify the URLScan configuration file, URLScan.ini, you could encounter the following issues:

• You cannot create new ASP.NET Web applications. NTFS file system permissions are configured to strengthen default access to Web locations. This may prevent the logged on user from creating new ASP.NET Web applications.
• Cannot debug existing ASP.NET Web applications. URLScan blocks the DEBUG verb, which is used when you debug ASP.NET Web applications.

The following steps show you how to improve IIS security on your development workstation and avoid the issues listed above:

• Install and run IISLockdown
• Configure URLScan
• Restrict access to the local Web server

Install and Run IISLockdown

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. However, 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.

To install and run IISLockdown

1. Run the IISLockdown installation program (Iislockd.exe) from https://download.microsoft.com/download/iis50/Utility/2.1/NT45XP/EN-US/iislockd.exe.

   Note   If you run Iislockd.exe a second time, it removes all changes based on the log file \WINNT\System32\Inetsrv\oblt-log.log.

2. During setup, choose the Dynamic Web Site option, and choose the option to install URLScan. ASP.NET Web Forms use the HTTP POST verb. Choosing the static option and installing URLScan blocks the POST verb in URLScan.ini.

   The Dynamic Web Site option does the following:

   • Adds POST to the [AllowVerbs] section as shown below.

     [AllowVerbs]
     GET
     HEAD
     POST
     

   • Disables the following Internet Services: Web service (HTTP), File Transfer Protocol (FTP), the Simple Mail Transport Protocol (SMTP) e-mail service, and the Network News Transport Protocol (NNTP) news service.

   • Maps the following script maps to 404.dll: Index Server, Web Interface (.idq, .htw, .ida), server side includes (.shtml, .shtm, .stm), Internet Data Connector (.idc), HTR scripting (.htr), Internet printing (.printer)

   • Removes the following virtual directories: IIS Samples, MSADC, IISHelp, Scripts, and IISAdmin.

   • Restricts anonymous access to system utilities and the ability to write to Web content directories.

   • Disables Web Distributed Authoring and Versioning (WebDAV).

   • Installs the URLScan ISAPI filter.

Pitfalls

If you use IISLockdown, note the following pitfalls:

• IISmetabase updates can be lost. If you undo IISLockdown changes by running Iislockd.exe a second time, you lose any changes made to the IIS metabase since the last time IISLockdown was run. For example, if you configure a virtual directory as an application root after running IIS lockdown, that change is lost when you run IISLockdown again.
• Resources are blocked by 404.dll. If you receive a 404 error for a previously available resource, it might be because the resource type is blocked by 404.dll. To confirm whether or not this is the case, check the script mapping for the requested resource type in IIS.

Configure URLScan

The URLScan ISAPI filter installs when you run IISLockdown. If you do not explicitly allow the DEBUG verb, URLScan prevents debugging. Also, URLScan blocks requests that contain unsafe characters such as the period (.) used for directory traversal.

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

To configure URLScan, edit URLScan.ini in %Windir%\System32\inetsrv\urlscan\. To allow debugging with URLScan, add DEBUG to the [AllowVerbs] section in URLScan.ini as shown below.

[AllowVerbs]
GET
HEAD
POST
DEBUG

Pitfalls

If you install URLScan, note the following pitfalls:

• When you debug an application by using Visual Studio.NET, you may see the following error:

  Microsoft Development Environment:
  Error while trying to run project: Unable to start debugging on the Web server. Could not start ASP.NET or ATL Server debugging.
  Verify that ASP.NET or ATL Server is correctly installed on the server. Would you like to disable future attempts to debug ASP.NET pages for this project?
  

  You should see a log entry similar to the one shown below in URLScan<date>.log in the \WINNT\system32\inetsrv\urlscan folder.

  [01-18-2003 - 22:25:26] Client at 127.0.0.1: Sent verb 'DEBUG', which is not specifically allowed. Request will be rejected.
  

• Requests that you expect to work might get blocked.

• You may not be able to create new Web projects in Visual Studio .NET because you use characters in the project name that URLScan rejects. For example, the comma (,) and the pound sign (#) will be blocked.

If you experience errors during debugging, see Microsoft Knowledge Base article 306172, "INFO: Common Errors When You Debug ASP.NET Applications in Visual Studio .NET," at https://support.microsoft.com/default.aspx?scid=kb;EN-US;306172.

Secure SQL Server and MSDE

To update SQL Server and MSDE, you must:

• Apply patches for each instance of SQL Server and MSDE
• Analyze SQL Server and MSDE security configuration

Apply Patches for Each Instance of SQL Server and MSDE

MSDE shares common technology with SQL Server, and it enables developers, partners, and IT professionals to build database applications without requiring the full SQL Server product. MSDE can be packaged with applications that require database support. To apply patches to MSDE, you must know which application installed it on your system. This is important because you must obtain the patch for MSDE from the product vendor.

For more information on applications that include MSDE, refer to the following resources:

• "Microsoft Products That Include MSDE," at https://www.microsoft.com/technet/security/bulletin/msdeapps.mspx
• "SQL Server/MSDE-Based Applications," at http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=31

If your third-party vendor does not supply a patch for MSDE, and if it becomes critical to have the latest patches, you can only do the following:

• Uninstall the instance of SQL Server using Add/Remove Programs. If you do not see an uninstall option for your instance, you might need to uninstall your application.

• Stop the instance of SQL Server using the Services MMC snap-in in Computer Management. You can also stop the instance from the command line by running the following command:

  net stop mssqlserver (default instance), mssql$instancename (for instances)
  

• Use IPSec to limit which hosts can connect to the abandoned (unpatched) instances of SQL Server. Restrict access to localhost clients.

Analyze SQL Server and MSDE Security Configuration

Use MBSA to analyze your Microsoft SQL Server or MSDE configuration on your workstation.

To analyze SQL Server and MSDE security configuration

1. Run MBSA by double-clicking the desktop icon or selecting it from the Programs menu.

2. Click Scan a computer. MBSA defaults to the local computer.

3. Clear all check boxes except for Check for SQL vulnerabilities.

   This option scans for security vulnerabilities in the configurations of SQL Server 7.0, SQL Server 2000, and MSDE. For example, it checks the authentication mode, the sa account password, and the SQL Server service account, among other checks.

   A number of the checks require that your instance of SQL Server is running. If it is not running, start it.

4. Click Start scan. Your configuration is now analyzed. When the scan completes, MBSA displays a security report, which it also writes to the %Userprofile%\SecurityScans directory.

5. Review the failed checks, and fix vulnerable configuration settings.

   Click Result details next to each failed check for more information about why the check failed. Click How to correct this, for information about how to fix the vulnerability.

For more information about using MBSA, see "How To: Use Microsoft Baseline Security Analyzer (MBSA)," in the How To section of this guide.

Evaluate Your Configuration Categories

To evaluate the security of your workstation configuration, review the configuration categories shown in Table 6. Start by using the categories to evaluate the security configuration of the base operating system. Then apply the same configuration categories to review your IIS, SQL Server, and .NET Framework installation.

Table 6   Configuration Categories

Stay Secure

Monitor the security state of your workstation, and update it regularly to help prevent newly discovered vulnerabilities from being exploited. In addition to using Windows Update, subscribe to the Microsoft Technical Security Notification Services, at https://profile.microsoft.com/RegSysProfileCenter/subscriptionwizard.aspx?wizid=5a2a311b-5189-4c9b-9f1a-d5e913a26c2e&lcid=1033, to register for regular e-mail bulletins that notify you of new fixes and updates.

You can also use the "Microsoft Security Bulletin Search," at https://www.microsoft.com/technet/security/current.asp, on the TechNet Web site. This allows you to view the security bulletins that are available for your system.

© Microsoft Corporation. All rights reserved.