Re: FW: Fwd: Re: barnyard2-1.10 major problem

[beenph <beenph () gmail com>]

On Thu, Oct 25, 2012 at 2:04 PM, Safwat Fahmy
<safwat.fahmy () safemedia com> wrote:
> Maybe you did not see my previous email below. I really appreciate your
> prompt response. Her is my question following up on your response to  Mr.
> Hughes
>
> Can you please explain to me how the schema cause this issue if BY2 delivers
> 2 separate events not one event with two assembled packet?
>
> This might help me understand better to find a work around
>
> Cheers,

As far as i know and mabey SF people could jump in on this point  but,
In the unified2 format its not possible to know if multiple packets
generated by an event are
part of the same packet (reassembled stream) or if they are different
non contiguous packets
part of a stream that fire from an alert.
 So reassembling them into a" super packet" in post processing could
be something tidious/risky to do i think.

In the unified2 file used as example in this context if you use
u2bloat that comes with snort that extract packets from
unified2 file it will generate a pcap file with two packets.

binf@SINGULAR:~/BY-TEST/test/log$ u2boat ./snort.log.1350901409  ofile
Defaulting to pcap output.
binf@SINGULAR:~/BY-TEST/test/log$ /usr/sbin/tcpdump -r ./ofile  -n
reading from file ./ofile, link-type EN10MB (Ethernet)
06:54:38.178786 IP 172.25.236.179.4926 > 207.171.163.31.80: Flags
[P.], seq 1095327932:1095328327, ack 2867172496, win 6432, length 395
06:54:38.300156 IP 172.25.236.179.4926 > 207.171.163.31.80: Flags
[P.], seq 395:722, ack 463, win 7504, length 327

In this context ,  we have in
the unified2 file 1 event and two packet generated by the following event.

Snort probably triggered from the reassembled packet and outputed two packet.

I guess having the rule would allow to understand what are the packets
in relation to a possible complete session.

One of the particularities of the current schema is that there is not
relation regarding
the matching snort event_id, thus once a event is logged it will
obtain its event_id from a incrementing sequence.



Here is some example on how you could "correlate" them into a view:

SELECT a.cid,a.signature,a.timestamp,b.ip_src,b.ip_dst FROM event as
a,iphdr as b WHERE a.sid=35 AND  (a.cid=b.cid AND a.sid=b.sid) GROUP
BY a.timestamp,a.sid,a.cid,a.signature,b.ip_src,b.ip_dst;

OR

SELECT a.cid,a.signature,a.timestamp,b.ip_src,b.ip_dst FROM event as
a,iphdr as b WHERE timestamp IN (SELECT timestamp FROM event WHERE
sid=35  GROUP BY timestamp) AND (a.cid=b.cid AND a.sid=b.sid);

Also note that a.sid is the defined sensor id (sid) and you would need
to adjust that for your context.

So its not impossible to do correlation because each event logged will
be logged with the original event time but its not necessarly optimal
using the current schema.

I hope this clarified some stuff
-elz















> Safwat
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Safwat Fahmy [mailto:safwat.fahmy () safemedia com]
> Sent: Thursday, October 25, 2012 1:05 PM
> To: 'beenph'
> Cc: 'barnyard2-users () googlegroups com'; 'snort-users'; lhughes
> (lhughes () safemedia com)
> Subject: RE: [Snort-users] Fwd: Re: barnyard2-1.10 major problem
> Importance: High
>
> Can you please explain to me how the schema cause this issue if BY2 delivers
> 2 separate events not one event with two assembled packet?
>
> This might help me understand better to find a work around
>
> Safwat
>
>
>
>
>
>
>
> -----Original Message-----
> From: beenph [mailto:beenph () gmail com]
> Sent: Thursday, October 25, 2012 12:46 PM
> To: Lawrence R. Hughes, Sr.
> Cc: barnyard2-users () googlegroups com; snort-users
> Subject: Re: [Snort-users] Fwd: Re: barnyard2-1.10 major problem
>
> u2spewfoo show it as  1 event  two packet.
>
> Look
> >        sensor id: 0    event id: 1     event second: 1350903278
> >        packet second: 1350903278       packet microsecond: 178786
> >        linktype: 1     packet_length: 449
>
> >        sensor id: 0    event id: 1     event second: 1350903278
> >        packet second: 1350903278       packet microsecond: 300156
> >        linktype: 1     packet_length: 381
>
>
> > You have it all wrong beenph!
> > Just ask the guys at SF the above should be treated as a single event
> > with 2 packets.
>
> Its how its treated.
>
> 1 event 2 packet
>
> But with the current database schema its logged as two full event.
>
> The problem you highlight is not the spooler. It is the  Default database
> schema.
> If you use that schema in your commercial activities you have to
> deal/understand with its restrictions.
>
> The new schema will handle this without an issue. In the meantime you can
> probably correlate this writing a smart query.
>
> Cheers,
> -elz
>
> ----------------------------------------------------------------------------
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics Download AppDynamics Lite for
> free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> 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!

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
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!