Proteger el módulo mod_status de Apache e interpretar correctamente los valores de estado

Lo que muestra mod_status

El módulo mod_status de Apache proporciona información sobre el servidor web en funcionamiento. Por ejemplo, ayuda a saber cuántos procesos de trabajo están activos en ese momento y qué solicitudes se están procesando. Las explicaciones siguientes se refieren al servidor HTTP Apache 2.4; la documentación de la rama de desarrollo es independiente y no puede aplicarse a esta versión sin antes comprobarla.

A manipulador genera la salida de estado para una ruta URL configurada. Una sección «Location» puede pasar esta ruta al controlador server-status asignar; para ello no es necesario que exista un archivo con el mismo nombre en el DocumentRoot. Por lo tanto, la ruta es un acceso al diagnóstico del servidor y no una página habitual proporcionada por el sistema de archivos.

Para el diagnóstico manual, lo más adecuado es la vista HTML. La variante con ?auto Proporciona una representación legible por máquina que un sistema de monitorización puede consultar periódicamente. Los detalles disponibles dependen, entre otras cosas, de la configuración del servidor. Este parámetro no convierte el punto final en un servicio independiente: su salida también debe protegerse contra el acceso no autorizado.

Es necesario que mod_status esté cargado y que tengas permiso para editar la configuración correspondiente de Apache. Además, para las restricciones de acceso deben estar disponibles los módulos de autorización necesarios. La forma de activar un módulo y los archivos responsables de ello varían en función de la distribución y la instalación; por lo tanto, una ruta de archivo concreta no constituye un punto de partida válido para todos los casos.

Para Supervisión de Apache La salida es una fuente de diagnóstico, pero no constituye una supervisión completa del rendimiento de la aplicación. Por ejemplo, muestra que los trabajadores están ocupados, pero no aclara por sí misma si es una base de datos, un backend o un cliente lento lo que está retrasando el procesamiento. Para determinar las causas, necesitas además los datos correspondientes de la aplicación, del sistema y de los registros.

Datos de estado y sus implicaciones en materia de seguridad

La página de estado muestra, entre otras cosas, los trabajadores ocupados y los disponibles, así como información sobre la hora de inicio o reinicio y el tiempo de ejecución. Los trabajadores ocupados no están disponibles como capacidad libre en el momento de la consulta. El grado de criticidad de la relación entre trabajadores ocupados y disponibles solo puede evaluarse teniendo en cuenta la evolución y el límite de trabajadores realmente configurado.

El periodo de tiempo ayuda a contextualizar los valores agregados en el tiempo: una media desde el inicio puede ocultar picos de carga breves. Del mismo modo, una consulta con pocos trabajadores disponibles no es, en un primer momento, más que una instantánea. Las consultas repetidas, junto con los tiempos de respuesta y los errores, proporcionan una base más sólida para analizar una posible escasez.

Con Estado ampliado Apache registra datos adicionales, entre los que se incluyen las visitas y los volúmenes de datos agregados, así como información sobre los hosts y las solicitudes actuales. Al cargar mod_status, este registro está activado de forma predeterminada en Apache 2.4. No obstante, una decisión de configuración explícita permite determinar con claridad qué nivel de detalle se prevé para cada caso concreto.

Un registro más detallado tiene su precio: supone un esfuerzo adicional y puede ralentizar el servidor. Por eso, sopesa la utilidad diagnóstica frente a ese esfuerzo, en lugar de considerar automáticamente que un mayor nivel de detalle es una mejora gratuita. Por otro lado, sin ExtendedStatus se pierde información que puede resultar útil para identificar las solicitudes en curso.

La salida puede revelar solicitudes en curso e información del cliente. Por lo tanto, trátala como datos operativos confidenciales y no como una revisión de estado pública. La vista HTML y ?auto necesitan el mismo nivel de protección de acceso; una ruta difícil de adivinar no impide el acceso a quien la conozca o la descubra.

Comprobar las rutas de acceso y el modelo de trabajadores

