Säkra Apache mod_status och tolka statusvärdena korrekt

Vad mod_status visar

Apache-modulen mod_status tillhandahåller information om den aktiva webbservern. Den hjälper till exempel till att ta reda på hur många arbetare som just nu är sysselsatta och vilka förfrågningar som behandlas. Följande förklaringar avser Apache HTTP Server 2.4; dokumentationen för utvecklingsgrenen är separat och kan inte överföras till denna version utan att först kontrolleras.

En handlare genererar statusutmatningen för en konfigurerad URL-sökväg. Ett ”Location”-avsnitt kan överföra denna sökväg till hanteraren server-status tilldela; det krävs ingen fil med samma namn i DocumentRoot för detta. Sökvägen utgör därmed en ingång till serverdiagnosen och är inte en vanlig sida som hämtas från filsystemet.

HTML-vyn är lämplig för manuell felsökning. Varianten med ?auto ger en maskinläsbar representation som ett övervakningssystem regelbundet kan hämta. Vilka detaljer som är tillgängliga beror bland annat på serverkonfigurationen. Parametern gör inte slutpunkten till en separat tjänst: även dess utdata måste skyddas mot obehörig åtkomst.

Förutsättningen är att mod_status är laddat och att du har behörighet att redigera den aktuella Apache-konfigurationen. För åtkomstbegränsningar måste dessutom de nödvändiga auktoriseringsmodulerna vara tillgängliga. Hur en modul aktiveras och vilka filer som är ansvariga för detta varierar beroende på distribution och installation; en enskild filväg är därför ingen allmängiltig utgångspunkt.

För Apache-övervakning Utmatningen är en källa till diagnostik, men utgör inte en fullständig övervakning av applikationsprestanda. Den visar till exempel att arbetare är upptagna, men förklarar inte i sig om det är en databas, ett backend-system eller en långsam klient som fördröjer bearbetningen. För att kunna fastställa sådana orsaker behöver du dessutom lämpliga applikations-, system- och loggdata.

Statusdata och deras säkerhetskonsekvenser

Statussidan visar bland annat upptagna och lediga arbetare samt uppgifter om start- eller omstartstid och körtid. Upptagna arbetare är inte tillgängliga som ledig kapacitet vid tidpunkten för förfrågan. Hur kritisk fördelningen mellan upptagna och lediga arbetare är kan först bedömas utifrån utvecklingen och den faktiskt konfigurerade gränsen för antalet arbetare.

Tidsperioden hjälper till att sätta de aggregerade värdena i ett tidsmässigt sammanhang: Ett genomsnitt sedan starten kan dölja korta belastningstoppar. På samma sätt är en förfrågan med få lediga arbetare i första hand bara en ögonblicksbild. Upprepade förfrågningar tillsammans med svarstider och fel ger en bättre grund för att undersöka en eventuell brist.

Med Utökad status Apache registrerar ytterligare detaljer, däribland aggregerade besök och datamängder samt information om aktuella värdar och förfrågningar. När mod_status laddas är denna loggning aktiverad som standard i Apache 2.4. Ett uttryckligt konfigurationsval gör det dock tydligt vilken detaljnivå som är avsedd för den aktuella driften.

Den mer detaljerade loggningen har sitt pris: den medför extra arbete och kan göra servern långsammare. Väg därför den diagnostiska nyttan mot denna arbetsinsats, istället för att automatiskt betrakta fler detaljer som en kostnadsfri förbättring. Utan ExtendedStatus saknas å andra sidan information som kan vara till hjälp vid tilldelningen av pågående förfrågningar.

Utmatningen kan avslöja pågående förfrågningar och klientinformation. Behandla den därför som känsliga driftsdata och inte som en offentlig hälsokontroll. HTML-vyn och ?auto kräver samma åtkomstskydd; en svårgissad sökväg hindrar inte åtkomst från någon som känner till eller upptäcker den.

Kontrollera åtkomstvägar och arbetarmodellen

