Linux Server Hardening: 15 Steps for an SME Environment

Summary: A Linux server isn't "secure" the moment it's installed — the defaults are reasonable, but they aren't enough. A 15-step hardening checklist at SME scale (key-based SSH, root login disabled, fail2ban, ufw firewall, automatic security patches, log forwarding, user management, audit log, NTP sync, file-integrity monitoring) configures the server to resist baseline attacks. These 15 steps take 1–2 hours on an Ubuntu / Debian / RHEL host and become the standard for every server you build after that.

In SMEs, a Linux server is often left in "installed, running, don't touch" mode. A server with SSH wide open on the default port, root login enabled, password authentication accepted, and logs kept only on local disk is a candidate target for automated scanning bots. Brute-force attempts start in the first week, and when one of them lands a successful login, the attacker has the whole system.

In this article we cover the standard hardening steps for Linux servers at SME scale. Target audience: IT managers, system administrators, and decision-makers who want to turn "I installed Linux — now what?" into a practical checklist.

The Hardening Mindset

Hardening isn't a single tool — it's a discipline.

Three Core Principles

1. Shrink the attack surface — remove services you don't use
2. Tighten access — who is authorised to do what?
3. Improve visibility — collect logs, notice anomalies

CIS Benchmarks

The hardening guides published by the Center for Internet Security (CIS Benchmarks) are treated as the industry baseline. Separate publications exist for Ubuntu, RHEL, Debian, CentOS. The steps below are aligned with CIS Benchmark principles and distilled to SME practice.

15-Step Hardening Checklist

1. Up-to-Date System

The first command after a fresh install:

# Debian/Ubuntu
sudo apt update && sudo apt upgrade -y

# RHEL/Rocky/Alma
sudo dnf upgrade -y

Pull every patch — the system should be at current.

2. SSH Key-Based Access

Password-based SSH is exposed to brute force. Switch to key-based authentication.

On the client (local Windows / Mac / Linux):

ssh-keygen -t ed25519 -C "user@firma.com.tr"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server.firma.com.tr

On the server, in /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes

Then:

sudo systemctl restart ssh

3. Disable Root SSH Login

In /etc/ssh/sshd_config:

PermitRootLogin no

Root access is then reached by SSH-ing as a regular user and using sudo. Even with a compromised account, the attacker doesn't land on root directly.

4. Change the SSH Port (Optional)

The default port 22 is the prime target for automated scanners. Moving to a different port (e.g. 2222) is "security through obscurity" — not a defence on its own, but it cuts down the noise considerably.

Port 2222

Open the new port in the firewall and close 22.

The stronger alternative: don't expose SSH to the internet at all — put it behind a VPN.

5. UFW or firewalld

Close every port you don't need.

Ubuntu / Debian (UFW):

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp  # SSH
sudo ufw allow 80/tcp    # HTTP
sudo ufw allow 443/tcp   # HTTPS
sudo ufw enable

RHEL (firewalld):

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

6. Fail2ban

Automatically blocks brute-force attempts.

sudo apt install fail2ban -y

In /etc/fail2ban/jail.local:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
port = 2222

sudo systemctl enable --now fail2ban

After 5 failed attempts within 10 minutes the source IP is banned for 1 hour.

7. Automatic Security Patches

If new security vulnerabilities don't get patched, you stay exposed.

Ubuntu / Debian:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

RHEL / Rocky:

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

Configure it so only security patches are applied automatically; everything else stays manual.

8. Sudo Permission Management

Not every user should hold sudo.

# Add a new user to sudo only if needed
sudo usermod -aG sudo username

# Never edit sudoers directly
sudo visudo

Log sudo commands:

Defaults logfile=/var/log/sudo.log

9. Disable Unneeded Services

A running service you don't use is an attack vector you don't see.

# Which services are running?
systemctl list-units --type=service --state=running

# Disable an unneeded service
sudo systemctl disable --now servicename

Typical candidates to disable: avahi-daemon, cups (printer sharing), bluetooth (on a server).

10. Audit Log (auditd)

System-level: who did what?

sudo apt install auditd -y
sudo systemctl enable --now auditd

Custom rules in /etc/audit/rules.d/audit.rules:

-w /etc/passwd -p wa -k passwd_changes
-w /etc/sudoers -p wa -k sudoers_changes

