Top 50 server security questions, answered fast

Look for things you did not do: unknown processes using a lot of CPU, new user accounts or SSH keys, new cron jobs or systemd services, outbound connections to strange addresses, and gaps in the logs. Start with who, last -a (on Debian 13, wtmpdb last from the wtmpdb package), sudo ss -tupan and ps auxf, and read every ~/.ssh/authorized_keys file, including root’s. One odd finding is a reason to dig deeper; several together usually mean a compromise. Read the full guide.

Yes. Bots scan and guess passwords on every server with SSH open to the internet, so failed logins alone do not mean you were hacked. What matters is a successful login you do not recognise: check sudo journalctl -u ssh -u sshd | grep Accepted and last -a. If password logins are switched off, the guessing cannot succeed. Read the full guide.

It comes from sshd’s reverse DNS check: the hostname found for the connecting address does not map back to that same address. It warns about mismatched DNS and is not proof that anyone got in; it usually comes from the same bots that guess passwords. Treat it as a failed login and look for successful ones instead. Read the full guide.

Very often, yes. Miners use names such as kdevtmpfsi, kinsing or xmrig, or names that look like kernel threads, and run from /tmp, /var/tmp or /dev/shm. Find the real program with sudo ls -l /proc/PID/exe (a path ending in “(deleted)” is a red flag) and its connections with sudo ss -tpn | grep pid=PID. Read the full guide.

sudo ss -tulpn lists every listening TCP and UDP port with the process that owns it, and sudo ss -tupn shows current connections. Compare them with what you expect, for example SSH, a web server and a database bound to 127.0.0.1. A shell, Perl or Python process, or anything running from /tmp, that holds a connection to an unknown address needs a closer look. Read the full guide.

Run sudo rkhunter --check --sk or sudo chkrootkit, and compare package files with the package database using sudo rpm -Va (RHEL family) or sudo debsums -c (Debian and Ubuntu, from the debsums package). Expect some false positives after updates and config changes. A clean result is not proof: an attacker with root can fool tools that run on the same system, so for a trustworthy check, boot from rescue media. Read the full guide.

Not usually to protect the server itself: attackers mostly get in through weak passwords, exposed services and unpatched software, which patching and hardening deal with better. A scanner is useful where the server stores or passes on files for other people, such as mail, file shares and upload folders. ClamAV is the common free choice; sudo clamscan -r -i /var/www lists infected files only. Read the full guide.

Check the usual hiding places: every authorized_keys file, accounts with UID 0 (awk -F: '$3 == 0' /etc/passwd should print only root), sudoers files, crontabs and /etc/cron.*, systemd units and timers (systemctl list-timers --all), /etc/ld.so.preload (normally absent) and PHP files in upload directories. Then change every password and key that person knew. Read the full guide.

Isolate it with a firewall rule, security group or the provider’s console, but keep it running, because powering off destroys evidence held in memory. Copy logs, the process list and open connections to another machine, write down times, and do not delete files or run cleanup tools yet. Then decide whether you need your host or an incident responder. Read the full guide.

If the attacker had root, rebuild: you cannot be sure you found every backdoor, and the tools on the server may lie to you. Install a fresh system from trusted media, patch it, restore data (not programs and configs wholesale) from a backup made before the break-in, and close the hole they used. A break-in limited to one unprivileged account or one website can sometimes be cleaned, but only if you can show root was never reached. Read the full guide.

Freeze the process (sudo kill -STOP PID), remove what restarts it, then kill it; otherwise it will be back within minutes. Look for cron entries, systemd services, SSH keys, changed shell profiles and files made immutable (lsattr shows an i flag; sudo chattr -i FILE clears it). Then find how it got in; weak SSH passwords, Redis or the Docker API open to the internet, and unpatched web apps are common. If the miner ran as root or you cannot find how it got in, rebuilding is the safer fix. Read the full guide.

Find when the first malicious file or process appeared (stat FILE shows its times) and read the logs around that time: SSH logins in the journal or /var/log/auth.log / /var/log/secure, web access logs for requests to odd scripts, and package logs for software left unpatched. Check what is reachable from outside with sudo ss -tulpn: a database, Redis or Docker API listening on all interfaces is a common way in. If you never find the entry point, a rebuilt server can be broken into the same way. Read the full guide.

Everything stored on or typed into the server: user and root passwords, SSH keys whose private half was on it, database passwords, API tokens, cloud access keys, and secrets in application files such as .env or wp-config.php. Change them from a clean computer and only after the attacker’s access is cut, or they will see the new ones. Also check what those credentials open, such as new users or keys in your cloud account. Read the full guide.

