{"id":245,"date":"2025-12-11T00:17:50","date_gmt":"2025-12-11T00:17:50","guid":{"rendered":"https:\/\/www.vps.tc\/blog\/10-essential-steps-to-secure-and-harden-your-linux-server\/"},"modified":"2026-09-09T09:22:29","modified_gmt":"2026-09-09T09:22:29","slug":"10-essential-steps-to-secure-and-harden-your-linux-server","status":"publish","type":"post","link":"https:\/\/www.vps.tc\/blog\/en\/10-essential-steps-to-secure-and-harden-your-linux-server\/","title":{"rendered":"10 Essential Steps to Secure and Harden Your Linux Server"},"content":{"rendered":"
Table of Contents<\/strong><\/p>\n
    \n
  1. Why Linux servers stay on attackers' radar<\/a><\/li>\n
  2. Step 1: Start with a minimal, fully patched system<\/a><\/li>\n
  3. Step 2: Lock down SSH, your primary entry point<\/a><\/li>\n
  4. Step 3: Enforce strong authentication and authorization<\/a><\/li>\n
  5. Step 4: Put a real firewall in front of every service<\/a><\/li>\n
  6. Step 5: Reduce attack surface: services, ports and software<\/a><\/li>\n
  7. Step 6: Harden the OS and kernel<\/a><\/li>\n
  8. Step 7: Protect data with sane permissions and encryption<\/a><\/li>\n
  9. Step 8: Logging, auditing and knowing what changed<\/a><\/li>\n
  10. Step 9: Backups and disaster recovery that actually work<\/a><\/li>\n
  11. Step 10: Continuous monitoring and basic incident response<\/a><\/li>\n
  12. Pulling your Linux security plan together<\/a><\/li>\n
  13. Frequently Asked Questions<\/a><\/li>\n<\/ol>\n<\/div>\n

    Why Linux servers stay on attackers' radar<\/h2>\n

    Public Linux servers are scanned almost immediately after they become reachable. SSH password attempts, web application probes and leaked keys tested against your address range are routine background noise. If you run production workloads, server security cannot be an afterthought.<\/p>\n

    There is no magic hardening script. A safer host comes from a baseline that you can apply, verify and maintain across every machine. I have learned this the unglamorous way: a system can look quiet while an important control is missing.<\/p>\n

    These are ten practical areas I check on internet-facing Linux servers. They will not make a host invulnerable, but they remove many easy paths and make the remaining ones easier to detect.<\/p>\n

    Step 1: Start with a minimal, fully patched system<\/h2>\n

    If the operating system is outdated, later configuration work has a weak foundation. On a fresh VPS or dedicated server, patch it first, then remove services and packages you do not need.<\/p>\n

    Use a minimal base image<\/h3>\n

    Choose a maintained, minimal distribution image rather than one carrying a collection of services you may never use. With providers like VPS.TC VPS<\/a> or dedicated servers<\/a>, start with the leanest suitable Linux template and add software deliberately.<\/p>\n

    Apply security updates immediately<\/h3>\n

    After confirming that you can log in through the provider console, update the system before installing your application stack. On Debian and Ubuntu:<\/p>\n

    sudo apt update && sudo apt full-upgrade -y<\/code><\/pre>\n
    On RHEL, Rocky or AlmaLinux:<\/p>\n
    sudo dnf upgrade --refresh -y<\/code><\/pre>\n
    Reboot when a kernel, systemd, glibc or another component requiring a restart was upgraded. Check before and after instead of treating every package update as proof that a reboot is necessary:<\/p>\n
    sudo needs-restarting -r<\/code><\/pre>\n
    That command is available on RHEL-family systems with dnf-utils<\/code> or the current dnf-plugins-core<\/code> package. On Debian and Ubuntu, review \/var\/run\/reboot-required<\/code> when it exists.<\/p>\n
    Automate future security updates<\/h3>\n
    For Debian and Ubuntu, install and configure unattended-upgrades<\/code> if automatic security updates fit your release and change-control policy:<\/p>\n
    sudo apt install unattended-upgrades\nsudo dpkg-reconfigure unattended-upgrades<\/code><\/pre>\n
    On RHEL-like systems, dnf-automatic<\/code> can apply or report updates according to its configuration. Automatic patching still needs monitoring, exclusions for special workloads and a recovery plan. Test kernel updates on a disposable or staging host first.<\/p>\n
    Step 2: Lock down SSH, your primary entry point<\/h2>\n
    SSH is still the service I see probed most often. Changing its port may reduce log noise, but it is not a security control by itself. Authentication, authorization and network restrictions matter more.<\/p>\n
    Disable direct root login<\/h3>\n
    Create an individual administrator account and give it only the sudo access it needs.<\/p>\n
    sudo adduser deploy\nsudo usermod -aG sudo deploy<\/code><\/pre>\n
    On RHEL-based systems, use the wheel<\/code> group instead:<\/p>\n
    sudo usermod -aG wheel deploy<\/code><\/pre>\n
    Before changing the daemon configuration, validate it with sshd -t<\/code>. In \/etc\/ssh\/sshd_config<\/code> or a file under \/etc\/ssh\/sshd_config.d\/<\/code>, use settings similar to:<\/p>\n
    PermitRootLogin no\nPasswordAuthentication no\nKbdInteractiveAuthentication no\nPermitEmptyPasswords no\nPubkeyAuthentication yes<\/code><\/pre>\n
    Reload the service name used by your distribution. Debian and Ubuntu commonly use ssh<\/code>; RHEL-family systems commonly use sshd<\/code>:<\/p>\n
    sudo sshd -t && sudo systemctl reload ssh<\/code><\/pre>\n
    On RHEL-family systems, replace ssh<\/code> with sshd<\/code>. Keep an existing session open and test a second key-based session before disabling passwords. I once came close to locking myself out because I changed access rules before testing the new account; the provider console saved me, but it was not a clever recovery plan.<\/p>\n
    Use key-based authentication, not passwords<\/h3>\n
    Generate a key on your workstation, protect it with a passphrase and keep the private half off the server.<\/p>\n
    ssh-keygen -t ed25519<\/code><\/pre>\n
    Use ssh-copy-id<\/code> where available, or append the public key to ~\/.ssh\/authorized_keys<\/code>. For automation, use a separate restricted key rather than your personal administrator key.<\/p>\n
    Limit who can log in via SSH<\/h3>\n
    Define the permitted accounts explicitly when that matches your access model:<\/p>\n
    AllowUsers deploy<\/code><\/pre>\n
    For a bastion host, restrict access further with source addresses, a VPN or an upstream firewall. If you use an MFA-capable SSH setup, test the emergency access path before you need it.<\/p>\n
    Step 3: Enforce strong authentication and authorization<\/h2>\n
    SSH hardening answers who may enter. Sudo policy answers what they can do after entering.<\/p>\n
    Use sudo with least privilege<\/h3>\n
    Give each administrator a personal account and record privilege changes in version control or configuration management. Use \/etc\/sudoers.d\/<\/code> and validate edits with visudo<\/code>; do not share a root password.<\/p>\n
    When someone leaves the team, remove the account or disable it, revoke its keys and review any service credentials it owned. Access that exists only in somebody's memory is not an access-control system.<\/p>\n
    Consider multi-factor authentication for critical access<\/h3>\n
    MFA can protect SSH, VPN and management panels when it is deployed carefully. TOTP through a PAM module is one option; FIDO2 or hardware-backed keys can provide stronger phishing resistance where your SSH clients and policy support them. Keep a documented, tightly controlled break-glass method, and test it without weakening normal access.<\/p>\n
    Step 4: Put a real firewall in front of every service<\/h2>\n
    A provider firewall and a host firewall solve different problems. I use both when possible, with the host rules kept simple enough to audit.<\/p>\n
    Allow only what you actually use<\/h3>\n
    List the required ports before writing rules. Usually that means SSH and, for a web server, ports 80 and 443. Database ports should normally be reachable only from the application network or trusted administration addresses.<\/p>\n
    On Ubuntu, ufw<\/code> is convenient for a small host:<\/p>\n
    sudo ufw default deny incoming\nsudo ufw default allow outgoing\nsudo ufw allow 22\/tcp\nsudo ufw allow 80\/tcp\nsudo ufw allow 443\/tcp\nsudo ufw enable<\/code><\/pre>\n
    On RHEL-based systems with firewalld:<\/p>\n
    sudo firewall-cmd --permanent --set-default-zone=public\nsudo firewall-cmd --permanent --add-service=ssh\nsudo firewall-cmd --permanent --add-service=http\nsudo firewall-cmd --permanent --add-service=https\nsudo firewall-cmd --reload<\/code><\/pre>\n
    For more explicit rule sets, nftables is the current Linux packet-filtering framework behind many distributions' tooling. Whichever layer you choose, confirm the SSH rule and keep a console or active session available before enabling it. The -a<\/code> flag is not the thing to remember here; the thing to remember is how you will recover from a bad rule.<\/p>\n
    Step 5: Reduce attack surface: services, ports and software<\/h2>\n
    Every listening daemon expands the amount of code and configuration you must maintain. If a service is unnecessary, remove it or prevent it from starting.<\/p>\n
    Inventory running services<\/h3>\n
    Start with sockets:<\/p>\n
    sudo ss -tulpn<\/code><\/pre>\n
    Then inspect enabled services:<\/p>\n
    systemctl list-unit-files --type=service --state=enabled<\/code><\/pre>\n
    Check each unfamiliar listener with its package and service documentation. Do not disable something merely because its name is unfamiliar; identify it first.<\/p>\n
    Disable and remove what you do not need<\/h3>\n
    sudo systemctl disable --now avahi-daemon\nsudo systemctl disable --now cups<\/code><\/pre>\n
    Those examples are appropriate only when you do not need discovery or printing. Remove unused packages through the distribution package manager and review dependencies afterward. A service that is disabled but never patched can still become a problem if somebody starts it later.<\/p>\n
    Step 6: Harden the OS and kernel<\/h2>\n
    Kernel settings can reduce exposure, but they are not a substitute for patching, firewall rules or application security. Test them against the way the host actually routes traffic.<\/p>\n
    Apply secure sysctl settings<\/h3>\n
    For a host that is not a router, a starting point may include:<\/p>\n
    net.ipv4.ip_forward = 0\nnet.ipv4.conf.all.accept_source_route = 0\nnet.ipv4.conf.default.accept_source_route = 0\nnet.ipv4.conf.all.accept_redirects = 0\nnet.ipv4.conf.default.accept_redirects = 0<\/code><\/pre>\n
    Save this in a reviewed file such as \/etc\/sysctl.d\/99-custom.conf<\/code> and apply it with:<\/p>\n
    sudo sysctl --system<\/code><\/pre>\n
    Be careful with reverse-path filtering. Strict rp_filter=1<\/code> can break asymmetric routing, policy routing, VPNs or some cloud network designs. Use the distribution default or a tested loose mode where the network requires it; do not paste a large hardening template into production. I have seen a supposedly harmless sysctl change turn a routing problem into a longer investigation because nobody had written down the expected traffic paths.<\/p>\n
    Use mandatory access control where feasible<\/h3>\n
    SELinux and AppArmor restrict what processes can do even when a process is compromised or running with high privileges. Keep SELinux enforcing or AppArmor enabled where the distribution and application support it. Fix policy denials deliberately; disabling the control to make an application start is usually only hiding the real configuration problem.<\/p>\n
    For multiple servers, put the chosen MAC policy into images and automation. Verify the policy after application upgrades, since a package update can change required paths or permissions.<\/p>\n
    Step 7: Protect data with sane permissions and encryption<\/h2>\n
    A network compromise is not the only route to data loss. A stolen credential, an over-permissive service account or an exposed backup can be just as damaging.<\/p>\n
    Fix ownership and permissions<\/h3>\n
    World-writable files should be unusual and explainable. Check them periodically:<\/p>\n
    sudo find \/ -xdev -type d -perm -0002 -print\nsudo find \/ -xdev -type f -perm -0002 -print<\/code><\/pre>\n
    Review the results rather than blindly running chmod 777<\/code>. That changes the symptom, not the ownership or application design that caused it. Protect \/etc\/shadow<\/code>, SSH keys, TLS private keys and application secrets with correct owners and the narrowest practical modes.<\/p>\n
    Encrypt data at rest and in transit<\/h3>\n
    LUKS full-disk encryption can protect data on stolen physical media, but it also changes how a remote server boots and how keys are made available. Plan console access and key handling before deploying it. For databases and application data, field-level or volume encryption may be more appropriate.<\/p>\n
    For public services, use current TLS configurations supplied by the web server and certificate tooling, and remove obsolete protocols only after checking client compatibility. Encryption does not help if private keys are stored in a world-readable backup.<\/p>\n
    Step 8: Logging, auditing and knowing what changed<\/h2>\n
    When a server behaves strangely, I want logs before I want a reboot. Restarting first can erase volatile evidence and rarely explains the original fault.<\/p>\n
    Centralize and retain logs<\/h3>\n
    Forward important journald or syslog records to a separate collector with restricted access and a retention policy. Include authentication events, sudo activity, firewall events, service failures and application logs. A remote copy is useful because an attacker with root can alter local evidence.<\/p>\n
    Audit critical actions<\/h3>\n
    For high-value systems, use auditd<\/code> or an equivalent auditing pipeline for changes to identity files, SSH configuration, sudo policy and other sensitive paths. Tune rules to the risks you can investigate; collecting everything without enough storage or alerting creates noise rather than visibility.<\/p>\n
    Also record configuration changes through Ansible, packages or a Git-backed process. Knowing who changed a file and when is often as useful as knowing that it changed.<\/p>\n
    Step 9: Backups and disaster recovery that actually work<\/h2>\n
    Security includes recovery. Ransomware, accidental deletion, failed updates and provider incidents all test the same question: can you restore the service and the data?<\/p>\n
    Follow a practical backup strategy<\/h3>\n
    The 3-2-1 rule remains a useful baseline:<\/p>\n