From Vulnerable VPS to Automated Fortress — Part II

Part I was the diagnosis: what a typical unmanaged VPS looks like, why it's a problem, and the principles that guide hardening. Now we get into the actual work. This part is the execution plan — commands in order, with context, explained so you understand what each one does and why it goes where it goes. This isn't a copy-paste recipe. It's a master blueprint you can adapt to any server from day zero.

The Master Script: From Zero to Fortress in 5 Phases

Order matters. You can't configure the firewall before you create the users. You can't automate reports before you have the directory structure in place. Each phase sets the foundation for the next one. Follow the order and the result is predictable. Skip steps and you end up with a half-hardened server — which is almost worse than an unprotected one, because it gives you false confidence.

Phase 1: Cleanup — Getting Rid of the Bloatware

Before you build anything, you clean. A freshly provisioned VPS comes with services you never asked for and don't need: print management, local network discovery, modem management. In a cloud environment these serve no purpose, but they do add attack surface. First step: update the system to its latest state, then strip out everything that has no business being there.

That third command is more significant than it looks. If the server had a graphical interface installed — common on VPS instances that started as personal labs — this tells systemd not to load it on the next boot. Everything else keeps working exactly the same, but without pulling in X11, the display manager, and all their dependencies. Less RAM consumed, smaller attack surface, more focused system.

Phase 2: Building the User Hierarchy

This is where the real security architecture begins. The premise is straightforward: no task should have more permissions than it strictly needs to get done. We create four users with very specific roles, and only one of them gets sudo access.

The services and pentest users have no sudo access. That's deliberate. If a Docker container gets compromised and the attacker lands in the services user, they're in a dead end: can't install software, can't modify system configs, can't escalate. The cage works.

Phase 3: Directory Architecture Under /opt

A server without structure is a server you can't defend or audit properly. If you need to know tomorrow what's in production, what's in testing, and where the logs are, the answer should be immediate. The /opt structure is that answer.

The -p flag on mkdir creates the entire hierarchy at once, including intermediate directories that don't exist yet. The chown -R applies the ownership change recursively to the whole /opt tree. From this point, labadmin can work freely inside that structure without needing sudo for every file operation.

/opt/
 ├── services/          # Production applications
 │   ├── web/           # Web services and frontends
 │   ├── api/           # Backends and APIs
 │   └── proxy/         # Nginx configurations
 ├── lab/               # Lab and research environments
 │   ├── redteam/       # Offensive tools
 │   ├── blueteam/      # Defensive tools
 │   ├── malware/       # Samples for analysis (isolated)
 │   └── poc/           # Proof of concept testing
 ├── tools/             # Maintenance scripts and binaries
 └── data/              # Persistent data
     ├── logs/          # Centralized logs
     ├── captures/      # Network traffic captures
     └── dumps/         # Memory or DB dumps

Phase 4: Network Hardening — Firewall and VPN

This is the phase with the most visible impact. Before these commands run, the server is reachable from anywhere on the internet across multiple ports. After, only three public doors exist. Everything else disappears off the map.

The order here is critical. Define the rules first, then enable the firewall. If you do it the other way around and forget to allow port 22 before running ufw enable, you'll lock yourself out of your own server over SSH. Tailscale gets installed before UFW is enabled because its install script needs internet access to download the binaries.

Once active, Portainer, databases, and any admin panel no longer need a public port. They're only reachable via the Tailscale network IP. To Shodan, to Nmap, to any external scanner — those services simply don't exist.

Phase 5: Automating Reports with Cron

The last pillar is observability. A server that doesn't report what's happening is a server you're administering blind. The ssh-summary.sh script is the minimum viable solution: an automatic daily summary that lands in your log without you having to do anything.

That last line deserves some attention. The crontab -l 2>/dev/null lists the existing scheduled tasks, sending any errors to nowhere in case the crontab is currently empty. The output gets combined with the new line via a pipe, and everything is passed to crontab - which rewrites the full crontab. This is the safe way to add a task without wiping out the ones you already have.

Technical Glossary: The Language of Hardening

If you've made it this far and there are terms that kept showing up in the posts without ever fully clicking, this section is for you. These aren't Wikipedia definitions — each one is grounded in exactly what we've been doing throughout this series.