Securing Apache mod_status and Correctly Interpreting Status Values

What mod_status Displays

The Apache module mod_status provides information about the running web server. For example, it helps answer questions such as how many workers are currently active and which requests are being processed. The following explanations refer to Apache HTTP Server 2.4; the documentation for the development branch is separate and cannot be applied to this version without verification.

A handler Generates the status output for a configured URL path. A "Location" section can pass this path to the handler server-status assign; a file with the same name in the DocumentRoot is not required for this. The path therefore provides access to server diagnostics and is not a regular page served from the file system.

The HTML view is suitable for manual diagnosis. The version with ?auto provides a machine-readable representation that a monitoring system can retrieve on a regular basis. The details that are available depend, among other things, on the server configuration. This parameter does not turn the endpoint into a separate service: its output must also be protected against unauthorized access.

This requires that mod_status be loaded and that you have permission to edit the appropriate Apache configuration file. For access restrictions, the required authorization modules must also be available. How a module is enabled and which files are responsible for this varies depending on the distribution and installation; therefore, a single file path is not a universally applicable starting point.

For Apache Monitoring The output serves as a diagnostic tool, but it is not a comprehensive application performance monitoring solution. For example, it shows that workers are busy, but it does not explain whether a database, a backend, or a slow client is causing the delay. To identify the root cause, you’ll also need the appropriate application, system, and log data.

Status Data and Their Security Implications

The status page displays, among other things, busy and idle workers, as well as information on the start or restart time and the runtime. Busy workers are not available as free capacity at the time of the query. How critical a ratio of busy to idle workers is can only be assessed by looking at the history and the actual configured worker limit.

The time period helps contextualize aggregated values over time: An average since the start may mask short-term spikes in load. Similarly, a query with few available workers is initially just a snapshot. Repeated queries, combined with response times and errors, provide a better basis for investigating a potential shortage.

With ExtendedStatus Apache logs additional details, including aggregated hits and data volumes, as well as information about current hosts and requests. When mod_status is loaded, this logging is enabled by default in Apache 2.4. However, making an explicit configuration decision makes it clear what level of detail is intended for the specific operation.

More detailed logging comes at a cost: it requires additional effort and can slow down the server. Therefore, weigh the diagnostic benefits against this effort, rather than automatically viewing more details as a free improvement. On the other hand, without ExtendedStatus, you’ll be missing information that can be helpful for identifying ongoing requests.

The output may reveal ongoing requests and client information. Therefore, treat it as sensitive operational data and not as a public health check. The HTML view and ?auto require the same level of access protection; a path that is difficult to guess does not prevent access by someone who knows it or discovers it.

Check Access Paths and the Worker Model

Before making any changes, identify the installed Apache version and the active multiprocessing module (MPM). Also check which virtual hosts are serving the listener in question, whether reverse proxies are forwarding requests, and which access rules are already in effect. Only with this overview can you assess where a new rule will take effect and which existing configurations it might affect.

A local monitoring agent could retrieve the status using a loopback address. However, a successful local retrieval only indicates that this specific path—using the selected address, port, and virtual host—is functioning properly. It does not prove that other hosts are protected, nor does it prove that external access is blocked.

A second approach could involve using a reverse proxy and a different virtual host. Different redirects or access rules may apply there; you should also check which client address Apache actually uses for authorization. Consider the Access Path Therefore, this includes the proxy, host selection, and Apache rules, rather than applying the local test to the entire topology.

The MPM determines how Apache uses processes and, if applicable, threads for processing. A process is an operating system unit; threads run within a process and can perform tasks there. The significance of the number of workers therefore depends on the model used. The Comparison of Apache Worker Models explains the differences between Prefork, Worker, and Event.

Especially when it comes to event-MPM Open connections do not automatically mean that worker threads are occupied on a permanent basis. Certain waiting states may be handled differently than the active processing of a request. Therefore, note the active MPM before making a capacity decision based on connection and worker counts.

Set Up a Local Status Endpoint

Before making the change, check whether Apache HTTP Server 2.4 is running, mod_status is loaded and the required authorization modules are available. Also, list the existing virtual hosts and access rules. Module activation and configuration paths vary depending on the distribution; the following example belongs in the appropriate Apache configuration file, not in a generic file.

The example turns on ExtendedStatus explicitly specifies it and assigns the path to the status handler. Require local Restricts access according to Apache's rules for local connections. The directive for detailed logging is located outside the `Location` section. Before applying this change, you must verify how this section interacts with your existing configuration.

ExtendedStatus On

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

Have the change reviewed and approved in accordance with your operational process before applying it. The example is a starting point; it is not a guarantee for all virtual hosts or proxy paths. In particular, existing authorization sections can influence which rule applies to a specific request.

After running the application, you can retrieve the machine-readable output locally using the following command. It requires a listener to be set up on the selected loopback address and the default port 80. Also check whether the request reaches the intended virtual host; if necessary, you’ll need to adjust the port and host selection to match your environment.

curl --fail --silent --show-error 'http://127.0.0.1/server-status?auto'

A failed retrieval is, at first, merely an indication—not a definitive error diagnosis. In addition to authorization issues, other possible causes include a different listener, a different host mapping, or a redirect. Conversely, a successful local retrieval does not necessarily mean that other access paths are secure.

Securely Expand Monitoring Access

Choose the access method based on where the monitoring is running and who needs the output. An agent on the same host can use the local restriction. If an external system needs to access the data, access should be limited to only the sources that are actually needed and then verified via the designated network path.

