Tech Log Entry — Kali Linux Live USB (Tool Installation and Zeek Configuration)
Tech Log Entry — Kali Linux Live USB (Tool Installation and Zeek Configuration)
Part 2 of 2: Network Analysis Tool Installation, Zeek Deployment, and JSON Log Configuration
Date: June 30, 2026
Summary
Following successful encrypted persistence boot (documented in Part 1), a full suite of network analysis tools was installed into the persistence partition of the Kali Linux 2026.2 Live USB. Tools installed include Wireshark, tshark, tcpdump, Suricata, nmap, netdiscover, tcpflow, jq, termshark (manual binary install), and Zeek (via official Zeek apt repository with symlink PATH resolution). Zeek was deployed via zeekctl, confirmed running with active log output, and reconfigured to output JSON-format logs for use with jq. All tools were confirmed present and operational across a full reboot cycle, verifying persistence is functioning correctly.
Background and Context
This entry continues directly from Part 1. The goal for Part 2 was to populate the 24.1 GB encrypted persistence partition with a practical network analysis toolkit, verify tool persistence across reboots, and establish a basic Zeek monitoring workflow. All work was performed from within the Kali Live session booted from the USB drive on laptop #2.
Tools Installed
Steps in Process
Step 1: Initial apt Update
After booting into encrypted persistence, ran sudo apt update. Result: package lists updated; 266 packages shown as upgradeable. Total upgrade was deferred — only specific tools were upgraded as needed, to avoid the time cost of a full system upgrade in a live session.
Step 2: Core Tool Installation via apt
Installed all available tools in a single apt command:
sudo apt install -y wireshark tshark tcpdump suricata termshark nmap jq tcpflow netdiscover
Result: all tools installed except termshark, which returned 'unable to locate package termshark' — not in Kali's standard repositories. Wireshark did not prompt about non-superuser packet capture (question was silently skipped, likely because components were partially pre-installed in the live image).
Tool locations confirmed via which:
wireshark, tshark, tcpdump, suricata, nmap, jq, tcpflow: /usr/bin/
netdiscover: /usr/sbin/ — standard location for network administration tools
Step 3: termshark Manual Binary Install
termshark is not in Kali's apt repositories. Installed from the official GitHub releases page:
wget https://github.com/gcla/termshark/releases/download/v2.4.0/termshark_2.4.0_linux_x64.tar.gz -P /tmp
tar -xzf /tmp/termshark_2.4.0_linux_x64.tar.gz -C /tmp
sudo mv /tmp/termshark_2.4.0_linux_x64/termshark /usr/local/bin/
Confirmed: which termshark returned /usr/local/bin/termshark; termshark --version returned v2.4.0.
Step 4: Zeek Installation via Official Repository
Zeek is not in Kali's default repositories. Installed using the official OpenSUSE Build Service repository for Debian 12 (closest stable match for Kali's Debian base):
echo 'deb http://download.opensuse.org/repositories/security:/zeek/Debian_12/ /' | sudo tee /etc/apt/sources.list.d/security:zeek.list
curl -fsSL https://download.opensuse.org/repositories/security:zeek/Debian_12/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/security_zeek.gpg > /dev/null
sudo apt update
sudo apt install -y zeek
During installation, two package configuration dialogs appeared from courier-base (a mail server component pulled in as a dependency): one asking about web-based administration directories (answered No) and one about SSL certificate generation (acknowledged with OK — informational only). These are unrelated to Zeek's functionality.
Zeek installation confirmed successful but binaries installed to /opt/zeek/bin/ rather than a standard PATH location.
Step 5: Zeek PATH Resolution via Symlinks
After installation, 'which zeek' returned 'zeek not found' because /opt/zeek/bin/ is not in the default PATH. Multiple approaches to add /opt/zeek/bin/ to PATH were attempted (see Problems section). The reliable solution was creating symlinks in /usr/local/bin/, which is already in PATH on all shell types:
sudo ln -s /opt/zeek/bin/zeek /usr/local/bin/zeek
sudo ln -s /opt/zeek/bin/zeekctl /usr/local/bin/zeekctl
sudo ln -s /opt/zeek/bin/zeek-cut /usr/local/bin/zeek-cut
Confirmed: which zeek returned /usr/local/bin/zeek; zeek --version returned zeek version 8.2.0.
Step 6: Zeek Deployment via zeekctl
zeekctl requires root privileges and must be called with the full path when using sudo (due to sudo's restricted PATH):
sudo /opt/zeek/bin/zeekctl
Inside the zeekctl interactive prompt:
install
deploy
status
Status output confirmed: name zeek, type standalone, host localhost, status running, with active PID. The 4-hour timestamp offset in the status output is expected — Zeek runs in UTC; local time is CDT (UTC-5).
Note: Zeek does not start automatically at boot. It must be manually started each session with sudo /opt/zeek/bin/zeekctl deploy. A desktop reminder note was created in the persistence partition to document this and other session startup steps.
Step 7: Zeek Log Verification and JSON Configuration
Active log files confirmed in /opt/zeek/logs/current/:
conn.log — all network connections (source, destination, port, duration, bytes)
dns.log — all DNS queries and responses
notice.log — Zeek-generated alerts
stats.log — Zeek performance statistics
capture_loss.log, packet_filter.log, loaded_scripts.log, stderr.log, stdout.log, telemetry.log
Default Zeek log format is tab-separated text, not JSON. jq cannot parse this format. Zeek was reconfigured to output JSON by adding a single line to the site policy file:
echo '@load policy/tuning/json-logs.zeek' | sudo tee -a /opt/zeek/share/zeek/site/local.zeek
Confirmed present in local.zeek via tail -3. Redeployed:
sudo /opt/zeek/bin/zeekctl deploy
JSON output confirmed: sudo cat /opt/zeek/logs/current/dns.log | jq . produced structured JSON entries with fields ts, uid, id.orig_h, id.resp_h, query, qtype_name, and others.
Step 8: Reboot Verification
Full shutdown and reboot performed. Boot sequence followed correctly (two-prompt sda4 pattern, then sdb3 passphrase). After reaching the desktop, confirmed in terminal:
which suricata zeek jq tcpflow termshark
All five returned valid paths. Zeek was started manually, redeployed, and JSON log output confirmed with:
sudo cat /opt/zeek/logs/current/dns.log | jq '.query' | head -5
Five JSON-formatted domain name entries returned, confirming both persistence and JSON configuration survived the reboot.
Problems Encountered and Solutions
Problem 1: termshark Not in apt Repositories
Did not work: sudo apt install termshark — 'unable to locate package'
Worked: Manual binary download from official GitHub releases, extracted and moved to /usr/local/bin/
Problem 2: Zeek PATH Not Resolving After Installation
Zeek installed to /opt/zeek/bin/ which is not in the default PATH. Multiple approaches were tried to add it permanently:
Did not work: echo 'export PATH=$PATH:/opt/zeek/bin' >> ~/.bashrc and source ~/.bashrc — sourcing caused terminal errors (shopt not found, complete not found, parse errors) due to shell context mismatch; the PATH also did not persist to new terminal windows
Did not work: echo 'export PATH=$PATH:/opt/zeek/bin' | sudo tee -a /etc/bash.bashrc — new terminal windows still did not pick up the PATH
Did not work: echo 'export PATH=$PATH:/opt/zeek/bin' | sudo tee /etc/profile.d/zeek-path.sh — /etc/profile.d/ only loads for login shells; Kali's default terminal emulator launches non-login shells
Worked: sudo ln -s /opt/zeek/bin/zeek /usr/local/bin/zeek (and zeekctl, zeek-cut) — symlinks in /usr/local/bin/ are in PATH on all shell types regardless of login/non-login status
Problem 3: sudo Cannot Find zeekctl by Name
Even after symlinks were created, 'sudo zeekctl' returned 'sudo: zeekctl: command not found' because sudo uses a restricted PATH that excludes /usr/local/bin/ by default on this Kali configuration.
Did not work: sudo zeekctl
Worked: sudo /opt/zeek/bin/zeekctl (or sudo /usr/local/bin/zeekctl) — using the full path bypasses sudo's PATH restriction
Problem 4: jq Parse Error on Default Zeek Logs
Running sudo cat /opt/zeek/logs/current/dns.log | jq . returned 'jq: parse error: invalid numeric literal' because Zeek's default log format is tab-separated text, not JSON.
Did not work: Piping default-format Zeek logs to jq
Worked: Adding @load policy/tuning/json-logs.zeek to /opt/zeek/share/zeek/site/local.zeek and redeploying — all subsequent logs output as JSON, fully parseable by jq
Problem 5: Zeek Log Permission Denied
Attempting to read Zeek logs with standard redirection (< /opt/zeek/logs/current/dns.log) returned 'permission denied' even with sudo, because the shell opens the file for redirection before sudo takes effect.
Did not work: sudo zeek-cut ... < /opt/zeek/logs/current/dns.log
Worked: sudo sh -c '/opt/zeek/bin/zeek-cut ... < /opt/zeek/logs/current/dns.log' — wraps the entire command including redirection in a root subshell
Note: after switching to JSON output, sudo cat ... | jq . is the preferred workflow and does not have this redirection issue.
Problem 6: Zeek Mail Errors on zeekctl deploy
Every zeekctl deploy produced errors: 'error occurred while trying to send mail: ERR: authdaemon: s_connect() failed' and 'sendmail: unable to submit message'. Zeek is configured by default to email alerts to a local administrator, but no local mail server is running on a live USB system.
Resolution: Ignored. These errors are harmless — no data is sent anywhere. The mail feature is intended for unattended server deployments. For a manually operated portable toolkit, the feature adds no value. The MailTo field in /opt/zeek/etc/zeekctl.cfg can be cleared to suppress the messages if desired in a future session.
Lessons Learned
Not all tools are in the distribution's default repositories. Having a fallback strategy (official project repo, GitHub releases binary, or build from source) before starting saves time. Zeek required an external repo; termshark required a manual binary install.
sudo's PATH is more restricted than the user's PATH. Tools installed to non-standard locations (/opt/, /usr/local/bin/) may be visible to the user but not to sudo. Symlinks in /usr/local/bin/ and full-path calls to sudo solve this reliably.
Shell startup file sourcing is context-dependent. .bashrc is not sourced for login shells; /etc/profile.d/ is not sourced for non-login shells. When PATH changes don't stick across terminals, symlinks are more reliable than export statements in startup files.
Switching Zeek to JSON output early (before beginning analysis work) saves significant effort. The tab-separated default format requires zeek-cut for every query; JSON format works directly with jq and is more flexible for filtering and scripting.
Zeek must be started manually each session. It is not configured to auto-start on boot in this live USB setup. Documenting session startup steps in a persistent notes file on the desktop is a practical operational habit.
Verify tool persistence immediately after the first reboot. A passing reboot test with 'which [tool]' for every installed tool confirms the entire persistence layer is working before relying on it in the field.
Things to Watch Out for in Future
Zeek does not start automatically at boot. Run sudo /opt/zeek/bin/zeekctl deploy at the start of each session before expecting log output. The desktop note file in the persistence partition documents this.
Zeek logs accumulate in /opt/zeek/logs/. On a 24.1 GB persistence partition, long sessions with high-traffic captures can consume space. Periodic log cleanup or rotation should be considered for extended use.
The zeekctl mail errors (sendmail failures) will appear on every deploy. These are harmless but visually noisy. They can be silenced by clearing the MailTo field in /opt/zeek/etc/zeekctl.cfg.
Suricata is installed but not yet configured for active use. Suricata requires interface configuration and rule updates before it functions as an IDS. This is a planned next step.
Wireshark produces a QDBus warning on launch ('failed to register with host portal'). This is harmless and does not affect packet capture or analysis functionality.
When reading Zeek logs with sudo, use sudo cat ... | jq rather than redirection (< file) to avoid permission denied errors from the shell's file-opening step.
Next Steps / To-Do
Configure Suricata: set network interface, update rules (suricata-update), run in IDS mode, and review alert output in fast.log and eve.json
Learn Zeek log analysis workflow: practice jq filters on conn.log and dns.log to identify traffic patterns, unusual connections, and DNS anomalies
Explore zeek-cut for tab-format log analysis as an alternative to jq for quick field extraction
Silence Zeek mail errors: clear MailTo in /opt/zeek/etc/zeekctl.cfg
Test the USB drive on laptop #1 to confirm compatibility and boot behavior on a different machine
Test on a public machine (library or hotel) to establish realistic success rate for Secure Boot / USB boot compatibility
Consider setting up automatic Zeek startup via a shell alias or small script in the persistence partition
Review Zeek's loaded_scripts.log to understand which analysis scripts are active by default and identify useful additions (e.g., GeoIP, signature detection modules)
Investigate Wireshark capture permissions for the kali user to allow packet capture without sudo
Comments
Post a Comment