Wednesday, December 7, 2016

Heimdall, He Who Watches the Event Log

I have a tiny server, sitting in the cloud, running cygwin’s OpenSSH. Logging in requires an SSH key, but this doesn't stop people from trying all sorts of ways to get in.

Normally, this does nothing whatsoever, other than fill up my event logs with “invalid user” messages. However, I thought it might be nice to filter these users out at the firewall level. That’s what this program does: it monitors the event log for invalid SSH connection attempts, and adds the offending IP to the Windows Firewall list of blocked IP addresses.

Since my server is named Bifröst, I've named this program Heimdall. Heimdall is designed to be run from the command line, or as a scheduled task. While Heimdall is not a terribly complex program, I did learn a few things as I wrote it. This post is both to document what I found, and to serve as a reminder to me, should I ever need this information again.

The first thing Heimdall does is scan through the event log, looking for events matching a specific pattern. This is done using the EventLogReader and EventLogQuery classes. In my case, the relevant code followed this pseudo-code:

public static IEnumerable<EventEntry> GetEvents(int entriesToScan)
{
 const string queryString = "*[System[Provider[@Name='sshd'] and EventID=0]]";

 var eventsQuery = 
  new EventLogQuery("Application", PathType.LogName, queryString)
  {
   ReverseDirection = true
  };

 // The "EventEntry" class is just a model for holding information about this
 // a single event.  Keep reading for further details.
 var events = new List<EventEntry>();
 entriesToScan = Math.Max(entriesToScan, 1);

 try
 {
  using (var logReader = new EventLogReader(eventsQuery))
  {
   EventRecord eventInstance;
   int currentEvent;

   for (
    eventInstance = logReader.ReadEvent(), currentEvent = 1;
    eventInstance != null && currentEvent <= entriesToScan;
    eventInstance = logReader.ReadEvent(), currentEvent += 1)
   {
    EventEntry entry;

    try
    {
     entry = EventEntry.From(eventInstance);
    }
    finally
    {
     eventInstance.Dispose();
    }

    if (entry != null)
    {
     events.Add(entry);
    }
   }

   eventInstance?.Dispose();
  }
 }
 catch (EventLogNotFoundException e)
 {
  Console.Write("Failed to query the log!", e);
  return null;
 }

 return events;
}

I learned that the event log messages emitted from logReader.ReadEvent() implement IDisposable and should be disposed of.

I did not find any way to limit the number of items returned by the query, other than manually counting them. Since the every query looks like a standard xpath query, I tried experimenting with position(), but I could not make it work.

In my case, I needed information out of the EventData section of the event object. I could not find a way to access this information using any of the conveinance methods, but fortunately, the complete event information is available as XML. I was able to access the EventData by parsing the XML from the EventRecord object:

public static string GetData(EventRecord eventInstance)
{
 const string namespaceName =
  "http://schemas.microsoft.com/win/2004/08/events/event";

 var eventDataName = XName.Get("EventData", namespaceName);
 var dataName = XName.Get("Data", namespaceName);

 return XDocument.Parse(eventInstance.ToXml())
  .Descendants(eventDataName).FirstOrDefault()?
  .Descendants(dataName).FirstOrDefault()?
  .Value;
}

Once I had the event data, I was able to parse it using a regular expression, looking for a username and IP address. The username gets compared to a white-list of allowed usernames, and the IP address is checked to make sure it isn't coming from a private block. This is partially for my own protection: I figure that if I ever accidentally lock myself out, I can always try again from a private IP address.

If the attempted username is not on the white-list, and if the IP address is not private, then Heimdall adds the IP address to the list of addresses blocked by the Windows Firewall. Working with the Windows Firewall is done by way of the INetFwPolicy2 interface.

For the purposes of this program, I make no attempt to create new firewall rules. Instead, I modify an existing Firewall rule, which I manually created beforehand. A useful additional to Heimdall would be the ability to create its own rule, to reduce the amount of manual configuration necessary. However, as of right now, Heimdall assumes that this rule already exists:

