How to Secure a Linux Server: Firewall, SSH, Patching and Access

Server security does not come from a single product but from layers that complement each other: up-to-date software, a firewall with only the necessary ports open, SSH login with keys instead of passwords, everyone given only the access their job needs, logs that are watched regularly, and backups kept away from the server with tested restores. If one of these layers is missing, the others cannot fully close the gap.

The order below is written for a typical Linux virtual private server (VPS) where a small or mid-sized business hosts its website or application. First you will find what to do on the first day of setup, then the routines to keep running.

Where do most attacks on servers come from?

Every server exposed to the internet becomes a target for automated scanners from the moment it goes live. These scanners do not pick anyone in particular; they look for open SSH ports, default passwords and known vulnerabilities that have not been patched. That is why most of the problems we see come from simple oversights rather than sophisticated attacks:

• SSH or an admin panel left open to password login
• An operating system, CMS, plugin or library that has not been updated
• A database, cache or admin port left open to the internet
• Accounts and keys of former employees that still work
• Backups stored in the same place as the server, and therefore lost along with it in an attack

What should you do on a new server on day one?

Settings made during the initial setup are much easier than those you try to fix later. We suggest this order:

1. Update the system. The image your provider gives you is often weeks or months old. Refresh the package list and apply all updates first.
2. Create a personal admin account. Do daily work with a personal account that elevates privileges when needed (sudo) rather than as root. That way the logs show who did what.
3. Switch SSH to keys. Create an SSH key pair on your own computer and add the public key to the server. In OpenSSH's default configuration, password login (PasswordAuthentication) is enabled; once you have confirmed key login works, turn it off, and disable direct root login (PermitRootLogin) completely.
4. Turn on the firewall. Deny incoming traffic by default and allow only the ports you actually use, such as SSH, HTTP (80) and HTTPS (443).
5. Confirm automatic security updates. On Ubuntu Server the unattended-upgrades package is installed and enabled by default, but it only applies security updates and, by default, does not reboot the server on its own. Schedule a planned reboot time for kernel updates.
6. Slow down brute-force attempts. A tool such as Fail2ban watches the logs for repeated failed logins and blocks the offending IP address for a set period.

When you change SSH settings, test in a second window that you can log in with the new settings before closing your current session. Otherwise you can lock yourself out of the server.

What is the difference between a firewall and a WAF?

A network-level firewall decides who can reach which ports. Using the security groups in your cloud provider's panel together with the firewall on the server itself means a misconfiguration in one can be caught by the other.

A web application firewall (WAF), on the other hand, looks at the content of requests arriving on ports 80 and 443, which you have to keep open; it tries to block known attack patterns such as SQL injection or cross-site scripting (XSS). A WAF is useful, but it does not replace patching an outdated plugin; the real way to close a hole in the application layer is to update.

Ports for databases (MySQL, PostgreSQL), Redis and similar services should never be open to the internet. Configure these services so they can be reached only from the server itself or from a private network.

How should you manage updates?

Operating system updates are only half the job. On websites, most vulnerabilities appear in the application layer: the CMS, plugins, themes and libraries pulled in through npm or Composer. Put these on a schedule too:

• Apply security patches as soon as possible and other updates in a planned maintenance window.
• Try major version upgrades in a test environment first.
• Do not just disable plugins and themes you do not use; remove them.
• Follow critical vulnerability announcements and subscribe to the security bulletins of the software you run. In Turkey, the National Cyber Incident Response Center (USOM) publishes security advisories.

How do you set up access control?

The principle of least privilege is simple: every person and every service gets only the access needed to do its job. In practice this means:

• No shared root password or shared account; everyone has their own account and their own key.
• When someone leaves the team, their key is removed the same day. OpenSSH's AllowUsers setting lets you explicitly limit which users can log in over SSH.
• Turn on two-step verification for admin panels such as Plesk or cPanel and for your hosting provider account; where possible, make the panel reachable only from specific IP addresses.
• Application passwords and API keys are never written into the code repository; they are kept in environment variables or a secrets manager.

What should you monitor?

On a server without logs, you often notice a problem only when the site goes down. At a minimum, watch these signals: failed and successful logins, newly added users or keys, unexpectedly high CPU usage, a disk that is filling up, and unusual outbound traffic from the server. NIST's guide to general server security also lists logging and reviewing those logs regularly among the core security activities.

If you run more than one server, collecting logs in one central place and setting up email or message alerts for critical events lets you see a problem within minutes instead of hours.

Why are backups part of security?

In scenarios such as ransomware or deleted data, backups are the last resort, but only if they are stored away from the server. Keeping backups in a separate account, versioned and, where possible, immutable stops an attacker from deleting the backups along with the server. Relying on a backup that has never been restored is also risky. We cover methods and a test plan in detail in our article on server backup and disaster recovery.

Who is responsible on shared hosting, a VPS or a managed server?

On shared hosting, the provider is responsible for the security of the operating system and server software; you are responsible for your site itself, its plugins and your panel password. On a VPS, everything from the operating system up is yours. With a managed server service, this load is shared with a team, and you need to agree in writing in the contract who does what. We compare which infrastructure suits you in our article on VPS vs VDS vs shared hosting.

Encrypting traffic is also part of the picture; your site should be served only over HTTPS with a valid certificate.

In short: a checklist

• System and applications up to date, security updates automatic
• SSH with keys only, root login disabled, allowed users limited
• Only the ports in use open on the firewall, database closed to the outside
• Everyone has their own account, leavers' access removed, two-step verification on panels
• Login attempts, resource usage and new accounts monitored
• Backups kept away from the server, versioned and restore-tested

If you would like to review the state of your own server together, take a look at our server and infrastructure services.