Innan du gör någon ändring bör du ta reda på vilken version av Apache som är installerad och vilket Multiprocessing Module (MPM) som är aktivt. Kontrollera dessutom vilka virtuella värdar som betjänas av den aktuella lyssnaren, om omvända proxyservrar vidarebefordrar förfrågningar och vilka åtkomstregler som redan gäller. Först med denna översikt går det att bedöma var en ny regel kommer att träda i kraft och vilka befintliga konfigurationer den kan påverka.

En lokal övervakningsagent skulle kunna hämta statusinformationen via en loopback-adress. En lyckad lokal hämtning visar dock endast att just denna specifika väg med den valda adressen, porten och den valda virtuella värden fungerar. Den bevisar varken att andra värdar är skyddade eller att extern åtkomst misslyckas.

Ett annat sätt kan vara att använda en omvänd proxy och en annan virtuell värd. Där kan andra omdirigeringar eller åtkomstregler gälla; dessutom måste man kontrollera vilken klientadress Apache faktiskt använder för auktoriseringen. Titta på Åtkomstväg därför inklusive proxy, val av värd och Apache-regler, istället för att överföra det lokala testet till hela topologin.

MPM avgör hur Apache använder processer och, i förekommande fall, trådar för bearbetning. En process är en enhet i operativsystemet; trådar körs inom en process och kan där utföra uppgifter. Betydelsen av antalet arbetare beror därför på vilken modell som används. Den Jämförelse av Apache-arbetsmodeller förklarar skillnaderna mellan Prefork, Worker och Event.

Särskilt när det gäller event-MPM Öppna anslutningar innebär inte automatiskt att arbetartrådar är upptagna hela tiden. Vissa väntetillstånd kan hanteras på ett annat sätt än den aktiva bearbetningen av en förfrågan. Notera därför den aktiva MPM:en innan du drar slutsatser om kapaciteten utifrån antalet anslutningar och arbetartrådar.

Konfigurera en lokal statusändpunkt

Kontrollera innan du gör ändringen om Apache HTTP Server 2.4 körs, mod_status är laddad och att de nödvändiga auktoriseringsmodulerna är tillgängliga. Registrera dessutom de befintliga virtuella värdarna och åtkomstreglerna. Modulaktivering och konfigurationsvägar varierar beroende på distribution; följande exempel hör hemma i den relevanta Apache-konfigurationsfilen, inte i en fil som generellt förutsätts finnas.

I exemplet kopplas Utökad status uttryckligen och tilldelar sökvägen till statushanteraren. Require local begränsar åtkomsten enligt Apaches regler för lokala anslutningar. Direktivet för detaljloggning placeras utanför Location-avsnittet. Innan du implementerar detta måste du kontrollera hur detta avsnitt samverkar med din befintliga konfiguration.

ExtendedStatus On

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

Låt ändringen granskas och godkännas enligt din driftsprocess innan du tillämpar den. Exemplet är en utgångspunkt, inte en garanti för alla virtuella värdar eller proxyrutter. Framför allt kan befintliga auktoriseringsavsnitt påverka vilken regel som gäller för en specifik förfrågan.

Efter körningen kan du hämta den maskinläsbara utdata lokalt med följande läsbefallning. Den förutsätter att en lyssnare är konfigurerad på den valda loopback-adressen och standardporten 80. Kontrollera också om förfrågan når den avsedda virtuella värden; vid behov måste du anpassa port- och värdvalet till din miljö.

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

En misslyckad hämtning är i första hand bara en indikation, inte en entydig feldiagnos. Förutom auktoriseringen kan det till exempel handla om en annan lyssnare, en avvikande värdtilldelning eller en omdirigering. En lyckad lokal hämtning innebär däremot inte nödvändigtvis att andra åtkomstvägar är skyddade.

Utöka åtkomsten till övervakningen på ett säkert sätt

Välj åtkomstväg utifrån var övervakningen körs och vem som behöver utdata. En agent på samma värd kan använda den lokala begränsningen. Om ett externt system behöver åtkomst bör åtkomsten begränsas till de källor som faktiskt behövs och därefter kontrolleras via den avsedda nätverksvägen.

