0.4 Installing the Tools and the Lab Pack

Introduction

Lesson 0.3 introduced the course's tools. This lesson installs them, gets the lab pack, and checks both, so that when you open Module 1 the commands in the lessons produce the same output on your machine as they did when the lessons were written.

There are three routes, depending on your operating system, and they all end in the same place: the six tools at the course's versions, and the lab pack unzipped and verified. Linux is the most direct.

Windows reaches Linux through the Windows Subsystem for Linux. macOS can run most of the tools natively, but a Linux virtual machine is the simplest way to run all of them at the versions the course uses.

You do not need administrator access to a network, a capture card or a server. The course reads capture files; it never asks you to capture live traffic until Lab Setup, which is optional. A laptop with a few gigabytes of free disk is enough.

Set aside an hour or so for this lesson, depending on your connection. Most of it is waiting for downloads: the tools, and then the lab pack, which is the largest single download in the course. Doing it before Module 1 means the first lesson starts with the evidence rather than an install.

Two habits from here on will help. Keep a command log from the start: a plain text file where you paste each command you run and a note of what it showed. And keep this lesson's checks in it, so that if anything behaves oddly later, you can see exactly what your setup looked like when it worked.

The course's commands were written on Linux, and they run unchanged on any Linux system with the tools installed. That makes Linux the recommended route, either installed directly or in a virtual machine:

A virtual machine is a good choice even if you have Linux already, because it keeps the course's tools and versions separate from anything else on your system. Ubuntu 24.04 is a sensible default: it is current, widely documented, and the install commands in section 3 are written for it. Give the machine a few gigabytes of disk for the pack and room to unzip it.

On Windows, the Windows Subsystem for Linux gives you an Ubuntu system inside Windows, and from there the steps are the same as on Linux. Section 2 covers it.

macOS is the one route where the tools are uneven. Wireshark and TShark install cleanly from Wireshark's own installer. Zeek and Suricata are available through other routes, but not from their projects' own macOS packages, and matching the course's versions is harder:

If you use a Mac, the simplest path is a Linux virtual machine for the course. If you prefer to work natively, install what you can, use Docker for Zeek, and accept that some outputs may differ slightly from the lessons'.

Whichever route you choose, choose it once. The course's examples and the answer guides all assume one machine with one set of tools, and the version loop in section 5 is only meaningful if it describes the machine you actually work on. Moving between machines partway through the course means checking versions and the pack again.

A word on resources. None of the tools is demanding on its own, but some of the course's commands read captures of tens of megabytes and logs of thousands of lines, and they run noticeably faster with a couple of processor cores and a few gigabytes of memory to spare. A virtual machine with two cores and four gigabytes is comfortable; less works, more slowly.

Whatever you choose, make sure you can copy text out of the terminal. You will paste commands into it from the lessons, and copy outputs out of it into your command log, many times in every module.

On Windows 10 version 2004 or later, or Windows 11, one command installs the Windows Subsystem for Linux and an Ubuntu distribution. Run it in PowerShell or Command Prompt, opened as administrator, then restart when asked:

wsl --install
wsl --list --verbose

Microsoft's documentation describes what the first command does: it enables the components WSL needs, installs the Linux kernel, sets WSL 2 as the default, and installs Ubuntu. When it finishes and you restart, open Ubuntu from the Start menu and create a user name and password. The second command lists your distributions and the WSL version each uses; Ubuntu should show version 2.

From here, everything in the course happens inside the Ubuntu terminal, and section 3's commands apply unchanged.

One recommendation from Microsoft's documentation matters for this course in particular: keep files you work on with Linux tools in the Linux file system, not on the Windows drive. Working across the two is possible but significantly slower, and the lab pack's captures are large enough that the difference shows. Unzip the pack into your Linux home directory, as section 6 does, rather than into a Windows folder.

If you want Wireshark's graphical interface as well, install the Windows version from Wireshark's download page and open the pack's captures from the Linux file system through Windows' file browser.

The course's lessons use TShark inside Ubuntu; Wireshark on Windows is a useful companion for looking at a packet's structure, not a requirement. If you install both, make sure the Windows Wireshark is also from the 4.6 branch, so the two views of a packet agree.

WSL is a full Linux system, so anything you learn about the tools there applies on any Linux machine you meet at work.

A few practical points save time later. Windows Terminal, which Microsoft recommends for WSL, lets you open several Ubuntu tabs side by side, which is useful when a lesson has you compare two outputs.

The Linux home directory is reachable from Windows' file browser under the network location for WSL, which is how you would open a capture in Windows' Wireshark. And the Ubuntu inside WSL needs its packages updated like any other, with the commands Microsoft's documentation gives, before you install the course's tools.

