{"id":1552,"date":"2026-10-31T05:10:10","date_gmt":"2026-10-31T05:10:10","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1552"},"modified":"2026-10-31T05:10:10","modified_gmt":"2026-10-31T05:10:10","slug":"first-week-security-checklist-new-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/first-week-security-checklist-new-vps\/","title":{"rendered":"First-Week Security Checklist After You Spin Up a New VPS"},"content":{"rendered":"

TL;DR \/ Summary:<\/strong> A fresh VPS is a blank machine on the public internet\u2014bots will find it within minutes. Spend the first week on access hygiene, updates, firewalls, and backups before you chase pretty dashboards. Use virtualserversvps.com<\/a> while you compare plans, then harden whatever you buy.<\/p>\n

Assume the clock starts at provision<\/h2>\n

Automated scanners hit new IP addresses constantly. If you leave password root SSH open \u201cjust for tonight,\u201d that night is enough. Treat day zero as incident-prevention day, not theme-install day. Sites can wait an hour; open admin ports should not.<\/p>\n

Write your checklist in a notes app before you click Create. Working from memory under excitement is how people skip a step. Check items off visibly so you know what remains.<\/p>\n

Access: keys, users, and sudo<\/h2>\n
    \n
  1. Create a non-root sudo user on first login.<\/li>\n
  2. Install your SSH public key; confirm key login works in a second terminal before disabling password auth.<\/li>\n
  3. Disable root SSH login once the sudo user is proven.<\/li>\n
  4. Change the SSH port only if you understand the operational cost; a firewall allowlist helps more than obscurity alone.<\/li>\n<\/ol>\n

    If you use a provider panel console, keep it bookmarked for lockout recovery. Losing SSH without console access turns a small mistake into a rebuild. Store recovery codes for the panel in a password manager, not a chat log.<\/p>\n

    Patch cadence that is boring on purpose<\/h2>\n

    Run system updates on day one. Enable unattended security updates for the OS if your distribution supports them cleanly, or schedule a weekly manual window you will actually keep. Pin application runtimes deliberately\u2014surprise major upgrades on a Friday night are not a strategy.<\/p>\n

    Document package sources. Random third-party PPAs installed to \u201csave time\u201d become mystery risk later. Prefer vendor repos you can name in one sentence.<\/p>\n

    Firewall and exposed services<\/h2>\n

    Default-deny inbound. Allow SSH from your IP if it is stable, or from a small set of jumps. Allow 80\/443 only when a web stack is ready. Database ports should not face the world; bind to localhost or a private network.<\/p>\n

    List listening ports after each install. New teams are often surprised by admin UIs that opened themselves. Close what you cannot explain. Re-check after installing panels, agents, or \u201chelper\u201d daemons.<\/p>\n

    Backups before content nostalgia<\/h2>\n

    Configure snapshots or off-box backups before you import production data. Test a restore into a temporary hostname once. An untested backup is a rumor. Keep at least one copy that ransomware on the VPS cannot encrypt\u2014object storage with separate credentials works well for solo operators.<\/p>\n

    Write the restore steps while you still remember them. Outages are bad times for archaeology.<\/p>\n

    TLS, mail, and reputation side quests<\/h2>\n

    Terminate TLS with a real certificate once DNS points at the box. Avoid sending campaign email directly from a tiny VPS unless you enjoy deliverability pain; use a transactional provider. Set reverse DNS if your host allows it and you must send any mail at all.<\/p>\n

    Monitor disk and inode usage from week one. Log files and failed deploys fill disks quietly. A 90% disk alert is cheaper than a silent outage.<\/p>\n

    Logging and alerts without noise<\/h2>\n

    Enable basic auth logs and a disk-space alert in the first week. You do not need a full observability stack on day two, but you do need to know when SSH sees a burst of failures. Route alerts to a channel you actually read\u2014email you ignore is not monitoring.<\/p>\n

    Time-sync matters for logs. Confirm NTP\/chrony is healthy so incident timelines make sense later.<\/p>\n

    Application layer after the OS<\/h2>\n

    Once the box is dull and patched, lock the app: strong admin passwords, 2FA where available, least-privilege database users, and no default install screens left public. Many compromises skip fancy kernel exploits and simply log into forgotten admin URLs or exposed panels.<\/p>\n

    Remove sample sites and default virtual hosts. Attackers love the paths tutorials forget to delete.<\/p>\n

    People checklist<\/h2>\n