Apache mod_status beveiligen en statuswaarden correct interpreteren

Wat mod_status zichtbaar maakt

De Apache-module mod_status biedt informatie over de actieve webserver. Deze module helpt bijvoorbeeld bij het achterhalen hoeveel workers er op dit moment actief zijn en welke verzoeken worden verwerkt. De volgende toelichtingen hebben betrekking op Apache HTTP Server 2.4; de documentatie van de ontwikkelingsvertakking staat hier los van en kan niet zonder meer op deze versie worden toegepast.

A handelaar genereert de statusuitvoer voor een geconfigureerd URL-pad. Een Location-sectie kan dit pad aan de handler doorgeven server-status toewijzen; hiervoor is geen bestand met dezelfde naam in de DocumentRoot nodig. Het pad biedt dus toegang tot de serverdiagnose en is geen gewone pagina die vanuit het bestandssysteem wordt geleverd.

Voor handmatige diagnose is de HTML-weergave geschikt. De variant met ?auto levert een machinaal leesbare weergave op die een monitoringsysteem regelmatig kan opvragen. Welke details beschikbaar zijn, hangt onder andere af van de serverconfiguratie. De parameter maakt van het eindpunt geen afzonderlijke dienst: ook de uitvoer ervan moet tegen ongeoorloofde toegang worden beschermd.

Voorwaarde is dat mod_status is geladen en dat je de betreffende Apache-configuratie mag bewerken. Voor toegangsbeperkingen moeten bovendien de benodigde autorisatiemodules beschikbaar zijn. Hoe een module wordt geactiveerd en welke bestanden daarvoor verantwoordelijk zijn, verschilt per distributie en installatie; een enkel bestandspad is daarom geen algemeen geldend uitgangspunt.

Voor Apache-monitoring De uitvoer is een bron van diagnose, maar geen volledige monitoring van de applicatieprestaties. Het laat bijvoorbeeld zien dat workers bezig zijn, maar geeft zelf geen uitleg of een database, een backend of een trage client de verwerking vertraagt. Voor dergelijke vragen over de oorzaak heb je bovendien de juiste applicatie-, systeem- en loggegevens nodig.

Statusgegevens en de gevolgen daarvan voor de veiligheid

De statuspagina toont onder andere bezette en vrije workers, evenals gegevens over het tijdstip van opstarten of herstarten en de looptijd. Bezette workers zijn op het moment van de opvraging niet beschikbaar als vrije capaciteit. Hoe kritiek de verhouding tussen bezette en vrije workers is, kan pas worden beoordeeld aan de hand van het verloop en de daadwerkelijk geconfigureerde workerlimiet.

De tijdsperiode helpt om geaggregeerde waarden in de tijd te plaatsen: een gemiddelde sinds de start kan korte piekbelastingen verhullen. Ook is een opvraging met weinig beschikbare workers in eerste instantie slechts een momentopname. Herhaalde opvragingen, in combinatie met responstijden en fouten, bieden een betere basis om een mogelijke schaarste te onderzoeken.

Met Uitgebreide status Apache registreert aanvullende gegevens, waaronder geaggregeerde bezoekersaantallen en gegevensvolumes, evenals informatie over actuele hosts en verzoeken. Bij het laden van mod_status is deze registratie in Apache 2.4 standaard ingeschakeld. Een expliciete configuratiekeuze maakt echter duidelijk welk detailniveau in de betreffende omgeving is voorzien.

Deze nauwkeurigere registratie heeft een prijs: het kost extra moeite en kan de server vertragen. Weeg daarom het diagnostische nut af tegen deze inspanning, in plaats van meer details automatisch als een gratis verbetering te beschouwen. Zonder ExtendedStatus ontbreekt daarentegen informatie die nuttig kan zijn voor het toewijzen van lopende verzoeken.

De uitvoer kan lopende verzoeken en clientgegevens onthullen. Behandel deze daarom als gevoelige bedrijfsgegevens en niet als openbare gezondheidscontrole. De HTML-weergave en ?auto vereisen dezelfde toegangsbeveiliging; een moeilijk te raden pad voorkomt geen toegang door iemand die het kent of ontdekt.

Toegangsroutes en het worker-model controleren

Noteer vóór een wijziging de geïnstalleerde Apache-versie en de actieve Multiprocessing Module, kortweg MPM. Controleer bovendien welke virtuele hosts de betreffende listener bedienen, of reverse-proxys verzoeken doorsturen en welke toegangsregels al van kracht zijn. Pas met dit overzicht kun je beoordelen waar een nieuwe regel van invloed is en welke bestaande configuraties hierdoor kunnen worden beïnvloed.