Antes de realizar cualquier cambio, comprueba la versión de Apache instalada y el módulo de multiprocesamiento (MPM) activo. Comprueba también qué hosts virtuales atienden al listener en cuestión, si hay proxies inversos que reenvíen las solicitudes y qué reglas de acceso están ya en vigor. Solo con esta visión general se puede evaluar dónde surtirá efecto una nueva regla y qué configuraciones existentes podría afectar.

Un agente de supervisión local podría consultar el estado a través de una dirección de bucle cerrado. Sin embargo, una consulta local satisfactoria solo indica que esa ruta concreta, con la dirección, el puerto y el servidor virtual seleccionados, funciona. No demuestra ni que otros servidores estén protegidos ni que el acceso externo falle.

Una segunda opción puede consistir en utilizar un proxy inverso y otro host virtual. En ese caso, pueden aplicarse otras redirecciones o reglas de acceso; además, hay que comprobar qué dirección de cliente utiliza realmente Apache para la autorización. Fíjate en el Vía de acceso por eso, incluyendo el proxy, la selección de host y las reglas de Apache, en lugar de trasladar la prueba local a toda la topología.

El MPM determina cómo Apache utiliza los procesos y, en su caso, los subprocesos para el procesamiento. Un proceso es una unidad del sistema operativo; los subprocesos se ejecutan dentro de un proceso y pueden procesar tareas en él. La importancia del número de trabajadores depende, por tanto, del modelo utilizado. El Comparación de los modelos de trabajadores de Apache explica las diferencias entre Prefork, Worker y Event.

Precisamente en el caso de event-MPM Las conexiones abiertas no equivalen automáticamente a hilos de trabajo ocupados de forma permanente. Ciertos estados de espera pueden tratarse de forma diferente al procesamiento activo de una solicitud. Por lo tanto, toma nota del MPM activo antes de tomar una decisión sobre la capacidad basándote en el número de conexiones y de hilos de trabajo.

Configurar el punto final de estado local

Antes de realizar el cambio, comprueba si se está ejecutando el servidor HTTP Apache 2.4, mod_status esté cargado y los módulos de autorización necesarios estén disponibles. Registra además los hosts virtuales y las reglas de acceso existentes. La activación de los módulos y las rutas de configuración varían según la distribución; el siguiente ejemplo debe incluirse en el archivo de configuración de Apache correspondiente, no en un archivo genérico.

El ejemplo se activa Estado ampliado lo acepta expresamente y asigna la ruta al gestor de estado. Require local limita el acceso según las reglas de Apache para las conexiones locales. La directiva para el registro detallado se encuentra fuera de la sección «Location». Antes de aplicarla, debes comprobar cómo interactúa esta sección con tu configuración actual.

ExtendedStatus On

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

Asegúrate de que el cambio se revise y se apruebe de acuerdo con tu proceso operativo antes de aplicarlo. El ejemplo es un punto de partida, no una garantía para todos los hosts virtuales o rutas de proxy. En particular, las secciones de autorización existentes pueden influir en qué regla se aplica a una solicitud concreta.

Tras la ejecución, puedes obtener localmente el resultado legible por máquina mediante el siguiente comando de lectura. Este comando requiere que haya un listener configurado en la dirección de bucle cerrado seleccionada y en el puerto estándar 80. Comprueba también si la solicitud llega al servidor virtual previsto; si es necesario, tendrás que adaptar el puerto y la selección del servidor a tu entorno.

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

Una consulta fallida es, en un primer momento, solo una indicación, no un diagnóstico claro del error. Además de la autorización, podrían ser la causa, por ejemplo, otro listener, una asignación de host diferente o un redireccionamiento. Por su parte, una consulta local satisfactoria no garantiza que otras vías de acceso estén protegidas.

Ampliar de forma segura el acceso a la supervisión

Elige la vía de acceso en función de dónde se ejecute la supervisión y quién necesite los resultados. Un agente en el mismo servidor puede utilizar la restricción local. Si un sistema externo necesita acceder, el acceso debe limitarse a las fuentes realmente necesarias y, a continuación, debe comprobarse a través de la ruta de red prevista.

En Require ip No basta con tener en cuenta la dirección que el servidor de monitorización cree que tiene. Detrás de un proxy inverso, la configuración instalada debe proporcionar la dirección que Apache utiliza realmente para la autorización. Comprueba esta asignación en la ruta real antes de autorizar el acceso a una red; una dirección de cliente estimada no constituye un control de acceso fiable.

