Hardening Ubuntu Server: automation, security, monitoring

The first 30 minutes after installing Ubuntu Server are critical. The default image is not ready for production loads: open SSH, root password access, open files limit of 1024, no automatic updates. Within the first day, hundreds of bots from Mirai and Qbot botnets scan the server. In practice, 80% of servers in our clients' infrastructure arrive with these issues. Recently, a startup contacted us: their server was hacked on the second day after deployment, and user data leaked. We remediated the damage and reconfigured the system to prevent recurrence. Our Ubuntu Server hardening process ensures the system is attack-ready from day one.

We configure Ubuntu Server from scratch — from bare-metal to cloud instances on AWS, GCP, Yandex Cloud. Besides security, we optimize performance: configure swap, increase file-max, select I/O schedulers (none for SSD, mq-deadline for HDD), enable TCP BBR for network throughput. All this reduces latency and prevents crashes under peak load. Canonical recommends performing hardening after the first login.

What problems we solve

• Security by default: cloud images often have root login enabled. We disable password authentication, configure fail2ban with maxretry=3, bantime=3600, findtime=600, and UFW with admin whitelist. Additionally: user audit, removal of unused accounts, sudo configuration via wheel group.
• Performance: default open files limit (1024) is unsuitable for loaded applications. We increase it to 65536 and adjust vm.swappiness (10—20 for DB servers, 60 for desktops). For high-load web servers, we set net.core.somaxconn = 1024.
• Manageability: without update automation, the server risks vulnerabilities. We configure unattended-upgrades with notifications, and integrate monitoring via Prometheus node_exporter and centralized log collection through Loki.

Why standard installation doesn't suit production

According to Canonical's recommendation, hardening must be performed after the first login. We measured: time to hack a server with open SSH password is less than 2 hours. So the first 30 minutes after launch are critical. If these holes aren't closed, you risk not only data but also reputation. In practice, skipping Ubuntu Server hardening leads to incidents: SSH break-ins, outages due to incorrect network config (e.g., disabling IPv6 without DNS resolver setup), failures from file descriptor exhaustion.

Ansible automation speeds up setup 2–3 times compared to manual. Budget savings on incidents reach 30–40% after automation deployment.

How to perform basic hardening in 5 steps

1. Disable root password login and configure SSH keys.
2. Install and configure UFW with IP whitelist.
3. Install fail2ban with SSH protection settings.
4. Configure unattended-upgrades with notifications.
5. Increase open files limits to 65536.

# /etc/fail2ban/jail.local [sshd] enabled = true maxretry = 3 bantime = 3600 findtime = 600 

How to accelerate server deployment with automation

Using Ansible or Terraform reduces the time for each subsequent server to 2–3 hours. We prepare roles for Debian/Ubuntu (common, security, monitoring, time) and store them in Git along with Terraform configuration for cloud providers. This ensures repeatability and versioning. When recreating an instance, just run one playbook. If you need repeatable setup for a server fleet, contact us — we'll prepare Ansible roles.

How we configure Ubuntu Server turnkey

Concrete case: server setup for a high-load Go API. After minimal installation, we execute:

# Check current users and ports who
ss -tlnp
# Disable root password login
sed -i 's/^PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
sed -i 's/^PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl reload ssh

Create user app, add SSH key. Then basic configuration:

# Update packages
apt update && apt full-upgrade -y

# Time zone and hostname
timedatectl set-timezone Europe/Moscow
hostnamectl set-hostname prod-api-01

# Limits for loaded services
cat >> /etc/security/limits.conf << 'EOF'
* soft nofile 65536
* hard nofile 65536
* soft nproc 32768
* hard nproc 32768
EOF

Configure security:

# UFW
ufw default deny incoming
ufw default allow outgoing
ufw allow from <office-ip> to any port 22
ufw --force enable

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

And automatic updates:

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

For time synchronization we use systemd-timesyncd or chrony — depending on requirements. For financial applications, we install chrony with manual NTP server configuration. Example chrony config for production:

server 0.pool.ntp.org iburst server 1.pool.ntp.org iburst allow 10.0.0.0/8 

What's included in the setup

• Audit of current server state (cloud image, bare-metal).
• Hardening SSH, UFW, fail2ban, limits, NTP.
• Installation and configuration of software for the task (nginx, PostgreSQL, Redis, Docker).
• Scripting and delivery of Ansible playbook for reproducibility.
• Documentation: final configuration, operation manual.
• Support: 30 days of free consultation after delivery.

The result is a production-ready server from day one. The setup cost pays for itself within months by preventing downtime and breaches.

Process and timelines

Manual setup of one server takes 1–2 days. For server fleets, we use Ansible — reducing time to 2–3 hours per subsequent server. Average client budget savings from automation — 30% on incident time.

Why entrust the setup to us?

We have been doing DevOps infrastructure for over 5 years, completed setups for 40+ projects — from startups to enterprises. We guarantee compliance with best security practices (CIS benchmark on request). To configure a server for your project, contact us. Get a consultation on Ubuntu Server hardening.