Snort Report 22 Posted

My 22nd Snort Report titled Snort vs. Microsoft Security Bulletin MS08-068 has been posted. From the article:

Welcome to the 22nd edition of the Snort Report! On Nov. 11, 2008, Microsoft published Microsoft Security Bulletin MS08-068 -- Important Vulnerability in SMB Could Allow Remote Code Execution (957097). Server Message Block (SMB) is an old and integral aspect of Microsoft Windows file sharing and related functions...

I continue by describing how Snort's rule set dealt with this super-old vulnerability.

---

Richard Bejtlich is teaching new classes in DC and Europe in 2009. Register by 1 Jan and 1 Feb, respectively, for the best rates.

Read More

Snort Report 21 Posted

My 21st Snort Report titled Understanding Snort's Unified2 output has been posted. From the article:

Welcome to the 21st edition of the Snort Report! In July 2007 I described Snort's Unified output, first released in July 2001 with Snort 1.8.0. Unified output allows Snort to write sets of data to a sensor's hard drive. Writing to the hard drive, instead of performing database inserts, allows Snort to operate faster and minimize packet loss.

Unified2 output first appeared in Snort 2.8.0, released in September 2007.

I came across this comparison of Unified and Unified2 format at SecurixLive.com but didn't get to include it in my article.

If you're worried about the Barnyard2 implementation at SecurixLive having licensing issues, the author is addressing those as we speak; he did not intend to cause any trouble. So, I am looking forward to seeing greater adoption of Unified2 formats once solutions like those in my article are tested.

---

Richard Bejtlich is teaching new classes in DC and Europe in 2009. Register by 1 Jan and 1 Feb, respectively, for the best rates.

Read More

Snort Report 20 Posted

My 20th Snort Report titled Using Snort 2.8.3 to inspect HTTP traffic has been posted. From the article:

Solution provider takeaway: Solution providers will learn new features in Snort 2.8.3 to improve the granularity of inspecting HTTP traffic.

Welcome to the 20th edition of the Snort Report! In July, we described new features in Snort 2.8.2 and how to identify them when compared to Snort 2.8.0 and intervening releases. Since then, Snort 2.8.2.1, 2.8.2.2 and 2.8.3 have arrived. In this issue of the Snort Report, we'll use the previously explained techniques to learn what's new in Snort 2.8.3, and then try those techniques ourselves.

Read More

Snort Report 19 Posted

My 19th Snort Report titled Using SnortSP and Snort 2.8.2 has been posted. From the article:

Solution provider takeaway: Solution providers will learn how to set up two Snort 3.0 beta components -- the Snort Security Platform (SnortSP) and the Snort 2.8.2 detection engine on the SnortSP.

In the last Snort Report, I discussed the architectural basics of Snort 3.0. The new Snort system consists of the Snort Security Platform (SnortSP) plus an assortment of engines. SnortSP is a foundation that provides traffic-inspection functions, like packet acquisition, traffic decoding, flow management and fragment reassembly. Each engine runs as a module on SnortSP. The first available module is a port of Snort 2.8.2 specifically for running on top of SnortSP.

I can never tell when SearchSecurity will post these articles... this one is dated 5 Sep but I just noticed it online.

Read More

Snort Report 18 Posted

My 18th Snort Report titled The Power of Snort 3.0 has been posted. From the article:

Service provider takeaway: Service providers will learn about Snort 3.0's new architecture and how it can be used as a platform for generic network traffic inspection tools.

Recently, I attended a seminar offered by Sourcefire, the company that supports Snort. Marty Roesch, Snort's inventor and primary developer, discussed Snort 3.0. In this edition of the Snort Report, I summarize Marty's plans and offer a few thoughts on the direction of Snort development.

Right now I am working on the next Snort Report, where I discuss how to get the latest Snort 3.0 beta running on Debian.

Read More

Snort Report 17 Posted

My 17th Snort Report titled How to find new features in Snort 2.8.2 has been posted. It was delayed in production for a while but it still applies to Snort 2.8.2.1. From the article:

Service provider takeaway: Service providers will learn about new features in Snort 2.8.2 that they can deploy at customer sites.

The last time we looked at new Snort options occurred with Snort 2.8.0, released in late September 2007. Since then, Snort 2.8.0.1, 2.8.0.2 and 2.8.1 have been published. At the time of writing, Snort 2.8.2-8-rc1 is the latest version, although release candidate versions should generally not be deployed in production environments. However, RC editions do provide a look at the newest elements of Snort available to the general public. This Snort Report provides an overview of some of the new features in the latest editions of Snort while explaining how to identify these new features.

I'm working on a new Snort Report now looking at the new SSP Beta 2.

Read More

Snort Report 16 Posted

My 16th Snort Report titled When Snort Is Not Enough has been posted. From the article:

[I]t's important to understand how a network intrusion detection system (IDS) like Snort and techniques based upon its use fit into a holistic detection and response operation. Placing Snort within an entire security program is too broad a topic to cover in this Snort Report. Rather, let's consider when a tool like Snort is independently helpful and when you should support Snort with complementary tools and techniques.

Read More

Snort Report 15 Posted

