Zabezpieczenie modułu Apache mod_status i prawidłowa interpretacja wartości stanu

Co wyświetla mod_status

Moduł Apache mod_status udostępnia informacje o działającym serwerze WWW. Pomaga on na przykład ustalić, ile procesów roboczych jest aktualnie aktywnych i jakie żądania są właśnie przetwarzane. Poniższe wyjaśnienia odnoszą się do serwera Apache HTTP 2.4; dokumentacja gałęzi rozwojowej jest od niej odrębna i nie można jej przenieść na tę wersję bez uprzedniej weryfikacji.

A Handler generuje komunikat o stanie dla skonfigurowanej ścieżki URL. Sekcja „Location” może przekazać tę ścieżkę do modułu obsługi server-status przypisać; nie jest do tego wymagany plik o tej samej nazwie w katalogu DocumentRoot. Ścieżka ta stanowi zatem dostęp do narzędzi diagnostycznych serwera, a nie zwykłą stronę dostarczaną z systemu plików.

Do ręcznej diagnostyki nadaje się widok HTML. Wariant z ?auto zapewnia format nadający się do odczytu maszynowego, z którego system monitorujący może regularnie pobierać dane. To, jakie szczegóły są dostępne, zależy między innymi od konfiguracji serwera. Parametr ten nie przekształca punktu końcowego w oddzielną usługę: również jego dane wyjściowe muszą być chronione przed nieuprawnionym dostępem.

Warunkiem jest, aby moduł mod_status był załadowany oraz abyś miał uprawnienia do edycji odpowiedniej konfiguracji serwera Apache. W przypadku ograniczeń dostępu muszą być również dostępne niezbędne moduły autoryzacyjne. Sposób aktywacji modułu oraz pliki odpowiedzialne za tę operację różnią się w zależności od dystrybucji i instalacji; dlatego też podanie pojedynczej ścieżki do pliku nie stanowi uniwersalnego punktu wyjścia.

Dla Monitorowanie serwera Apache Wynik ten stanowi źródło informacji diagnostycznych, ale nie jest kompletnym monitorowaniem wydajności aplikacji. Pokazuje na przykład, że procesy robocze są zajęte, ale sam w sobie nie wyjaśnia, czy to baza danych, backend czy też powolny klient opóźnia przetwarzanie. Aby ustalić takie przyczyny, potrzebujesz dodatkowo odpowiednich danych dotyczących aplikacji, systemu i logów.

Dane dotyczące statusu i ich konsekwencje dla bezpieczeństwa

Strona stanu wyświetla między innymi informacje o zajętych i wolnych workerach, a także dane dotyczące czasu uruchomienia lub ponownego uruchomienia oraz czasu działania. Zajęci workerzy nie są dostępni jako wolna pojemność w momencie zapytania. To, na ile krytyczny jest stosunek liczby zajętych do wolnych workerów, można ocenić dopiero na podstawie historii oraz faktycznie skonfigurowanego limitu workerów.

Okres pomiaru pomaga osadzić wartości zagregowane w kontekście czasowym: średnia od momentu uruchomienia może maskować krótkotrwałe szczyty obciążenia. Podobnie, zapytanie przy niewielkiej liczbie wolnych pracowników stanowi początkowo jedynie migawkę sytuacji. Powtarzające się zapytania w połączeniu z czasami odpowiedzi i błędami stanowią lepszą podstawę do zbadania ewentualnego niedoboru zasobów.

Z Status rozszerzony Apache rejestruje dodatkowe szczegóły, w tym zagregowaną liczbę odwiedzin i objętość danych, a także informacje o aktualnych hostach i żądaniach. Po załadowaniu modułu mod_status rejestracja ta jest domyślnie włączona w Apache 2.4. Wyraźna decyzja konfiguracyjna pozwala jednak ustalić, jaki poziom szczegółowości jest przewidziany w danym środowisku operacyjnym.

