VRT Rule Update for 09/29/2011

Join us as we welcome the introduction of the newest rule release for today from the VRT. In this release we introduce 266 new rules and make modifications to 7 additional rules.

There were no changes made to the snort.conf in this release.

In VRT's rule release:

The Sourcefire VRT has added and modified multiple rules in the backdoor, bad-traffic, blacklist, botnet-cnc, deleted, dos, exploit, misc, netbios, scada, specific-threats, spyware-put, web-activex, web-client and web-misc rule sets to provide coverage for emerging threats from these technologies.

In order to subscribe now to the VRT's newest rule detection functionality, you can subscribe for as low as $29 US dollars a year for personal users, be sure and see our business pricing as well at http://www.snort.org/store. Make sure and stay up to date to catch the most emerging threats!

VRT Rule release for 09/27/2011

Join us as we welcome the introduction of the newest rule release for today from the VRT. In this release we introduce 170 new rules and make modifications to 14 additional rules.

There were no changes made to the snort.conf in this release.

In VRT's rule release:

The Sourcefire VRT has added and modified multiple rules in the backdoor, blacklist, botnet-cnc, dos, exploit, misc, netbios, policy, pop3, scada, shellcode, smtp, specific-threats, web-activex, and web-misc rule sets to provide coverage for emerging threats from these technologies.

In order to subscribe now to the VRT's newest rule detection functionality, you can subscribe for as low as $29 US dollars a year for personal users, be sure and see our business pricing as well at http://www.snort.org/store. Make sure and stay up to date to catch the most emerging threats!

Snort 2.9.1: Registered Users now have access to the VRT ruleset

As you know, per the VRT license, registered users must wait 30 days between the time of release of the rules and when they have access to them.  Subsequently people who are not subscribers could not run the Snort version 2.9.1.0 release of the older Shared Object rules available from the VRT.

Well, since the release of 2.9.1, it's been 30 days now, and those that couldn't upgrade to 2.9.1 because of this restriction, your days of waiting are over.

Registered users have now passed the 30 day mark, and can now upgrade to Snort 2.9.1.

Please be sure and read all the blog posts that are associated with Snort 2.9.1 here.

Snort 2.9.1: SIP preprocessor

The Session Initiation Protocol (SIP) is widely used in Internet telephone calls and for multimedia distribution. It is an application layer control (signaling) protocol, and is actually very similar to the HTTP protocol in terms of syntax. But because of its increasing popularity and vulnerabilities found, we designed the SIP preprocessor to tackle these challenges. In this article, I will show you how to effectively use several key features of the preprocessor in detail.

In summary, there are three key features in this preprocessor:

1) Built-in alerts on most found common vulnerabilities
2) Writing your own rule using rule options provided by SIP preprocessor
3) Ignore the call channel

Built-in alerts

When I wrote this preprocessor, I collected all the SIP related vulnerabilities found in recent years. I was actually very surprised with how much those vulnerabilities were in common. You can get the full list from the snort manual or the README.reputation file. The majority of vulnerabilities are related with the format of the SIP message, either a field missing or a field is too long. Let's look at an example:

URI field

1) This field is required, and shouldn't be empty. I provide one alert for empty field (show below). If you don't want this alert, you can simply delete it from the preprocessor.rules. If you want to change to other action, you can replace "alert" with that action (drop, pass, etc).

alert ( msg: "SIP_EVENT_EMPTY_REQUEST_URI"; sid: 2; gid: 140; rev: 1; metadata: rule-type preproc ; classtype:bad-unknown; reference:cve,2007-1306; )

2) In general, the length of this field should be limited to some number, such as 512. When the length exceeds the normal range, either the packet is bad or it is exploring a potential vulnerability through an extra long field. If you want to enforce a particular length in your system, you can change the length through the SIP preprocessor configuration max_uri_len.

alert ( msg: "SIP_EVENT_BAD_URI"; sid: 3; gid: 140; rev: 1; metadata: rule-type preproc ; classtype:bad-unknown; )

