Some things to consider when deploying a server
Published: 2026-04-09 (first published as "Server Setup Checklist Starter")So hypothetically, I've inhereted a server that manages some health data, but in this instance this server just does reporting. Nothing crazy, no HIPPA compliance, but still, needs to be secure.
To start, let's omit some key details in case Anthropic's new cybersecurity model sees this article and then
goes rogue - not the best idea to give out the IP, OS, services running, firewall used, method of
authentication, or org that this belongs to for OPSEC reasons.
Let's say, hypothetically then, that this is an server running Ubuntu 22.04 LTS that uses VNC over
Wireguard, runs MySQL server and a proprietary reporting server in Java. Seems pretty normal, sounds
backoffice enough.
This may be fine in a backoffice with proper network segregation - it's own VLAN, ID/P solution, a router
with firewall with a limited but straight shot to the internet with only the ports enabled that are
absolutely nessesary - but this is not.
Hypothetically, it's hosted on a relatively cheap but older web hosting provider that doesn't have the best
security and occasionally may hire from overseas to do Tier 1 tasks. Sounds like a fine business move,
right?
Think again.
Without going into too much detail, this server is pretty much wide open. It's got a lot of ports open, it's got a lot of services running, it's got more than one user out of the box with full Admin privileges, and default passwords for each that the hosting provider reuses amongst clients.
What to do first?
- Change all default passwords. It's obvious, low hanging fruit. Just do it. And use a password manager.
- Remove unused users.
- Disable login as root or Administrative accounts.
- Add a barely-enough privileged user for the service you're running. Don't give any more access that necessary. We're going for RBAC, principle of least privilege, and zero trust here. This isn't 2003.
- Add an unprivileged user account for daily tasks, setup, and monitoring. This is the account you will use to configure and get things up and running. You'll need to sudo or (in Windows environments) run as admin and do the UAC thing, but you won't login as admin.
- Use a secure VPN that encrypts your traffic and doesn't require an external port punched in a firewall. It's called NAT transversal. Checkout Tailscale.
- Restrict your VNC/RDP connections to ONLY accept on the VPN interface.
- Use key-based authentication for SSH/RDP/VNC and keep password login only as a second factor. Consider using a hardware based token for authentication, such as a Yubikey.
- Update the server completely.
- Install your services, and don't skip security configurations. Iterate on the security setup, making notes as you go that SOMEONE ELSE will be able to reference later. You may not be the guy fixing it.
- Regularly review logs and monitor for suspicious activity. All that security does almost no good if someone at your hosting provider has access to your stuff. When configuring your logging, consider using a SIEM (Security Information and Event Management) solution so you don't just send everything to an unmonitored shared mailbox and have to wade through a million emails or search for ("you've been hacked lolz").
- Don't run an email relay server. No reason to. Go out to an external provider. Your domain reputation will thank you.
Remember,
"An ounce of prevention is worth a pound of cure."
If you want to add to the list, go ahead and contact me through the CLI at the bottom of the article list on the homepage.