Bardziej szczegółowe rejestrowanie ma swoją cenę: wiąże się z dodatkowym nakładem pracy i może spowolnić działanie serwera. Dlatego warto rozważyć korzyści diagnostyczne w stosunku do tego nakładu, zamiast automatycznie traktować większą ilość szczegółów jako bezpłatne ulepszenie. Z drugiej strony, bez ExtendedStatus brakuje informacji, które mogą być pomocne w przypisywaniu bieżących żądań.

Wynik może ujawniać bieżące żądania i informacje o kliencie. Należy zatem traktować go jako wrażliwe dane operacyjne a nie jako publiczną ocenę stanu zdrowia. Widok HTML i ?auto wymagają takiego samego zabezpieczenia dostępu; ścieżka, którą trudno odgadnąć, nie uniemożliwia dostępu osobie, która ją zna lub odkryła.

Sprawdź ścieżki dostępu i model pracowników

Przed wprowadzeniem zmian sprawdź zainstalowaną wersję serwera Apache oraz aktywny moduł wieloprocesowy (w skrócie MPM). Sprawdź również, które wirtualne hosty obsługują dany listener, czy serwery proxy odwrotne przekazują żądania oraz jakie reguły dostępu już obowiązują. Dopiero po uzyskaniu takiego przeglądu można ocenić, gdzie nowa reguła będzie miała zastosowanie i na jakie istniejące konfiguracje może ona wpłynąć.

Lokalny agent monitorujący mógłby sprawdzić stan za pomocą adresu pętli zwrotnej. Pomyślne sprawdzenie lokalne wskazuje jednak jedynie, że ta konkretna ścieżka z wybranym adresem, portem i wirtualnym hostem działa. Nie dowodzi to ani tego, że inne hosty są chronione, ani tego, że dostęp z zewnątrz nie powiedzie się.

Drugim rozwiązaniem może być wykorzystanie serwera proxy odwrotnego i innego wirtualnego hosta. W tym przypadku mogą obowiązywać inne reguły przekierowań lub dostępu; należy również sprawdzić, z którego adresu klienta Apache faktycznie korzysta do autoryzacji. Spójrz na ścieżka dostępu dlatego też, uwzględniając serwer proxy, wybór hosta i reguły Apache’a, zamiast przenosić lokalny test na całą topologię.

MPM określa, w jaki sposób Apache wykorzystuje procesy i, w razie potrzeby, wątki do przetwarzania. Proces jest jednostką systemu operacyjnego; wątki działają w ramach procesu i mogą tam wykonywać zadania. Znaczenie liczby procesów roboczych zależy zatem od zastosowanego modelu. Porównanie modeli procesów roboczych Apache’a wyjaśnia różnice między Prefork, Worker i Event.

Szczególnie w przypadku event-MPM Otwarte połączenia nie oznaczają automatycznie, że wątki robocze są stale zajęte. Niektóre stany oczekiwania mogą być traktowane inaczej niż aktywne przetwarzanie żądania. Dlatego przed podjęciem decyzji dotyczącej wydajności na podstawie liczby połączeń i wątków roboczych należy sprawdzić, jaki moduł MPM jest aktualnie aktywny.

Konfiguracja lokalnego punktu końcowego stanu

Przed wprowadzeniem zmian sprawdź, czy działa serwer Apache HTTP 2.4, mod_status jest załadowany, a wymagane moduły autoryzacyjne są dostępne. Należy również zarejestrować istniejące wirtualne hosty i reguły dostępu. Aktywacja modułów i ścieżki konfiguracyjne różnią się w zależności od dystrybucji; poniższy przykład należy umieścić w odpowiednim pliku konfiguracyjnym serwera Apache, a nie w pliku, którego obecność jest ogólnie zakładana.

W tym przykładzie włącza się Status rozszerzony wyraźnie go akceptuje i przypisuje ścieżkę do modułu obsługi statusu. Require local ogranicza dostęp zgodnie z regułami Apache'a dotyczącymi połączeń lokalnych. Dyrektywa dotycząca szczegółowego rejestrowania znajduje się poza sekcją „Location”. Przed wdrożeniem należy sprawdzić, jak ta sekcja współdziała z istniejącą konfiguracją.