My 15th Snort Report titled Justifying Snort has been posted. I really like this post. The staff (Crystal Ferraro) at SearchSecurity did a great job editing my original submission, cutting the text but enhancing it too. Prospective book authors should judge their publishers by the quality of the editing and copyediting/proofing staffs. From the article:

Service provider takeaway: Service providers will learn how to communicate the value of Snort to customers.

There's a good chance that as a value-added reseller (VAR) or security service provider, you believe Snort and similar tools are valuable. However, there are plenty of technical folks that believe Snort is a waste of time. The goal of this Snort Report is to help you communicate the value of Snort to those customers whose IT departments are resistant to the open source tool. Although I focus on the value of Snort, you can apply this approach to any similar product.

IDS vs. IPS

I believe the majority of objections to the value of Snort stem from the fact that it's called an intrusion detection system (IDS). Looking closely at that label, we should assume that an IDS is a "system" that "detects" "intrusions." The ultimate IDS would be 100% accurate in its ability to perform that role. A simple question flows naturally from the perception that an IDS is supposed to detect intrusions: "If you can detect intrusions, why can't you prevent them?" At first glance this question makes sense. We should prevent activity that has been 100% identified as being an intrusion.

For more please read the article. It will take 5 mins or less. Debate here is welcome.

Read More

Snort Report 14 Posted

My 14th Snort Report titled Network session data analysis with Snort and Argus has been posted. The article doesn't talk about Snort (despite the title -- not mine!) but it does discuss Argus, the network session tool developed by Carter Bullard. From the start of the article:

This edition of the Snort Report departs from the standard format by introducing a data format and data collecting tool that can work alongside Snort. The data format is session data, and the tool is Argus 3.0.

Why session data?

The Snort intrusion detection system can identify suspicious and malicious activity by inspecting network traffic. Snort makes a judgment based on its analytical capabilities and notifies the operator of its decision by generating an alert. I call the output of this collect-inspect-report process "alert data."

While this is a good and necessary methodology, it has one important flaw. In most configurations, Snort is not told to report on what it sees if the traffic in question is deemed to be "normal." One might consider this aspect of Snort to be a benefit. Why generate an alert if the traffic is "normal" and not suspicious or malicious?

No alerting system can perfectly identify all suspicious or malicious activity. In many cases it's simply not possible -- especially on a packet-by-packet basis -- to identify a packet or stream as being worthy of an operator's attention. In those cases it makes sense to keep a log of the traffic. Recording traffic or characteristics of traffic for later analysis has recently been labeled retrospective network analysis (RNA), not to be confused with Sourcefire's Real-time Network Awareness. Others call recording traffic in this manner "network forensics," but that implies a degree of care and evidence handling that exceeds the methodology I present here.
When you collect data about traffic that Snort didn't consider to be suspicious or malicious, you have the opportunity to look back (hence the term "retrospective") to see what happened during an incident. How do you know to look back? Perhaps you receive a tip from law enforcement. Maybe a client reports odd activity. Or you perform a manual investigation and realize you'd like to know as much as possible about the network traffic of a certain host. In all of these situations, Snort might not have provided any clue that something was amiss.

Despite my attention to Snort in this series, I never deploy Snort as a stand-alone tool. I always supplement Snort with additional data sources. One of the most important supplementary data sources I collect is session data.

In my 15th Snort Report, already submitted to the publisher, I explain why IDS was never "dead." You might want to hear Marty Roesch's views on the subject in this video from RSA, where he also discusses Snort 3.0.

Read More

Snort Report 13 Posted

My 13th Snort Report titled How to use shared object rules in Snort is posted. From the start of the article:

Shared object (SO) rules were introduced in Snort 2.6.0 in early 2006 to provide a means to obscure the exact detection mechanism used in the rule and allow for more flexible detection criteria. However, for the most part, organizations have continued to rely upon traditional Snort rules. This may be about to change, in light of a recent security advisory from Sourcefire. Let's take a look at how to get shared object rules working on Snort sensors.

If you have questions on Snort you'd like me to try to answer, please post them as comments here. Thank you.

Read More

Snort Report 12 Posted

My 12th Snort Report titled Snort Frequently Asked Questions is posted. From the start of the article:

Service provider takeaway: Snort isn't perfect. In this tip, service providers will learn the answers to frequently asked questions about Snort's usage and limitations.

In this edition of the Snort Report, I address some of the questions frequently asked by service providers who are users or potential users of Snort. I say "potential users" because some people hear about Snort and wonder if it can solve a particular problem. Here I hope to provide realistic expectations for service providers using Snort.

Again, please note I did not write the words "Snort isn't perfect." The editor did. This is one of the aspects of the Snort Report I do not control. In this article I address these questions.

1. Can I use Snort to protect a network from denial-of-service attacks?


2. Can Snort decode encrypted traffic?


3. Can Snort detect layer 2 attacks?


4. Can Snort log flows or sessions?


5. Can Snort rebuild content from traffic?

If you like this article and have your own Snort questions, please post them here as comments. Thank you.

Read More

Snort Report 11 Posted

My 11th Snort Report on Snort Limitations has been posted. From the start of the article:

