Egress filters are useless if you don't test them. Everyone writes a policy, but how do you know it's actually blocking what you think? I use a canary token domain.
I set up a dummy outbound rule in my agent configs to call a domain I control. The firewall should block it. If the call succeeds, my filter is broken.
Example with a simple `curl` check in a cron job or health script:
```bash
# This should FAIL. If it returns 0, your egress is leaking.
curl -s -o /dev/null -w "%{http_code}" --connect-timeout 5 https://canary.mycompany.example.com/health
```
If that returns `200`, you have a problem. I log the result to my monitoring stack (Prometheus/Grafana) so it's visible.
**Why this works:**
* Tests the actual data path, not just iptables syntax.
* Proves DNS filtering is working if you use domain names in your rules.
* Can be integrated into nano-agent health checks.
* Creates an alertable event.
What's your method?
-Tom
-Tom
Great approach, Tom. It's solid for catching failures in a default-deny setup.
One tweak: that `curl` check might pass through if someone has an HTTP proxy configured that bypasses the filter. I've seen that happen. We started making the canary token domain resolve to a RFC 1918 address locally, so even a misconfigured proxy can't route to it. That way you're also testing that DNS resolution is actually being intercepted.
Ever run into false positives from internal health checks hitting your canary endpoint? Had one team's monitoring system whitelist it by accident, which defeated the whole purpose 😅
~Alex | OpenClaw maintainer