All right, now let's jump into the CLI.
So we're going to walk through a few of the configurations in here,
and let's start out with our local.zeek file since that's
going to give us some insight into how Zeek's actually
functioning inside of this environment.
And if we're looking through here,
there's not much that's changed from a standard Zeek installation.
We're still loading most of the normal frameworks that we do.
A lot of the protocol analyzers are being loaded.
Some of the file analyzers are being loaded,
and some of the special package scripts or specific detection scripts.
But if we look down here at the bottom,
we have a couple additional scripts that are being
loaded or sections that are being loaded.
So based on the Rock framework,
we have a Kafka plugin that we're using because we're shipping the logs
over to Kafka before they get sent over to Logstash.
And then we have some scripts in this scripts/rock folder that's
giving us additional Rock customizations for Zeek.
So let's go check out some of those.
Before we do, we'll go look at the Kafka plugin to see what that's all about.
And as you can see, this one's not very long.
But what it's doing is it's enabling logging from Zeek
over to Kafka for all of our logs.
We're giving it a priority.
We're sending logs for active streams using the Kafka
function and the action to send logs over there.
So this is a very basic configuration really just telling us,
hey, add these logs,
go send him over to Kafka using a custom writer that we have in this plugin,
and we're good.
Now let's take this one step back.
And in this rock folder, we have a couple of different scripts.
We have our typical load script.
We have miscellaneous scripts in here.
We have protocols and additional plugins and utilities.
But what I want to check out is this rock.zeek one.
And what this does is it gives us some additional capabilities.
So if we wanted to log the VLANs or the MAC addresses and log
all of the HTTP headers and stuff like that,
so that's what this is actually doing for us.
And I understand that some of this language is still Bro and not Zeek,
and that's because the name change is still being
filtered throughout the industry.
But we have all of these additional frameworks and scripts that
are being loaded for RockNSM specifically.
And we can even turn on a couple more that are in here if we wanted
additional information or additional context.
We're even loading things like SSH fingerprinting and the JA3 fingerprinting.
So there's a lot of capabilities that come with
RockNSM's implementation of Zeek right here.
And as you can see,
there's a couple other plugins or a couple other scripts that are
in here in the plugin folder that RockNSM uses.
And in the miscellaneous folder too,
we have some scripts to help add some intelligence,
so like the GeoIP.
We're adding that to the connection logs.
Let's go check that one out real quick.
And if you look at that,
we are defining different fields for this GeoIP information,
so the originating location, country code,
so on and so forth.
So I really encourage you to go check out RockNMS's build for
Zeek and explore it a little bit more in detail.
Look at the scripts and see how it interacts with the system.
Let's go check out the pipelines and see what Logstash is doing with this too.
And look at this.
There's 109 possibilities in the conf.d folder with
all of these different filters.
So let's take a couple and see what's going on with them.
To start with, let's look at the Logstash input filter for it.
Looks like we need to go sudo on that one.
And this is defining the simple input from Zeek or from Kafka because
Zeek's sending to Kafka and then coming over to Logstash.
And we're just defining the inputs, looking at the different fields that it has,
and calling it a day on that one.
But then,
we have all of these filters here that are going to help us
either parse and mutate the information,
enrich the data that we have coming in,
modify it based on how Rock wants to use the data.
So let's take the DNS filter, for example, and see what's going on with that.
And as I said, this filter, we have mutations in here,
so we're converting some fields over to what the
standard that Rock wants to use is, the ECS standard.
We're making sure we tag the authoritative DNS servers in
here or recursive DNS servers in here.
And then we're translating some fields based on the
outcomes of some of these if statements.
And now before we put that down, let's just look at the output now.
So we have this one Logstash output pipeline here.
And if we're looking at that, really,
it's just defining the output and defining the events and where to send them.
So we're sending all of our stuff to Elasticsearch localhost.
We're defining the indexes there.
And essentially, what this one's doing is if we're able to parse the data,
we're going to just send it to Elasticsearch.
But if not, we're going to send it into a special parsing‑failures index instead.
So we're going to send it to its normal index or its
parsing‑values failures index.
And so that's how RockNSM handles a lot of the Zeek data.
Like I've been emphasizing,
we're not going to go through every single script and identify every single
possibility for how RockNSM uses Zeek with the other tools.
But if you want to, you can download the ISO,
install it on a virtual machine easily,
and get up and running so you can explore it and modify it for your own needs.