Web Server Identification & Patching Checklist: 5 Checks (2026)

A CVE drops for Nginx, and the first twenty minutes go to working out which servers run the affected version. Meanwhile one host has an Apache nobody remembers installing, still listening, still unpatched. This page documents the 5 checks in the CtrlOps Identification and Patching audit, in the order the audit runs them.

Every threshold below is transcribed from the audit script itself. The audit answers two questions at once: what is actually running here, and how much of that can somebody else find out from outside.

Key takeaways

Five checks, and the two HIGH ones are the two that decide how bad an application bug gets to be.

• Two are rated HIGH: the worker process user and pending updates. One is MEDIUM, two are LOW.
• Only the config syntax test needs root, because nginx -t and apachectl configtest read the full config tree. Everything else reads the process table, an HTTP response and package metadata.
• Only the update check can fail on a patching basis, and only on apt. Debian and Ubuntu expose whether an update comes from a security pocket; on RHEL family, SUSE and Alpine every pending update is reported as a warning regardless of what it fixes.
• Version disclosure is LOW on purpose. Hiding the version slows automated scanning and protects nothing by itself. It is a filter, not a fix, and the fix is check 4.
• The whole audit takes about 9 seconds when CtrlOps runs it over your existing SSH connection. It is the fastest audit in the web server category.

Check 1: What web servers are installed and running?

You cannot patch what you do not know is installed, and the server that causes trouble is usually the one nobody remembers. A host that has been through two migrations often has both Nginx and Apache present, one serving traffic and one idle, still bound to a port and still carrying whatever vulnerabilities its last version had.

The audit detects Nginx, Apache, Caddy and Lighttpd by binary and by running process, reads the version from each, and reports whether it is running or stopped. It also names the URL it managed to probe, which tells you what the rest of the audit was able to see.

How to check manually

nginx -v 2>&1; pgrep -x nginx >/dev/null && echo "nginx running"
apache2 -v 2>/dev/null || httpd -v 2>/dev/null
pgrep -x apache2 >/dev/null || pgrep -x httpd >/dev/null && echo "apache running"

ss -tlnp | grep -E ':80|:443|:8080|:8443'

This check never warns or fails. It exists so the rest of the report can be read against a known stack, and so a second engine that nobody expected shows up in writing.

How to fix it

Nothing to fix. If the inventory names an engine you did not expect, decide whether it should be there:

sudo systemctl status apache2
sudo ss -tlnp | grep apache2

# If genuinely unused
sudo systemctl disable --now apache2
sudo apt purge apache2

Check 2: Does the Server header leak the exact version?

By default both servers announce themselves in every response: Server: nginx/1.25.4 or Server: Apache/2.4.58 (Ubuntu). That is a CVE lookup handed to a scanner for free. Suppressing it does not make the server safer, it removes the shortcut that mass scanning depends on.

The audit reads the Server header from the live response and looks for a version-shaped string. Without a live response, it falls back to checking whether server_tokens off or ServerTokens Prod is configured.

How to check manually

curl -sI https://yourdomain.com | grep -i '^server:'

grep -rn 'server_tokens' /etc/nginx/ | grep -v '#'
grep -rni 'ServerTokens' /etc/apache2/ /etc/httpd/ 2>/dev/null | grep -v '#'

There is no failure branch here, and that is deliberate. A visible version is an information leak with a real but modest effect, and treating it as a failure would put it alongside findings that are genuinely dangerous.

How to fix it

# In the http block
server_tokens off;

ServerTokens Prod
ServerSignature Off

ServerTokens Prod reduces the header to Apache. ServerSignature Off removes the version from generated error pages, which is the other place it commonly appears. On Nginx, removing the product name entirely needs a third-party module or a patched build, and is rarely worth it.

Check 3: Do worker processes run as root?

Both servers start as root so they can bind ports 80 and 443, then drop to an unprivileged user for the processes that handle requests. If that drop does not happen, every request is processed with full system privileges, and an application-level bug becomes a root shell rather than a contained problem.

The audit reads the process table twice: Nginx workers by command line, and Apache by executable name specifically. That second detail exists because matching Apache on the command line also matched things like tail -f /var/log/apache2/access.log, and an unprivileged user in that list was enough to mask an Apache that was genuinely running entirely as root.

How to check manually

ps -eo user=,args= | grep '[n]ginx: worker' | awk '{print $1}' | sort -u
ps -eo user=,comm= | awk '$2=="apache2" || $2=="httpd" {print $1}' | sort -u

grep -rn '^user ' /etc/nginx/nginx.conf
grep -rn 'APACHE_RUN_USER' /etc/apache2/envvars 2>/dev/null

How to fix it

# First line of /etc/nginx/nginx.conf
user www-data;   # or `nginx` on RHEL family

# Debian and Ubuntu: /etc/apache2/envvars
export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data

# RHEL family: /etc/httpd/conf/httpd.conf
# User apache
# Group apache

A user change needs a full restart rather than a reload, because the master process sets it at startup:

sudo systemctl restart nginx
ps -eo user=,args= | grep '[n]ginx: worker'

Check 4: Are web server or OpenSSL updates pending?

This is software that answers unauthenticated requests from the internet by design. A published vulnerability in Nginx, Apache or OpenSSL is being scanned for within hours, and the window between disclosure and mass exploitation is routinely shorter than a maintenance cycle.