Apart from inspecting format, the SIP preprocessor also inspects call sequence. The "InviteReplay" billing attack and "FakeBusy" billing attack are alerted. These attacks are difficult to detect simply only by using rules. The SIP preprocessor provides a simple and quick way to detect them.

SIP preprocessor rule options

In you want to expand your inspection beyond built-in alerts, you may write your own rule or simply use our rule pack. SIP preprocessor provides four new rule options to help you:

sip_method
sip_stat_code
sip_header
sip_body



Those options are similar to the rule options used in HTTP inspector, but they are not content modifiers. I will not go the details of every keyword, as you can find the details in the snort manual and README.reputation.

However, I want to emphasize two features here:

One powerful feature of sip_method/sip_stat_code is: you can specify several methods/status codes together. This will make rule writing easy. For example:
If you want to apply a rule to invite message and cancel message, you can use:

alert udp any any -> any 5060 (sip_method:invite, cancel; sid:1000000)


Another feature is that you can use pcre option H and P for SIP message:

H: Match SIP request or SIP response header, Similar to sip_header.
P: Match SIP request or SIP response body, Similar to sip_body

Ignore call channel

Similar to the FTP preprocessor, the SIP preprocessor also provides ability to ignore the call channel. It can be enabled through the SIP preprocessor configuration: ignore_call_channel. After a media session is created, the media data is transmitted in the call channel. If a user is not interested with that data, Snort can focus on other traffic by totally ignoring the data channel. When the media session is terminated using SIP, the ignored channel will be reinspected again. If there is not a termination signal received, Snort uses a timeout to reinspect the channel again.

Snort 2.9.1 Installation Guide for RHEL 6.1 has been released

Thanks to Randal Rioux for producing his awesome installation guide for RHEL 6.1 Server x64 for Snort 2.9.1.

Not only does Randy display how to set up Snort 2.9.1, but also includes the instructions for Barnyard2.  Nice work.

Once again, thanks Randy for his document, it's posted on http://www.snort.org/docs as always!

Snort 2.9.1 Installation Guide for CentOS 5.6 has been released

Thanks to Nick Moore for producing his awesome installation guide for CentOS 5.6 for Snort 2.9.1.

One of the biggest changes of note for Snort 2.9.1 that troubled people in the past was all the compile tags that we recommend that you build in.  The recommended configuration was to download the VRT ruleset and use the compile tags at the top of the snort.conf included in that ruleset and compile Snort with those options.  So, in order to ease the pain of installation of Snort, we took those compile options (except for the rule performance monitoring and preprocessor monitoring compile options) and built those in by default.

Building Snort with the recommended options is as simple as "./configure" now, in addition, if you want to enable the performance monitoring for rules and preprocessors, just add the --enable-sourcefire compile tag to your configure line (./configure --enable-sourcefire) and you'll have the same Snort build we use here at Sourcefire.

Once again, thanks Nick for his document, it's posted on http://www.snort.org/docs as always!

VRT Rule Update for 09/21/2011

Join us as we welcome the introduction of the newest rule release for today from the VRT. In this release we introduce 4 new rules and make modifications to 1 additional rules.

There were no changes made to the snort.conf in this release.

In VRT's rule release:

The Sourcefire VRT has added and modified multiple rules in the exploit, specific-threats, and web-client rule sets to provide coverage for emerging threats from these technologies.

In order to subscribe now to the VRT's newest rule detection functionality, you can subscribe for as low as $29 US dollars a year for personal users, be sure and see our business pricing as well at http://www.snort.org/store. Make sure and stay up to date to catch the most emerging threats!

VRT Rule Update for 09/20/2011

Join us as we welcome the introduction of the newest rule release for today from the VRT. In this release we introduce 9 new rules and make modifications to 6 additional rules.

There were no changes made to the snort.conf in this release.

In VRT's rule release:

The Sourcefire VRT has added and modified multiple rules in the blacklist, botnet-cnc, deleted, dos, exploit, policy, specific-threats, spyware-put, web-activex and web-misc rule sets to provide coverage for emerging threats from these technologies.

