Sikring af Apache mod_status og korrekt tolkning af statusværdier

Hvad mod_status viser

Apache-modulet mod_status leverer oplysninger om den kørende webserver. Det hjælper blandt andet med at finde ud af, hvor mange worker-processer der er i gang, og hvilke anmodninger der behandles. De følgende forklaringer vedrører Apache HTTP Server 2.4; dokumentationen for udviklingsgrenen er adskilt herfra og kan ikke overføres til denne version uden nærmere undersøgelse.

En handler genererer statusudskriften for en konfigureret URL-sti. Et »Location«-afsnit kan videregive denne sti til handleren server-status tildele; der kræves ikke en fil med samme navn i DocumentRoot til dette formål. Stien giver således adgang til serverdiagnostik og er ikke en almindelig side, der leveres fra filsystemet.

HTML-visningen er velegnet til manuel fejlfinding. Varianten med ?auto leverer en maskinlæsbar repræsentation, som et overvågningssystem regelmæssigt kan hente. Hvilke detaljer der er tilgængelige, afhænger blandt andet af serverkonfigurationen. Parameteren gør ikke slutpunktet til en separat tjeneste: Også dens output skal beskyttes mod uautoriseret adgang.

Forudsætningen er, at mod_status er indlæst, og at du har tilladelse til at redigere den relevante Apache-konfiguration. For adgangsbegrænsninger skal de nødvendige autorisationsmoduler desuden være tilgængelige. Hvordan et modul aktiveres, og hvilke filer der er ansvarlige for dette, varierer afhængigt af distribution og installation; en enkelt filsti er derfor ikke et universelt udgangspunkt.

For Apache-overvågning Udskriften er en kilde til fejlfinding, men ikke en fuldstændig overvågning af applikationsydelsen. Den viser for eksempel, at workerne er i gang, men forklarer ikke i sig selv, om det er en database, et backend eller en langsom klient, der forsinker behandlingen. For at finde årsagen har du desuden brug for relevante applikations-, system- og logdata.

Statusdata og deres sikkerhedsmæssige konsekvenser

Statussiden viser blandt andet beskæftigede og ledige workere samt oplysninger om start- eller genstartstidspunktet og kørselstiden. Beskæftigede workere er på forespørgselstidspunktet ikke tilgængelige som ledig kapacitet. Hvor kritisk forholdet mellem beskæftigede og ledige workere er, kan først vurderes ud fra forløbet og den faktisk konfigurerede worker-grænse.

Tidsperioden hjælper med at sætte de aggregerede værdier ind i en tidsmæssig sammenhæng: Et gennemsnit siden opstarten kan skjule korte belastningstoppe. Ligeledes er en forespørgsel med få ledige arbejdere i første omgang blot et øjebliksbillede. Gentagne forespørgsler sammen med svartider og fejl giver et bedre grundlag for at undersøge en mulig knaphed.

Med Udvidet status Apache registrerer yderligere detaljer, herunder samlede antal besøg og datamængder samt oplysninger om aktuelle værter og anmodninger. Når mod_status indlæses, er denne registrering som standard aktiveret i Apache 2.4. En eksplicit konfigurationsbeslutning gør det dog muligt at se, hvilket detaljeringsniveau der er planlagt i den pågældende drift.

Den mere detaljerede registrering har sin pris: Den medfører ekstra arbejde og kan gøre serveren langsommere. Du bør derfor afveje den diagnostiske nytte mod denne indsats, i stedet for automatisk at betragte flere detaljer som en gratis forbedring. Uden ExtendedStatus mangler der på den anden side oplysninger, der kan være nyttige til at identificere igangværende forespørgsler.

Udskriften kan afsløre igangværende anmodninger og klientoplysninger. Behandl den derfor som følsomme driftsdata og ikke som en offentlig sundhedstjek. HTML-visningen og ?auto kræver den samme adgangsbeskyttelse; en sti, der er svær at gætte, forhindrer ikke adgang for nogen, der kender den eller opdager den.

Kontroller adgangsveje og worker-modellen