Med Require ip Det är inte enbart avgörande vilken adress övervakningsservern har ur sin egen synvinkel. Bakom en omvänd proxy måste den installerade konfigurationen ange den adress som Apache faktiskt använder för auktorisering. Kontrollera denna tilldelning i praktiken innan du ger ett nätverk åtkomst; en antagen klientadress är ingen tillförlitlig åtkomstkontroll.

Flera Require-Direktiv inom ett avsnitt fungerar i princip som en ”eller”-operator: Om en förfrågan uppfyller något av villkoren kan det redan vara tillräckligt. Om en klient ska komma från det tillåtna nätverket och dessutom logga in, ska villkoren uttryckligen anges i en <RequireAll>-Sätt ihop behållarna och testa båda kraven var för sig.

Vid grundläggande autentisering är det endast en lämplig överföringsprotokoll, såsom TLS, som skyddar inloggningsuppgifterna under överföringen. Ett separat förvaltningsnätverk kan ytterligare begränsa åtkomsten, men ersätter inte en effektiv Apache-auktorisering. Även där bör endast behöriga system kunna hämta både HTML-utdata och den maskinläsbara utdata.

Att tolka statusvärden på rätt sätt

Statussidan besvarar olika diagnostiska frågor med olika data. Läs Arbetstagarplacering Därför är den inte isolerad: den beskriver tillståndet vid tidpunkten för hämtningen. Ytterligare detaljer om begäran beror på konfigurationen och i synnerhet på ExtendedStatus; vilka fält som visas kan variera beroende på server och MPM.

Anta att en förfrågan visar många upptagna och endast ett fåtal lediga arbetare. Det kan vara en kortvarig belastningstopp eller tyda på en mer långvarig belastning. Upprepa förfrågan och jämför utvecklingen med svarstider, fel och den faktiska gränsen för arbetare innan du överväger en kapacitetsändring.

På event-MPM Vissa väntetillstånd kan hanteras av lyssnaren istället för av permanent bundna arbetstrådar. ”Writing” och ”Keep-alive” ska därför tolkas som anslutningstillstånd, inte generellt som antalet upptagna trådar. Även processer som avslutas och äldre generationer efter en graceful restart kan påverka bilden; kontrollera detaljerna för din installerade 2.4-version.

För att klassificera arkitekturen kompletterar Jämförelse mellan Event MPM och Worker MPM statusindikatorn. Valet av MPM förklarar hur Apache organiserar anslutningar och arbete, men det ersätter inte en granskning av den specifika servern och dess tillämpning.

Övervaka statusdata över tid

För Apache Monitoring är en enskild statussida bara en del av helheten. Låt den maskinläsbara utdata visas via ?auto Hämta dem regelbundet från en behörig agent och spara värdena med en tidsstämpel. På så sätt kan du till exempel se om det endast är ett fåtal lediga arbetare som dyker upp kortvarigt eller om de kvarstår över flera förfrågningar.

För en Intervallfrekvens Du jämför en kumulativ räknare med dess tidigare värde och delar skillnaden med den förflutna tiden. Om antalet besök till exempel ökar med 120 inom 60 sekunder motsvarar det i genomsnitt två besök per sekund för detta intervall. Detta medelvärde säger ännu ingenting om fördelningen inom minuten.

Kontrollera start- respektive omstartsinformation samt räknarställningen innan du beräknar skillnaden. Om servern har startats om eller om en räknare har gått ned jämfört med föregående avläsning, ska detta betraktas som en återställning och en ny jämförelseserie ska påbörjas. En negativ trafikfrekvens baserad på två mätarställningar skulle här vara missvisande; även uteblivna avläsningar bör förbli synliga i förloppet.

De genomsnittsvärden som mod_status visar över serverns drifttid jämnar ut korta belastningstoppar. En tidsserie med ett lämpligt valt avfrågningsintervall visar förändringar mer exakt, men kan också missa händelser som inträffar mellan två avfrågningar. Välj därför intervallet utifrån diagnosfrågan och ta hänsyn till arbetsinsatsen för insamling och lagring.

Även lagrade statusdata måste skyddas: Beroende på utdata kan de innehålla information om förfrågningar och klienter. Begränsa åtkomsten till agenten, lagringsutrymmet och utvärderingen till behöriga personer och system. Fastställ dessutom hur länge rådata och härledda nyckeltal ska bevaras för respektive driftsändamål.

