TrotterWatch – He who dares wins. He who hesitates… doesn’t.

Over the past couple of week’s I’ve been thinking about the possibility of being able to utilise online services to stop suspect requests sapping server resources which could ultimately lead to DoS. One of the biggest and most commonly used methods for checking suspect IP addresses or host-names for email communication is a DNSBL (Domain Name System Block List). A DNSBL is method for checking an IP or host-name against a blacklisting database which utilises the DNS protocol. DNS queries are performed using a record type A (Address Record) which in-terms of a natural DNS query, you would send the domain name (google.com) and if valid, would expect the destination IP address. To query a DNSBL however, you would need to reverse the octets of the IP address (or if it’s hostname then just add it as is) and prefix the DNSBL domain to the query. So if I was checking the validity of the IP 208.67.222.222 using the DNSBL service Spamhaus, the query would look something similar to the below:

222.222.67.208.zen.spamhaus.org

If the domain is listed, the DNSBL provider will present you with a private IP address which you would need to cross check with the return codes for the DNSBL provider.

Spamhaus Zen Return Codes Keeping the above the in mind, wouldn’t it be great if we could harness these resources to validate a Http request for say an ASP.NET Core application. Granted that this would not be 100% foolproof and obviously an enterprise firewall would always be the better option hands down, but considering those businesses/projects which fail to have the funds to pay an extra £100 > per month on Azure credits for their App Service, this seems like a pretty good alternative.

Over the past couple of days, I’ve attempted to implement DNSBL into a middleware component which I’ve called TrotterWatch (I’ll explain the name later). I’ve been putting together some working demo on my Github page if you fancy taking a look.

It’s still a work in progress, but the idea behind it is that you as a developer will specify the DNSBL servers you wish to run checks on or use the defaults provided. The providers will be passed in as JSON and then instantiated in the Assembly. I would urge the developer to manage the DNSBL providers as some may not work correctly due to location, DNS configuration or even just your IP. Plus it gives you the flexibility to limit the amount of query’s during the life cycle of new request if your only checking a request against 5 popular DNSBL’s rather than the default 20-30.

Example of a JSON array of providers which you would you would reference in TrotterWatchOptions or use defaults.

[
  {
    "Name": "Spamhaus Zen",
    "Url": "zen.spamhaus.org",
    "Type": "Both"
  },
  {
    "Name": "SPFBL",
    "Url": "dnsbl.spfbl.net",
    "Type": "Ip"
  }
] 

Example of adding TrotterWatch to the middleware pipeline. It accepts an ILogger along with ContinueChecks which is designed to stop further checks if an IP and/or hostname has already been listed.

//Use of default RBL's
app.UseTrotterWatch();

//Custom RBL Providers
app.UseTrotterWatch(new TrotterWatchOptions
{
RblProviders = "", //File Path to JSON
ContinueChecks = false, //Continue checks if already listed in an RBL Provider
Logger = loggerFactory.CreateLogger("TrotterWatch") //Logger...obviously 😉
});

If the request IP is listed against any of the providers stated, the pipeline will short circuit and the Http Response will be set to 403 (Forbidden) and the Http Headers will present the custom X-TrotterWatch header explaining who the IP/Hostname is listed with along with the return code.

You may of noticed that only IP’s are being passed from HttpContext so what would be the point of the host name? Well, if an RBL provider supports hostnames and JSON provider has been set to either RblType.Hostname or RblType.Both, TrotterWatch will automatically query the PTR record (as well as the IP) of the request IP and then use the response (if any) as a host name query.

Still a lot of work to get it to a point which would work well in production. I’ll be adding an encrypted session cookie for IP validation along with some form of persistence storage along with re-configuring the providers to query in parallel. I’ll be updating with updates as and when.

Nearly forgot, the name was taken from popular British TV series called Only Fool and Horses. During one of the many amazing episodes that John Sullivan created, one of the characters was tasked by his brother to be a security guard. He was given a security uniform with the initials “TW” which he was told represented “Trotter Watch”. We  find out later on that the uniform initials stood for Traffic Warden and that the character Rodney was far from winning any security of the year awards. To me, I felt the name and idea behind it really sums up what the tool is…a last resort 🙂

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.