Sécuriser le module mod_status d'Apache et analyser correctement les valeurs d'état

Ce que mod_status affiche

Le module Apache mod_status fournit des informations sur le serveur Web en cours d'exécution. Il permet notamment de savoir combien de processus de travail sont actuellement actifs et quelles requêtes sont en cours de traitement. Les explications suivantes concernent Apache HTTP Server 2.4 ; la documentation relative à la branche de développement est distincte et ne peut être transposée à cette version sans vérification préalable.

A manipulateur génère la sortie d'état pour un chemin URL configuré. Une section « Location » peut transmettre ce chemin au gestionnaire server-status ; il n'est pas nécessaire pour cela qu'un fichier du même nom existe dans le répertoire DocumentRoot. Ce chemin d'accès permet donc d'accéder aux diagnostics du serveur et ne correspond pas à une page classique fournie par le système de fichiers.

L'affichage HTML est adapté au diagnostic manuel. La variante avec ?auto fournit une représentation lisible par machine qu’un système de surveillance peut consulter régulièrement. Les détails disponibles dépendent, entre autres, de la configuration du serveur. Ce paramètre ne transforme pas le point de terminaison en un service distinct : sa sortie doit également être protégée contre tout accès non autorisé.

Pour cela, il faut que mod_status soit chargé et que vous ayez les droits nécessaires pour modifier la configuration d'Apache. Pour les restrictions d'accès, les modules d'autorisation nécessaires doivent également être disponibles. La manière d'activer un module et les fichiers impliqués varient selon la distribution et l'installation ; il n'est donc pas possible de donner un chemin d'accès unique valable dans tous les cas.

Pour Surveillance d'Apache Ces informations constituent une source de diagnostic, mais ne constituent pas à elles seules un suivi complet des performances de l'application. Elles indiquent par exemple que les workers sont occupés, mais ne permettent pas de déterminer si c'est une base de données, un backend ou un client lent qui ralentit le traitement. Pour identifier ces causes, vous avez besoin en plus de données pertinentes sur l'application, le système et les journaux.

Les données d'état et leurs implications en matière de sécurité

La page d'état affiche notamment les workers occupés et disponibles, ainsi que des informations sur l'heure de démarrage ou de redémarrage et la durée d'exécution. Les workers occupés ne sont pas disponibles en tant que capacité libre au moment de la requête. Le caractère critique d'un rapport entre workers occupés et disponibles ne peut être évalué qu'en tenant compte de l'historique et de la limite de workers effectivement configurée.

La période considérée permet de replacer les valeurs agrégées dans leur contexte temporel : une moyenne calculée depuis le début peut masquer de brefs pics de charge. De même, une requête effectuée alors qu'il y a peu de travailleurs disponibles ne constitue dans un premier temps qu'un instantané. Des requêtes répétées, associées aux temps de réponse et aux erreurs, fournissent une meilleure base pour analyser une éventuelle pénurie.

Avec ExtendedStatus Apache enregistre des informations supplémentaires, notamment le nombre cumulé de visites et le volume de données, ainsi que des informations sur les hôtes et les requêtes en cours. Lors du chargement de mod_status, cette fonctionnalité est activée par défaut dans Apache 2.4. Une décision de configuration explicite permet toutefois de déterminer clairement le niveau de détail prévu pour chaque environnement d'exploitation.

Cette collecte plus précise a un coût : elle entraîne une charge de travail supplémentaire et peut ralentir le serveur. Il convient donc de mettre en balance l'intérêt diagnostique et cet effort, plutôt que de considérer automatiquement ces détails supplémentaires comme une amélioration gratuite. En revanche, sans ExtendedStatus, il manque des informations qui peuvent s'avérer utiles pour l'attribution des requêtes en cours.

La sortie peut révéler les requêtes en cours et des informations sur le client. Il convient donc de la traiter comme données d'exploitation sensibles et non comme un bilan de santé public. L'affichage HTML et ?auto nécessitent le même niveau de protection d'accès ; un chemin difficile à deviner n'empêche pas l'accès à quelqu'un qui le connaît ou qui l'a découvert.

Vérifier les chemins d'accès et le modèle de travailleur