On Ubuntu, most of the tools come from the distribution's own packages, and two come from archives their projects maintain, so you get the current releases rather than the older ones the distribution ships:

sudo apt-get update
sudo apt-get install -y tcpdump jq python3 unzip software-properties-common
sudo add-apt-repository ppa:wireshark-dev/stable
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt-get update
sudo apt-get install -y tshark suricata

The first two lines install tcpdump, jq, Python, unzip and the helper that adds package archives. The next two add the archives: Wireshark's download page links the Wireshark developers' stable archive for Ubuntu, and Suricata's installation guide names the OISF's stable archive, which always holds the latest stable release. The last two lines refresh the package lists and install TShark and Suricata from those archives.

Why the archives matter: the distribution's own packages are fixed when the distribution is released. On Ubuntu 24.04, TShark from the distribution is an older branch than the course's, and Suricata from the distribution is on the 7.0 branch, which reached its end of life in July 2026. The archives give you the current releases, which match the course's.

During the TShark installation, Ubuntu may ask whether non-root users should be able to capture packets. For this course the answer does not matter, because you read files rather than capture, and you can change it later. If you later follow Lab Setup and capture your own traffic, choose to allow it then, or capture with sudo.

If you work on another Linux distribution, the same tools are available, but the commands differ. Use your distribution's package manager for tcpdump, jq and Python, and follow each project's own installation page for Wireshark, Suricata and Zeek. Lesson 0.3's references point to each.

The order of the commands matters in one way. If you installed TShark or Suricata from Ubuntu's own packages before adding the archives, the installed versions stay where they are until you upgrade them; the last install command does that, because installing a package that is already present from a newer archive upgrades it. Check the versions afterward, as section 5 does, rather than assuming.

The archives are maintained by the projects themselves, which is why the course trusts them. Adding a third-party archive is a decision to trust whoever runs it with root access to your machine, so add only these two, and only from the names their projects publish.

Zeek is the one tool that most distributions do not package, so it needs its own step. Zeek's installation documentation offers three routes: binary packages for many Linux distributions through the openSUSE Build Service, official Docker images, and building from source.

The packages come in lines: a package named after a long-term-support line, such as zeek-8.0, stays on that line until you switch, while the package named simply zeek follows the latest feature release. Zeek's documentation lists the current lines, and the instructions for adding the repository for your distribution. The course uses the 9.0 long-term-support line; install the package for it if your distribution's repository has one.

The Docker images are the most consistent route across platforms, and they need no repository setup. The image tagged lts is the current long-term-support release:

docker pull zeek/zeek:lts
docker run --rm -v "$PWD":/pcap -w /pcap zeek/zeek:lts \
  zeek -C -r inside.pcap

The second command runs Zeek from the image on a capture in the current folder, and writes its logs to the same folder. If you use the container, run every Zeek command in the lessons the same way, with the capture's folder mounted. zeek-cut is in the image too, and works the same way.

On macOS, Homebrew has a Zeek formula, which Zeek's documentation notes is not maintained by the Zeek project, so its version may lag. The container is the safer route on a Mac.

Whichever route you take, check the result with the version command from lesson 0.3. A Zeek from the 9.0 line will write the same logs as the course's; another line may differ in some fields, and the version line at the foot of each lesson tells you which produced its output.

The container route has one more advantage: it is easy to keep more than one version. If you later need to compare how two Zeek releases log the same capture, which happens when an organization upgrades its sensors, the image tag selects the release and nothing else on your machine changes. The course does not need this, but the habit is a good one to have before you need it.

When the tools are installed, run the loop from lesson 0.3. On the machine the lessons were built on, it prints this:

$ for t in 'tcpdump --version' 'tshark --version' 'zeek --version' \
  'suricata -V' 'jq --version' 'python3 --version'; do
  $t 2>&1 | grep -m1 -E '[0-9]+\.[0-9]+'; done
tcpdump version 4.99.4
TShark (Wireshark) 4.6.9 (v4.6.9-0-g2d548b197c75).
/opt/zeek/bin/zeek version 9.0.1
This is Suricata version 8.0.8 RELEASE
jq-1.7
Python 3.13.18

Compare yours line by line. The versions that matter most are TShark's 4.6 branch, Zeek's 9.0 line and Suricata's 8.0 branch. A later patch release in the same line, such as a newer 4.6 or 8.0, is fine: patch releases fix problems without changing what the course relies on. A different branch is worth noting, because some outputs will differ.

If a tool is missing, the loop prints an error for it, which tells you what to install. If a tool reports an older branch than expected, the most likely cause is that the distribution's package was installed before the project's archive was added; upgrade the package and check again.

