To read the article online, visit http://www.4GuysFromRolla.com/articles/032107-1.aspx

Health Monitoring in ASP.NET 2.0: Notifications via Email

By Scott Mitchell


Introduction


The Health Monitoring system in ASP.NET 2.0 is designed to monitor the health of a running ASP.NET application in a production environment. It works by recording event information to a specified log source. The .NET 2.0 Framework includes a variety of built-in events that can be used by the Health Monitoring system, including events for monitoring application re-starts and stops, unhandled exceptions, and failed authentication attempts, among others. The .NET Framework also include support for logging these events to the Windows event log, to a Microsoft SQL Server database, via WMI, in an email, and to the ASP.NET page tracing system. As we saw in The Basics, when using the out-of-the-box events and log sources, the Health Monitoring system can be setup and configured entirely through Web.config without needing to write a single line of code!

In this article we will continue our exploration of the built-in events and log sources. In particular, we will look at the WebFailureAuditEvent event, which is raised when there is a security audit failure. We will also look at the SimpleMailWebEventProvider event provider, which, as its name implies, sends event information via email. Read on to learn more!

Monitoring Security Audits


As discussed in The Basics, all Health Monitoring events must derive from the WebBaseEvent class. In the System.Web.Management namespace you'll find that the WebBaseEvent class has a variety of subclasses that break down different types of events into different classes. This type hierarchy is best expressed pictorially. The following diagram shows many (but not all) of the built-in Health Monitoring events. I've drilled down and shaded the events relating to security auditing, since those are the set of events we'll be exploring in this article.

To have the Health Monitoring system start logging one of these events, we simply need to update the <eventMappings> and <rules> sections within the <healthMonitoring> section in Web.config. Recall that the <eventMappings> section maps a human-friendly name to a set of events. In The Basics, we were interested in two classes of events: application lifetime events and error events. Consequently, we had two <add> elements in the <eventMappings> section.

For this article, let's continue to capture unhandled exceptions, but let's pass on the application lifetime events. Additionally, we will capture failed authentication events. Therefore, use the following <eventMappings> section:

<configuration>
  <system.web>
    <healthMonitoring enabled="true">
       <eventMappings>
          <clear />

          <!-- Log ALL error events -->
          <add name="All Errors" type="System.Web.Management.WebBaseErrorEvent"
               startEventCode="0" endEventCode="2147483647" />
         
          <!-- Log authentication failure events -->
          <add name="Auth Failure Audits" type="System.Web.Management.WebAuthenticationFailureAuditEvent"
                startEventCode="0" endEventCode="2147483647" />
       </eventMappings>

       ...
    </healthMonitoring>
  </system.web>
</configuration>

The second <add> element above associates the name "Auth Failure Audits" with the WebAuthenticationFailureAuditEvent class. This setting associates just authentication failure events with the name "Auth Failure Audits". Had we wanted to capture all security audit failures we could have specified the type WebFailureAuditEvent instead. Alternatively, specifying the type WebAuditEvent would log both success and failure audit events.

In addition to assigning a human-friendly name to the event type in the <eventMappings> section, we also need to add an entry to the <rules> section indicating what log source to use when the event is raised. The <rules> section maps an event from the <eventMappings> section to a log source specified in the <providers> section. The following entries have both the "All Errors" and "Auth Failure Audits" errors mapped to the "SqlWebEventProvider", which logs the events to the ASPNETDB.MDF database in the App_Data folder.

<configuration>
  <system.web>
    <healthMonitoring enabled="true">
       <eventMappings> ... </eventMappings>

       <providers>
          <clear />

          <add connectionStringName="LocalSqlServer" maxEventDetailsLength="1073741823"
                   buffer="false" name="SqlWebEventProvider"
                   type="System.Web.Management.SqlWebEventProvider" />
       </providers>

       <rules>
          <clear />

          <add name="All Errors SQL" eventName="All Errors" provider="SqlWebEventProvider"
                   profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:00:00" />

          <add name="Auth Failure Audits SQL" eventName="Auth Failure Audits"
                   provider="SqlWebEventProvider" profile="Default" minInstances="1"
                   maxLimit="Infinite" minInterval="00:00:00" />
       </rules>
    </healthMonitoring>
  </system.web>
</configuration>

Note the minInterval setting in the <rules> section. This value specifies a window that must elapse before a particular event will be logged again. I've set the minInterval value above to "00:00:00", which means even if the same event happens, say, five times over the course of ten seconds, five events will be logged. Alternatively, you might care to have this event logged at most once every 30 seconds. If you set the minInterval value to "00:00:30", the first time the event fired it would be logged. If the same event fired 10 seconds later, that instance would not be logged since the 30 second window has not yet elapsed. For critical events, be sure to use an appropriate minInterval value ("00:00:00", perhaps). For non-critical events, a higher minInterval may be appropriate.

