Reconcile VPS firewall policy for FTP, SSH, Telnet, and SMTP honeypot ports

[Xore]

Found in docs/CGNAT-DEPLOYMENT.md §VPS deployment.

vps/portbridge forwards public TCP 21, 22, 23, and 25 to Dionaea, Cowrie, and Multipot, but vps/honeypot-firewall.sh does not allow those ports. The documentation explicitly leaves unresolved whether that is intentional, configured elsewhere, or firewall drift.

Scope

• Inspect the live VPS UFW/routing state and determine whether each listener is intentionally reachable.
• Resolve the port-22 collision with real administrative SSH on 2222 without weakening management access.
• If these honeypots should be public, add explicit idempotent firewall rules and comments.
• If any should remain closed/manual, encode and document that decision so portbridge and firewall configuration do not silently disagree.
• Add a static check comparing intended public portbridge listeners with firewall policy, including justified exceptions.

Acceptance

• A documented decision exists for TCP 21, 22, 23, and 25.
• External reachability is tested from outside the VPS, not inferred from a listening socket.
• Admin SSH on 2222 remains reachable throughout rollout and rollback.
• The firewall script stays idempotent and does not expose dashboard/investigation services directly.

Production firewall changes require explicit authorization and a preserved admin session.

[Xore]

Starting work on this (Claude Code session).

[Xore]

Resolved in 1ba9a1c.

Finding: this was firewall-policy drift, not an intentional decision to keep 21/22/23/25 closed or manual. Live ufw status on the VPS already had all four ports allowed (21/tcp, 22/tcp, 23/tcp, 25/tcp, ALLOW IN Anywhere), and portbridge (network_mode: host) was already listening on all four and forwarding to Dionaea (21), cowrie (22/23), and multipot (25) per RULES in vps/docker-compose.yml. vps/honeypot-firewall.sh — the idempotent script meant to encode the policy — just never had these four added when the sensors were wired up, so the live state and the repo's source of truth for it had silently diverged.

Admin SSH (2222): confirmed unaffected throughout. It's a separate host listener (sshd on 0.0.0.0:2222/[::]:2222), opened by hand per docs/CGNAT-DEPLOYMENT.md step 2, outside both RULES and honeypot-firewall.sh. Portbridge's 22 only exists because step 1 already moved real admin SSH off 22 first.

External reachability — tested from outside the VPS (from the homeserver, a separate network, via raw TCP connect to the VPS's public IPv4), both before and after applying the fix:

• 21, 22, 23, 25: OPEN
• 2222 (admin SSH): OPEN throughout

Changes:

• vps/honeypot-firewall.sh: added 21 22 23 25 to the TCP port list, with a comment explaining the drift and the 2222 non-collision.
• vps/check-firewall-portbridge-sync.sh (new): statically diffs portbridge's RULES env var against honeypot-firewall.sh's port lists (both directions, TCP+UDP), so this can't silently drift again. Verified it fails when the fix is reverted and passes both against the repo copy and the live /root/vps/ deployment.
• docs/CGNAT-DEPLOYMENT.md: replaced the "worth a follow-up look" hedge with the resolved decision and a pointer to the new check.
• Applied on the live VPS: honeypot-firewall.sh re-run was fully idempotent (Skipping adding existing rule for every port, both v4 and v6) — no live behavior change, only the script now matches reality.

Also noticed, out of scope for this issue: live ufw status has 8080/tcp, 8090/tcp, and 8091/tcp allowed with no process currently listening on any of them (checked via ss -tlnp), and none of them appear in portbridge's RULES at all — they look like leftovers from an earlier socat-hp-http/socat-hp-dashboard/socat-hp-tanner/socat-static wiring that's since been superseded (those containers are on the isolated proxy bridge network today, not host-published). 8082 (socat-hp-snare) is in the same boat but isn't even open. I'll file a separate issue for that rather than touch it here.

Moving on to #121 next per the user's instruction.