Avant d'effectuer une modification, identifiez la version d'Apache installée et le module de multiprocessing (MPM) actif. Vérifiez également quels hôtes virtuels desservent le listener concerné, si des proxys inversés transfèrent les requêtes et quelles règles d'accès sont déjà en vigueur. Ce n’est qu’une fois cette vue d’ensemble établie qu’il est possible d’évaluer où une nouvelle règle aura un impact et quelles configurations existantes elle est susceptible d’affecter.

Un agent de surveillance local pourrait récupérer l'état via une adresse de bouclage. Cependant, une requête locale réussie indique uniquement que ce chemin précis, avec l'adresse, le port et l'hôte virtuel sélectionnés, fonctionne. Elle ne prouve ni que d'autres hôtes sont protégés, ni qu'un accès externe échoue.

Une deuxième approche peut passer par un proxy inverse et un autre hôte virtuel. D'autres redirection ou règles d'accès peuvent s'appliquer dans ce cas ; il convient également de vérifier quelle adresse client Apache utilise réellement pour l'autorisation. Considère le chemin d'accès c'est pourquoi il faut inclure le proxy, la sélection de l'hôte et les règles Apache, plutôt que de transposer le test local à l'ensemble de la topologie.

Le MPM détermine la manière dont Apache utilise les processus et, le cas échéant, les threads pour le traitement. Un processus est une entité du système d'exploitation ; les threads s'exécutent au sein d'un processus et peuvent y traiter des tâches. L'importance du nombre de workers dépend donc du modèle utilisé. Le Comparaison des modèles de workers Apache explique les différences entre Prefork, Worker et Event.

C'est justement dans le cas de event-MPM Les connexions ouvertes ne sont pas automatiquement synonymes de threads de travail occupés en permanence. Certains états d'attente peuvent être traités différemment du traitement actif d'une requête. Notez donc le MPM actif avant de tirer des conclusions sur la capacité à partir du nombre de connexions et de threads de travail.

Configurer un point de terminaison d'état local

Avant d'effectuer la modification, vérifie si le serveur HTTP Apache 2.4 est en cours d'exécution, mod_status est chargé et que les modules d'autorisation nécessaires sont disponibles. Répertoriez également les hôtes virtuels et les règles d'accès existants. L'activation des modules et les chemins de configuration varient selon la distribution ; l'exemple suivant doit être placé dans le fichier de configuration Apache approprié, et non dans un fichier générique supposé exister.

L'exemple s'active ExtendedStatus l'accepte expressément et attribue le chemin au gestionnaire d'état. Require local limite l'accès selon les règles d'Apache pour les connexions locales. La directive relative à la journalisation détaillée se trouve en dehors de la section « Location ». Avant de l'appliquer, tu dois vérifier comment cette section interagit avec ta configuration existante.

ExtendedStatus On

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

Fais vérifier et valider la modification conformément à votre processus opérationnel avant de l'appliquer. Cet exemple constitue un point de départ et ne garantit pas son applicabilité à tous les hôtes virtuels ou chemins de proxy. Les sections d'autorisation existantes, en particulier, peuvent influencer la règle qui s'applique à une requête spécifique.

Après l'exécution, tu peux récupérer localement la sortie lisible par machine à l'aide de la commande de lecture suivante. Celle-ci nécessite la mise en place d'un écouteur sur l'adresse de bouclage sélectionnée et le port par défaut 80. Vérifie également si la requête parvient bien à l'hôte virtuel prévu ; le cas échéant, tu devras adapter le port et le choix de l'hôte à ton environnement.

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

Un accès infructueux n'est dans un premier temps qu'un indice, et non un diagnostic d'erreur formel. Outre l'autorisation, d'autres causes sont envisageables, comme un autre écouteur, une attribution d'hôte différente ou une redirection. À l'inverse, un accès local réussi ne permet pas de déterminer si d'autres voies d'accès sont protégées.

Étendre l'accès à la surveillance en toute sécurité

Choisissez le mode d'accès en fonction de l'endroit où s'effectue la surveillance et de l'utilisateur qui a besoin des résultats. Un agent installé sur le même hôte peut utiliser la restriction locale. Si un système externe doit y accéder, l'autorisation doit être limitée aux sources réellement nécessaires, puis vérifiée via le chemin réseau prévu à cet effet.

