Satisnet Ltd, Suite B, Building 210, The Village, Butterfield Business Park, Great Marlings, Luton, Bedfordshire, LU2 8DL
+44 (0) 1582 369330

Zeek Within Your Environment – Deployment and Set Up

Friday 5th June 2020

Zeek Within Your Environment – Deployment and Set Up

As a precursor to part two of this blog ‘Utilising Zeek for Effective Context Enhancement Within Your Azure Sentinel Instance‘, two senior members of the Satisnet SOC Team, JJ Brown and Jawad Malik, wanted to go through our Zeek instance, and the road in which this was deployed and set up within our environment.

Zeek Within Your Environment

There’s often a drive towards hardening and increasing visibility of the endpoint and perimeter levels during security monitoring implementations. However, from a security monitoring perspective, this can leave you with a gap in context between these two points when in more developed estates.

We may assume that our perimeter is secure, being protected by the latest and greatest next-gen firewall, or other perimeter security solution, but nothing is infallible.

For example, something may have been missed by your perimeter – perhaps a configuration error in your policies or emerging threat intel on even previously benign events becoming potential threat actors. Or maybe malicious activity on the endpoint has occurred, requiring the identification of lateral or east-west communications that has been missed by your firewall.

These scenarios, although basic, are standard problems for your analysts, who will struggle to provide an effective determination without the full picture.

NetFlow solutions, such as Zeek, can help by providing such a level of context to the analyst, at both an incident triage and response level, and by giving a view into the connection on multiple layers of the OSI model.

Setting Up Zeek

The beauty of Zeek is that it works on most modern, Unix-based systems and requires no custom hardware. It can be downloaded in either a pre-built binary package or via source code forms. Let’s take a case study look at how Zeek can be set up to combat the first scenario we mentioned.

For our environment, we used Ubuntu 18.04 LTS, hosted on a Windows 10 Pro Hyper-V VM, with the following systems specs:

OS: Ubuntu 18.04.4 Server (64-bit)
Memory: 16GB
Disk: 500GB
vCPU: 4
NICs: x2

Before you start, we do recommend that you follow the official guide on installing the required dependencies and Zeek (here), as well as the minimal starting configuration for a single Zeek instance (here).

So, let’s begin: Use the following commands for minimal install:

Required Dependencies

sudo apt-get install cmake make gcc g++ flex bison libpcap-dev libssl-dev python-dev swig zlib1g-dev
Download the full zeek source code (here)
git clone –recursive

Install Zeek

cd zeek
sudo make install

Adjust the PATH environment variable to include the path to Zeek’s binaries:
export PATH=/usr/local/zeek/bin:$PATH 

Configuring Zeek

Update the configuration files located under:

Make sure to specify the network interface that you want to monitor:

Find the line interface=eth0 and change it to your interface

Specify the private IP range which you want to monitor:

Find the MailTo line and add your email address:

Use the following:
sudo /opt/zeek/etc/ install
sudo /opt/zeek/etc/ start 

Outputting Zeek logs to JSON Format 

By default, Zeek will output the logs in the TSV (Tab Separated Values) format. For higher performance and better parsing in the likes of Azure Sentinel, we recommend that you configure Zeek to output the logs in JSON format. See below for how you can do this.

Configure Zeek to output JSON logs, starting with:
sudo /opt/zeek/etc/ stop

Edit /opt/zeek/share/zeek/site/local.zeek and add the following:
@load policy/tuning/json-logs.zeek
sudo /opt/zeek/etc/ deploy 

To confirm the changes:
tail -f /opt/zeek/logs/current/conn.log