Health Monitoring in ASP.NET 2.0: Notifications via Email
By Scott Mitchell
A Multipart Series on ASP.NET 2.0's Health Monitoring System
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. This article is one of an ongoing series on
the Health Monitoring system.
Health Monitoring Basics - explores the concepts
and advantages of the Health Monitoring system and looks at logging events to a Microsoft SQL Server database.
Notifications via Email - looks at security-related
events and shows how to alert an administrator to failed authentication attempts by "logging" events to email.
Raising Custom Events - learn how to create and raise custom
Health Monitoring events.
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:
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.
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.)
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.
...
<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>
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 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).
A Multipart Series on ASP.NET 2.0's Health Monitoring System
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. This article is one of an ongoing series on
the Health Monitoring system.
Health Monitoring Basics - explores the concepts
and advantages of the Health Monitoring system and looks at logging events to a Microsoft SQL Server database.
Notifications via Email - looks at security-related
events and shows how to alert an administrator to failed authentication attempts by "logging" events to email.
Raising Custom Events - learn how to create and raise custom
Health Monitoring events.
