Say what dejima's notifications cost, before someone pays it #12
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: dejima/dejima-devbox-hardener#12
Reference in New Issue
Block a user
Summary generated by LLM agent
dejima's notification feature needs the devbox to reach an ntfy server, and an ntfy server on the operator's own network is one of the things rules 7 to 10 drop. Nothing in either runbook said so, and the failure is silent: the post goes nowhere, the only trace is a line in a user unit's journal, and the feature reads as switched off rather than as firewalled.
The rule that fixes it is one line, and it is the widest exception on the page. On most home networks ntfy is not a host, it is a name on the reverse proxy that fronts everything else, so its address is the proxy's address and its port is 443. These rules match an address and a port; they cannot see the Host header or the TLS SNI, which are the only things that distinguish one vhost from another. A rule entered as "allow ntfy" therefore grants every service that proxy routes, and the four DROPs stop meaning what the rest of the page says they mean. Nothing catches it afterwards:
dejima-devbox-auditprobes the gateway, the gateway is still dropped, and PASS keeps being reported on a devbox that can now reach the whole proxy.So the new section in
proxmox/README.md§3 states the requirement briefly and spends most of its length on that trap. It gives the two shapes that avoid it, both of which work by making ntfy a destination the firewall can actually name: a dedicated port on the proxy (simpler, and existing vhosts on 443 do not inherit it), or a dedicated address (same URL for every client, butlisten 443 sslbinds the wildcard, so every other vhost answers on the new address until each one is pinned off it). There is an nginx block for the first shape, three probes to run from the VM where the third one is what actually says whether it worked, and an ntfy token scoped to publish on its own topics, which is the bound the firewall has no way to express.The section also says where the notify service runs, because it decides what else applies: it is a systemd user service on the VM rather than something inside the container, so dejima's own egress allowlist never sees the post. There is no second list to update, and equally nothing one layer in that narrows this pinhole if it is cut too wide. That correction came back from following the section on a real box, and is the second commit here.
The rule joins the "Values that must agree" table, the exception-creep hazard points at it as the worked example, and the "Rules 3-6 are the entire remaining LAN exposure" claim now accounts for it.
docs/building-a-devbox.mdgets a short guest-side pointer after installing dejima, since that is where someone turning notifications on will be.proxmox/firewall.fw.templatecarries the rule as an optional placeholder line above the DROPs with the same warning, and its "two hosts, however many ports" line now says when it is three.Tested with
bats test/: 98 passing, including the address-leak guard (everything added is a placeholder or anexample.comname) and the link and anchor checks over the new cross-references.