ExtendedStatus On

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

Przed zastosowaniem zmiany należy ją sprawdzić i zatwierdzić zgodnie z procedurami operacyjnymi. Podany przykład stanowi jedynie punkt wyjścia i nie gwarantuje poprawności działania dla wszystkich wirtualnych hostów lub ścieżek proxy. W szczególności istniejące sekcje autoryzacji mogą wpływać na to, która reguła ma zastosowanie do konkretnego żądania.

Po uruchomieniu aplikacji możesz lokalnie pobrać wynik w formacie nadającym się do odczytu maszynowego za pomocą poniższego polecenia odczytującego. Wymaga ono skonfigurowania nasłuchu na wybranym adresie pętli zwrotnej oraz domyślnym porcie 80. Sprawdź również, czy żądanie dociera do przewidzianego wirtualnego hosta; w razie potrzeby dostosuj wybór portu i hosta do swojego środowiska.

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

Nieudane wywołanie to na razie jedynie wskazówka, a nie jednoznaczna diagnoza błędu. Oprócz kwestii autoryzacji przyczyną mogą być na przykład inny listener, inne przypisanie hosta lub przekierowanie. Z kolei pomyślne wywołanie lokalne nie oznacza jeszcze, że inne ścieżki dostępu są zabezpieczone.

Bezpieczne rozszerzenie dostępu do monitoringu

Wybierz ścieżkę dostępu w zależności od tego, gdzie odbywa się monitorowanie i kto potrzebuje wyników. Agent na tym samym hoście może korzystać z ograniczeń lokalnych. Jeśli dostęp musi uzyskać system zewnętrzny, należy ograniczyć udostępnienie do źródeł faktycznie potrzebnych, a następnie sprawdzić je za pomocą przewidzianej ścieżki sieciowej.

Na stronie Require ip Nie ma znaczenia wyłącznie to, jaki adres serwer monitorujący widzi z własnej perspektywy. W przypadku odwrotnego proxy zainstalowana konfiguracja musi podawać adres, który Apache faktycznie wykorzystuje do autoryzacji. Sprawdź to powiązanie w rzeczywistych warunkach przed udostępnieniem sieci; domniemany adres klienta nie stanowi wiarygodnej kontroli dostępu.

Kilka Require-Dyrektywy w obrębie sekcji działają zasadniczo jak Operator „lub”: Jeśli zapytanie spełnia jeden z warunków, to może już wystarczyć. Jeśli klient ma pochodzić z dozwolonej sieci i dodatkowo się zalogować, należy wyraźnie sformułować te warunki w <RequireAll>-Połącz kontenery i przetestuj oba wymagania osobno.

W przypadku uwierzytelniania podstawowego dane dostępowe są chronione podczas przesyłania wyłącznie dzięki zastosowaniu odpowiedniego protokołu transportowego, takiego jak TLS. Oddzielna sieć administracyjna może dodatkowo ograniczyć dostępność, ale nie zastępuje skutecznego uwierzytelniania w serwerze Apache. Również w tym przypadku tylko uprawnione systemy powinny mieć możliwość pobierania wyników w formacie HTML oraz w formacie nadającym się do odczytu maszynowego.

Prawidłowe klasyfikowanie wartości stanu

Strona stanu zawiera odpowiedzi na różne pytania diagnostyczne wraz z odpowiednimi danymi. Przeczytaj Przypisanie pracowników nie jest więc informacją izolowaną: opisuje stan w momencie wywołania. Dodatkowe szczegóły żądania zależą od konfiguracji, a w szczególności od ExtendedStatus; to, które pola się pojawiają, może się różnić w zależności od serwera i modułu MPM.

Załóżmy, że podczas sprawdzania widocznych jest wielu zajętych pracowników i tylko kilku wolnych. Może to być krótkotrwały szczyt obciążenia lub wskazywać na długotrwałe obciążenie. Powtórz zapytanie i porównaj przebieg z czasami odpowiedzi, błędami oraz faktycznie obowiązującym limitem pracowników, zanim rozważysz zmianę wydajności.

