Issues / #27
Lock down nimsforest VPS: Tailscale for SSH, Cloudflare-only HTTPS
accepted
improvement
Project: nimsforest
Reporter: anonymous
17 Mar 2026 12:06
Description
When setting up a new Hetzner VPS, the default security posture should be:
1. Install Tailscale immediately
2. Lock down the firewall to only accept:
- HTTPS (443) from Cloudflare IPs only (for web traffic)
- SSH (22) from Tailscale IP only
3. No direct public access to the VPS
Rationale: A VPS is exposed to the entire internet. By default, only the operator should be able to reach it (via Tailscale), and only Cloudflare should be allowed to proxy web traffic. This should be a standard part of every nimsforest VPS provisioning workflow.
Never expose a VPS directly to the public internet without a proxy like Cloudflare in front.
1. Install Tailscale immediately
2. Lock down the firewall to only accept:
- HTTPS (443) from Cloudflare IPs only (for web traffic)
- SSH (22) from Tailscale IP only
3. No direct public access to the VPS
Rationale: A VPS is exposed to the entire internet. By default, only the operator should be able to reach it (via Tailscale), and only Cloudflare should be allowed to proxy web traffic. This should be a standard part of every nimsforest VPS provisioning workflow.
Never expose a VPS directly to the public internet without a proxy like Cloudflare in front.
Comments (3)
nebula
17 Mar 2026 12:06
Grooming: recategorized from bug→improvement, set priority to medium, moved project from hydrabody→nimsforest, rewrote truncated title, restructured description into actionable steps
Nebula's reasoning: This is not a bug — it's a security hardening proposal for the VPS provisioning workflow. Moved to nimsforest since that's the infrastructure being discussed. Priority medium because security matters but this is aspirational (current setup with WireGuard/UFW already provides protection). Rewrote the title from a truncated sentence into a clear summary, and restructured the stream-of-consciousness description into a concrete checklist that can be implemented.
Nebula's reasoning: This is not a bug — it's a security hardening proposal for the VPS provisioning workflow. Moved to nimsforest since that's the infrastructure being discussed. Priority medium because security matters but this is aspirational (current setup with WireGuard/UFW already provides protection). Rewrote the title from a truncated sentence into a clear summary, and restructured the stream-of-consciousness description into a concrete checklist that can be implemented.
nebula
18 Mar 2026 11:02
Plan review: rejected — High risk security infrastructure change
Nebula's reasoning: This modifies SSH access policies and firewall rules for production servers. A misconfiguration could lock out all SSH access entirely. Security infrastructure changes of this scope require direct human oversight and testing.
Nebula's reasoning: This modifies SSH access policies and firewall rules for production servers. A misconfiguration could lock out all SSH access entirely. Security infrastructure changes of this scope require direct human oversight and testing.
nebula
18 Mar 2026 11:17
Plan review: accepted
Nebula's reasoning: The revised plan only modifies scripts and documentation in the nimsforest2 repo, submitted as a PR. No servers are touched — actual firewall and SSH changes are a separate, human-executed step. The code changes are bounded and reviewable.
Nebula's reasoning: The revised plan only modifies scripts and documentation in the nimsforest2 repo, submitted as a PR. No servers are touched — actual firewall and SSH changes are a separate, human-executed step. The code changes are bounded and reviewable.