Python does not need to match exactly. Neither does tcpdump, for the course's purposes, because the course reads captures rather than taking them. The course's scripts use only Python's standard library and run on any recent Python 3. jq 1.7 and later behave the same for everything the course uses.

When the loop matches, you are ready for the lab pack. If one line still differs after an upgrade, note it in your command log and carry on; the version lines at the foot of the lessons will tell you where to expect a difference. Keep the loop's output; it is the first line of your command log, and the version record a reviewer would ask for.

If you use the Zeek container, the loop's Zeek line will report an error because Zeek is not installed directly. Run the version command through the container instead, as section 4's second command does with a capture, and record that line in place of the loop's. The container image carries the same Zeek as its tag says, so its version line is the one that matters.

Checking now saves time later. Every lesson from Module 1 onward assumes the tools are present and at these versions, and a missing tool is much easier to notice before the first command than in the middle of an exercise.

The lab pack is one zip file, available to subscribers at /downloads/lab-packs/nd-lab-pack.zip. It is large, because it holds real captures, so download it once and keep it. Its size and SHA-256 hash, as built for this version of the course, are:

$ ls -l nd-lab-pack.zip | awk '{print $5, $9}'
sha256sum nd-lab-pack.zip
245857757 nd-lab-pack.zip
c83b36cfa9d055c823254809f8d54744405982e707e812f3812f618d019de682  nd-lab-pack.zip

That is 245,857,757 bytes. After downloading, compute the hash of your copy with sha256sum on Linux or WSL, or shasum -a 256 on macOS, and compare it with the one above. If they match, your copy is exactly the pack the lessons were built on. If they do not, download it again before going further.

Then unzip it into a folder in your home directory. The course's lessons assume a layout like this:

mkdir -p ~/nd && cd ~/nd
unzip ~/Downloads/nd-lab-pack.zip
ls

The last command lists the folders. The figure shows the layout they make:

Every lesson names the folder it uses, and every command in it runs from inside that folder. Keep the folder names as the zip made them, because a few commands refer from one folder to its neighbor. The capstone's detection scoring, for example, runs from the case7 folder and reads the benign window from case7b beside it, and the Module 11 scorer reads several case folders the same way.

The pack changes only when the course does. If a later version of the course changes a pack, the lessons that use it are rebuilt at the same time, and the hash in this lesson changes with them. A mismatch between your copy's hash and this lesson's is therefore always worth resolving before you start.

The download needs a paid subscription, as the course's lessons beyond Module 0 do. Module 0 itself, including this lesson, is free to read, so you can set up everything else before subscribing and download the pack when you are ready to start Module 1.

Keep the zip after unzipping it. If a folder is ever damaged, or you want a clean copy for a second machine, unzipping again is quicker than downloading again, and the hash above tells you the zip is still intact.

The zip's hash checks the download as a whole. Each folder's SHA256SUMS file checks the files inside it, which is the check every exercise starts with. Run it once now for every folder, from the folder you unzipped into:

$ for d in */; do (cd "$d" && sha256sum -c --quiet SHA256SUMS) \
  || echo "$d failed"; done; echo checked $(ls | wc -l) folders
checked 27 folders

The loop prints nothing for a folder whose files all match, the name of any folder that fails, and a count at the end. All 27 folders pass on the built pack, and yours should too. A failure after a matching zip hash means a file was changed after unzipping, which is worth finding out about before you rely on it.

Make this loop a habit as well. The exercises each start by checking their own folder, and the capstone starts by checking two. Running the check before any work is what Module 2 calls verifying evidence before analysis, and it is the same discipline whether the evidence is the course's or an incident's.

The check also makes your later work defensible. When you write in an exercise record that a finding came from a particular capture, the checksum is what lets anyone else confirm they are looking at the same capture, and the SHA256SUMS file is the published list they can check it against.

If a folder ever fails the check, do not try to repair the file by hand. Delete the folder and unzip it again from the zip, then run the check for that folder alone. A capture that has been edited, even accidentally, is no longer the evidence the lessons describe.

The same caution applies to the logs. It is tempting to tidy a log file, removing lines you do not need, so a command runs faster. Make a working copy for that instead, and leave the pack's files as they are; lesson 2.7 explains why a working copy is the right habit for any evidence.

If something does not match later in the course, the cause is usually one of a few, and each has a quick check:

With the tools checked and the pack verified, your setup is complete. Lesson 0.5 uses both: it opens the first capture of Module 1, reads it with TShark and capinfos, runs Zeek on it, and shows you how to work through an exercise.

Versions this lesson relies on: Wireshark and TShark 4.6.9; Zeek 9.0.1 (LTS); Suricata 8.0.8; tcpdump 4.99.4.