In order to subscribe now to the VRT's newest rule detection functionality, you can subscribe for as low as $29 US dollars a year for personal users, be sure and see our business pricing as well at http://www.snort.org/store. Make sure and stay up to date to catch the most emerging threats!

VRT Rule Update for 09/16/2011

Join us as we welcome the introduction of the newest rule release for today from the VRT. In this release we introduce 41 new rules and make modifications to 63 additional rules.

There were no changes made to the snort.conf in this release.

In VRT's rule release:

The Sourcefire VRT has added and modified multiple rules in the blacklist, botnet-cnc, deleted, dos, exploit, policy, specific-threats, spyware-put, web-activex and web-misc rule sets to provide coverage for emerging threats from these technologies.

In order to subscribe now to the VRT's newest rule detection functionality, you can subscribe for as low as $29 US dollars a year for personal users, be sure and see our business pricing as well at http://www.snort.org/store. Make sure and stay up to date to catch the most emerging threats!

Snort 2.9.1 HTTP and SMTP logging features

To provide better context to the alerts generated by Snort, Snort version 2.9.1 introduced some new logging features for HTTP and SMTP which will help the user to better analyze the alerts. This logging of extra data by HTTP Inspect and SMTP preprocessors is similar to the X-Forwarded-For/True-Client-IP logging introduced prior to Snort 2.9.1.

HTTP Logging:

---

Let's talk about HTTP URI and Hostname logging.

How to enable logging of HTTP URI and Hostname?

To turn on the logging of the HTTP Request URI, the config option to use is "log_uri" and to enable the logging of hostnames, use the config option "log_hostname" as shown in the example below:

preprocessor http_inspect: global memcap
preprocessor http_inspect_server: log_uri \
log_hostname

The memcap here will determine the maximum amount of memory the HTTP Inspect preprocessor will use for logging the URI and Hostname data. You can refer to the Snort Manual for further details.

When these features are turned on in HTTP Inspect, the HTTP Request URI and HTTP Request hostname headers are extracted and logged to unified2 as an "extra data event" with each alert generated for that particular session. It is recommended to turn on stream5 reassembly with PAF on HTTP ports to ensure correctness and accuracy.

When a HTTP Request URI is greater than 2048 or when a HTTP hostname (specified in the "Host" Request header) is greater than 256, Snort will log the truncated the URI and/or hostname. A preprocessor alert with GID:119 and SID:25 is generated when hostname exceeds 256 bytes.

There is also a preprocessor alert with GID:119 and SID:24 for multiple "Host" headers in one HTTP request.

Please note that the URI and hostname are only logged in Unified2 mode and not logged with -A cmg.

So, how do you read the output?

Unified2 can be read using the Snort tool u2spewfoo. You can find it under the tools/u2spewfoo directory in the Snort tarball.

Example of the Output:

---


(Event)
sensor id: 0 event id: 2 event second: 1299776137 event microsecond: 355217
sig id: 1 gen id: 1 revision: 0 classification: 0
priority: 0 ip source: 10.1.2.3 ip destination: 10.9.8.7
src port: 60710 dest port: 80 protocol: 6 impact_flag: 0 blocked: 0

