Snort and the Value of Detecting the Undetectable

There are many instances where networks are hacked, unlawfully accessed or effectively disabled. The now infamous 2006 hacking of the T.J. Maxx network has been well documented – both in terms of lack of due diligence on the part of T.J. Maxx and the legal ramifications suffered by the company as a result. Add to this the level of harm done to thousands of T.J. Maxx customers and the importance of allocating resources toward network security quickly becomes apparent.

On further analysis of the T.J. Maxx hacking, it’s possible to point to a tangible point in time where the incident was finally noticed and mitigated. But what about the security incidents that go unnoticed? What if an enterprising young hacker is discreet enough to siphon tiny pieces of vital information from a network in a manner that leaves system administrators none the wiser? To better combat this type of scenario, security/system administrators may consider the Snort Intrusion Detection System (IDS).

Beginnings of Snort

In 1998, Snort was released by Sourcefire founder Martin Roesch. At the time, it was billed as a lightweight intrusion detection system that functioned primarily on Unix and Unix-like operating systems. At the time, the deployment of Snort was considered cutting edge, as it quickly became the de facto standard in network intrusion detection systems. Written in the C programming language, Snort quickly gained popularity as security analysts gravitated toward to the granularity with which it could be configured. Snort is also completely open source, and the result has been a very robust, widely popular piece of software that has withstood ample amounts of scrutiny in the open source community.

Snort Fundamentals

At the time of this writing, the current production version of Snort is 2.9.2. It maintains three modes of operation: Sniffer mode, packet logger mode and network intrusion detection and prevention system (IDS/IPS) mode.

Sniffer mode involves little more than capturing packets as they cross paths with whichever network interface card (NIC) Snort is installed on. Security administrators can use this mode to decipher what type of traffic is being detected at the NIC, and can then tune their configuration of Snort accordingly. It should be noted that there is no logging in this mode, so all packets that enter the network are simply displayed in one continuous stream on the console. Outside of troubleshooting and initial installation, this particular mode has little value in and of itself, as most system administrators are better served by using something like the tcpdump utility or Wireshark.

Packet logger mode is very similar to sniffer mode, but one key difference should be evident in the name of this particular mode. Packet logger mode allows system administrators to log whatever packets are coming down into preferred places and formats. For example, if a system administrator wants to log packets into a directory named /log on a specific node within the network, he would first create the directory on that particular node. On the command line, he would instruct Snort to log packets accordingly. The value in packet logger mode is in the record keeping aspect inherent in its name, as it allows security analysts to examine the history of a given network.

OK. All of this information is nice to know, but where is the value added? Why should a system administrator spend time and effort installing and configuring Snort when Wireshark and Syslog can perform practically the same services with a much prettier interface? The answer to these very pertinent questions is the network intrusion detection system (NIDS) mode.

Sniffer mode and packet logger mode are stepping stones on the way to what Snort is really all about – NIDS mode. NIDS mode relies primarily on the snort configuration file (commonly referred to as snort.conf), which contains all of the rule sets that a typical Snort deployment consults prior to sending alerts to system administrators. For example, if an administrator would like to trigger an alert every time FTP traffic enters and/or leaves the network, she would simply refer to the appropriate rules file within snort.conf, and voila! An alert will be triggered accordingly. As one may imagine, the configuration of the snort.conf can get extremely granular in terms of alerts, protocols, certain port numbers, and any other heuristic that a system administrator may feel is relevant to her particular network.

Where Snort Comes Up Short

Shortly after Snort began to gain popularity, its only shortcoming was the talent level of the person configuring it. As time went by however, the most basic computers began to support multiple processors, and many local area networks began to approach speeds of 10 Gbps. Snort has been consistently billed as "lightweight" throughout its history, and this moniker is relevant to this day. When run on the command line, packet latency has never been much of an obstacle, but in recent years a concept known as multithreading has really begun to take hold as many applications attempt to take advantage of the above-mentioned multiple processors. Despite several attempts at overcoming the multithreading issue, Roesch and the rest of the Snort team have not been able to produce any tangible results. Snort 3.0 was due to be released in 2009, but had not yet been made available at time of writing. Furthermore, Ellen Messmer of Network World suggests that Snort has quickly found itself in a rivalry with the Department of Homeland Security IDS known as Suricata 1.0, whose proponents suggest that it supports multithreading. However, it should be noted that these claims have been vehemently disputed by Snort’s founder.

Snort’s Future

Is Snort still useful? This depends on the scenario. Hackers who know how to take advantage of Snort’s multithreading shortcomings would be delighted to know that a given network’s only means of detecting intrusions is Snort 2.x. However, Snort was never meant to be THE security solution to any network. Snort has always been considered a passive tool that serves a particular purpose in terms of network packet analysis and network forensics. If resources are limited, a wise system administrator with abundant knowledge in Linux might consider deploying Snort in line with the rest of his or her network. While it may have its shortcomings, Snort still provides the greatest value at the lowest cost. (Read more about Linux distros in Linux: Bastion of Freedom.)