Na stronie event-MPM Niektóre stany oczekiwania mogą być obsługiwane przez moduł nasłuchujący zamiast przez trwale powiązane wątki robocze. Stany „Writing” i „Keep-alive” należy zatem traktować jako stany połączeń, a nie ogólną liczbę zajętych wątków. Na obraz sytuacji mogą również wpływać kończące się procesy oraz starsze generacje po płynnym restarcie; sprawdź szczegóły dotyczące zainstalowanej wersji 2.4.

W celu klasyfikacji architektury uzupełnieniem jest Porównanie modeli MPM typu „event” i „worker” Wskaźnik stanu. Model MPM wyjaśnia, w jaki sposób Apache organizuje połączenia i pracę; nie zastępuje on jednak obserwacji konkretnego serwera i jego aplikacji.

Obserwowanie danych o stanie w czasie

W przypadku Apache Monitoring pojedyncza strona stanu to tylko fragment całości. Wyświetl wersję przeznaczoną dla maszyn za pomocą ?auto regularnie pobieraj je od uprawnionego agenta i zapisuj wartości wraz z sygnaturą czasową. W ten sposób możesz na przykład sprawdzić, czy niewielka liczba wolnych workerów pojawia się tylko na krótko, czy też utrzymuje się przez kilka zapytań.

Dla Częstotliwość interwałów Porównujesz skumulowaną wartość licznika z jego poprzednią wartością i dzielisz różnicę przez upływający czas. Jeśli na przykład liczba odwiedzin wzrośnie o 120 w ciągu 60 sekund, oznacza to średnio dwie odwiedziny na sekundę w tym przedziale czasowym. Ta średnia nie mówi jednak nic o rozkładzie w obrębie tej minuty.

Przed obliczeniem różnicy sprawdź informacje o uruchomieniu lub ponownym uruchomieniu oraz stan licznika. Jeśli serwer został ponownie uruchomiony lub stan licznika spadł w porównaniu z poprzednim odczytem, potraktuj to jako reset i rozpocznij nową serię porównawczą. Ujemna wartość przepływu wynikająca z dwóch odczytów licznika mogłaby w tym przypadku wprowadzać w błąd; również nieudane zapytania powinny być widoczne w historii.

Średnie wartości generowane przez mod_status w całym okresie działania serwera wygładzają krótkotrwałe skoki obciążenia. Szereg czasowy z odpowiednio dobranym interwałem zapytań dokładniej odzwierciedla zmiany, ale może również pomijać zdarzenia występujące między dwoma zapytaniami. Należy zatem dobrać interwał odpowiednio do celu diagnostycznego, biorąc pod uwagę nakład pracy związany z gromadzeniem i przechowywaniem danych.

Również zapisane dane dotyczące stanu wymagają ochrony: w zależności od rodzaju danych mogą one zawierać informacje o żądaniach i klientach. Należy ograniczyć dostęp do agenta, pamięci i analizy wyłącznie do uprawnionych osób i systemów. Należy również określić, jak długo dane surowe i wyliczone wskaźniki będą przechowywane dla danego celu operacyjnego.

Sprawdź dostęp i komunikaty o błędach

Po zatwierdzeniu zmiany sprawdź najpierw, czy dostęp jest zgodny z uprawnieniami, na przykład ze strony lokalnego agenta monitorującego. Następnie sprawdź zarówno stronę HTML, jak i jej wariant z lokalizacji sieciowej, do której dostęp jest wyraźnie zabroniony ?auto. Żadna z tych stron nie może tam przekazywać danych dotyczących statusu. Test przeprowadzony tylko w jednej lokalizacji lub tylko na jednej ścieżce dostępu nie jest wystarczający.

Powtórz test dla faktycznie dostępnych hostów wirtualnych oraz, w razie potrzeby, dla połączeń bezpośrednich i realizowanych za pośrednictwem serwera proxy odwrotnego. Lokalny sukces nie oznacza, że serwer proxy zapewnia taki sam poziom ochrony. Zwróć również uwagę na przekierowania: decydujące znaczenie ma to, czy na końcu ścieżki dostępu ujawniane są wrażliwe dane dotyczące stanu.