Packet
sensor id: 0 event id: 2 event second: 1299776137
packet second: 1299776137 packet microsecond: 355217
linktype: 1 packet_length: 214
[ 0] 02 09 08 07 06 05 02 01 02 03 04 05 08 00 45 00 ..............E.
[ 16] 00 C8 00 04 00 00 40 06 5C 19 0A 01 02 03 0A 09 ......@.\.......
[ 32] 08 07 ED 26 00 50 00 00 00 02 00 00 00 02 50 10 ...&.P........P.
[ 48] 01 00 0C 19 00 00 47 45 54 20 2F 20 48 54 54 50 ......GET / HTTP
[ 64] 2F 31 2E 30 0D 0A 48 6F 73 74 3A 20 77 77 77 2E /1.0..Host: www.
[ 80] 77 33 2E 0D 0A 20 6F 72 67 20 0D 0A 55 73 65 72 w3... org ..User
[ 96] 2D 41 67 65 6E 74 3A 20 4D 6F 7A 69 6C 6C 61 2F -Agent: Mozilla/
[ 112] 35 2E 30 20 28 58 31 31 3B 20 55 3B 20 4C 69 6E 5.0 (X11; U; Lin
[ 128] 75 78 20 78 38 36 5F 36 34 3B 20 65 6E 2D 55 53 ux x86_64; en-US
[ 144] 3B 20 72 76 3A 31 2E 39 2E 32 2E 31 35 29 20 47 ; rv:1.9.2.15) G
[ 160] 65 63 6B 6F 2F 32 30 31 31 30 33 30 33 20 55 62 ecko/20110303 Ub
[ 176] 75 6E 74 75 2F 31 30 2E 31 30 20 28 6D 61 76 65 untu/10.10 (mave
[ 192] 72 69 63 6B 29 20 46 69 72 65 66 6F 78 2F 33 2E rick) Firefox/3.
[ 208] 36 2E 31 35 0D 0A 6.15..



(Event)
sensor id: 0 event id: 3 event second: 1299776137 event microsecond: 355254
sig id: 1 gen id: 1 revision: 0 classification: 0
priority: 0 ip source: 10.1.2.3 ip destination: 10.9.8.7
src port: 60710 dest port: 80 protocol: 6 impact_flag: 0 blocked: 0

Packet
sensor id: 0 event id: 3 event second: 1299776137
packet second: 1299776137 packet microsecond: 355254
linktype: 1 packet_length: 176
[ 0] 02 09 08 07 06 05 02 01 02 03 04 05 08 00 45 00 ..............E.
[ 16] 00 A2 00 05 00 00 40 06 5C 3E 0A 01 02 03 0A 09 ......@.\>......
[ 32] 08 07 ED 26 00 50 00 00 00 A2 00 00 00 02 50 10 ...&.P........P.
[ 48] 01 00 8F E5 00 00 41 63 63 65 70 74 2D 45 6E 63 ......Accept-Enc
[ 64] 6F 64 69 6E 67 3A 20 67 7A 69 70 2C 64 65 66 6C oding: gzip,defl
[ 80] 61 74 65 0D 0A 41 63 63 65 70 74 2D 43 68 61 72 ate..Accept-Char
[ 96] 73 65 74 3A 20 49 53 4F 2D 38 38 35 39 2D 31 2C set: ISO-8859-1,
[ 112] 75 74 66 2D 38 3B 71 3D 30 2E 37 2C 2A 3B 71 3D utf-8;q=0.7,*;q=
[ 128] 30 2E 37 0D 0A 4B 65 65 70 2D 41 6C 69 76 65 3A 0.7..Keep-Alive:
[ 144] 20 31 31 35 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 115..Connection
[ 160] 3A 20 6B 65 65 70 2D 61 6C 69 76 65 0D 0A 0D 0A : keep-alive....


(ExtraDataHdr)
event type: 4 event length: 33


(ExtraData)
sensor id: 0 event id: 2 event second: 1299776137
type: 9 datatype: 1 bloblength: 9 HTTP URI: /


(ExtraDataHdr)
event type: 4 event length: 43


(ExtraData)
sensor id: 0 event id: 2 event second: 1299776137
type: 10 datatype: 1 bloblength: 19 HTTP Hostname: www.w3.org


In the output above, two extra data events are generated for the event with GID:1 and SID: 1. The first extra data event displays the URI and the second displays the hostname associated with that session.

It is important to note that the unique "event id" and "event second" are used to correlate the alerts with their extra data. The "event type" indicates the presence of an "extra data" record and the unique "type" will determine the type of the extra data event logged. Here is a list of extra data types used in Snort.