Keep a copy of the hacked site as evidence, then replace WordPress core, themes and plugins with fresh copies from official sources instead of editing infected files. Look for PHP files where none belong (find wp-content/uploads -name '*.php'), remove unknown admin users, and change all passwords and the keys and salts in wp-config.php. Delete plugins you do not use and update the rest; vulnerable plugins and themes are a common way in. Read the full guide.

Reply quickly with what you are doing, because hosts often suspend servers whose owners stay silent. The complaint usually includes log lines with times and addresses; use them to find the cause, typically a hacked account sending spam, a phishing page on a hacked site, or malware attacking other servers. Stop the activity, fix the way in, and send the host a short note on cause and fix. Read the full guide.

First isolate the server, keep it running, and save the ransom note and logs. Check No More Ransom for a free decryptor, report the attack, and plan to rebuild from clean offline backups. The FBI and CISA do not encourage paying, because payment does not guarantee your files will be recovered, and paying a sanctioned group can be illegal. Read the full guide.

Often, yes. If personal data of people in the EU may be affected, the GDPR requires the controller to notify the supervisory authority within 72 hours of becoming aware of the breach, unless it is unlikely to put people at risk; the UK has a similar rule. US states, other countries and contracts (for example card payment rules) set their own duties, so involve a lawyer or your data protection officer early and keep notes of what happened and when. Read the full guide.

Use SSH keys and turn off passwords: set PasswordAuthentication no and KbdInteractiveAuthentication no, check the effective values with sudo sshd -T | grep -i authentication (a file in /etc/ssh/sshd_config.d/ can override yours), test with sudo sshd -t, and restart SSH while keeping your current session open. fail2ban adds temporary bans; sudo fail2ban-client status sshd lists them. Moving SSH to another port cuts log noise but does not protect you on its own. Read the full guide.

ufw uses the first rule that matches, so put the block before your allow rules: sudo ufw prepend deny from 203.0.113.5. With firewalld (RHEL family), send the address to the drop zone: sudo firewall-cmd --permanent --zone=drop --add-source=203.0.113.5, then sudo firewall-cmd --reload. Blocking single addresses helps against one noisy source, not against a botnet. Read the full guide.

Contact your hosting provider first: a flood that fills your network link has to be filtered upstream, and nothing on the server can fix that. Meanwhile, work out the type of attack (sudo ss -s for connection counts, web logs for request floods), rate-limit at the web server or firewall, and consider a CDN or DDoS protection service for public websites. Also make sure your server is not an open DNS resolver or other reflector that attackers can use against others. Read the full guide.

Look the address up on the blocklist’s own website to see why it was listed, then fix the cause before asking for removal, or it will be listed again. The cause is usually spam sent through a hacked mailbox password, a PHP mail script or malware; check the mail queue with sudo postqueue -p (Postfix) or sudo exim -bp (Exim) and see which account sent the most. When it is fixed, use each list’s own removal process. Read the full guide.

Check the records with dig +short example.com A and dig +short example.com NS and compare them with what they should be. If the nameservers changed, log in to (or recover) your registrar account, put the right nameservers back, and turn on two-factor authentication and a registrar lock. If only records changed, fix them at your DNS host and change that account’s password. Read the full guide.

Debian and Ubuntu: sudo apt update && sudo apt upgrade. RHEL family and Fedora: sudo dnf upgrade --refresh. SUSE: sudo zypper refresh && sudo zypper patch. Afterwards, check whether services or the kernel need a restart, because updated code only runs once they do. Read the full guide.

On Ubuntu, sudo unattended-upgrade -v installs updates from the security pockets only with the default configuration (add --dry-run to preview). On the RHEL family use sudo dnf upgrade --security, and on SUSE sudo zypper patch --category security. Debian’s apt has no security-only switch; limit unattended-upgrades to the security origin, or list packages with fixes using debsecan. Read the full guide.

On a stable release such as Debian stable or Ubuntu LTS, usually yes: security fixes are backported into the versions you already run, so each update changes as little as possible. The risk comes from third-party repositories, major-version jumps and services restarting during busy hours. Read the package list before you confirm, take a snapshot or backup first, and update a staging server or one cluster node before the rest. Read the full guide.