Inden du foretager en ændring, skal du registrere den installerede Apache-version og det aktive multiprocessing-modul, kort sagt MPM. Kontroller desuden, hvilke virtuelle værter der betjener den pågældende listener, om reverse-proxyer videresender forespørgsler, og hvilke adgangsregler der allerede gælder. Først med dette overblik kan man vurdere, hvor en ny regel vil have virkning, og hvilke eksisterende konfigurationer den kan påvirke.

En lokal overvågningsagent kunne hente status via en loopback-adresse. En vellykket lokal hentning viser dog kun, at netop denne forbindelse med den valgte adresse, port og den valgte virtuelle vært fungerer. Den beviser hverken, at andre værter er beskyttet, eller at ekstern adgang mislykkes.

En anden mulighed kan være via en reverse-proxy og en anden virtuel vært. Her kan andre omdirigeringer eller adgangsregler finde anvendelse; desuden skal det undersøges, hvilken klientadresse Apache rent faktisk bruger til autorisation. Se på Adgangsvej derfor inklusive proxy, valg af host og Apache-regler, i stedet for at overføre den lokale test til hele topologien.

MPM bestemmer, hvordan Apache anvender processer og eventuelt tråde til databehandling. En proces er en enhed i operativsystemet; tråde kører inden for en proces og kan der udføre opgaver. Betydningen af antallet af arbejdsprocesser afhænger derfor af den anvendte model. Den Sammenligning af Apache-arbejdermodellerne forklarer forskellene mellem Prefork, Worker og Event.

Især når det gælder event-MPM Åbne forbindelser er ikke nødvendigvis det samme som permanent optagede arbejdstråde. Visse ventetilstande kan behandles anderledes end den aktive behandling af en anmodning. Notér derfor den aktive MPM, før du træffer en beslutning om kapacitet på baggrund af antallet af forbindelser og arbejdstråde.

Opsætning af et lokalt statusendepunkt

Kontroller, inden du foretager ændringen, om Apache HTTP Server 2.4 kører, mod_status er indlæst, og de nødvendige autorisationsmoduler er tilgængelige. Registrer desuden de eksisterende virtuelle værter og adgangsregler. Modulaktivering og konfigurationsstier varierer afhængigt af distributionen; det følgende eksempel hører hjemme i den relevante Apache-konfigurationsfil, ikke i en generel standardfil.

Eksemplet skifter Udvidet status udtrykkeligt og tildeler stien til statusbehandleren. Require local begrænser adgangen i henhold til Apaches regler for lokale forbindelser. Direktivet til detaljeret logning står uden for »Location«-afsnittet. Inden du implementerer det, skal du kontrollere, hvordan dette afsnit fungerer sammen med din eksisterende konfiguration.

ExtendedStatus On

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

Sørg for, at ændringen kontrolleres og godkendes i henhold til din driftsproces, inden du implementerer den. Eksemplet er et udgangspunkt og ikke en garanti for alle virtuelle værter eller proxy-ruter. Især eksisterende autorisationsafsnit kan have indflydelse på, hvilken regel der gælder for en konkret forespørgsel.

Efter kørslen kan du hente den maskinlæsbare udskrift lokalt ved hjælp af følgende læsekommando. Den forudsætter, at der er oprettet en listener på den valgte loopback-adresse og standardporten 80. Kontroller også, om anmodningen når frem til den påtænkte virtuelle vært; hvis nødvendigt skal du tilpasse port- og værtsvalget til dit miljø.

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

En mislykket hentning er i første omgang blot en indikation, ikke en entydig fejldiagnose. Ud over autorisationen kan der f.eks. være tale om en anden lytter, en afvigende host-tildeling eller en omdirigering. En vellykket lokal hentning siger derimod ikke noget om, hvorvidt andre adgangsveje er beskyttet.

Sikker udvidelse af adgangen til overvågning

Vælg adgangsmetoden ud fra, hvor overvågningen foregår, og hvem der har brug for uddataene. En agent på samme vært kan benytte den lokale begrænsning. Hvis et eksternt system skal have adgang, bør adgangen begrænses til de kilder, der reelt er behov for, og derefter kontrolleres via den tilsigtede netværksvej.

