📖 Daily Learning Drip

DNS is your first (and cheapest) firewall

DNS is your first (and cheapest) firewall. On OpenWrt, swap your resolver for Unbound and enable DNSSEC validation — it cryptographically verifies that the DNS answers you get haven't been tampered with en route. Then point Unbound at a blocklist like StevenBlack's hosts file (ad/tracker/malware domains) loaded via conf.d or the blocklist package. A single family of IoT devices — a cheap camera or a smart plug — phoning home to a malicious domain gets silently NXDOMAIN'd at the router, before it ever reaches your LAN. No per-device agents, no firewall rules per host. The entire network gets the same protection by default.

Concrete example: In OpenWrt's LuCI, go to Services → DNS Forwarder, set Upstream Resolver to 1.1.1.3 (Cloudflare DoH with DNSSEC), enable DNSSEC validation, and under Additional Options add -d to enable remote-control for script access. Then on the shell:

# Fetch a consolidated blocklist into OpenWrt
wget -O /etc/unbound/blocklist.conf https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
# Reload Unbound
/etc/init.d/unbound restart

Any device on your network — phone, laptop, HA sensor — is now protected from known-bad domains without touching it.

AI automation tie-in: Have a Hermes cron job run weekly that curls the abuse.ch Feodo Tracker IP list, cross-references it against your Unbound query log (/var/log/unbound.log), and sends you a Telegram message naming any internal host that tried to reach a C2 server. That turns passive DNS blocking into active threat detection — the same OpenWrt + DNS stack now feeds an AI agent that alerts you before something goes wrong.

Network Segmentation on OpenWrt — Your IoT Can't Touch Your Workstation

The DNS blocklist from yesterday stops malicious domains, but it doesn't stop a compromised smart plug from scanning your laptop. If every device sits on the same subnet, a single breach spreads sideways instantly. The fix is VLANs — virtual LANs that split one physical switch into isolated broadcast domains at the router level.

How it works in OpenWrt: Create two VLAN interfaces (e.g. lan and iot) under Network → Interfaces, assign each a different subnet (192.168.10.1/24 for trusted, 192.168.20.1/24 for IoT), and attach each VLAN to a separate switch port. Then in Network → Firewall, add a forward rule that drops traffic from the iot zone to the lan zone:

# Block IoT → LAN traffic at the firewall
uci add firewall rule
uci set firewall.@rule[-1].name='Block-IoT-to-LAN'
uci set firewall.@rule[-1].src='iot'
uci set firewall.@rule[-1].dest='lan'
uci set firewall.@rule[-1].target='DROP'
uci commit firewall
/etc/init.d/firewall restart

Your smart camera can still reach the internet (and get NXDOMAIN'd by Unbound), but it can never SSH into your NAS or ping your workstation. Even if it runs a zero-day exploit, the blast radius is one VLAN — not your entire home.

Concrete example: On a GL.iNet router running OpenWrt, tag port 3 as VLAN 20 (IoT) in Switch → VLAN Configuration. Plug your security cameras into port 3. In Interfaces, create a new interface on VLAN 20 with protocol static and IP 192.168.20.1/24. In Firewall, assign the new interface to the iot zone and add a rule rejecting everything from iot to lan. Result: cameras can update firmware over the internet, but can't talk to your laptop — no agent software required on any device.

AI automation tie-in: Run a Hermes cron job that checks /var/log/firewall.log daily for repeated DROP hits from the IoT zone, and Telegram-alert you if a specific IoT MAC address starts hammering blocked destinations — that's early-warning intrusion detection without any cloud service.