Let's move our conversation over to the default scripts
that Zeek ships with and employs.
We have a few to cover here before we move into the
actual optimization and tuning of Zeek.
Understanding the various scripts that we have to work with goes
a long way in knowing how we can modify them to make the tool
more efficient and effective for us.
We have two directories that we're concerned about when
talking about the default scripts.
One is the base directory, and the other is the policy one.
By default,
Zeek ships with the base directory loaded along with some policy scripts.
We'll look into these in the coming demos.
The policy ones are situational, like I mentioned in the previous clip.
The base ones contain a lot that help with Zeek's functionality out of
the box and all of the definitions that it uses.
And we can modify which ones of these are loaded as well.
The init‑bare script is something that you likely won't touch,
but it's great to dive into if you want to see some of the inner
workings of how Zeek's functionality is created.
This one is loaded by default when Zeek initializes and when the
instance is invoked with the Zeek ‑b command.
This script has so many defined types and variables and vectors declared,
along with so much more.
I mean,
this thing even defines connection record types and many of the other
objects that we went over in the previous module.
We'll dive a little bit further into this in the next clip.
The init‑default script is another one of the base ones
loaded by default and contains all of the various
frameworks and utilities that Zeek loads.
It has the scripts for all of the various protocol and
file analysis functionality as well.
Looking at it here, as you can see,
it enables a lot of the main features and
functionality of Zeek by loading this one.
We can circumvent this by using the ‑b command when invoking
Zeek and only running in the bare bones mode.
Finally, the local.zeek script.
This is the one that we've been modifying as we've been adding
and removing signatures and tuning scripts.
This one is where we customize our system and define
exactly which scripts we want to load,
and I've been mentioning it a lot throughout this course.
The key here is that we create our own scripts and then
load them using the local.zeek script.
Of course,
we should make sure we use commenting when we can in order to
ensure we're documenting what we're loading and why.
This is where most of our customization magic happens though.
Besides all of those scripts that come with Zeek and are loaded by default,
we should consider all of the other things in there that are loaded by default.
We have the packet/protocol processing scripts,
utilities, various BIFs that we need for the event definitions,
and so much more.
Since Zeek is an event‑driven network security
monitor that performs traffic analysis,
much of what we find in that base directory is crucial
to getting value out of the box.
Let's use the next clip to hop into the lab and explore
many of these in much more detail.