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.

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.

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

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.

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

Reference

Concepts

Other Resources