Jeśli dozwolone wywołanie zakończy się niepowodzeniem, należy sprawdzić, oprócz Autoryzacja a także słuchacz, adres i port, jak również wybór wirtualnego hosta. Również reguły proxy i przekierowania mogą spowodować, że żądanie zostanie przekierowane inaczej niż oczekiwano. Dlatego pojedynczy błąd nie pozwala z całą pewnością stwierdzić, czy przyczyną jest nieprawidłowa reguła dostępu, czy też uszkodzony moduł obsługi.

Sprawdź istniejące konfiguracje pod kątem starych dyrektyw dostępu, takich jak Order oraz Deny. Ich nieprzemyślane połączenie z nowszymi Require-Zasady mogą prowadzić do nieoczekiwanych wyników. Sprawdź, która kombinacja faktycznie działa, zamiast wyciągać wnioski o ostatecznym dostępie na podstawie pojedynczej zasady zezwalającej.

Ponadto lokalizacja chroniona niekoniecznie jest jedynym możliwym punktem końcowym statusu. Jeśli moduł mod_status jest załadowany, jego handler może również występować w konfiguracjach dla poszczególnych katalogów, w tym .htaccess być dostępne. Należy zatem sprawdzić istniejące wpisy i dozwolone delegacje, zwłaszcza na serwerach współużytkowanych, aby nie można było skonfigurować kolejnego niezabezpieczonego modułu obsługi.

Od poszlak do decyzji operacyjnych

Jeśli wielokrotnie wiele procesów roboczych jest zajętych, a tylko kilka pozostaje wolnych, wskazuje to na potencjalne obciążenie wydajnościowe, ale nie stanowi jeszcze dowodu na przyczynę. Porównaj ten trend z czasami odpowiedzi, wskaźnikami błędów oraz faktycznie obowiązującym limitem liczby pracowników. Dopiero całościowy obraz pokaże, czy obłożenie pokrywa się z zauważalnymi problemami i jak długotrwałe są one.

Zanim zwiększysz limit, sprawdź dostępną pamięć oraz dodatkowe zapotrzebowanie planowanych procesów lub wątków. Jednocześnie zbadaj, dlaczego operacje trwają tak długo: większa równoległość może nie wyeliminować rzeczywistej przyczyny i pochłonąć dodatkowe zasoby. Dlatego zmiany należy wprowadzać w ramach kontrolowanego procesu operacyjnego, a następnie monitorować ich działanie.

W przypadku powolnych żądań wielokrotne sprawdzanie statusu pomaga zawęzić zakres aktualnych żądań i powiązanych procesów. Porównaj te czasy z logami dostępu i błędów, a także z danymi aplikacji i jej zaplecza. Przelotne żądanie może zniknąć między dwoma sprawdzeniami statusu; pojedynczy wpis nie pozwala ani wiarygodnie zidentyfikować konkretnej aplikacji jako przyczyny, ani nie stanowi dowodu na atak.

Aby uzyskać efektowny Identyfikator procesu Możesz dodatkowo sprawdzić dane dotyczące systemu operacyjnego, takie jak wykorzystanie procesora i pamięci. Ta korelacja stanowi dodatkową wskazówkę, ale nie zastępuje porównania czasowego z żądaniami i logami. Zwłaszcza w przypadku powtarzających się obserwacji należy wziąć pod uwagę, że procesy i aktualnie przetwarzane przez nie żądania mogą ulegać zmianom.

W przypadku event-MPM należy również zwrócić uwagę na procesy kończące działanie oraz stare generacje po płynnym restarcie. Mogą one wpływać na obraz sytuacji podczas przejścia; otwartych połączeń nie należy przy tym automatycznie utożsamiać z trwale zajętymi wątkami roboczymi. Przed podjęciem ostatecznej decyzji dotyczącej wydajności na podstawie wyników takiej fazy przejściowej należy sprawdzić specyfikę zainstalowanej wersji Apache 2.4.