Zeek has a dependency on events for its functionality.
In fact, its script language is very event driven.
I like to think of any event‑driven language as a bunch of
if/then statements for simplification.
Especially in Zeek's case, that's an oversimplified statement,
but it still works.
Let's dive into why.
As Zeek processes the network traffic,
it's creating events based on the protocol analyzers and
the scripts that are running those.
So Zeek logs the events,
and then through the scripts that we're building or customizing,
actions to take on those events.
We can look at the Zeek built‑in functions,
the .bif files, to see the events that have been documented by the developers.
Seeing these and understanding how they're detected can help with the
overall understanding of the Zeek workflow and architecture.
Taking a look at this example for RDP session events,
there is a lot defined here.
If you check out this .bif file, you'll be able to see all of them,
but this is just a cross‑section of one of the events.
We have individual events generated for requests and
responses and flags set by the servers.
Each of these .bif files shows us all of the events generated for
each protocol or analyzer or situation in general.
We can also add our own if we wanted to.
So, these scripts or definitions show us how the events are defined.
Once Zeek gets them, like we've been seeing all along,
it's up to us to tell it what to do about them or with them.
The two main components within Zeek that help it use and track
events are the event handlers and the event queues.
The event queue is where Zeek places the events that it sees,
in order of first seen to last seen.
The event handlers themselves then process the events as they come in.
Zeek describes this as first come, first serve.
In our example scripts that we're working with,
the event handlers are each of the events and actions that we define in
the third section of the scripts with the events there.
Let's hop into the lab really quick and take a look at
the event handlers for some scripts,
and then dive into the script reference to see what we can do with them.
If you're ready, let's hop right in.
Alright, and here we are in our Zeek instance in the lab again.
The first thing that we're going to show you is the .bif file for those RDP
events that we were just talking about in the slides.
And I just want to go through some of them and show
how the events are actually defined.
And with this pulled up, as you can see,
each event is separated by the different spaces in here,
and we have the comments that actually go in and explain
what each of them does or what it's for.
So, for example,
one of these right here is when the RDPEUDP connections
are actually established on both sides,
and Zeek tracks this based on the SYN flags.
Another one is an event if there's an RDP
negotiation failure like this one here.
We have two different events that are generated,
and one of them includes the flag count,
one of them does not.
And as you can see, it's just tracking the event itself,
the name of the event,
and then the different parameters or variables that we
have defined for the events themselves.
So, using these .bif files,
it's really cool because we can see how Zeek actually processes and
understands the traffic and creates events out of that.
And with this information,
we can see where the event may have been logged or what some of
the other options are for it specifically.
Alright,
the next doc that I want to talk about is our detecting traceroute script
that we wanted to go over so we can see the event handlers.
So I'm just going to more that one,
and like we went over it previously in the slides,
we have the first two sections of the script here,
but when we're looking at the event handlers,
we want to look at the third section, so right where the events start.
And this first event is the event handler for when Zeek initializes.
This is what's going to happen for this script whenever we
deploy Zeek with this new configuration,
or whenever we start up Zeek.
When it initializes,
it's going to create a log stream based on all of this information here,
and we're going to go through and identify a lot of
this stuff later on in this module.
But we have the log stream created,
we have options for it to actually write events to logs,
we have local definitions here for some of the fields as well.
Now, if we scroll down a little bit,
we have those two other events that I spoke of earlier.
We have the low TTL packets that are being detected with the signature,
and then an event for the icmp_time_exceeded.
So, if you look at these ones,
they're a little bit more simplified than the initialization event,
and they're fairly simple statements.
We have a signature match right here,
so if the signature for traceroute detected is true or Zeek sees it,
then that event is going to get raised.
And then the other one is,
if there have been too many time‑exceeded events there,
that one's going to get raised as well.
And we can look at that signature right within the folder.
As you can see, it's that detect‑low‑ttl.sig,
and it's just those two signatures for IPv4 and IPv6.
And we're looking at just the header field.
Back into the main.zeek script for the traceroute detection,
you can think of these event handlers as just those if/then statements,
right?
So, Zeek is going to process these as they come in.
So whenever the scripts run, if it sees any of these matches,
it's going to do whatever the actions are defined here,
and that's going to be regardless of the order that
they're in or anything like that.
If we wanted to prioritize it,
we can use the priority commands to help prioritize each event.
Alright, now let's hop into the script reference.
Now we're going to be diving into this in a lot more
detail later on in the module,
but I wanted to give a quick overview of what this is and how we can use it.
So here in the Script Reference, we have all of these different options,
and it pretty much goes through step by step and details what each of them does,
how they can be used in the scripts, and gives us some examples for them as well.
We also have the script index here that I spoke of earlier
that actually goes in and shows us every single script that
Zeek has documented in here, what it does,
what you can redefine with it,
and these redefinitions are going to be extremely crucial when
we're optimizing and creating our own scripts.
Going back to the Script Reference, we have these different types,
the operators, types, attributes, declaration statements,
directives, and if we just hop into the Operators section,
you can see that some of this might be familiar.
It defines the operators that Zeek supports for its scripting language.
So, we have things like the equality and greater‑than and less‑than,
logical and/ors or nots, stuff like that.
We could do arithmetic as well.
We'll dive a lot deeper into this and the various
options later on in the module,
but identifying this script reference and all of the different
information that's available within it so you can better understand
the scripts that Zeek has and how it uses them is crucial to fully
understanding how the system works.