Re: Logging Packets with Snort

[Jeremy Hoel <jthoel () gmail com>]

Also

Our logs, when we make a cx query, look like this:

Oct 25 20:04:29 sensor OpenfpcQ[20930]: sensor COMMS: Accepted new
connection from 10.10.105.224
Oct 25 20:04:29 sensor OpenfpcQ[20930]: sensor COMMS: 10.10.105.224:
RID: 109 getting summary data
Oct 25 20:04:29 sensor OpenfpcQ[20930]: sensor COMMS: 10.10.105.224:
RID: 109 Stime=0 Etime=0
Oct 25 20:04:39 sensor OpenfpcQ[20930]: sensor COMMS: 10.10.105.224:
RID: 109 Table Sent. Closing connection

when we make a status query, they look like:
Oct 25 20:20:49 sensor OpenfpcQ[20930]: sensor COMMS: Accepted new
connection from 10.10.52.59
Oct 25 20:20:50 sensor OpenfpcQ[20930]: sensor COMMS: 10.10.52.59
Recieved Status Request
Oct 25 20:20:53 sensor OpenfpcQ[20930]: sensor DEBUG: Status msg sent
to client is 
1||NODE||iiaglast001||1381946566||1381944416||76||65365484||4||139368||5413088||0||4||139368||0.40||0.37||0.39||0||0||0.7

it doesn't log the original request going to the sensor.

Glad you got it working..

