Knowledge Site / Content Detail

How to Make Your VPS Invisible to Hackers (And Still Use It)

How to Make Your VPS Invisible to Hackers (And Still Use It)

• Matt Williams

If you’re running self-hosted apps like OpenClaw, Hermes, or any Docker-based services on a VPS right now, there’s a good chance your server is currently being scanned by bots looking for open doors. The scary part? You might not even know those doors exist.

Most VPS providers hand you a public IP address and quietly assume you know how to secure it. One misconfigured port bind or an accidentally exposed admin dashboard is all it takes to turn your machine into a playground for automated scanners. Before you know it, your server is interacting with systems you never intended it to touch.

The traditional response—stacking UFW rules, installing fail2ban, and moving SSH to a non-standard port—is essentially a small act of faith. You’re still exposed to the public internet; you’re just hoping the locks are strong enough.

There’s a better way: Close everything. Literally.

In this guide, we’ll walk through a “zero-trust” approach to VPS security using Tailscale. By the end, your server will be completely unreachable from the public internet, yet fully accessible to you and only you through a private, encrypted network.

The Problem with “Standard” VPS Security

The typical VPS setup follows a familiar pattern:

  1. Get a public IP
  2. Open port 22 for SSH (so you can manage the thing)
  3. Follow Docker Quick Start guides that map ports to 0.0.0.0 because it’s easier
  4. Tell yourself you’ll lock down that dashboard “later”

Here’s the brutal truth: automated scanners don’t care what your app does. They don’t distinguish between OpenClaw, Hermes, or your weekend side project. They simply scan for open sockets on public IPs and keep trying keys until something slips.

When you follow the traditional model, you’re constantly playing defense against the entire internet. But what if you could remove your server from the internet entirely—while still using it?

The Tailscale Solution: Join the Private Network

Instead of filtering traffic on an exposed server, we’re going to change the entire networking model. We’ll use Tailscale to place your VPS on a private mesh network (called a “Tailnet”) alongside your other devices. Your server gets a private IP and a Magic DNS name, and you connect through the Tailnet instead of the public address.

The philosophy is simple: Don’t ask “How do I protect this open port?” Ask “Why does this port need to be open at all?”

When you start with a “default deny” mindset, security becomes much more manageable.

Prerequisites

For this tutorial, we’ll use a Hostinger Ubuntu VPS (KVM2 plan recommended), though the principles apply to any provider. If you’re setting up a new machine, you can use hostinger.com/mattw and code MATTW for 10% off.

Phase 1: Lock Down the Box

Before we even install Tailscale, we need to ensure the server is completely dark to the public internet.

Step 1: Configure the Provider Firewall

In your Hostinger dashboard (or equivalent):

  • Navigate to the Security tab → Firewall
  • Set the default policy to Block all incoming traffic
  • Don’t worry—this won’t lock you out. You’ll still have access through the browser-based management console

Step 2: Secure SSH Access

While still in the dashboard:

  • Add your SSH public key to the server settings
  • This key will be available across all your Hostinger machines if you run a fleet

Step 3: Bootstrap the Server

Open the browser terminal and log in as root. Now run a bootstrap script to create a clean, hardened environment. A good bootstrap script should:

  • Create a non-root user with sudo privileges
  • Install essential tools (GitHub CLI, Node.js)
  • Set up a modern shell (like Fish) if desired
  • Harden SSH by disabling root login and password authentication entirely

This last point is crucial. Once you disable password authentication and root login over SSH, brute force attacks become impossible—but you can still access the machine through your provider’s console if needed.

You can run mine with this command: curl -fsSL -o /tmp/vpsbootstrap.sh "https://gist.githubusercontent.com/technovangelist/2d89196de66cd6ab3d30c35633d1601e/raw/e435a29583b99702a2da286af9febc43967b135f/vpsbootstrap.sh" && sudo bash /tmp/vpsbootstrap.shOr just go to the source of the script at https://tvl.st/vpsbs

Step 4: Verify the Lockdown

Before proceeding, test your work:

From another machine on your home network, try to ping your VPS’s public IP or connect to common ports. If everything is correct, these connections should fail completely.

Meanwhile, on the VPS itself, verify that local services can still communicate:

# Local connections should still work
curl localhost:your-app-port

When your server is “dark” to the outside world but functional internally, you’ve reached the perfect baseline.

Phase 2: Configure Tailscale Access Control

Now for the magic. We’re going to create a secure bridge into your server using Tailscale’s access control system.

Set Up Your ACLs

  1. Create a Tailscale account if you haven’t already
  2. Navigate to the Access Controls section in the admin panel
  3. Switch to the JSON Editor (it’s more powerful than the visual one)

Here’s where we’ll define who can talk to what. Tailscale uses tags and grants (the modern replacement for legacy ACLs) to control access.

Define Your Network Topology

First, create aliases for known machines:

{
  "hosts": {
    "my-desktop": "100.x.x.x"
  },
  "tagOwners": {
    "tag:prod": [],
    "tag:video": [],
    "tag:agent": []
  }
}

Leaving the owner array empty defaults ownership to the admin.

Create Granular Permissions with Grants

Now define what each tag can access using grants (not the old ACL syntax):

{
  "grants": [
    {
      "src": ["tag:prod", "tag:video"],
      "dst": ["tag:agent", "tag:prod", "tag:video"],
      "ip": ["*"]
    },
    {
      "src": ["tag:agent"],
      "dst": ["my-desktop"],
      "ip": ["tcp:11434"]
    }
  ]
}

What’s happening here?

  • Machines tagged prod or video can talk to everything on the network (full access)
  • Machines tagged agent (your VPS) can only talk to your desktop on port 11434 (useful for OpenClaw/Ollama)
  • If the grant doesn’t exist, the connection is denied by default

This means your VPS can reach exactly one service on one machine—nothing else. Not the internet, not your other devices, just that specific port.

Phase 3: Join Your Server to the Tailnet

Now the fun part—bringing your dark server into the light (of your private network only).

  1. In the Tailscale admin panel, click Add Device → Linux
  2. Crucial: Select the appropriate tag (e.g., tag:agent) before generating the script
  3. Copy the installation command and paste it into your VPS terminal
  4. Run the command

Within seconds, your server appears in your Tailscale dashboard. If you’ve enabled Device Approval (recommended), manually approve the new machine before it can communicate.

Phase 4: Connect and Verify

You should now be able to SSH into your server from your local machine—not through the public IP, but through the Tailscale network:

# Use the Tailscale IP or Magic DNS name
ssh [email protected]
# Or if you configured an SSH config alias:
ssh my-vps

Test Your Security

To verify the access controls are working:

  1. Check that your apps respond via the Tailscale IP
  2. Go back to your Tailscale admin panel
  3. Temporarily comment out the grant for your VPS
  4. Try connecting again—it should fail

This confirms that if Tailscale is your only path in, and your ACLs are correct, unauthorized access is mathematically impossible.

The Payoff: Sleep-Easy Security

Once this is set up, you gain something invaluable: removing entire categories of mistakes before they happen.

  • Accidentally exposed a Docker port to 0.0.0.0? Doesn’t matter—the firewall blocks it.
  • Forgot to secure that admin dashboard? It’s unreachable from the internet.
  • Compose file typo binds to every interface? Your VPS is still dark.

Your apps like OpenClaw or Hermes run exactly as expected, but they no longer sit on the open internet waiting for attention. If you want to go even further and block outbound internet access (forcing the VPS to use a proxy), that’s possible too—though it’s a topic for another day.

Conclusion: Change Your Security Mindset

The traditional approach treats VPS security as a filtering problem: decide which ports to open, then try to protect them. The Tailscale approach treats it as a network architecture problem: remove the server from the public internet entirely, then explicitly define the allowed conversations.

When you start asking “Why does this port need to exist?” instead of “How do I protect it?”, the rest of your configuration becomes obvious. Your VPS stops leaking through forgotten default settings, and you stop worrying about automated scanners hammering your SSH port at 3 AM.

This setup works for one machine or a hundred. Once you understand the pattern, every new host becomes a simple matter of tagging and joining.

Want to see the specific reverse proxy setup or how to configure OpenClaw behind this architecture? Watch the full video walkthrough for the visual details and additional pro tips on keeping your infrastructure truly private.

Stay secure, and happy hosting.