In this demo,
I will show you how to complete the configuration of a Zeek cluster
using a management host and three remote sensors.
I will start by checking if the Zeek software is
installed and taking note of the versions.
Each system should be running the same version of the Zeek software.
Then, I will create a user account with the same name as the
account I created on the management host.
Since I'm using an unprivileged account to manage Zeek,
I will have to enable the specific permissions that the zeek and
zeekctl binaries need to function properly.
Once all those tasks are completed,
I will pivot back to the management host, which I have named the master sensor.
I will update the cluster configuration, and then run the zeek deploy
command to start the cluster deployment and configuration.
If all goes well,
I'll be able to show you the logs that have been sent from
the remote sensors to the management host.
Let's dive in.
This is the command line interface of the DMZ sensor.
I will first verify the version of Zeek that is installed and
then create a Zeek user account that has the same name as the
account I created on the master sensor.
I will only demonstrate these steps for one system in
this demo for the sake of time.
However, you will need to repeat these steps for each system in the cluster.
Now, I will ensure that the Zeek directory files are all owned by Zeek
and enable the permissions on the zeek and zeekctl binaries so they
can be used with an unprivileged account.
Once that is complete,
we need to capture the IP address of this sensor and then
configure the second network interface for monitoring.
It is important that you double‑check that your sensor has at least two
interfaces and that the monitoring interface is in promiscuous mode.
I have created a systemd unit file that will enable promiscuous mode on
the eth1 interface after each reboot of the system.
You can use any method you are familiar with as long as it gets the job done.
Do not forget to test and verify that the interface goes into
promiscuous mode using your startup method.
Promiscuous mode will allow the sensor to see all
traffic that passes the network interface.
Forgetting to enable promiscuous mode is one of the most
common mistakes made by a system administrator when
configuring the monitoring interface.
Also, for cases where you have multiple monitoring
interfaces for more complex deployments,
those interfaces all need to have promiscuous mode enabled. On
the screen, you can see where I disabled promiscuous mode on the
monitoring interface and then used the system startup script to
enable promiscuous mode.
This is all that we need to do on each sensor, and now we will shift to the
Zeek management host for the rest of the configuration steps.
I completed the previous tasks on all three of our Zeek sensors, and
now I'm on the master sensor, which is our Zeek management host. As
the Zeek user, I will now show you the changes we need to make to the
Zeek node configuration file.
At the start of this module, we changed the default configuration from
standalone to cluster, but we only configured the manager. Now, we will
complete the configuration by adding the three sensors.
The IP address for each sensor is displayed on the screen for
your convenience. The names worker‑1 and worker‑2 can be used
if that is your preference.
However,
I would recommend you change them to reflect a more
meaningful name. Since we already have names for our
sensors, that is what I will use here.
Do not forget to change the interface to the actual monitoring
interface you have configured on your sensors.
The Globomantics Zeek sensors are all using the eth0 interface as
management and the eth1 as the monitoring interface that is connected to a
span or mirror port on the respective network switch.
I will also mention that this is the minimal configuration
needed to get a cluster up and running.
There are some additional configuration settings that allow you
to use PF_RING and AF_PACKET that allow for high bandwidth
packet capture and load balancing.
However, these are advanced topics and outside the scope of this course.
Okay, I've made all the necessary configuration changes, but before I move
on I'll take a few seconds to double‑check the changes. And it all looks to
be in order, so we can move to the next step.
Now that the cluster configuration is complete,
I need to copy the public SSH keys to each sensor so that when I
use the zeekctl command to deploy the configuration the Zeek user
will be able to authenticate and perform all the necessary tasks
on each remote machine.
Remember, we created the public and private keys at the start
of this module using the Zeek user account.
So we need to use that same account when we copy the
public keys to the remote sensors.
After copying the public key to the remote server,
I will also manually check that we can SSH without using a password.
This is the behavior that Zeek expects, and if it does not work
the deployment command will fail. Some common problems I see that
prevent this step from working are things like forgetting to
generate the SSH keys beforehand,
having different user accounts, for instance creating different accounts
on each system in the cluster, and not remembering the password for the
account being used to copy the SSH public keys.
If you followed my suggestion during this course,
you will have avoided these common missteps.
This is a good time to mention some security tips.
I am copying the public key to the remote servers and will be using the
private key to authenticate. Anyone with access to the private key can
authenticate to all the servers in the Zeek cluster.
The private key is not protected by a password,
so I would strongly recommend that access to the management
host be limited and restricted to only trusted personnel with
a business or operational need.
This is also known as the principle of least privilege.
Okay,
so I was able to copy the public key and verify login to
all three sensors without any problems.
Next up is to run the zeekctl deploy command, which will push the configuration
out to the cluster and start the Zeek daemon on each node.
If there are any misconfigurations or problems with authentication,
you will see it in the output. It looks like everything went well.
The zeekctl status command will give us some information about the cluster.
In most cases, you are looking to see that all your sensors
are operational and in the running status.
Okay,
just one more thing to do. Right now, we should be
receiving logs from all the sensors.
If we go to where the logs are stored,
we will see that there are several logs created that correspond to
the protocols that the Zeek sensors have seen while monitoring their
segment of the Globomantics network.
There are a lot of them, and this is not even every
possible log type that Zeek can provide.
We will revisit this list again in the next clip. There is even a convenient
cluster.log file we can use to check on our cluster status.
If we peek inside,
we can get some great details that will help us if we ever need to troubleshoot
a problem. I have one more tip before we end this clip, each Zeek sensor needs
to be able to communicate with the master sensor on ports 47761 and 47762. So if
you have a host‑based firewall or any other access controls that would prevent
communication over these ports,
you will need to provide this information to the network
engineers so you can get those valuable logs.