All right, and now to validate the configurations that we just made.
So the first thing that we want to validate is
going to be that telnet signature.
Now where we're going to go to actually look at the signatures
being triggered is going to be the notice log,
and that's going to be in the directory /usr/local/zeek/logs,
and then current.
And as you can see, we have a whole bunch of logs right here.
So let's check out the notice log real quick first to validate that
we don't have any signatures triggered already.
And as you can see, we don't.
We have a certificate validation problem in here,
which is fine, but we don't have our actual signatures that have been triggered.
And keep in mind that this directory,
this /user/local/zeek directory is one of the default
installation directories for Zeek, but this may vary based on your installation.
So let's try to connect to telnet.
We're just going to try to connect to this same host,
our Zeek host, and connect to it,
and it should reject it since we're not set up for telnet.
Now let's look at the actual notice log and see.
As you can see here, we got a signature match.
A sensitive signature notification was sent, and we have our event string.
Remember that Why are you even using this?! Now,
these logs are a little messy when we're viewing them like this,
but we'll learn how to clean those up in the next module where we're
talking about the notice in the logging framework.
But for now, we can validate that our signature for telnet actually worked.
Now let's look at the other signature that we made for
HTTP traffic going to our 30.11 box.
So for this one I'm going to hop over to the web browser,
and we're going to try to navigate to the 30.11 address,
but let's put databases in the URI just to see if it triggers that signature.
We should get a no file or directory found here.
And hopping back over to our notice log, check this out.
We have another signature match for that HTTP sig
saying we shouldn't be accessing this.
So we just validated that we're able to create these signatures to
look for specific types of traffic or specific patterns of traffic or
get those events logged in the notice log so that we can use them for
some sort of thing later on.
Now remember, we can clean up these logs, and we will in the next module.
We're going to use something called zeek‑cut to help clean
up some of our logging and notice stuff.
We're going to look at potential JSON output.
We might be able to also ship these logs to SIEMs like the ELK stack or
Splunk, and then we can also filter some of these logs as well.
There are a lot of possibilities to customize Zeek, and
especially the logging and the notifications.
So these signatures working, these were just really basic ones, but you saw how
we can inspect the HTTP payload. And if you think about it,
we can do things like detecting malicious strings or looking
for specific types of commands and looking for PII getting
sent across and so on and so forth.
So there's a lot of capabilities built, even just in this signature
framework, and that's only scratching the surface of what Zeek can do
or what we can customize Zeek to do. And with that, I'm glad we were
able to get the signature framework figured out and our signatures
actually validated.
I'll be revisiting this later on in the course as well so we can
solidify this knowledge. In this module, we were able to learn about
the Zeek architecture and workflow and learn about the various
components within Zeek's signature framework.
We also built a few signatures to detect traffic on the network
so that we can see all of those conditions,
like the header conditions and the content conditions. Coming
up next, I'm going to dive into the logging and notice
frameworks so that we can identify how they work and what role
they play in the Zeek workflow.
We'll learn all about these and how to use them, so join me in the next module!