Essential Linux Security Hardening: Accounts, Services, and Rootkit Protection

Security is a perennial topic in IT, and after incidents like the "Prism" leaks, addressing information security has become urgent. Operations staff must adopt attacker‑mindset guidelines to patch threats and vulnerabilities.

1. Account and Login Security

Account security is the first line of defense. The following measures focus on Linux login accounts.

1) Remove Unnecessary Accounts and Groups

Linux creates many default users and groups that are rarely needed. Deleting them reduces attack surface. Examples of removable users include adm, lp, sync, shutdown, halt, news, uucp, operator, games, gopher ; removable groups include adm, lp, news, uucp, games, dip, pppusers, popusers, slipusers .

2) Disable Unneeded Services

After installation, many services start automatically. Unnecessary services should be stopped and disabled. For a web server, only the HTTP daemon and essential system services need to run. Commonly safe‑to‑disable services include:

anacron, auditd, autofs, avahi-daemon, avahi-dnsconfd, bluetooth, cpuspeed, firstboot, gpm, haldaemon, hidd, ip6tables, ipsec, isdn, lpd, mcstrans, messagebus, netfs, nfs, nfslock, nscd, pcscd, portmap, readahead_early, restorecond, rpcgssd, rpcidmapd, rstatd, sendmail, setroubleshoot, yppasswdd, ypserv

3) Password and Key Authentication Policies

Linux supports password and key authentication. Passwords should be at least six characters with numbers, letters, underscores, and special symbols, but complex passwords can lead to brute‑force attacks and operational burden. Key authentication, using a public key on the server and a private key locally, avoids brute‑force risks and is recommended for SSH logins.

Linux remote management tools such as SecureCRT, PuTTY, or Xshell use SSH and key authentication.

4) Proper Use of su and sudo

The su command switches users, often from a regular user to root. Because many users may need elevated privileges, sharing the root password is unsafe. sudo allows fine‑grained permission delegation without exposing the root password. Configuration resides in /etc/sudoers and follows the principle of granting the least privilege necessary.

5) Trim Login Welcome Messages

Banner files such as /etc/issue, /etc/issue.net, /etc/redhat-release, and /etc/motd disclose OS version and other details. Remove or modify their contents to avoid giving attackers useful information. To display a custom banner on SSH, add Banner /etc/issue.net to /etc/ssh/sshd_config.

2. Remote Access and Authentication Security

1) Replace Telnet with SSH

Telnet transmits credentials in clear text and is vulnerable to interception. SSH provides encrypted authentication and should be the default remote access method.

2) Manage Shell History

The history command and .bash_history file record user commands, useful for auditing. Protect or back up this file because attackers may delete it to hide their activity.

3) Enable tcp_wrappers Firewall

tcp_wrappers

works alongside iptables to filter service access, allowing administrators to permit or deny specific services.

3. Filesystem Security

1) Lock Critical Files

Use chattr to set immutable or append‑only attributes on important files (requires root). The counterpart lsattr displays attributes. Be aware that immutable flags can interfere with log rotation and package management, and cannot be applied to directories like /, /dev, /tmp, or /var.

2) Check and Fix File Permissions

Identify insecure permissions with commands such as:

find / -type f -perm -2 -o -perm -20 | xargs ls -al find / -type d -perm -2 -o -perm -20 | xargs ls -ld

Search for files with set‑uid/set‑gid bits: <code>find / -type f -perm -4000 -o -perm -2000 -print | xargs ls -al</code> List suid/sgid files owned by root: <code>find / -user root -perm -2000 -print -exec md5sum {} ; find / -user root -perm -4000 -print -exec md5sum {} ;</code> Find files without an owner or group: <code>find / -nouser -o -nogroup</code> 3) Secure /tmp , /var/tmp , and /dev/shm These directories are world‑writable and can host malicious scripts. If /tmp is a separate partition, add nosuid,noexec,nodev options in /etc/fstab : <code>LABEL=/tmp /tmp ext3 rw,nosuid,noexec,nodev 0 0</code> If /tmp is a directory on the root filesystem, create a loopback filesystem with the same options: <code>[root@server ~]# dd if=/dev/zero of=/dev/tmpfs bs=1M count=10000 [root@server ~]# mke2fs -j /dev/tmpfs [root@server ~]# cp -av /tmp /tmp.old [root@server ~]# mount -o loop,noexec,nosuid,rw /dev/tmpfs /tmp [root@server ~]# chmod 1777 /tmp [root@server ~]# mv -f /tmp.old/* /tmp/ [root@server ~]# rm -rf /tmp.old [root@server ~]# echo "/dev/tmpfs /tmp ext3 loop,nosuid,noexec,rw 0 0" >> /etc/fstab</code> 4. Linux Rootkit Detection Tools Rootkits replace system binaries or modify the kernel to hide malicious activity. Two common detection tools are: 1) chkrootkit Install manually, then run: <code>[root@server chkrootkit]# /usr/local/chkrootkit/chkrootkit</code> Sample output shows infected binaries such as ifconfig , ls , login , netstat , ps , and top . Infected systems should be backed up and reinstalled. 2) rkhunter Run a full check with: <code>[root@server ~]# /usr/local/bin/rkhunter --check --skip-keypress</code> Schedule daily scans via /etc/crontab : <code>30 09 * * * root /usr/local/bin/rkhunter --check --cronjob</code> 5. Post‑Attack Handling Process Even a well‑secured server can be compromised. The response workflow includes: Disconnect the network to stop ongoing attacks. Identify the attack source by analyzing logs ( /var/log/messages , /var/log/secure ) and open ports. Determine the cause and intrusion vector (vulnerabilities, exploited services). Back up user data immediately, ensuring no malicious payload remains. Reinstall the operating system to guarantee a clean environment. Patch all discovered vulnerabilities in the OS and applications. Restore data, re‑enable the network, and resume services. Additional steps: Lock suspicious accounts and terminate their sessions. Inspect system logs and .bash_history for malicious commands. Examine running processes (e.g., using pidof and /proc/<pid>/exe ) to verify binaries. Verify filesystem integrity with package managers, e.g., rpm -Va . By following these hardening measures and incident‑response procedures, administrators can significantly improve Linux server security.