Varios Require-Las directivas dentro de una sección, si no se utilizan dentro de un contenedor adecuado, se comportan básicamente como una Operador «o»: Si una solicitud cumple alguna de las condiciones, eso puede ser suficiente. Si se requiere que un cliente proceda de la red autorizada y, además, se autentifique, especifica las condiciones expresamente en un <RequireAll>-Combina los contenedores y comprueba ambos requisitos por separado.

En la autenticación básica, solo un protocolo de transporte adecuado, como TLS, protege los datos de acceso durante la transmisión. Una red de gestión independiente puede limitar aún más el acceso, pero no sustituye a una autorización eficaz de Apache. También en este caso, solo los sistemas autorizados deberían poder acceder a la salida en HTML y a la salida legible por máquina.

Clasificar correctamente los valores de estado

La página de estado responde a diferentes preguntas de diagnóstico con datos distintos. Lee la Asignación de trabajadores Por eso no es un dato aislado: describe el estado en el momento de la consulta. Los detalles adicionales de la solicitud dependen de la configuración y, en particular, de ExtendedStatus; los campos que aparecen pueden variar según el servidor y el MPM.

Supongamos que una consulta muestra muchos trabajadores ocupados y solo unos pocos libres. Esto puede deberse a un pico de carga momentáneo o indicar una presión más prolongada. Repite la consulta y compara la evolución con los tiempos de respuesta, los errores y el límite de trabajadores realmente vigente antes de plantearte un cambio en la capacidad.

En event-MPM Ciertos estados de espera pueden ser gestionados por el listener en lugar de por hilos de trabajo vinculados de forma permanente. Por lo tanto, «Writing» y «Keep-alive» deben interpretarse como estados de conexión, y no de forma general como un número de hilos ocupados. Los procesos que se están cerrando y las generaciones anteriores tras un reinicio suave también pueden influir en el panorama; comprueba los detalles de tu versión 2.4 instalada.

Para la clasificación de la arquitectura, el Comparación entre el MPM de eventos y el MPM de trabajadores la visualización del estado. La elección del MPM explica cómo Apache organiza las conexiones y el trabajo; sin embargo, no sustituye a la observación del servidor concreto y de su aplicación.

Seguimiento de los datos de estado a lo largo del tiempo

En Apache Monitoring, una sola página de estado no es más que una parte del conjunto. Obtén la salida legible por máquina a través de ?auto Consúltalos periódicamente a través de un agente autorizado y guarda los valores con una marca de tiempo. De este modo, podrás detectar, por ejemplo, si el número reducido de trabajadores disponibles es algo pasajero o si se mantiene a lo largo de varias consultas.

Para un Frecuencia de intervalo Se compara un contador acumulado con su valor anterior y se divide la diferencia entre el tiempo transcurrido. Por ejemplo, si el número de visitas aumenta en 120 en un intervalo de 60 segundos, esto equivale a una media de dos visitas por segundo durante ese intervalo. Este valor medio no dice nada sobre la distribución dentro del minuto.

Antes de calcular la diferencia, comprueba la información de inicio o reinicio y el valor del contador. Si el servidor se ha reiniciado o si un contador ha bajado con respecto a la consulta anterior, considéralo un reinicio y comienza una nueva serie de comparaciones. Una tasa de tráfico negativa derivada de dos lecturas del contador resultaría engañosa en este caso; además, las consultas fallidas deberían seguir siendo identificables en la cronología.

Los promedios generados por mod_status a lo largo del tiempo de funcionamiento del servidor suavizan los picos de carga breves. Una serie temporal con un intervalo de consulta adecuado muestra los cambios con mayor precisión, pero también puede pasar por alto eventos que se produzcan entre dos consultas. Por lo tanto, elige el intervalo en función de la cuestión que se quiera diagnosticar y ten en cuenta el esfuerzo que supone la recopilación y el almacenamiento de los datos.