This is a simple blocking rule, which Heimdall is able to access by name:

private static INetFwRule GetBlockingRule() =>
 ((INetFwPolicy2)
 Activator.CreateInstance(Type.GetTypeFromProgID("HNetCfg.FwPolicy2")))
  .Rules
  .OfType<INetFwRule>()
  .FirstOrDefault(r => r.Name == "Block Specific IPs");

Once we have a reference to the firewall rule, we just need to add the target IP address to the list of remote addresses affected by this rule.

I took some care to handle ranges of IP addresses; that is, if two or more adjacent IP addresses are blocked, they are added to the firewall as a range, instead of individual entries. I found the IPAddressRange project to be very useful in assisting with this.

public static void BlockIp(IPAddress ip)
{
 var rule = GetBlockingRule();

 var addresses = rule.RemoteAddresses
  .Split(',')
  .Where(s => string.IsNullOrWhiteSpace(s) == false)
  .Select(IPAddressRange.Parse)
  .ToList();

 addresses.Add(new IPAddressRange(ip));

 // Details of ConsolidateRanges are not relevant to this post; check the
 // source on BitBucket if you are curious.
 addresses = ConsolidateRanges(addresses);

 rule.RemoteAddresses = string.Join(",", addresses.Select(r => r.ToString()));
}

Finally, Heimdall sends me an email whenever a new IP address is blocked. I've had this program running for about a week now, and I've enjoyed seeing some of the creative usernames that people try to log in with. Over the past week alone, there have been 35 separate IP addresses blocked, which have attempted 205 unique usernames.

If you are curious enough to have read this far, you may be interested in seeing the source code for Heimdall!

Wednesday, October 23, 2013

Visual Studio as a Diffing Tool

I have recently learned how to make use of Visual Studio 2012's built-in diffing tool. I'm happy to report that it does a reasonably decent job at this. While diffing, you have access to Visual Studio's superior syntax highlighting and intellisense capabilities. Also, it reuses existing windows, which can be handy if your target file is already open in your IDE. I have always used external diffing tools in the past, but there is a certain appeal to having an integrated tool. Just being able to diff and edit in a consistent color scheme is nice.

Sadly, Visual Studio does not support three-way merging or directory comparison, so I won't be putting KDiff3 down just yet. Also, unless you have set up a Team Foundation source control server, this capability is rather obscure and difficult to invoke. It involves some command line incantations:

devenv.exe /Diff Source Target [SourceName] [TargetName]

That isn't too bad, as command line arguments go. Still, I do not want to specify the complete path for every source and target file that I want to compare. Fortunately, it is quite possible to set up Visual Studio as a merge tool option for TortoiseHg. To do so, edit your global mercurial.ini file, and add this to your [merge-tools] section (go ahead and create that section if it does not exist):

[merge-tools]
vs.executable = ${ProgramFiles(x86)}/Microsoft Visual Studio 11.0/Common7/IDE/devenv.exe
vs.gui = True
vs.diffargs = /diff $parent $child "$plabel1" "$clabel"
vs.priority = 1

Now go up to your [tortoisehg] section. Create or edit your vdiff setting to point to your newly defined merge tool. It should look like this (along with whatever other items you have in that section):

[tortoisehg]
vdiff = vs

Restart TortoiseHg. Now, when you ask TortoiseHg to diff a single file for you, it should open that file in Visual Studio. If you ask for a three-way merge or a directory diff, TortoiseHg is smart enough to know that Visual Studio can't handle it, and will pick a different tool.

Tuesday, October 11, 2011

Introducing MinCat for MSBuild / Visual Studio

I am happy to release a new project today. Introducing MinCat: the JavaScript and CSS minimizer and concatenation utility for MSBuild and (optionally) Microsoft MVC.

The Problem

JavaScript presents an interesting problem to many web developers. As a client-side scripting language, it is very forgiving about how it is used, and how it is included in the context of a larger web document. There is a sloppy way to serve JavaScript, and a professional way to serve JavaScript.