Logs land in /var/log/audit/audit.log.

11. Centralised Logging — Syslog Forwarding

Logs shouldn't live only on the server; ship them to a central log host.

/etc/rsyslog.d/forward.conf:

*.* @@logserver.firma.local:514

On the central log host: Graylog, ELK, Wazuh.

12. NTP / chrony — Time Synchronisation

A log with the wrong timestamp is a useless log. Time synchronisation is mandatory.

sudo apt install chrony -y
sudo systemctl enable --now chrony

For Türkiye, in /etc/chrony/chrony.conf:

server tr.pool.ntp.org iburst

13. Disk Encryption (LUKS)

Servers carrying sensitive data should be set up encrypted (much easier at install time than later):

• LUKS — built into Linux
• Centralised key management (HSM, or network-bound with Tang / Clevis)

What it gets you:

• Even if the disk is physically stolen, the data can't be opened
• A password or key is required at boot

14. File-Integrity Monitoring — AIDE or Tripwire

Did a critical file change?

sudo apt install aide -y
sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Run a regular check:

sudo aide --check

Unexpected changes (an attacker modifying a file) get flagged.

15. Antivirus (ClamAV) — Optional

Not strictly required on Linux but useful for file-server roles in particular (when Windows users download and open files):

sudo apt install clamav clamav-daemon -y
sudo freshclam

Weekly cron scan:

0 3 * * 0 root clamscan -r --remove /home /var/www

Additional Disciplines

Beyond the 15 steps, also worth considering:

SELinux or AppArmor

Mandatory Access Control — constrain how applications behave.

• RHEL / CentOS: SELinux on by default
• Ubuntu: AppArmor on by default
• At SME scale, leaving the defaults intact is reasonable

Resource Limits — limits.conf

Cap a user's ability to fork-bomb or hog resources:

* hard nproc 1000
* hard nofile 4096

sysctl Kernel Parameters

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

net.ipv4.tcp_syncookies=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
kernel.randomize_va_space=2

CrowdSec — Modern Fail2ban Alternative

Community-sourced threat intelligence plus local blocking. Modern, open source.

curl -s https://install.crowdsec.net | sudo sh

Regular Maintenance

Hardening isn't a one-shot — it needs ongoing care.

Monthly

• Patch-status review
• Log review
• Disk-usage check
• AIDE check

Quarterly

• Certificate renewal check
• Backup-restore test
• Unauthorised-account audit

Annual

• Full security audit
• CIS Benchmark comparison
• Penetration test

What Yamanlar Bilişim Offers

Our Linux-hardening support areas at SME scale:

• Audit of the current Linux server-security posture
• Rollout of the 15-step hardening checklist
• CIS Benchmark conformance checks
• Centralised-logging architecture
• AIDE / Tripwire deployment
• Fail2ban / CrowdSec configuration
• Patch-management automation
• Annual hardening refresh

Frequently Asked Questions

ssh serdar@server
sudo systemctl restart nginx

That's both safer (no direct login as root) and audit-friendly (you can see who did what).

• Fail2ban: classic, built in, log-driven, blocks by IP
• CrowdSec: modern, shares community-wide threat intel, ML-aware

For an SME, fail2ban is a fine starting point. CrowdSec is the "modern" option — it picks up newly-seen attacker IPs from the global community and bans them before the brute force even starts. The pick depends on your team's technical maturity.

• Wazuh: open-source SIEM that combines logs, EDR, and compliance in one platform
• Graylog: open-source log management, user-friendly
• ELK Stack: the most flexible, but operationally heavy
• Splunk: enterprise; expensive for an SME

For a first choice we recommend Wazuh — at SME scale it's satisfying, free, and comprehensive.

Conclusion

Linux server hardening moves you from the "installed, running, done" mindset to the "installed, hardened, monitored" discipline. The 15-step list takes 1–2 hours at SME scale and becomes the standard for every server you build after. Regular maintenance — monthly patching, quarterly access audits, annual full review — keeps the discipline alive.

Yamanlar Bilişim offers a Linux-hardening package sized to your needs and brings your existing servers up to a CIS-Benchmark-aligned level — turning "default-installed" boxes into resilient infrastructure that the scanning bots quickly lose interest in.