Now we're hopping into the lab and we'll be installing Zeek and
letting it use its default scripts and information.
We're going to start off this demo by installing the necessary prerequisite
packages and updating our current packages on the CentOS box.
We'll then move into the user and group configuration
and start the Zeek installation.
After all of the code is built and installed,
we'll configure it really quickly, and then be ready to go.
Let's hop in and start configuring.
We're going to start off this demo by checking out the prerequisites
for the Zeek installation and getting them installed.
As you can see here, we're in the temp directory currently,
which is where the Zeek code sits.
I'm going to use the sudo yum install command followed by the
package names to install all of the libraries and tools that I
want to have in this deployment.
A list of the actual required ones can be found in
the Zeek documentation library, or in the slide deck a couple slides back.
So we'll let this run for a few minutes and then move on.
Up next, now that I have these packages installed,
I need to check for any updates on the yum repos for my packages
that were already installed on the machine.
The command for this is sudo yum update, and there's nothing available.
My applications are up to date.
With that being said,
I need to reboot the host in order to ensure that everything is
ready after the installation to function.
Once the host comes back up and we have connectivity into the box,
we can add our user, Zeek.
We're going to add this user to the group Zeek,
add it to our wheel group so it can have unlimited access to the system,
and set the password.
Giving this user sudo privileges isn't the best
idea from a security perspective.
We'd want to control exactly what permissions it
has in an enterprise environment, but for lab purposes and quick setup,
this is fine for now.
Now I'm going to change over to that Zeek user that we
created so we can kick off the installation.
Up first, I need to un-tar the package.
We're going to just use the simple tar -xvf command
with the filename at the end.
Since we're already in that directory, we don't need to add anything else,
like the path, for it to work.
With that being completed,
let's take a look at what we have in the newly-created zeek- 3.0 .0 directory.
Here, we have several options that we can check out,
including the README doc and the configure scripts.
We'll start this configure script, but in a special way.
I want this to have the default directory of
/opt/zeek for the installation path.
So I'm using the --prefix=/opt/zeek syntax after the configure command
to let the system know that's where I want it to be.
I'm running the command sudo make to get the code
recompiled so that we can install the build.
Now this is going to take several minutes to compile.
I mean, you can be sitting there watching this for a while.
I don't think watching that happen here would be beneficial,
so we'll skip over to the next item.
The next command is going to get it all installed properly after compilation.
It should look something like this once it's all said and done.
The command to do this is the make install command.
After Zeek is installed and ready to go,
we need to make a few more minor tweaks prior to starting Zeek.
We need to set the capabilities of it, and of ZeekControl,
so that they can have permission to access the network management
functions and raw and packet sockets within the system.
We'll also change the ownership to the Zeek user if you want,
and tell the system where the Zeek path is.
Now that those items are out of the way,
let's move into the configuration of the tool really quickly.
Within the path directory,
we're going to move into the /etc portion of it so that we can
check out some of the configuration items here.
We're able to configure the network.cfg, the node.cfg, and the zeekctl.cfg.
Right now, we're only going to focus on the node.cfg file.
This is where you identify the interfaces being used and some of the parameters
of the cluster configuration if using this deployment type.
We need to know what interface to put into the configuration,
so using the ip add command brings up our available options.
I'm going to simply use the main interface, ens192, for it.
I'm using VI to edit the configuration so that we can get it written quickly.
If this were a cluster deployment,
we would put those other two interfaces here as workers that
need to connect to the manager designated by whatever
addresses we have it designated at here.
Once that's saved, we should be good to go to start Zeek up.
Uh-oh, looks like it's not quite ready to go.
Let's try to deploy really quickly to see if we can
get the configurations out there.
Oh, that's crashing too.
Well, this is good for some troubleshooting of the installation then, isn't it?
Notice how I used the zeekctl command followed by deploy to start that.
We can use this command, along with several other commands,
to get additional information about Zeek and what's going on with it.
Looking at the status, we see that our standalone node has crashed,
that's not good.
This typically happens when there's something wrong with
permissions or access to certain pieces of the system.
In our case,
I'm going to try to set the capabilities of the Zeek and ZeekControl
applications again to gain access to the network management and
capture sockets now that the ownership of the program changed
ownership to the Zeek user and group.
Another useful command is this ZeekControl command,
which gives us the status about the plugins installed and
the version information for the tool.
Next, we'll start Zeek up, and look, no errors.
This is great news.
So I know we covered this briefly previously in the course,
but it's worth mentioning again.
You know that most of the time,
Linux logs are stored here in the /var/log directory.
Well, Zeek doesn't do this.
It keeps its logs in its own directory within the Zeek path.
As you can see here, we don't have anything for Zeek.
Let's hop over to the correct directory so that we can see
what's being detected since we turned Zeek on and verify
that it's functioning as expected.
So we'll navigate over to the /opt/zeek/logs/current to see
the current events that Zeek has detected.
Listing the contents,
we have those same options that were present during
the first demo in the course.
Surprisingly, this is actually structured data.
It doesn't really look like it the way it's displayed on the
screen with this resolution and font size,
so play with your settings at home to see if you can get it into
a more readable state with your SSH program.
This is just the output from the application layer,
HTTP analyzer, and corresponding policy script.
We also have the connection log, which shows us our connection-related events,
and the weird log, which is my favorite.
If you want these ASCII logs a little more
structured or readable in a certain way,
I definitely recommend that you pipe them over to a SIM and control
the ingestion of that data so you can create fields,
tags, and workflows for the data that Zeek is giving you.
We'll cover the data exporting in a later module.