JavaScript Editor jscript editor     Web designer 

Main Page

ASP.NET health monitoring provides an easy way to monitor the health of ASP.NET applications, providing administrators with detailed run-time information about ASP.NET resources. ASP.NET health monitoring features can be used to perform the following tasks:

This topic describes how to optimize the security of the health monitoring feature through best practices when configuring health monitoring and coding with the monitoring API.

Following these best practices can improve the security of your application; however, it is also important that you continually keep your application server up to date with the latest security patches for Microsoft Windows and Internet Information Services (IIS), as well as any patches for Microsoft SQL Server or other membership data sources.

For more information about best practices for writing secure code and securing applications, see the book Writing Secure Code by Michael Howard and David LeBlanc and the guidance provided by Microsoft Patterns and Practices.

Secure Health Monitoring Configuration

The health monitoring feature is enabled by default for ASP.NET applications and can be disabled by setting the enabled attribute of the healthMonitoring element to false. The default configuration settings are set to the most secure values. For more information about health monitoring configuration settings and their default values, see healthMonitoring. Consider locking the health monitoring configuration settings using the location Element (ASP.NET Settings Schema) element. For details, see How to: Lock ASP.NET Configuration Settings.

Securing Configuration Values

When storing sensitive information in a configuration file for an application, you should encrypt the sensitive values using Protected Configuration. Information that is especially sensitive includes the encryption keys stored in the machineKey configuration element, and connection strings to a data source stored in the connectionStrings configuration element. For more information, see Encrypting Configuration Information Using Protected Configuration.

Programmatic Configuration

The health monitoring configuration section (healthMonitoring) is accessible only by code that uses medium trust or higher, preventing low-trust applications from registering custom types.

Extending Health Monitoring

The health monitoring types in the System.Web.Management namespace have the following characteristics:

  • Base class constructors are protected internal, so instances of base class event types cannot be created directly by user code.

  • Access to Web event instances is limited to configuration-specified providers, filters, and template pages.

  • Inheritance link demands on events with protected content ensure that only fully trusted custom events can be derived.

  • Custom trusted events that expose sensitive data from protected event properties must enforce code access security themselves to avoid luring attacks. For details about code access security, see ASP.NET Code Access Security or Code Access Security Basics.

  • The Windows Management Instrumentation (WMI) types that are used to view Web events are locked down to prevent all users from accessing event data.

Securing Connections to Data Sources

You can create custom health monitoring event providers to log event data to a database. ASP.NET comes with a SQL provider. For more information, see Securing Data Access.

To keep the connection to your database server secure, you should encrypt connection-string information in the configuration file using Protected Configuration. For more information, see Encrypting Configuration Information Using Protected Configuration.

When using a SQL provider, the database must be secured appropriately by authentication. Microsoft SQL Server Express mountable files must be properly secured by access control lists (ACLs) and SQL authentication.


SQL Server Express should not be run under a normal (non-privileged) account when logging events.

Securing Against Denial of Service Attacks

Web events can be triggered by an HTTP request or application code that generates exceptions or events. Event-provider capacity can be exceeded by a high volume of events, or large events. The ASP.NET application or server can be overwhelmed by a high volume of events, which might affect memory usage, disk space, and increased network traffic.

To reduce your application's exposure to a denial of service attack, ASP.NET uses the following default design:

  • ASP.NET measures out one instance of an event per minute. This throttling frequency is configured in the profiles element and associated with events and providers in the rules element.

  • Event buffering is isolated for each provider type to prevent competitions for buffer space. Buffer settings are configured in the bufferModes element. Providers can be configured to use a specific set of buffer settings by specifying the bufferModes element that contains the settings required for that provider.

  • To raise a custom event, medium or higher trust is required.

As a system administrator, you can use the same methods above to appropriately configure throttling and buffering settings to avoid overflow, especially for events that can be triggered by HTTP requests. Additionally, you can set up separate buffer modes to deal with important and unimportant events.

Error Messages and Events

The following sections discuss how you can mitigate potential security risks that are exposed by unexpected error messages and events.


To prevent sensitive information from being exposed to unwanted sources, configure your application either to not display detailed error messages, or to display detailed error messages only when the client is the Web server itself. For more information, see customErrors Element (ASP.NET Settings Schema).

Event Log

By default, ASP.NET logs high-volume, exceptional, per-request Web events to the performance monitoring system. In the default configuration, this means that failed login attempts will record user-name and other diagnostic information in the Application event log. This data can be viewed in the Event Viewer. If your server is running Microsoft Windows ServerВ 2003, you can improve the security of your application by securing the event log, and by setting parameters regarding the size, retention, and other characteristics of the event log to prevent an indirect denial of service attack against it.

See Also


healthMonitoring Element (ASP.NET Settings Schema)


Securing Data Access

Other Resources

Encrypting Configuration Information Using Protected Configuration

JavaScript Editor jscript editor     Web designer