Linux Server Security Guide

A comprehensive guide to understanding and implementing Linux server hardening.

Table of Contents

1. Security Mindset

2. Defense in Depth

3. Attack Surface Reduction

4. SSH Security

5. Firewall Strategy

6. Intrusion Detection & Prevention

7. Kernel Hardening

8. User & Access Management

9. Audit & Monitoring

10. Automated Updates

11. Filesystem Security

12. Incident Response Basics

13. Ongoing Maintenance

Security Mindset

Security is not a one-time task — it's an ongoing process. Every server is a potential target, regardless of size or perceived importance. Attackers use automated tools that scan the entire internet for vulnerable systems.

Key principles:

• Least privilege: Grant only the minimum access needed
• Defense in depth: Multiple layers of security, so failure of one layer doesn't compromise the system
• Assume breach: Design systems assuming an attacker will get in, then limit what they can do
• Monitor and respond: Detection is as important as prevention

Defense in Depth

Our scripts implement multiple security layers:

┌──────────────────────────────────────────────┐
│  Layer 7: Application Security               │
│  (Your application code, WAF)                │
├──────────────────────────────────────────────┤
│  Layer 6: Authentication & Authorization     │
│  (SSH keys, sudo, PAM, fail2ban)             │
├──────────────────────────────────────────────┤
│  Layer 5: Network Security                   │
│  (Firewall, rate limiting, IP filtering)     │
├──────────────────────────────────────────────┤
│  Layer 4: OS Hardening                       │
│  (Kernel params, sysctl, module blacklist)   │
├──────────────────────────────────────────────┤
│  Layer 3: Filesystem Security                │
│  (Permissions, mount options, SUID cleanup)  │
├──────────────────────────────────────────────┤
│  Layer 2: Monitoring & Auditing              │
│  (auditd, logging, alerting)                 │
├──────────────────────────────────────────────┤
│  Layer 1: Patch Management                   │
│  (Automatic security updates)                │
└──────────────────────────────────────────────┘

Attack Surface Reduction

Before hardening, reduce what attackers can target:

Remove unnecessary packages

# List installed packages
dpkg -l                        # Debian/Ubuntu
rpm -qa                        # RHEL/CentOS

# Remove examples
apt purge telnet ftp rsh-client    # Debian/Ubuntu
yum remove telnet ftp rsh          # RHEL/CentOS

Disable unnecessary services

# List all enabled services
systemctl list-unit-files --state=enabled

# Disable services you don't need
systemctl disable --now avahi-daemon
systemctl disable --now cups

Close unnecessary ports

# Check open ports
ss -tulnp                      # Shows all listening ports
nmap -sT localhost             # Port scan yourself

SSH Security

SSH is the primary remote access method and the #1 attack target on internet-facing servers.

Why disable password authentication?

Passwords are susceptible to brute-force attacks. An internet-facing SSH server sees thousands of brute-force attempts daily. SSH keys are cryptographically stronger and cannot be brute-forced.

Key security settings explained

Before disabling password auth

1. Generate an SSH key pair on your workstation:

   ssh-keygen -t ed25519 -C "your-email@example.com"

2. Copy the public key to the server:

   ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

3. Test key-based login in a new terminal before applying hardening

4. Only then run harden-ssh.sh

Firewall Strategy

A firewall should implement the principle of default deny — block everything, then explicitly allow only what's needed.

Default policy

Incoming:  DENY ALL (then allow specific ports)
Outgoing:  ALLOW ALL (restrict if possible)
Forward:   DENY ALL (unless acting as router)

Typical server rules

Rate limiting

SSH rate limiting (via ufw limit) allows 6 connections per 30 seconds per IP. This stops brute-force while allowing normal use.

Intrusion Detection & Prevention

Fail2Ban: How it works

1. Fail2Ban monitors log files for authentication failures

2. After maxretry failures within findtime, the IP is banned

3. Ban lasts for bantime, then the IP is released

4. Recidive jail catches repeat offenders with escalating bans

Progressive ban strategy

First offense:   1 hour ban     (sshd jail)
DDoS detection:  48 hour ban    (sshd-ddos jail)
Repeat offender: 1 week ban     (recidive jail)

Monitoring Fail2Ban

# Overall status
fail2ban-client status

# SSH jail details
fail2ban-client status sshd

# Currently banned IPs
fail2ban-client get sshd banip

# Unban a specific IP
fail2ban-client set sshd unbanip 192.168.1.100

Kernel Hardening

Kernel parameters control fundamental OS behavior. Our sysctl-hardened.conf addresses:

Network stack hardening

• SYN cookies (tcp_syncookies=1): Protects against SYN flood DoS attacks
• Reverse path filtering (rp_filter=1): Drops packets with impossible source addresses (IP spoofing)
• ICMP redirects disabled: Prevents network route poisoning
• Source routing disabled: Prevents attackers from choosing packet routes

Memory protection

• ASLR (randomize_va_space=2): Randomizes memory layout, making exploits unreliable
• Core dump restriction (suid_dumpable=0): Prevents SUID programs from creating memory dumps that might contain secrets

