There are some tuning scripts that we can just use
to help us optimize the system,
although they don't provide too much granular control of the environment.
I really briefly mentioned them in the previous demo,
but we'll check out some of these and explain what they are,
as well as highlight some best practices to use when
working with Zeek and trying to optimize it.
So, the first one is definitely going to be one that I
personally like using since I'm a fan of JSON logs.
It's appropriately named too.
We saw this in the logging framework module,
but what this one does is it changes all of the logging formatting
that uses the logging framework into the JSON format.
This affects the system globally and only if we're using the
defaults instead of running in bare mode.
It's super helpful in having all of your logs in the format that you want.
All it is is this redefinition of the ASCII writer.
Then we have the track‑all‑assets script that does just what it sounds like and
loads a few scripts by default to help with its processes.
This one is looking for our known‑hosts, services, and certs.
We also have a default folder within the policy/tuning directory that
we should consider as part of the loads for tuning,
and we highlighted those in the previous demo.
Three scripts are here,
and the first one is going to be about extracted file limits.
So this first one does just what it sounds like.
It defines the limits for any extracted files that Zeek processes.
The default for this is 100 MB.
So if you need to adjust these numbers,
you can do so here and load this script if you want.
The second one of these in the default tuning folder
is the packet‑fragments script.
This one allows us to customize the capture filters for the
fragmented packets and the timeout for them.
The first function of defining the fragmentation
filters isn't really used any longer,
but it's still there in case you have a use case that requires it.
By default though, the packet filter is wide open.
Finally, we have the warning script.
This one prints messages to the stdout for good
settings that can be used in many cases.
For example, this one is telling us that we don't have any local_nets defined,
which is very important when we're talking about a
network security monitoring tool.
Those tuning scripts are mostly loaded via the local.zeek script by default.
And if we wanted to create additional tuning scripts and load them, we can.
There are other ways to optimize Zeek though in order to gain the
required functionality for your organization.
For example,
we might want to tie the Zeek processes to certain CPUs if we
have multiple tools built on the same system,
like Security Onion, for example.
This will allow Zeek to have a consistent performance within the system.
We can also customize or forward the logs,
which we mentioned a lot earlier in the course.
If we're cyber operations professionals,
we probably don't want to go fishing for logs within the Zeek system itself.
We'd want to ship them to a SIEM or another tool.
We can do this through additional tools that can help parse the logs
before getting to the centralized Syslog server.
Tools like syslog‑ng can help with this,
as well as the Splunk Universal Forwarder and other ones
built for tools like the ELK Stack.
Adding additional information to Zeek in order to use the system
effectively is an extremely large use case.
This extra information can be through integrations
like full packet capture tools, ticketing systems,
and more.
It can also be through things like threat intelligence downloads and tying
specific context information to the alerts that we receive.
These integrations are outside the scope of this course,
but are addressed in another course in the same skill path at Pluralsight.
One thing to keep in mind as we're talking about tuning and
optimizing Zeek is that you have to know what you want to know
in order to be able to tune it.
It's useful to optimize the system,
and it comes pretty well built out of the box.
Again,
commenting and uncommenting the different scripts that are
loaded is a great way to modify the system,
and customize the system, and also, creating those tuning scripts,
like changing the JSON format or the file ingestion size.
Those are really great in helping to customize and tune
the system to your specific environment.