The 10 Most Common Server Security Mistakes

Every Linux server has a root account. Allowing root to log in via SSH gives automated bots a 50% head start — they already know the username. Set PermitRootLogin no in /etc/ssh/sshd_config and create a named sudo user for all admin operations.

Password-based SSH auth is vulnerable to brute-force and credential stuffing attacks. Switch to SSH key authentication and set PasswordAuthentication no. With key auth, an attacker cannot log in even if they know the correct password — they need the private key file.

One SSH key for the whole team means you cannot revoke access for one person without rotating it for everyone. Each team member needs their own key pair, and their public key should be added to ~/.ssh/authorized_keys individually. Removing access is then as simple as deleting their public key entry.

A server running unpatched packages is running known vulnerabilities — CVEs with public proof-of-concept exploits. Enable unattended-upgrades to apply security patches automatically, or schedule regular manual apt update && apt upgrade runs.

MySQL, Redis, MongoDB, and PostgreSQL should never be reachable on public interfaces. Bind them to 127.0.0.1 in their configuration files. Shodan scans show tens of thousands of exposed database instances online at any given moment — do not add yours.

A firewall that only blocks known-bad traffic is the wrong model — block everything and allow only what you need. Set UFW to default deny incoming before adding your allow rules. Many provisioned servers have no firewall running at all, or have it disabled after installation.

Files writable by any user are a privilege escalation vector. A compromised web process that can write to world-writable directories can plant PHP shells or modify system scripts. Run find / -xdev -type f -perm -0002 2>/dev/null to find them. Web application files should be owned by the web user with permissions no higher than 644/755.

Services like Nginx, PHP-FPM, and Node.js should run as unprivileged users — not root. If a vulnerability in the service is exploited, a root-running process gives the attacker full system access; an unprivileged process gives them access only to that service's files. Check with ps aux | grep nginx — worker processes should show a non-root user.

Ransomware attacks encrypt server data and delete local backups. If your only backups live on the same server being attacked, you have no recovery path. Store backups in a separate storage account or remote location, and test restoration — a backup you have never restored is just a hope, not a safety net.

Auth logs, web server logs, and application error logs are your early warning system. If you are not watching them, you will not know you have been compromised until the damage is done. At minimum, set up Fail2Ban to watch auth logs and configure email alerts for login failures. Log forwarding to a centralized service adds retention and makes post-incident analysis possible.