À l'adresse suivante : Require ip L'adresse que le serveur de surveillance voit n'est pas le seul élément déterminant. Derrière un proxy inverse, la configuration installée doit fournir l'adresse qu'Apache utilise réellement pour l'autorisation. Vérifie cette correspondance sur le chemin réel avant de valider un réseau ; une adresse client supposée ne constitue pas un contrôle d'accès fiable.

Plusieurs Require- Les directives situées au sein d'une section agissent en principe comme une Opérateur « ou »: Si une requête remplit l'une de ces conditions, cela peut déjà suffire. Si un client doit provenir du réseau autorisé et s'identifier en plus, énoncez explicitement ces conditions dans un <RequireAll>- Regroupe les conteneurs et teste chacune des exigences séparément.

Dans le cadre de l'authentification de base, seul un protocole de transport adapté, tel que TLS, protège les identifiants lors de leur transmission. Un réseau de gestion distinct peut limiter davantage l'accessibilité, mais ne remplace en aucun cas une autorisation Apache efficace. Là encore, seuls les systèmes autorisés devraient pouvoir récupérer les fichiers HTML et les données lisibles par machine.

Bien interpréter les valeurs d'état

La page d'état répond à différentes questions de diagnostic à l'aide de différentes données. Lisez la Affectation des travailleurs Elle n'est donc pas isolée : elle décrit l'état au moment de la consultation. Les détails supplémentaires de la requête dépendent de la configuration et notamment de l'ExtendedStatus ; les champs affichés peuvent varier selon le serveur et le MPM.

Supposons qu'une requête révèle un grand nombre de workers occupés et très peu de workers disponibles. Il peut s'agir d'un pic de charge passager ou indiquer une pression prolongée. Répétez la requête et comparez l'évolution avec les temps de réponse, les erreurs et la limite de workers effectivement en vigueur avant d'envisager une modification de la capacité.

À l'adresse suivante : event-MPM certains états d'attente peuvent être gérés par l'écouteur plutôt que par des threads de travail liés en permanence. Les états « Writing » et « Keep-alive » doivent donc être considérés comme des états de connexion, et non de manière générale comme un nombre de threads occupés. Les processus en cours de fermeture et les anciennes générations après un redémarrage en douceur peuvent également influencer ce tableau ; vérifie les détails pour la version 2.4 que tu as installée.

Pour situer cette architecture dans son contexte, le Comparaison entre le MPM « Event » et le MPM « Worker » l'affichage de l'état. Le choix du MPM explique comment Apache organise les connexions et le travail ; il ne remplace toutefois pas l'observation du serveur concret et de son application.

Suivre les données d'état dans le temps

Pour Apache Monitoring, une simple page d'état ne représente qu'un aperçu. Récupère la sortie lisible par machine via ?auto Consulte-les régulièrement via un agent autorisé et enregistre les valeurs avec un horodatage. Cela te permettra, par exemple, de déterminer si le nombre réduit de workers disponibles est un phénomène passager ou s'il persiste sur plusieurs requêtes.

Pour une fréquence d'intervalle tu compares un compteur cumulé à sa valeur précédente et tu divises la différence par le temps écoulé. Si, par exemple, le nombre de visites augmente de 120 en 60 secondes, cela correspond à une moyenne de deux visites par seconde pour cet intervalle. Cette moyenne ne donne toutefois aucune indication sur la répartition au sein de la minute.

Avant de calculer la différence, vérifie les informations de démarrage ou de redémarrage ainsi que la valeur du compteur. Si le serveur a redémarré ou si la valeur d'un compteur a diminué par rapport à la consultation précédente, considère cela comme une réinitialisation et commence une nouvelle série de comparaisons. Un taux de trafic négatif résultant de deux relevés de compteur serait ici trompeur ; les requêtes échouées doivent également rester identifiables dans l'historique.

Les moyennes calculées par mod_status sur la durée de fonctionnement du serveur lissent les pics de charge de courte durée. Une série chronologique avec un intervalle d'interrogation bien choisi reflète les variations avec plus de précision, mais peut également passer à côté d'événements survenus entre deux interrogations. Choisis donc l'intervalle en fonction de la question de diagnostic et tiens compte de l'effort nécessaire à la collecte et au stockage des données.

Les données d'état enregistrées doivent également être protégées : selon le type de sortie, elles peuvent contenir des informations relatives aux requêtes et aux clients. Limitez l'accès à l'agent, au stockage et à l'analyse aux personnes et systèmes autorisés. Définissez également la durée de conservation des données brutes et des indicateurs dérivés en fonction de leur finalité opérationnelle respective.

