[Zeek] Zeek script to look for first few packets

[Jim Mellander]

If you're working on a protocol currently unknown to zeek, you could try
your hand at writing a protocol analyzer plugin.  A recent thread on that
subject:
http://mailman.icsi.berkeley.edu/pipermail/zeek-dev/2019-March/013196.html

As an enhancement to zeek, it might be nice to trigger an event if the
protocol analyzers were unable to identify the connection, with some
representation of the traffic seen to allow script level analysis.  Haven't
spent much time thinking about the syntax or efficiency of such an event,
though, although it might be an interesting topic for conversation.



On Fri, May 3, 2019 at 10:48 AM Aashish Sharma <asharma at lbl.gov> wrote:

> Manju,
>
> zeek conceptually works better at connection and protocol events than at
> packet levels. Infact
> thats one of the strengths of it that it does all low level tcp and
> protocol
> understandings for you and hands you events which are at more easier
> levels to
> work with.
>
> While you can work on packet, it is generally not recommended. More so if
> you
> desire to operate at packet levels to save processing time, on the
> contrary you
> are going on an non-optimal path.
>
> You should consider event based approach. Your message doesn't quite
> explain
> what your specifics are that helps you identify when you are done but here
> are
> couple of examples which might help understand other approaches or way to
> think:
>
> Problem: I'd like to only process if all three conditions are T
>
> - IP is in local_nets
> - dst port is acceptable port list &&
> - response IP is not in list of acceptable hosts
>
> event new_connection(c: connection)
> {
>
>         local orig = c$id$orig_h ;
>         local resp = c$id$resp_h ;
>         local dport = c$id$resp_p ;
>
>         if (orig !in Site::local_nets)
>                 return ;
>
>         if (dport !in ok_ports)
>                 return ;
>
>         if (resp !in ok_hosts )
>                 return ;
>
>         # do your processing
>
> }
>
> Similarly:  lets say you want to only operate on Apache Server stuff:
>
>
> event http_header(c: connection, is_orig: bool, name: string, value:
> string) &priority=5
>         {
>                 if (name != "SERVER")
>                         return ;
>
>                 if (/Apache/ in value)
>                 {
>                   # do your processing
>                 }
>
>         }
>
>         or alternatively:
>
>
>         if ( name == "SERVER" && /Apache/ in value)
>                 # do processing
>
> The way is you eliminate all the un-interesting traffic you don't care
> about -
> this saves more processing than to go per packet level heuristics.
>
> You should probably look at connection events:
>
>
> https://docs.zeek.org/en/stable/scripts/base/bif/plugins/Bro_TCP.events.bif.bro.html
>
> and definitely try avoiding working on packet events
>
> Hope this helps,
>
> Aashish
>
> On Fri, May 03, 2019 at 10:08:09PM +0530, Manju Lalwani wrote:
> > how can I make Zeek look for the first ten packets only  in a tcp
> session ?
> > The first ten packets are enough to fingerprint the traffic I am trying
> to
> > identify and so would like to ensure my script  looks at only the first
> 10
> > packets to save processing time.
> >
> > Also the communication can be identified based on 7 packets immediately
> > following the tcp handshake and using a custom service not categorised by
> > zeek.. tcp_packet event has been the closest match for my script . Is
> there
> > any Zeek event that can be a better match for this communication ?
> >
> > Thanks in advance,
> > Manju
>
> > _______________________________________________
> > Zeek mailing list
> > zeek at zeek.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/zeek
>
> _______________________________________________
> Zeek mailing list
> zeek at zeek.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/zeek
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/zeek/attachments/20190503/7e11a9be/attachment.html