Patching Linux and Windows servers without the drama

Most successful attacks don’t use clever new techniques. They use known vulnerabilities on servers that haven’t been patched, or on systems so old they no longer receive patches at all. A steady, boring patching routine closes most of that risk.

Start with an inventory

You can’t patch what you don’t know about. For every server, record:

• Operating system and version, and its end-of-support date.
• What runs on it, and who depends on it.
• Whether it’s reachable from the internet.
• How it’s backed up.

End-of-life systems go to the top of the list. CentOS Linux 7 stopped receiving updates on June 30, 2024, and Windows Server 2012 and 2012 R2 reached end of extended support on October 10, 2023. Servers like these won’t get fixes for newly discovered vulnerabilities, so plan a migration to a supported release.

Automate security updates on Linux

On Debian and Ubuntu, unattended-upgrades installs security updates automatically:

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

Its activity is logged under /var/log/unattended-upgrades/, so check there that it’s actually running.

On RHEL, AlmaLinux and Rocky Linux, dnf-automatic does the same job:

sudo dnf install dnf-automatic
# In /etc/dnf/automatic.conf set:
#   upgrade_type = security
#   apply_updates = yes
sudo systemctl enable --now dnf-automatic.timer

Newer releases that ship DNF5 package this slightly differently, so check your distribution’s documentation for the exact package and timer names.

Don’t forget reboots

Kernel and core library updates only take effect after a reboot, or with a live-patching service. Make it visible when a reboot is pending:

• Debian and Ubuntu create /var/run/reboot-required.
• On the RHEL family, needs-restarting -r (from dnf-utils) tells you.

Schedule reboots in a regular maintenance window rather than letting them pile up for months.

Windows Server: control the schedule

Microsoft releases security updates on the second Tuesday of each month (Patch Tuesday). Rather than letting servers update and restart whenever they like:

• Manage updates centrally with Group Policy and WSUS, or a cloud update manager.
• Define maintenance windows per server group.
• Approve updates for a test group first, then production a few days later.

Use rings, not hope

Group servers into rings and patch them in order:

1. Test: non-critical or staging servers, patched first.
2. Early production: a small set of real servers, a day or two later.
3. Everything else, once the first rings look healthy.

Before each window, make sure backups or snapshots are current and you know how to roll back. After it, check that services, scheduled jobs and monitoring are green.

The hardening steps people skip

Patching fixes known bugs. Hardening reduces what an attacker can reach in the first place:

• Use SSH keys instead of passwords, and disable direct root login.
• Keep RDP off the public internet. Put it behind a VPN or gateway.
• Run a host firewall that allows only the ports each server needs.
• Remove software and services you don’t use.
• Stop advertising versions. In Apache, ServerTokens Prod and ServerSignature Off. In PHP, expose_php = Off. And never show error details to visitors in production (display_errors = Off).
• Serve websites over HTTPS only, and add security headers such as Strict-Transport-Security.

A monthly routine that works

• Security updates applied automatically, with logs reviewed.
• One maintenance window for reboots and larger updates.
• A short report: what was patched, what’s pending and which systems are approaching end of life.

If your servers haven’t had this kind of attention for a while, we can help you catch up and then keep things on schedule.