Los datos de estado almacenados también deben protegerse: dependiendo de la salida, pueden contener información sobre las solicitudes y los clientes. Limita el acceso al agente, al almacenamiento y a la evaluación a las personas y sistemas autorizados. Además, establece durante cuánto tiempo se conservarán los datos brutos y los indicadores derivados para el fin operativo correspondiente.

Comprobar el acceso y los mensajes de error

Una vez aprobada una modificación, comprueba en primer lugar el acceso autorizado previsto, por ejemplo, desde el agente de supervisión local. A continuación, comprueba, desde una ubicación de red en la que el acceso esté expresamente prohibido, tanto la página HTML como la variante ?auto. Ninguno de los dos debe proporcionar datos de estado en ese lugar. No basta con realizar una prueba en una sola ubicación o a través de una sola vía de acceso.

Repite la comprobación para los hosts virtuales a los que se puede acceder realmente y, si procede, para las conexiones directas y las que pasan por un proxy inverso. El hecho de que la prueba tenga éxito a nivel local no garantiza que el proxy aplique el mismo nivel de protección. Presta atención también a los redireccionamientos: lo decisivo es si, al final de una ruta de acceso, se revelan datos de estado sensibles.

Si falla una consulta válida, comprueba, además de la Autorización así como el listener, la dirección y el puerto, y la selección del host virtual. Las reglas de proxy y redireccionamiento también pueden desviar la solicitud de forma diferente a la esperada. Por lo tanto, un único error no permite concluir con certeza que se trate de una regla de acceso incorrecta ni de un controlador defectuoso.

Comprueba si las configuraciones existentes contienen directivas de acceso obsoletas, como Order y Deny. Su mezcla imprudente con los más recientes Require-Las reglas pueden dar lugar a resultados inesperados. Comprueba la combinación que realmente es válida, en lugar de deducir el acceso definitivo a partir de una única regla que lo permita.

Además, una ubicación protegida no es necesariamente el único estado final posible. Si mod_status está cargado, su controlador también puede aparecer en configuraciones por directorio, incluyendo .htaccess esté disponible. Por lo tanto, comprueba las entradas existentes y las delegaciones permitidas, especialmente en servidores compartidos, para que no se pueda configurar ningún otro controlador desprotegido.

De los indicios a las decisiones empresariales

Si hay muchos trabajadores ocupados de forma repetida y solo unos pocos disponibles, esto es un indicio de una posible presión sobre la capacidad, pero aún no constituye una prueba de la causa. Compara la evolución con los tiempos de respuesta, las tasas de error y el límite de trabajadores realmente vigente. Solo el panorama global permite determinar si la ocupación coincide con problemas apreciables y cuál es su carácter duradero.

Antes de aumentar un límite, comprueba la memoria disponible y las necesidades adicionales de los procesos o subprocesos previstos. Al mismo tiempo, analiza por qué las operaciones tardan tanto: un mayor paralelismo puede no resolver la causa real del problema y consumir aún más recursos. Por lo tanto, los cambios deben integrarse en un proceso operativo controlado, seguido de un seguimiento posterior.

En el caso de las solicitudes lentas, las consultas repetidas del estado ayudan a delimitar las solicitudes actuales y los procesos asociados. Compara los momentos con los registros de acceso y de errores, así como con los datos de la aplicación y sus backends. Una solicitud efímera puede desaparecer entre dos consultas; una sola indicación no identifica de forma fiable una aplicación concreta como causa ni demuestra que se trate de un ataque.

Para una llamativa ID del proceso Además, puedes comprobar datos del sistema operativo, como el uso de la CPU y de la memoria. Esta correspondencia es una pista más, pero no sustituye a la comparación temporal con las solicitudes y los registros. Especialmente en el caso de observaciones repetidas, debes tener en cuenta que los procesos y las solicitudes que están procesando en ese momento pueden cambiar.

En el caso del MPM «event», ten en cuenta además los procesos que se están cerrando y las generaciones antiguas tras un reinicio suave. Pueden influir en el panorama durante la transición; las conexiones abiertas no deben equipararse de forma generalizada con hilos de trabajo ocupados de forma permanente. Comprueba las particularidades de la versión de Apache 2.4 instalada antes de extraer una decisión definitiva sobre la capacidad a partir de una fase de transición de este tipo.