How to Harden Linux Servers: Essential Security Practices Every Ops Engineer Should Know

This guide outlines comprehensive Linux security hardening steps—including account protection, service minimization, password policies, sudo usage, file system safeguards, rootkit detection tools, and post‑attack response—to help operations teams secure their servers against common threats.

Efficient Ops
Efficient Ops
Efficient Ops
How to Harden Linux Servers: Essential Security Practices Every Ops Engineer Should Know

1. Account and Login Security

Account security is the first line of defense. Remove unnecessary system users and groups such as adm, lp, sync, shutdown, halt, news, uucp, operator, games, gopher and groups like adm, lp, news, uucp, games, dip, pppusers, popusers, slipusers to reduce attack surface.

1) Delete special accounts and groups

After installation, Linux creates many default accounts and groups that are rarely needed; they should be removed promptly.

2) Disable unnecessary services

Identify and stop services that are not required for the server’s purpose (e.g., on a web server, only keep httpd and essential system services). Example of services that can often be disabled: anacron, auditd, autofs, avahi-daemon, bluetooth, cpuspeed, firstboot, gpm, haldaemon, ip6tables, ipsec, isdn, lpd, mcstrans, messagebus, netfs, nfs, nfslock, nscd, pcscd, portmap, readahead_early, restorecond, rpcgssd, rpcidmapd, rstatd, sendmail, setroubleshoot, yppasswdd, ypserv.

3) Password security policies

Use key‑based authentication instead of password authentication for remote logins. Store private keys securely and disable password logins via SSH configuration.

Linux servers are typically managed with tools like SecureCRT, PuTTY, or Xshell; key authentication is implemented through these tools and the SSH service.

4) Proper use of su and sudo

su allows switching to the root user but can expose the root password to many users. sudo grants limited privileges without revealing the root password, and its configuration resides in /etc/sudoers.

5) Trim login welcome messages

Remove or modify files that disclose system version information: /etc/issue, /etc/issue.net, /etc/redhat-release, and /etc/motd. To hide /etc/issue.net during SSH login, add Banner /etc/issue.net to /etc/ssh/sshd_config and then clear the file content.

2. Remote Access and Authentication Security

1) Replace telnet with SSH

Telnet transmits credentials in clear text; SSH encrypts traffic and should be used exclusively for remote access.

2) Manage shell history

Use the history command and protect ~/.bash_history to retain audit trails, backing up the file if necessary.

3) Enable tcp_wrappers firewall

Combine iptables with tcp_wrappers to provide a two‑layer firewall, controlling service access more granularly.

3. File System Security

1) Lock critical files

Use chattr to set immutable or append‑only attributes on important files, noting that this cannot be applied to directories such as /, /dev, /tmp, or /var.

2) Check and modify file permissions

Identify world‑writable files and directories and programs with set‑uid/set‑gid bits:

Find files with write permission for anyone: find / -type f -perm -2 -o -perm -20 | xargs ls -al Find directories with write permission for anyone: find / -type d -perm -2 -o -perm -20 | xargs ls -ld Find files with set‑uid or set‑gid bits: find / -type f -perm -4000 -o -perm -2000 -print | xargs ls -al Find files owned by root with set‑uid/set‑gid: find / -user root -perm -2000 -print -exec md5sum {} \; Find files without an owner: find / -nouser -o -nogroup

3) Secure /tmp, /var/tmp, and /dev/shm

Mount /tmp with nosuid,noexec,nodev options if it is a separate partition, or create a loopback filesystem with those options for a directory‑based /tmp. Example commands are provided in fstab and using dd, mke2fs, and mount.

4. Linux Rootkit Detection Tools

1) chkrootkit

Install and run chkrootkit to scan for known rootkits. Sample output shows infected binaries such as ifconfig, ls, login, netstat, ps, and top. If infection is detected, backing up data and reinstalling the system is recommended.

2) RKHunter

Use rkhunter --check --skip-keypress for automated scanning. Schedule daily checks via /etc/crontab with a line like 30 09 * * * root /usr/local/bin/rkhunter --check --cronjob.

5. Post‑Attack Handling Process

1) General response steps

1) Cut network connectivity. 2) Identify the attack source via logs and open ports. 3) Analyze intrusion vectors and vulnerabilities. 4) Backup user data. 5) Reinstall the operating system. 6) Patch software and system flaws. 7) Restore data and reconnect to the network.

2) Lock suspicious users

If immediate network isolation is impossible, lock any suspicious accounts and terminate their sessions.

3) Review system logs

Examine /var/log/messages, /var/log/secure, and users' .bash_history files, especially /root/.bash_history, for malicious commands.

4) Inspect and terminate suspicious processes

Use ps, top, or pidof to locate processes, then check the executable path via /proc/<pid>/exe and file descriptors via /proc/<pid>/fd.

5) Verify file system integrity

Run rpm -Va to verify package files and detect altered binaries.

6) Reinstall and recover

After backing up data, perform a clean OS installation and restore the data, then apply the security hardening measures described above.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

LinuxSecuritySysadminHardeningRootkit
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.