Before we close out this module and head on over to the next one to build our
own detection script, we'll hop into the lab one more time.
This time, we'll make some modifications to the Zeek system.
We'll turn on and off some of the scripts that are loaded.
We'll make sure that the custom ones that we've been using in this
course have loaded as well, and we'll make sure our tuning scripts
are defined how we want them to be.
Let's hop in. So here we are back in the lab, and the first thing
that I want to do before we go ahead and start commenting and
uncommenting things in our local.zeek script,
I want to go ahead and look at some of those tuning
scripts in the tuning folder.
Let's make sure that the track‑all‑assets one is configured how we want it to.
Yeah,
there's nothing really to change here unless we wanted
to do another redefinition here,
which would be okay if we had specific use cases for this. Hopping into that
default directory, let's take a look at the extracted_file_limits.zeek and go
ahead and modify that to 200, okay? So let's go ahead and do nano for that one
to define that default limit right there.
So let's go ahead and do that one, and that should be about 2 GB right there,
which is an extremely large file size, so let's chop it down to 200 MB instead.
Save that, and now it's time to go ahead and hop into the local.zeek script.
So let's go ahead and do that.
Now I'm not going to change any of those default scripts.
We're not going to change the default tuning scripts that are loaded.
But what we will do is we'll turn on the TCP scan script.
We'll turn on the detect traceroute script,
which is going to be a good one to test out with.
We'll leave the vulnerability ones alone, and then we'll jump all the way
down to our scripts, and we'll turn on our signatures again.
We'll make sure we load that json‑logs policy tuning scripts, so all of our
logs are going to come through in JSON now. And if you noticed further up
above where the tuning scripts were loaded,
it was just that tuning/defaults folder that was loaded,
not the tuning/ folder that was loaded, so that JSON
script was not loaded by default.
And then for fun too,
if we wanted to load our new script that we wrote for ICMP replies from the
logging module earlier in the course, we could do that as well.
And so I'm just going to type out the full directory here, and that one
was test.zeek, right? And then we'll save it. And then after we make any
customizations to the scripts that we want loaded, we always have to
deploy Zeek again, and there it goes. Now that it restarted, we can go
ahead and test it out.
So one thing that I want to do is navigate to the log
directory real quick. And as you can see,
we already have some logs, so let's cat the connection log real quick.
And as you can see, it's in JSON format by default. Switching over to my
domain controller, we're going to try to traceroute to Google real quick
because we turned on that detect traceroute script, so let's just see if
that script actually worked and it's invoked now because it wasn't being
used prior to us uncommenting that.
So while that traceroute's running,
we can look and, as you can see, we have the notice log already generated,
whereas previously, there was no notice log.
And so since the detect traceroutes is a signature detection,
we're likely going to get a signature‑based notice here. So let's look at it.
And as you can see,
we have a message here that says somebody seems to be running traceroute
using ICMP. And if we do that with the pretty print,
so jq, if we go ahead and look at it with that,
here we go.
We have a capture loss here as part of the notice,
but the one that we're looking for is that traceroute detected.
And so, the note's telling us what the alert was. The message is telling us
that 30.11 seems to be running traceroute using ICMP.
Now we can also do something similar, too. If you look,
you notice that we are using ICMP for traceroute.
And since we turned on our ICMP reply script,
we also have a reply.log in here as well.
So we can take a look at that. And we can see the ICMP replies
from Google coming back into the system.
So our scripts that we wanted to load and add to the local script worked.
We were able to modify the format of our standard logs into the
JSON format, and we can see it right here.
Those are just some small customizations that you can use. Other
customizations that we can have within Zeek,
we can load scripts that have redefinitions for any of the BiFs or the
contents within the BiFs. We can have redefinitions for log writers. We can
have redefinitions for variables and functions. So, using that local.zeek
script is very helpful in helping us customize the system and making it how we
want. And like I mentioned previously,
we need to make sure we know what we want to know to be able to
optimize the system and tune it effectively.
But these were just some small tricks that we can use to help add to the
functionality of Zeek while at the same time customizing it to our preferences
and turning off some scripts that we may not need.
And from a tuning perspective,
customizing how the scripts behave and interact with the
system will be helpful because you'll be able to identify
thresholds that you need to modify,
which we can redefine with scripts here and there.
You'll be able to identify different events that you want to see
or different events that you don't want to see.
So redefinitions and, especially tuning thresholds helps us optimize as well.
And there we go. Now that we've learned some of the basic surrounding tuning
and optimizing the Zeek system, we'll need to get to building our own script
for detection and load it into the configuration.
That's what we'll be doing in the next module, so join me there.