Type 1: True-Client-IP/XFF IPv4 address
Type 2: True-Client-IP/XFF IPv6 address
Type 4: HTTP Gzip decompressed data
Type 5: SMTP filename
Type 6: SMTP MAIL FROM addresses
Type 7: SMTP RCPT TO addresses
Type 8: SMTP Email headers
Type 9: HTTP Request URI
Type 10: HTTP Request Hostname
Type 11: Packet's IPv6 Source IP Address
Type 12: Packet's IPv6 Destination IP Address

SMTP Logging:

---

The SMTP preprocessor, similar to HTTP Inspect preprocessor, can log extra data associated with each alert. The data that SMTP logs are as follows:

1. The email addresses in the MAIL FROM command.
2. The email addresses in the RCPT TO command. When there are multiple RCPT TO headers, the email addresses are concatenated using commas.
3. The filename of the MIME attachment extracted from the "Content-Disposition" header. Multiple filenames are appended with commas.
4. SMTP email headers.

How to enable logging of SMTP "extra data"?

SMTP preprocessor can log the extra data mentioned above using the following config options.

preprocessor smtp: memcap 838860 \
log_mailfrom \
log_rcptto \
log_filename \
log_email_hdrs \
email_hdrs_log_depth 56

The config options "log_mailfrom", "log_rcptto", "log_filename" and "log_email_hdrs" do not take any arguments. However, email_hdrs_log_depth requires the user to pass a number between 0-20480, which will determine in bytes the amount of email headers logged. The config option "memcap" is used to determine the maximum memory used for logging the above mentioned data.

Again, stream5 reassembly needs to be turned on for SMTP ports for this feature to work correctly. Without stream5 reassembly, the SMTP extra data won't be logged.

How to read the Output?

Like HTTP extra data, SMTP extra data can be read using the u2spewfoo and "event id" and "event second" are used to correlate the alerts with their extra data events.

Example of the Output:

---


(ExtraData)
sensor id: 0 event id: 2 event second: 1273194706
type: 6 datatype: 1 bloblength: 33 SMTP MAIL FROM Addresses:

(ExtraData)
sensor id: 0 event id: 2 event second: 1273194706
type: 7 datatype: 1 bloblength: 57 SMTP RCPT TO Addresses: ,

(ExtraData)
sensor id: 0 event id: 2 event second: 1273194706
type: 5 datatype: 1 bloblength: 26 SMTP Attachment Filename: sample.txt,foo.txt