On Fri, Oct 25, 2013 at 8:31 PM, Johnny Venter <Johnny.Venter () zoho com> wrote:
> Ok, I'll try that tonight and report--thank you for taking the time to help.  Hopefully, I'll report good news.
>
>
> On Oct 25, 2013, at 4:30 PM, Jeremy Hoel <jthoel () gmail com> wrote:
>
> > I don't use the snorby plugin for that.  We have 50 sensors and it
> > never gets to the all of them before timing out.  We wrote a script to
> > wrap around openfpc-client and call that script and it fills things in
> > quickly.
> >
> > you should be able to watch tcpdump from the snorby box to the sensor
> > and see the request made (it's over the clear) and see the command it
> > sends to see if it's doing it right.
> >
> >
> >
> > On Fri, Oct 25, 2013 at 8:27 PM, Johnny Venter <Johnny.Venter () zoho com> wrote:
> > > Jeremy, thanks.  I was able to get the command to work by specifying the bpf
> > > filter inline:
> > >
> > > Logline created from session IDs: ofpc-v1-bpf type:search bpf: host
> > > xx.xx.xx.xx stime:1382713697 etime:1382729022 timestamp:
> > > DEBUG: Connected to localhost
> > > DEBUG: Sent Request
> > > #####################################
> > > Date    : Fri Oct 25 16:14:05 2013
> > > Filename: /tmp/test.pcap.pcap
> > > Size    : 11M
> > > MD5     : fd597ee282327cb7635bce5085489ebf
> > >
> > > I think the issue might be that when I query from Snorby, it's not passing
> > > the start time and end time when I make the request.  I checked the syslog
> > > on the Snort sensor and it only specifies the host bpf filter (unless the
> > > syslog is not verbose and the start time and end time) is hidden.  Can any
> > > of you try the query with Snorby and check your syslog to see if the time is
> > > recorded in the syslog entry?
> > >
> > > Thanks.
> > >
> > >
> > > On Oct 25, 2013, at 4:22 PM, Jeremy Hoel <jthoel () gmail com> wrote:
> > >
> > > FYI - there is no replication for OpenFPC.  It's a client/server/proxy
> > > type setup.  Ie: Snorby normally talks to the local OpenFPC server
> > > (which would normally be the proxy/master) and then it asks each
> > > sensor/client in turn to give it packets related to the request.
> > > Problem is, things timeout before it gets through a long list.  that's
> > > why we do it to the sensor directly outside snorby.
> > >
> > >
> > >
> > > On Fri, Oct 25, 2013 at 8:13 PM, Johnny Venter <Johnny.Venter () zoho com>
> > > wrote:
> > >
> > > Thanks, Ayodele for your help.  I ran this on MySQL on my Snort sensor:
> > > SELECT @@global.time_zone, @@session.time_zone;
> > >
> > > Results:
> > > +--------------------+---------------------+
> > > | @@global.time_zone | @@session.time_zone |
> > > +--------------------+---------------------+
> > > | SYSTEM             | SYSTEM              |
> > > +--------------------+---------------------+
> > >
> > > On the snort sensor server (Ubuntu), the time is: Fri Oct 25 16:10:29 EDT
> > > 2013
> > >
> > > On the Snorby server (Ubuntu), the time is the same.
> > >
> > > I'm still confused on the DB replication you mention.  Here is my setup.
> > > Snort outputs to unified2. Barnyard2 takes that as input and stores it in my
> > > MySQL DB.  Snorby does not have a DB, it connects to the Snort DB.
> > >
> > > Thanks.
> > >
> > > On Oct 25, 2013, at 4:03 PM, Ayodele Okeowo <aymacro () gmail com> wrote:
> > >
> > > Start from your short sensor by checking the timestamp on the mysql database
> > > if it's current. If database timestamp is correct, then try a manual mysql
> > > replication between both snort database and snorby.
> > >
> > > If timestamp is not current on the snort mysql db, then check your barnyard2
> > > and make sure it's passing data to the snort db.
> > >
> > > From there troubleshooting should be more simpler.
> > >
> > > On Oct 25, 2013 3:57 PM, "Johnny Venter" <Johnny.Venter () zoho com> wrote:
> > >
> > >
> > > I did not enable sessions with OpenFPC so there's no DB for
> > > packets/sessions.  Can you elaborate on the DB replication?
> > >
> > > Also, I get the following messages in syslog:
> > >
> > > Oct 25 14:29:32 snort_s daemonlogger[16404]: stat failed for
> > > "/var/tmp/openfpc/pcap/openfpc-snort_s.pcap.1381018707": Value too large for
> > > defined data type
> > > Oct 25 14:29:32 snort_s daemonlogger[16404]: stat failed for
> > > "/var/tmp/openfpc/pcap/openfpc-snort_s.pcap.1381700285": Value too large for
> > > defined data type
> > > Oct 25 14:29:32 snort_s daemonlogger[16404]: stat failed for
> > > "/var/tmp/openfpc/pcap/openfpc-snort_s.pcap.1381711036": Value too large for
> > > defined data type
> > > Oct 25 14:29:32 snort_s daemonlogger[16404]: stat failed for
> > > "/var/tmp/openfpc/pcap/openfpc-snort_s.pcap.1381517654": Value too large for
> > > defined data type
> > > Oct 25 14:29:32 snort_s daemonlogger[16404]: stat failed for
> > > "/var/tmp/openfpc/pcap/openfpc-snort_s.pcap.1382715970": Value too large for
> > > defined data type
> > >
> > > Oct 25 14:29:32 snort_s daemonlogger[16404]: [!] Ringbuffer: deleting
> > > /var/tmp/openfpc/pcap/openfpc-snort_s.pcap.1382725637
> > > Oct 25 14:29:32 snort_s daemonlogger[16404]: Logging packets to
> > > /var/tmp/openfpc/pcap/openfpc-snort_s.pcap.1382725772
> > >
> > > Thanks.
> > >
> > > On Oct 25, 2013, at 3:50 PM, Ayodele Okeowo <aymacro () gmail com> wrote:
> > >
> > > This sounds like a database replication issue from the way your snorby
> > > server gets packets from the snort sensor mysql database.
> > >
> > > On Oct 25, 2013 3:05 PM, "Johnny Venter" <Johnny.Venter () zoho com> wrote:
> > >
> > >
> > > Hi Jeremy, thanks for the quick response and yes, I need more help :)
> > >
> > > When I issue:
> > >
> > > openfpc-client -a status
> > >
> > > The oldest packet is: 1380905610 (Fri Oct  4 12:53:30 2013)
> > >
> > > The packet request in my previous email was requested today.
> > >
> > > Here's some more information on my setup:  I have a snort sensor with
> > > Barnyard2, MySQL and with openfpc installed and capturing packets--I think
> > > they reference this as running in "slave" mode.  I have another server that
> > > runs Snorby and connects to the MySQL database on the snort sensor.  I
> > > request packets from the Snorby server which in turn connects to the snort
> > > sensor for packet requests.
> > >
> > > Any other ideas was to why I'm getting 24 byte packets?
> > > While I do like the full packet capture so I can detect the start of an
> > > intrusion, can I query the unified2 file similar to what Sourcefire does?
> > >
> > > Thanks.
> > >
> > >
> > > On Oct 25, 2013, at 2:52 PM, Jeremy Hoel <jthoel () gmail com> wrote:
> > >
> > > The interface you are talking about and using is Snorby; it's a gui for
> > > looking at snort alerts.  Snort itelf does not capture full packets, just
> > > the bits that cause the event (like you see in SourceFire).  Snorby has a
> > > plug-n for the a tool called OpenFPC (which is what you see in your logs)
> > > that connects back to an OpenFPC client/server to get the pcap data, but you
> > > have to run openfpc on the sensor and set it up.
> > >
> > > We've found that the 'extract packets' part doesn't work great due to the
> > > way that OpenFPC does client/server comms over many devices.  But, we do run
> > > OpenFPC, do the full packet captures and pull the packets ourselves with a
> > > script to the sensor that we want the data from.
> > >
> > > The errors you are showing could be because the pcap data isn't there
> > > anymore (how far back do your openfpc captures go?)
> > >
> > > I hope that helps clarify some bits and if you need more help, let me
> > > know.
> > >
> > >
> > >
> > >
> > > On Fri, Oct 25, 2013 at 6:45 PM, Johnny Venter <Johnny.Venter () zoho com>
> > > wrote:
> > >
> > >
> > > Having some performance issues with my Snort sensor that has OpenFPC
> > > installed.
> > >
> > > Not sure if this is the right place for this question, but here goes:
> > >
> > > I have a sensor that monitors the Internet traffic.  The interface is
> > > 1GB.  When I try to download packet captures (from Snorby) most of the time
> > > it takes a while and then downloads a packet that is 24 bytes.  When I open
> > > this pcap in Wireshark or tcpdump, it only displays one line: link-type
> > > EN10MB (Ethernet)
> > >
> > > When I click on the "Packet Capture Options" in Snorby:
> > >
> > > <Screen Shot 2013-10-25 at 2.37.55 PM.png>
> > >
> > > I watch the syslog from my snort sensor and here is the output:
> > >
> > > Oct 25 14:34:15 snort_s OpenfpcQ[1035]: snort_s COMMS: Accepted new
> > > connection from 127.0.0.1
> > > Oct 25 14:34:15 snort_s OpenfpcQ[1035]: snort_s DECODE: User netp-user
> > > assigned RID: 0 for action fetch. Comment: 0 Filetype : PCAP
> > > Oct 25 14:34:15 snort_s OpenfpcQ[1035]: snort_s COMMS: 127.0.0.1: RID:
> > > 15 Fetch Request OK -> WAIT!
> > > Oct 25 14:34:15 snort_s OpenfpcQ[1035]: snort_s NODE: Request: 15 User:
> > > netp-user Action: fetch BPF: host 192.168.216.175 and host 192.168.216.77
> > > Oct 25 14:34:42 snort_s OpenfpcQ[1035]: snort_s NODE: Request: 15 User:
> > > netp-user Result: 1382726055-15.pcap, 24, ab487d36057d446b6a8b72091da72f23
> > > Oct 25 14:34:42 snort_s OpenfpcQ[1035]: snort_s COMMS: 15 127.0.0.1
> > > Sending File:/tmp/1382726055-15.pcap MD5: ab487d36057d446b6a8b72091da72f23
> > > Oct 25 14:34:42 snort_s OpenfpcQ[1035]: snort_s COMMS: Uploaded 1 x 1KB
> > > chunks
> > >
> > > So it's really a hit or miss with my packet capture.  Does anyone have
> > > any idea why this happens?
> > >
> > > Also, in the commercial version of Snort (Sourcefire), it *seems* to
> > > capture just the packet the generated the alert--which saves space and
> > > resources.  Can this be replicated with snort's unified2 output mode (which
> > > I currently use)? If so, how can I query the binary file for the specific
> > > intrusion event?
> > >
> > > Thanks.
> > >
> > >
> > >
> > > ------------------------------------------------------------------------------
> > > October Webinars: Code for Performance
> > > Free Intel webinars can help you accelerate application performance.
> > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> > > from
> > > the latest Intel processors and coprocessors. See abstracts and register
> > >
> > >
> > >
> > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> > > _______________________________________________
> > > Snort-users mailing list
> > > Snort-users () lists sourceforge net
> > > Go to this URL to change user options or unsubscribe:
> > > https://lists.sourceforge.net/lists/listinfo/snort-users
> > > Snort-users list archive:
> > > http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
> > >
> > > Please visit http://blog.snort.org to stay current on all the latest
> > > Snort news!
> > >
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------------------------
> > > October Webinars: Code for Performance
> > > Free Intel webinars can help you accelerate application performance.
> > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> > > from
> > > the latest Intel processors and coprocessors. See abstracts and register
> > >
> > >
> > >
> > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> > > _______________________________________________
> > > Snort-users mailing list
> > > Snort-users () lists sourceforge net
> > > Go to this URL to change user options or unsubscribe:
> > > https://lists.sourceforge.net/lists/listinfo/snort-users
> > > Snort-users list archive:
> > > http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
> > >
> > > Please visit http://blog.snort.org to stay current on all the latest
> > > Snort news!
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------------------------
> > > October Webinars: Code for Performance
> > > Free Intel webinars can help you accelerate application performance.
> > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> > > from
> > > the latest Intel processors and coprocessors. See abstracts and register >
> > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> > > _______________________________________________
> > > Snort-users mailing list
> > > Snort-users () lists sourceforge net
> > > Go to this URL to change user options or unsubscribe:
> > > https://lists.sourceforge.net/lists/listinfo/snort-users
> > > Snort-users list archive:
> > > http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
> > >
> > > Please visit http://blog.snort.org to stay current on all the latest Snort
> > > news!

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!