Five security basics for a new Linux server

A new Linux server is reachable from the whole internet from the minute it starts, and automated scanners begin trying its login within minutes. Five steps stop most of what they try: sign in with SSH keys instead of passwords, work as an ordinary user rather than root, run a firewall that allows only what you use, let security updates install themselves, and keep tested backups with two-factor sign-in on the account that controls the server. The large cloud providers' own first-steps guides start the same way.

Why the first hour matters

A self-managed virtual server, such as a Noiz Cloud server, arrives as a clean install of Ubuntu or Debian with full root access over SSH. Everything from there is yours: the operating system, its updates, the firewall, the users, the SSH keys and the backups. That freedom is the point of a server of your own, and it also means nobody else is closing the doors for you.

The UK government's Cyber Essentials scheme, a widely used baseline for small organisations, names five controls: firewalls, secure configuration, security updates, user access control and malware protection. The five basics below line up with it.

1. Sign in with SSH keys, and stop root logging in with a password

A password can be guessed, and a server on the internet is guessed at constantly. An SSH key pair replaces it: a private key that stays on your computer and a public key that you place on the server. Without the private key, there is nothing to guess.

Once your key works, turn off password logins and stop root signing in directly. Akamai's (Linode's) guide sets PermitRootLogin no and PasswordAuthentication no in the SSH server's settings. Protect the private key itself with a passphrase.

Test that you can sign in with the key in a second window before you close the first. Locking yourself out of a new server is a common first mistake.

Our help articles How to set up SSH key-based authentication on a Linux server and Where SSH keys are stored in Linux go through it step by step.

2. Work as an ordinary user with sudo

Root can do anything, including destroy the server with one mistyped command. DigitalOcean's guide discourages using root for everyday work for exactly that reason, and Akamai's tells you to use a limited user account at all times. Create a user for yourself, give it sudo rights, and use sudo only for the commands that need it.

The same idea applies to people and tools: each one gets its own account and its own key, so you can see who did what and remove one without disturbing the others.

Initial server setup with Ubuntu on a Noiz VPS covers creating the user.

3. Turn on a firewall that allows only what you run

A firewall decides which connections reach the server. Akamai's advice is the whole rule: allow only the traffic you need and deny everything else. On a new web server that usually means SSH, HTTP and HTTPS, and nothing more.

On Ubuntu and Debian, UFW (Uncomplicated Firewall) makes this a few commands. Allow SSH first, then turn the firewall on, so you do not cut off your own connection. Cyber Essentials adds a useful test: administrative interfaces should not be open to the internet unless they are protected by two-factor sign-in or limited to known addresses.

See How to set up a firewall with UFW on Ubuntu and Debian.

4. Let security updates install themselves

Akamai calls updating "the single biggest security precaution you can take". Most attacks on servers use flaws that already have a fix. The fix only helps once it is installed.

• Ubuntu installs and enables unattended-upgrades by default, which applies security updates automatically. Automatic reboots are off unless you turn them on, so restart when an update asks for it, at a time that suits you.
• Debian usually installs it, but it can be missing or switched off. Run sudo dpkg-reconfigure unattended-upgrades and answer yes to check.

Cyber Essentials expects critical and high-risk fixes to be applied within 14 days. Automatic security updates make that the default rather than a chore.

5. Back up, test the restore, and lock the account

Backups are your way back from a mistake, a failed update or an attack. The UK National Cyber Security Centre (NCSC) gives three rules: back up what the business needs to operate, keep a copy that is not permanently connected, and know how to restore it, including checking that the backup holds what you need. A backup you have never restored is a hope, not a plan.

The account that controls the server is just as important. Whoever signs in to it can reinstall, delete or read the server, whatever its SSH settings. Turn on two-factor sign-in there. DigitalOcean recommends an authenticator app over SMS codes, which can be intercepted.

On a Noiz Cloud server, backups and restore testing are yours to arrange. If you would rather Noiz ran them, the Backup add-on is a managed backup for servers and workstations, with restore terms agreed before you buy.

A sixth, optional: slow down the guessers

Tools such as fail2ban and the open-source CrowdSec read your logs and block addresses that keep failing to sign in. They cut down the noise. fail2ban's own documentation is clear that this cannot remove the risk of weak authentication, so treat it as an extra after step 1, never instead of it.

On shared hosting

On a shared hosting plan the host runs the server, so the basics look different but follow the same logic:

• Turn on two-factor authentication in Plesk.
• Use a different strong password for the control panel, each FTP account and each mailbox.
• Use SFTP or FTP over TLS rather than plain FTP. On Noiz shared hosting, SSH is part of the Premium plans.
• Keep WordPress, its plugins and themes updated, and delete the ones you do not use, as WordPress's own hardening guide advises.
• Know where your backup is. Every Noiz shared plan includes a weekly panel backup.

Where Noiz fits

A Noiz Cloud server gives you the root access these steps need, provisioned within one working day. If you would rather hand over the operating system as well, Noiz quotes Linux administration by the hour, once off or maintained monthly.

If you want a second pair of hands on a new server's first hour, ask us for a Linux administration quote.

Sources

• DigitalOcean, Initial server setup with Ubuntu: https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu
• DigitalOcean, Recommended Droplet setup: https://docs.digitalocean.com/products/droplets/getting-started/recommended-droplet-setup/
• DigitalOcean, two-factor authentication: https://docs.digitalocean.com/platform/accounts/2fa/
• Akamai TechDocs, Set up and secure a Compute Instance: https://techdocs.akamai.com/cloud-computing/docs/set-up-and-secure-a-compute-instance
• Ubuntu Server documentation, automatic updates: https://ubuntu.com/server/docs/how-to/software/automatic-updates/
• Debian wiki, UnattendedUpgrades: https://wiki.debian.org/UnattendedUpgrades
• NCSC, Cyber Essentials overview: https://www.ncsc.gov.uk/cyberessentials/overview
• NCSC, Cyber Essentials requirements for IT infrastructure v3.3 (April 2026): https://www.ncsc.gov.uk/sites/default/files/2026-08/IT%20Requirements%20v3.3.pdf
• NCSC, Backing up your data: https://www.ncsc.gov.uk/collection/small-organisations-guide-to-cyber-security/backing-up-your-data
• fail2ban: https://github.com/fail2ban/fail2ban
• CrowdSec documentation: https://docs.crowdsec.net/docs/intro
• Plesk Obsidian, multi-factor authentication: https://docs.plesk.com/en-US/obsidian/administrator-guide/plesk-administration/securing-plesk/setting-up-multifactor-authentication-in-plesk.80028/
• WordPress, hardening: https://developer.wordpress.org/advanced-administration/security/hardening/

Note: while some of this content was produced with the help of AI, the final editing has been done by a real human being.