(ExtraData)
sensor id: 0 event id: 2 event second: 1273194706
type: 8 datatype: 1 bloblength: 323 SMTP EMAIL HEADERS:
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/mixed; boundary="_----------=_12731947069000"
Date: Thu, 6 May 2010 21:11:46 -0400
From: bbantwal@sourcefire.com
To: bbantwal@sourcefire.com
Subject: Email Sent via Perl
X-Mailer: MIME::Lite 3.027 (F2.74; T1.29; A2.06; B3.07; Q3.07
<bbantwal@sourcefire.com><bbantwal@sourcefire.com><foo-barfoo@gmail.com>

We will not be updating the spo_database output method to insert this information into the database.  As a reminder, this output method will be removed in a future Snort release in 2012.  Sourcefire has turned over the maintenance of the "ACID" database schema to the Barnyard2 group, and will also, no longer be maintaing it either.

VRT Rule Update for 09/13/2011, MS Tuesday

Join us as we welcome the introduction of the newest rule release for today from the VRT. In this release we introduce 24 new rules and make modifications to 27 additional rules.

There were two changes made to the snort.conf in this release.  Since all pop3 and sql Shared object rules have been moved to GID 1 format, we've removed the following two files:

include $SO_RULE_PATH/pop3.rules
include $SO_RULE_PATH/sql.rules

In VRT's rule release:

Synopsis: The Sourcefire VRT is aware of vulnerabilities affecting products from Microsoft Corporation.

Details: Microsoft Security Advisory MS11-071: A programming error in the Microsoft Windows operating system may allow a remote attacker to execute code on an affected system. The problems occur due to certain components being allowed to load DLL files from untrusted locations.
Rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 1, SIDs 20118 and 20119.

Microsoft Security Advisory MS11-072: Microsoft Excel contains programming errors that may allow a remote attacker to execute code on an affected system.
Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 1, SIDs 20121 through 20128.

Microsoft Security Advisory MS11-073: Microsoft Office contains a programming error that may allow a remote attacker to execute code on an affected system.
A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 1, SID 20129.

Additionally, previously released rules will also detect attacks targeting this vulnerability and are included in this release with updated reference information. The are identified with GID 3, SIDs 18494 and 18495.

Microsoft Security Advisory MS11-074: Microsoft SharePoint contains programming errors that may allow a remote attacker to elevate privileges on an affected system.
Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 1, SIDs 20111 through 20117.

In order to subscribe now to the VRT's newest rule detection functionality, you can subscribe for as low as $29 US dollars a year for personal users, be sure and see our business pricing as well at http://www.snort.org/store. Make sure and stay up to date to catch the most emerging threats!

Snort 2.9.1 Guide for OSX Lion published!

Christoph Murauer updated his install guide for Snort 2.9.1 on OSX 10.7 "Lion" this past week.

Check out the install guide here.

We'd like to thank Christoph, and all of our Open Source contributors, with their patches, install guides, and documentation.  You are what makes the community powerful.  Thanks!

What is PAF?

Snort is constantly being updated to improve detection and/or performance to keep pace with the networks it monitors. The stream5 preprocessor was updated for 2.9.0 to perform stream normalization that enables better detection prior to acknowledgement of the data. In Snort 2.9.1 we further that effort with the addition of what we call Protocol Aware Flushing (PAF).

To understand PAF, we need to look at how TCP, the Transmission Control Protocol, is used to provide reliable communication between hosts. The basic idea with TCP is that a sequence of octets goes in one end and that exact same sequence comes out the other, nothing added, deleted, or otherwise changed.

The key here is that we are talking about a sequence. TCP knows nothing of how the data is structured or where one message ends and the next begins. That makes things interesting for Snort because, internally, TCP will slice an arbitrarily long sequence of octets into segments as it sees fit.

Consider this example where an HTTP client wants to send two GETs to a server (one packet per line):

GET /1 HTTP/1.0\r\n\r\n
GET /2 HTTP/1.0\r\n\r\n



Snort might see one packet per GET, but in the general case, especially where the payload is longer than the MTU, there will be multiple packets and Snort may see something like this:

GET /1 HT
TP/1.0\r\n\r\nGET /2
HTTP/1.0\r\n\r\n



There are literally billions of ways to slice this little 38 character sequence, from one character per packet to both requests in a single packet. Historically, IDS evasion techniques used small TCP segments, and those were overcome by doing TCP reassembly within Snort. Without reassembly, rule contents would not reliably match.

Reassembling the accumulated data and releasing the associated buffers is called flushing. Prior to PAF, stream5 would flush when the number of segments and the number of octets accumulated reached certain thresholds. These thresholds were effective but ultimately a "one-size-fits-all" approach.

To take detection to the next level, the flush points had to be protocol specific and PAF allows the application preprocessors to determine when to flush. The first preprocessors to use this stream5 feature are http_inspect and dce2. In the example above, each GET request will be flushed separately, regardless of how it is segmented by TCP.

To enable PAF, add this to your snort.conf:

config paf_max: 16000



In our testing, using 16k has resulted in improved accuracy of detection. Larger values can improve detection but also increase packet processing latency and variance.

HTTP and DCE/RPC were the first choices based on traffic volume and complexity, respectively. Later releases of Snort will add PAF support for other protocols, and new preprocessors are being designed to use this feature.

Flow matters

Recently on one of the Snort lists, there was a thread that argued that the "flow" statement in rules didn't matter if you had your variables set correctly.  This is a common misconception, so I thought I'd write a post about it and explain why flow, and its use in rules is important.

First let's talk about what flow is.  The Snort reference manual says:

The flow keyword is used in conjunction with TCP stream reassembly. It allows rules to only apply to certain directions of the traffic flow.

You can click on the link above to read all about the different flow operators there are, I'm not going to regurgitate them here.  But one thing to keep in mind, is that to_client and from_server are the same.  As are to_server and from_client.

Let's take four rules for example.  

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (flow:to_server,established;) 

Simple.  Someone on your HOME_NET going to EXTERNAL_NET on a HTTP_PORTS specified port, and the client initiated the conversation. 

Example:  Someone going to "www.google.com" or any Web site from your network outbound.

What about the opposite of that?

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (flow:to_client,established;)

Again, pretty simple, someone went to a webpage, and now your rule is looking for the result of that action.  The webpage (or file, or whatever) is coming down to the browser from the server.

Example:  Someone went to "www.maliciouspdf.com" and downloaded a malicious PDF.  You are not attempting to see if someone requested a ".pdf" as a download, (although you may do that to set a flowbit, see my post on resolving flowbit dependancies here), but you are looking for the actual PDF coming back down from the server. 

So, let's take our first example and flip the flow.  Remember, this is all assuming that you have HOME_NET and EXTERNAL_NET set, just like the email thread was implying.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (flow:to_client,established;)

So, traffic headed outbound from my network over HTTP_PORTS, but HOME_NET did not initiate the conversation.

Example:  Let's say someone sets their source port as 80, and then infiltrates your network through a connection that starts outside (the initial SYN packet was sent inbound to HOME_NET), you are looking for the traffic leaving your network headed back to that attacker who set his source port as 80.  Maybe they are exfiltrating the DOC files off of your network.

Finally, let's look at the opposite of example two above.

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (flow:to_server,established;)

Traffic headed inbound to the network over $HTTP_PORTS but HOME_NET again did not initiate the conversation.

Example:  Again, let's say someone sets their source port as 80, and then infiltrates your network, this rule will look for the connections inbound to your network.  Let's say they are requesting a DOC file from your network.  Whereas the previous rule would look for the DOC file leaving, this rule will look for the initial request.

These are very simplistic examples, hopefully this post will help explain why flow is so important.  Variables tell Snort which direction the traffic is going (inbound or outbound of your network in the simplest of terms), flow tells Snort who is responsible for which aspect of the conversation (are you a server, or a client?).

Any further questions about Snort and it's operation should be directed to the Snort mailing lists.  The best place to get your questions answered.

Snez: New Snort GUI has been posted

If you head over to our "additional-downloads" page on Snort.org, you'll notice a new project at the bottom of the list named "Snez".  From the project's Sourceforge page:

SNEZ is a web interface to the popular open source IDS program SNORT® . The main design feature of SNEZ is the ability to filter (or dismiss) alerts without having to delete.

 Take a look at this new project and help the author out by providing feedback!

VRT Rule Update for 09/07/2011

Just updated, is a rule release for today from the VRT.  This rule release contains 48 new rules and 20 rule updates, mostly malware:

There are no changes to the snort.conf in this release.

The Sourcefire VRT has added and modified multiple rules in the backdoor, blacklist, botnet-cnc, chat, exploit, scada, specific-threats, spyware-put, web-activex, and web-misc rule sets to provide coverage for emerging threats from these technologies.

In order to subscribe now to the VRT's newest rule detection functionality, you can subscribe for as low as $29 US dollars a year for personal users, be sure and see our business pricing as well at http://www.snort.org/store.  Make sure and stay up to date to catch the most emerging threats!

VRT Rule Update for 09/01/2011

Just updated, is a rule release for today from the VRT.  This rule release contains 88 new rules and 28 rule updates, mostly malware:

There are no changes to the snort.conf in this release.

The Sourcefire VRT has added and modified multiple rules in the backdoor, blacklist, botnet-cnc, content-replace, exploit, imap, netbios, pop3, shellcode, specific-threats, spyware-put, sql, web-activex, and web-misc rule sets to provide coverage for emerging threats from these technologies.

In order to subscribe now to the VRT's newest rule detection functionality, you can subscribe for as low as $29 US dollars a year for personal users, be sure and see our business pricing as well at http://www.snort.org/store.  Make sure and stay up to date to catch the most emerging threats!