For security updates, usually yes: an unpatched internet-facing server is a bigger risk than an occasional bad update. Use unattended-upgrades on Debian and Ubuntu (on by default on Ubuntu Server) or dnf-automatic with upgrade_type = security on the RHEL family, watch the logs, and decide separately whether the server may reboot itself. Critical clusters can use a staged schedule instead. Read the full guide.

Patch internet-facing systems within days when a fix for a critical or actively exploited flaw appears, and apply routine updates at least monthly on a fixed schedule. A CVE in CISA’s Known Exploited Vulnerabilities catalog goes to the front of the queue. Subscribe to your distribution’s security announcements so you hear about urgent fixes the same day. Read the full guide.

apt upgrade installs newer versions but never removes installed packages; an update that would need a removal is skipped. apt full-upgrade (the older name is dist-upgrade) removes packages when needed, so read its summary before you say yes. Packages shown as “kept back” need full-upgrade, or on Ubuntu are often phased updates that arrive on their own a few days later. Read the full guide.

A repository you add can install any software as root on every update, so you trust its owner as much as your distribution. Use only repositories run by the software’s vendor or well-known maintainers, tie each signing key to its own repository with signed-by, and remove ones you no longer use. Your distribution’s security team does not patch that software, so follow its own advisories. Read the full guide.

Rebuild the image on an updated base image and redeploy; changes made with apt or dnf inside a running container are lost when it is recreated. docker build --pull -t myapp . fetches the newest base image, and rebuilding on a schedule catches fixes even when your code has not changed. Updating the host does not update the software inside containers. Read the full guide.

On Debian and Ubuntu: sudo apt-mark hold nginx (apt-mark showhold lists holds, sudo apt-mark unhold nginx removes one). On the RHEL family, install the plugin with sudo dnf install 'dnf-command(versionlock)', then run sudo dnf versionlock add nginx. A held package also misses its security fixes, so note why it is held and lift the hold as soon as you can. Read the full guide.

Only for some updates. A new kernel runs only after a reboot, and updates to core parts such as glibc or systemd are easiest to finish with one; most other packages just need their services restarted. Running processes keep the old, vulnerable code in memory until they restart, so a fix is “installed” but not active until you do one or the other. Read the full guide.

On Debian and Ubuntu, /var/run/reboot-required exists when an update asks for a reboot and /var/run/reboot-required.pkgs names the packages; sudo needrestart -k compares the running and installed kernels. On the RHEL family, sudo dnf needs-restarting -r exits with code 1 when a reboot is needed. On SUSE, use sudo zypper needs-rebooting. Read the full guide.

Every process that still has the old library loaded. sudo needrestart -r l (Debian, Ubuntu) and sudo dnf needs-restarting -s (RHEL family) list them without restarting anything, and sudo lsof -n +L1 shows processes holding deleted files. Restart each with sudo systemctl restart SERVICE (this briefly interrupts it), and do not forget long-running processes outside systemd. Read the full guide.

For many serious kernel flaws, yes, with live patching: Canonical Livepatch (Ubuntu Pro), kpatch on RHEL, SUSE Live Patching, Oracle Ksplice or TuxCare KernelCare. Live patches cover selected security fixes for a limited time, not every kernel change, so you still need to reboot into new kernels regularly. ls /sys/kernel/livepatch/ shows which live patches are loaded. Read the full guide.

Open the provider’s console or IPMI, choose “Advanced options” in the GRUB menu (on Ubuntu, hold Shift or press Esc during boot to show it) and start the previous kernel. Once it is up, sudo journalctl -b -1 -p err shows errors from the failed boot if the journal is kept on disk. Fix the cause, or make the old kernel the default until a fixed one is released. Read the full guide.

Another package process is running, very often unattended-upgrades shortly after boot. See which one with sudo lsof /var/lib/dpkg/lock-frontend and wait for it to finish; never delete the lock files. If no process holds the lock and an earlier run was interrupted, run sudo dpkg --configure -a and then sudo apt -f install. Read the full guide.

On the RHEL family, sudo dnf history list shows transactions and sudo dnf history undo ID reverses one, as long as the old packages are still available. On Debian and Ubuntu, install a specific version with sudo apt install nginx=VERSION (apt-cache policy nginx lists available versions) and then hold it. A snapshot taken before patching (LVM, ZFS, Btrfs or your cloud provider) is the fastest way back. Read the full guide.

Run sudo dnf clean all and sudo dnf makecache to rule out stale metadata, then read the exact error: a broken repository, a missing GPG key, duplicate packages and a damaged RPM database each have their own fix. sudo dnf check reports dependency problems and duplicates, and sudo rpm --rebuilddb rebuilds the database indexes. On current RHEL-family systems, yum is DNF under another name. Read the full guide.