Kontrollera åtkomst och felmeddelanden

Efter att en ändring har godkänts ska du först kontrollera att den avsedda behöriga åtkomsten fungerar, till exempel från den lokala övervakningsagenten. Kontrollera därefter både HTML-sidan och varianten från en nätverksplats som uttryckligen inte är tillåten ?auto. Ingen av dem får lämna ut statusuppgifter där. En test av endast en plats eller endast en åtkomstväg räcker inte.

Upprepa testet för de virtuella värdar som faktiskt kan nås och, vid behov, för direktanslutningar och anslutningar som går via en omvänd proxy. Att testet lyckas lokalt bevisar inte att proxyn tillämpar samma skydd. Var också uppmärksam på vidarebefordringar: det avgörande är om känsliga statusdata lämnas ut i slutet av en åtkomstväg.

Om en tillåten hämtning misslyckas, undersök förutom Auktorisation även lyssnare, adress och port samt valet av virtuell värd. Proxy- och omdirigeringsregler kan också leda till att förfrågan dirigeras på ett annat sätt än förväntat. Ett enskilt fel innebär därför inte med säkerhet att det rör sig om en felaktig åtkomstregel eller en defekt hanterare.

Kontrollera befintliga konfigurationer för att se om de innehåller gamla åtkomstregler som Order och Deny. Deras ogenomtänkta blandning med de nyare Require-Regler kan leda till oväntade resultat. Kontrollera vilken kombination som faktiskt fungerar, istället för att dra slutsatser om den slutgiltiga åtkomsten utifrån en enskild regel som tillåter åtkomst.

En skyddad plats är dessutom inte nödvändigtvis den enda möjliga statusändpunkten. Om mod_status är laddat kan dess hanterare även användas i konfigurationer per katalog, inklusive .htaccess finnas tillgängliga. Kontrollera därför befintliga poster och tillåtna delegeringar, särskilt på delade servrar, så att inga ytterligare oskyddade hanterare kan konfigureras.

Från indikationer till operativa beslut

Om många arbetare upprepade gånger är upptagna och endast ett fåtal är lediga, är detta en indikation på möjlig kapacitetsbelastning, men ännu inget bevis på orsaken. Jämför utvecklingen med svarstider, felfrekvenser och den faktiskt gällande gränsen för antalet arbetare. Det är först den samlade bilden som visar om beläggningen sammanfaller med märkbara problem och hur bestående dessa är.

Innan du höjer en gräns bör du kontrollera det tillgängliga minnet och det extra behovet hos de berörda processerna eller trådarna. Undersök samtidigt varför bearbetningarna tar lång tid: En högre grad av parallellitet kan låta den egentliga orsaken kvarstå och binda upp ytterligare resurser. Ändringar bör därför genomföras inom ramen för en kontrollerad driftsprocess med efterföljande övervakning.

Vid långsamma förfrågningar kan upprepade statuskontroller hjälpa till att avgränsa aktuella förfrågningar och tillhörande processer. Jämför tidpunkterna med åtkomst- och felloggar samt med data från applikationen och dess backend-system. En flyktig begäran kan försvinna mellan två avfrågningar; en enskild visning varken identifierar på ett tillförlitligt sätt en viss applikation som orsak eller bevisar att det rör sig om en attack.

För en iögonfallande Process-ID Du kan dessutom kontrollera operativsystemdata såsom CPU- och minnesanvändning. Denna koppling är ytterligare en ledtråd, men ersätter inte en tidsmässig jämförelse med förfrågningar och loggar. Särskilt vid upprepade observationer bör du ta hänsyn till att processer och de förfrågningar de just bearbetar kan variera.

När det gäller event-MPM bör du dessutom beakta avslutande processer och gamla generationer efter en ”graceful restart”. De kan påverka situationen under övergången; öppna anslutningar kan inte generellt likställas med permanent upptagna arbetstrådar. Kontrollera särdragen hos den installerade versionen av Apache 2.4 innan du drar slutsatser om den långsiktiga kapaciteten utifrån en sådan övergångsfas.