Een lokale monitoringagent zou de status via een loopback-adres kunnen opvragen. Een succesvolle lokale opvraging toont echter alleen aan dat deze specifieke route met het gekozen adres, de poort en de geselecteerde virtuele host werkt. Het bewijst noch dat andere hosts beveiligd zijn, noch dat externe toegang wordt geblokkeerd.

Een tweede manier kan via een reverse-proxy en een andere virtuele host lopen. Daar kunnen andere omleidingen of toegangsregels van toepassing zijn; bovendien moet worden gecontroleerd welk clientadres Apache daadwerkelijk gebruikt voor de autorisatie. Bekijk de Toegangspad daarom inclusief proxy, hostselectie en Apache-regels, in plaats van de lokale test toe te passen op de volledige topologie.

De MPM bepaalt hoe Apache processen en, indien van toepassing, threads inzet voor de verwerking. Een proces is een eenheid van het besturingssysteem; threads draaien binnen een proces en kunnen daar taken uitvoeren. Het belang van het aantal workers hangt dus af van het gebruikte model. De Vergelijking van de Apache-workermodellen legt de verschillen tussen Prefork, Worker en Event uit.

Juist bij de event-MPM Open verbindingen betekenen niet automatisch dat de worker-threads continu bezet zijn. Bepaalde wachttijden kunnen anders worden behandeld dan de actieve verwerking van een verzoek. Noteer daarom de actieve MPM voordat je op basis van het aantal verbindingen en workers een beslissing neemt over de capaciteit.

Een lokaal status-eindpunt instellen

Controleer vóór de wijziging of Apache HTTP Server 2.4 draait, mod_status is geladen en de benodigde autorisatiemodules beschikbaar zijn. Leg bovendien de bestaande virtuele hosts en toegangsregels vast. Het activeren van modules en de configuratiepaden verschillen per distributie; het volgende voorbeeld hoort thuis in het juiste Apache-configuratiebestand, niet in een algemeen verondersteld bestand.

In dit voorbeeld wordt Uitgebreide status dit uitdrukkelijk in en wijst het pad toe aan de statushandler. Require local beperkt de toegang volgens de regels van Apache voor lokale verbindingen. De richtlijn voor gedetailleerde logboekregistratie staat buiten de Location-sectie. Voordat je deze overneemt, moet je controleren hoe deze sectie samenwerkt met je bestaande configuratie.

ExtendedStatus On

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

Laat de wijziging controleren en goedkeuren volgens je bedrijfsproces voordat je deze toepast. Het voorbeeld is een uitgangspunt, geen garantie voor alle virtuele hosts of proxypaden. Met name bestaande autorisatiesecties kunnen van invloed zijn op welke regel voor een specifiek verzoek geldt.

Na het uitvoeren kun je de machinaal leesbare uitvoer lokaal opvragen met het volgende leescommando. Hiervoor is een listener vereist op het gekozen loopback-adres en de standaardpoort 80. Controleer ook of het verzoek de beoogde virtuele host bereikt; indien nodig moet je de poort en de hostselectie aanpassen aan je omgeving.

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

Een mislukte opvraging is in eerste instantie slechts een aanwijzing, geen eenduidige foutdiagnose. Naast de autorisatie kunnen bijvoorbeeld ook een andere listener, een afwijkende hosttoewijzing of een omleiding de oorzaak zijn. Een succesvolle lokale opvraging zegt op zijn beurt nog niets over de beveiliging van andere toegangswegen.

Toegang tot monitoring veilig uitbreiden

Kies de toegangsroute op basis van waar de monitoring plaatsvindt en wie de uitvoer nodig heeft. Een agent op dezelfde host kan gebruikmaken van de lokale beperking. Als een extern systeem toegang moet krijgen, moet de toegang worden beperkt tot de bronnen die daadwerkelijk nodig zijn en vervolgens via de daarvoor bestemde netwerkroute worden gecontroleerd.

Op Require ip Het is niet alleen van belang welk adres de monitoringserver vanuit zijn perspectief heeft. Achter een reverse-proxy moet de geïnstalleerde configuratie het adres leveren dat Apache daadwerkelijk gebruikt voor de autorisatie. Controleer deze toewijzing in de praktijk voordat je een netwerk vrijgeeft; een verondersteld clientadres is geen betrouwbare toegangscontrole.