Information disclosure prevention

• kptr_restrict=2: Hides kernel memory addresses from non-root users
• dmesg_restrict=1: Restricts kernel log access to root
• perf_event_paranoid=3: Restricts performance monitoring to root

User & Access Management

Password policy rationale

Sudo hardening explained

• requiretty: Sudo only works from a real terminal (not from cron or scripts, which could be hijacked)
• env_reset: Clears dangerous environment variables that could alter program behavior
• timestamp_timeout=15: Re-authentication required every 15 minutes
• Logging: All sudo commands logged to /var/log/sudo.log

The principle of least privilege

root account     → Direct login disabled, use sudo
Admin accounts   → sudo access with password
Service accounts → No login shell (/usr/sbin/nologin)
Application user → No sudo, limited file access

Audit & Monitoring

Why audit?

Auditing creates a forensic trail. When (not if) a security incident occurs, audit logs tell you:

• What happened (file modified, command executed)
• When it happened (timestamp)
• Who did it (user, process)
• How it happened (system call, tool used)

Key audit categories

Useful audit commands

# Search by key
ausearch -k identity                    # User/group changes
ausearch -k privilege_escalation        # Sudo usage

# Reports
aureport --summary                      # Overall summary
aureport --auth                         # Authentication report
aureport --login --summary              # Login summary
aureport --failed                       # Failed operations

# Recent events
ausearch -ts recent                     # Last 10 minutes
ausearch -ts today                      # Today's events

Automated Updates

Why auto-update security patches?

The #1 cause of successful attacks is unpatched vulnerabilities. The average time between vulnerability disclosure and exploitation is decreasing — automated updates close this window.

What gets auto-updated?

Only security updates are auto-applied. Feature updates and major version changes require manual review.

Risks and mitigation

Filesystem Security

Mount options

SUID/SGID explanation

SUID (Set User ID) binaries run with the file owner's privileges, not the caller's. A vulnerable SUID-root binary = instant root access for an attacker.

# Find all SUID binaries
find / -xdev -perm -4000 -type f 2>/dev/null

# Common legitimate SUID binaries
/usr/bin/sudo        # Needed
/usr/bin/passwd       # Needed
/usr/bin/su           # Needed (but consider removing)
/usr/bin/chsh         # Often unnecessary
/usr/bin/chfn         # Often unnecessary
/usr/bin/newgrp       # Often unnecessary

Review each SUID binary and remove the bit if not needed:

chmod u-s /usr/bin/chfn    # Remove SUID from chfn

Incident Response Basics

If you suspect a compromise:

1. Don't panic, don't power off

Powering off destroys volatile evidence (memory, network connections).

2. Capture evidence

# Current connections
ss -tulnp > /tmp/connections.txt

# Running processes
ps auxf > /tmp/processes.txt

# Logged-in users
w > /tmp/users.txt

# Recent logins
last -50 > /tmp/logins.txt

# Recent file modifications
find / -mtime -1 -type f 2>/dev/null > /tmp/modified-files.txt

3. Check audit logs

# Failed logins
aureport --auth --failed

# Privilege escalation
ausearch -k privilege_escalation -ts today

# File modifications
ausearch -k perm_mod -ts today

4. Isolate

Disconnect from the network if active compromise is confirmed.

5. Investigate and remediate

Use logs and forensic evidence to determine the attack vector and scope.

Ongoing Maintenance

Hardening is not one-and-done. Schedule regular reviews:

Weekly

• [ ] Review failed SSH login attempts: journalctl -u sshd | grep Failed
• [ ] Check Fail2Ban bans: fail2ban-client status sshd
• [ ] Review sudo usage: cat /var/log/sudo.log

Monthly

• [ ] Run filesystem audit: bash filesystem-hardening.sh --audit-only
• [ ] Check for new SUID binaries
• [ ] Review user accounts: awk -F: '$3 >= 1000' /etc/passwd
• [ ] Verify auto-updates are working

Quarterly

• [ ] Re-run the CIS benchmark checklist
• [ ] Review and rotate SSH keys
• [ ] Test backup restoration
• [ ] Review firewall rules

Annually

• [ ] Full security assessment
• [ ] Review and update password policies
• [ ] Audit service accounts
• [ ] Update hardening scripts to latest version

Additional Resources

• CIS Benchmarks — Free PDF downloads
• NIST 800-123 — Guide to General Server Security
• NIST 800-63B — Digital Identity Authentication Guidelines
• Mozilla SSH Guidelines — Modern SSH configuration

*Guide by Datanest Digital | support@datanest.dev*

Linux Hardening Scripts

Production-ready server hardening automation implementing CIS benchmarks and industry best practices.

Automated Bash scripts and configuration files for securing Ubuntu/Debian and RHEL/CentOS Linux servers. Covers SSH hardening, firewall setup, intrusion detection, kernel tuning, audit logging, and more — all aligned with CIS Benchmark Level 1 and Level 2 recommendations.