Shared Object Rule EOL for certain Distros

Just a brief news note about the EOL for certain pre builds of our Shared Object rules that will be taking place in two weeks (February 7th)

EOL for the following:
-------------------------------
Debian "Lenny/Sid"
FC9
FC11 & FC12 (see below)

Updates
------------
Debian 5.0.7+
CentOS 5.4 will be updated to CentOS 5.5
Fedora 11 will be updated to Fedora 13, which is the new "previous"
Fedora 12 will be updated to Fedora 14, which is the new "current"
RHEL5 will be updated to RHEL 5.5 to include i386 and x86-64 support

Oklahoma City Snort talk at ISSA Meeting

Mitch Russell, a member of the Snort Community is giving a talk about Snort at the Oklahoma City ISSA Meeting on February 16, 2011.

The meeting will take place at Noon CST, at the Spaghetti Warehouse at 101 East Sheridan, Oklahoma City.

If you are in the area, you are encouraged to attend!

If you know of a Snort speaking event, or if you are giving one, please let me know, and we'll put it up on the Snort.org website on the Snort Speaking Events page, and we'll publicize it on the Snort.org blog for you as well.

External DAQ module has been released

Have you ever wanted to maintain your own DAQ module outside of the official LibDAQ distribution? Concerned about the official release cycle in relation to your own development? Tired of keeping a source patch for the official distribution up-to-date?

The example-daq-module tarball demonstrates the suggested process for externalizing the DAQ module build process, providing a bare bones example DAQ module and the autotools to support it.

Here is a quick description of the autoconf macros provided in sf.m4:

AC_ENABLE_VISIBILITY() - Default to hidden symbol visibility if the compiler supports it.
AC_SF_COMPILER_SETUP() - Add all of the wonderful compiler and linker flags we'd like to have with GCC or ICC.
AC_CHECK_DAQ_API() - Check for the presence of the DAQ API headers and provide a configuration option to specify their location (--with-libdaq-includes).
AC_CHECK_SFBPF() - Check for the presence of the SFBPF headers and library and provide configuration options to specify their locations (--with-libsfbpf-includes and --with-libsfbpf-libraries respectively).

The basic steps involved in taking example-daq-module and making it your own 
1. Unpack example-daq-module-0.1.tar.gz
2. Rename daq_example.c to daq_<your module name>.c
3. Implement all of the function stubs in the C file (see the daq_api.h for descriptions)
4. Update configure.ac and Makefile.am to reflect your name change (%s/example/<your module name>/g)
5. Add any additional autoconf-foo you want to configure.ac (arguments, header checks, library checks, etc)
6. Regenerate the autoconf files with 'autoreconf -ivf'
7. Configure, make, and make install!

The only caveat with this process is that you CANNOT include your DAQ module with the static DAQ modules when building externally. This should not be an issue for the majority of users. Please check it out if you want to, if you have any questions please feel free to post them to the Snort-devel mailing list.

Are you speaking about Snort?

Are you attending a Security Conference where there is a presentation on Snort?
Are you presenting at a Security Conference about Snort?

Email me!  I'd like to have a running list of Security Conferences with presentations about our OpenSource technologies.  We'll maintain it on the website and help publicize the speaking engagement for you!

Thanks!

New Shared Object rule support

Some news from the VRT, as of yesterday's subscriber release, they've released Shared Object rule support for the following platforms:

• Debian 5.0 x86-x64
• Debian 5.0 x86
• Slackware 13.1 x86-64
• RHEL 6.0 x86-64
• RHEL 5.5 x86-64
• OpenBSD 4.8 x86-64
• OpenBSD 4.8 x86

For our complete list of VRT Shared Object rules supported platforms go to:

http://www.snort.org/snort-rules/about-so_rules

For more information on yesterday's rule release:

http://www.snort.org/vrt/advisories/2011/01/13/vrt-rules-2011-01-13.html

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.  Be sure and stay up to date to catch the most emerging threats!

OpenBSD Snort 2.9.0.3 setup guide

Just added to http://snort.org/docs, another awesome setup guide from the Snort community, covering the latest version of Snort (2.9.0.3) on OpenBSD.

