~15k
Domains
blocked daily
blocked daily
100%
Devices
protected
protected
Pi-hole
DNS sinkhole
engine
engine
SIEM
Logs piped into
Mini-SOC
Mini-SOC
01. Project Overview
A network-level DNS sinkhole deployed on a Raspberry Pi Zero 2 WH, intercepting DNS queries across the entire home network before they resolve. Every device — phones, laptops, smart TVs, IoT sensors — is protected automatically with zero per-device configuration required.
Beyond ad-blocking, DNS query logs feed directly into the Mini-SOC Splunk pipeline. When a device queries a flagged domain, the event appears alongside Suricata IDS alerts — enabling correlation between DNS behaviour and network intrusion data.
"A single Raspberry Pi transforms from an ad-blocker into a network-wide threat sensor, feeding real intelligence into a production SIEM."
02. Technical Specifications
HARDWARE
Raspberry Pi Zero 2 WH
16 GB MicroSD card
5V / 2.5A power supply
Ethernet via USB adapter
SOFTWARE
Raspberry Pi OS (Debian-based)
Pi-hole v5.x
Lighttpd web server
NetworkManager
NETWORK CONFIG
Static IP: 10.0.0.153
Gateway: 10.0.0.1
Upstream DNS: Cloudflare 1.1.1.1
Admin UI: 10.0.0.153/admin
SECURITY
Fail2Ban installed
SSH key auth only
DNS-over-HTTPS enabled
Query logging → Splunk
03. Installation Process
STEP 01 — SYSTEM PREPARATION
Initial setup & network discovery
Scan the local subnet to find the Pi's DHCP address, then SSH in to begin configuration.
sudo nmap -sn 10.0.0.0/24
ssh pi@10.0.0.153
STEP 02 — SYSTEM UPDATE & TOOLS
Harden and update before installing anything
Change the default password, pull all OS updates, and install essential utilities. Never install software on an unpatched system.
passwd
sudo apt update && sudo apt full-upgrade -y
sudo apt autoremove -y
sudo apt install -y curl git htop vim net-tools
STEP 03 — STATIC IP VIA NETWORKMANAGER
Pin the Pi's address so router config stays stable
A static IP is critical — if the Pi's address changes, the router's DNS pointer breaks and the whole network loses filtering.
# Add to /etc/dhcpcd.conf:
interface eth0
static ip_address=10.0.0.153/24
static routers=10.0.0.1
static domain_name_servers=1.1.1.1 8.8.8.8
sudo systemctl restart dhcpcd
ip -4 addr show eth0 # verify
STEP 04 — INSTALL PI-HOLE
One-line automated installer
The installer walks through interface selection, upstream DNS, blocklists, web UI, and logging. Selections: eth0, Cloudflare (1.1.1.1), StevenBlack blocklist, query logging enabled.
curl -sSL https://install.pi-hole.net | bash
STEP 05 — ADMIN PASSWORD & ROUTER DNS
Lock the web UI and redirect all network DNS
Set the web UI password, then point the router's DHCP DNS field to 10.0.0.153. All devices on the network automatically use Pi-hole from this point.
pihole -a -p # set admin passwordRouter admin panel → DHCP settings → Primary DNS: 10.0.0.153 → Save & reboot router.
STEP 06 — BLOCKLIST TUNING & WHITELIST
Reduce false positives, add custom threat intel lists
Default lists block ~100k domains. Fine-tuning prevents legitimate services from breaking. Custom entries from AbuseIPDB and OTX feeds supplement the defaults.
pihole -g # update blocklists
pihole -w domain.com # whitelist a false positive
pihole -t # live DNS query log (tail mode)
STEP 07 — SECURITY HARDENING
Fail2Ban + SSH key-only authentication
Fail2Ban monitors /var/log/auth.log and bans IPs after repeated SSH failures. SSH key authentication was already configured; password auth is disabled.
sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
STEP 08 — VERIFY & TEST
Confirm DNS resolution is working through Pi-hole
Query a known ad server — it should return 0.0.0.0 (blocked). Legitimate domains must resolve normally to confirm no false positives in the critical path.
nslookup google.com 10.0.0.153 # should resolve
nslookup doubleclick.net 10.0.0.153 # should return 0.0.0.004. Results
- Network-wide ad and tracker blocking across all devices — phones, laptops, smart TVs, IoT sensors
- ~15,000 DNS queries blocked daily from default + custom blocklists
- Noticeable reduction in page load times — ad scripts are never fetched
- DNS query log feeds into Mini-SOC Splunk index for SIEM correlation
- Regex filtering catches DGA-pattern (algorithmically generated) domain queries
- Custom blocklist additions: known C2 domains from AbuseIPDB and OTX feeds
SIEM INTEGRATION —
DNS query logs are forwarded via rsyslog to Splunk on the Windows PC. Blocked domain events appear in the same dashboard as Suricata IDS alerts, enabling detection of devices querying known-bad domains even when the payload is never downloaded.
05. Key Takeaways
- DNS-level filtering intercepts threats before any network connection is established — earlier in the kill chain than IDS
- A single Raspberry Pi adds negligible latency (<2ms) while protecting every device on the network
- Integrating Pi-hole logs into Splunk transforms a simple ad-blocker into a network visibility tool
- Regular blocklist updates are essential — threat actors rotate domains frequently, static lists decay
- Whitelisting requires ongoing attention — aggressive blocklists break legitimate services regularly
06. Future Enhancements
- Automated feed from AlienVault OTX: add newly flagged domains to Pi-hole blocklist daily
- ML-based domain classification to catch DGA domains not yet in any blocklist
- Network segmentation with pfSense — different DNS policies per VLAN (IoT vs. laptop vs. guest)
- Dashboard in Splunk showing Pi-hole block rate alongside Suricata alert volume over time