ModSecurity

ModSecurity to otwartoźródłowy silnik zapory aplikacji webowych, czyli WAF, działający po stronie serwera WWW ^[1]. Sprawdza żądania HTTP według reguł zapisanych w języku SecRules, zanim trafią do aplikacji ^[1]. Podręcznik WordPressa nazywa ModSecurity najpopularniejszym otwartoźródłowym WAF-em ^[8]. Silnik sam niczego nie blokuje; o skuteczności decydują reguły, najczęściej zestaw OWASP CRS albo reguły przygotowane przez firmę hostingową.

Jak działa

Podręcznik WordPressa opisuje WAF na serwerze WWW jako warstwę, która filtruje treść, zanim przetworzy ją WordPress ^[8]. ModSecurity analizuje nagłówki, parametry i treść żądania, a reguła wskazuje, czego szukać i co zrobić przy trafieniu. Najczęściej stosowanym zestawem reguł jest OWASP CRS (Core Rule Set), opisany przez twórców jako zestaw ogólnych reguł wykrywania ataków dla ModSecurity i zgodnych zapór ^[2]. CRS obejmuje między innymi SQL injection, XSS, dołączanie plików lokalnych (LFI) i zdalnych, wstrzykiwanie kodu PHP oraz wstrzykiwanie poleceń ^[2].

CRS stosuje tryb punktacji anomalii. Trafiona reguła nie blokuje żądania od razu, tylko dodaje punkty do sumy dla danej transakcji ^[3]. Gdy suma osiągnie próg, transakcja zostaje odrzucona ^[3]. Dokumentacja zaleca próg wejściowy 5 ^[3]. Przebieg pokazuje schemat poniżej.

RYS. 1Żądanie przez ModSecurity z CRS

Odmiany

Projekt istnieje w dwóch liniach. Wersja 2.x jest modułem serwera Apache i nadal jest utrzymywana ^[1]. Wersja 3, czyli biblioteka libmodsecurity, została przepisana od nowa bez zależności od Apache ^[1]. Do konkretnych serwerów, takich jak Apache, Nginx czy IIS, podłącza się ją przez osobne łączniki (connectors) rozwijane w oddzielnych projektach ^[1]. Biblioteka jest napisana w C++17 i udostępniona na licencji Apache-2.0 ^[1].

Czułość CRS reguluje poziom paranoi. Poziomów jest cztery ^[4].

Dokumentacja uprzedza, że dostrojenie najwyższego poziomu może zająć wiele tygodni ^[4].

W WordPressie

Na hostingu współdzielonym ModSecurity zwykle działa po stronie dostawcy i właściciel strony nie widzi jego konfiguracji. Najczęstszym objawem jest nagły błąd 403 przy konkretnej czynności. SEOHOST wymienia jako typowe sytuacje zapis wpisu w CMS, wysłanie formularza albo wejście pod określony adres ^[7]. Potwierdzeniem jest wpis w logu błędów z komunikatem „ModSecurity: Access denied with code 403” i identyfikatorem reguły w nawiasach ^[7].

WordPress wysyła w żądaniach treści, które wyglądają podejrzanie dla reguł ogólnych: kod HTML we wpisach, fragmenty skryptów w widżetach, długie parametry w zapytaniach do REST API. Dlatego projekt CRS utrzymuje osobną wtyczkę z wyjątkami dla WordPressa, żeby system mógł działać razem z CRS ^[6]. Dokumentacja CRS wymienia gotowe pakiety wyjątków dla popularnych aplikacji, w tym WordPressa, jako punkt wyjścia do strojenia ^[5].

ModSecurity nie zastępuje wtyczki bezpieczeństwa ani odwrotnie. Wtyczka działa wewnątrz PHP i zna kontekst WordPressa, na przykład role użytkowników. ModSecurity działa wcześniej, na serwerze, i obejmuje także pliki, których WordPress nie ładuje.

Zagrożenia i skutki

Fałszywy alarm (false positive) to według dokumentacji CRS sytuacja, w której prawidłowe żądanie błędnie uruchamia regułę ^[5]. Wynika to z tego, że reguły są ogólne i nie znają szczegółów konkretnej aplikacji ^[5]. Dla redakcji objawia się to utraconym tekstem wpisu albo niedziałającym formularzem.

Najgorszą reakcją jest wyłączenie całej zapory. SEOHOST wskazuje, że długotrwałe wyłączenie firewalla obniża bezpieczeństwo strony i że lepiej zostawić WAF włączony, wyłączając tylko reguły blokujące legalne żądania ^[7]. Zbyt szerokie wyjątki mają podobny skutek: reguła wyłączona dla całej witryny przestaje chronić także przed prawdziwymi atakami.

Jak się bronić

• Przy błędzie 403 zanotować czas, adres, IP klienta i pełny komunikat reguły z logu ^[7], a potem przekazać identyfikator reguły firmie hostingowej.
• Dodawać wyjątki dla konkretnych identyfikatorów reguł zamiast wyłączać ModSecurity; pełne wyłączenie traktować tylko jako krótki test ^[7].
• Nie edytować plików reguł CRS. Dokumentacja zaleca wyjątki, bo modyfikacja plików tworzy trudny w utrzymaniu fork i utrudnia aktualizacje ^[5].
• Zawężać wyjątek do parametru, a nie do całej reguły, jeśli to możliwe.

Dokumentacja CRS rozróżnia wyjątki ładowane przy starcie i wyjątki stosowane w trakcie obsługi żądania ^[5]. Dwa przykłady wyjątków ładowanych przy starcie, wzięte z dokumentacji, pokazują różnicę między usunięciem reguły a zawężeniem jej zakresu ^[5]:

# usuwa całą regułę
SecRuleRemoveById 933151
# wyłącza sprawdzanie jednego parametru w regule
SecRuleUpdateTargetById 941320 "!ARGS:wp_post"

Reguły WAF mogą też służyć jako wirtualne patchowanie (virtual patching), czyli blokowanie wykorzystania znanej podatności do czasu wydania łatki. Nie jest to jednak zamiennik aktualizacji wtyczek i rdzenia.

Historia i przykłady

Rozwój ModSecurity przez lata sponsorowała firma Trustwave; według repozytorium projektu sponsoring trwał do lipca 2024 roku, a projekt działa obecnie pod opieką OWASP ^[1]. Repozytorium znajduje się w organizacji owasp-modsecurity w serwisie GitHub ^[1]. OWASP CRS działa zarówno z ModSecurity, jak i z Coraza, alternatywnym silnikiem zgodnym z tym samym formatem reguł ^[2].