Zeek has been a staple in the Security Onion suite for some time now.
But with the ability to containerize applications gaining popularity,
more applications have been added,
and new abilities have been created to improve the uses of the suite.
Let's take a look at how Zeek can be used with some of the Security Onion
components before we dive into the lab and see it first hand.
Zeek now is installed automatically with Security Onion and is containerized.
It's used within the platform to provide network visibility,
and the logs are parsed and sent to be stored.
They are then available to view in other tools.
Those tools are Kibana and Hunt.
We'll talk more about the ELK stack in Kibana more in the next modules as well.
But within Security Onion, Elasticsearch is what parses and stores the Zeek logs.
Kibana and Hunt then pull the logs for their use.
Kibana can be thought of as your front end to the ELK stack,
the SIEM GUI so to speak.
Hunt is a similar interface that allows you to essentially
hunt through your data in Elasticsearch.
It's already tuned fairly well and gives you a lot
of great information off the bat.
Zeek has the ability to use the Intelligence Framework in order to add
threat intelligence and additional context to your data.
Security Onion supports this capability as well and allows you
to add your own intel to the deployment.
We'll cover the Intelligence Framework in a later module for this course.
But as we'll find out here in a few minutes,
we'll need to program the Intelligence configurations using
the Salt scripts and monitor the logs to ensure that it's
being added appropriately afterwards.
As with a typical Zeek installation,
we're able to add our own custom scripts to the deployment as well.
This is handy for being able to deploy a solid Zeek implementation in
your network within Security Onion while also not being constrained to
the preconfigured parameters that they provide.
You can do things like add and remove scripts,
modify the local.zeek script, turn on and off protocol analyzers,
and so much more.
So Security Onion gives us a lot of flexibility with using Zeek while
also giving us a standardized build of it as well.
So as I mentioned,
we use something called Salt to manage the Zeek
configurations within Security Onion.
This actually manages all the processes on all of the Security Onion nodes.
So if you don't already know about Salt,
I suggest reading up on it in the documentation.
What this is used for is for infrastructure management and
helps us push out configs as needed.
Salt allows us to change options in Filebeat,
firewalls, alerting, Suricata, and Zeek as of Security Onion 2.3.
Salt files are also in YAML format.
With regards to Zeek, Salt manages the local.zeek,
node.config, and zeekctl.cfg files so we can use options for redefinitions,
signatures, and script loading from the local.zeek script in the Salt config.
We can modify the interface, network,
and many other options for the other two files.
Since the opt/so/saltstack/local directory isn't
overwritten during platform upgrades,
this is where we'll need to make our Salt files.
Any configuration that you make here or remove here will override the default
Salt configs in the default/pillar/zeek/init.sls file. Once saved after the
changes are made to the Salt files, the container should be restarted for the
config changes to take effect. In Security Onion's implementation of Zeek, we
have the same logs that we've seen in our standard Zeek deployment. So we'll
be able to see the connections and DNS activity and HTTP logs if we wanted to.
They're in JSON format by default and are collected by a Filebeat for
processing using Elasticsearch. They'll be in the /nsm/zeek/logs
directory for you to cat in jq with to view.
Remember, we'll use Hunt and Kibana as well to look at this information.