Server Hardening for Ubuntu Web Servers

By Khimananda Oli | Last reviewed: August 2026

Server hardening for Ubuntu web servers is the systematic process of reducing the operating system’s attack surface by removing unnecessary services, enforcing strict access controls, and applying security patches before attackers exploit known vulnerabilities. Most breaches I investigate in Nepal and globally stem from default configurations left unchanged after provisioning rather than sophisticated zero-day exploits. This guide provides the exact commands and configuration files needed to secure a production Ubuntu 24.04 LTS instance against automated scanners and targeted attacks.

How Do You Harden SSH Access for Ubuntu Web Servers?

SSH is typically the first service attackers probe. Default Ubuntu SSH configurations permit password authentication and root logins, both of which are unacceptable for production Ubuntu SSH server setups. You must enforce cryptographic key authentication and restrict access to specific users before exposing any web service.

Disable Password Authentication and Root Login

Edit the SSH daemon configuration file directly. Never rely on GUI tools or wrapper scripts for this critical step.

sudo nano /etc/ssh/sshd_config

# Apply these exact settings
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers deploy admin
X11Forwarding no
PrintMotd no

Validate the configuration syntax before restarting the service. A typo here can lock you out permanently.

sudo sshd -t
sudo systemctl restart sshd

Implement Fail2Ban for Brute Force Protection

Even with key-only authentication, attackers will hammer your SSH port. Fail2Ban monitors journal logs and dynamically updates nftables rules to block offending IPs. Install and configure it as part of your baseline Fail2Ban configuration.

sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

In /etc/fail2ban/jail.local, set aggressive thresholds for SSH:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
backend = systemd
maxretry = 3
bantime = 3600
findtime = 600

Restart Fail2Ban and verify active jails with sudo fail2ban-client status sshd. Monitor ban counts weekly; persistent high volumes indicate you should consider moving SSH to a non-standard port or implementing IP allowlisting via UFW.

How Do You Configure UFW Firewall Rules for Web Servers?

Uncomplicated Firewall (UFW) is Ubuntu’s default interface to nftables. A properly configured UFW policy denies all inbound traffic except explicitly allowed ports. This is non-negotiable for Ubuntu server security best practices. Many administrators enable UFW but forget to set the default deny policy, leaving the server effectively open.

Establish Default Deny Policy

Always set defaults before adding allow rules. The order matters because UFW processes rules sequentially.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

Verify the active rule set with sudo ufw status verbose. Confirm that only ports 22, 80, and 443 appear in the ALLOW IN column. Any additional ports require documented justification.

Rate Limit SSH Connections

UFW supports connection rate limiting natively, providing a lightweight alternative to Fail2Ban for smaller deployments:

sudo ufw limit 22/tcp comment 'SSH rate limit'

This blocks IPs attempting more than six connections within thirty seconds. Combine with Fail2Ban for defense in depth, but avoid stacking multiple rate limiters on the same port as they can interfere with legitimate administrative access during maintenance windows.

What Kernel Parameters Prevent Common Network Attacks?

The Linux kernel exposes tunable parameters via sysctl that directly impact network security posture. Default Ubuntu values prioritize compatibility over hardening. Adjusting these mitigates SYN floods, IP spoofing, and man-in-the-middle attacks without installing additional packages.

Apply Production Sysctl Hardening

Create a dedicated configuration file rather than editing the main sysctl.conf. This keeps customizations modular and auditable.

sudo nano /etc/sysctl.d/99-hardening.conf

# Prevent IP spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignore ICMP broadcast requests
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Disable source packet routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# Ignore send redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Block SYN attacks
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2

# Log Martians
net.ipv4.conf.all.log_martians = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Ignore ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Disable IPv6 if unused
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Apply changes immediately without reboot:

sudo sysctl --system

Verify each parameter took effect with sysctl net.ipv4.tcp_syncookies. Some cloud providers override sysctl values via cloud-init; check /etc/cloud/cloud.cfg.d/ if settings revert after reboot.

How Do You Automate Security Updates Without Breaking Services?

Manual patching fails at scale. Unattended-upgrades handles security patches automatically while excluding feature updates that might break application dependencies. This balance is critical for Ubuntu security update management in production environments where uptime matters as much as vulnerability remediation.

Configure Unattended-Upgrades Safely

sudo apt install unattended-upgrades apt-listchanges -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

Edit /etc/apt/apt.conf.d/50unattended-upgrades to restrict automatic installation to security origins only:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

Unattended-Upgrade::Package-Blacklist {
    "nginx";
    "postgresql-*";
    "php*";
};

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
Unattended-Upgrade::Mail "[email protected]";

Blacklisting application-critical packages prevents automatic upgrades from introducing breaking changes. Test this configuration in staging first. Monitor /var/log/unattended-upgrades/unattended-upgrades.log weekly to confirm patches apply cleanly.

Which File Permission and Service Practices Reduce Attack Surface?

Excessive file permissions and unused services are the most overlooked aspects of server hardening for Ubuntu web servers. Attackers who gain limited shell access escalate privileges through world-writable configs, SUID binaries, and dormant daemons listening on localhost.

Minimize Running Services

List all active systemd units and disable anything not required for your web stack:

systemctl list-units --type=service --state=running
sudo systemctl disable --now cups avahi-daemon bluetooth

For web servers, you typically need only sshd, nginx/apache, your application runtime, and monitoring agents. Everything else is attack surface. Document exceptions in your runbook.

How Do You Verify Hardening Effectiveness Continuously?

Hardening is not a one-time task. Configuration drift, package upgrades, and new team members introduce regressions. Implement continuous verification using OpenSCAP or Lynis to audit your baseline monthly. Export results to your monitoring stack so deviations trigger alerts alongside infrastructure metrics covered in our Ubuntu server monitoring guide.

sudo apt install lynis -y
sudo lynis audit system --quick

Review the generated report at /var/log/lynis.log. Focus on warnings tagged [HIGH] or [CRITICAL]. Create Ansible roles or Terraform modules that encode your hardening standards, then apply them idempotently across all instances. Manual hardening works for one server; automated, version-controlled hardening scales to fleets.

Securing Your Ubuntu Web Server Long-Term

Server hardening for Ubuntu web servers demands discipline beyond initial setup. Schedule quarterly reviews of SSH keys, UFW rules, and sysctl parameters. Integrate vulnerability scanning into your CI pipeline so hardened baselines ship with every deployment. If managing compliance frameworks like SOC 2 or ISO 27001, document each hardening control as evidence before auditors request it. Need help designing a hardened infrastructure that passes audits and survives traffic spikes? Reach out to discuss your environment.