Will deploy this in conjunction with updated tcpflow:
http://code.google.com/p/security-onion/issues/detail?id=148

Updated code section:

    if {$proto != "6" && $proto != "17"} {

        # Modified by Doug Burks for Security Onion
        set tmpTcpdumpFilter "${tmpFilter}host $srcIP and host $dstIP and proto $proto"

    } else {

        # Modified by Doug Burks for Security Onion
        set tmpTcpdumpFilter "${tmpFilter}host $srcIP and host $dstIP and port $srcPort and port $dstPort and proto $proto"

    }

        # Modified by Doug Burks for Security Onion
        set tcpdumpFilter "(ip and $tmpTcpdumpFilter) or (vlan and $tmpTcpdumpFilter)"

Packaged:
/usr/local/lib/ruby/gems/1.9.1/gems/fpm-0.3.11/bin/fpm -s dir -t deb -n 
securityonion-pcap-agent -v 20120224 /usr/local/bin/pcap_agent.tcl

Added the following to security-onion-upgrade.sh:


sed -i 's| |=|g' $CONF
source $CONF
if [ "$VERSION" = "20120222" ]; then
        NEW="20120224"
        echo "**********************************************"   | $LOGGER
        echo "* Upgrading from $VERSION to $NEW."               | $LOGGER
        echo "**********************************************"   | $LOGGER
        DIR="/nsm/backup/$NEW"
        mkdir -p $DIR                                           | $LOGGER
        cd $DIR

    apt-get -y remove tcpflow               >> $LOG

        echo "* Installing new pcap_agent.tcl"                  | $LOGGER
        FILE=securityonion-pcap-agent_"$NEW"_i386.deb
        wget -q http://sourceforge.net/projects/security-onion/files/$NEW/$FILE -O $FILE | $LOGGER
        dpkg -i $FILE                                           | $LOGGER

        echo "* Installing new tcpflow"                     | $LOGGER
        FILE=securityonion-tcpflow_"$NEW"-1_i386.deb
        wget -q http://sourceforge.net/projects/security-onion/files/$NEW/$FILE -O $FILE | $LOGGER
        dpkg -i $FILE                                           | $LOGGER

    nsm_sensor_ps-restart --only-pcap-agent

        sed -i "s|VERSION=$VERSION|VERSION=$NEW|g" $CONF        | $LOGGER
        echo "* Upgrade to $NEW complete."                      | $LOGGER
        echo 
fi

Tested by:
Doug Burks
Liam Randall
Scott Runnels

Doug with the release of this code we might want to add a little description 
for testing out the issue that we are trying to address.  Maybe drop a little 
description regarding monitoring complex interfaces- ie, interfaces with vlans, 
ip, and ethernet.  

Yeah, I was planning on including the following in the blog post.  What do you 
think?

PROBLEM #1
Suppose you're monitoring traffic that has VLAN tags (in both directions).  By 
default, when you right-click the Alert ID and request the transcript/pcap, you 
would get nothing.  In order to get transcripts/pcaps to work correctly in 
Sguil, you would have to manually set VLAN to "1" in pcap_agent.conf.

PROBLEM #2
Suppose you're monitoring traffic that has VLAN tags in one direction but not 
the other.  When you right-click the Alert ID and request the transcript/pcap, 
you would only get the non-VLAN side of the flow.  If you set VLAN to "1" in 
pcap_agent.conf, you would then receive just the VLAN side of the flow.

SOLUTION
The updated pcap_agent.tcl and tcpflow allow Sguil to transparently support all 
cases of traffic with VLAN tags, without VLAN tags, and with mixed VLAN tags.  
When you right-click the Alert ID and request the transcript/pcap, you should 
now get the entire flow.

NOTE
If you had manually set VLAN to "1" in pcap_agent.conf, then you should set it 
back to the default of 0 and restart pcap_agent:
sudo nsm_sensor_ps-restart --only-pcap-agent

CAVEAT
httpry doesn't support VLAN tags, so if the above cases apply to you, you still 
won't see HTTP events in Sguil where VLAN tags are involved.  However, we'll 
soon be removing httpry in favor of Bro's HTTP logging, which does handle VLAN 
tags properly.

Perfect.  The only addition might be to refer people to /nsm/bro/log:

"
If you're already running a recent version of SO then Bro is already configured 
to capture and generate your http logs by default- and it works seemlessly with 
IP, Vlan, QinQ, MPLS traffic and pretty much everything else we've thrown at 
it.  There are lots of ways to process and query the bro logs, however to get 
you started you could do something like this:

cd /nsm/bro/logs
find . -name 'notice*.*' -print0 | xargs -0 zgrep cnn.com
"

cd /nsm/bro/logs
find . -name 'notice*.*' -print0 | xargs -0 zgrep cnn.com

notice?  Did you mean http.log?

What are the advantages of using find/xargs over a simple zgrep?
zgrep "cnn.com" /nsm/bro/logs/*/http*

Might be simpler syntax for newbies.

Yes, on the http instead of notice; errant cut and paste.

On the preference for searching there are a ton of different ways to get this 
done; I like using find because it let's me drill right down to a specific date 
range, etc.

Why don't we just provide a couple of examples for people to work off of:

find . -newermt '2012-02-26' -a -not -newermt '2012-02-28 22:00' -name 
'notice*.*' -print0 | xargs -0 zgrep Server_Found

Although, we may want to confirm that the .bro script that generates this code 
is included by default or change it out to a http query.

Published:
http://securityonion.blogspot.com/2012/02/security-onion-20120224-now-available.
html