In the first Snort Report I mentioned a few things value-added resellers should keep in mind when deploying Snort:

1. Snort is not a "badness-ometer."
2. Snort is not "lightweight."
3. Snort is not just a "packet grepper."

In this edition of the Snort Report, I expand beyond those ideas, preparing you to use Snort by explaining how to think properly about its use. Instead of demonstrating technical capabilities, we'll consider what you can do with a network inspection and control system like Snort.

The editors titled this piece "Snort Limitations" -- I didn't.

Read More

Snort Report 10 Posted

My 10th Snort Report on Snort 2.8.0 new features: IPv6 and port lists is now available online. From the start of the article:

Snort 2.8.0 was recently published with several features long desired by Snort veterans. These new features include IPv6, port lists, packet performance monitoring and control of actions enabled by preprocessor or decoder events. This edition of the Snort Report provides details on IPv6 and port lists that VARs and systems integrators can use to optimize their use of the open source intrusion detection system.

In the next Snort Report I plan to look at other features in Snort 2.8.

Read More

Snort Report 9 Posted

My 9th Snort Report on Snort's Stream5 and TCP overlapping fragments is now available online. From the start of the article:

It's important for value-added resellers and consultants to understand how Snort detects security events. Stream5 is a critical aspect of the inspection and detection equation. A powerful Snort preprocessor, Stream5 addresses several aspects of network-centric traffic inspection. Sourcefire calls Stream5 a "target-based" system, meaning it can perform differently depending on the directives passed to it. These directives tell Stream5 to inspect traffic based on its understanding of differences of behavior in TCP/IP stacks. However, if Stream5 isn't configured properly, customers may end up with a Snort installation that is running but not providing much real value. In this edition of Snort Report I survey a specific aspect of Stream5, found in Snort 2.7.x and 2.8.x.

I'm working on the next Snort Report, which will look at new features in Snort 2.8.

Read More

Snort Report 8 Posted

My 8th Snort Report on How to Test Snort is now available online. From the start of the article:

"How do I test Snort?" is one of the most popular questions asked on the snort-users mailing list. While a seemingly simple question, the answer depends on your intent. Value-added resellers (VARs) and systems integrators (SIs) may need to provide customers with validation that the network intrusion detection system (IDS) is working as expected. This edition of Snort Report explains what it means to test Snort. I reveal some common misperceptions and offer alternatives to satisfy the majority of readers.

Also note that Snort 2.7.0.1 was posted today. The release notes appear to be the same as those for Snort 2.7.0, both online, in CVS and in the tarball.

Read More

Snort Report 7 Posted

My seventh Snort Report on Working with Unified Output has been posted. From the article:

In the last Snort Report we looked at output methods for Snort. These included several ways to write data directly to disk, along with techniques for sending alerts via Syslog and even performing direct database inserts. I recommended not configuring Snort to log directly to a database because Snort is prone to drop packets while performing database inserts. In this edition of the Snort Report I demonstrate how to use unified output, the preferred method for high performance Snort operation.

In the next edition I plan to discuss testing Snort.

Read More

Snort Report 6 Posted

My sixth Snort Report -- Output options for Snort data has been posted. From the introduction:

Output modes are the methods by which Snort reports its findings when run in IDS mode. As discussed in the first Snort Report, Snort can also run in sniffer and packet logger modes. In sniffer mode, Snort writes traffic directly to the console. As a packet logger, Snort writes packets to disk in Libpcap format. This article describes output options for IDS mode, called via the -c [snort.conf] switch. Only IDS mode offers output options.

This is the first of two Snort Reports in which I address output options. Without output options, consultants and VARs can't produce Snort data in a meaningful manner. Because output options vary widely, it's important to understand the capabilities and limitations of different features. In this edition of Snort Report, I describe output options available from the command line and their equivalent options (if available) in the snort.conf file. I don't discuss the Unix socket option (-A unsock or alert_unixsock). I will conclude with a description of logging directly to a MySQL database, which I don't recommend but explain for completeness.

In the next edition I will discuss Barnyard.

Read More

Snort Report 5 Posted

The fifth Snort Report -- Snort Rules -- has been posted. In this article I talk about what Snort rules really mean. I discuss how to get rules from Sourcefire and Bleeding Edge. I don't plan to explain the rules in a feature-by-feature manner because the Snort Manual does that already.

Also, Snort 2.6.1.4 is available. Here are the release notes.

If you missed the earlier editions they are linked at the top of the list on my company research page.

Read More

Snort Report 4 Posted

The fourth Snort Report -- Installing Snort 2.7 Beta 1 and Snort CVS -- has been posted. In the article I show how to install the latest Snort beta from an archive and how to operate a patched version by installing Snort from CVS.

If you missed the earlier editions they are linked at the top of the list on my company research page.

Read More

Snort Report 3 Posted

My third Snort Report has been posted. Using the snort.conf file built in the second Snort Report, I show how Snort can detect suspicious activity without using any rules or dynamic preprocessors. Granted, the examples are somewhat limited, but you get the idea. The purpose of these articles is to develop an intuitive understanding of Snort's capabilities, starting with the basics and becoming more complicated.

Read More