I'd like to thank Randal Rioux for his guide, as I know that takes a lot of time to write up.  We are always on the lookout for more setup guides, whitepapers, and how-to's from the community.  If you are interested in writing one, please contact me, and I will help you in anyway I can.
joel [at] snort.org

Thanks Randal!

False Positive Submission form

Shortly before we set the blog up, one of the features that was brought to the Snort.org website was the ability to submit a false positive via the website.  That feature can be found here:

https://www.snort.org/uploads

It requires you to login to Snort.org to be able to use the website, as this method provides us a valid point of contact for us to get a hold of you should we need further information, and to provide feedback.

If you notice false positives occurring with the VRT ruleset, please submit them via the above form, and VRT will get investigate your report and get back to you.

GUIs for Snort

I asked for people to send me topics that they'd like to learn more about in Snort, and I received a good amount of responses.  So I thought I'd get started on one of them.  (BTW - if you'd like to get our input on something Snort related for the blog, please feel free to email me at joel [at] snort.org)

Every so often (probably twice a year) there seems to be an uptick in the amount of people emailing the mailing lists asking about GUIs for Snort.  Many of them repeat offenders.  So I am guessing that either people don't know about the GUI options for Snort or people don't like the ones they have.  So let's start off with a few in alphabetical order:

BASE
BASE, the Basic Analysis and Security Engine was based off of the old ACID code codebase.  The ACID GUI interface (which is now dead, and has been for about five or six years) was a college project written by an attendee of Carnegie Mellon.  It hasn't been actively developed since about 2003.  BASE, a fork of the ACID code, picked up where the original author left off, added a bunch of new features, and made it easy to use, multi-language, and a  highly functional GUI.  There were plans for a redesign of BASE, including the database format that it reads from, but Kevin Johnson, the original BASE project manager has since left the project and turned the project over to new management.  However, it remains the most popular Snort GUI interface with over 215,000 downloads.  BASE is written in PHP, and has several dependencies.  BASE has it's own IRC channel #secureideas, although there is rarely anyone there, so most people come to the default #snort for help.

OSSIM
OSSIM, made by AlienVault stands for "Open Source Security Information Management".  Not only can it take the logs from Snort and display them in a great looking interface, but it also integrates with many other tools (p0f, arpwatch, pads, nessus, ntop, nagios, etc) for a consistant user interface.  I've personally never used this tool, but I've heard from the people that use do use it, and find it really a joy to use.

PLACID
Standing for "Phil Loathes ACID", it was originally made as a super stripped down way of simply looking at Snort Events in the Snort DB.  It has stayed that way.  There is a certain demographic of Snort users that like simple, text based interfaces, and PLACID serves that need.

SGUIL
(Pronounced "Squeel")  SGUIL started off as the "Snort GUI for Lamers".  The project, maintained by Bamm Vischer, is a multi part system consisting of a "Sensor", "Server", and "Client".  Not only is SGUIL a GUI for Snort, but it also integrates other technologies into the recording of data for use by the analyst as well (including fulltime, full packet capture).  This is a heavy weight technology, is written in TCL, and is a very well performing engine.  Most people start off with a GUI like BASE and move into SGUIL.  SGUIL also has it's own IRC channel #snort-gui.

Snorby
A relative newcomer to the Snort GUI area, Snorby uses a lot of "Web 2.0" effects and rendering providing the user with a very sharp and beautifully functioning tool.   This seems to be the current "go-to" web interface for Snort.  While it has many of the features of BASE (and a lot more, hotkeys, classifications, an iOS interface, and actual pdf reporting), and not as featured as SGUIL (in terms of architecture), it's extremely easy to deploy, looks fantastic, and functions as an alert browser very well.  Snorby's code is hosted on Github, here.  Another advantage of Snorby is that it integrates with the OpenFPC project.  Functioning similar to how SGUIL collects all information on the network using Full Packet Capture (FPC), Snorby gives you the ability to not only view the Snort alert, but also to view the alerts in context with the rest of the packet flow on the network.  Snorby's IRC channel can be found at #snorby.

SQueRT
Paul wrote in about SQueRT.  SQueRT uses the SGuil database format and is also web based.  You can see the screenshots and download it at the link above.

This is by no means complete, these are just the most common that I see people using.  If I have missed a free Snort GUI that you enjoy, please feel free to respond in the comments.  The more complete your post, the better.  Give people links to your favorite tool.

Update:  http://blog.snort.org/2011/10/comparison-of-3-popular-snort-guis.html

FirePOWER
While not free by any means, the FirePOWER system is the commercial system that we develop here at Cisco.  Not only making the administration and analysis of events from Snort (the engine embedded into FirePOWER) extremely simple, it couples hundreds of more features into an extremely complex system with a simple to understand and navigate GUI.  Made to keep large deployments simple, and small deployments even easier, this is by far, the best system made. (We're biased)  But, is not free.

Polman, another rule manager for Snort

Most people know about rule management tools for Snort, Oinkmaster and even PulledPork, however, one of the members of the Snort community, Edward Fjellskål, decided that neither one of those tools was for him, so he wrote a rule manager, with kind of a different twist to it.

It's called Polman, it uses a "database" type format, and allows for mass enable, disable, search, and display of rules.  I think the concept has a lot of merit.

Check out the example here, and check out the blog post about the tool here.  A link for the download for the tool is on the blog post.

ThePigDoktah needs some feedback

One of the many OpenSource projects that surround Snort is a new one by JJ Cummings of Sourcefire, named "thepigdoktah".

This is a tool basically for parsing and generating some useful statistics out of the performance logs that Snort generates.

Analyzing for you, Mb/s successfully analyzed, dropped packets, packets per second, size of packets.  There are a lot of metics and statistics in the perfmon preprocessor files that Snort generates, and thepigdoktah aims to expose those to the user.

Take a look at the project here.

Help for Rule Writers or What's in that Buffer?

Ever wondered what the buffers look like inside of Snort?  Want to see what the preprocessors and decoders do to your traffic?

Take a look at this new post by kpyke of our Vulnerability Research Team (VRT) here at Sourcefire.  The post includes some great new example SO rules that you can use to really understand what is going on under the hood of Snort

http://blog.talosintel.com/2011/01/in-which-kpyke-looks-behind-green.html

RPMS for RHEL5 are available from the Community

Vincent Cojot, one of our Snort Community members has taken it upon himself to maintain the list of RHEL5 compatible RPMS and SRPMS in both i386 and x86_64 formats.  These include libpcap, daq, libdnet, and of course Snort itself (2.9.0.3).  DAQ and Snort 2.9.0.x will not work on RHEL5 because of the older libpcap libraries, so you will either have to compile your own libpcap, or use the RPMs below.

So if you are on RHEL5, and you want to upgrade to the latest and greatest version of Snort without compiling, see Vincent's RPMS.

Sourcefire, however, makes no endorsement of Vincent's RPMS or their contents.  Use at your own risk.  Sourcefire will always recommend that you download and compile Snort, from the source code, available at http://www.snort.org.

Take a look:
http://vscojot.free.fr/dist/snort/snort-2.9.0.3

Hopefully this will help those of you at RHEL5.

UPDATE:  We created a page at Snort.org to help you if needed.

ClamAV Blog is back!

If you are into OpenSource Security products, and you are reading this blog, you might be interested in another product that we have from Sourcefire, ClamAV.   ClamAV is our OpenSource Anti-virus scanner that is available for free at http://www.clamav.net.

However, what you may not know is that we have a blog for ClamAV as well.  http://blog.clamav.net

So, to round it up, if it's:

Snort -- http://blog.snort.org
ClamAV -- http://blog.clamav.net


I will try and keep these three blogs updated to the fullest with the most appropriate content in each of their respective points of information.

Thanks!

VRT Rule Update Available Now and EOL of Snort 2.8.6.0

The Vulnerability Research Team of Sourcefire just released another rule pack for the following versions of Snort:

• 2.8.6.1
• 2.9.0.0
• 2.9.0.1
• 2.9.0.2
• 2.9.0.3

As announced back in October, and in accordance with our End of Life Policy, January 2nd was the end of life for VRT rules for 2.8.6.0.

We encourage all Snort Users that are using legacy versions of Snort (2.8.6.0 and below) to upgrade to the most current version (2.9.0.3).

Snort is available for download at https://www.snort.org/downloads.

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.  Be sure and stay up to date to catch the most current threats!

New Rule Pack and check your Snort.conf

In addition to alerting you to today's release of the VRT Rulepack, I thought I'd post a quick note about changes in the VRT snort.conf that have been in there for awhile that not a lot of people may have noticed. The changes were made in order to enable greater detection functionality and improve Snort's performance.

1. HTTP_PORTS (and the http_inspect preprocessor):

The HTTP_PORTS variable and the http_inspect preprocessor now include a lot more ports that the VRT has discovered for default applications to use as HTTP_PORTS. The variable reads:

portvar HTTP_PORTS [80,311,591,593,901,1220,1414,1830,2301,2381,2809,3128,3702,5250,7001,7777,7779,8000,8008,8028,8080,8088,8118,8123,8180,8181,8243,8280,8888,9090,9091,9443,9999,11371]

2. SMB / DCE-RPCv2 preprocessor

The DCERPCv2 preprocessor was updated to include a list of default shares being accessed that should not be allowed. This list is ["C$", "D$", "ADMIN$"]. The configuration now appears like this:

preprocessor dcerpc2: memcap 102400, events [co ]

preprocessor dcerpc2_server: default, policy WinXP, \

detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server 593], \

autodetect [tcp 1025:, udp 1025:, rpc-over-http-server 1025:], \

smb_max_chain 3, smb_invalid_shares ["C$", "D$", "ADMIN$"]

3. ORACLE_PORTS

The ORACLE_PORTS variable used to just include 1521. The default Oracle Port. After much research and pcap analysis it's been found that Oracle can occur many ports and there's a great need to cover those as well. The Oracle configuration line now reads like this:

portvar ORACLE_PORTS 1024:

4. SunRPC preprocessor

The SunRPC preprocessor was updated as well. It now includes more default ports for rpc decoding. The configuration now appears like this:

preprocessor rpc_decode: 111 32770 32771 32772 32773 32774 32775 32776 32777 32778 32779 no_alert_multiple_requests no_alert_large_fragments no_alert_incomplete

5. SSL Preprocessor

Finally, the SSL preprocessor has an updated configuration. It now includes more default ports for ssl processing, it has been configured to stop inspecting a flow once client and server key exchanges have taken place and all traffic is then encrypted. This helps in the efficiency of the engine by alleviating the need to inspect SSL encrypted traffic. The configuration now appears like this:

preprocessor ssl: ports { 443 465 563 636 989 992 993 994 995 7801 7702 7900 7901 7902 7903 7904 7905 7906 6907 7908 7909 7910 7911 7912 7913 7914 7915 7916 7917 7918 7919 7920 }, trustservers, noinspect_encrypted

Hopefully most of you have been paying attention to the updates in the snort.conf file shipped with the VRT's rulepacks, if you haven't, this is a good opportunity to double check your configuration files to ensure you have the latest detection functionality.

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.  Be sure and stay up to date to catch the most current threats!

Snort 2.9.0.4 is on it's way

Just starting to give Snort users a heads up, Snort 2.9.0.4 is on it's way.

This release won't change any current detection functionality, and contains:

Minor bug fixes

Snort Manual Updates (Thanks to members of the Snort Community)

But the biggest feature of Snort 2.9.0.4 is for our users of Razorback (also here), Snort 2.9.0.4 will be the first release of Snort to contain support for SaaC (Snort as a Collector) functionality.

Snort 2.9.0.4 will be released in Q1 of 2011, so stay tuned.

Classification Comments

As a reminder, comments on the contents of the new classification.config file (here) will close next Wednesday (January 12th), and we'll start looking at integration into Snort after that date.

The new classifications file is an evolution of Alienvault/Emerging Threat's work to provide a new structure of classifications to the Snort Community in order to define better priorities and descriptions for the classification names that were proposed.

We ask for a review of the descriptions and priorities, provide comments on the blog entry linked above, and we'll take a re-look at it after January 12th.

As a side note: There has been a lot of conversation on the mailing lists about the classification system as well. Even a suggestion to rewrite the classification system entirely. Which we aren't ruling out and may be the best solution.

But we'd love to hear your comments!