The audit queries whichever package manager the host has, apt, dnf, yum, zypper or apk, for pending updates matching nginx, apache2, httpd, openssl and libssl. On apt it also reads whether those updates come from a security pocket.

How to check manually

# Debian and Ubuntu
sudo apt update
apt-get -s upgrade | grep '^Inst ' | grep -iE 'nginx|apache2|httpd|openssl|libssl'

# RHEL family
sudo dnf check-update | grep -iE 'nginx|httpd|openssl'

Two things to carry away. A warning on a Rocky or Alma host is not evidence that nothing security-related is waiting: run dnf updateinfo list security to find out. And openssl and libssl are included deliberately, because a TLS library flaw reaches you through the web server whether or not the web server itself was updated.

How to fix it

sudo apt update && sudo apt upgrade nginx openssl -y
sudo systemctl restart nginx

# RHEL family
sudo dnf update nginx openssl -y
sudo systemctl restart httpd

Restart rather than reload after an OpenSSL update. A reload keeps the existing master process, and the old library stays mapped in memory until the process is replaced.

Check 5: Does the config pass its own syntax test?

A broken config does not stop a running server. The process keeps the configuration it loaded at startup and carries on serving, so everything looks fine. The failure arrives on the next reload, which is usually a certificate renewal at 3am or a reboot after a kernel update, and the site is down at the exact moment nobody is watching.

The audit runs nginx -t and apachectl configtest as root and reads the exit status.

How to check manually

sudo nginx -t
sudo apachectl configtest   # or: sudo httpd -t

How to fix it

The test output names the file and line:

sudo nginx -t
# nginx: [emerg] unknown directive "proxy_passs" in /etc/nginx/sites-enabled/app.conf:12

sudo nano /etc/nginx/sites-enabled/app.conf
sudo nginx -t && sudo systemctl reload nginx

Then stop it happening again by gating the reload on the test:

# In your deploy script
nginx -t || { echo "config test failed, not reloading"; exit 1; }
systemctl reload nginx

What this audit does not cover

This audit reads the process table, package metadata, one HTTP response and the config test result. It does not check:

• HTTP response headers. HSTS, CSP, frame protection and cookie flags are the Security Headers audit.
• TLS. Protocol versions, ciphers, certificate expiry and the HTTPS redirect are the TLS Configuration audit.
• Permissions and limits. Config file modes, web root ownership, request caps and rate limiting are the Configuration Hardening audit.
• What the server exposes. Directory listing, dotfiles, backups and status endpoints are the Content Exposure audit.
• The rest of the host's patch state. Kernel, runtimes and every other package are the System Updates audit.
• Servers built from source. The update check reads package metadata, so an Nginx compiled by hand reports nothing pending no matter how old it is.

The manual audit problem at scale

Five checks on one host is ten to fifteen minutes: inventory the binaries, curl the header, read the process table, query the package manager, run the config test. Across ten servers with a mix of Debian and RHEL layouts, that is over two hours, and the part that goes wrong is the inventory.

The Apache nobody remembers installing is exactly the one a manual sweep misses, because you check what you expect to find. That is also the one still running an unpatched version.

How CtrlOps runs all 5 checks in one click

Instead of running these commands on every server by hand, CtrlOps runs the whole Identification and Patching audit over the SSH connection you already have open. Nothing is installed on the server: no agent, no daemon, no package, no new credentials. The checks are read-only POSIX shell that executes, streams its results back, and leaves nothing behind.

Watch it run

The recording below walks through the SSH and Access audit rather than this one, but the flow is identical for every audit in the catalog: pick it, watch the checks stream in, read the score, send the failures to the AI Terminal.

Step 1: Open the Audit tab

Connect to your server in CtrlOps and open the Audit tab in the left sidebar.

Step 2: Select Identification & Patching

Choose it from the Web Server category. All 5 checks are listed with their descriptions, severity levels and the estimated run time, about 9 seconds in total. Only the config syntax check needs root.

Step 3: Run it

The audit runs over your existing SSH session. Results stream in as they complete, so you watch each check pass, warn or fail rather than waiting on a final report.

Step 4: Read the report

You get a summary containing:

• A hardening score out of 100
• A severity breakdown: how many HIGH, MEDIUM and LOW findings
• Pass, warning, failed and skipped counts
• A findings table naming the engines, versions, worker accounts and pending package counts

Step 5: Fix what failed

Select the failed findings and send them to the AI Terminal. Each proposed fix command appears with an explanation of what it changes. Nothing runs until you review and approve it, which matters here because the worker user fix needs a restart rather than a reload, and a restart drops every connection the server is currently holding.

Step 6: Re-run and compare

Run the same audit again after patching and watch the score move. Check 4 is the one to run weekly rather than after changes, because it goes from pass to fail with nothing on the server changing at all.

Conclusion

Two of these five describe how much damage an application bug gets to do, and both of them are usually correct on a well-built server and quietly wrong on one that has been through a migration. The other three are about knowing what you have before you need to know it in a hurry.

The inventory is the one to read even when everything passes, because the engine you did not expect is the one that will still be unpatched when the next advisory lands. The CtrlOps Security Audit runs all 5 in about 9 seconds per server.

The neighbouring checklists cover the other web server layers: security headers, TLS configuration, content exposure, configuration hardening and logging and monitoring.

Frequently asked questions