The "sloppy" method covers many possibilities: inline amongst the HTML, buried inside the href of an anchor, or heaped into the <head> in a stack of script-tags that comes up to your eyeballs. All of these methods work, but they also have issues.

The current best practice recommends a different approach. Instead of including HTML inline, we should serve it as external files. Moreover, these files should be minimized to reduce the page load time. If multiple files are necessary, we should concatenate them to reduce the number of HTTP requests required to load them.

However beneficial this is to the end-user, the act of minimizing and concatenating script files adds an additional burden to the developer. Fortunately, it is quite possible to automate this process, and numerous tools exist to facilitate this. MinCat is such a tool.

The Solution

MinCat exists to address exactly the problem described above. It is a small, simple tool that lets you control the minimization and concatenation of your JavaScript files. It is designed to integrate directly with MSBuild. Because Visual Studio uses MSBuild under the hood, this means it provides easy integration with your existing Visual Studio web projects.

It's usage is simple and straightforward. By adding <Minimize> or <Concatenate> commands to your project file, you can control how your JavaScript is prepared for your source files. For instance, this command would minimize all of the JavaScript files in your "Scripts" folder, placing the resulting files in "Scripts\min":

<Minimize Input="Scripts\*.js" Outpath="Scripts\min\" />

For MVC projects, MinCat also provides an MVC Script helper extension. At a basic level, this extension will facilitate the switch between the minimized or development version of a particular file. However, it really begins to shine when combined with the new "directives" that MinCat offers (more on those later!)

@Html.Script(Url.Content("~/Scripts/MyScript.js"))

Since minimizing JavaScript is not always a quick operation, MinCat will only re-minimize files if they have changed since the last time they were minimized. It accomplishes this by comparing the last modified date of the source files with the corresponding date on the minimized files. This helps keep the overall build time down to a minimum.

MinCat comes bundled with the excellent YUICompressor. However, it is designed so that the compressor is a modular component, and it could easily be reworked to use a different compression engine.

New JavaScript Directives

As if all that weren't enough, MinCat additionally provides support for a number of directives, designed to be placed in the actual source of individual JavaScript files. These provide further control over how each file is treated by the minimization process. Because these directives are fully supported by the (optional) MinCat MVC Script helper extension, they provide some exciting new ways to organize and structure your JavaScript.

/* @skip minimize */
This directive will cause the source file to never be minimized, even if it is otherwise included by a wildcard in the input path. This has no effect when used with the MVC helper extension.
/* @require "filename.js" */
This directive instructs the minimizer that the current file depends on code from another file. When this file is minimized, all required external files will be collected (recursively, so a required file can also require a file), sorted into the correct order, reduced to a distinct list, and concatenated in front of the file that specifies them. Therefore, the resulting minimized file will contain everything it needs to function. When used with the MVC Script helper extension, each required file will be loaded in its own <script /> tag, in the correct order, before the <script /> tag that contains your target file.
/* @include "filename.js" */
This directives causes the minimizer to include the complete contents of the specified file directly inline, wherever that directive is found. When used with the MVC Script helper extension, the loaded <script /> file will also include the desired content directly inline.

Note the differences between @require and @include. The @include directive is primarily exciting because it allows you to create assembly-like structures:


var Global = (function () {
  "use strict";

  var internal = {};

  function Global() {
    var instance = {};

    /* @include "Access to Internal, Instance, and Global Variables.js" */
  }

  /* @include "Access to Internal and Global Variables.js" */

  /* @require "Access to Global Variables Only.js" */
  return Global;
}());

Learn More!

MinCat is open source software, released under a BSD License. It is available on BitBucket, and as a NuGet package.

Complete documentation is available on its wiki page.

As always, I am excited to learn how people are using my tools. If you try this out, please feel free to drop me a note with your impressions. And of course, always let me know if you find a bug!

Wednesday, July 20, 2011

JSLint, Licensing, and JSON Visualization

The JSLint license specifies that it should be used for Good, not Evil.

