Health Monitoring in ASP.NET 2.0: Notifications via EmailBy Scott Mitchell
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.configwithout 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
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
WebBaseEventclass. In the
System.Web.Managementnamespace you'll find that the
WebBaseEventclass 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
<rules> sections within the
<healthMonitoring> section in
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
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
<add> element above associates the name "Auth Failure Audits" with the
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
Alternatively, specifying the type
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.
<rules> section maps an event from the
<eventMappings> section to a log source specified
<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
minInterval setting in the
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.
SimpleMailWebEventProviderevent 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
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
Once you have specified the SMTP settings, all that remains is to add the
SimpleMailWebEventProvider event provider
<providers> section and an entry to the
<rules> section associating the event
SimpleMailWebEventProvider event provider.
With this configuration in place, anytime an authentication failure event occurs the data will be logged to the database and will be sent to firstname.lastname@example.org.
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!
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
WebAuthenticationFailureAuditEventevent, 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
ValidateUsermethod 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
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).