Protect or disable Apache server-status

The fix

# Best: if nothing scrapes it, remove the module entirely
sudo a2dismod status

If something does scrape it, restrict it rather than leaving it open:

<Location /server-status>
    SetHandler server-status
    Require local
    Require ip 10.0.1.5
</Location>
ExtendedStatus Off

Why it matters

/server-status is not a health check. It is a live operational dashboard, and it publishes:

• Every request currently being served — the full URL, including query strings and anything else in the path.
• Client IP addresses for those requests.
• Every vhost the server hosts, which enumerates your internal hostnames.
• Uptime, worker state, request rates, and the server version.

With ExtendedStatus On — which mod_status enables by default in some packagings — you get the full request line for every worker. That means session tokens, password reset links, API keys and anything else people put in query strings appear on the page, live, to whoever loads it.

Scanners look for this path continuously and it is trivially findable. It is one of the most reliably productive URLs on the internet for reconnaissance.

Require local is narrower than it sounds

The default Debian status.conf uses:

<Location /server-status>
    SetHandler server-status
    Require local
</Location>

Require local allows 127.0.0.1, ::1, and the server’s own IP addresses. That is usually fine — but note two things:

Behind a reverse proxy or load balancer, every request appears to come from the proxy. If the proxy is on the same host, or if mod_remoteip is not configured, Require local may match traffic that originated anywhere. A proxied /server-status request can pass a Require local check that was never meant to allow it.

Require local is not Require ip 127.0.0.1. If you want strictly loopback, say so.

The safest position is that the module isn’t loaded. The second safest is an explicit IP allow-list plus ExtendedStatus Off.

mod_info is worse

While you’re here:

sudo a2dismod info

mod_info serves /server-info, which is your entire parsed configuration — every module, every directive, every vhost, every path. There is no production scenario where that should be reachable. It is less common than mod_status and strictly more damaging.

Verify it worked

Check whether the module is loaded at all:

sudo apachectl -M 2>/dev/null | grep -E 'status_module|info_module'

Nothing is the goal.

Then test it the way an attacker would — from outside, not from the server:

curl -si https://your.site/server-status | head -1
curl -si https://your.site/server-status?auto | head -5
curl -si https://your.site/server-info | head -1

Expect 403 or 404. A 200 with a table of requests is a live disclosure, and ?auto is the machine-readable variant people forget to block separately.

Check every vhost, not just the default — a <Location> in one vhost doesn’t cover the others:

sudo apachectl -S 2>/dev/null | grep -oE 'namevhost [^ ]+' | awk '{print $2}' | \
while read h; do
  printf '%-30s %s\n' "$h" "$(curl -sk -o /dev/null -w '%{http_code}' --resolve "$h:443:127.0.0.1" "https://$h/server-status")"
done

Any 200 there is the finding.

Confirm ExtendedStatus, which decides how bad an exposure would be:

sudo grep -rn 'ExtendedStatus' /etc/apache2/ /etc/httpd/ 2>/dev/null

Before you apply this

Disabling mod_status silently blinds anything that scrapes it — and blinding a monitor is a failure you notice late, because a monitor that gets a 404 usually just stops reporting rather than alerting.

Find out what polls it before removing:

sudo grep -c 'server-status' /var/log/apache2/access.log 2>/dev/null
sudo grep 'server-status' /var/log/apache2/access.log 2>/dev/null | \
  awk '{print $1}' | sort | uniq -c | sort -rn | head

Those addresses are your consumers. Common ones: Munin, Nagios, Zabbix, Datadog’s Apache integration, and mod_status-based autoscaling.

If something legitimate needs it, keep the module and allow that address explicitly — the Require ip form above. Don’t leave it open because a monitor needs it; the monitor needs one IP, not the internet.

ExtendedStatus Off reduces what monitors can report (no per-request detail), which some integrations depend on. That’s the trade: leave it on and the page is a credential leak if it’s ever exposed, or turn it off and your dashboard loses detail. If you’ve restricted access properly, ExtendedStatus On is defensible — it is only catastrophic when combined with an open <Location>.

Reload rather than restart, and apachectl -t first — a <Location> block referencing SetHandler server-status after you’ve removed the module is a startup error.

Related

• Disable unused modules — the broader audit.
• Disable information disclosure — listings and version banners.