Med Require ip Det er ikke alene afgørende, hvilken adresse overvågningsserveren har set fra sin egen synsvinkel. Bag en reverse-proxy skal den installerede konfiguration angive den adresse, som Apache rent faktisk bruger til autorisation. Kontroller denne tilknytning i praksis, inden du frigiver et netværk; en formodet klientadresse er ikke en pålidelig adgangskontrol.

Flere af dem Require-Direktiver inden for et afsnit fungerer som udgangspunkt som en ”eller”-operator: Hvis en anmodning opfylder en af betingelserne, kan det i sig selv være tilstrækkeligt. Hvis en klient skal komme fra det tilladte netværk og desuden logge ind, skal betingelserne udtrykkeligt angives i en <RequireAll>-Saml containerne og test begge krav hver for sig.

Ved Basic Authentication er det først en passende transportprotokol som TLS, der beskytter adgangsdataene under overførslen. Et separat administrationsnetværk kan yderligere begrænse adgangen, men erstatter ikke en effektiv Apache-autorisation. Også her bør kun autoriserede systemer kunne hente HTML-udskriften og den maskinlæsbare udskrift.

At placere statusværdier korrekt

Statussiden besvarer forskellige diagnosespørgsmål med forskellige data. Læs Arbejdstagerfordeling Derfor er den ikke isoleret: Den beskriver tilstanden på det tidspunkt, hvor den hentes. Yderligere detaljer om anmodningen afhænger af konfigurationen og især af ExtendedStatus; hvilke felter der vises, kan variere afhængigt af serveren og MPM’en.

Antag, at en forespørgsel viser mange optagede og kun få ledige arbejdere. Det kan være en kortvarig spidsbelastning eller tyde på et længerevarende pres. Gentag forespørgslen, og sammenlign udviklingen med svartider, fejl og den faktisk gældende worker-grænse, før du overvejer at ændre kapaciteten.

På event-MPM kan visse ventetilstande håndteres af lytteren i stedet for af permanent tilknyttede arbejdstråde. »Writing« og »Keep-alive« skal derfor opfattes som forbindelsestilstande og ikke generelt som et tal for antallet af optagede tråde. Også processer, der afsluttes, og ældre generationer efter en graceful restart kan påvirke billedet; tjek detaljerne for din installerede 2.4-version.

Med henblik på klassificeringen af arkitekturen supplerer Sammenligning af Event MPM og Worker MPM statusvisningen. Valget af MPM forklarer, hvordan Apache organiserer forbindelser og arbejde; det erstatter dog ikke en observation af den konkrete server og dens applikation.

Overvågning af statusdata over tid

For Apache Monitoring er en enkelt statusside blot et udsnit. Lad den maskinlæsbare udskrift komme via ?auto Hent dem regelmæssigt fra en autoriseret agent, og gem værdierne med et tidsstempel. På den måde kan du f.eks. se, om der kun er få ledige arbejdere i en kort periode, eller om de forbliver ledige over flere forespørgsler.

For en Intervalhastighed Du sammenligner en kumulativ tæller med dens forrige værdi og dividerer forskellen med den forløbne tid. Hvis antallet af besøg f.eks. stiger med 120 inden for 60 sekunder, svarer det for dette interval til gennemsnitligt to besøg pr. sekund. Dette gennemsnit siger dog endnu intet om fordelingen inden for det pågældende minut.

Kontroller oplysninger om opstart eller genstart samt tællerstandene, inden du beregner forskellen. Hvis serveren er blevet genstartet, eller hvis en tæller er faldet i forhold til den forrige aflæsning, skal du betragte dette som en nulstilling og starte en ny sammenligningsserie. En negativ trafikrate baseret på to tællerstande ville her være vildledende; også udfaldne forespørgsler bør forblive synlige i forløbet.

De gennemsnitstal, som mod_status udregner over serverens driftstid, udjævner korte belastningsspidser. En tidsserie med et passende forespørgselsinterval viser ændringer mere præcist, men kan også overse hændelser, der finder sted mellem to forespørgsler. Vælg derfor intervallet, så det passer til det problem, der skal diagnosticeres, og tag højde for den indsats, der kræves til indsamling og lagring.

Også gemte statusdata skal beskyttes: Afhængigt af udskriften kan de indeholde oplysninger om anmodninger og klienter. Begræns adgangen til agent, lager og analyse til autoriserede personer og systemer. Fastlæg desuden, hvor længe rådata og afledte nøgletal skal opbevares til det pågældende driftsformål.

