Elmah Scan Exclusion

ELMAH (Error Logging Modules and Handlers) is a fantastic logging tool for exception tracking in ASP.NET web applications. It captures almost every type of un-handled exception and it captures an incredibly detailed snapshot of what went wrong, making it an essential tool for diagnosing what went wrong on your website. However, the verbosity and spread of what is logged by ELMAH can be a double edged sword as meaningful, important errors can be lost in a sea of noise.

Security Scans and a Clean ELMAH Log:

Security scans can flood your ELMAH log in a matter of minutes. It is a good practice to frequently run scans on a production environment to find vulnerabilities, so skipping them is not an option. But, neither is omitting logging as production is the environment in which errors have the biggest negative impacts.  So, we must find a way to allow these two tools to coexist without hindering each other.

Security scans work by "crawling" a website and trying every possible combination of links that a user can find. Additionally, they will try to deliver payloads to valid pages by appending some characters to the end of URLs. The result of this exhaustive search is a huge sum of 404 (not found) and 403 (forbidden) error codes, which are things that ELMAH tracks. So, we need a solution to stop the log from becoming unreadable whenever a scan runs and from losing any legitimate errors that may have occurred during the scan in the backlog of records. The solution is actually quite simple - it just requires a few lines in your Web.Config file and the IP address of the scanning server.
<elmah>
    <errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/elmah" />
    <errorFilter>
         <test>
            <regex binding="Context.Request.ServerVariables['REMOTE_ADDR']" pattern="^123\.123\.123\.\d{1,3}$" type="String" />  
          </test>
    </errorFilter>
</elmah>
The code above goes right into the ELMAH section of your Web.Config file. As you can see, this is where you select basic settings like the folder where the log files are saved. What we are interested in is the error filter. This allows you to modify anything about what errors are saved, be it the type of error or, in our case, where the error is coming from. We are using a regular expression test to match the IP of the requester. We know that any IPs like 123.123.123. are coming from the scan server. So, we simply made a regular expression that matches exactly that pattern and then 1 to 3 digits beyond the third period, which encapsulates all possible addresses that could be used for scanning the application. Now your ELMAH log should be clean, and most importantly, readable.

Thanks for reading!

Published 11/08/16

Comments

Popular posts from this blog

ASP.NET Identity Remember Me

IIS Express Client Certificates

ASP.NET MVC - How to enable/disable CaC/Client Certificate authentication per area or route.