Verschillende Require-Directieven binnen een sectie werken zonder geschikte container in principe als een Of-operatie: Als een verzoek aan een van de voorwaarden voldoet, kan dat al voldoende zijn. Moet een client afkomstig zijn uit het toegestane netwerk en zich bovendien aanmelden, vermeld de voorwaarden dan uitdrukkelijk in een <RequireAll>-Zet de containers naast elkaar en test beide vereisten afzonderlijk.

Bij Basic Authentication worden de inloggegevens pas tijdens de overdracht beschermd door een geschikt transportprotocol, zoals TLS. Een apart beheernetwerk kan de toegankelijkheid bovendien beperken, maar is geen vervanging voor een effectieve Apache-autorisatie. Ook daar mogen alleen geautoriseerde systemen de HTML- en de machinaal leesbare uitvoer opvragen.

Statuswaarden correct interpreteren

De statuspagina geeft antwoord op verschillende diagnostische vragen met verschillende gegevens. Lees de Toewijzing van werknemers daarom niet op zichzelf staand: het beschrijft de toestand op het moment van opvraging. Aanvullende details van het verzoek zijn afhankelijk van de configuratie en met name van ExtendedStatus; welke velden worden weergegeven, kan per server en MPM verschillen.

Stel dat een query veel bezette en slechts enkele vrije workers laat zien. Dit kan een kortstondige piek in de belasting zijn of wijzen op langdurige druk. Herhaal de query en vergelijk het verloop met responstijden, fouten en de daadwerkelijk geldende workerlimiet voordat je een capaciteitswijziging overweegt.

Op event-MPM Bepaalde wachttoestanden kunnen door de listener worden afgehandeld in plaats van door permanent gekoppelde worker-threads. ‘Writing’ en ‘Keep-alive’ moeten daarom worden gezien als verbindingsstatussen, en niet algemeen als het aantal bezette threads. Ook beëindigde processen en oudere generaties na een graceful restart kunnen het beeld beïnvloeden; controleer de details voor de door jou geïnstalleerde 2.4-versie.

Voor de classificatie van de architectuur vult de Vergelijking tussen Event MPM en Worker MPM de statusweergave. De keuze voor het MPM legt uit hoe Apache verbindingen en taken organiseert; het is echter geen vervanging voor het observeren van de specifieke server en de bijbehorende toepassing.

Statusgegevens in de loop van de tijd volgen

Voor Apache Monitoring is een enkele statuspagina slechts een deel van het geheel. Laat de machinaal leesbare uitvoer via ?auto Haal de waarden regelmatig op via een bevoegde agent en sla ze op met een tijdstempel. Zo kun je bijvoorbeeld zien of er slechts kortstondig een klein aantal vrije workers is, of dat dit aantal gedurende meerdere opvragingen aanhoudt.

Voor een Intervalfrequentie Je vergelijkt een cumulatieve teller met zijn vorige waarde en deelt het verschil door de verstreken tijd. Als het aantal bezoeken binnen 60 seconden bijvoorbeeld met 120 toeneemt, komt dat voor dit interval neer op gemiddeld twee bezoeken per seconde. Dit gemiddelde zegt nog niets over de verdeling binnen die minuut.

Controleer vóór het berekenen van het verschil de opstart- of herstartgegevens en de tellerstand. Als de server opnieuw is opgestart of als een teller ten opzichte van de vorige opvraging is gedaald, beschouw dit dan als een reset en begin een nieuwe reeks vergelijkingen. Een negatieve verkeerssnelheid op basis van twee tellerstanden zou hier misleidend zijn; ook mislukte opvragingen moeten in het verloop herkenbaar blijven.

De gemiddelden die door mod_status worden weergegeven over de looptijd van de server, vlakken korte pieken in de belasting af. Een tijdreeks met een passend gekozen opvraaginterval geeft veranderingen nauwkeuriger weer, maar kan ook gebeurtenissen tussen twee opvragingen missen. Kies het interval daarom afgestemd op de diagnostische vraag en houd rekening met de inspanning die nodig is voor het verzamelen en opslaan van de gegevens.

Ook opgeslagen statusgegevens moeten worden beschermd: afhankelijk van de uitvoer kunnen deze request- en clientgegevens bevatten. Beperk de toegang tot de agent, de opslag en de analyse tot bevoegde personen en systemen. Leg bovendien vast hoe lang ruwe gegevens en afgeleide kengetallen voor het betreffende bedrijfsdoel worden bewaard.

