Rob Jamison, Manager, Network Intelligence, Managed Security Solutions Group, BT Global Services

In early 2003, I visited a customer headquartered in a sedate Midwestern city. They are an industrial equipment manufacturer who had contracted with us to monitor their networks. The company had a strong in-house security staff who were excited about the Managed Security Monitoring (MSM) model. They wanted the oversight we provided as well as monitoring coverage while they were sleeping, on vacation, or out of the office for any reason. While this was a pretty standard arrangement, as was their SNORT IDS, the ruleset our customer contact was running was anything but standard.

There were no signatures to catch FTP attacks, HTTP GET CGI/PL script abuse, or Trojan software connecting out from their network. There were none of the standard signatures detecting myriad CVE’s and BID’s generated over the years — not a single one with an identifiable SID we were used to seeing in SNORT instances! How could someone have been so careless as to bring up a PRODUCTION IDS with so little coverage for targeted or worm-based attacks that had been proliferating the Internet?

CODERED and NIMDA had destroyed networks in the summer of 2001, and SQL SLAMMER had knocked even some of the most robust non-Windows networks offline, due to the saturation of UDP traffic just months earlier. Could this gentleman really have enough confidence that his application servers and Microsoft domain infrastructure was patched, and that no one was running any rogue services on the network?

Truth of the matter was that our customer knew exactly what he was doing. He only wanted to see a handful of signatures that were generic and could indicate that “something” was amiss that REALLY needed to be looked at. Not that something was a quasi attack or could be successful if only that OS was running this configuration of application X — just the nuts and bolts fundamentals of good ‘ole fashion network monitoring. His SNORT’s ran fast, faster than any other IDS of the same hardware investment, because pattern matching was reduced to a handful of rules.

Just as there are three primary colors that make up a continuous spectrum of light, here are three rules our savvy customer was running:

1. Error 404: A client has requested something from my webserver that it does not have, or does not have at the location some client was looking for. When a high number of distinct web servers report 404 to a single client host, that host is not up to any good.

2. DARKNET: There was some IP traffic (ICMP/TCP/UDP doesn’t matter) from an RFC1918 (private) host that we didn’t allocate, or just don’t know about. This is the equivalent of the Police “running” a license plate, and the response coming back “not in system.” How many police would consider that a routine false positive and let the driver go without further questioning?

3. TCP/UDP/ICMP Portscan: With a suitable threshold, applicable target network range, and tuning out verified false positives, something or someone has solicited a bunch of connections to our internal servers. While this is one of the most common false positives, if correctly deployed and monitored, it can be the most useful of all signatures.

There are some clear lessons to be taken away from this short story about a Mid-Western IT manager and his seemingly peculiar rulesets. The bottom line is that keeping it simple is a great strategy. Provided you have a strong working knowledge of your network and its operating environment, simple red-flag conditions can bring a whole world of mischief to light in short order.