The download available at the end of this article includes a live demo that implements user accounts using ASP.NET 2.0's Membership feature and ASP.NET's security Web controls. In Login.aspx users are prompted for their credentials. If the login attempt is invalid, either because the username and password is incorrect or because the user has been locked out, the WebAuthenticationFailureAuditEvent event is automatically raised. Our application is configured to log this event to SQL Server, as the following screenshots illustrate. (See Examining ASP.NET 2.0's Membership, Roles, and Profile for an in-depth look at Membership.)

The user provided invalid credentials.

The log shows the invalid login attempt.

Note that the log includes the username attempted when the login attempt failed ("Invalid User").

Invalid Credentials vs. a Locked Out User
The Membership system is configured to automatically lock out a user if they attempt to logon more than a specified number of times with invalid credentials within a specified time window. This behavior is designed to help thrwart brute force attacks, where an attacker might try to login as a known user trying a variety of different passwords. Once a user has been locked out, they cannot log in, even if they enter the appropriate credentials.

The authentication failure audit event information is the same regardless of whether a user cannot login due to invalid credentials or because they have been logged out. If needed, this information could be captured through the use of a custom event. We'll explore how to accomplish this using Health Monitoring in a future article. In the mean time, check out Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 4 for a look at how to differentiate between these two authentication failures.

Receiving Event Notifications via Email


Along with providing Windows event log and SQL Server database log sources, the .NET Framework includes event providers that "log" the event to an email message. There are two such event providers:
  • SimpleMailWebEventProvider - sends a plain-text email that includes the event details. This provider allows a very limited amount of customization to the email's body.
  • TemplatedMailWebEventProvider - invokes an ASP.NET page to generate the content for the email message. This allows for much greater control over the layout and formatting of the event details in the email body.
Let's update our Health Monitoring configuration information so that authentication failures are both logged to the database and emailed to an administrator. We'll use the SimpleMailWebEventProvider event provider for sending the emails since it is simpler and doesn't require creating an additional ASP.NET page for the email template.

To use either of these event providers, we must first add a <system.net> section to our Web.config file and specify the SMTP network settings. If you omit these settings or do not put in valid values, the Health Monitoring system will fail silently. See Sending Email in ASP.NET 2.0 for a more detailed discussion on these Web.config settings.

Once you have specified the SMTP settings, all that remains is to add the SimpleMailWebEventProvider event provider to the <providers> section and an entry to the <rules> section associating the event with the SimpleMailWebEventProvider event provider.

<configuration>
  <system.web>
    <healthMonitoring enabled="true">
       <eventMappings> ... </eventMappings>

       <providers>
          <clear />

          ...

          <add type="System.Web.Management.SimpleMailWebEventProvider"
               name="EmailWebEventProvider"
               from="scott@example.com"
               to="you@yourserver.com"
               bodyHeader="!!! HEALTH MONITORING WARNING!!!"
               bodyFooter="Brought to you by Acme Warning Systems..."
               buffer="false" />

       </providers>

       <rules>
          <clear />

          ...

          <add name="Auth Failure Audits Email" eventName="Auth Failure Audits"
               provider="EmailWebEventProvider" profile="Default" minInstances="1"
               maxLimit="Infinite" minInterval="00:00:00" />
       </rules>
    </healthMonitoring>
  </system.web>

  <system.net>
    <mailSettings>
      <smtp>
        <network
             host="relayServerHostname"
             port="portNumber"
             userName="username"
             password="password" />
      </smtp>
    </mailSettings>
  </system.net>
</configuration>

With this configuration in place, anytime an authentication failure event occurs the data will be logged to the database and will be sent to you@yourserver.com.

The event information is sent via email.

The SimpleMailWebEventProvider event provider is currently configured to automatically send emails as soon as an authentication failure event fires. We can, however, instruct the provider to buffer its output. For example, we could have it so that the buffer is flushed once every minute or when there are 25 or more items in the buffer, whichever happens first. We'll explore buffering in a future installment!

Conclusion


Along with application lifetime and error-related events, the .NET 2.0 Framework also includes Health Monitoring events that are raised when certain security audits succeed or fail. In this article we explored the WebAuthenticationFailureAuditEvent event, which fires whenever an authentication attempt fails. The Membership system's providers can raises this event if a user's credentials are invalid. For example, the SqlMembershipProvider's ValidateUser method accepts a user's name and password as input and returns a Boolean indicating whether the credentials are valid. In addition to returning a Boolean value, the method also raises the WebAuthenticationSuccessAuditEvent or the WebAuthenticationFailureAuditEvent.

We also looked at the SimpleMailWebEventProvider event provider, which "logs" the events to an email. This event provider can be used to notify administrators when certain events occur (such as unhandled exceptions, authentication failures, and so on).

Happy Programming!

  • By Scott Mitchell


    Attachments


  • Download the code used in this article
  • Further Readings


  • Health Monitoring in ASP.NET 2.0: The Basics
  • How To: Use Health Monitoring in ASP.NET 2.0
  • FAQ - Health Monitoring in ASP.NET 2.0
  • The ASP.NET 2.0 Quickstart Tutorials :: Web Events
  • How To: Instrument ASP.NET Applications for Security
  • How to: Send E-mail for Health Monitoring Notifications
  • Article Information
    Article Title: ASP.NET.Health Monitoring in ASP.NET 2.0: Notifications via Email
    Article Author: Scott Mitchell
    Published Date: March 21, 2007
    Article URL: http://www.4GuysFromRolla.com/articles/032107-1.aspx


    Copyright 2014 QuinStreet Inc. All Rights Reserved.
    Legal Notices, Licensing, Permissions, Privacy Policy.
    Advertise | Newsletters | E-mail Offers