Toegang en foutmeldingen controleren

Controleer na een goedgekeurde wijziging eerst of de bevoegde toegang, bijvoorbeeld door de lokale monitoringagent, correct is ingesteld. Controleer vervolgens vanaf een uitdrukkelijk niet-toegestane netwerklocatie zowel de HTML-pagina als de variant ?auto. Beide mogen daar geen statusgegevens verstrekken. Een test op slechts één locatie of via slechts één toegangsweg is niet voldoende.

Herhaal de test voor de daadwerkelijk bereikbare virtuele hosts en, indien van toepassing, voor directe verbindingen en verbindingen die via een reverse-proxy lopen. Een lokaal succes bewijst niet dat de proxy dezelfde bescherming biedt. Let ook op doorverwijzingen: het is van cruciaal belang of er aan het einde van een toegangspad gevoelige statusgegevens worden weergegeven.

Als een toegestane opvraging mislukt, controleer dan naast de Autorisatie ook de listener, het adres en de poort, evenals de keuze van de virtuele host. Proxy- en omleidingsregels kunnen het verzoek eveneens anders doorsturen dan verwacht. Een enkele fout wijst daarom niet noodzakelijkerwijs op een verkeerde toegangsregel of een defecte handler.

Controleer bestaande configuraties op verouderde toegangsrichtlijnen zoals Order en Deny. De ondoordachte vermenging daarvan met de nieuwere Require-Regels kunnen tot onverwachte resultaten leiden. Controleer welke combinatie daadwerkelijk werkt, in plaats van op basis van één enkele toegestane regel te concluderen dat toegang mogelijk is.

Een beveiligde locatie is bovendien niet per se het enige mogelijke status-eindpunt. Als mod_status is geladen, kan de handler ervan ook in configuraties per map worden gebruikt, inclusief .htaccess beschikbaar zijn. Controleer daarom de bestaande vermeldingen en toegestane delegaties, met name op gedeelde servers, zodat er geen extra onbeveiligde handler kan worden ingesteld.

Van aanwijzingen naar bedrijfsbeslissingen

Als er herhaaldelijk veel workers bezet zijn en er slechts enkele vrij zijn, wijst dit op mogelijke capaciteitsdruk, maar is dit nog geen bewijs van de oorzaak. Vergelijk het verloop met responstijden, foutpercentages en de daadwerkelijk geldende limiet voor het aantal workers. Pas het totaalbeeld laat zien of de bezetting samenvalt met merkbare problemen en hoe duurzaam deze zijn.

Controleer, voordat je een limiet verhoogt, de beschikbare opslagruimte en de extra benodigde capaciteit voor de beoogde processen of threads. Ga tegelijkertijd na waarom bewerkingen zo lang duren: een hogere mate van parallelliteit kan de werkelijke oorzaak in stand houden en nog meer resources in beslag nemen. Wijzigingen moeten daarom plaatsvinden binnen een gecontroleerd bedrijfsproces, gevolgd door monitoring.

Bij trage verzoeken helpen herhaalde statuscontroles om lopende verzoeken en bijbehorende processen te identificeren. Vergelijk de tijdstippen met toegangs- en foutlogboeken en met gegevens van de applicatie en de bijbehorende backends. Een vluchtig verzoek kan tussen twee statuscontroles verdwijnen; een enkele melding identificeert noch op betrouwbare wijze een bepaalde applicatie als oorzaak, noch bewijst deze dat er sprake is van een aanval.

Voor een opvallende Proces-ID Je kunt daarnaast ook gegevens over het besturingssysteem, zoals CPU- en geheugengebruik, controleren. Deze koppeling is een extra aanwijzing, maar geen vervanging voor het afstemmen op de tijd van verzoeken en logbestanden. Vooral bij herhaalde waarnemingen moet je er rekening mee houden dat processen en de verzoeken die ze op dat moment verwerken, kunnen veranderen.

Let bij event-MPM bovendien op aflopende processen en oude generaties na een graceful restart. Deze kunnen het beeld tijdens de overgang beïnvloeden; open verbindingen zijn daarbij niet zonder meer gelijk te stellen aan permanent bezette worker-threads. Controleer de specifieke kenmerken van de geïnstalleerde Apache 2.4-versie voordat je uit een dergelijke overgangsfase een definitieve beslissing over de capaciteit afleidt.