New Report Helps Users Bring Up a Secure Virtual Private Server Under Debian 11
Self-managed Virtual Private Servers (VPS) have made new systems cheap for technically knowledgeable people to deploy, whether for hosting a personal (“vanity”) domain, to create a remote distributed node from which to collect data, for use in working with DNSDB API or the Security Information Exchange data, or for other purposes. However, while you can get a Un*x virtual private server cheaply and easily today, there are still MANY details associated with bringing up a functional and secure system. Our new report is meant to help users bring up a secure-yet-still-usable system. We’re sharing the content in the new report because one of our company’s explicit objectives is to “help make the Internet a safer place.”
That said, let us be clear: even if a reader diligently follows ALL of the advice in the new report, no one can guarantee that the resulting system will always be “perfectly safe and secure.” There may be things we’ve inadvertently overlooked (or intentionally excluded), latent undiscovered vulnerabilities, novel new attacks, typos on our part (or yours), untrustworthy staff at the hosting provider, or many other issues that may keep a relatively-well-configured systems from being “fully secure.” After all, as notable cybersecurity expert Gene Spafford (https://en.wikipedia.org/wiki/Gene_Spafford) once said, “The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards — and even then, I have my doubts.”
We can’t get that “Spafford-like” level of security. We need systems that authorized users can use to get their work done. Nonetheless, the steps outlined in the new report may help you be at least somewhat more secure.
To be comfortable leveraging the new report, you’ll need to be technically savvy. If you’re NOT a technical person who likes to run his or her own system, this is not the right document for you. We’re explicitly assuming that you do NOT need a “control panel” environment, for example. Similarly, if you’re not interested in a Un*x-based approach (using Debian Linux), perhaps preferring a MS Windows-based system instead, this is also NOT the right document for you.
You may also wonder why we chose “Bullseye” rather than the latest Debian release, “Bookworm,” for the VPS operating system. The answer has two parts: security and resources. Some VPS may have quite modest resources available, including perhaps as little as 512MB of RAM. “Bullseye” recommends 512MB as a minimum (see https://www.debian.org/releases/bullseye/amd64/ch03s04.en.html), and thus would fit in that configuration, while Bookworm’s absolute minimum for a standalone system is 1024MB (see https://wiki.debian.org/DebianEdu/Documentation/Bookworm/Requirements). Additionally, Bullseye has been available since 2021 and has undergone continual reviews, bug fixes, and security updates, ensuring that it is now widely tested and “battle worn.” It will continue to be fully supported and updated by Debian until June, 2026.
Despite our quite-limited VPS hardware, we’ll demonstrate…
- Basic authoritative DNS records that should be created in one’s DNS provider’s control panel
- Bringing up sshd for encrypted remote access with public key authentication and Yubikey MFA support
- Getting automatic patching set up
- Setting up ufw (with ipsets) for firewall service
- Using NTP for time synchronization
- Configuring and running a DNSSEC-enabled recursive resolver service
- Installing Postfix for email, complete with SPF/DKIM/DMARC and opportunistic TLS
- Setting up an NGINX web server to deliver static web pages with Let’s Encrypt free TLS certificates
- While malware’s not the problem for Un*x systems that it is for Windows, we do also install two anti-rootkit products and a system auditing tool as part of the build
- Finally, we address the reality that having only 512MB forces us to forgo many classic security tools and services we really wish we could have shoe-horned in, including staples such as ClamAV and SpamAssassin.
No security document can guarantee a “bulletproof” system, but we hope this document will at least provide a solid and usable outline and “launching off point” for those setting up a basic VPS.
