I build defences, then spend my time trying to get past them.

A four-VLAN network on a Cisco Catalyst, routed by a virtualized pfSense firewall on a Proxmox host. Suricata inspects the workstation segment and writes EVE JSON into Redis; Logstash drains the queue into Elasticsearch under a least-privilege role scoped to its own indices.

Redis sits in the middle for a specific reason. Elastic publishes no log shipper for FreeBSD, which is what the firewall runs, so the usual agent path is closed. The buffer also absorbs outages: during a heap resize the search cluster was down for twenty seconds and the queue drained afterward with no gap in the data.

Segmentation is enforced by default deny between segments, with each exception written deliberately. The honeypot's path to the log cluster, for example, is scoped to one host rather than the whole segment, so adding a machine to that VLAN does not silently grant it a route into the SIEM.

The full build is documented at github.com/Mentalnuk3/homelab-security, including an incident log of every failure and how it was diagnosed.

• pfSense
• Suricata 7.0.8
• Elasticsearch
• Logstash
• Kibana
• Redis
• Proxmox
• Cisco IOS
• 802.1Q

The standard advice for a noisy sensor is to disable whole rule categories. Before doing that I checked the actual alert record: 76 alerts against 23,583 events, and every one of them explainable.

Seventy-two fired because a browser on the trusted segment visited a dynamic DNS provider while I was configuring my own VPN endpoint. Disabling that category would have removed 6,062 rules, including nine that match specific malware families using that same provider for command and control, in order to silence traffic I generated once, by hand.

Nothing was suppressed. The one signature that genuinely repeated was traced to a game launcher holding a long-lived connection, identified by pivoting from the alert to the TLS metadata for that destination. It was rate limited rather than suppressed, because the same signature also detects real evasion through overlapping TCP segments.

• Suricata
• ET Open
• JA3 fingerprinting
• threshold.config
• EVE JSON

A from-scratch VPN built during a DEF CON 33 workshop: a post-quantum handshake over TCP, an AES-256 key derived from it, and traffic carried over UDP through a TUN interface. Written in C++ against OpenSSL.

It runs in the isolated lab segment, and the placement is the point. This is unaudited cryptographic code that parses network packets. Software like that belongs behind a boundary that already exists and has already been tested, not one written specially for it.

Bringing it up took four separate fixes, including a diagnostic that had been checking UDP for a service listening on TCP. The command was correct, it ran cleanly, and its empty answer was worthless. I keep that one on the list because the lesson generalizes: a negative result from the wrong question proves nothing.

• C++
• OpenSSL
• TUN/TAP
• tcpdump
• systemd
• Debian

A Python service that ingests firewall logs, enriches each event with external IP reputation from AbuseIPDB, and passes the result through an LLM for behavioral summarization before indexing into Elasticsearch for review in Kibana.

The design constraint worth naming: an enrichment layer that hallucinates is worse than no enrichment, because it launders a guess into something that reads like a finding. Reputation data and model output are stored in separate fields so an analyst can always see which claim came from where.

• Python
• Gemini API
• AbuseIPDB
• Elasticsearch
• Kibana

WireGuard on the firewall, split tunnel, with a per-peer keypair and a pre-shared key layered on the handshake. The endpoint is a dynamic DNS hostname because the ISP assigns the public address by DHCP, and a hardcoded address fails silently while you are away from home.

DNS is not a monitoring system, so a watchdog records the public address on a schedule and logs loudly when it changes. It fails independently of the thing it watches. The DNS client itself was verified by falsifying its cache with a reserved documentation address and confirming it corrected itself, rather than by trusting that a hostname resolving today means the client still works.

• WireGuard
• pfSense
• Dynamic DNS
• cron
• PHP

Pi-hole handles blocklists, unbound does the recursion and forwards upstream over TLS with DNSSEC validation. The ISP sees encrypted traffic to one address instead of every domain the house looks up.

This does not make DNS private from the resolver, and saying otherwise would be marketing. It moves trust from the ISP to a chosen provider. That was a deliberate trade, not an oversight.

• Pi-hole
• unbound
• DNS-over-TLS
• DNSSEC
• Quad9

A tarpit that answers scanners with an endless generated stream, running in a container with a hard memory cap and a tight systemd sandbox. It presents itself as a conventional web server, because a scanner that fingerprints a honeypot simply moves on.

It replaced a full honeypot farm that wanted 16 GB of RAM to capture malware behavior I had no use for. On a residential connection the interesting question is who is scanning and for what, not what their post-exploitation tooling does. Choosing the smaller tool because it matches the threat model is the judgment worth defending.

• Go
• LXC
• systemd hardening
• Filebeat
• Elasticsearch

A reinforcement learning agent on a Raspberry Pi Zero W that passively surveys wireless networks and captures handshakes for offline cryptanalysis, used to audit my own environment.

Separately, a Tor middle relay on a Raspberry Pi 4B with throughput monitored through Nyx. Middle relays carry traffic between nodes and never touch the open internet, so they contribute capacity without the exposure that comes with running an exit. Both are currently offline. The relay is being rebuilt inside the lab's isolated segment.

• Raspberry Pi
• bettercap
• A2C / reinforcement learning
• Tor
• Nyx