Find the full filesystem with df -h (and df -i for inodes), then the biggest directories with sudo du -xh --max-depth=1 / | sort -h. Quick wins: sudo apt clean or sudo dnf clean all, old journal files (sudo journalctl --vacuum-size=200M) and old kernels; sudo lsof -n +L1 finds deleted files still held open. Never delete files under /var/lib/dpkg or /var/lib/rpm. Read the full guide.

Use an out-of-band console: your cloud or VPS provider’s web console, IPMI or iDRAC, or rescue mode. From there, undo the change, which is usually an sshd_config edit, a firewall rule, or fail2ban banning your own address (sudo fail2ban-client set sshd unbanip YOUR_IP lifts that). Next time, run sudo sshd -t before restarting SSH and keep one session open until a new login works. Read the full guide.

If your own account can use sudo, run sudo passwd root. Otherwise you need the console: on the RHEL family, add rd.break to the kernel line in GRUB; on Debian and Ubuntu, use recovery mode or add init=/bin/bash. Then make the root filesystem writable and run passwd; on SELinux systems, create /.autorelabel so file labels are fixed at the next boot. Read the full guide.

For Let’s Encrypt certificates managed by Certbot, sudo certbot certificates shows expiry dates and sudo certbot renew renews them; reload the web server afterwards if no deploy hook does it. Then find out why automatic renewal stopped: sudo certbot renew --dry-run tests it, and systemctl list-timers should show a certbot timer (otherwise check cron). Let’s Encrypt certificates last 90 days by default, so renewal has to run on its own. Read the full guide.

A CVE ID, such as CVE-2024-6387, is a unique name for one publicly known vulnerability, so vendors, scanners and advisories can all refer to the same flaw. The ID alone says nothing about how serious the flaw is or whether your system is affected. For that, look the CVE up on your distribution’s security tracker, which shows the fixed version for each release. Read the glossary entry.

The Common Vulnerability Scoring System (now version 4.0) rates a flaw’s severity from 0 to 10: Low 0.1–3.9, Medium 4.0–6.9, High 7.0–8.9 and Critical 9.0–10.0. It measures how bad a flaw is in general, not your risk: a critical bug in a service you do not run may matter less than a medium one in your public web server that is being attacked. Distributions sometimes give their own, different rating. Read the glossary entry.

KEV is CISA’s Known Exploited Vulnerabilities catalog, a list of flaws that attackers are known to have exploited in the wild. If a CVE that affects you is on it, patch now, whatever its CVSS score. EPSS, from FIRST, estimates the probability (0 to 1) that a CVE will be exploited in the next 30 days, which helps you rank everything else. Read the full guide.

Look the CVE up on your distribution’s tracker (Debian Security Tracker, Ubuntu CVE pages, Red Hat CVE pages) to get the fixed package version for your release, then compare it with what is installed: dpkg -l openssh-server or rpm -q openssh-server. On the RHEL family, dnf updateinfo list --cve=CVE-2024-6387 shows a pending fix; on Ubuntu, sudo pro fix CVE-2024-6387 checks and fixes in one step. Read the full guide.

Usually you are. Debian, Ubuntu, Red Hat and others backport security fixes into the version they shipped, so the version number stays old while the hole is closed, and scanners that only read the version banner report false positives. Show the fix with the package changelog, for example apt-get changelog openssh-server | grep CVE-2024-6387 or rpm -q --changelog openssh-server | grep CVE-2024-6387, and send that to whoever ran the scan. Read the full guide.

Every vendor publishes them, with a mailing list or feed: Debian Security Advisories (debian-security-announce), Ubuntu Security Notices (ubuntu-security-announce), Red Hat errata (RHSA), AlmaLinux and Rocky Linux errata, SUSE security updates and FreeBSD security advisories. Subscribe for every operating system you run, and also for major software you installed from outside the distribution. Read the full guide.

An end-of-life release gets no more security fixes, so every new flaw stays open. As of November 2026, for example, CentOS Linux 7 has had no updates since June 30, 2024, Debian 11 LTS ended on August 31, 2026, and Ubuntu 20.04 left standard support in May 2025 (Ubuntu Pro ESM continues until May 2030). Upgrade or migrate to a supported release, or buy extended support to gain time, and limit the server’s exposure to the internet until then. Read the full guide.