Alright,
now we're going to hop into the lab and talk about some of the scripts
that we can use with the Zeek logging framework.
We'll build our own in this demo and validate that it meets our intentions.
If you're ready, let's hop in.
Alright,
so the first thing that I want to do before we get into the
logging that we're going to change is hop in and change our
default format back to the TSV format.
So we'll edit our local site script,
and I'm just going to uncomment that tuning script that I put in,
and then we'll redeploy Zeek.
Alright, there we go.
So for the purposes of this demo,
we're going to be using this simple script that I wrote just
to be able to detect ICMP echo replies, okay?
And so this is only attempting to demonstrate the logging framework itself,
not necessarily detect malicious activity since they're just ICMP replies,
right?
So we have our various script entities and pieces,
and we actually don't need this notice framework load up here,
but we'll leave it in there anyway.
It's not going to hurt anything.
But the main focus of what I want to show you is
under the actual events for Zeek.
So when Zeek's invoked, we're creating this log stream for the module ping,
and the path is going to be reply.
So the output of the file is going to be reply.log in the local
directory since we're going to run Zeek just locally here.
The second event where it's actually detecting the ICMP echo replies,
we're going to pass all of these records over to it,
including the connection record, which we'll talk about later on in the course.
We are passing some other fields from the actual
export above down into the logs,
and we're going to write the logs using the local
record and the info that we're passing.
And so we're going to be using a pcap here.
It's just a simple pcap with five ping requests and replies.
And so this is the file that we're going to be using to run Zeek.
So hopping back over to our local directory,
as you can see we already have an ICMP folder here,
so let's hop into that.
And as you can see, we have that same pcap,
and then we have this test.zeek script.
And so let's take a look at that, and as you can see,
it's the same script that we had in VS Code right there.
Now this is just a very simple logging script like I was talking about,
and it's really just passing the connection record information over and
designating the timestamp fields and the actual connection ID.
We're not really modifying anything else.
And one of the important things that I want to highlight
here in this script before we actually go ahead and run it
is this redefinition up here, right underneath the module.
And this is another method that we can do on a per‑log
stream basis or per‑script basis and change the logging
format over to the JSON format.
And so that's what this is doing right here.
Alright, we're going to exit that,
and now I'm going to run the command to actually
invoke the Zeek instance in here.
We're going to do it locally right within this folder.
I'm going to run it as bare bones,
so it's only going to use this script specifically.
And so we're going to use icmp.pcap as the file that Zeek's going to read,
and then we're going to use the test.zeek as the script that we're going to run.
And so after running that, as you can see,
we have a couple different logs that got placed in here,
right?
So we have the connection log, which is just tracking the connections,
and we imported the connection framework into our scripts,
which is why this log is showing up.
And we can see that it's already in JSON format.
So we can do the pretty print for it,
and we can see that we're responding over port 8,
the protocol's icmp, so on and so forth.
We can also use jq, then, to look at the reply.log as well.
And it shows the replies, five of them,
so one for each request that got sent out,
reply that came back.
So that's really cool that we were able to see that and customize
the JSON format coming out in just the one script and also customize
the logging a little bit because we were able to tell Zeek which
fields that we wanted in here, in the log.
And since we're passing some of the basic connection information over,
that's where we have the ID, the originating host and port,
and the responding host and port.