Server Hardening Best Practices for Dedicated Servers

Start with the Attack Surface Inventory

Before changing anything, know what’s running:

# All listening ports

ss -tlnp

# Running services

systemctl list-units --type=service --state=running

# SUID/SGID files (privilege escalation candidates)

find / -perm /6000 -type f 2>/dev/null

# World-writable directories

find / -xdev -type d -perm -0002 2>/dev/null

Document what each open port and running service is for. If you can’t immediately answer “why is this port open,” that’s the first thing to investigate.

SSH Hardening

SSH is the primary administrative access vector on Linux servers — and the primary target for brute-force attacks. Hardening SSH closes off the most common attack path before any other configuration.

Edit /etc/ssh/sshd_config and enforce these settings:

# Disable password authentication entirely

PasswordAuthentication no

ChallengeResponseAuthentication no

# Disable root login over SSH

PermitRootLogin no

# Use a non-standard port (reduces automated scan noise)

Port 2222

# Limit SSH to specific users

AllowUsers deploy_user admin_user

# Reduce authentication timeout window

LoginGraceTime 30

MaxAuthTries 3

# Disable legacy protocol features

Protocol 2

X11Forwarding no

AllowAgentForwarding no

AllowTcpForwarding no

# Keep-alive settings to terminate idle sessions

ClientAliveInterval 300

ClientAliveCountMax 2

Key-based authentication is mandatory once password authentication is disabled. Generate keys on your local machine with ssh-keygen -t ed25519 and copy the public key to ~/.ssh/authorized_keys on the server before disabling passwords.

Apply the changes: systemctl restart sshd. Verify you can still connect via key before closing your current session.

NIST Special Publication 800-123 provides comprehensive guidance on SSH configuration in production environments, including key management practices.

Firewall Configuration with nftables

Modern Linux distributions use nftables as the preferred firewall framework. A minimal ruleset for a web server:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {

    chain input {

        type filter hook input priority 0; policy drop;

        # Accept established/related connections

        ct state established,related accept

        # Accept loopback

        iif lo accept

        # Accept ICMP (ping) - limit rate

        icmp type echo-request limit rate 5/second accept

        icmpv6 type echo-request limit rate 5/second accept

        # SSH on custom port

        tcp dport 2222 ct state new limit rate 10/minute accept

        # HTTP and HTTPS

        tcp dport { 80, 443 } accept

        # Log and drop everything else

        log prefix "Dropped: " drop

    }

    chain forward {

        type filter hook forward priority 0; policy drop;

    }

    chain output {

        type filter hook output priority 0; policy accept;

    }

}

Save to /etc/nftables.conf and enable: systemctl enable –now nftables. The default policy is drop on inbound — only explicitly allowed traffic gets through.

For servers running cPanel/WHM, cPanel manages its own firewall rules. Use ConfigServer Security & Firewall (CSF), which integrates with WHM and provides a UI for rule management without overriding cPanel’s required ports.

User Account Management

Every user account is a potential compromise vector. Dedicate attention to:

Disable unused system accounts: Check /etc/passwd for accounts with login shells that shouldn’t have them. Set their shell to /sbin/nologin:

usermod -s /sbin/nologin unused_account

Remove unnecessary sudo privileges: visudo to review /etc/sudoers. Each line granting NOPASSWD sudo is a privilege escalation path if that account is compromised. Require password for all sudo operations in production.

Use role-based user accounts: Application services should run as their own dedicated system user with minimal permissions. The web server shouldn’t run as root. MySQL shouldn’t run as root. Create application-specific users:

useradd -r -s /sbin/nologin -d /var/www/app appuser

chown -R appuser:appuser /var/www/app

Audit last logins regularly: lastlog | grep -v Never shows accounts that have been used to log in. Accounts you didn’t expect to see in that output warrant investigation.

Kernel Hardening via sysctl

Several kernel parameters reduce the attack surface for network-level exploits:

# /etc/sysctl.d/99-hardening.conf

# Disable IP source routing (used in some spoofing attacks)