Suppose I construct some program that I believe to be Good, and use JSLint to improve the quality of that program. Further suppose that I release my code under a permissive license, such as a BSD license. Now suppose that somebody else takes my program and uses it for Evil.

In this case, the evil-doer has not actually violated their license agreement with me, since BSD licenses permit Evil. However, the evil-doer has now profited from the increased code quality gained from using JSLint.

Is the evil-doer now in violation of the JSLint license, despite never actually using JSLint themselves? Alternatively, perhaps I am now in violation of the JSLint license? Does the JSLint license require me to use the "Good" clause in my license as well, to prevent this scenario?

These are the questions that trouble me this morning. By the way, I've released the source to my JSON visualizer under a BSD license.

Wednesday, December 29, 2010

Notes on GetSchemaTable

I recent found myself using the SqlDataReader.GetSchemaTable method. I made some notes detailing what it will return for various data types in SQL Server 2005.

Notes on GetSchemaTable
 Numeric 
ColumnNameDataTypeColumnSizePrecisionScaleNotes
bigintInt64819255 
bitBoolean1255255 
decimalDecimal17180 
intInt32410255 
moneyDecimal819255 
numericDecimal17180 
smallintInt1625255 
smallmoneyDecimal410255 
tinyintByte13255 
floatDouble815255 
realSingle47255 
datetimeDateTime8233 
smalldatetimeDateTime4160 
charString20255255 
varcharString20255255 
textString2147483647255255isLong
ncharString20255255 
nvarcharString20255255 
varchar(max)String2147483647255255isLong
nvarchar(max)String2147483647255255isLong
ntextString1073741823255255isLong
timestampByte[]8255255IsRowVersion
xmlString2147483647255255isLong

I created these notes through the simple method of creating a table with every possible data type. Or rather, every data type that I am interested in, which is very nearly the same thing--I mean, who uses varbinary, really? I then used the GetSchemaTable method on my new table, and inspected the results.

There is a page on MSDN that appears to contain this information, but upon closer inspection, it must be talking about something else entirely. For instance, it claims that the SQL Server data type "varchar" has no mapping whatsoever, not even as a System.String.

Certainly, this makes sense upon further reflection: it's possible to put any varchar value into a string, but not the other way around. Still, it's not terribly useful if you just want to know what sort of data type you can reasonably expect to get out of a given column.

I further note that the MSDN documentation states that the NumericPrecision column should be null for non-numeric data types, but this is simply not true.

Saturday, July 10, 2010

Conditional Operators and Bracket Notation

Did you know it is valid JavaScript to use conditional operators inside bracket notation to access object properties? For whatever reason, I have only just now realized this.

In other words, this is a perfectly valid fragment:

var obj = {
  valid: [],
  invalid: []
};

items.forEach(function (item) {
  obj[item.isValid() ? "valid" : "invalid"].push(item);
});

The conditional operator, which takes the form condition ? ifTrue : ifFalse, is a shorthand version of an if statement. In this case, it results in the name of the object property that I wish to access.

I am yet undecided on whether this is more or less readable than the verbose version:

items.forEach(function (item) {
  if (item.isValid()) {
    obj.valid.push(item);
  } else {
    obj.invalid.push(item);
  }
});

Perhaps I will look back on this post in a few months and marvel at how obvious it all seems in hindsight. In the meantime, it is nice that I am still learning new things about JavaScript.

Friday, February 12, 2010

Wacky Code

This has got to be the most wacky code I have written all week:

range1.setEndPoint('StartToStart', range2);
range1.setEndPoint('StartToStart', range2);

Yes, the same line is there twice, and yes, it is supposed to be like that. The ranges in question are IE-only TextRange objects, which I am using to manage the position of the cursor within a rich text editor. The line has to be repeated because the first execution doesn't quite work, but the second one does:

<p>widget{cursor}</p> <-- position after first line -->
<p>{cursor}gadget</p> <-- requested position,
                          position after second setting -->

Wacky. Sadly, this is just one of many TextRange eccentricities that I've run into.