NetHound | Level 3 Implementation

Why this level matters

Most network protections weaken over time, not on installation day. Firmware changes, ISP swaps, access point replacements, and accidental rule edits can all reopen paths you thought were closed. The probe helps you notice those changes instead of assuming everything still works.

Why a Raspberry Pi works well

A Raspberry Pi can stay powered on continuously, sit quietly on the protected network, and run scheduled checks without depending on someone’s laptop being awake. That makes it a strong home choice for Level 3.

Preparation

Choose a Raspberry Pi that can run Raspberry Pi OS 64-bit cleanly.
Plan to keep it on the protected network path at all times.
Decide where you want the probe logs to live on disk.
Pick a schedule that is frequent enough to catch drift without creating noise.
Register at endpoint.nethound.io/register if you want emailed credentials and a hosted dashboard for uploaded results.

Step 3: Build a NetHound probe on a Raspberry Pi

The goal is to create a small always-on Linux host that boots cleanly, joins the protected network, downloads the NetHound Linux ARM64 probe, and runs it on a schedule.

Hardware and software you need

Raspberry Pi 4, Pi 5, or another model that runs Raspberry Pi OS 64-bit reliably
MicroSD card or SSD storage
Power supply for the Pi
Ethernet connection preferred, though protected Wi-Fi also works
Raspberry Pi OS 64-bit

Detailed build steps

Flash Raspberry Pi OS 64-bit to the device storage and complete the first-boot setup.
Update the Pi so it is not running on stale packages:
```
sudo apt update
sudo apt full-upgrade -y
```
Set a stable hostname such as nethound-probe so you can find it later on the network:
```
sudo hostnamectl set-hostname nethound-probe
```
Put the Pi on the protected network path you actually want to monitor. Ethernet behind the protected router or access point is best. If using Wi-Fi, join only the protected SSID.
Create a directory for the probe and logs:
```
mkdir -p ~/nethound/logs
cd ~/nethound
```

Download the Linux ARM64 probe binary from NetHound:

curl -L -o nethound-go-probe https://files.nethound.io/latest/linux/arm64/nethound-go-probe
chmod +x nethound-go-probe

Run the probe manually the first time to confirm the Pi can execute it and the network path behaves as expected:
```
./nethound-go-probe
```
If you want hosted reporting, add the API key issued during registration to the probe configuration. You can review uploaded runs later at endpoint.nethound.io/dashboard.
Review the output carefully. This first run becomes your baseline. If you already hardened the network at Levels 1 or 2, the Pi should reflect those protections.

Create a wrapper script so every scheduled run is logged to a file:

cat > ~/nethound/run-probe.sh <<'EOF'
#!/bin/bash
set -euo pipefail
cd /home/pi/nethound
STAMP=$(date +"%Y-%m-%d_%H-%M-%S")
./nethound-go-probe > "/home/pi/nethound/logs/$STAMP.log" 2>&1
EOF
chmod +x ~/nethound/run-probe.sh

Adjust the /home/pi path if your Raspberry Pi username is not pi.
Schedule the probe to run automatically. A simple cron schedule is usually enough:
```
crontab -e
```
Then add a line such as:
```
0 */6 * * * /home/pi/nethound/run-probe.sh
```
That example runs the probe every 6 hours. Choose a different interval if your environment needs more or less frequent checks.
Reboot the Pi once and confirm it comes back online cleanly, stays on the protected network, and still has the scheduled job in place.
After the first scheduled run, check the log directory to confirm new output files are being created:
```
ls -lah ~/nethound/logs
```
Use those logs as your drift history. When the router, DNS policy, Wi-Fi, or ISP path changes, compare new logs to earlier ones.

How to validate the Raspberry Pi probe correctly

Confirm the Pi is on the same protected network path you expect the family devices to use.
Run the browser test from a user device on that same network and compare the result pattern to the Pi probe output.
Test again after router firmware changes, ISP swaps, access point replacements, or filtering policy edits.