net.ipv4.conf.all.accept_source_route = 0

net.ipv4.conf.default.accept_source_route = 0

# Disable ICMP redirect acceptance

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.default.accept_redirects = 0

# Enable reverse path filtering (anti-spoofing)

net.ipv4.conf.all.rp_filter = 1

# Disable ping broadcasts

net.ipv4.icmp_echo_ignore_broadcasts = 1

# Log martian packets (packets with impossible source addresses)

net.ipv4.conf.all.log_martians = 1

# Disable IPv6 if not in use

net.ipv6.conf.all.disable_ipv6 = 1

# Kernel pointer hiding

kernel.kptr_restrict = 2

kernel.dmesg_restrict = 1

Apply with sysctl -p /etc/sysctl.d/99-hardening.conf.

File System Security

Set correct permissions on sensitive directories:

chmod 750 /root

chmod 644 /etc/passwd

chmod 640 /etc/shadow

chmod 600 /etc/ssh/sshd_config

Mount options that reduce privilege escalation risks:

Edit /etc/fstab to add noexec, nosuid, and nodev to partitions that shouldn’t contain executable files:

/dev/sdb1 /var/tmp ext4 defaults,noexec,nosuid,nodev 0 2

Audit file integrity with AIDE: AIDE (Advanced Intrusion Detection Environment) creates a database of file checksums and can alert when files change unexpectedly. Initialize with aide –init, then run aide –check periodically or via cron. Unexpected changes to system binaries, libraries, or configuration files indicate a compromise.

Software and Package Management

Keep packages current: Unpatched vulnerabilities in the kernel, OpenSSL, glibc, and other system libraries are the most common path to server compromise after weak credentials.

# CentOS/AlmaLinux/Rocky Linux

dnf update --security -y

# Ubuntu/Debian

apt-get upgrade -y

Automate security updates: dnf-automatic (RHEL family) or unattended-upgrades (Debian family) can be configured to automatically apply security patches while leaving major version upgrades for manual review.

Audit installed packages: Remove packages that were installed for testing and never removed. Each installed package is a potential vulnerability. rpm -qa (RHEL) or dpkg -l (Debian) lists everything installed.

Remove development tools from production servers: Compilers, debuggers, and package build tools don’t belong on production servers. An attacker who gains limited access can use them to compile exploit code. Remove gcc, make, and similar tools if they’re present.

Intrusion Detection and Log Monitoring

Fail2Ban monitors log files and blocks IPs that exhibit suspicious patterns — repeated failed SSH logins, Nginx 4xx error floods, and other abuse signals. Fail2Ban is installable via the package manager on all major Linux distributions and works with any log file format.

Log centralization: Shipping logs to a remote syslog server means that even if the server is compromised and local logs are wiped, you retain the audit trail. rsyslog supports remote logging natively. For teams already running an ELK stack (Elasticsearch, Logstash, Kibana) or a managed log aggregation service, configure the server’s rsyslog.conf to forward to the central receiver.

Monarx malware detection: InMotion’s Premier Care bundle includes Monarx, a file-scanning malware detection engine designed specifically for web hosting environments. Monarx detects web shell uploads, malicious PHP injections, and cryptocurrency miners — the most common malware targeting Linux servers in web hosting contexts. It runs at the kernel level without the performance impact of traditional antivirus solutions.

Scheduling Regular Audits

Hardening at provisioning time degrades over time if not maintained. Set a quarterly review cycle covering:

• Review open ports against current application requirements
• Audit user accounts and SSH authorized_keys for all users
• Check AIDE integrity database for unexpected file changes
• Review sudo grants and remove any that are no longer needed
• Apply any security patches that weren’t automatically applied
• Review Fail2Ban and firewall logs for attack pattern changes

The servers with the cleanest security records aren’t the ones that got hardened once and forgotten. They’re the ones where someone checks the work on a schedule.

Related reading: DDoS Protection Strategies for Dedicated Infrastructure | Zero Trust Security on Bare Metal