At Require ip It is not solely the address that the monitoring server sees that matters. Behind a reverse proxy, the installed configuration must provide the address that Apache actually uses for authorization. Verify this mapping in a real-world scenario before you grant access to a network; a presumed client address does not constitute reliable access control.

Several Require-Directives within a section generally behave like a "Or" operator: If a request meets one of the conditions, that may be sufficient. If a client is required to come from the permitted network and also log in, explicitly state the conditions in a <RequireAll>-Combine the containers and test both requirements individually.

With Basic Authentication, only a suitable transport protocol such as TLS protects the credentials during transmission. A separate management network can further restrict access, but it is no substitute for effective Apache authorization. Even there, only authorized systems should be able to retrieve the HTML and machine-readable output.

Interpreting Status Values Correctly

The status page provides answers to various diagnostic questions using different data. Read the Worker Assignment Therefore, it is not isolated: it describes the state at the time the information is retrieved. Additional request details depend on the configuration and, in particular, on `ExtendedStatus`; the fields that appear may vary depending on the server and MPM.

Suppose a query shows many busy workers and only a few available ones. This could be a brief peak in load or indicate sustained pressure. Repeat the query and compare the trend with response times, errors, and the actual worker limit before considering a capacity change.

At event-MPM Certain waiting states can be handled by the listener rather than by permanently bound worker threads. "Writing" and "Keep-alive" should therefore be interpreted as connection states, not simply as the number of occupied threads. Terminating processes and older generations following a graceful restart can also affect the picture; check the details for your installed 2.4 version.

To help classify the architecture, the Comparison of Event MPM and Worker MPM the status display. The MPM selection explains how Apache organizes connections and workloads; however, it does not replace monitoring the specific server and its application.

Monitoring Status Data Over Time

For Apache Monitoring, a single status page is just a snapshot. Get the machine-readable output via ?auto Retrieve the values regularly from an authorized agent and save them with a timestamp. This way, you can tell, for example, whether a low number of available workers is just a temporary occurrence or persists across multiple queries.

For a Interval rate You compare a cumulative counter with its previous value and divide the difference by the elapsed time. For example, if the number of hits increases by 120 within 60 seconds, this corresponds to an average of two hits per second for that interval. This average does not provide any information about the distribution within the minute.

Before calculating the difference, check the startup or restart information and the counter reading. If the server has been restarted or a counter has decreased since the previous retrieval, treat this as a reset and start a new comparison series. A negative traffic rate derived from two counter readings would be misleading in this context; failed queries should also remain identifiable in the history.

The averages reported by mod_status over the server's runtime smooth out short-term load spikes. A time series with an appropriately chosen query interval shows changes more accurately, but it may also miss events that occur between two queries. Therefore, choose the interval based on the diagnostic question and take into account the effort required for data collection and storage.

Stored status data must also be protected: Depending on the output, it may contain request and client information. Restrict access to the agent, storage, and analysis to authorized individuals and systems. Also, specify how long raw data and derived metrics will be retained for the respective operational purpose.

Check Access and Error Messages

After a change has been approved, first verify that authorized access is granted, such as by the local monitoring agent. Then, from a network location that is explicitly not permitted, check both the HTML page and the variant ?auto. Neither of them is allowed to provide status data there. Testing just one location or just one access path is not sufficient.

Repeat the test for the virtual hosts that can actually be reached and, if applicable, for direct connections and those routed through a reverse proxy. A successful local test does not prove that the proxy enforces the same level of protection. Also pay attention to redirects: The key factor is whether sensitive status data is output at the end of an access path.

If a valid retrieval fails, check the following in addition to the Authorization This includes the listener, address, and port, as well as the selection of the virtual host. Proxy and redirect rules can also route the request differently than expected. Therefore, a single error does not necessarily indicate an incorrect access rule or a faulty handler.

Check existing configurations for outdated access directives such as Order and Deny. Their ill-considered mixing with the newer ones Require-Rules can lead to unexpected results. Check the combination that is actually effective, rather than assuming the final access is permitted based on a single rule that allows it.

Furthermore, a protected location is not necessarily the only possible status endpoint. If mod_status is loaded, its handler can also be configured on a per-directory basis, including .htaccess be available. Therefore, check existing entries and permitted delegations—especially on shared servers—to ensure that no additional unprotected handlers can be set up.

From Indicators to Operational Decisions

If, on a recurring basis, many workers are busy and only a few are free, this is an indication of potential capacity constraints, but it does not yet prove the cause. Compare this trend with response times, error rates, and the actual worker limit in effect. Only by looking at the big picture can you determine whether the utilization coincides with noticeable problems and how persistent those problems are.

Before you increase a limit, check the available memory and the additional requirements of the intended processes or threads. At the same time, investigate why processing takes so long: Increasing parallelism may not address the root cause and could tie up additional resources. Changes should therefore be made as part of a controlled operational process followed by monitoring.

For slow requests, repeated status checks can help narrow down current requests and associated processes. Compare the timestamps with access and error logs, as well as with data from the application and its backends. A transient request may disappear between two checks; a single occurrence neither reliably identifies a specific application as the cause nor proves that an attack has occurred.

For an eye-catching Process ID You can also check operating system data such as CPU and memory usage. This correlation is another clue, but it is not a substitute for synchronizing the data with requests and logs. Especially when observations are repeated, you should keep in mind that processes and the requests they are currently processing may change.

With event-MPM, also be aware of terminating processes and old generations following a graceful restart. They can affect the system state during the transition; open connections should not automatically be equated with worker threads that are permanently occupied. Check the specifics of the installed Apache 2.4 version before drawing any long-term capacity conclusions from such a transition phase.