Securing ASP.NET Health Monitoring
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:
Monitor live ASP.NET applications, individually or across a Web farm.
Monitor the performance of an ASP.NET application to ensure that it is healthy.
Diagnose ASP.NET applications that appear to be failing.
Log interesting events that do not necessarily relate to errors in an ASP.NET application.
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.
.gif "Note") Note |
|---|
When implementing custom event consumers or custom event providers you need to encode or check event contents as appropriate to avoid cross site scripting issues. |
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.
| Note |
|---|
When implementing custom event consumers or custom event providers you need to encode or check event contents as appropriate to avoid cross site scripting issues. |
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. |
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.
Exceptions
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
Reference
healthMonitoring Element (ASP.NET Settings Schema)
Concepts
Other Resources
Encrypting Configuration Information Using Protected Configuration