Vérifier l'accès et les messages d'erreur

Une fois une modification validée, vérifiez d'abord que l'accès autorisé prévu fonctionne correctement, par exemple depuis l'agent de surveillance local. Vérifiez ensuite, depuis un emplacement réseau expressément interdit, aussi bien la page HTML que la variante. ?auto. Aucun des deux ne doit y fournir de données d'état. Un test effectué sur un seul site ou via une seule voie d'accès n'est pas suffisant.

Répétez le test pour les hôtes virtuels réellement accessibles et, le cas échéant, pour les connexions directes et celles passant par un proxy inverse. Un succès au niveau local ne prouve pas que le proxy assure le même niveau de protection. Prêtez également attention aux redirections : ce qui importe, c’est de savoir si des données d’état sensibles sont restituées à la fin d’un chemin d’accès.

Si une requête autorisée échoue, vérifiez, outre la Autorisation ainsi que le listener, l'adresse et le port, ainsi que le choix de l'hôte virtuel. Les règles de proxy et de redirection peuvent également acheminer la requête différemment de ce qui était prévu. Une seule erreur ne permet donc pas de conclure avec certitude à une règle d'accès erronée ni à un gestionnaire défectueux.

Vérifie si les configurations existantes contiennent d'anciennes directives d'accès telles que Order et Deny. Leur mélange irréfléchi avec les plus récents Require- Le respect des règles peut entraîner des résultats inattendus. Vérifie la combinaison qui s'applique réellement, au lieu de déduire l'accès final à partir d'une seule règle autorisée.

De plus, un emplacement protégé n'est pas nécessairement le seul état final possible. Si mod_status est chargé, son gestionnaire peut également être défini dans des configurations par répertoire, y compris .htaccess être disponibles. Vérifie donc les entrées existantes et les délégations autorisées, en particulier sur les serveurs partagés, afin qu'aucun autre gestionnaire non protégé ne puisse être configuré.

Des indices aux décisions opérationnelles

Si, de manière récurrente, de nombreux workers sont occupés et que seuls quelques-uns sont disponibles, cela indique une éventuelle pression sur les capacités, mais ne constitue pas encore une preuve de la cause. Comparez cette évolution avec les temps de réponse, les taux d'erreur et la limite de workers effectivement en vigueur. Ce n'est qu'en considérant l'ensemble de ces éléments que l'on peut déterminer si l'occupation coïncide avec des problèmes perceptibles et évaluer leur caractère persistant.

Avant d'augmenter une limite, vérifiez la mémoire disponible et les besoins supplémentaires des processus ou threads concernés. Cherchez également à comprendre pourquoi les traitements prennent autant de temps : un parallélisme accru peut ne pas résoudre la cause réelle du problème et mobiliser davantage de ressources. Les modifications doivent donc s'inscrire dans un processus opérationnel contrôlé, suivi d'une phase d'observation.

En cas de requêtes lentes, des vérifications répétées de l'état permettent de cerner les requêtes en cours et les processus associés. Comparez ces horodatages avec les journaux d'accès et d'erreurs, ainsi qu'avec les données de l'application et de ses back-ends. Une requête éphémère peut disparaître entre deux vérifications ; un seul signalement ne permet ni d’identifier de manière fiable une application spécifique comme cause du problème, ni de prouver qu’il s’agit d’une attaque.

Pour un look qui ne passe pas inaperçu ID du processus Tu peux également vérifier les données du système d'exploitation, telles que l'utilisation du processeur et de la mémoire. Cette corrélation constitue un indice supplémentaire, mais ne remplace pas la comparaison chronologique avec les requêtes et les journaux. En particulier en cas d'observations répétées, tu dois tenir compte du fait que les processus et les requêtes qu'ils traitent à un moment donné peuvent changer.

Avec event-MPM, tenez également compte des processus en cours de fermeture et des anciennes générations après un redémarrage en douceur. Ceux-ci peuvent influencer la situation pendant la transition ; les connexions ouvertes ne doivent pas pour autant être systématiquement assimilées à des threads de travail occupés en permanence. Vérifie les particularités de la version d'Apache 2.4 installée avant de tirer des conclusions définitives sur la capacité nécessaire à partir d'une telle phase de transition.