Kontroller adgang og fejlmeddelelser

Efter at en ændring er blevet godkendt, skal du først kontrollere, om der er den forventede autoriserede adgang, f.eks. fra den lokale overvågningsagent. Kontroller derefter både HTML-siden og varianten fra en netværksplacering, hvor adgang udtrykkeligt ikke er tilladt ?auto. Ingen af dem må levere statusdata derfra. En test af kun én lokation eller via kun én adgangsvej er ikke tilstrækkelig.

Gentag testen for de virtuelle værter, der rent faktisk kan nås, og om nødvendigt for direkte forbindelser samt forbindelser, der går via en reverse-proxy. At testen lykkes lokalt, er ikke ensbetydende med, at proxyen sikrer den samme beskyttelse. Vær også opmærksom på omdirigeringer: Det afgørende er, om der i slutningen af en adgangsvej udleveres følsomme statusdata.

Hvis en tilladt hentning mislykkes, skal du ud over Godkendelse herunder lytter, adresse og port samt valget af den virtuelle vært. Proxy- og omdirigeringsregler kan ligeledes omdirigere anmodningen på en anden måde end forventet. En enkelt fejl er derfor ikke i sig selv et sikkert tegn på hverken en forkert adgangsregel eller en defekt handler.

Kontroller eksisterende konfigurationer for gamle adgangsregler som f.eks. Order og Deny. Deres uovervejede blanding med de nyere Require-Regler kan føre til uventede resultater. Kontroller den kombination, der rent faktisk virker, i stedet for at konkludere, at adgangen er tilladt, ud fra en enkelt tilladende regel.

En beskyttet placering er desuden ikke nødvendigvis det eneste mulige statuspunkt. Hvis mod_status er indlæst, kan dens handler også i konfigurationer pr. mappe, herunder .htaccess være tilgængelig. Kontroller derfor eksisterende poster og tilladte delegationer, især på fælles servere, så der ikke kan oprettes yderligere ubeskyttede handlere.

Fra indicier til driftsbeslutninger

Hvis der gentagne gange er mange arbejdere i gang og kun få ledige, er det et tegn på mulig kapacitetsbelastning, men endnu ikke et bevis på årsagen. Sammenlign udviklingen med svartider, fejlprocenter og den faktisk gældende worker-grænse. Først det samlede billede viser, om belægningen falder sammen med mærkbare problemer, og hvor vedvarende disse er.

Inden du hæver en grænse, skal du kontrollere den tilgængelige hukommelse og det ekstra behov hos de pågældende processer eller tråde. Undersøg samtidig, hvorfor behandlinger tager lang tid: En højere grad af parallelitet kan lade den egentlige årsag bestå og binde yderligere ressourcer. Ændringer bør derfor indgå i en kontrolleret driftsproces med efterfølgende overvågning.

Ved langsomme forespørgsler kan gentagne statusforespørgsler hjælpe med at indsnævre de aktuelle forespørgsler og de tilhørende processer. Sammenlign tidspunkterne med adgangs- og fejllogfiler samt med data fra applikationen og dens backend-systemer. En flygtig anmodning kan forsvinde mellem to statusforespørgsler; en enkelt registrering kan hverken pålideligt identificere en bestemt applikation som årsagen eller bevise, at der er tale om et angreb.

For en iøjnefaldende Proces-ID Du kan desuden kontrollere operativsystemdata såsom CPU- og hukommelsesforbrug. Denne sammenkobling er et yderligere spor, men erstatter ikke en tidsmæssig sammenligning med anmodninger og logfiler. Især ved gentagne observationer bør du tage højde for, at processer og de anmodninger, de netop behandler, kan skifte.

Ved event-MPM skal du desuden være opmærksom på processer, der afsluttes, og gamle generationer efter en »graceful restart«. De kan påvirke billedet under overgangen; åbne forbindelser skal i den forbindelse ikke generelt sidestilles med permanent optagede arbejdstråde. Undersøg de særlige forhold ved den installerede Apache 2.4-version, inden du ud fra en sådan overgangsfase træffer en permanent beslutning om kapaciteten.